Dokumentenkennung: CD.TCOS.ASE Dateiname: ASE TCOS ID 2.0.1 (NXP).docx Stand: 26.07.2019 Version: 2.0.1 Hardware Basis: P6022y Autor: Ernst-G. Giessmann Geltungsbereich: TeleSec Entwicklungsgruppe Vertraulichkeitsstufe: Öffentlich  T-Systems International GmbH, 2019 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 ID Version 2.0 Release 1/P6022y Version: 2.0.1/20190726 Security Target TCOS ID Version 2.0 Release 1/P6022y 2/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 History Version Date Remark 2.0.1 2019-07-26 Final document Security Target TCOS ID Version 2.0 Release 1/P6022y 3/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 Contents Contents ..................................................................................................................................................3 1 ST Introduction........................................................................................................................5 1.1 ST Reference............................................................................................................................5 1.2 TOE Reference .........................................................................................................................5 1.3 TOE Overview...........................................................................................................................5 1.3.1 TOE security features for operational use ...........................................................................8 1.3.2 TOE Type.............................................................................................................................8 1.3.3 File System of the TOE........................................................................................................9 1.3.4 Life Cycle Phases Mapping .................................................................................................9 1.3.5 Non-TOE hardware/software/firmware ............................................................................. 12 1.3.6 TOE Boundaries................................................................................................................ 13 1.3.7 Conformance to eIDAS ..................................................................................................... 13 2 Conformance Claim ............................................................................................................. 14 2.1 CC Conformance Claims ....................................................................................................... 14 2.2 PP Claims .............................................................................................................................. 14 2.3 Package Claims ..................................................................................................................... 15 2.4 Conformance Claim Rationale ............................................................................................... 15 3 Security Problem Definition................................................................................................ 17 3.1 Assets and External Entities .................................................................................................. 17 3.2 Threats ................................................................................................................................... 20 3.3 Organizational Security Policies ............................................................................................ 26 3.4 Assumptions........................................................................................................................... 30 4 Security Objectives.............................................................................................................. 32 4.1 Security Objectives for the TOE............................................................................................. 32 4.2 Security Objectives for the Operational Environment ............................................................ 38 4.3 Security Objective Rationale.................................................................................................. 43 5 Extended Components Definition ...................................................................................... 46 5.1 FAU_SAS Audit data storage ................................................................................................ 46 5.2 FCS_RND Generation of random numbers........................................................................... 46 5.3 FIA_API Authentication Proof of Identity................................................................................ 47 5.4 FMT_LIM Limited capabilities and availability ....................................................................... 47 5.5 FPT_EMS TOE Emanation................................................................................................... 48 6 Security Requirements........................................................................................................ 50 6.1 Security Functional Requirements for the TOE ..................................................................... 50 6.1.1 Overview ........................................................................................................................... 51 6.1.2 Class FAU Security Audit.................................................................................................. 54 6.1.3 Class FCS Cryptographic Support.................................................................................... 55 6.1.4 Class FIA Identification and Authentication ...................................................................... 70 6.1.5 Class FDP User Data Protection ...................................................................................... 86 6.1.6 Class FMT Security Management................................................................................... 101 6.1.7 Class FPT Protection of the Security Functions ............................................................. 120 Security Target TCOS ID Version 2.0 Release 1/P6022y 4/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 6.1.8 Class FTP Inter-TSF trusted channel ............................................................................. 127 6.2 Security Assurance Requirements for the TOE................................................................... 131 6.3 Security Requirements Rationale ........................................................................................ 131 6.3.1 Rationale for SFR’s Dependencies................................................................................. 131 6.3.2 Security Assurance Requirements Rationale ................................................................. 134 7 TOE Summary Specification............................................................................................. 135 7.1 General Protection of User Data and TSF Data .................................................................. 135 7.2 Identification and Authentication .......................................................................................... 136 7.3 Access Control ..................................................................................................................... 137 7.4 Cryptographic Functions ...................................................................................................... 138 7.5 Protection of Communication............................................................................................... 139 7.6 Accuracy of the TOE security functionality /Self-protection................................................. 139 7.7 Statement of Compatibility ................................................................................................... 140 7.7.1 Relevance of Hardware TSFs......................................................................................... 140 7.7.2 Security Requirements.................................................................................................... 141 7.7.3 Security Objectives ......................................................................................................... 143 7.7.4 Conclusion ...................................................................................................................... 145 7.8 Assurance Measures ........................................................................................................... 145 Appendix Glossary and Acronyms.................................................................................................. 147 References ......................................................................................................................................... 148 Security Target TCOS ID Version 2.0 Release 1/P6022y 5/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 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 ID Version 2.0 Release 1/P6022y TOE: TCOS ID Version 2.0 Release 1/P6022y Sponsor: T-Systems International GmbH Editor(s): T-Systems International GmbH, TeleSec CC Version: 3.1 (Revision 5) Assurance Level: EAL4 augmented. General Status: Final Document Version Number: 2.0.1 Date: 2019-07-26 Certification ID: BSI-DSZ-CC-1078 Keywords: ICAO, PACE, EAC, Extended Access Control, ID-Card, Machine Readable Electronic Document, TCOS 1.2 TOE Reference 3 This Security Target refers to the Product “TCOS ID Version 2.0 Release 1/P6022y” (TOE) of T-Systems International GmbH for CC evaluation. 1.3 TOE Overview 4 The Target of Evaluation (TOE) addressed by this Security Target is a smart card with contact based and contact-less interfaces programmed according to [EACTR]. The smart card contains at least one application described in the following. In this ST the TOE as a whole is also called Electronic Document. 5 Here, an application is a collection of data (data groups) and their access conditions. We mainly distinguish between common user data, and sensitive user-data. Depending on the protection mechanisms involved, these user data can further be distinguished as follows: • EAC1-protected data: Sensitive user data protected by EAC1 (cf. [EACTR-1]), • EAC2-protected data: Sensitive user data protected by EAC2 (cf. [EACTR-2]), and • all other (common) user data. Other user data are protected by Password Authenti- cated Connection Establishment (PACE, cf. also [EACTR-2]). Note that EAC1 re- commends, and EAC2 requires prior execution of PACE. Security Target TCOS ID Version 2.0 Release 1/P6022y 6/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 6 Application Note 1: Due to existing migration periods both PACE and Basic Access Con- trol (BAC) according to [ICAO9303] must be supported by MRTD products. However, a product performing BAC is acting outside of the security policy defined by this ST. 7 In addition to the above user data, there is also data required for TOE security functionality (TSFs). Such data is necessary to execute the access control protocols, to verify integrity and authenticity of user data, or to generate cryptographic signatures. 8 Applications considered in [EACTR-1] and [EACTR-2] are • an electronic passport (ePass1) application, • an electronic identity (eID) application, and • a signature (eSign) application. 9 T-Systems International GmbH implemented all these applications in the TOE. They are subject of CC Evaluation. 10 The terminology used here follows [MREDPP, Table1], where an appropriate translation table of the identifiers used in different relevant Protection Profiles is given. 11 According to the Technical Guideline TR-03110 (cf. [EACTR-1, 2.1.1]) the ePass applica- tion supports Passive Authentication, Password Authenticated Connection Establishment (PACE) with CAN and MRZ as parts of the Standard and General Inspection Procedure, Terminal and Chip Authentication P.CS 2 and Version 3 as required in the General In- spection 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. 12 The ePass or eID Applications 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 Part 3, B.7]). 13 For the ePass Application, the electronic document holder can control the access to his user data by conscious presenting his document to authorities2 (CAN or MRZ authen- tication as specified in [EACTR-1, 3.3]). 14 For the eID Application, the electronic document holder can control the access to his user data by inputting his secret PIN or by conscious presenting his document to the authorities3. 15 For the eSign application, the electronic document holder can control the access to the digital signature functionality by conscious presenting his document to a Service Provider and using his secret Verification Authentication Data for this application: eSign-PIN4. 16 Application Note 2: 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 organizationally get different values of the respective secret PINs (PIN and eSign- PIN). It is especially important, since qualified electronic signatures will be generated by the eSign Application. For security reasons this policy will not be enforced by the TOE. 1 The notation of this application is different in the references; both ePass and ePassport are used. In this ST they are used synonymously, too. 2 CAN or MRZ user authentication, see [EACTR-1, sec. 2.3] 3 PIN or CAN user authentication, see [EACTR-1, sec. 2.3 and Part 2, sec. 2.3] 4 CAN and eSign-PIN (VAD as specified in [SSCDPP, sec. 3.2.3.5]).), user authentication, see [EACTR-2, sec. 2.3] Security Target TCOS ID Version 2.0 Release 1/P6022y 7/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 17 The cryptographic algorithms used by the TOE are defined outside the TOE in the Public Key Infrastructure( cf. [ALGO]). The security parameters of these algorithms must be se- lected by the electronic document issuer according to the Organizational Security Policies, e.g. P.Personalization [EAC1PP] or P.QSign [ALGO]. The TOE supports the standardized domain parameters mentioned in [RFC5639] (key length 256, 320, 384 and 512 bit), and the NIST P-256 curve mentioned in [EACTR-3, A.2.1.1] (with key length 256 bit) including the corresponding 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-3, A.2.3.1 and A.2.4.1]). This depends on the Initialization of the TOE. A more detailed description is given in the Ad- ministrator Guidance [TCOSGD]. 18 The electronic document is integrated into a plastic, optically and machine readable coun- ter-part of the electronic document. Note that this is not part of the TOE. 19 The hardware may be relevant in some context, and if so, the TOE will be identified in more detail as “TCOS ID Version 2.0 Release 1/P6022y”, otherwise the shorter notion “TCOS ID Version 2.0 Release 1” will be used, indicating that this context may be appli- cable to any realization regardless which hardware base is used. Note that the hardware base is identified as P60D145/081, which means that this ST applies to the derivates P60D081 and the P60D145, differing only in the memory size. 20 The TOE follows the composite evaluation aspects ([AIS36]). The Security Target of the underlying platform ([HWST]) claims conformance to Smartcard IC Platform Protection Profile ([ICPP]). 21 This composite ST is based on the ST of the underlying platform ([HWST]). The compati- bility of the Life Cycle Model of the Protection Profile [MREDPP] and the Life Cycle Model required by [ICPP] will be shown in chap. 1.3.4. 22 The TOE comprises of • the circuitry of the chip including all IC Dedicated Software being active in the Oper- ational Phase of the TOE (the integrated circuit, IC), • the IC Embedded Software (Card Operating System, COS) including configuration and initialization data related to the security functionality of the chip, • the selected Applications implemented in the file-system to be installed, and • the associated guidance documentation including description of the file system instal- lation procedure. 23 The components of the TOE are therefore the hardware (IC) and the operating system TCOS (OS) ready for initialization with a selected dedicated object system. The TOE De- sign Specification gives a detailed description of the parts of TOE. 24 The dedicated object systems (file systems) are specified in detail in the Admin Guidance. All they support all security functionality and mechanisms described within the ST. After initialization and during personalization, applications (data groups) required for the in- tended functionality and mechanisms and their access rights are created. Creation of the applications (i.e. the ISO7816-4 conforming file structure) including data groups and their access rights) is subject to a limited availability and limited capability policy defined in the family FMT_LIM. In particular, the loader ensures that creation or alteration of the file sys- tem is not possible after the manufacturing phase (this excludes populating data groups with values, as is done in the personalization phase). This is necessary for the manufac- turer to use a single IC for different configurations. 25 Application Note 3: Since parts of the contactless interface, e.g. the antenna, may have impact on specific aspects of vulnerability assessment and thus are security relevant, Security Target TCOS ID Version 2.0 Release 1/P6022y 8/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 these parts are considered as a part of the TOE. The decision upon this was made by the certification body in charge. Further details are considered in the ALC documentation. 26 The Guidance documentation ([TCOSGD]) provides further requirements for the manu- facturer and security measures required for protection of the TOE until reception by the end-user. 1.3.1 TOE security features for operational use 27 The TOE here has all security features of the TOE defined in [MREDPP]. In addition, it allows updating the TOE software during the life-cycle phase 4 “Operational Use” accord- ing to [MREDONPP]. 28 The following TOE security features are the most significant for its operational use. The TOE ensures that • only authenticated terminals can get access to the user data stored on the TOE and use security functionality of the electronic document according to the access rights of the terminal, • the electronic document holder can control access by consciously presenting his elec- tronic document and/or by entering his secret PIN, • authenticity and integrity of user data can be verified, • confidentiality of user data in the communication channel between the TOE and the connected terminal is provided, • inconspicuous tracing of the electronic document is averted, • its security functionality and the data stored inside are self-protected, and • digital signatures can be created. 29 For further details, refer to the chapter 6 “Security Requirements” and chapter 7 TOE Summary Specification. 1.3.2 TOE Type 30 The TOE’s type addressed by this ST is according to [MREDPP] a smart card programmed according to [EACTR]. With the eSign Application the TOE implements a Secure Signa- ture Creation Device according to Regulation (EU) No 910/2014 and the corresponding Implementing Decision [eIDAS]. 31 The TOE type definitions of the claimed PPs ([EAC1PP], [EAC2PP], [SSCDPP]) differ slightly. It is shown in the Protection Profile [MREDPP] that these differences do not violate consistency. It will not be repeated here. To avoid renaming in this ST all the notations of the different PPs are taken over here. 32 The typical life cycle phases for the current TOE type are development, manufacturing, card issuing and operational use. The life cycle phase development includes development of the IC itself and IC embedded software. Manufacturing includes IC manufacturing and smart card manufacturing, and installation of a card operating system. Card issuing in- cludes completion of the operating system, installation of the smart card applications and their electronic personalization, i.e. tying the application data up to the electronic docu- ment holder. 33 Operational use of the TOE is explicitly in the focus of the Protection Profile [MREDPP]. Nevertheless, some TOE functionality is already available in the manufacturing and the Security Target TCOS ID Version 2.0 Release 1/P6022y 9/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 card issuing life cycle phases. Therefore it is also considered by the Protection Profile [MREDPP] and this ST. 1.3.3 File System of the TOE 34 The TOE is configured with one of the dedicated file systems during life cycle phase 2 “Manufacturing”. Depending on the intended use, the file system of a desired configuration may not contain all applications listed in this ST. Although not all data groups will be pre- sent, all mechanisms, such as e.g., access controls and cryptographic operations de- scribed in the SFRs of this ST are implemented in these products too. The corresponding security requirements are fulfilled, as soon as the application is available. The available Major Configurations of the file system related to this ST are described in de- tail in other documents [TCOSGD]. They do not differ in security-relevant ways. For exam- ple, the product configured as Passport provides the same security functionality of an elec- tronic travel document as the product configured as Electronic Document. Though the latter can be used as a Qualified Signature Creation Device, this has no impact on the security functionality of a Passport, not providing this functionality. 35 The three Major Configurations of the TOE in this Security Target, which differ only in the description of the object system, are: • Passport: user data stored in an ICAO-compliant ([ICAO9303]) ePass Application protected by PACE and EAC1. Here, EAC1 is used only for data groups 3 and 4. • Residence Permit: user data stored in an ICAO-compliant ePass application pro- tected by PACE and EAC1/EAC2. Additional user data are stored in [EACTR-2] con- formant eID and [SSCDPP] conformant eSign Applications, and are protected by EAC2. • Electronic Document: user data contained in [EACTR-2]-conformant eID and eSign applications. An ePass application is included as well, but not compliant to [ICAO9303], since user data of all applications are protected by PACE/EAC2. Depending on the Configuration additionally the eSign Application can be already activated by a Certification Service Provider. The user data of the eSign Application are protected by PACE/EAC2. 1.3.4 Life Cycle Phases Mapping 36 Following the Protection Profile BSI-CC-0084 [ICPP, sec. 1.2.3] the life cycle phases of a smart card 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 37 According to the Protection Profile [MREDPP], the TOE life cycle is described in terms of the following four life cycle phases, divided in steps. Security Target TCOS ID Version 2.0 Release 1/P6022y 10/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 Life cycle phase 1 “Development” 38 Step 1: The TOE is developed in phase 1. The IC developer develops the integrated cir- cuit, the IC dedicated software and the guidance documentation associated with these TOE components. 39 Step 2: The software developer uses the guidance documentation for the integrated circuit and the guidance documentation for relevant parts of the IC dedicated software, and de- velops the IC embedded software (operating system), the electronic document applica- tion(s) and the guidance documentation associated with these TOE components. 40 The manufacturing documentation of the IC including the IC dedicated software and the embedded software in the non-volatile non-programmable memories is securely delivered to the IC manufacturer. The IC embedded software in the non-volatile programmable memories, the application(s), and the guidance documentation is securely delivered to the electronic document manufacturer. 41 This life cycle phase steps cover exactly phase 1 and phase 2 of [ICPP]. Life cycle phase 2 “Manufacturing” 42 Step 3: In a first step, the TOE integrated circuit is produced. The circuit contains the electronic document’s chip dedicated software, and the parts of the electronic document’s chip embedded software in the non-volatile non-programmable memory (ROM). The IC manufacturer writes IC identification data onto the chip in order to track and control the IC as dedicated electronic document material during IC manufacturing, and during delivery to the electronic document manufacturer. The IC is securely delivered from the IC manu- facturer to the electronic document manufacturer. If necessary, the IC manufacturer adds parts of the IC embedded software in the non-volatile programmable memory, e.g. EEPROM. 43 Step 4 (optional): The IC may be delivered as a module or a packaged component, com- bined with hardware for the contact based or contactless interface. 44 Step 5: The electronic document manufacturer • if necessary, adds the IC embedded software, or parts of it in the non-volatile pro- grammable memories, e. g. EEPROM or FLASH, • creates the application(s), and • equips the electronic document’s chip with pre-personalization data. 45 The first step, also named phase 5.1, is called Completion, and the one and only one user of the TOE in this stage is the Completion Agent acting as manufacturer. After Completion the Operating System cannot be changed anymore, the access protocols and the TSF are ready to use. There is only one command available (FORMAT), which allows the installa- tion of the object system of the desired configuration, and its access rules. 46 The other two steps, also known as phase 5.2, are called Installation, the one and only one user of the TOE in this stage is the Installation Agent. The keys and authentication data (the Format APDUs) for Installation are delivered securely to the Installation Agent. 47 After Installation, the electronic document is ready for import of user data (Personaliza- tion). Creation of the application(s) implies the creation of the master file (MF), dedicated files (DFs), and elementary files (EFs) according to [ISO7816]. 48 The pre-personalized electronic document together with the IC identifier is securely deliv- ered from the electronic document manufacturer to the Personalization Agent. The elec- Security Target TCOS ID Version 2.0 Release 1/P6022y 11/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 tronic document manufacturer also provides the relevant parts of the guidance documen- tation to the Personalization Agent. The authentication data for personalization is delivered securely to the Personalization Agent. 49 TOE delivery appears after IC life cycle phase 3 according to [ICPP] (IC Manufactur- ing). This corresponds to the end of step 5 of the TOE’s life cycle phase 2 according to [MREDPP]. The TOE is delivered as a chip with a completed Operating System and a ready to personalization object system. 50 This life cycle phase corresponds to the IC life cycle phases 3, 4, 5 and 6 of [ICPP], or more precisely, the Completion procedure (step 5.1) corresponds to IC life cycle phases 4 and 5 (Packaging and Composite Product Integration), whereas Installation is the IC personalization life cycle phase 6. 51 Application Note 4: The IC personalization phase should not be confused with the elec- tronic document personalization, which takes place only in the next life cycle phase of the TOE. 52 Some production steps, e.g. Step 4 may also take place after the TOE is finished, but before the TOE is delivered to the Personalization Agent, i.e. in step 5.2 of this phase. In this case TOE’s manufacturing is a usage of the TOE in a secure environment covered by the guidance documentation and is therefore subject of evaluation. 53 The security environment for the TOE and the ST of the underlying platform match, the IC life cycle phases up to 6 are covered by a controlled environment as required in [HWCR, p. 41]. In IC life cycle phase 7 no restrictions apply. Life cycle phase 3 “Personalization of the Electronic Document” 54 Step 6: The personalization of the electronic document includes 1. the survey of the electronic document holder’s biographical data, 2. the enrollment of the electronic document holder’s biometric reference data, such as a digitized portrait or other biometric reference data, 3. printing the visual readable data onto the physical part of the electronic document, and 4. configuration of the TSF, if necessary. 55 Configuration of the TSF is performed by the Personalization Agent and includes, but is not limited to, the creation of the digitized version of the textual, printed data, the digitized version of e.g. a portrait, or a cryptographic signature of a cryptographic hash of the data that are stored on the chip. The personalized electronic document, if required together with appropriate guidance for TOE use, is handed over to the electronic document holder for operational use. 56 Application Note 5: TSF data are data for the operation of the TOE upon which the en- forcement of the SFRs relies [CC]. Here TSF data include, but are not limited to, the per- sonalization agent’s key and authentication data. 57 From a hardware point of view, this cycle phase is already an operational use of the com- posite product and not a personalization of the hardware. The hardware’s “Personaliza- tion” (cf. [HWST]) ends with the Installation of the TOE (installation of the object system). 58 The Personalization with User Data, e.g. cardholder identification data, may be separated from the personalization of the TOE as Qualified Signature Creation Device, e.g. the gen- eration of a signature key. 59 The Personalization as a personalized SSCD includes the SVD certification for the in- tended user according to [eIDAS] and the delivery to the legitimate user. Security Target TCOS ID Version 2.0 Release 1/P6022y 12/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 This life cycle phase corresponds to the first step of Phase 7 of [ICPP]. Life cycle phase 4 “Operational Use” 60 Step 7: The chip of the TOE is used by the electronic document and terminals that Verify the chip’s data during the phase operational use. The user data can be read and modified according to the security policy of the issuer. 1.3.5 Non-TOE hardware/software/firmware 61 In order to be powered up and to communicate with the ‘external world’ the TOE needs a terminal (card reader) with contacts according to [ISO7816] or supporting the contactless communication according to [ISO14443]. 62 According to [EACTR] the TOE is able to recognize the following terminal types: • PACE terminal: A PACE terminal is a basic inspection system. It performs the standard inspection procedure, i.e. PACE followed by Passive Authentication. Afterwards user data are read by the terminal. A PACE terminal is allowed to read only common user data. EAC1 terminal (if the TOE contains an ICAO-conformant ePass application): An EAC1 terminal is an extended inspection system according to [EACTR-1]. It performs the advanced inspection procedure ([EACTR-1]) using EAC1, i.e. PACE, then Chip Authentication 1 followed by Passive Authentication, and finally Terminal Authentication 1. Afterwards user data are read by the terminal. An EAC1 terminal is allowed to read both EAC1 protected data, and common user data. • EAC2 terminal (if the TOE contains an eID application). An EAC2 terminal is an ex- tended inspection system performing the general authentication procedure according to [EACTR-2] using EAC2, i.e. PACE, then Terminal Authentication 2 followed by Passive Authentication, and finally Chip Authentication 2. Depending on its authori- zation level, an EAC2 terminal is allowed to read out some or all EAC2 protected sensitive user data, and common user data. 63 In general, the authorization level of a terminal is determined by the effective terminal authorization. The authorization is calculated from the certificate chain presented by the terminal to the TOE. It is based on the Certificate Holder Authorization Template (CHAT). A CHAT is calculated as an AND-operation from the certificate chain of the terminal and the electronic document presenter’s restricting input at the terminal. The final CHAT re- flects the effective authorization level and is then sent to the TOE [EACTR-3]. For the access rights, cf. also the SFR component FDP_ACF.1/TRM in chap. 6.1.5 (para 443). 64 All necessary certificates of the related public key infrastructure – Country Verifying Certi- fication Authority (CVCA) Link Certificates, Document Verifiers Certificates and Terminal Certificates – must be available in the card verifiable format defined in [EACTR-3]. 65 The term terminal within this ST usually refers to any kind of terminal, if not explicitly men- tioned otherwise. Which of the above terminals are related to what application and which data group is accessible by these terminals was given already in chapter 1.3.3. 66 Others than above listed terminals are out of scope of this ST. In particular, terminals using Basic Access Control (BAC) may be functionally supported by the electronic document, but the TOE is not in a certified mode as long as it is operated with BAC. 67 There is no explicit non-TOE hardware, software or firmware required by the TOE to per- form its claimed security features. Security Target TCOS ID Version 2.0 Release 1/P6022y 13/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 1.3.6 TOE Boundaries 1.3.6.1 TOE Physical Boundaries 68 Smart card as used in this ST means an integrated circuit containing a microprocessor, (CPU), a coprocessor for special (cryptographic) operations, a random number generator, volatile and non-volatile memory, and associated software, packaged and embedded in a carrier. The integrated circuit is a single chip incorporating CPU and memory, which in- clude RAM, ROM, and EEPROM. 69 The chip is embedded in a module, which provides the capability for standardized con- nection to systems separate from the chip through TOE’s interfaces in accordance with ISO standards. 70 The physical constituent of the TOE is the initialized chip with an operating system in ROM and EEPROM and an installed object system in a dedicated configuration. 71 After the Installation of the object system, the TOE can be personalized for the end-usage phase for the document holder as an electronic document. 1.3.6.2 TOE Logical Boundaries 72 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. 73 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). The output octet string from the TOE has the structure of a Response Application Protocol Data Unit (RAPDU). 74 The Application Protocol Data Units or TCOS commands that can be used in the operating systems are described in more detail in another document. 1.3.7 Conformance to eIDAS 75 In [eIDAS] the European Parliament and the Council of the European Union has codified the conceptional requirements for qualified electronic signature devices used in the Euro- pean Union. In the supporting Implementing Decision is stated that an electronic signature device according to eIDAS must be certified using the standards [CC] and [SSCDPP]. As shown in this ST the TOE fulfills these standards and is therefore compliant to signature creation devices according to points (a) of Article 30(3) or 39(2) of the Regulation for qualified electronic signature or seal creation devices. Security Target TCOS ID Version 2.0 Release 1/P6022y 14/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 2 Conformance Claim 2.1 CC Conformance Claims 76 This Security Target claims conformance to Common Criteria for Information Technology Security Evaluation [CC], Part 1: Introduction and general model; CCMB-2017-04-001, Version 3.1, Revision 5, April 2017, Part 2: Security functional components; CCMB-2017-04-002, Version 3.1, Revision 5, April 2017, Part 3: Security assurance components; CCMB-2017-04-003, Version 3.1, Revision 5, April 2017 as follows: Part 2 extended, Part 3 conformant. The Common Methodology for Information Technology Security Evaluation, Evaluation methodology; CCMB-2012-09-004, Version 3.1, Revision 5, April 2017, [CC] has to be taken into account. 2.2 PP Claims 77 This ST claims strict conformance to • base Common Criteria Protection Profile 'Machine-Readable Electronic Documents based on BSI TR-03110 for Official Use', BSI-CC-PP-0087-V2-MA-01, [MREDPP], and • its Common Criteria Protection Profile Module ‘Machine Readable Electronic Docu- ments - Optionales Nachladen (Optional Post-Emission Updates)’, BSI-CC-PP-0090- 2016, [MREDONPP]. 78 This implies that this ST claims also strict conformance to • Common Criteria Protection Profile ‘Machine Readable Travel Document with “ICAO Application”, Extended Access Control with PACE (EAC PP)’, BSI-CC-PP-0056-V2- 2012-MA-02, [EAC1PP] • Common Criteria Protection Profile ‘Electronic document implementing Extended Ac- cess Control Version 2 (EAC2) based on BSI TR-03110 (EAC2_PP)’, BSI-CC-PP- 0086, [EAC2PP] 79 Since these PPs claim strict conformance to [PACEPP], this ST implicitly also claims strict conformance to • Common Criteria Protection Profile ‘Machine Readable Travel Document using Standard Inspection Procedure with PACE’, BSI-CC-PP-0068-V2-2011-MA-01, [PACEPP]. 80 However, since [EAC1PP] and [EAC2PP] already claim strict conformance to [PACEPP], this implicit conformance claim is formally mostly ignored within this ST for the sake of presentation; but if necessary to yield a better overview however, references to this Pro- tection Profile are given or the relation with this PP is explained. Security Target TCOS ID Version 2.0 Release 1/P6022y 15/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 81 This ST claims also strict conformance to • Common Criteria Protection Profile for Secure Signature Creation Device – Part 2: Device with key generation, EN 419211-2:2013, BSI-CC-PP-0059-2009-MA-02 ([SSCDPP]) 82 Application Note 6: The conformance claim to SSCDPP 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], this ST specifies authentication and communication protocol (PACE) that have to be used for the eSign application of the TOE over the contact-less interface. This con- tributes to secure Signature Verification Data (SVD) export, Data To Be Signed (DTBS) import, and Verification Authentication Data (VAD) import functionality. 2.3 Package Claims 83 The evaluation of the TOE is a composite evaluation and uses the results of the CC eval- uation provided by [HWCR]. The IC hardware platform and its primary embedded software are evaluated at level EAL 6+. 84 The evaluation assurance level of the TOE is EAL4 augmented with ALC_DVS.2, ATE_\ DPT.25 and AVA_VAN.5 as defined in [CC]. 2.4 Conformance Claim Rationale 85 The TOE type is a chip consistent with the TOE type of the claimed PP ([MREDPP]). 86 The PP [MREDPP] conforms to the PPs [EAC1PP], [EAC2PP] and [SSCDPP].This implies for this ST: 1. The TOE type of this ST is the same as the TOE type of the claimed PPs: The Target of Evaluation (TOE) is an electronic document implemented as a smart card pro- grammed according to [EACTR], and additionally representing for the eSign applica- tion a combination of hardware and software configured to securely create, use and manage signature-creation data. 2. The security problem definition (SPD) of this ST contains the SPD of the claimed PPs. The SPD contains all threats, organizational security policies and assumptions of the claimed PPs. 3. The security objectives for the TOE in this ST include all the security objectives for the TOE of the claimed PPs. 4. The security objectives for the operational environment in this ST include all security objectives for the operational environment of the claimed PPs. 5. The SFRs specified in this ST include all security functional requirements (SFRs) specified in the claimed PPs. There are three refined SFRs within this ST: • The SFR FIA_UAU.1/SSCDPP is redefined from [SSCDPP] by additional assign- ments, this does not violate strict conformance to [SSCDPP]. • Multiple iterations of FDP_ACF.1 and FMT_SMR.1 exist from imported PPs to define the access control SFPs and security roles for (common) user data, EAC1- 5 In this ST the backslash provides a line break for CC conformant identifiers. It should not be considered as part of the iden- tifier. Identifiers containing natural words are hyphenated as usual. Security Target TCOS ID Version 2.0 Release 1/P6022y 16/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 protected user data, and EAC2-protected user data. These access control SFPs and security roles are unified to FDP_ACF.1/TRM and FMT_SMR.1 6. The SARs specified in this ST are the same as specified in the claimed PPs or extend them. Security Target TCOS ID Version 2.0 Release 1/P6022y 17/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 3 Security Problem Definition 3.1 Assets and External Entities 87 The primary assets are User Data to be protected by the COS as long as they are in scope of the TOE and the security services provided by the TOE (please refer to the Glossary for a definition of terms used, but not defined here). Asset Definition Authenticity of the Elec- tronic Document’s Chip The authenticity of the electronic document’s chip personalized by the issuing state or organ- ization for the electronic document holder, is used by the electronic document presenter to prove his possession of a genuine electronic document. Generic Security Property: Authenticity This asset is equal to the one(s) of [EAC1PP] and [EAC2PP], which itself stem from [PACEPP]. Electronic Document Tracing Data Technical information about the current and previous locations of the electronic document gathered unnoticeable by the electronic document holder recognizing the TOE not knowing any PACE password. TOE tracing data can be provided / gathered. Generic Security Property: Unavailability This asset is equal to the one(s) of [EAC1PP] and [EAC2PP], which itself stem from [PACEPP]. Note that unavailability here is required for anonymity of the electronic document holder. Sensitive User Data User data, which have been classified as sensitive data by the electronic document issuer, e. g. sensitive biometric data. Sensitive user data are a subset of all user data, and are pro- tected by EAC1, EAC2, or both. Generic Security Properties: Confidentiality, Integrity, Authenticity User Data stored on the TOE All data, with the exception of authentication data, that are stored in the context of the appli- cation(s) on the electronic document. These data are allowed to be read out, used or modi- fied either by a PACE terminal, or, in the case of sensitive data, by an EAC1 terminal or an EAC2 terminal with appropriate authorization level. Generic Security Properties: Confidentiality, Integrity, Authenticity This asset is included from [EAC1PP], [EAC2PP] respectively. In these protection profiles it is an extension of the asset defined in [PACEPP]. This asset also includes ”SVD” (Integrity and Authenticity only), “SCD” of [SSCDPP]. User Data transferred between the TOE and the Terminal All data, with the exception of authentication data, that are transferred (both directions) dur- ing usage of the application(s) of the electronic document between the TOE and authenti- cated terminals. Generic Security Properties: Confidentiality, Integrity, Authenticity This asset is included from [EAC1PP], [EAC2PP] respectively. In these protection profiles it is an extension of the asset defined in [PACEPP]. As for confidentiality, note that even though not each data element being transferred represents a secret, [EACTR-1], [EACTR-2] resp. require confidentiality of all transferred data by secure messaging in encrypt-then-au- thenticate mode. This asset also includes “DTBS” of [SSCDPP]. Table 1: Primary assets 88 In order to achieve a sufficient protection of the primary assets listed above, the following secondary assets are also protected by the TOE. The secondary assets represent TSF and TSF data in the sense of CC. Asset Definition Accessibility to the TOE Functions and Data only for Author- ized Subjects Property of the TOE to restrict access to TSF and TSF-Data stored in the TOE to authorized subjects only. Generic Security Property: Availability Genuineness of the TOE Property of the TOE to be authentic in order to provide claimed security functionality in a proper way. Generic Security Property: Availability Security Target TCOS ID Version 2.0 Release 1/P6022y 18/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 Asset Definition Electronic Document Communication Estab- lishment Authorization Data Restricted-revealable authorization information for a human user being used for verification of the authorization attempts as an authorized user (PACE password). These data are stored in the TOE, and are not send to it.Restricted-revealable here refers to the fact that if neces- sary, the electronic document holder may reveal her verification values of CAN and MRZ to an authorized person, or to a device that acts according to respective regulations and is con- sidered trustworthy. Generic Security Properties: Confidentiality, Integrity Secret Electronic Docu- ment Holder Authenti- cation Data Secret authentication information for the electronic document holder being used for verifica- tion of the authentication attempts as authorized electronic document holder (PACE pass- words). Generic Security Properties: Confidentiality, Integrity TOE internal Non-Se- cret Cryptographic Ma- terial Permanently or temporarily stored non-secret cryptographic (public) keys and other non-se- cret material used by the TOE in order to enforce its security functionality. Generic Security Properties: Integrity, Authenticity TOE internal Secret Cryptographic Keys Permanently or temporarily stored secret cryptographic material used by the TOE in order to enforce its security functionality. Generic Security Properties: Confidentiality, Integrity Secret Cryptographic Update Keys All cryptographic key material related to the update mechanism; i.e. cryptographic material that is used to establish a secure communication channel with the update terminal, to au- thenticate an update terminal, to decrypt and verify the authenticity of an update package, and for other update-related cryptographic operations. Generic Security Properties: Authenticity, Confidentiality, Integrity Meta-Data Data that contains information about the update, e.g. version information, checksums, infor- mation w.r.t. applicability to specific product versions and platforms, etc. All Meta-Data is encrypted, any information about the update is transmitted over a secure channel between the TOE and the Update Terminal. Generic Security Properties: Authenticity, Confidentiality, Integrity Update Data Unencrypted data that is used to update the TOE software, e.g. data to be used to authenti- cate an Update Terminal. Generic Security Properties: Authenticity, Integrity Update Log Data Log records that store information about previously applied updates and failed update at- tempts. Generic Security Properties: Authenticity, Integrity Update Package Encrypted update data, appended with optional unencrypted meta-data, and signed. Generic Security Properties: Authenticity, Confidentiality, Integrity Update Package Verifi- cation Status Security attribute indicating whether the supplied update was successfully verified (and where hence its authenticity and integrity can be assumed) or not, and whether an attempt to verify was made or not. Allowed values are NOT VERIFIED, SUCCESSFULLY VERIFIED and VERIFICATION FAILED. Generic Security Properties: Authenticity, Integrity Version Information Version information that uniquely identify the version of the TOE software currently installed on the TOE. Generic Security Properties: Confidentiality, Integrity Table 2: Secondary assets 89 The protection profile [MREDPP] considers the following external entities and subjects: External entity Definition Attacker A threat agent (a person or a process acting on his behalf) trying to undermine the security policy defined by the current PP, especially to change properties of the assets that have to be maintained. The attacker is assumed to possess at most high attack potential. Note that the attacker might capture any subject role recognized by the TOE. Country Signing Certifi- cation Authority (CSCA) An organization enforcing the policy of the electronic document issuer, i. e. confirming cor- rectness of user and TSF data that are stored within the electronic document. The CSCA represents the country specific root of the public key infrastructure (PKI) for the electronic document, and creates Document Signer Certificates within this PKI. The CSCA also issues Security Target TCOS ID Version 2.0 Release 1/P6022y 19/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 External entity Definition a self-signed CSCA certificate that has to be distributed to other countries by secure diplo- matic means, see [ICAO9303]. Country Verifying Certi- fication Authority (CVCA) The Country Verifying Certification Authority (CVCA) enforces the privacy policy of the issu- ing state or organization, i. e. enforcing protection of sensitive user data that are stored in the electronic document. The CVCA represents the country specific root of the PKI of EAC1 ter- minals, EAC2 terminals respectively, and creates Document Verifier Certificates within this PKI. Updates of the public key of the CVCA are distributed as CVCA Link-Certificates. Document Signer (DS) An organization enforcing the policy of the CSCA. A DS signs the Document Security Object that is stored on the electronic document for Passive Authentication. A Document Signer is authorized by the national CSCA that issues Document Signer Certificate , see [ICAO9303]. Note that this role is usually delegated to a Personalization Agent. Document Verifier (DV) An organization issuing terminal certificates as a Certificate Authority, authorized by the cor- responding CVCA to issue certificates for EAC1 terminals, EAC2 terminals respectively, see [EACTR-3]. Electronic Document Holder A person the electronic document issuer has personalized the electronic document for. Per- sonalization here refers to associating a person uniquely with a specific electronic electronic document. This subject includes “Signatory” as defined [SSCDPP]. Electronic Document Presenter A person presenting the electronic document to a terminal and claiming the identity of the electronic document holder. Note that an electronic document presenter can also be an at- tacker. Moreover, this subject includes “user” as defined in [SSCDPP]. Manufacturer Generic term comprising both the IC manufacturer that produces the integrated circuit, and the electronic document manufacturer that creates the electronic document and attaches the IC to it. The manufacturer is the default user of the TOE during the manufacturing life cycle phase. When referring to the role manufacturer, the TOE itself does not distinguish between the IC manufacturer and the electronic document manufacturer. The manufacturer may act as Completion and Installation Agent. PACE Terminal A technical system verifying correspondence between the password stored in the electronic document and the related value presented to the terminal by the electronic document pre- senter. A PACE terminal implements the terminal part of the PACE protocol and authenti- cates itself to the electronic document using a shared password (CAN, PIN, PUK or MRZ). A PACE terminal is not allowed reading sensitive user data. Personalization Agent vAn organization acting on behalf of the electronic document issuer that personalizes the electronic document for the electronic document holder. Personalization includes some or all of the following activities: (i) establishing the identity of the electronic document holder for the biographic data in the electronic document, (ii) enrolling the biometric reference data of the electronic document holder, (iii) writing a subset of these data on the physical electronic doc- ument (optical personalization) and storing them within the electronic document’s chip (elec- tronic personalization), (iv) writing document meta data (i. e. document type, issuing country, expiry date, etc.) (v) writing the initial TSF data, and (vi) signing the Document Security Ob- ject, and the elementary files EF.CardSecurity and the EF.ChipSecurity (if applicable [ICAO9303], [EACTR-3]) in the role DS. Note that the role personalization agent may be dis- tributed among several institutions according to the operational policy of the electronic docu- ment issuer. This subject includes “Administrator” as defined in [SSCDPP]. EAC1 Terminal / EAC2 Terminal A terminal that has successfully passed the Terminal Authentication protocol (TA) version 1 is an EAC1 terminal, while an EAC2 terminal needs to have successfully passed TA version 2. Both are authorized by the electronic document issuer through the Document Verifier of the receiving branch (by issuing terminal certificates) to access a subset or all of the data stored on the electronic document. Terminal A terminal is any technical system communicating with the TOE through the contactless or contact-based interface. The role terminal is the default role for any terminal being recog- nized by the TOE as neither being authenticated as a PACE terminal nor an EAC1 terminal nor an EAC2 terminal. Table 3: External Entities6 6 This table defines external entities and subjects in the sense of [CC]. Subjects can be recognized by the TOE independent of their nature (human or technical user). As result of an appropriate identification and authentication process, the TOE cre- ates – for each of the respective external entity – an ‘image’ inside and ‘works’ then with this TOE internal image (also called subject in [CC]). From this point of view, the TOE itself perceives only ‘subjects’ and, for them, does not differ bet- ween ‘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 recognized by the TOE. Security Target TCOS ID Version 2.0 Release 1/P6022y 20/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 3.2 Threats 90 This section describes the threats to be averted by the TOE independently or in collabo- ration with its IT environment. These threats result from the assets stored in or protected by the TOE and the method of TOE’s use in the operational environment. 91 The threats, which are defined in the Protection Profile [ICPP] are already covered by claimed Protection Profiles and are therefore not considered in this ST. 92 The following threats are specified in the Protection Profile [MREDPP]. T.InconsistentSec Inconsistency of security measures 93 An attacker gains read or write access to user data or TOE data without being allowed to, due to an ambiguous/unintended configuration of the TOE’s internal access conditions of user or TSF data. This may lead to a forged electronic document or misuse of user data. 94 Threat agent has high attack potential, and may be in possession of one or more legitimate electronic documents. Asset: authenticity, integrity and confidentiality of user data stored on the TOE T.Interfere Interference of security protocols 95 An attacker uses an unintended interference of implemented security protocols to gain access to user data. 96 Threat agent has high attack potential, and may be in possession of one or more legitimate electronic documents. 97 Asset: authenticity, integrity and confidentiality of user data stored on the TOE T.AdvancedTracing Advanced Tracing and Group Key Compromise 98 The attacker compromises a group key or is able to trace and identify the electronic doc- ument holder by key material that is used to guarantee the authenticity of the document. Tracing is often (e.g. in the case of Chip Authentication 2) avoided by using one key for a group of electronic documents. If the group is large enough, individual tracing is no longer possible. If an attacker compromises such a group key however, authenticity of all of the electronic documents within the group can be guaranteed. On the other hand, if chip indi- vidual keys are used to ensure the authenticity of the document, only a single document is affected by a key compromise. However then, the (public) chip-individual keys can be misused for tracing the document and its holder. 99 Threat agent: having high attack potential, being in the possession of one or more legiti- mate electronic documents 100 Asset: authenticity, integrity, and confidentiality of user data stored on the TOE Security Target TCOS ID Version 2.0 Release 1/P6022y 21/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 101 The following threats are specified in the Protection Profile Module [MREDONPP]. T.FaTSF Faulty TSF 102 Adverse action: An attacker gains read or write access to user data or TSF data, or ma- nipulates or mitigates the TSF, for example due to: • software issues that were not detected, not exploitable, or deemed unable to being exploitable at the time of certification, but due to unforeseen advances in technology became a security risk during operational use of the TOE, or • cryptographic mechanisms that were deemed secure at the time of certification, but due to unforeseen advances in the field of cryptography became a security risk during operational use of the TOE. 103 Threat agent: having high attack potential, being in possession of one or more legitimate electronic documents 104 Asset: all data stored on the TOE (esp. the integrity, authenticity and – if applicable – secrecy of the data) T.UaU Unauthorized Update 105 Adverse action: An attacker gains read or write access to user data or TSF data, or ma- nipulates or mitigates the TSF by misuse of the update functionality. This threat contains two main aspects: • the unauthorized installation, which may lead to the use of untimely, outdated or re- voked updates, • the installation of updates that are not authorized and authentic. 106 Threat agent: having high attack potential, being in possession of one or more legitimate electronic documents 107 Asset: all data stored on the TOE (esp. the integrity, authenticity and – if applicable – secrecy of the data) 108 The following threats are included from [EAC1PP]. They concern EAC1-protected data. T.Counterfeit Counterfeit of travel document chip data 109 An attacker with high attack potential produces an unauthorized copy or reproduction of a genuine travel document’s chip to be used as part of a counterfeit travel document. This violates the authenticity of the travel document’s chip used for authentication of a traveller by possession of a travel document. 110 The attacker may generate a new data set or extract completely or partially the data from a genuine travel document’s chip and copy them to another appropriate chip to imitate this genuine travel document’s chip. 111 Threat agent: having high attack potential, being in possession of one or more legitimate travel documents 112 Asset: authenticity of user data stored on the TOE Security Target TCOS ID Version 2.0 Release 1/P6022y 22/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 T.Read_Sensitive_Data DataRead the sensitive biometric reference data 113 Adverse action: An attacker tries to gain the sensitive biometric reference data through the communication interface of the travel document’s chip. 114 The attack T.Read_Sensitive_Data is similar to the threat T.Skimming (cf. [8]) in respect of the attack path (communication interface) and the motivation (to get data stored on the travel document’s chip) but differs from those in the asset under the attack (sensitive bio- metric reference data vs. digital MRZ, digitized portrait and other data), the opportunity (i.e. knowing the PACE Password) and therefore the possible attack methods. Note, that the sensitive biometric reference data are stored only on the travel document’s chip as private sensitive personal data whereas the MRZ data and the portrait are visually reada- ble on the physical part of the travel document as well. 115 Threat agent: having high attack potential, knowing the PACE Password, being in posses- sion of a legitimate travel document 116 Asset: confidentiality of logical travel document sensitive user data (i.e. biometric refer- ence) 117 The following threats are included from [EAC2PP]. They concern EAC2-protected data. T.Counterfeit/EAC2 Counterfeit of electronic document chip data 118 Adverse action: An attacker with high attack potential produces an unauthorized copy or reproduction of a chip of a genuine electronic document. This copy or reproduction can be used as a part of a counterfeit electronic document. This violates the authenticity of the electronic document's chip used for authentication of a electronic document presenter by possession of an electronic document. The attacker may generate a new data set or ex- tract completely or partially the data from a genuine electronic document’s chip and copy them to another appropriate chip to imitate the chip of the genuine electronic document. 119 Threat agent: having high attack potential, being in possession of one or more legitimate ID-Cards. 120 Asset: authenticity of user data stored on the TOE T.Sensitive_Data Unauthorized access to sensitive user data 121 Adverse action: An attacker tries to gain access to sensitive user data through the com- munication interface of the electronic document’s chip. The attack T.Sensitive_Data is similar to the threat T.Skimming from [PACEPP] w.r.t. the attack path (communication interface) and the motivation (to get data stored on the electronic document’s chip) but differs from those in the asset under the attack (sensitive data vs. digital MRZ, digitized portrait and other data), the opportunity (i.e. knowing the PACE Password) and therefore the possible attack methods. 122 Threat agent: having high attack potential, knowing the PACE Password, being in posses- sion of a legitimate electronic document 123 Asset: confidentiality of sensitive user data stored on the electronic document Security Target TCOS ID Version 2.0 Release 1/P6022y 23/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 124 The following threats are included from [PACEPP]. Both [EAC1PP] and [EAC2PP] claim [PACEPP], and thus include the threats formulated in [PACEPP]. We list each threat only once here. T.Abuse-Func Abuse of Functionality 125 An attacker may use functions of the TOE which shall not be used in TOE operational phase in order (i) to manipulate or to disclosure the User Data stored in the TOE, (ii) to manipulate or to disclose the TSF-data stored in the TOE or (iii) to manipulate (bypass, deactivate or modify) soft-coded security functionality of the TOE. This threat addresses the misuse of the functions for the initialization and personalization in the operational phase after delivery to the Passport holder. 126 Application Note 7: 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.Eavesdropping Eavesdropping on the communication between the TOE and the PACE terminal 127 An attacker is listening to the communication between the Travel document and the PACE terminal (PCT) in order to gain the user data transferred between the TOE and the service provider (inspecting authority) connected. 128 Application Note 8: A product using BIS-BAC cannot avert this threat in the context of the security policy defined in this PP. When using EIS-AIP-BAC, this threat might be averted only with respect to a selected data groups (DG3, DG4) within the ePass application, but it is out of the scope of the current PP; see also the Application Note 2 above. T.Forgery Forgery of Data 129 An attacker fraudulently alters the User Data or/and TSF-data stored on the ePass or/and exchanged between the TOE and the service provider (inspecting authority) connected in order to outsmart the authenticated terminal (PCT) by means of changed ePass holder’s related reference data (like biographic or biometric data). The attacker does it in such a way that the service provider (represented by the terminal connected) perceives these modified data as authentic one. T.Information_Leakage Information Leakage from travel document 130 An attacker may exploit information leaking from the TOE during its usage in order to disclose confidential User Data or/and TSF-data. The information leakage may be inherent in the normal operation or caused by the attacker. 131 Application Note 9: Leakage may occur through emanations, variations in power con- sumption, I/O characteristics, clock frequency, or by changes in processing time require- ments. This leakage may be interpreted as a covert channel transmission, but is more closely related to measurement of operating parameters which may be derived either from measurements of the contactless interface (emanation) or direct measurements (by con- tact to the chip still available even for a contactless chip) and can then be related to the specific operation being performed. Examples are Differential Electromagnetic Analysis (DEMA) and Differential Power Analysis (DPA). Moreover, the attacker may try actively to enforce information leakage by fault injection (e.g. Differential Fault Analysis). Security Target TCOS ID Version 2.0 Release 1/P6022y 24/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 T.Malfunction Malfunction due to Environmental Stress 132 An attacker may cause a malfunction the ePass’es hardware and Embedded Software by applying environmental stress in order to (i) deactivate or modify security features or func- tionality of the TOE’s 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 ePass outside the normal operating conditions, exploiting errors in the ePass’es Embedded Soft- ware or misusing administrative functions. To exploit these vulnerabilities an attacker needs information about the functional operation. 133 Application Note 10: A malfunction of the TOE may also be caused using a direct interac- tion 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 TOE’s internals. T.Phys-Tamper Physical Tampering 134 An attacker may perform physical probing of the ePass in order (i) to disclose the TSF- data, or (ii) to disclose/reconstruct the TOE’s Embedded Software. An attacker may phys- ically modify the ePass in order to alter (i) its security functionality (hardware and software part, as well), (ii) the User Data or the TSF-data stored on the ePass. 135 Application Note 11: Physical tampering may be focused directly on the disclosure or ma- nipulation of the user data (e.g. the biometric reference data for the inspection system) or the TSF data (e.g. authentication key of the ePass) or indirectly by preparation of the TOE to following attack methods by modification of security features (e.g. to enable information leakage through power analysis). Physical tampering requires a direct interaction with the ePass’s internals. Techniques commonly employed in IC failure analysis and IC reverse engineering efforts may be used. Before that, hardware security mechanisms and layout characteristics need to be identified. Determination of software design including treatment of the user data and the TSF data may also be a pre-requisite. The modification may result in the deactivation of a security function. Changes of circuitry or data can be permanent or temporary. T.Skimming Skimming ePass / Capturing Card-Terminal Commu- nication 136 An attacker imitates an inspection system in order to get access to the user data stored on or transferred between the TOE and the service provider (inspecting authority) con- nected via the contactless interface of the TOE. The attacker cannot read and does not know the correct value of the shared password (CAN, MRZ) in advance. 137 Application Note 12: A product using BIS-BAC cannot avert this threat in the context of the security policy defined in this PP. When using EIS-AIP-BAC, this threat might be averted only with respect to a selected data groups (DG3, DG4) within the ePass applica- tion, but it is out of the scope of the corresponding PP. 138 This table defines external entities and subjects in the sense of [CC]. Subjects can be recognized 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 entity – 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 recog- nized by the TOE. 139 Application Note 13: This threat also covers the item T.Read_Sensitive_Data in the ICAO- EAC PP [ICAO9303]: sensitive biometric reference data stored on the travel document Security Target TCOS ID Version 2.0 Release 1/P6022y 25/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 are part of the asset user data stored on the TOE. Knowledge of the Document Basic Access Keys is here not applicable, because the TOE does not cover the BAC protocol and, therefore, the Document Basic Access Keys are not existent for the TOE. 140 Application Note 14: MRZ is printed and CAN is printed or stuck on the Travel document. Please note that neither CAN nor MRZ effectively represent secrets, but are restricted- revealable, cf. OE.Card-Holder. T.Tracing Tracing travel document 141 An attacker tries to gather TOE tracing data (i.e. to trace the movement of the travel doc- ument) unambiguously identifying it remotely by establishing or listening to a communica- tion via the contactless interface of the TOE. The attacker cannot read and does not know the correct values of shared passwords (CAN, MRZ) in advance. 142 Application Note 15: 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 this PP, see also the Application Note 2 above. 143 Application Note 16: Since the Standard Inspection Procedure does not support any unique-secret-based authentication of the travel document’s chip (no Chip Authentication), a threat like T.Counterfeit (counterfeiting travel document) cannot be averted by the cur- rent TOE. 144 The following threats are included from [SSCDPP]. These items are applicable if the eSign application is operational. T.DTBS_Forgery Forgery of the DTBS/R 145 An attacker modifies the DTBS/R sent by the SCA. Thus, the DTBS/R used by the TOE for signing does not match the DTBS the signatory intended to sign. T.Hack_Phys Physical attacks through the TOE interfaces 146 An attacker interacts physically with the TOE to exploit vulnerabilities, resulting in arbitrary security compromises. This threat is directed against SCD, SVD and DTBS. T.SCD_Derive Derive the signature-creation data 147 An attacker derives the SCD from publicly known data, such as SVD corresponding to the SCD or signatures created by means of the SCD or any other data exported outside the TOE, which is a threat against the secrecy of the SCD. T.SCD_Divulg Storing, copying, and releasing of the signature- creation data 148 An attacker stores or copies the SCD outside the TOE. An attacker can obtain the SCD during generation, storage and use for signature-creation in the TOE. T.Sig_Forgery Forgery of the digital signature 149 Without use of the SCD an attacker forges data with associated digital signature and the verification of the digital signature by the SVD does not detect the forgery. The signature generated by the TOE is subject to deliberate attacks by experts possessing a high attack potential with advanced knowledge of security principles and concepts employed by the TOE. Security Target TCOS ID Version 2.0 Release 1/P6022y 26/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 T.SigF_Misuse Misuse of the signature-creation function of the TOE 150 An attacker misuses the signature-creation function of the TOE to create a digital signature for data the signatory has not decided to sign. The TOE is subject to deliberate attacks by experts possessing a high attack potential with advanced knowledge of security principles and concepts employed by the TOE. T.SVD_Forgery Forgery of the signature-verification data 151 An attacker presents a forged SVD to the CGA. This results in loss of SVD integrity in the certificate of the signatory. 3.3 Organizational Security Policies 152 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 or- ganization upon its operations (see CC part 1, sec. 3.2). This ST includes the OSPs from the claimed protection profiles as listed below and provides no further OSPs. 153 The following OSP is defined in [MREDPP] akin to the Protection Profile [ICPP]. It ad- dresses the need of a policy for the document manufacturer. Please refer to [ICPP] for further descriptions and the details. P.Lim_Block_Loader 154 The composite manufacturer uses the Loader for loading of Security IC Embedded Soft- ware, user data of the Composite Product or IC Dedicated Support Software in charge of the IC Manufacturer. She limits the capability and blocks the availability of the Loader in order to protect stored data from disclosure and manipulation. 155 The following OSPs are defined in the EAC1 PP [EAC1PP]: P.Personalization Personalization of the travel document by issuing State or Organization only 156 The issuing State or Organization guarantees the correctness of the biographical data, the printed portrait and the digitized portrait, the biometric reference data and other data of the logical travel document with respect to the travel document holder. The personalization of the travel document for the holder is performed by an agent authorized by the issuing State or Organization only. P.Sensitive_Data Privacy of sensitive biometric reference data 157 The biometric reference data of finger(s) (EF.DG3) and iris image(s) (EF.DG4) are sensi- tive private personal data of the travel document holder. The sensitive biometric reference data can be used only by inspection systems, which are authorized for this access at the time the travel document is presented to the inspection system (Extended Inspection Sys- tems). The issuing State or Organization authorizes the Document Verifiers of the receiv- ing States to manage the authorization of inspection systems within the limits defined by the Document Verifier Certificate. The travel document’s chip shall protect the confidenti- ality and integrity of the sensitive private personal data even during transmission to the Extended Inspection System after Chip Authentication Version 1. Security Target TCOS ID Version 2.0 Release 1/P6022y 27/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 158 The following OSPs are defined in the EAC2 PP [EAC2PP]: P.EAC2_Terminal Abilities of Terminals executing EAC Version 2 159 Terminals that intent to be EAC2 terminals must implement the respective terminal part of the protocols required to execute EAC version 2 according to [TR03110-2], and store (static keys) or generate (temporary keys and nonces) the corresponding credentials. P.RestrictedIdentity Restricted Identity and Sector’s Static Key Pairs 160 If the TOE supports the Restricted Identity protocol, the electronic document issuer shall ensure that the Restricted Identity key pair is generated securely and the private keys are stored securely in the electronic document as defined in [EACTR-2]. P.Terminal_PKI PKI for Terminal Authentication 161 The electronic document issuer shall establish a public key infrastructure for the card ver- ifiable certificates used for Terminal Authentication. For this aim, the electronic document issuer shall run a Country Verifying Certification Authority. The instances of the PKI shall fulfill the requirements and rules of the corresponding certificate policy. The electronic document issuer shall make the CVCA certificate available to the personalization agent or the manufacturer. 162 The following OSPs are defined in the PACE PP [PACEPP], since both [EAC1PP] and [EAC2PP] claim [PACEPP]. We list each OSP only once here. P.Card_PKI PKI for Passive Authentication (issuing branch) 163 Application Note 17: The description below states the responsibilities of involved parties and represents the logical, but not the physical structure of the PKI. Physical distribution ways shall be implemented by the involved parties in such a way that all certificates be- longing to the PKI are securely distributed / made available to their final destination, e.g. by using directory services. 164 1. The travel document Issuer shall establish a public key infrastructure for the passive authentication, i.e. for digital signature creation and verification for the travel document. For this aim, he runs a Country Signing Certification Authority (CSCA). The travel doc- ument Issuer shall make the CSCA Certificate (CCSCA) and the Document Signer Cer- tificates (CDS) available to the CVCAs under agreement (who shall finally distribute them to their terminals). 165 2. The CSCA shall securely generate, store and use the CSCA key pair. The CSCA shall keep the CSCA Private Key secret and issue a self-signed CSCA Certificate (CCSCA) having to be made available to the travel document Issuer by strictly secure means. The CSCA shall create the Document Signer Certificates for the Document Signer Pub- lic Keys (CDS) and make them available to the travel document Issuer. 166 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 and (iv) securely use the Document Signer Security Target TCOS ID Version 2.0 Release 1/P6022y 28/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 P.Manufact Manufacturing of the travel document’s chip 167 The Initialization Data are written by the IC Manufacturer to identify the IC uniquely. The travel document Manufacturer writes the Pre-personalisation Data which contains at least the Personalisation Agent Key. P.Pre-Operational Pre-operational handling of the travel document 168 1. The travel document Issuer issues the travel document and approves using the termi- nals complying with all applicable laws and regulations. 169 2. The travel document Issuer guarantees correctness of the user data (amongst other of those, concerning the travel document holder) and of the TSF-data permanently stored in the TOE. 170 3. The travel document Issuer uses only such TOE’s technical components (IC) which enable traceability of the travel document in their manufacturing and issuing life phases, i.e. before they are in the operational phase. 171 4. If the travel document Issuer authorizes a Personalization Agent to personalize the travel document for travel document holders, the travel document Issuer has to ensure that the Personalization Agent acts in accordance with the travel document Issuer’s policy. P.Terminal Abilities and trustworthiness of terminals 172 The Basic Inspection Systems with PACE (BIS-PACE) shall operate their terminals as follows: 173 1. The related terminals (basic inspection system, cf. above) shall be used by terminal operators and by travel document holders as defined in [ICAO9303]. 174 2. They shall implement the terminal parts of the PACE protocol [ICAOSAC], of the Pas- sive Authentication and use them in this order. The PACE terminal shall use randomly and (almost) uniformly selected nonces, if required by the protocols (for generating ephemeral keys for Diffie-Hellman). 175 3. The related terminals need not to use any own credentials. 176 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 Authentication (determination of the authenticity of data groups stored in the travel document [6]). 177 5. The related terminals and their environment shall ensure confidentiality and integrity of respective data handled by them (e.g. confidentiality of PACE passwords, integrity of PKI certificates, etc.), where it is necessary for a secure operation of the TOE according to the current PP (). P.Trustworthy_PKI Trustworthiness of PKI 178 The CSCA shall ensure that it issues its certificates exclusively to the rightful organizations (DS) and DSs shall ensure that they sign exclusively correct Document Security Ob- jects having to be stored on the travel document. Security Target TCOS ID Version 2.0 Release 1/P6022y 29/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 179 The following OSPs are defined in the SSCD PP [SSCDPP]. They are applicable, if the eSign application is included. P.CSP_QCert Qualified certificate 180 The CSP uses a trustworthy CGA to generate a qualified certificate or non-qualified cer- tificate (cf. [eIDAS, Article 3 clause 15 and Annex I]) for the SVD generated by the SSCD. The certificates contain at least the name of the signatory and the SVD matching the SCD implemented in the TOE under sole control of the signatory. The CSP ensures that the use of the TOE as SSCD is evident with signatures through the certificate or other publicly available information. P.QSign Qualified electronic signatures 181 The signatory uses a signature-creation system to sign data with an advanced electronic signature according to [eIDAS], which is a qualified electronic signature if it is based on a valid qualified certificate. The DTBS are presented to the signatory and sent by the SCA as DTBS/R to the SSCD. The SSCD creates the digital signature created with a SCD implemented in the SSCD that the signatory maintain under his sole control and is linked to the DTBS/R in such a manner that any subsequent change of the data is detectable. P.Sig_Non-Repud Non-repudiation of signatures 182 The life cycle of the SSCD, the SCD and the SVD shall be implemented in a way that the signatory is not able to deny having signed data if the signature is successfully verified with the SVD contained in his un-revoked certificate. P.Sigy_SSCD SSCD TOE as secure signature-creation device 183 The TOE meets the requirements for an SSCD laid down in the eIDAS Regulation and its Implenenting Acts []eIDAS]. This implies the SCD is used for digital signature creation under sole control of the signatory and the SCD can practically occur only once. 184 The following OSPs are defined in the PP Module [MREDONPP]: P.Code_Confidentiality 185 Update code packages that are created by the TOE software developer or document man- ufacturer are kept confidential, are encrypted after development at the site of the electronic document manufacturer, and are delivered to the TOE in encrypted form. P.Secure_Environment 186 Update terminals are placed in a secure environment that prevents unauthorized physical access, and are operated by authorized staff only. Authorized staff oversees the complete update procedure. P.Eligible_Terminals_Only 187 Update terminals (i.e. terminals with appropriate certificates that are able to install up- dates) are handed only to those entities where P.Secure_Environment is enforced. In case of a security incident, these update terminals are functionally disabled (through organiza- tional and/or cryptographic means by e.g. withdrawing certificates). Security Target TCOS ID Version 2.0 Release 1/P6022y 30/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 3.4 Assumptions 188 The assumptions describe the security aspects of the environment in which the TOE will be used or is intended to be used. 189 The assumptions A.Process-Sec-IC, A.Plat-Appl and A.Resp-Appl defined in the Protec- tion Profile [ICPP] are not relevant for this ST. 190 The following assumptions are included from [EAC1PP]. They concern EAC1-protected data. A.Auth_PKI PKI for Inspection Systems 191 The issuing and receiving States or Organizations establish a public key infrastructure for card verifiable certificates of the Extended Access Control. The Country Verifying Certifi- cation Authorities, the Document Verifier and Extended Inspection Systems hold authen- tication key pairs and certificates for their public keys encoding the access control rights. The Country Verifying Certification Authorities of the issuing States or Organizations are signing the certificates of the Document Verifier and the Document Verifiers are signing the certificates of the Extended Inspection Systems of the receiving States or Organiza- tions. The issuing States or Organizations distribute the public keys of their Country Veri- fying Certification Authority to their travel document’s chip. A.Insp_Sys Inspection Systems for global interoperability 192 The Extended Inspection System (EIS) for global interoperability (i) includes the Country Signing CA Public Key and (ii) implements the terminal part of PACE [ICAOSAC] and/or BAC [BACPP]. BAC may only be used if supported by the TOE. If both PACE and BAC are supported by the TOE and the IS, PACE must be used. The EIS reads the logical travel document under PACE or BAC and performs the Chip Authentication v.1 to verify the logical travel document and establishes secure messaging. EIS supports the Terminal Authentication Protocol v.1 in order to ensure access control and is authorized by the issuing State or Organization through the Document Verifier of the receiving State to read the sensitive biometric reference data. 193 [EAC2PP] only includes the assumption from [PACEPP] (see below) and defines no other assumption. 194 The following assumptions are included from PACE PP [PACEPP], since both [EAC1PP] and [EAC2PP] claim [PACEPP]. We list each OSP only once here. A.Passive_Auth PKI for Passive Authentication 195 The issuing and receiving States or Organizations establish a public key infrastructure for passive authentication i.e. digital signature creation and verification for the logical travel document. The issuing State or Organization runs a Certification Authority (CA) which se- curely generates, stores and uses the Country Signing CA Key pair. The CA keeps the Country Signing CA Private Key secret and is recommended to distribute the Country Signing CA Public Key to ICAO, all receiving States maintaining its integrity. The Docu- ment Signer (i) generates the Document Signer Key Pair, (ii) hands over the Document Signer Public Key to the CA for certification, (iii) keeps the Document Signer Private Key secret and (iv) uses securely the Document Signer Private Key for signing the Document Security Target TCOS ID Version 2.0 Release 1/P6022y 31/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 Security Objects of the travel documents. The CA creates the Document Signer Certifi- cates for the Document Signer Public Keys that are distributed to the receiving States and Organizations. It is assumed that the Personalization Agent ensures that the Document Security Object contains only the hash values of genuine user data according to [ICAO9303]. 196 The following assumptions are included from SSCD PP [SSCDPP]. They are applicable, if the eSign application is included. A.CGA Trustworthy certificate generation application 197 The CGA protects the authenticity of the signatory’s name or pseudonym and the SVD in the (qualified) certificate by an advanced electronic signature of the CSP. A.SCA Trustworthy signature creation application 198 The signatory uses only a trustworthy SCA. The SCA generates and sends the DTBS/R of the data the signatory wishes to sign in a form appropriate for signing by the TOE. 199 No additional assumptions are made by the PP Module [MREDONPP]. Security Target TCOS ID Version 2.0 Release 1/P6022y 32/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 4 Security Objectives 200 This chapter describes the security objectives for the TOE and for the TOE environment. The security objectives for the TOE environment are separated into security objectives for the development, and production environment and security objectives for the operational environment. 4.1 Security Objectives for the TOE 201 The following TOE security objectives address the protection provided by the TOE inde- pendent of the TOE environment. 202 The following Security Objectives for the TOE are defined in the Protection Profile [ICPP] for the Loader and are relevant for the electronic document manufacturing process ([MREDPP]). A loader is a part of the chip operating system that allows to load data, i.e. the object system containing (sensitive) user data, TSF data etc. into the Flash or EEPROM memory after delivery of the smart card to the document manufacturer. OT.Cap_Avail_Loader Availability of the Loader Functionality 203 The TSF provides limited capability of the Loader functionality of the TOE embedded soft- ware and irreversible termination of the Loader in order to protect user data from disclo- sure and manipulation. 204 The following objective is defined in ([MREDPP]) and concerns the consistency of the access control mechanisms. OT.Non_Interfere No interference of Access Control Mechanisms 205 The various implemented access control mechanisms must be consistent. Their imple- mentation must not allow to circumvent an access control mechanism by exploiting an unintended implementational interference of one access control mechanism with another one. OT.CA3 Protection against advanced tracing techniques using Chip Authentication 3 206 The TOE provides the Chip Authentication 3 protocol. Chip Authentication 3 provides a message-deniable strong explicit authentication of the electronic document, pseudonymity of the electronic document without the need to use the same keys on several chips, and the possibility of whitelisting electronic documents, even in the case of a group key com- promise. (cf. [EACTR-2-v2.20]). 207 The following objectives are included from [EAC1PP]. They concern EAC1-protected data. For the remaining security objectives see the next sections. OT.Chip_Auth_Proof Proof of the travel document’s chip authenticity 208 The TOE must support the Inspection Systems to verify the identity and authenticity of the travel document’s chip as issued by the identified issuing State or Organization by means of the Chip Authentication Version 1 as defined in [5]. The authenticity proof provided by travel document’s chip shall be protected against attacks with high attack potential. Security Target TCOS ID Version 2.0 Release 1/P6022y 33/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 209 Application Note 18: The OT.Chip_Auth_Proof implies the travel document’s chip to have (i) a unique identity as given by the travel document’s Document Number, (ii) a secret to prove its identity by knowledge i.e. a private authentication key as TSF data. The TOE shall protect this TSF data to prevent their misuse. The terminal shall have the reference data to verify the authentication attempt of travel document’s chip i.e. a certificate for the Chip Authentication Public Key that matches the Chip Authentication Private Key of the travel document’s chip. This certificate is provided by (i) the Chip Authentication Public Key (EF.DG14) in the LDS defined and (ii) the hash value of DG14 in the Document Se- curity Object signed by the Document Signer OT.Sens_Data_Conf Confidentiality of sensitive biometric reference data 210 The TOE must ensure the confidentiality of the sensitive biometric reference data (EF.DG3 and EF.DG4) by granting read access only to authorized Extended Inspection Systems. The authorization of the inspection system is drawn from the Inspection System Certificate used for the successful authentication and shall be a non-strict subset of the authorization defined in the Document Verifier Certificate in the certificate chain to the Country Verifier Certification Authority of the issuing State or Organization. The TOE must ensure the con- fidentiality of the logical travel document data during their transmission to the Extended Inspection System. The confidentiality of the sensitive biometric reference data shall be protected against attacks with high attack potential. OT.Chip_Auth_Proof_PACE_CAM Proof of the electronic document’s chip authenticity(Refinement of OT.Chip_Auth_Proof) 211 The TOE must support the Terminals Inspection Systems to verify the identity and au- thenticity of the travel electronic document’s chip as issued by the identified issuing State or Organization by means of the Chip Authentication Version 1 as defined in [EACTR-1] PACE-Chip Authentication Mapping (PACE-CAM) as defined in [ICAO9303]. The au- thenticity proof provided by travel electronic document’s chip shall be protected against attacks with high attack potential. 212 Application Note 19: PACE-CAM enables much faster authentication of the of the chip than running PACE with General Mapping (according to [TR03110-1]) followed by CA1.en- sure the confidentiality of the sensitive biometric reference data (EF.DG3 and EF.DG4) by granting read access only to authorized Extended Inspection Systems. The authorization of the inspection system is drawn from the Inspection System Certificate used for the suc- cessful authentication and shall be a non-strict subset of the authorization defined in the Document Verifier Certificate in the certificate chain to the Country Verifier Certification Authority of the issuing State or Organization. The TOE must ensure the confidentiality of the logical travel document data during their transmission to the Extended Inspection Sys- tem. The confidentiality of the sensitive biometric reference data shall be protected against attacks with high attack potential. 213 The following objectives are included from [EAC2PP]. They concern EAC2-protected data. For the remaining security objectives see the next sections. Note that justifications made in the PP will not be repeated here. Please refer to the Protection Profile [EAC2PP]. OT.AC_Pers_EAC2 Personalization of the Electronic Document 214 The TOE must ensure that user data and TSF-Data that are permanently stored in the TOE can be written by authorized personalization agents only, with the following excep- tion: An EAC2 terminal may also write or modify user data according to its effective access Security Target TCOS ID Version 2.0 Release 1/P6022y 34/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 rights. The access rights are determined by the electronic document during Terminal Au- thentication 2. OT.CA2 Proof of the Electronic Document’s Chip Authenticity 215 The TOE must allow EAC2 terminals to verify the identity and authenticity of the electronic document’s chip as being issued by the identified issuing state or organization by Chip Authentication 2 [EACTR-2]. The authenticity of the chip and its proof mechanism provided by the electronic document’s chip shall be protected against attacks with high attack po- tential. OT.RI_EAC2 Support of Restricted Identity by the TOE 216 If the TOE supports pseudonymous authentication, it must use the Restricted Identity pro- tocol as defined in [EACTR-2]. OT.Sens_Data_EAC2 Confidentiality of sensitive User Data 217 The TOE must ensure confidentiality of sensitive user data by granting access to sensitive data only to EAC2 terminals with corresponding access rights. The authorization of an EAC2 terminal is the minimum set of the access rights drawn from the terminal certificate used for successful authentication and the corresponding DV and CVCA certificates, and the access rights sent to the electronic document as part of PACE. 218 The TOE must ensure confidentiality of all user data during transmission to an EAC2 ter- minal after Chip Authentication 2. Confidentiality of sensitive user data shall be protected against attacks with high attack potential. 219 The following objectives are included from PACE PP [PACEPP], since both [EAC1PP] and [EAC2PP] claim [PACEPP]. OT.AC_Pers Access Control for Personalization of logical MRTD 220 The TOE must ensure that the logical travel document data in EF.DG1 to EF.DG16, the Document Security Object according to LDS [ICAO9303] and the TSF data can be written by authorized Personalization Agents only. The logical travel document data in EF.DG1 to EF.DG16 and the TSF data may be written only during and cannot be changed after personalization of the document. 221 Application Note 20: The OT.AC_Pers implies that the data of the LDS groups written dur- ing personalization for travel document holder (at least EF.DG1 and EF.DG2) can not be changed using write access after personalization. OT.Data_Authenticity Authenticity of Data 222 The TOE must ensure authenticity of the User Data and the TSF-data31 stored on it by enabling verification of their authenticity at the terminal-side32.The TOE must ensure au- thenticity of the User Data and the TSF-data during their exchange between the TOE and the terminal connected (and represented by PACE authenticated BIS-PACE) after the PACE Authentication. It shall happen by enabling such a verification at the terminal-side (at receiving by the terminal) and by an active verification by the TOE itself (at receiving by the TOE). Security Target TCOS ID Version 2.0 Release 1/P6022y 35/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 OT.Data_Confidentiality Confidentiality of Data 223 The TOE must ensure confidentiality of the User Data and the TSF-data34 by granting read access only to the PACE authenticated BIS-PACE connected. The TOE must ensure confidentiality of the User Data and the TSF-data during their exchange between the TOE and the terminal connected (and represented by PACE authenticated BIS-PACE) after the PACE Authentication. OT.Data_Integrity Integrity of Data 224 The TOE must ensure integrity of the User Data and the TSF-data30 stored on it by pro- tecting these data against unauthorized modification (physical manipulation and unauthor- ized modifying).The TOE must ensure integrity of the User Data and the TSF-data during their exchange between the TOE and the terminal connected (and represented by PACE authenticated BIS-PACE) after the PACE Authentication. OT.Identification Identification of the TOE 225 The TOE must provide means to store Initialization36 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 cycle phases of the travel document. The storage of the Pre-Personalization data includes writing of the Personalization Agent Key(s). OT.Prot_Abuse-Func Protection against Abuse of Functionality 226 The TOE must prevent that functions of the TOE, which may not be used in TOE opera- tional 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 manip- ulate (bypass, deactivate or modify) soft-coded security functionality of the TOE. OT.Prot_Inf_Leak Protection against Information Leakage 227 The TOE must provide protection against disclosure of confidential User Data or/and TSF- data stored and/or processed by the travel document • 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. 228 Application Note 21: This objective pertains to measurements with subsequent complex signal processing due to normal operation of the TOE or operations enforced by an at- tacker. OT.Prot_Malfunction Protection against Malfunctions 229 The TOE must ensure its correct operation. The TOE must prevent its operation outside the normal operating conditions where reliability and secure operation have not been proven or tested. This is to prevent functional errors in the TOE. The environmental con- ditions may include external energy (esp. electromagnetic) fields, voltage (on any con- tacts), clock frequency or temperature. Security Target TCOS ID Version 2.0 Release 1/P6022y 36/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 OT.Prot_Phys-Tamper Protection against Physical Tampering 230 The TOE must provide protection of confidentiality and integrity of the User Data, the TSF- data and the travel document’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 measuring voltage and current) or • measuring not using galvanic contacts, but other types of physical interaction be- tween electrical charges (using tools used in solid-state physics research and IC failure analysis), • manipulation of the hardware and its security functionality, as well as • controlled manipulation of memory contents (User Data, TSF-data) with a prior • reverse-engineering to understand the design and its properties and functionality. OT.Tracing Tracing travel document 231 The TOE must prevent gathering TOE tracing data by means of unambiguous identifying the travel document remotely through establishing or listening to a communication via the contactless/contact interface of the TOE without knowledge of the correct values of shared passwords (PACE passwords) in advance. 232 Application Note 22: Since the Standard Inspection Procedure does not support any unique-secret-based authentication of the travel document’s chip (no Chip Authentication), a security objective like OT.Chip_Auth_Proof (proof of travel document authenticity) can- not be achieved by the current TOE. 233 The following objectives are included from SSCD PP [SSCDPP]. They are applicable, if the eSign application is included. OT.DTBS_Integrity_TOE DTBS/R integrity inside the TOE 234 The TOE must not alter the DTBS/R. As by definition of the DTBS/R this may consist of the DTBS themselves, this objective does not conflict with a signature creation process where the TOE hashes the provided DTBS (in part or entirely) for signature creation. OT.EMSEC_Design Provide physical emanations security 235 The TOE shall be designed and built in such a way as to control the production of intelli- gible emanations within specified limits. OT.Lifecycle_Security Lifecycle security 236 The TOE shall detect flaws during the initialization, personalization and operational usage. The TOE shall securely destroy the SCD on demand of the signatory. 237 Application Note 23: The TOE may contain more than one set of SCD. There is no need to destroy the SCD in case of repeated SCD generation. The signatory shall be able to destroy the SCD stored in the SSCD e.g. after the (qualified) certificate for the correspond- ing SVD has been expired. OT.SCD_Secrecy Secrecy of the signature creation data 238 The secrecy of the SCD (used for signature creation) shall be reasonably assured against attacks with a high attack potential. Security Target TCOS ID Version 2.0 Release 1/P6022y 37/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 239 Application Note 24: The TOE shall keep the confidentiality of the SCD at all times, in particular during SCD/SVD generation, signature creation operation, storage and secure destruction. OT.SCD_SVD_Corresp Correspondence between SVD and SCD 240 The TOE shall ensure the correspondence between the SVD and the SCD generated by the TOE. This includes unambiguous reference of a created SVD/SCD pair for export of the SVD and in creating an electronic signature creation with the SCD. OT.SCD_Unique Uniqueness of the signature creation data 241 The TOE shall ensure the cryptographic quality of an SCD/SVD pair it creates as suitable for the advanced or qualified electronic signature. The SCD used for signature creation shall practically occur only once and shall not be reconstructable from the SVD. In that context ‘practically occur once’ means that the probability of equal SCDs is negligible. OT.SCD/SVD_Auth_Gen Authorized SCD/SVD generation 242 The TOE shall provide security features to ensure that authorized users only may invoke the generation of the SCD and the SVD. OT.Sig_Secure Cryptographic security of the electronic signature 243 The TOE shall create digital signatures that cannot be forged without knowledge of the SCD through robust encryption techniques. The SCD shall not be reconstructable using the digital signatures or any other data exportable from the TOE. The digital signatures shall be resistant against these attacks, even when executed with a high attack potential. OT.Sigy_SigF Signature creation function for the legitimate signatory only 244 The TOE shall provide the digital signature creation function for the legitimate signatory only and protects the SCD against the use of others. The TOE shall resist attacks with high attack potential. OT.Tamper_ID Tamper detection 245 The TOE shall provide system features that detect physical tampering of its components, and uses those features to limit security breaches. OT.Tamper_Resistance Tamper resistance 246 The TOE shall prevent or resist physical tampering with specified system devices and components. 247 A careful analysis reveals that the formally listed here objectives OT.SCD_Secrecy, OT.DTBS_Integrity_TOE, OT.EMSEC_Design, OT.Tamper_ID, and OT.Tamper_Resis- tance are actually fully or partly covered by security objectives included from the [PACEPP]. 248 The following objectives are included from PP Module [MREDONPP]. OT.Update_MechanismTOE Update Mechanism 249 The TSF provides a mechanism to install code-signed updates of the TOE software by authorized staff during operational use. Security Target TCOS ID Version 2.0 Release 1/P6022y 38/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 OT.Enc_Sign_Update Encrypted-then-signed Update Packages 250 The TOE only installs update packages that are encrypted, integrity-protected and signed by the authority in charge of delivering and installing updates. OT.Update_Terminal_Auth Updates only by authenticated Update Terminals 251 The TOE allows only authenticated update terminals to upload an update package to the TOE and to initiate the update procedure. The TOE uses a dedicated cryptographic method described in the TCOS Admin Guidance [TCOSGD] to authenticate an update terminal. OT.Attack_Detection Detection of Attacks on the TOE using the Update Mechanism 252 The TOE has logging capabilities that track installed updates and failed update attempts. It also limits the amount of faulty (signature verification or decryption fails) update at- tempts. It allows dedicated terminals to read out the update logs. OT.Key_Secrecy Key Secrecy of Cryptographic Update Keys 253 The TOE keeps the cryptographic update keys secret, and is designed such that emis- sions from the TOE do not allow to read out or gain full or partial information about the keys. 4.2 Security Objectives for the Operational Environment 254 These objectives for the environment are extended to the electronic document manufac- turing process by the following objective defined in ([MREDPP]). OE.Lim_Block_Loader 255 The manufacturer will protect the Loader functionality against misuse, limit the capability of the Loader and terminate irreversibly the Loader after intended usage of the Loader. 256 Justification: This security objective directly addresses the threat OT.Non_Interfere. This threat concerns the potential interference of different access control mechanisms, which could occur as a result of combining different applications on a smartcard. Such combina- tion does not occur in one of the claimed PPs. Hence, this security objective for the envi- ronment does • neither mitigate a threat of one of the claimed PPs that was addressed by security objectives of that PP, • nor does it fulfill any organizational security policy of one of the claimed PPs that was meant to be addressed by security objectives of the TOE of that PP. 257 The following objectives are included from [EAC1PP]. They concern EAC1-protected data. For the remaining security objectives see the next sections. Note that justifications made in the PP will not be repeated here. Please refer to the Protection Profile [EAC1PP]. OE.Auth_Key_Travel_Document Travel document Authentication Key 258 The issuing State or Organization has to establish the necessary public key infrastructure in order to (i) generate the travel document’s Chip Authentication Key Pair, (ii) sign and store the Chip Authentication Public Key in the Chip Authentication Public Key data in EF.DG14 and (iii) support inspection systems of receiving States or Organizations to verify Security Target TCOS ID Version 2.0 Release 1/P6022y 39/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 the authenticity of the travel document’s chip used for genuine travel document by certifi- cation of the Chip Authentication Public Key by means of the Document Security Object. OE.Authoriz_Sens_Data Authorization for Use of Sensitive Biometric Reference Data 259 The issuing State or Organization has to establish the necessary public key infrastructure in order to limit the access to sensitive biometric reference data of travel document holders to authorized receiving States or Organizations. The Country Verifying Certification Au- thority of the issuing State or Organization generates card verifiable Document Verifier Certificates for the authorized Document Verifier only. OE.Exam_Travel_Document Examination of the physical part of the travel document 260 The inspection system of the receiving State or Organization must examine the travel doc- ument presented by the traveller to verify its authenticity by means of the physical security measures and to detect any manipulation of the physical part of the travel document. The Basic Inspection System for global interoperability (i) includes the Country Signing CA Public Key and the Document Signer Public Key of each issuing State or Organization, and (ii) implements the terminal part of PACE [ICAO9303] and/or the Basic Access Control [BACPP]. Extended Inspection Systems perform additionally to these points the Chip Au- thentication Protocol Version 1 to verify the Authenticity of the presented travel document’s chip. OE.Ext_Insp_Systems Authorization of Extended Inspection Systems 261 The Document Verifier of receiving States or Organizations authorizes Extended Inspec- tion Systems by creation of Inspection System Certificates for access to sensitive bio- metric reference data of the logical travel document. The Extended Inspection System authenticates themselves to the travel document’s chip for access to the sensitive bio- metric reference data with its private Terminal Authentication Key and its Inspection Sys- tem Certificate. OE.Prot_Logical_Travel_Document Protection of data from the logical travel document 262 The inspection system of the receiving State or Organization ensures the confidentiality and integrity of the data read from the logical travel document. The inspection system will prevent eavesdropping to their communication with the TOE before secure messaging is successfully established based on the Chip Authentication Protocol Version 1. 263 The following objectives are included from [EAC2PP]. They concern EAC2-protected data. For the remaining security objectives see the next sections. Note that justifications made in the PP will not be repeated here. Please refer to the Protection Profile [EAC2PP]. OE.Chip_Auth_Key Key Pairs needed for Chip Authentication and Restricted Identification 264 The electronic document issuer has to ensure that the electronic document’s chip authen- tication key pair and the Restricted Identification key pair are generated securely, that the private keys of these key pairs are stored correctly in the electronic document's chip, and that the corresponding public keys are distributed to the EAC2 terminals that are used according to [EACTR-2] to check the authenticity of the electronic document's chip. Security Target TCOS ID Version 2.0 Release 1/P6022y 40/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 OE.RestrictedIdentity Restricted Identity and Sector’s Static Key Pairs 265 If the TOE supports pseudonymous identification and thus implements the Restricted Identity protocol, the electronic document issuer has to ensure that the Restricted Identity key pair is generated securely and the private keys are stored securely in the electronic document as required according to [EACTR-2]. OE.Terminal_Authentication Key pairs needed for Terminal Authentication 266 The electronic document issuer shall establish a public key infrastructure for the card ver- ifiable certificates used for Terminal Authentication. For this aim, the electronic document issuer shall run a Country Verifying Certification Authority. The instances of the PKI shall fulfill the requirements and rules of the corresponding certificate policy. The electronic document issuer shall make the CVCA certificate available to the personalization agent or the manufacturer. 267 The following objectives are included from PACE PP [PACEPP], since both [EAC1PP] and [EAC2PP] claim [PACEPP]. OE.Legislative_Compliance Issuing of the travel document 268 The travel document Issuer must issue the travel document and approve it using the ter- minals complying with all applicable laws and regulations. OE.Passive_Auth_Sign Authentication of travel document by Signature 269 The travel document Issuer has to establish the necessary public key infrastructure as follows: the CSCA acting on behalf and according to the policy of the travel document Issuer must (i) generate a cryptographically secure CSCA Key Pair, (ii) ensure the secrecy of the CSCA Private Key and sign Document Signer Certificates in a secure operational environment, and (iii) publish the Certificate of the CSCA Public Key (CCSCA). Hereby authenticity and integrity of these certificates are being maintained. 270 A Document Signer acting in accordance with the CSCA policy must (i) generate a cryp- tographically secure Document Signing Key Pair, (ii) ensure the secrecy of the Document Signer Private Key, (iii) hand over the Document Signer Public Key to the CSCA for certi- fication, (iv) sign Document Security Objects of genuine travel documents in a secure op- erational environment only. The digital signature in the Document Security Object relates to all hash values for each data group in use according to [ICAO9303. The Personalization Agent has to ensure that the Document Security Object contains only the hash values of genuine user data according to [ICAO9303]. The CSCA must issue its certificates exclu- sively to the rightful organizations (DS) and DSs must sign exclusively correct Document Security Objects to be stored on travel document. OE.Personalization Personalization of travel document 271 The travel document Issuer must ensure that the Personalization Agents acting on his behalf (i) establish the correct identity of the travel document holder and create the bio- graphical data for the travel document, (ii) enroll the biometric reference data of the travel document holder, (iii) write a subset of these data on the physical Travel document (optical personalization) and store them in the travel document (electronic personalization) for the travel document holder as defined in [ICAO9303], (iv) write the document details data, (v) write the initial TSF data, (vi) sign the Document Security Object defined in [ICAO9303] (in the role of a DS). Security Target TCOS ID Version 2.0 Release 1/P6022y 41/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 OE.Terminal Terminal operating 272 The terminal operators must operate their terminals as follows: 1. The related terminals (basic inspection systems, cf. above) are used by terminal oper- ators and by travel document holders as defined in [ICAO9303]. 2. The related terminals implement the terminal parts of the PACE protocol [ICAOSAC], of the Passive Authentication [ICAOSAC] (by verification of the signature of the Docu- ment Security Object) and use them in this order. The PACE terminal uses randomly and (almost) uniformly selected nonces, if required by the protocols (for generating ephemeral keys for Diffie-Hellman). 3. The related terminals need not to use any own credentials. 4. The related terminals securely store the Country Signing Public Key and the Document Signer Public Key (in form of CCSCA and CDS) in order to enable and to perform Pas- sive Authentication of the travel document (determination of the authenticity of data groups stored in the travel document, [ICAO9303]). 5. The related terminals and their environment must ensure confidentiality and integrity of respective data handled by them (e.g. confidentiality of the PACE passwords, integrity of PKI certificates, etc.), where it is necessary for a secure operation of the TOE. 273 Application Note 25: OE.Terminal completely covers and extends “OE.Exam_MRTD”, “OE.Passive_Auth_Verif“ and “OE.Prot_Logical_MRTD” from BAC PP [BACPP]. OE.Travel_Document_Holder Travel document holder Obligations 274 The travel document holder may reveal, if necessary, his or her verification values of the PACE password to an authorized person or device who definitely act according to respec- tive regulations and are trustworthy. 275 The following objectives are included from SSCD PP [SSCDPP]. They are applicable, if the eSign application is included. OE.CGA_QCert Generation of qualified certificates 276 The CGA generates a qualified certificate that includes, inter alias • the name of the signatory controlling the TOE, • the SVD matching the SCD stored in the TOE and controlled by the signatory, • the advanced signature of the CSP. 277 The CGA confirms with the generated certificate that the SCD corresponding to the SVD is stored in a SSCD. OE.DTBS_Intend SCA sends data intended to be signed 278 The Signatory uses trustworthy SCA that • generates the DTBS/R of the data that has been presented as DTBS and which the signatory intends to sign in a form which is appropriate for signing by the TOE, • sends the DTBS/R to the TOE and enables verification of the integrity of the DTBS/R by the TOE, • attaches the signature produced by the TOE to the data or provides it separately. Security Target TCOS ID Version 2.0 Release 1/P6022y 42/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 OE.DTBS_Protect SCA protects the data intended to be signed 279 The operational environment ensures that the DTBS/R cannot be altered in transit be- tween the SCA and the TOE. OE.HID_VAD Protection of the VAD 280 If an external device provides the human interface for user authentication, this device will ensure confidentiality and integrity of the VAD as needed by the authentication method employed from import through its human interface until import through the TOE interface. OE.Signatory Security obligation of the Signatory 281 The Signatory checks that the SCD stored in the SSCD received from SSCD provisioning service is in non-operational state. The Signatory keeps his or her VAD confidential. OE.SSCD_Prov_Service Authentic SSCD provided by SSCD Provisioning Service 282 The SSCD Provisioning Service handles authentic devices that implement the TOE to be prepared for the legitimate user as signatory personalizes and delivers the TOE as SSCD to the signatory. OE.SVD_Auth Authenticity of the SVD 283 The operational environment ensures the integrity of the SVD exported by the TOE to the CGA. The CGA verifies the correspondence between the SCD in the SSCD of the signa- tory and the SVD in the input it provides to the certificate generation function of the CSP. 284 The following objectives are included from PP Module [MREDONPP]. OE.Code_Confidentiality 285 The operational environment must ensure that the TOE software developer or document manufacturer keeps update code packages confidential, encrypts them after development at the site of the developer/manufacturer, and delivers them to the TOE in encrypted form. 286 This objective is applicable in the Development and Production Environment, whereas the following are related to the Operational Environment. OE.Secure_Environment 287 The operational environment must ensure that update terminals are placed in a secure environment that prevents unauthorized physical access, and are operated by authorized staff only. The operational environment must also ensure through e.g. organizational pol- icies and procedures, that authorized staff oversees the complete update procedure. OE.Eligible_Terminals_Only 288 The operational environment must also ensure by, e.g. organizational procedures, sup- ported by cryptographic means, that only those entities that have policies in place that guarantee OE.Secure_Environment, are supplied with update terminals. Moreover, the operational environment guarantees that update terminals can be functionally deactivated if these policies are no longer in place or not enforced at the entities. This is implemented by the issuance of certificates for update terminals in a corresponding public key infra- structure. Security Target TCOS ID Version 2.0 Release 1/P6022y 43/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 289 Justification: Each of these security objectives on the environment directly addresses one of the organizational security policies P.Code_Confidentiality, P.Secure_Environment, and P.Eligible_Terminals_Only. Hence, these security objectives for the environment do • neither mitigate a threat of the base PP that was addressed by security objectives of the base PP, • nor do they fulfill any organizational security policy of the base PP that was meant to be addressed by security objectives of the TOE of the base PP. 290 Note in particular that OE.Eligible_Terminals_Only requires a general issuance and revo- cation mechanism or update terminals and leaves the specific implementation open, whereas OE.Terminal_Authentication of the base PP specifically addresses certificates for EAC2 terminals. 4.3 Security Objective Rationale 291 The following table provides an overview for security objectives coverage (TOE and its environment). It shows that all threats and OSPs are addressed by the security objectives. It also shows that all assumptions are addressed by the security objectives for the TOE environment. O.Leak-Inherent O.Phys-Probing O.Malfunction O.Phys-Manipulation O.Leak-Forced O.Abuse-Func O.Identification O.RND OT.Cap_Avail_Loader OT.Non_Interfere OT.Chip_Auth_Proof OT.Sens_Data_Conf OT.Chip_Auth_Proof_PACE_CAM OT.AC_Pers_EAC2 OT.CA2 OT.CA3 OT.RI_EAC2 OT.Sens_Data_EAC2 OT.AC_Pers OT.Data_Authenticity OT.Data_Confidentiality OT.Data_Integrity OT.Identification OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Malfunction OT.Prot_Phys-Tamper OT.Tracing OT.DTBS_Integrity_TOE OT.EMSEC_Design OT.Lifecycle_Security OT.SCD_Secrecy OT.SCD_SVD_Corresp OT.SCD_Unique OT.SCD/SVD_Auth_Gen OT.Sig_Secure OT.Sigy_SigF OT.Tamper_ID OT.Tamper_Resistance OT.Update_Mechanism OT.Enc_Sig_Update OT.Update_Terminal_Auth OT.Attack_Detection OT.Key_Secrecy T.Leak-Inherent x T.Phys-Probing x T.Malfunction x T.Phys-Manipulation x T.Leak-Forced x T.Abuse-Func x T.RND x T.InconsistentSec x x x x x x x x x x T.Interfere x T.Counterfeit x x x T.Read_Sensitive_Data x T.Counterfeit/EAC2 x T.AdvancedTracing x T.Sensitive_Data x T.Abuse-Func x T.Eavesdropping x T.Forgery x x x x x x T.Information_Leakage x T.Malfunction x T.Phys-Tamper x T.Skimming x x x T.Tracing x T.DTBS_Forgery x T.Hack_Phys x T.SCD_Derive x x T.SCD_Divulg x Security Target TCOS ID Version 2.0 Release 1/P6022y 44/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 O.Leak-Inherent O.Phys-Probing O.Malfunction O.Phys-Manipulation O.Leak-Forced O.Abuse-Func O.Identification O.RND OT.Cap_Avail_Loader OT.Non_Interfere OT.Chip_Auth_Proof OT.Sens_Data_Conf OT.Chip_Auth_Proof_PACE_CAM OT.AC_Pers_EAC2 OT.CA2 OT.CA3 OT.RI_EAC2 OT.Sens_Data_EAC2 OT.AC_Pers OT.Data_Authenticity OT.Data_Confidentiality OT.Data_Integrity OT.Identification OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Malfunction OT.Prot_Phys-Tamper OT.Tracing OT.DTBS_Integrity_TOE OT.EMSEC_Design OT.Lifecycle_Security OT.SCD_Secrecy OT.SCD_SVD_Corresp OT.SCD_Unique OT.SCD/SVD_Auth_Gen OT.Sig_Secure OT.Sigy_SigF OT.Tamper_ID OT.Tamper_Resistance OT.Update_Mechanism OT.Enc_Sig_Update OT.Update_Terminal_Auth OT.Attack_Detection OT.Key_Secrecy T.Sig_Forgery x x T.SigF_Misuse x x x T.SVD_Forgery x T.FaTSF x x x T.UaU x x P.Personalization x x P.Sensitive_Data x P.RestrictedIdentity x P.Manufact x P.Pre-Operational x x P.CSP_QCert x x P.QSign x x P.Sig_Non-Repud x x x x x x x x x x P.Sigy_SSCDPP x x x x x x x x P.Lim_Block_Loader x x P.Process-TOE x Table 4:Security Objective Rationale for the TOE OE.Resp-Appl OE.Process-Sec-IC OE.Lim_Block_Loader OE.Auth_Key_Travel_Document OE.Authoriz_Sens_Data OE.Exam_Travel_Document OE.Ext_Insp_Systems OE.Ext_Insp_Systems OE.Chip_Auth_Key OE.RestrictedIdentity OE.Terminal_Authentication OE.Legislative_Compliance OE.Passive_Auth_Sign OE.Personalization OE.Terminal OE.Travel_Document_Holder OE.CGA_QCert OE.DTBS_Intend OE.DTBS_Protect OE.HID_VAD OE.Signatory OE.SSCD_Prov_Service OE.SVD_Auth OE.Code_Confidentiallity OE.Secure_Environment OE.Eligible_Terminals_Only T.Counterfeit x x T.Skimming x T.Tracing x T.Forgery x x x x T.SigF_Misuse x P.Personalization x P.Sensitive_Data x x P.Pre-Operational x x P.EAC2_Terminal x x x P.RestrictedIdentity x P.Terminal_PKI x P.Card_PKI x P.Terminal x x P.Trustworthy_PKI x P.CSP_QCert x P.QSign x P.Sig_Non-Repud x x x x x x P.Sigy_SSCDPP x P.Lim_Block_Loader x P.Process-TOE x P.Code_Confidentiality x P.Secure_Environment x Security Target TCOS ID Version 2.0 Release 1/P6022y 45/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 OE.Resp-Appl OE.Process-Sec-IC OE.Lim_Block_Loader OE.Auth_Key_Travel_Document OE.Authoriz_Sens_Data OE.Exam_Travel_Document OE.Ext_Insp_Systems OE.Ext_Insp_Systems OE.Chip_Auth_Key OE.RestrictedIdentity OE.Terminal_Authentication OE.Legislative_Compliance OE.Passive_Auth_Sign OE.Personalization OE.Terminal OE.Travel_Document_Holder OE.CGA_QCert OE.DTBS_Intend OE.DTBS_Protect OE.HID_VAD OE.Signatory OE.SSCD_Prov_Service OE.SVD_Auth OE.Code_Confidentiallity OE.Secure_Environment OE.Eligible_Terminals_Only P.Eligible_Terminals_Only x A.Process-Sec-IC x A.Process-Sec-SC x A.Resp-Appl x A.Auth_PKI x x A.Insp_Sys x A.Passive_Auth x x A.CGA x x A.SCA x Table 5:Security Objective Rationale for the Environment For the additional threats the corresponding rationale is given in the claimed by this ST Protection Profile [MREDPP], its Module [MREDONPP] or in the claimed therein PPs. Hence, it will not be repeated here. Security Target TCOS ID Version 2.0 Release 1/P6022y 46/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 5 Extended Components Definition 292 This Security Target includes all extended components from the claimed PPs. This in- cludes families FAU_SAS, FCS_RND, FMT_LIM and FPT_EMS from [PACEPP] and FIA_API from [EAC2PP]. 5.1 FAU_SAS Audit data storage 293 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 capabil- ity to store [assignment: list of audit information] in the audit records. 5.2 FCS_RND Generation of random numbers 294 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 in- tended to be used for cryptographic purposes. Component leveling: FCS_RND.1 Generation of random numbers requires that random numbers meet a defined quality metric. FAU_SAS Audit data storage 1 FCS_RND Generation of random numbers 1 Security Target TCOS ID Version 2.0 Release 1/P6022y 47/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 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 Random number generation 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 295 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 leveling: FIA_API.1 Authentication Proof of Identity. Management: FIA_API.1 The following actions could be considered for the management functions in FMT: Man- agement 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, or of the TOE itself]. 5.4 FMT_LIM Limited capabilities and availability 296 The family “Limited capabilities and availability (FMT_LIM)” is specified as follows. Family behavior FIA_API Authentication Proof of Identity 1 Security Target TCOS ID Version 2.0 Release 1/P6022y 48/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 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 component Limited capability of this family requires the functions themselves to be de- signed in a specific manner. Component leveling: FMT_LIM.1 Limited capabilities require that the TSF is built to provide only the ca- pabilities (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 life-cycle. 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. FMT_LIM.1 Limited capabilities Hierarchical to: No other components. Dependencies: FMT_LIM.2 Limited availability. FMT_LIM.1.1 The TSF shall be designed and implemented in a manner that limits their capabilities so that in conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced [assignment: Limited ca- pability and availability policy]. FMT_LIM.2 Limited availability Hierarchical to: No other components. Dependencies: FMT_LIM.1 Limited capabilities. FMT_LIM.2.1 The TSF shall be designed and implemented in a manner that limits their availability so that in conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is enforced [assignment: Limited ca- pability and availability policy]. 5.5 FPT_EMS TOE Emanation 297 The family “TOE Emanation (FPT_EMS)” is specified as follows. Family behavior This family defines requirements to mitigate intelligible emanations. FMT_LIM Limited capabilities and availability 1 2 Security Target TCOS ID Version 2.0 Release 1/P6022y 49/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 Component leveling: FPT_EMS.1 Emanation of TSF and User data, defines limits of TOE emanation re- lated to TSF and User data. FPT_EMS.1.1 Limit of Emissions requires to not emit intelligible emissions enabling access to TSF data or user data. FPT_EMS.1.2 Interface Emanation requires not emit interface emanation enabling ac- cess to TSF data or user data. Management: FPT_EMS.1 There are no management activities foreseen. Audit: FPT_EMS.1 There are no actions defined to be auditable. FPT_EMS.1 TOE Emanation Hierarchical to: No other components. Dependencies: No other components. FPT_EMS.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_EMS.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]. FPT_EMS TOE emanation 1 Security Target TCOS ID Version 2.0 Release 1/P6022y 50/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 6 Security Requirements 298 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 assur- ance security requirements that the TOE needs to satisfy in order to meet the security objectives for the TOE. 299 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. 300 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. Refinements made by the ST author appear slanted, bold and underlined. 301 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. 302 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. 303 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. 304 In order to distinguish between SFRs defined here and SFRs that are taken over from PPs to which this PP claims strict conformance, the latter are iterated or renamed in the follow- ing way7: /EAC1PP or /□□□_EAC1PP [EAC1PP], /EAC2PP or /□□□_EAC2PP for [EAC2PP], and /SSCDPP or /□□□_SSCDPP for [SSCDPP]. 305 The SFRs related to the module PP [MREDONPP] are marked with the iteration /UPD or /UPD_□□□. 306 The SFRs related to the IC Platform are marked with the iteration /ICP. 6.1 Security Functional Requirements for the TOE 307 The statements of security requirements must be internally consistent. As several different PPs with similar SFRs are claimed, great care must be taken to ensure that these several iterated SFRs do not lead to inconsistency. 308 Both [EAC1PP] and [EAC2PP] claim strict conformance to [PACEPP]. Thus they include all SFRs from [PACEPP]. On the other hand, due to strict conformance to [EAC1PP] and [EAC2PP], this PP includes all SFRs from [EAC1PP] and [EAC2PP]. Hence all SFRs from [PACEPP] appear in this PP twice as SFRs from [EAC1PP] and [EAC2PP], and thus SFRs 7 Here □□□ stands for the original SFR identifier. Security Target TCOS ID Version 2.0 Release 1/P6022y 51/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 from [PACEPP] are not listed in this PP. In other words, despite claiming strict conform- ance to [PACEPP], SFRs can be safely ignored during evaluation and certification as long as [EAC1PP] and [EAC2PP] are taken into account. 309 One must remember that each of these iterated SFRs mostly concerns different (groups of) user and TSF data for each protocol (i.e. PACE, EAC1 and EAC2). We distinguish three cases: 1. The SFRs apply to different data that are accessible by executing different protocols. Hence, they are completely separate. An example is FCS_CKM.1/DH_PACE from [EAC1PP] and [EAC2PP]. No remark is added in such case in the text below. 2. The SFRs are equivalent. Then we list them all for the sake of completeness. Hence, it suffices to consider only one iteration. For such SFRs, we explicitly give a remark. An example is FIA_AFL.1/PACE from [EAC1PP] and [EAC2PP]. 3. The SFRs do not apply to different data or protocols, but are also not completely equivalent. Then these multiple SFRs are refined in such a way, that one common component is reached that subsumes all iterations that stem from the inclusions of the claimed PPs. An example is FDP_ACF.1, which is combined here from [EAC1PP] and [EAC2PP]. Such a case is also explicitly mentioned in the text. 310 Thus, internal consistency is not violated. 6.1.1 Overview 311 In order to give an overview of the security functional requirements mentioned in 1.3.1 in the context of the security services offered by the TOE the security functional groups were considered and the functional requirements described in the following sections are allo- cated to them. The following table provides an overview of security functional require- ments in the context of the main security functionalities offered by the TOE: Security Target TCOS ID Version 2.0 Release 1/P6022y 52/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 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} – {FDP_ACC.1/UPD, FDP_ACF.1/UPD} Supported by: – FIA_UAU.1/EAC2_Terminal: Terminal Authentication (BIS-PACE, EIS-GAP, ATT, SGT) – FIA_UAU.1/EAC1PP: Terminal Authentication (EIS-AIP-BAC) – {FDP_ACC.1/Signature-creation_SSCDPP, FDP_ACF.1/Signature-creation_SSCDPP} Supported by: – FIA_UAU.1/UPD – FIA_UID.1/UPD Secure data exchange between the electronic document and the Ser- vice 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 – FTP_ITC.1/UPD 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/EAC2_Terminal: Terminal Authentication (BIS-PACE, EIS-GAP, ATT, SGT) b) for AIP: – FCS_COP.1/SYM_EAC1PP: encryption/decryption – FCS_COP.1/MAC_EAC1PP: MAC generation/verification – FIA_API.1/EAC1PP: Chip Identification/Authentication (version 1) – FIA_UAU.1/EAC1PP: Terminal Authentication (EIS-AIP-BAC) Identification and authen- tication of users and components – FIA_UID.1/PACE: PACE Identification (PCT equiv. BIS-PACE) – FIA_UID.1/EAC2_Terminal: Terminal Identification (EIS-GAP, ATT, SGT) – FIA_UID.1/EAC1PP: Terminal Identification (EIS-AIP-BAC) – FIA_UAU.1/PACE: PACE Authentication (PCT equiv. BIS-PACE) – FIA_UAU.1/EAC2_Terminal: Terminal Authentication (EIS-GAP, ATT, SGT) – FIA_API.1/CA: Chip Identification / Authentication for GAP (version 2) – FIA_UAU.1/EAC1PP: Terminal Authentication (EIS-AIP-BAC) – FIA_API.1/EAC1PP: Chip Identification/Authentication for AIP (version 1) – FIA_UAU.4: single-use of authentication data – FIA_UAU.5: multiple authentication mechanisms – FIA_UAU.6: Re-authentication of Terminal – FIA_AFL.1/PIN_Suspending – FIA_AFL.1/PIN_Blocking: reaction to unsuccessful authentication attempts for establish- ing PACE communication using blocking authentication data – FIA_AFL.1/PACE: reaction to unsuccessful authentication attempts for establishing PACE communication using non-blocking authentication and authorization data – FIA_AFL.1/UPD – FIA_UID.1/SSCDPP: Identification of electronic document holder as Signatory (eSign- PIN) – FIA_UIA.1/SSCDPP: Authentication of electronic document holder as Signatory (eSign- PIN) – FIA_AFL.1/SSCDPP: 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, SGT) – FCS_CKM.1/DH_CA: Chip Authentication – FCS_CKM.2/DH: Diffie-Hellman key distribution within PACE and Chip Authentication – FCS_CKM.4: session keys destruction (authentication expiration) – FCS_COP.1/SHA: Keys derivation – FCS_RND.1: random numbers generation – FTP_ITC.1/PACE: preventing tracing while establishing Chip Authentication – FMT_SMR.1: security roles definition. Audit – FAU_SAS.1: Audit storage Supported by: – FMT_MTD.1/INI_ENA: Writing Initialization and Pre-personalization – FMT_MTD.1/INI_DIS: Disabling access to Initialization and Pre-personalization Data in the operational phase Generation of the Signa- ture Key Pair for the eSign application – FCS_CKM.1/SSCDPP Supported by: – FCS_CKM.4/SSCDPP – {FDP_ACC.1/SCD/SVD_Generation_SSCDPP, FDP_ACF.1/SCD/SVD_Generation_SSCDPP} – {FDP_ACC.1/SVD_Transfer_SSCDPP, FDP_ACF.1/SVD_Transfer_SSCDPP} Creation of Digital Signa- tures by the eSign appli- cation – FCS_COP.1/SSCDPP Security Target TCOS ID Version 2.0 Release 1/P6022y 53/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 Management of and ac- cess to TSF and TSF- data – The entire class FMT Supported by: – the entire class FIA: user identification/authentication – FCS_CKM.1.1/CA for CA key generation Accuracy of the TOE se- curity functionality / Self- protection – The entire class FPT – FDP_RIP.1: enforced memory/storage cleaning – FDP_SDI.2/Persistent_SSCDPP – FDP_SDI.2/DTBS_SSCDPP Supported by: – the entire class FMT. Table 6: Security Functional Groups vs. SFRs 312 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.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 Ef- fective Date and the Certificate Expiration Date as security attributes. Document Verifier Certificate (CDV) The Document Verifier Certificate CDV is issued by the Country Verifying Certification Authority. It contains (i) the Document Verifier Public Key (PKDV) as authentication reference data (ii) identification as domestic or foreign Document Verifier, the coded access control rights of the Document Verifier, the Certificate Effective Date and the Certificate Expiration Date as security attributes. Terminal Certificate (CT) The Terminal Certificate (CT) is issued by the Document Verifier. It contains (i) the Terminal Public Key (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. Issuing PKI branch Country Signing Certification Authority Key Pair and Certifi- cate Country Signing Certification Authority of the electronic document issuer signs the Document Signer Public Key Certificate (CDS) with the Country Signing Certification Authority Private Key (SKCSCA) and the signature will be verified by receiving terminal with the Country Signing Certification Authority Public Key (PKCSCA). The CSCA also issues the self-signed Country Signing CertA Certificate (CCSCA) having to be distrib- uted by strictly secure diplomatic means. 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 ref- erence data. The Document Signer acting under the policy of the CSCA signs the Card/ Chip Security Object (SOC) of the electronic document and the Document Se- curity Object (SOD) of the ePass 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 electronic document and used by the terminal for Chip Authentication. Its authenticity is verified by terminal in the context of the Pas- sive Authentication (verification of SOC). Note that the TOE provides several Chip Authentication Keys in different EFs (cf. [TCOSGD]). Chip Authentication Private Key (SKPICC) A Chip Authentication Key Pair (SKPICC, PKPICC) is used for Key Agreement Protocol: Diffie-Hellman (DH) according to RFC 2631 or Elliptic Curve Diffie-Hellman (ECDH, ECKA key agreement algorithm) according to [ECCTR, sec. A.2]. SKPICC is used by the TOE to authenticate itself as authentic electronic document. Session keys PACE Session Keys (PACE- KMAC, PACE-KEnc) Secure messaging AES keys for message authentication (CMAC-mode) and for message encryption (CBC-mode) agreed between the TOE and a terminal (PCT) as result of the PACE Protocol. Security Target TCOS ID Version 2.0 Release 1/P6022y 54/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 Name Data Chip Authentication Session Keys (CA-KMAC, CA-KEnc) Secure messaging AES keys for message authentication (CMAC-mode) and for message encryption (CBC-mode) agreed between the TOE and terminal (EIS-AIP- BAC, EIS-GAP, ATT, SGT) as result of the Chip Authentication Protocol, see, Part 2, A.4, and E.2.2, A.2.3.2. Ephemeral keys PACE authentication ephem- eral 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- anonymization), see Part 1, sec. 3 and Part 2, sec. 3]. 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 [Part 1, sec. 3 and Part 2, sec. 3]. For Restricted Identification please also refer to Paragraph 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 Electronic document 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 sig- nature. Properties of this key pair shall fulfill the relevant requirements stated in [XXX] in order to be compliant with the European eIDAS Regulation. Update Key Secret Update Key Secret Update Key is represented by a private cryptographic key being used by the TOE to create a secure channel for the installation of packages to update TOE and User Data in the operational phase. The update mechanism is described in detail in the Guidance [TCOSGD]. Using this key the TOE prevents the acceptance of wrong packages. Table 7: Keys and Certificates 6.1.2 Class FAU Security Audit 313 The following SFR is imported due to claiming [PACEPP]. • FAU_SAS.1/PACEPP (equivalent to FAU_SAS.1/EAC2PP, listed here only for the sake of completeness) 314 The following SFRs are imported due to claiming [EAC1PP] and [EAC2PP] in the Protec- tion Profile [MREDPP]. • FAU_SAS.1/EAC1PP (equivalent to FAU_SAS.1/PACEPP, listed here only for the sake of completeness) • FAU_SAS.1/EAC2PP 315 The following SFR is imported due to claiming [MREDONPP]. • FAU_SAS.1/UPD 316 FAU_SAS.1/EAC2PP Audit storage Hierarchical to: No other components. Dependencies: No dependencies. Security Target TCOS ID Version 2.0 Release 1/P6022y 55/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FAU_SAS.1/EAC2PP The TSF shall provide the Manufacturer8 with the capability to store the Initialization and Pre-Personalization Data9 in the audit records. 317 Application Note 26: The Manufacturer role is the default user identity assumed by the TOE in the life phase ‘manufacturing’. The IC manufacturer and the electronic document manufacturer 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 electronic document (see FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS). Please note that there could also be such audit records which cannot be read out, but directly used by the TOE. 318 FAU_SAS.1/UPD Audit storage Hierarchical to: No other components. Dependencies: No dependencies. FAU_SAS.1.1/UPD The TSF shall provide the TOE update functionality10 with the capability to store update log information and version history, namely the following data objects: update package information data11 in the audit records. 6.1.3 Class FCS Cryptographic Support 319 The following SFRs are imported due to claiming [EAC2PP]. They concern cryptographic support for applications that contain EAC2-protected data groups. • FCS_CKM.1/DH_PACE_EAC2PP • FCS_COP.1/SHA_EAC2PP • FCS_COP.1/SIG_VER_EAC2PP • FCS_COP.1/PACE_ENC_EAC2PP • FCS_COP.1/PACE_MAC_EAC2PP • FCS_CKM.4/EAC2PP • FCS_RND.1/EAC2PP 320 The following SFRs are imported due to claiming [EAC1PP]. They concern cryptographic support for applications that contain EAC1-protected data groups. • FCS_CKM.1/DH_PACE_EAC1PP • FCS_CKM.4/EAC1_PP (equivalent to FCS_CKM.4/EAC2PP, listed here only for the sake of completeness) • FCS_COP.1/PACE_ENC_EAC1PP • FCS_COP.1/PACE_MAC_EAC1PP 8 [assignment: authorized users] 9 [assignment: list of audit information] 10 [assignment: authorized users] 11 [assignment: list of audit information] Security Target TCOS ID Version 2.0 Release 1/P6022y 56/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 321 Application Note 27: Note that national regulations on key sizes and algorithms may fur- ther restrict the choice of algorithms and key sizes defined in the above two SFRs. • FCS_RND.1/EAC1PP (equivalent to FCS_RND.1/EAC2PP, listed here only for the sake of completeness) • FCS_CKM.1/CA_EAC1PP • FCS_COP.1/CA_ENC_EAC1PP • FCS_COP.1/SIG_VER_EAC1PP • FCS_COP.1/CA_MAC_EAC1PP 322 The following SFRs are imported due to claiming [MREDONPP]. • FCS_CKM.1/UPD_ITC • FCS_CKM.1/UPD_DEC • FCS_CKM.1/UPD_INT • FCS_CKM.4/UPD • FCS_COP.1/UPD_ITC • FCS_COP.1/UPD_DEC • FCS_COP.1/UPD_SIG • FCS_COP.1/UPD_INT 323 The following SFRs are imported due to claiming [SSCDPP]. They only concern the cryp- tographic support for an eSign application. • FCS_CKM.1/SSCDPP • FCS_CKM.4/SSCDPP (equivalent to FCS_CKM.4/EAC2PP, listed here only for the sake of completeness) • FCS_COP.1/SSCDPP 324 The following SFRs are defined in [MREDPP] and concerns cryptographic support for en- hancements of [EAC2PP] (Chip Authentication 3). • FCS_CKM.1/CA3 • FCS_COP.1/CA3 325 The following SFRs are defined in [MREDPP] and concerns cryptographic support for ePassport applications in combination with [EAC1PP]. • FCS_CKM.1/CAM • FCS_COP.1/CAM 326 The TOE provides cryptographic services based on elliptic curve cryptography (ECC) us- ing the following curves with corresponding key lengths (1) key length 192 bit a. brainpoolP192r1 defined in RFC5639 [RFC5639], b. brainpoolP192t1 defined in RFC5639 [RFC5639], c. ansix9p192r1 defined in ANSI X.9.62, identical to P-192 defined in [FIPS186], (2) key length 224 bit a. brainpoolP224r1 defined in RFC5639 [RFC5639], b. brainpoolP224t1 defined in RFC5639 [RFC5639], (3) key length 256 bit a. brainpoolP256r1 defined in RFC5639 [RFC5639], b. brainpoolP256t1 defined in RFC5639 [RFC5639], c. ansix9p256r1 defined in ANSI X.9.62, identical to P-256 defined in [FIPS186], Security Target TCOS ID Version 2.0 Release 1/P6022y 57/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 (4) key length 320 bit a. brainpoolP320r1 defined in RFC5639 [RFC5639], b. brainpoolP320t1 defined in RFC5639 [RFC5639], (5) key length 384 bit a. brainpoolP384r1 defined in RFC5639 [RFC5639], b. brainpoolP384t1 defined in RFC5639 [RFC5639], c. ansix9p384r1 defined in ANSI X.9.62, identical to P-384 defined in [FIPS186], (6) key length 512 bit a. brainpoolP512r1 defined in RFC5639 [RFC5639]. b. brainpoolP512t1 defined in RFC5639 [RFC5639]. 327 Application Note 28: Note that beside the listed supported elliptic curves, it is generally possible to import customer specific curves, if one follows the encoding rules defined in the TCOS Admin Guidance [TCOSGD]. Cryptographic security conditions, as e.g., re- quired by [RFC5639, sec 2.1 Security Requirements], are not checked by the TOE. There- fore, it is strongly recommended to check the curve parameters before import during per- sonalization phase by the administrator. The scope of the TOE contains only the specified curves. Because the curves with the length 192 and 224 are not specified in any SFR the scope of this TOE also does not include these curves. 328 FCS_CKM.1/CA_EAC1PP Cryptographic key generation – CA Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Crypto- graphic operation] fulfilled FCS_CKM.4 Cryptographic key destruction fulfilled FCS_CKM.1.1/CA_EAC1PP The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm ECDH compliant to [ECCTR]12 and specified cryptographic key sizes 256, 320, 384, 512 bit13 that meet the following: based on an ECDH protocol compliant to TR-3110 [EACTR]14. 329 FCS_CKM.1/DH_PACE_EAC1PP Cryptographic key generation – DH by PACE Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Crypto- graphic operation] fulfilled FCS_CKM.4 Cryptographic key destruction fulfilled FCS_CKM.1.1/DH_PACE_EAC1PP 12 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to [PKCS#3], ECDH compliant to [ECCTR]] 13 [assignment: cryptographic key sizes] 14 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 58/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm ECDH compliant to [ECCTR]15 and specified cryptographic key sizes 256, 320, 384, 51216 that meet the following: TR-3110 [EACTR, part 2]17. 330 FCS_CKM.1/DH_PACE_EAC2PP Cryptographic key generation – DH by PACE Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Crypto- graphic operation] fulfilled FCS_CKM.4 Cryptographic key destruction fulfilled FCS_CKM.1.1/DH_PACE_EAC2PP The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm ECDH compliant to [ECCTR18 and specified cryptographic key sizes 256, 320, 384, 51219 that meet the following: TR-3110-2 [EACTR]20. 331 Application Note 29: The TOE exchanges a shared secret with the external entity during the PACE protocol, see [EACTR]. This protocol is based on the ECDH protocol compliant to TR-03111 [ECCTR] (i.e. the elliptic curve cryptographic algorithm ECKA). The shared secret is used for deriving the AES session keys for message encryption and message authentication according to [EACTR] for the TSF as required by FCS_COP.1/ PACE.PICC.ENC, and FCS_COP.1/PACE.PICC.MAC. FCS_CKM.1/DH.PACE.PICC im- plicitly contains the requirements for the hashing functions used for key derivation by de- manding compliance to TR-03110 [EACTR]. 332 FCS_CKM.1/CA3 Cryptographic key generation – Diffie-Hellman for Chip Authentication 3 Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Crypto- graphic operation] fulfilled FCS_CKM.4 Cryptographic key destruction fulfilled FCS_CKM.1.1/CA3 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm Chip Authentication 15 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to [PKCS#3], ECDH compliant to [ECCTR]] 16 [assignment: cryptographic key sizes] 17 [assignment: list of standards] 18 [selection: id-PACE-ECDH-GM-AES-CBC-CMAC-128 with brainpoolP256r1, id-PACE-ECDH-GM-AES-CBC-CMAC-192 with brainpoolP384r1, id-PACE-ECDH-GM-AES-CBC-CMAC-256 with brainpoolP512r1] 19 [assignment: cryptographic key sizes] 20 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 59/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 3 using Diffie-Hellman21 and specified cryptographic key sizes 256, 320, 384, 51222 that meet the following: TR-0311-2 v.2.21[EACTR]23. 333 Application Note 30: After successful CA3, secure messaging (cf. FCS_COP.1/ PACE_\ ENC_EAC2PP and FCS_COP.1/PACE_MAC_EAC2PP) is restarted using the derived session keys KEnc and KMAC. 334 FCS_CKM.1/CAM Cryptographic key generation – PACE-CAM public key and Diffie-Hellman for General Mapping in PACE-GM Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Crypto- graphic operation] fulfilled FCS_CKM.4 Cryptographic key destruction fulfilled FCS_CKM.1.1/CAM The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm PACE-CAM in com- bination with PACE-GM24 and specified cryptographic key sizes 256, 320, 384, 51225 that meet the following: [ICAO9303]26. 335 Application Note 31: In the combined protocol PACE-CAM, after the completion of PACE in combination with the general mapping (PACE-GM), the chip authenticates itself by add- ing (multiplying) the randomly chosen nonce of the GM step with the inverse of the chip authentication secret key, and sends this value together with chip authentication public key to the card; cf. [ICAO9303]. 336 FCS_CKM.1/UPD_ITC Cryptographic key generation Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Crypto- graphic operation] fulfilled FCS_CKM.4 Cryptographic key destruction fulfilled FCS_CKM.1.1/UPD_ITC The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm ECDH compliant to 21 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to [PKCS#3], ECDH compliant to [ECCTR]] 22 [assignment: cryptographic key sizes] 23 [assignment: list of standards] 24 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to [PKCS#3], ECDH compliant to [ECCTR]] 25 [assignment: cryptographic key sizes] 26 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 60/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 [ECCTR]27 and specified cryptographic key sizes 128,192,256 bit28 that meet the following: [ECCTR]29. 337 Application Note 32: The details of the TCOS update mechanism are described in the TCOS Guidance. 338 FCS_CKM.1/UPD_DEC Cryptographic key generation Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Crypto- graphic operation] fulfilled FCS_CKM.4 Cryptographic key destruction fulfilled FCS_CKM.1.1/UPD_DEC The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm ECKA30 and speci- fied cryptographic key sizes 128 bit31 that meet the following: [EACTR-3], [TCOSGD]32. 339 FCS_CKM.1/UPD_INT Cryptographic key generation Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Crypto- graphic operation] fulfilled FCS_CKM.4 Cryptographic key destruction fulfilled FCS_CKM.1.1/UPD_INT The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm ECKA33 and speci- fied cryptographic key sizes none34 that meet the following: none35. 340 Application Note 33: The integrity is solely implied by a digital signature verification; hence no key is used here. 27 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to [PKCS#3], ECDH compliant to [ECCTR]] 28 [assignment: cryptographic key sizes] 29 [assignment: list of standards] 30 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to [PKCS#3], ECDH compliant to [ECCTR]] 31 [assignment: cryptographic key sizes] 32 [assignment: list of standards] 33 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to [PKCS#3], ECDH compliant to [ECCTR]] 34 [assignment: cryptographic key sizes] 35 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 61/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 341 FCS_CKM.1/SSCDPP Cryptographic key generation – SSCD Hierarchical to: No other components. Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Crypto- graphic operation] fulfilled FCS_CKM.4 Cryptographic key destruction fulfilled FCS_CKM.1.1/SSCDPP The TSF shall generate an SCD/SVD pair cryptographic keys in ac- cordance with a specified cryptographic key generation algorithm EC- DSA key generation compliant to [ECCTR]36 and specified crypto- graphic key sizes 256, 320, 384 and 512 bit length group order 37 that meet the following: [ECCTR]38. 342 FCS_CKM.4/EAC2PP 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 FCS_CKM.4.1/EAC2PP The TSF shall destroy cryptographic keys in accordance with a speci- fied cryptographic key destruction method physical deletion by over- writing the memory data with zeros, random numbers or the new key39 that meets the following: none40. 343 Application Note 34: The TOE destroys encryption session keys and the message authen- tication keys for secure messaging and the PACE protocol after reset or termination of secure messaging session (trusted channel) or reaching fail secure state according to FPT_FLS.1. The TOE clears the memory area of any session keys before starting a new communication with an external entity in a new after-reset-session as required by FDP_RIP.1. A secret key will be deleted explicitly after execution of the DELETE command. 344 Application Note 35: This SFR covers also the iterated FCS_CKM.4/SSCDPP using the same Selections. 345 FCS_CKM.4/UPD 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 36 [assignment: cryptographic key generation algorithm]/[selection: Diffie-Hellman-Protocol compliant to PKCS#3, ECDH com- pliant to [ECCTR]] 37 [assignment: cryptographic key sizes] 38 [assignment: list of standards] 39 [assignment: cryptographic key destruction method] 40 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 62/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FCS_CKM.1 Cryptographic key generation] fulfilled FCS_CKM.4.1/UPD The TSF shall destroy cryptographic keys in accordance with a speci- fied cryptographic key destruction method physical deletion by over- writing the memory data with zeros, random numbers or the new key41 that meets the following: none42. 346 FCS_COP.1/CA_ENC_EAC1PP Cryptographic operation 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 FCS_CKM.4 Cryptographic key destruction fulfilled FCS_COP.1.1/CA_ENC_EAC1PP The TSF shall perform secure messaging – encryption and decryp- tion43 in accordance with a specified cryptographic algorithm AES,3DES in CBC mode44 and cryptographic key sizes 112, 128, 192 and 256 bit 45 that meet the following: compliant to [ICAOSAC]46. 347 FCS_COP.1/CA_MAC_EAC1PP Cryptographic operation 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 FCS_CKM.4 Cryptographic key destruction fulfilled FCS_COP.1.1/CA_MAC_EAC1PP The TSF shall perform secure messaging – message authentication code47 in accordance with a specified cryptographic algorithm CMAC(AES),Retail-MAC(3DES)48 and cryptographic key sizes 112, 128, 192 or 256 bit49 that meet the following: compliant to [ICA- OSAC]50. 41 [assignment: cryptographic key destruction method] 42 [assignment: list of standards] 43 [assignment: list of cryptographic operations] 44 [assignment: cryptographic algorithm] 45 [assignment: cryptographic key sizes]/[selection: 112, 128, 192, 256] 46 [assignment: list of standards] 47 [assignment: list of cryptographic operations] 48 [assignment: cryptographic algorithm] 49 [assignment: cryptographic key sizes]/[selection: 112, 128, 192, 256] bit 50 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 63/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 348 FCS_COP.1/CAM PACE-CAM 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 FCS_CKM.4 Cryptographic key destruction fulfilled FCS_COP.1.1/CAM The TSF shall perform the PACE-CAM protocol51 in accordance with a specified cryptographic algorithm PACE-CAM52 and cryptographic key sizes 256, 320, 384, 512 bit53 that meet the following: [EACTR, part 2]54. 349 FCS_COP.1/PACE_ENC_EAC1PP Cryptographic operation – PACE secure messaging encryption 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 FCS_CKM.4 Cryptographic key destruction fulfilled FCS_COP.1.1/PACE_ENC_EAC1PP The TSF shall perform decryption and encryption for secure messag- ing55in accordance with a specified cryptographic algorithm AES,3DES56 in CBC mode57 and cryptographic key sizes 112, 128, 192, 256 bit58 that meet the following: compliant to TR-03110 [EACTR, part 2]59. 350 Application Note 36: This SFR requires the TOE to implement the cryptographic primitive for secure messaging with encryption of transmitted data and encrypting the nonce in the first step of PACE. 351 FCS_COP.1/PACE_ENC_EAC2PP Cryptographic operation – PACE secure messaging encryption Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or 51 [assignment: list of cryptographic operations] 52 [assignment: cryptographic algorithm] 53 [assignment: cryptographic key sizes]/[selection: 112, 128, 192, 256] bit 54 [assignment: list of standards] 55 [assignment: list of cryptographic operations] 56 [selection: AES,3DES] 57 [assignment: cryptographic algorithm] 58 [assignment: cryptographic key sizes] 59 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 64/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] fulfilled FCS_CKM.4 Cryptographic key destruction fulfilled FCS_COP.1.1/PACE_ENC_EAC2PP The TSF shall perform secure messaging - encryption and decryption 60in accordance with a specified cryptographic algorithm AES in CBC mode61 and cryptographic key sizes 128, 192, 256 bit62 that meet the following: TR-03110 [EACTR, part 3]63. 352 Application Note 37: This SFR requires the TOE to implement the cryptographic primitive for secure messaging with encryption of transmitted data and encrypting the nonce in the first step of PACE. 353 FCS_COP.1/PACE_MAC_EAC1PP Cryptographic operation – PACE secure messaging 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 FCS_CKM.4 Cryptographic key destruction fulfilled FCS_COP.1.1/PACE_MAC_EAC1PP The TSF shall perform MAC calculation for secure messaging64 in ac- cordance with a specified cryptographic algorithm CMAC(AES), Re- tail-MAC(3DES)65 and cryptographic key sizes 112, 128 bit, 192 bit, 256 bit66 that meet the following: compliant to [ICAOSAC]67. 354 Application Note 38: This SFR requires the TOE to implement the cryptographic primitive for secure messaging with message authentication code over transmitted data. 355 FCS_COP.1/PACE_MAC_EAC2PP Cryptographic operation – PACE secure messaging 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 60 [assignment: list of cryptographic operations] 61 [assignment: cryptographic algorithm] 62 [assignment: cryptographic key sizes] 63 [assignment: list of standards] 64 [assignment: list of cryptographic operations] 65 [assignment: cryptographic algorithm] 66 [assignment: cryptographic key sizes] 67 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 65/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FCS_CKM.4 Cryptographic key destruction fulfilled FCS_COP.1.1/PACE_MAC_EAC2PP The TSF shall perform MAC calculation for secure messaging68 in ac- cordance with a specified cryptographic algorithm CMAC(AES)69 and cryptographic key sizes 128 bit, 192 bit, 256 bit70 that meet the follow- ing: TR03110-3[EACTR, part 3]71. 356 Application Note 39: This SFR requires the TOE to implement the cryptographic primitive for secure messaging with message authentication code over transmitted data. 357 FCS_COP.1/SHA_EAC2PP Cryptographic operation – SHA 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] justified in [MREDPP]: the dependant SFRs are not applicable because this SFR does not use any keys. FCS_CKM.4 Cryptographic key destruction justified in [MREDPP]: the dependant SFRs are not applicable because this SFR does not use any keys. FCS_COP.1.1/SHA_EAC2PP The TSF shall perform hashing72 in accordance with a specified cryp- tographic algorithm (1) SHA-1, (2) SHA-224, (3) SHA-256, (4) SHA-384, (5) SHA-512 73 and cryptographic key sizes none74 that meet the following: FIPS 180-4 [FIPS180]75. 358 FCS_COP.1/SIG_VER_EAC1PP Cryptographic operation – Signature Verifi- cation Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or 68 [assignment: list of cryptographic operations] 69 [assignment: cryptographic algorithm] 70 [assignment: cryptographic key sizes] 71 [assignment: list of standards] 72 [assignment: list of cryptographic operations] 73 [assignment: cryptographic algorithm] 74 [assignment: cryptographic key sizes] 75 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 66/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction fulfilled FCS_COP.1.1/ SIG_VER_EAC1PP The TSF shall perform digital signature verification76 in accordance with a specified cryptographic algorithm ECDSA with plain signature format 77 and cryptographic key sizes 256, 320, 384 and 512 bit length group order 78 that meet the following: [EACTR]79. 359 FCS_COP.1/SIG_VER_EAC2PPCryptographic operation – Signature Verifi- cation Hierarchical to: No other components. Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] not fulfilled, but justi- fied: The root key PKCVCA (initialization data) used for verifying the DV Certificate is stored in the TOE during its personalization in the card issuing life cycle phase 7. Since importing the respective certifi- cates (Terminal Certificate, DV Certificate) does not require any special security measures except those required by the current SFR (cf. FMT_MTD.3 below), the EAC2PP does not contain any dedi- cated requirement like FDP_ITC.2 for the import function. FCS_CKM.4 Cryptographic key destruction fulfilled FCS_COP.1.1/SIG_VER_EAC2PP The TSF shall perform digital signature verification80 in accordance with a specified cryptographic algorithm ECDSA with plain signature format 81 and cryptographic key sizes 256, 320, 384 and 512 bit length group order 82 that meet the following: [EACTR]83. 360 FCS_COP.1/CA3 Cryptographic operation – CA3 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 FCS_CKM.4 Cryptographic key destruction fulfilled 76 [assignment: list of cryptographic operations] 77 [assignment: cryptographic algorithm] 78 [assignment: cryptographic key sizes] 79 [assignment: list of standards] 80 [assignment: list of cryptographic operations] 81 [assignment: cryptographic algorithm] 82 [assignment: cryptographic key sizes] 83 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 67/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FCS_COP.1.1/CA3 The TSF shall perform the Chip authentication 3 (CA3) protocol84 in accordance with a specified cryptographic algorithm CA385 and cryp- tographic key sizes 256, 320, 384, 512 bit86 that meet the following: TR03110-2-v2.21 [EACTR]87. 361 Application Note 40: Whereas FCS_CKM.1/CA3 addresses the Diffie-Hellman based key- derivation, this SFR is concerned with the correct implementation and execution of the whole CA3 protocol. This in particular includes pseudonymous signature generation with PSign [EACTR]. 362 FCS_COP.1/UPD_ITC Cryptographic operation – Inter Trusted Channel 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 FCS_CKM.4 Cryptographic key destruction fulfilled FCS_COP.1.1/UPD_ITC The TSF shall perform signature verification88 in accordance with a specified cryptographic algorithm EC-DSA89 and cryptographic key sizes 512 bit90 that meet the following: [ECCTR]91. 363 Application Note 41: The integrity of the trusted channel is protected by a digital signature over a hash value of chained MAC values computed during the update procedure. Only the curve BrainpoolP512T1 is used here. 364 FCS_COP.1/UPD_DEC Cryptographic operation – Decryption of Update Packages 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 FCS_CKM.4 Cryptographic key destruction fulfilled FCS_COP.1.1/UPD_DEC 84 [assignment: list of cryptographic operations] 85 [assignment: cryptographic algorithm] 86 [assignment: cryptographic key sizes] 87 [assignment: list of standards] 88 [assignment: list of cryptographic operations] 89 [assignment: cryptographic algorithm] 90 [assignment: cryptographic key sizes] 91 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 68/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall perform decryption of update packages92 in accord- ance with a specified cryptographic algorithm AES-256 in OFB mode93 and cryptographic key sizes 256 bit94 that meet the following: [FIPS197] and [SP800-38A]95. 365 FCS_COP.1/UPD_INT Cryptographic operation – Integrity Verification of Update Package 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 FCS_COP.1.1/UPD_INT The TSF shall perform integrity verification of update packages96 in accordance with a specified cryptographic algorithm SHA25697 and cryptographic key sizes none98 that meets the following: [FIPS197]99. 366 Application Note 42: The whole Update Package is protected by a digital signature of a hash value, and therefore no key is used here. 367 FCS_COP.1/UPD_SIG Cryptographic operation – Signature Verification of Update Packages 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 justified [MREDONPP] FCS_CKM.4 Cryptographic key destruction not fulfilled but justified [MREDONPP] FCS_COP.1.1/UPD_SIG The TSF shall perform digital signature verification100 in accordance with a specified cryptographic algorithm EC-DSA101 and cryptogra- phic key sizes 512 bit102 that meet the following: [TCOSGD]103. 92 [assignment: list of cryptographic operations] 93 [assignment: cryptographic algorithm] 94 [assignment: cryptographic key sizes] 95 [assignment: list of standards] 96 [assignment: list of cryptographic operations] 97 [assignment: cryptographic algorithm] 98 [assignment: cryptographic key sizes] 99 [assignment: list of standards] 100 [assignment: list of cryptographic operations] 101 [assignment: cryptographic algorithm] 102 [assignment: cryptographic key sizes] 103 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 69/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 368 Application Note 43: Only the curve BrainpoolP512T1 is used here. 369 FCS_COP.1/SSCDPP Cryptographic operation – Qualified Signature Creation 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 FCS_CKM.4 Cryptographic key destruction fulfilled FCS_COP.1.1/SSCDPP The TSF shall perform digital signature generation104 in accordance with a specified cryptographic algorithm EC-DSA compliant to [EC- CTR]105 and cryptographic key sizes 256, 320, 384 and 512 bit length group order106 that meet the following: [ECCTR]107. 370 FCS_RND.1/EAC2PP Random number generation Hierarchical to: No other components. Dependencies: No dependencies. FCS_RND.1.1/EAC2PP The TSF shall provide a mechanism to generate random numbers that meet the requirements of a DRG.4 (DRG.4.1) The internal state of the RNG shall use PTRNG of class PTG.2 as random source. (DRG.4.2) The RNG provides forward secrecy. (DRG.4.3) The RNG provides backward secrecy even if the current internal state is known. (DRG.4.4) The RNG provides enhanced forward secrecy on condi- tion “session closed or aborted”. (DRG.4.5) The internal state of the RNG is seeded by a PTRNG of class PTG.2. (DRG.4.6) The RNG generates output for which k > 234 strings of bit length 128 are mutually different with probability 1−ε, with ε < 2-16. (DRG.4.7) Statistical test suites cannot practically distinguish the random numbers from output sequences of an ideal RNG. 104 [assignment: list of cryptographic operations] 105 [assignment: cryptographic algorithm] 106 [assignment: cryptographic key sizes]/[selection: 128, 192, 256] bit 107 [assignment: list of standards] Security Target TCOS ID Version 2.0 Release 1/P6022y 70/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The random numbers must pass test procedure A, the NIST and the dieharder108 tests.109 371 Application Note 44: The DRG.4 is seeded and re-seeded using the random number gen- erator PTRNG of the hardware, providing herewith forward and backward secrecy. 6.1.4 Class FIA Identification and Authentication 372 The following Table provides an overview of the authentication and identification mecha- nisms used. 373 The following SFRs are imported due to claiming [EAC2PP]. They mainly concern authen- tication mechanisms related to applications with EAC2-protected data. • FIA_AFL.1/Suspend_PIN_EAC2PP • FIA_AFL.1/Block_PIN_EAC2PP • FIA_API.1/CA_EAC2PP • FIA_API.1/RI_EAC2PP • FIA_UID.1/PACE_EAC2PP • FIA_UID.1/EAC2_Terminal_EAC2PP 374 Application Note 45: The user identified after a successfully performed TA2 protocol is an EAC2 terminal. Note that TA1 is covered by FIA_UID.1/PACE_EAC1PP. In that case, the terminal identified is in addition also an EAC1 terminal. • FIA_UAU.1/PACE_EAC2PP • FIA_UAU.1/EAC2_Terminal_EAC2PP • FIA_UAU.4/PACE_EAC2PP • FIA_UAU.5/PACE_EAC2PP • FIA_UAU.6/CA_EAC2PP • FIA_AFL.1/PACE_EAC2PP • FIA_UAU.6/PACE_EAC2PP 375 The following SFRs are imported due to claiming [EAC1PP]. They mainly concern authen- tication mechanisms for applications with EAC1-protected data. • FIA_UID.1/PACE_EAC1PP • FIA_UAU.1/PACE_EAC1PP • FIA_UAU.4/PACE_EAC1PP • FIA_UAU.5/PACE_EAC1PP • FIA_UAU.6/PACE_EAC1PP (equivalent to FIA_UAU.6/PACE_EAC2PP, listed here only for the sake of completeness) • FIA_UAU.6/EAC_EAC1PP • FIA_API.1/EAC1PP • FIA_AFL.1/PACE_EAC1PP (equivalent to FIA_AFL.1/PACE_EAC2PP, listed here only for the sake of completeness) 376 The following SFRs are defined in [MREDPP] and concern enhancements of [EAC2PP] (Chip Authentication 3). • FIA_API.1/CA3 108 The selected here test suites http://csrc.nist.gov/groups/ST/toolkit/rng/documents/sts-2.1.1.zip and http://www.phy.duke.edu/~rgb/General/dieharder/dieharder-3.31.0.tgz are available at NIST and Dieharder web sites. Note that the dieharder tests include Marsaglia’s “Diehard battery of tests” and NIST tests. 109 [assignment: a defined quality metric] Security Target TCOS ID Version 2.0 Release 1/P6022y 71/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 • FIA_API.1/PACE_CAM • FIA_UAU.6/CA3 377 The following SFRs are imported due to claiming [MREDONPP]. • FIA_AFL.1/UPD • FIA_UAU.1/UPD • FIA_UID.1/UPD 378 The following SFRs are imported due to claiming [SSCDPP]. They concern access mech- anisms for an eSign application, if available. • FIA_UID.1/SSCDPP • FIA_AFL.1/SSCDPP 379 FIA_AFL.1/Suspend_PIN_EAC2PP Authentication failure handling – Sus- pending PIN Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/PACE FIA_AFL.1.1/Suspend_PIN_EAC2PP The TSF shall detect when an administrator configurable positive integer sad within the range 1 ≤ sad ≤ 6 according to [TCOSGD]110 unsuccessful authentication attempts occur related to consecutive failed authentication attempts using PIN as the shared password for PACE111. FIA_AFL.1.2/Suspend_PIN_EAC2PP When the defined number of unsuccessful authentication attempts has been met112, the TSF shall suspend the reference value of PIN according to [EACTR-2]113. 380 According to [EACTR] at least the current value 1 of the retry counter for PIN shall be a suspending value, i.e. if this value is reached the PIN must be suspended. Nev- ertheless the administrator may select a different suspending value and a corre- sponding initial value. The assignment must be according with requirements given in [TCOSGD]. 381 FIA_AFL.1/Block_PIN_EAC2PPAuthentication failure handling – Blocking PIN Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/PACE FIA_AFL.1.1/Block_PIN_EAC2PP 110 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 111 [assignment: list of authentication events] 112 [selection: met, surpassed] 113 [assignment: list of actions] Security Target TCOS ID Version 2.0 Release 1/P6022y 72/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall detect when an administrator configurable positive in- teger bad within the range 1 ≤ bad ≤ 3 according [TCOSGD]114 un- successful authentication attempts occur related to consecutive failed authentication attempts using suspended PIN as the shared password for PACE115. FIA_AFL.1.2/Block_PIN_EAC2PP When the defined number of unsuccessful authentication attempts has been met116, the TSF shall block the reference value of PIN ac- cording to [EACTR-2]117. 382 Application Note 46: According to [EACTR-2], the 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 PIN shall be RC = 0. Nevertheless the administrator may configure the TOE such that it suspends already the PIN if the retry counter reaches the value bad. The assignment shall be consistent with the implemented authentication mechanism and resistant against attacks with high attack potential. No more than bad + sad ≤ 9 overall tries of the PIN are allowed. 383 FIA_AFL.1/PACE_EAC2PP Authentication failure handling – PACE au- thentication using non-blocking authentication/authorization data Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/PACE FIA_AFL.1.1/PACE_EAC2PP The TSF shall detect when 1118 unsuccessful authentication at- tempts occurs related to authentication attempts using PACE pass- word as shared password119. FIA_AFL.1.2/PACE_EAC2PP When the defined number of unsuccessful authentication attempts has been met120, the TSF shall require the restart of the PACE pro- tocol; and the TSF will increase the reaction time to the next au- thentication attempt121. 384 Application Note 47: The assignment operation reflects the fact that according the imple- mentation the authentication procedure consumes a defined minimal amount of time. Be- cause MRZ and PUK possesses enough entropy for this reaction time (cf. Administrator Guidance [TCOSGD]), this is sufficient even to prevent a brute force attack with attack potential beyond high (to recover a random 9 digit number would require already about 30 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] 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 ID Version 2.0 Release 1/P6022y 73/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 years). Since the CAN does not represent a secret, because it may be revealed already to external entities, it might be not necessary to consider a brute force attack against the CAN. The waiting time after power-up is sufficient to prevent the skimming of the TOE even for a random 6 digit CAN value if the Attacker does not know the CAN. 385 Application Note 48: The TOE detects any unsuccessful authentication attempt. After a administrator configurable number of authentication failures with the CAN has been met, the TSF adds an extra time before it allows for the next PACE run with the CAN (cf. [TCOSGD]). 386 FIA_AFL.1/UPD Update Package Verification Failure Handling Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/UPD FIA_AFL.1.1/UPD The TSF shall detect when 1122 unsuccessful authentication update attempts occurs related to mutual authentication of the TCOS up- date procedure123. FIA_AFL.1.2/UPD When the defined number of unsuccessful authentication update attempts has been met124, the TSF shall require the restart of the update procedure125. 387 Application Note 49: The above SFR is slightly refined here by replacing 'authentication' with 'update'. In addition, the second assignment is made more precise. An update attempt includes authentication of the update terminal to the TOE. However, when a properly au- thenticated terminal sends an update package that is not authentic or whose integrity can- not be validated, this is still a failed update attempt and the TOE handles it according to the above SFR. Hence, this refinement is stricter than the original SFR definition. 388 FIA_API.1/CA_EAC2PP Authentication Proof of Identity Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1/CA_EAC2PP The TSF shall provide the Chip Authentication Protocol according to [EACTR-2 Version 2 (for GAP)126 to prove the identity of the TOE127. 122 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 123 [assignment: list of authentication events of the update procedure] 124 [selection: met, surpassed] 125 [assignment: list of actions] 126 [assignment: authentication mechanism] 127 [assignment: authorized user or role] Security Target TCOS ID Version 2.0 Release 1/P6022y 74/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 389 Application Note 50: The Chip Authentication shall be triggered by the terminal immedi- ately after the successful Terminal Authentication (as required FIA_UAU.1/EAC2_Termi- nal_EAC2PP) using, amongst other, H(ephem-PKPCD-TA) from the accomplished TA. The terminal verifies genuineness of the ID Card by verifying the authentication token TPICC calculated by the TOE using ephem-PKPCD-TA and CA-KMAC, (and, hence, fi- nally making evident possessing the Chip Authentication Key (SKPICC)). 390 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 Authentication and is considered to be part of the CA Protocol (see also P.Terminal). 391 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 TOE’s identity. If the Chip Authentication was successfully performed, Secure Messaging is restarted us- ing the derived session keys (CA-KMAC, CA-KEnc), cf. FTP_ITC.1/CA_\ EAC2PP. Oth- erwise, Secure Messaging is continued using the previously established session keys (PACE-KMAC, PACE-KEnc), cf. FTP_ITC.1/PACE. 392 Please note that the Chip Authentication Protocol according to [EACTR-2, 3.3], version 1 (for AIP) is covered by FIA_API.1 there. 393 FIA_API.1/CA3 Authentication Proof of Identity Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1/CA3 The TSF shall provide the protocol Chip Authentication 3 according to [EACTR-2]128 to prove the identity of the TOE129. 394 FIA_API.1/PACE_CAM Authentication Proof of Identity Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1/CAM The TSF shall provide the protocol PACE-CAM [ICAO9303]130, to prove the identity of the TOE131. 395 FIA_API.1/RI_EAC2PP Authentication Proof of Identity Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1/RI_EAC2PP 128 [assignment: authentication mechanism] 129 [assignment: authorized user or role] 130 [assignment: authentication mechanism] 131 [assignment: authorized user or role] Security Target TCOS ID Version 2.0 Release 1/P6022y 75/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall provide the Restricted Identification protocol accord- ing to [EACTR-2]132 to prove the identity of the TOE133. 396 Application Note 51: The Restricted Identification provides a sector-specific identifier of every electronic document. It thus provides a pseudonymous way to identify the electronic document holder in a case where the CHAT of the terminal does not allow to access sen- sitive user data that directly identify the electronic document holder. Restricted Identifica- tion shall only be used after successfully running Terminal Authentication 2 and Chip Au- thentication 2. Note that Restricted Identification is optional according to [EACTR-2], and thus the above SFR only applies if Restricted Identification is supported by the TOE. 397 FIA_API.1/EAC1PP Authentication Proof of Identity Hierarchical to: No other components. Dependencies: No dependencies. FIA_API.1.1/EAC1PP The TSF shall provide the Chip Authentication Protocol according to [EACTR-2]134 to prove the identity of the TOE135. 398 Application Note 52: In [EACTR-2, 3.3] the Chip Authentication Mechanism 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 protocol properly using its Chip Authentication Private Key corresponding to the Chip Authentication Key (EF.DG14). 399 FIA_UID.1/PACE_EAC2PPTiming of identification 400 This SFR is refined from [EAC1PP]. Refinements address the PACE-CAM protocol. Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1/PACE_EAC2PP The TSF shall allow 1. to establishing a communication channel, 2. carrying out the PACE Protocol according to [EACTR-2], 3. to read the Initialization Data if it is not disabled by TSF ac- cording to FMT_MTD.1/INI_DIS, 4. none 136. on behalf of the user to be performed before the user is identified. FIA_UID.1.2/PACE_EAC2PP The TSF shall require each user to be successfully identified befo- re allowing any other TSF-mediated actions on behalf of that user. 132 [assignment: authentication mechanism] 133 [assignment: authorized user or role] 134 [assignment: authentication mechanism] 135 [assignment: authorized user or role] 136 [assignment: list of TSF-mediated actions] Security Target TCOS ID Version 2.0 Release 1/P6022y 76/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 401 Application Note 53: The user identified after a successful run of PACE is a PACE terminal. In case the PIN or PUK were used for PACE, the user identified is the electronic document holder using a PACE terminal. Note that neither the CAN nor the MRZ effectively represent secrets, but are restricted-revealable; i.e. in case the CAN or the MRZ were used for PACE, it is either the electronic document holder itself, an authorized person other than the electronic document holder, or a device. 402 FIA_UID.1/EAC2_Terminal_EAC2PP Timing of identification Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1/EAC2_Terminal_EAC2PP The TSF shall allow 1. to establish a communication channel, 2. carrying out the PACE protocol according to [EACTR-2], 3. to read the Initialization Data if it is not disabled by TSF ac- cording to FMT_MTD.1/INI_DIS , 4. carrying out the Terminal Authentication Protocol 2 protocol according to [EACTR-2] 5. none137. on behalf of the user to be performed before the user is identified. FIA_UID.1.2/EAC2_Terminal_EAC2PP The TSF shall require each user to be successfully identified be- fore allowing any other TSF-mediated actions on behalf of that user. 403 Application Note 54: The user identified after a successfully performed TA protocol is a terminal for GAP: either EIS-GAP or ATT or SGT. 404 Please note that the Terminal Authentication Protocol according to [EACTR-2, 3.4], version 1 (for AIP) is covered by [EAC2PP] (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. 405 Application Note 55: 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. 406 Please note that a Personalization Agent acts on behalf of the Card issuer under his and CSCA and DS policies. Hence, they define authentication procedure(s) for Personalization 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-3, C.4, Table 21]. 407 FIA_UID.1/PACE_EAC1PP Timing of identification 408 This SFR is refined from [EAC1PP]. Refinements address the PACE-CAM protocol. 137 [assignment: list of TSF-mediated actions] Security Target TCOS ID Version 2.0 Release 1/P6022y 77/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1/PACE_EAC1PP The TSF shall allow 1. to establish a communication channel, 2. carrying out the PACE Protocol according to [EACTR-1], 3. to read the Initialization Data if it is not disabled by TSF ac- cording to FMT_MTD.1/INI_DIS, 4. to carry out either the Chip Authentication Protocol v.1 ac- cording to [EACTR-1] or the Chip Authentication Mapping (PACE-CAM) according to [ICAO9303], 5. to carry out the Terminal Authentication Protocol v.1 accord- ing to [EACTR-1] resp. according to [ICAO9303] if PACE- CAM is used 6. none138. on behalf of the user to be performed before the user is identified. FIA_UID.1.2/PACE_EAC1PP The TSF shall require each user to be successfully identified befo- re allowing any other TSF-mediated actions on behalf of that user. 409 Application Note 56: The user identified after a successfully performed PACE protocol is a PACE terminal (PCT). In case PIN or PUK were used for PACE, it is the ID_Card holder using PCT. Please note that neither CAN nor MRZ effectively represent secrets, but are restricted-revealable; i.e. in case CAN or MRZ were used for PACE, it is either the RP_Card holder itself or an authorized other person or device. 410 FIA_UAU.1/PACE_EAC2PP 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_EAC2PP The TSF shall allow 1. to establish a communication channel, 2. carrying out the PACE Protocol139 according to [EACTR-2] 3. to read the Initialization Data if it is not disabled by TSF accord- ing to FMT_MTD.1/INI_DIS 4. none140 on behalf of the user to be performed before the user is authenti- cated. FIA_UAU.1.2/PACE_EAC2PP 138 [assignment: list of TSF-mediated actions] 139 electronic document identifies themselves within the PACE protocol by selection of the authentication key ephem-PKPICC- PACE 140 [assignment: list of TSF-mediated actions] Security Target TCOS ID Version 2.0 Release 1/P6022y 78/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 411 Application Note 57: The user authenticated after a successfully performed PACE proto- col is a PACE terminal (PCT). In case PIN or 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. 412 FIA_UAU.1/EAC2_Terminal_EAC2PP Timing of authentication Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/EAC2_Ter- minal_EAC2PP. FIA_UAU.1.1/EAC2_Terminal_EAC2PP The TSF shall allow 1. establishing a communication channel, 2. carrying out the PACE protocol according to [EACTR-2, 3.2], 3. to read the Initialization Data if it is not disabled by TSF ac- cording to FMT_MTD.1/INI_DIS, 4. carrying out the Terminal Authentication Protocol 2 protocol according to [EACTR-2]141 on behalf of the user to be performed before the user is authenti- cated. FIA_UAU.1.2/EAC2_Terminal_EAC2PP The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 413 Application Note 58: The user authenticated after a successful run of TA2 is an EAC2 termi- nal. The authenticated terminal will immediately perform Chip Authentication 2 as required by FIA_API.1/CA using, amongst other, Comp(ephem-PKPCD-TA) from the accomplished TA2. Note that Passive Authentication using SOC is considered to be part of CA2 protocol. 414 FIA_UAU.1/PACE_EAC1PP 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_EAC1PP The TSF shall allow 1. establishing a communication channel, 2. carrying out the PACE Protocol142 according to [EACTR-1], 141 [assignment: list of TSF-mediated actions] 142 electronic document identifies themselves within the PACE protocol by selection of the authentication key ephem-PKPICC- PACE Security Target TCOS ID Version 2.0 Release 1/P6022y 79/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 3. to read the Initialization Data if it is not disabled by TSF ac- cording to FMT_MTD.1/INI_DIS, 4. to identify themselves by selection of the authentication key, 5. to carry out the Chip Authentication Protocol Version 1 accord- ing to [EACTR-1], 6. to carry out the Terminal Authentication Protocol Version 1 ac- cording to [EACTR-1] 7. none143 on behalf of the user to be performed before the user is authenti- cated. FIA_UAU.1.2/PACE_EAC1PP The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 415 FIA_UID.1/UPD Timing of identification Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1/UPD The TSF shall allow 1. to establish a communication channel, 2. to authenticate an update terminal by the PACE protocol ac- cording to [EACTR-1]144, 3. none145. on behalf of the user to be performed before the user is identified. FIA_UID.1.2/UPD The TSF shall require each user to be successfully identified befo- re allowing any other TSF-mediated actions on behalf of that user. 416 FIA_UAU.1/UPD Timing of authentication Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/UPD FIA_UAU.1.1/UPD The TSF shall allow 1. to establish a communication channel, 2. to authenticate an update terminal by the PACE protocol ac- cording to [EACTR-1]146, 3. none147. 143 [assignment: list of TSF-mediated actions] 144 [assignment: cryptographic method] 145 [assignment: list of TSF-mediated actions] 146 [assignment: cryptographic method] 147 [assignment: list of TSF-mediated actions] Security Target TCOS ID Version 2.0 Release 1/P6022y 80/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 on behalf of the user to be performed before the user is authenti- cated. FIA_UAU.1.2/UPD The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 417 FIA_UAU.4/PACE_EAC2PP Single-use authentication mechanisms - Sin- gle-use authentication of the Terminals by the TOE Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.4.1/PACE_EAC2PP The TSF shall prevent reuse of authentication data related to 1. PACE Protocol according to [EACTR-2, 3.2], 2. Authentication Mechanism based on AES148 3. Terminal Authentication 2 protocol according to [EACTR-2, 3.4], 4. none149. 418 Application Note 59: For the PACE protocol, the TOE randomly selects a nonce s of 128 bits Length being (almost) uniformly distributed. For the TA protocol, TOE randomly selects a nonce rPICC of 64 bits length, see [EACTR-3, B.3 and B.11.6]. 419 FIA_UAU.4/PACE_EAC1PP Single-use authentication mechanisms - Sin- gle-use authentication of the Terminals by the TOE Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.4.1/PACE_EAC1PP The TSF shall prevent reuse of authentication data related to 1. PACE Protocol according to [EACTR-1], 2. Authentication Mechanism based on AES150, 3. Terminal Authentication Protocol v1 according to [EACTR- 1]151. 420 FIA_UAU.5/PACE_EAC2PP Multiple authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.5.1/PACE_EAC2PP 148 [selection: Triple-DES , AES or other approved algorithms] 149 [assignment: identified authentication mechanism(s)] 150 [selection: Triple-DES, AES or other approved algorithms] 151 [assignment: identified authentication mechanism(s)] Security Target TCOS ID Version 2.0 Release 1/P6022y 81/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall provide 1. PACE protocol according to [EACTR-2], 2. Passive Authentication according to [ICAO9303], 3. Secure messaging in MAC-ENC mode according to [EACTR- 3] 4. Symmetric Authentication Mechanism based on AES152, 5. Terminal Authentication 2 protocol according to [EACTR-2], 6. Chip Authentication 2 according to [EACTR-2]153, 7. Chip Authentication 3 according to [EACTR-2-v2.20], 8. none 154 to support user authentication. FIA_UAU.5.2/PACE_EAC2PP The TSF shall authenticate any user’s claimed identity according to the following rules: 1. Having successfully run the PACE protocol the TOE accepts only received commands with correct message authentication codes sent by secure messaging with the key agreed with the terminal by the PACE protocol 2. The TOE accepts the authentication attempt as personalization agent by the Authentication Mechanism with Personalization Agent Key(s) 155 3. The TOE accepts the authentication attempt by means of the Terminal Authentication 2 protocol, only if (i) the terminal pre- sents its static public key PKPCD and the key is successfully veri- fiable up to the CVCA and (ii) the terminal uses the PICC identi- fier IDPICC = Comp(ephem-PKPICC-PACE) calculated during, and the secure messaging established by the, current PACE au- thentication, 4. Having successfully run Chip Authentication 2, the TOE accepts only received commands with correct message authentication codes sent by secure messaging with the key agreed with the terminal by Chip Authentication 2. 5. Having successfully run Chip Authentication 3, the TOE accepts only received commands with correct message authentication codes sent by secure messaging with the key agreed with the terminal by Chip Authentication 3, 6. none156. 421 Application Note 60: 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. 422 Please note that the Chip Authentication Protocol according to [EACTR-2, sec. 3.3], ver- sion 1 (for AIP) is covered in this context by [EAC1PP] (see FIA_UAU.5 there). 152 [selection: AES or other approved algorithms] 153 Passive Authentication using SOC is considered to be part of CA2 154 [assignment: list of multiple authentication mechanisms] 155 [selection: the Authentication Mechanism with Personalization Agent Key(s) ] 156 [assignment: rules describing how the multiple authentication mechanisms provide authentication] Security Target TCOS ID Version 2.0 Release 1/P6022y 82/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 423 Application Note 61: 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. 424 FIA_UAU.5/PACE_EAC1PP Multiple authentication mechanisms Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.5.1/PACE_EAC1PP The TSF shall provide 1. PACE Protocol and PACE-CAM protocol according to [ICAO9303], 2. Passive Authentication according to [ICAO9303], 3. Secure messaging in MAC-ENC mode according to [ICAO9303], 4. Symmetric Authentication Mechanism based on AES157 5. Terminal Authentication Protocol v.1 according to [EACTR-1] to support user authentication158. FIA_UAU.5.2/PACE_EAC1PP The TSF shall authenticate any user’s claimed identity according to the following rules: 1. Having successfully run the PACE protocol the TOE accepts only received commands with correct message authentication code sent by means of secure messaging with the key agreed with the terminal by means of the PACE protocol. 2. The TOE accepts the authentication attempt as Personalization Agent by the Authentication Mechanism with Personalization Agent Key(s)159. 3. After run of the Chip Authentication Protocol Version 1 the TOE accepts only received commands with correct message authen- tication code sent by means of secure messaging with key agreed with the terminal by means of the Chip Authentication Mechanism v1. 4. The TOE accepts the authentication attempt by means of the Terminal Authentication Protocol v.1 only if the terminal uses the public key presented during the Chip Authentication Proto- col v.1 and the secure messaging established by the Chip Au- thentication Mechanism v.1 , or if the terminal uses the pub- lic key presented during PACE-CAM and the secure mes- saging established during PACE160 5. none161. 157 [selection: Triple-DES, AES or other approved algorithms] 158 [assignment: list of multiple authentication mechanisms] 159 [selection: the Authentication Mechanism with Personalization Agent Key(s)] 160 [assignment: rules describing how the multiple authentication mechanisms provide authentication] 161 [assignment: rules describing how the multiple authentication mechanisms provide authentication] Security Target TCOS ID Version 2.0 Release 1/P6022y 83/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 425 Application Note 62: The included from the EAC1PP PP requirements FIA_UID.1/ EAC1PP, FIA_UAU.1/EAC1PP, FIA_UAU.4/EAC1PP, FIA_UAU.5/EAC1PP and FIA_\ API.1/EAC1PP are restricted to the application of an EIS-AIP-BAC terminal, which is the only type of a General Inspection System supporting Advanced Inspection Procedure ver- sion 1 with TDES considered in this ST. They are included in this ST only due to compat- ibility reasons and are not applicable to other authentication protocols. 426 The PP ([PACEPP]) 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. 427 FIA_UAU.6/CA3 Re-Authenticating of Terminal by the TOE Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.6.1/CA3 The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful run of the Chip Authenti- cation 3 shall be verified as being sent by the EAC2 terminal162. 428 FIA_UAU.6/CA_EAC2PP Re-authenticating – Re-authenticating of Terminal by the TOE Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.6.1/CA_EAC2PP The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful run of the Chip Authenti- cation 2 shall shall be verified as being sent by the EAC2 termi- nal163. 429 FIA_UAU.6/PACE_EAC2PP Re-authenticating – Re-authenticating of Ter- minal by the TOE Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.6.1/PACE_EAC2PP The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful run of the PACE proto- col shall be verified as being sent by the PACE terminal164. 430 Application Note 63: The PACE protocol specified in [EACTR] starts secure messaging used for all commands exchanged after successful PACE authentication. The TOE checks each command by secure messaging in encrypt-then-authenticate mode 162 [assignment: list of conditions under which re-authentication is required] 163 [assignment: list of conditions under which re-authentication is required] 164 [assignment: list of conditions under which re-authentication is required] Security Target TCOS ID Version 2.0 Release 1/P6022y 84/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 based on CMAC or Retail-MAC, whether it was sent by the successfully authenticated terminal (see FCS_COP.1/PACE_MAC for further details). The TOE does not execute any command with incorrect message authentication code. Therefore, the TOE re- authenticates the terminal connected, if a secure messaging error occurred, and ac- cepts only those commands received from the initially authenticated terminal. 431 FIA_UAU.6/EAC_EAC1PP Re-authenticating – Re-authenticating of Terminal by the TOE Hierarchical to: No other components. Dependencies: No dependencies. FIA_UAU.6.1/EAC_EAC1PP The TSF shall re-authenticate the user under the conditions each command sent to the TOE after successful run of the Chip Authenti- cation Protocol Version 1 shall be verified as being sent by the In- spection System165. 432 Application Note 64: The PACE and the Chip Authentication Protocols specified in [EACTR] include secure messaging for all commands exchanged after successful au- thentication of the Inspection System. The TOE checks by secure messaging in MAC_ENC mode each command based on a corresponding MAC algorithm whether it was sent by the successfully authenticated terminal (see FCS_COP.1/CA_MAC for further details). The TOE does not execute any command with incorrect message au- thentication code. Therefore the TOE re-authenticates the user for each received com- mand and accepts only those commands received from the previously authenticated user. 433 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: SFR identifier Equivalent to / covered by item in the ST Comments FIA_UAU.1/SSCDPP – This requirement concerns the dedicated authentication data for the eSign application like eSign-PIN and eSign- PUK, if any. FIA_UID.1/SSCDPP – This requirement concerns the dedicated authentication data for the eSign application like eSign-PIN and eSign- PUK, if any. FIA_AFL.1/SSCDPP – This requirement concerns the dedicated authentication data for the eSign application like eSign-PIN and eSign- PUK, if any. 434 FIA_UAU.1/SSCDPP Timing of authentication Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/SSCDPP, cf. [SSCDPP] 165 [assignment: list of conditions under which re-authentication is required] Security Target TCOS ID Version 2.0 Release 1/P6022y 85/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FIA_UAU.1.1/SSCDPP The TSF shall allow 1. self test according to FPT_TST.1/SSCDPP, 2. identification of the user by means of TSF required by FIA_UID.1/SSCDPP 3. establishing a trusted channel between CGA and the TOE by means of TSF required by FTP_ITC.1/CA_EAC2 and FTP_\ ITC.1/CA3 respectively166, 4. establishing a trusted channel between HID and the TOE by means of TSF required by FTP_ITC.1/CA_EAC2 and FTP_\ ITC.1/CA3 respectively 167, 5. none168 on behalf of the user to be performed before the user is authenti- cated. FIA_UAU.1.2/SSCDPP The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user. 435 FIA_UID.1/SSCDPP Timing of identification Hierarchical to: No other components. Dependencies: No dependencies. FIA_UID.1.1/SSCDPP The TSF shall allow 1. self test according to FPT_TST.1, 2. none 169 on behalf of the user to be performed before the user is identified. FIA_UID.1.2/SSCDPP The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. 436 FIA_AFL.1/SSCDPP Authentication failure handling Hierarchical to: No other components. Dependencies: FIA_UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/SSCDPP FIA_AFL.1.1/SSCDPP 166 the authenticated terminal is ATT, cf. FIA_UAU.1/EAC2_Terminal 167 the authenticated terminal is SGT, cf. FIA_UAU.1/EAC2_Terminal; the trusted channel by FTP_ITC.1/CA implements a trusted path between HID and the TOE 168 [assignment: list of (additional) TSF-mediated actions] 169 [assignment: list of additional TSF-mediated actions] Security Target TCOS ID Version 2.0 Release 1/P6022y 86/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall detect when an administrator configurable positive in- teger sigad within the range 1 ≤ sigad ≤ 9 according to [TCOSGD]170 unsuccessful authentication attempts occur related to consecutive failed authentication attemptsITC171. FIA_AFL.1.2/SSCDPP When the defined number of unsuccessful authentication attempts has been met172, the TSF shall block RAD173. 6.1.5 Class FDP User Data Protection 437 Multiple iterations of FDP_ACF.1 exist from imported PPs to define the access control SFPs for (common) user data, EAC1-protected user data, and EAC2-protected user data. The access control SFPs defined in FDP_ACF.1/EAC1PP from [EAC1PP] and FDP_ACF.1/EAC2PP from [EAC2PP] are here unified to one single FDP_ACF.1/TRM, whereas the several iterations of FDP_ACF.1 from [SSCDPP] stand separate. Here we take FDP_ACF.1/EAC2PP as a base definition of functional elements, and it is refined in a way that it is compatible with FDP_ACF.1/EAC1PP. Hence highlighting refers to changes w.r.t. to FDP_ACF.1/EAC2PP. In the Application Note below, we explain how FDP_ACF.1/EAC1PP is covered as well. 438 Concerning FDP_ACF.1/TRM here and the several iterations FDP_ACF.1 from [SSCDPP], we remark that FDP_ACF.1/TRM also concerns data and objects for signature generation. Note however, that FDP_ACF.1/TRM requires that prior to granting access to the signature application, in which the access controls defined in [SSCDPP] apply, an EAC2 terminal and the electronic document holder need to be authenticated. Hence, no inconsistency exist. 439 The following SFRs are imported due to claiming [EAC2PP]. They concern access control mechanisms related to EAC2-protected data. • FDP_ACC.1/TRM_EAC2PP This SFR is equivalent to/covered by FDP_ACC.1/TRM_EAC1PP; cf. the Application Note above. • FDP_ACF.1/TRM_EAC2PP This SFR is equivalent to/covered by FDP_ACF.1/TRM • FDP_RIP.1/EAC2PP • FDP_UCT.1/TRM_EAC2PP • FDP_UIT.1/TRM_EAC2PP 440 The following SFRs are imported due to claiming [EAC1PP]. They concern access control mechanisms related to EAC1-protected data. • FDP_ACC.1/TRM_EAC1PP The above is equivalent to FDP_ACC.1/TRM_EAC2PP, since EF.SOD (cf. FDP_ACC.1/TRM in [EAC1PP]) can be considered user data.; cf. also the Application Note below FDP_ACF.1/TRM. • FDP_ACF.1/TRM_EAC1PP The above is covered by FDP_ACF.1/TRM; cf. Applica- tion Note there. • FDP_RIP.1/EAC1PP 170 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]] 171 [assignment: list of authentication events] 172 [selection: met, surpassed] 173 [assignment: list of actions] Security Target TCOS ID Version 2.0 Release 1/P6022y 87/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 • FDP_UCT.1/TRM_EAC1PP (equivalent to FDP_UCT.1/TRM_EAC2PP, listed here only for the sake of completeness) • FDP_UIT.1/TRM_EAC1PP (equivalent to FDP_UIT.1/TRM_EAC2PP, listed here only for the sake of completeness) 441 The following SFRs are imported due to claiming [MREDONPP]. • FDP_ACC.1/UPD • FDP_ACF.1/UPD • FDP_IFC.1/UPD • FDP_IFF.1/UPD • FDP_RIP.1/UPD 442 The following SFRs are imported due to claiming [SSCDPP]. They concern access control mechanisms of an eSign application. • FDP_ACC.1/SCD/SVD_Generation_SSCDPP • FDP_ACF.1/SCD/SVD_Generation_SSCDPP • FDP_ACC.1/SVD_Transfer_SSCDPP • FDP_ACF.1/SVD_Transfer_SSCDPP • FDP_ACC.1/Signature-creation_SSCDPP • FDP_ACF.1/Signature-creation_SSCDPP • FDP_RIP.1/SSCDPP • FDP_SDI.2/Persistent_SSCDPP • FDP_SDI.2/DTBS_SSCDPP 443 FDP_ACF.1/TRM Security attribute based access control – Terminal Access Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control: fulfilled 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 personalization and fixed over the whole life time of the TOE. No management 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 Access Control SFP174 to objects based on the following: 1. Subjects: a. Terminal, b. PACE Terminal, c. EAC2 terminal: EIS, ATT, SGT 175 d. EAC1 terminal 2. Objects: a. all user data stored in the TOE; including sensitive EAC1-protected user data, and sensitive EAC2-pro- tected user data, 174 [assignment: access control SFP] 175 [assignment: list of EAC2 terminal types] Security Target TCOS ID Version 2.0 Release 1/P6022y 88/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 b. all TOE intrinsic secret (cryptographic) data 3. Security attributes: a. Terminal Authorization Level (access rights) b. Authentication status of the electronic document holder as a signatory (if an eSign application is included)176. FDP_ACF.1.2/TRM The TSF shall enforce the following rules to determine if an oper- ation among controlled subjects and controlled objects is al- lowed: A PACE terminal is allowed to read data objects from FDP_ACF.1/TRM after successful PACE authentication accord- ing to [EACTR-2] and/or [ICAO9303], as required by FIA_UAU.1/PACE177. FDP_ACF.1.3/TRM The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none178. FDP_ACF.1.4/TRM The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 1. Any terminal not being authenticated as a PACE terminal or an EAC2 terminal or an EAC1 terminal is not allowed to read, to write, to modify, to use any User Data stored on the electronic document. 2. Terminals not using secure messaging are not allowed to read, write, modify, or use any data stored on the electronic document. 3. No subject is allowed to read ‘Communication Establishment Authorization Data’ stored on the electronic document 4. No subject is allowed to write or modify ‘secret electronic document holder authentication data’ stored on the electronic document, except for PACE terminals or EAC2 terminals ex- ecuting PIN management based on the following rules: Change PIN, Resume PIN, Unblock PIN, Activate PIN, Deac- tivate PIN179 5. No subject is allowed to read, write, modify, or use the pri- vate Restricted Identification key(s) and Chip Authentication key(s) stored on the electronic document. 6. Reading, modifying, writing, or using sensitive user data that are protected only by EAC2, is allowed only to EAC2 ter- minals using the following mechanism: The TOE applies the EAC2 protocol (cf. FIA_UAU.5) to determine access rights of 176 [assignment: list of subjects and objects controlled under the indicated SFP, and. for each, the SFP-relevant security at- tributes, or named groups of SFP-relevant security attributes] 177 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on con- trolled objects] 178 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects] 179 [assignment: list of rules for PIN management chosen from [EACTR-2]]. Security Target TCOS ID Version 2.0 Release 1/P6022y 89/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 the terminal according to [EACTR-2] . To determine the ef- fective authorization of a terminal, the chip must calculate a bitwise Boolean ’and’ of the relative authorization contained in the CHAT of the Terminal Certificate, the referenced DV Certificate, and the referenced CVCA Certificate, and addi- tionally the confined authorization sent as part of PACE. Based on that effective authorization and the terminal type drawn from the CHAT of the Terminal Certificate, the TOE shall grant the right to read, modify or write sensitive user data, or perform operations using these sensitive user data. 7. No subject is allowed to read, write, modify or use the data objects 2b) of FDP_ACF.1.1/TRM. 8. No subject is allowed to read sensitive user data that are pro- tected only by EAC1, except an EAC1 terminal (OID inspec- tion system) after EAC1, cf. FIA_UAU.1/EAC1, that has a corresponding relative authorization level. This includes in particular EAC1-protected user data DG3 and DG4 from an ICAO-compliant ePass application, cf. [EACTR-1] and [ICAO9303]. 9. If sensitive user data is protected both by EAC1 and EAC2, no subject is allowed to read those data except EAC1 termi- nals or EAC2 terminals that access these data according to rule 6 or rule 8 above. 10. Nobody is allowed to read the private signature key(s) 180. 444 Application Note 65: The above definition is based on FDP_ACF.1/TRM_EAC2PP. We argue that it covers FDP_ACF.1/TRM_EAC1PP as well. Subject 1 b and 1 d are renamed here from FDP_ACF.1.1/TRM_EAC1PP according to Table 1. Objects in 2), in particular the term EAC1-protected user data, subsume all those explicitly enumerated in FDP_ACF.1.1/TRM_EAC1PP. Also the security attribute 3 a) Terminal Authorization Level here subsumes the explicitly enumerated attributes 3 a) and 3 b) of FDP_ACF.1.1/TRM_EAC1PP, but are semantically the same. Since in addition EAC2 pro- tected data are stored in the TOE of this PP, additional subjects, objects and security attributes are listed here. However since they apply to data with a different protection mechanism (EAC2), strict conformance is not violated.FDP_ACF.1.2/TRM uses the re- naming of Table 1, and references in addition [EACTR-2]. However the references are compatible as justified in [EAC2PP], yet both are mentioned here since [EACTR-2] is the primary norm for an eID application, whereas [ICAOSAC] is normative for an ICAO com- pliant ePass application. Investigating the references reveals that access to data objects defined in FDP_ACF.1.1/TRM must be granted if these data are neither EAC1-protected, nor EAC2-protected.FDP_ACF.1.3/TRM is the same as in FDP_ACF.1.3/ TRM_EAC2PP. 445 References are changed in FDP_ACF.1.2/TRM_EAC1PP. It is already justified in [EAC2PP] that definitions in [EACTR-2] and [ICAO9303] are compatible. 446 FDP_ACF.1.3/TRM is taken over from [EAC1PP] and [EAC2PP] (same formulation in both).Rules 1 and 2 of FDP_ACF.1.4/TRM_EAC1PP in [EAC1PP] are covered by their counterparts rule 1 and rule 2 here. Rules 3 and 4, and rule 6 of FDP_ACF.1.4/TRM_E\ AC1PP in [EAC1PP] are combined here to rule 8, where terminals need the corresponding CHAT to read data groups. Rule 5 of [EAC1PP] is here equivalent to rule 7. None of this conflicts with strict conformance to [EAC1PP]. Note that adding additional rules compared to FDP_ACF.1.4/TRM_EAC1PP here can never violate strict conformance, as these are 180 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] Security Target TCOS ID Version 2.0 Release 1/P6022y 90/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 rules that explicitly deny access of subjects to objects. Hence security is always increased. The above definition also covers FDP_ACF.1.1/TRM_EAC2PP and extends it by addi- tional subjects and objects. Sensitive user data in the definition of FDP_ACF.1.1/TRM_EAC2PP are here EAC2-protected sensitive user data. EAC1-pro- tected data are added here by refinement. Since the protection level and mechanisms elated to EAC2-protected data do not change, strict conformance is not violated. FDP_ACF.1.2/TRM_EAC2PP and FDP_ACF.1.3/TRM_EAC2PP are equivalent to the current definition. Rules 8, 9 and 10 are added here by open assignment from [EAC2PP]. None of this conflicts with strict conformance. The dependency of this SFR is met by FDP_ACC.1/TRM_EAC1PP and FDP_ACC.1/TRM_EAC2PP. Note that the SFR in [EAC1PP] applies the assignment operation, whereas in [EAC2PP] (by referencing [PACEPP]) the assignment is left open. Hence they are compatible. We remark that in order to restrict the access to user data as defined in the SFR FDP_ACC.1/TRM_\ EAC1PP, clearly access to objects 2 b) of FDP_ACF.1.1/TRM must be restricted as well according to the SFP, otherwise access to user data is impossible to enforce. 447 FDP_ACC.1/TRM_EAC2PP Subset access control – Terminal Access Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control: fulfilled FDP_ACC.1.1/TRM The TSF shall enforce the Access Control SFP 181 on terminals gaining access to the User Data and data stored in EF.SOD of the electronic document182. 448 Application Note 66: The Protection Profile [PACEPP] allows for extension to cover addi- tional security functionalities. This is not necessary here, as all security functionalities are covered by FDP_ACF.1/TRM. 449 FDP_RIP.1/EAC2PP Subset residual information protection Hierarchical to: No other components. Dependencies: No dependencies. FDP_RIP.1.1/EAC2PP The TSF shall ensure that any previous information content of a re- source is made unavailable upon the de-allocation of the resource from183 the following objects: 1. Session Keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA-KEnc) ( (immediately after closing related communication session) 2. the ephemeral private key ephem-SKPICC-PACE (by having generated a DH shared secret K184), 3. secret electronic document holder authentication data, e.g. PIN and/or PUK ( when their temporarily stored values are not used any more ), 181 [assignment: access control SFP] 182 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 183 [selection: allocation of the resource to, de-allocation of the resource from] 184 according to [EACTR-2] Security Target TCOS ID Version 2.0 Release 1/P6022y 91/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 4. none185. 450 Application Note 67: This SFR covers also FDP_RIP.1 from the [EAC1PP] despite this is not explicitly mentioned in [MREDPP]. 451 FDP_UCT.1/TRM_EAC2PP Basic data exchange confidentiality - MRTD 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 [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] not fulfilled but justified FDP_UCT.1.1/TRM_EAC2PP The TSF shall enforce the Access Control SFP186 to be able to transmit and receive187 user data in a manner protected from unau- thorized disclosure. 452 Application Note 68: The SFR FDP_UCT.1 requires the use of secure messaging between the MRTD and the Basic Inspection System. There is no need for SFR FTP_ITC.1, e.g. to require this communication channel to be logically distinct from other communication channels since there is only one channel. Since the TOE does not provide a direct human interface a trusted path as required by FTP_TRP.1 is also not applicable here. 453 FDP_UIT.1/TRM_EAC2PP Data Exchange Integrity 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 [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] not fulfilled but justified FDP_UIT.1.1/TRM_EAC2PP The TSF shall enforce the Access Control SFP188 to be able to transmit and receive189 user data in a manner protected from modi- fication, deletion, insertion and replay190 errors. FDP_UIT.1.2/TRM_EAC2PP The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion and replay191 has occurred. 454 Application Note 69: The SFR FDP_UIT.1 requires the use of secure messaging between the MRTD and the Basic Inspection System. There is no need for SFR FTP_ITC.1, e.g. to 185 [assignment: list of objects] 186 [assignment: access control SFP(s) and/or information flow control SFP(s)] 187 [selection: transmit, receive] 188 [assignment: access control SFP(s) and/or information flow control SFP(s)] 189 [selection: transmit, receive] 190 [selection: modification, deletion, insertion, replay] 191 [selection: modification, deletion, insertion, replay] Security Target TCOS ID Version 2.0 Release 1/P6022y 92/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 require this communication channel to be logically distinct from other communication channels since there is only one channel. Since the TOE does not provide a direct human interface a trusted path as required by FTP_TRP.1 is also not applicable here. 455 FDP_ACC.1/UPD Subset access control – Terminal Access Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control: fulfilled FDP_ACC.1.1/UPD The TSF shall enforce the Update Access Control SFP 192 on 1. Subjects: a. terminal, b. update terminal, 2. Objects: a. version information identifying the TOE software, b. update package c. update log information 3. Operations: a. reading out version information, b. reading out log data, c. uploading an update package, d. initiating an update procedure. and none193. 456 FDP_ACF.1/UPD Security attribute based access control – Terminal Access Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control: fulfilled FMT_MSA.3 Static attribute initialization: not fulfilled, but justified [MREDONPP] FDP_ACF.1.1/UPD The TSF shall enforce the Update Access Control SFP194 to objects based on the following: 1. Subjects: a. terminal, b. update terminal, 2. Objects: a. version information identifying the TOE software, b. update package c. update log information 3. Security attributes: 192 [assignment: access control SFP] 193 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 194 [assignment: access control SFP] Security Target TCOS ID Version 2.0 Release 1/P6022y 93/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 a. access rights 4. none 195. FDP_ACF.1.2/UPD The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: The authentication level of a terminal must be determined by the PACE protocol196 as required by FIA_UAU.1/UPD. Depending on the authentication level, an authenticated update terminal is allowed one or more of the following: • read one or more data objects from FDP_ACF.1/UPD • upload an update package to the TOE and initiate the update pro- cedure. The precise definition of access rights and how the authentication level is calculated from an authenticated terminal is defined in [TCOSGD] 197. FDP_ACF.1.3/UPD The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none198. FDP_ACF.1.4/UPD The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none199. 457 Application Note 70: Note that the write access to the TOE does not imply that the pack- age data will be accepted by the TOE and modifies afterwards the User Data. 458 FDP_IFC.1/UPD Subset information flow control Hierarchical to: No other components. Dependencies: FDP_IFF.1/UPD Simple security attributes: fulfilled FDP_IFC.1.1/UPD The TSF shall enforce the Update Flow Control SFP200 on the follow- ing: 1. Subjects: a. terminal, b. update terminal, 2. information: a. update package, 195 [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] 196 [assignment: list of technical specifications of cryptographic procedures] 197 [assignment: list of technical specifications of cryptographic procedures] 198 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects] 199 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 200 [assignment: access control SFP] Security Target TCOS ID Version 2.0 Release 1/P6022y 94/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 b. update data, c. meta-data, such as version information 3. operations: a. performing an update201. 459 FDP_IFF.1/UPD Simple security attributes Hierarchical to: No other components. Dependencies: FDP_IFC.1/UPD Simple security attributes: fulfilled MT_MSA.3 Static attribute initialization: not fulfilled, but justified: The update control TSF according to FDP_IFF.1/UPD uses security attributes that have been defined during personalization, and that are fixed over the whole life time of the TOE. No management of these security attributes (i.e. SFR FMT_MSA.1 and FMT_MSA.3) is necessary here. FDP_IFF.1.1/UPD The TSF shall enforce the Update Control SFP202 on based on the fol- lowing types of subject and information security attributes: 1. Subjects: a. terminal, b. update terminal, 2. information: a. update package, b. update data, c. meta-data, such as version information 3. security attributes: a. update package verification status with the values: NOT VERI- FIED (default status), SUCCESSFULLY VERIFIED, and VERI- FICATION FAILED203. FDP_IFF.1.2/UPD The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: 1. The terminal has established a secure channel with the TOE. 2. The TOE shall only accept update packages sent via a secure channel established with an authenticated update terminal204. FDP_IFF.1.3/UPD The TSF shall enforce the following rules in their specific order: 201 [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] 202 [assignment: information flow control SFP] 203 [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] 204 [assignment: for each operation, the security attribute-based relationship that must hold between subject and information secu- rity attributes] Security Target TCOS ID Version 2.0 Release 1/P6022y 95/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 1. The integrity (using the keyed or unkeyed hash function cf. FCS_COP.1/UPD_INT) and authenticity (using the digital signa- ture, cf. FCS_COP.1/UPD_SIG) of the first part of the update package is verified. If the integrity and authenticity are not both validated, abort with VERIFICATION FAILED, and erase all data transferred so far, cf. FDP_RIP.1. 2. The first part of the update package is only decrypted, cf. FCS_COP.1/UPD_DEC, if the integrity and authenticity of the that part has been verified in rule 1. If the decryption fails, abort with VERIFICATION FAILED, and erase all data transferred so far, cf. FDP_RIP.1. 3. If all parts of the update package have been decrypted, continue with rule 4. Otherwise, apply rules 1. and 2. on the remaining parts (replace 'first part' with 'current part' above) until either all parts have been decrypted, or the procedure has been aborted with VERIFICATION FAILED. 4. If additional meta-data is stored in the update package as speci- fied in the TCOS update procedure according to [TCOSGD] 205 is not verified as correct according to [TCOSGD]206 the security at- tribute is set to VERIFICATION FAILED and the update package including all associated data are destroyed, cf. FDP_RIP.1. Cor- rectness w.r.t. the referenced technical specification must not con- tradict any of the given rules here. 5. Next, the TSF shall verify that: a. the version number of the update package must be greater than the version of the installed corresponding software package; b. the update data are suitable to the specific TOE configura- tion/platform by checking relevant meta-data ( i.e. TOE product identifier, version number etc.). If all conditions in step 5 are verified, the verification status is set to SUCCESSFULLY VERIFIED. Otherwise abort with VERIFICATION FAILED, and erase all data transferred so far, cf. FDP_RIP.1. Only if the verification status is SUCCESSFULLY VERIFIED, the TOE shall install the update data207. FDP_IFF.1.4/UPD The TSF shall explicitly authorize an information flow based on the fol- lowing rules: none208. FDP_IFF.1.5/UPD The TSF shall explicitly deny an information flow based on the follow- ing rules: none209. 460 FDP_RIP.1/UPD Subset residual information protection Hierarchical to: No other components. 205 [assignment: list of meta-data contained in the update package or reference to technical specification(s) defining those] 206 [assignment: technical specification(s) defining correct form and content of meta-data] 207 [assignment: additional information flow control SFP rules] 208 [assignment: rules, based on security attributes, that explicitly authorize information flows ] 209 [assignment: rules, based on security attributes, that explicitly deny information flows ] Security Target TCOS ID Version 2.0 Release 1/P6022y 96/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 Dependencies: No dependencies. FDP_RIP.1.1/UPD The TSF shall ensure that any previous information content of a re- source is made unavailable upon the de-allocation of the resource from210 the following objects: 1. Session Keys (immediately after closing related communication session) 2. all ephemeral keys of the TCOS Update Procedue: Kauth , Kenc, KMAC (cf. [TCOSGD])211 related to the update mechanism, 3. Update package, decrypted update data and meta-data up- loaded to the TOE or generated during the update procedure, 4. none212. 461 Application Note 71: The functional family FDP_RIP possesses such a general character, so that it is applicable not only to user data (as assumed by the class FDP), but also to TSF-data; in this respect it is similar to the functional family FPT_EMS. Applied to crypto- graphic keys, FDP_RIP.1 requires a certain quality metric (‘any previous information con- tent of a resource is made unavailable’) for key destruction in addition to FCS_CKM.4 that merely requires a fact of key destruction according to a method/standard. The three ephemeral keys : Kauth, Kenc, KMAC of the TCOS Update Procedure are not accessible later and will be over-written with new key data during the next update. 462 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_SSCDPP FDP_ACF.1/SCD/SVD_Generation_SSCDPP FDP_ACC.1/SVD_Transfer_SSCDPP FDP_ACF.1/SVD_Transfer_SSCDPP FDP_ACC.1/Signature-creation_SSCDPP FDP_ACF.1/Signature-creation_SSCDPP FDP_RIP.1/SSCDPP FDP_RIP.1 contributes to achievement of OT.Sigy_SigF (eSign-PIN) and OT.SCD_Se- crecy (SCD) FDP_SDI.2/Persistent_SSCDPP FDP_SDI.2/DTBS_SSCDPP 463 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: 210 [selection: allocation of the resource to, de-allocation of the resource from] 211 [assignment: listof ephemeral keys or reference to specification] 212 [assignment: list of objects] Security Target TCOS ID Version 2.0 Release 1/P6022y 97/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 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 464 Application Note 72: 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 initi- ated by R.Admin and cannot be changed later. The default value of the security attribute SCD Identifier is “NULL” (not assigned/not linked), i.e. the management function men- tioned in no. 4 of FMT_SMF.1.1 is in fact an assignment and not really a change. 465 FDP_ACC.1/SCD/SVD_Generation_SSCDPP 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_SSCDPP. FDP_ACC.1.1/SCD/SVD_Generation_SSCDPP The TSF shall enforce the SCD/SVD Generation SFP213 on 1. subjects: S.User 2. objects: SCD, SVD 3. operations: generation of SCD/SVD pair214. 466 FDP_ACF.1/SCD/SVD_Generation_SSCDPP Security attribute based ac- cess control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control: fulfilled by FDP_ACC.1/SCD/SVD_Generation_SSCDPP, FMT_MSA.3 Static attribute initialization: control: fulfilled by FMT_MSA.3/SSCDPP FDP_ACF.1.1/SCD/SVD_Generation_SSCDPP The TSF shall enforce the SCD/SVD_Generation_SFP215 to ob- jects based on the following: the user S.User is associated with the security attribute “SCD/SVD Management“216. FDP_ACF.1.2/SCD/SVD_Generation_SSCDPP The TSF shall enforce the following rules to determine if an oper- ation among controlled subjects and controlled objects is al- lowed: 213 [assignment: access control SFP] 214 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 215 [assignment: access control SFP] 216 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] Security Target TCOS ID Version 2.0 Release 1/P6022y 98/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 S.User with the security attribute “SCD/SVD Management” set to “authorized” is allowed to generate SCD/SVD pair217. FDP_ACF.1.3/SCD/SVD_Generation_SSCDPP The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none218. FDP_ACF.1.4/SCD/SVD_Generation_SSCDPP 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 pair219. 467 FDP_ACC.1/SVD_Transfer_SSCDPP Subset access control Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control: fulfilled by FDP_ACF.1/SVD_Transfer_SSCDPP FDP_ACC.1.1/SVD_Transfer_SSCD The TSF shall enforce the SVD_Transfer_SFP220 on 1. subjects: S.User, 2. objects: SVD, 3. operations: export221. 468 FDP_ACF.1/SVD_Transfer_SSCDPP Security attribute based ac- cess control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control: fulfilled by FDP_ACF.1/SVD_ Transfer_SSCDPP, FMT_MSA.3 Static attribute initialization: fulfilled by FMT_MSA.3/SSCDPP FDP_ACF.1.1/SVD_Transfer_SSCDPP The TSF shall enforce the SVD_Transfer_SFP222 to objects ba- sed on the following: 1. the S.User is associated with the security attribute Role, 2. the SVD223. 217 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 218 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects] 219 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 220 [assignment: access control SFP] 221 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] 222 [assignment: access control SFP] 223 [assignment: list of subjects and objects controlled under the indicated SFP, and. for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes] Security Target TCOS ID Version 2.0 Release 1/P6022y 99/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FDP_ACF.1.2/SVD_Transfer_SSCDPP The TSF shall enforce the following rules to determine if an oper- ation among controlled subjects and controlled objects is al- lowed: R.Admin 224 is allowed to export SVD225. FDP_ACF.1.3/SVD_Transfer_SSCDPP The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none226. FDP_ACF.1.4/SVD_Transfer_SSCDPP The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none227. 469 FDP_ACC.1/Signature_Creation_SSCDPP Subset access control Hierarchical to: No other components. Dependencies: FDP_ACF.1 Security attribute based access control: fulfilled by FDP_ACC.1/Signature_Creation_SSCDPP FDP_ACC.1.1/Signature-creation_SSCDPP The TSF shall enforce the Signature-creation_SFP228 on 1. subjects: S.User, 2. objects: DTBS/R, SCD, 3. operations: signature-creation229. 470 FDP_ACF.1/Signature_Creation_SSCDPP Security attribute based ac- cess control Hierarchical to: No other components. Dependencies: FDP_ACC.1 Subset access control: fulfilled by FDP_ACC.1/Signa- ture_Creation_SSCDPP, FMT_MSA.3 Static attribute initialization: fulfilled by FMT_MSA.3/ SSCD FDP_ACF.1.1/Signature-creation_SSCDPP 224 [selection: R.Admin, R.Sigy ] 225 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 226 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects] 227 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 228 [assignment: access control SFP] 229 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP] Security Target TCOS ID Version 2.0 Release 1/P6022y 100/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall enforce the Signature-creation_SFP230 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”231. FDP_ACF.1.2/Signature-creation_SSCDPP The TSF shall enforce the following rules to determine if an oper- ation 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 232. FDP_ACF.1.3/Signature-creation_SSCDPP The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: none233. FDP_ACF.1.4/Signature-creation_SSCDPP 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”234. 471 FDP_SDI.2/Persistent_SSCDPP Stored data integrity monitoring and ac- tion Hierarchical to: FDP_SDI.1 Stored data integrity monitoring Dependencies: No dependencies FDP_SDI.2.1/Persistent_SSCDPP The TSF shall monitor user data stored in containers controlled by the TSF for integrity error235 on all objects, based on the fol- lowing attributes: integrity checked stored data236. FDP_SDI.2.2/Persistent_SSCDPP 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 error237. 230 [assignment: access control SFP] 231 [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] 232 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects] 233 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects] 234 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 235 [assignment: integrity errors] 236 [assignment: user data attributes] 237 [assignment: action to be taken] Security Target TCOS ID Version 2.0 Release 1/P6022y 101/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 472 FDP_SDI.2/DTBS_SSCDPP Stored data integrity monitoring and action Hierarchical to: FDP_SDI.1 Stored data integrity monitoring Dependencies: No dependencies FDP_SDI.2.1/DTBS_SSCDPP The TSF shall monitor user data stored in containers controlled by the TSF for integrity error238 on all objects, based on the fol- lowing attributes: integrity checked stored DTBS239. FDP_SDI.2.2/DTBS_SSCDPP 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 error240. 473 FDP_RIP.1/SSCDPP Subset residual information protection Hierarchical to: No other components. Dependencies: No dependencies. FDP_RIP.1.1/SSCDPP The TSF shall ensure that any previous information content of a re- source is made unavailable upon the de-allocation of the resource from241 the following objects: SCD242. 474 Application Note 73: 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. 6.1.6 Class FMT Security Management 475 FMT_SMR.1 Security roles Hierarchical to: No other components. Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/ PACE_EAC1PP, FIA_UID.1/PACE_EAC2PP, FIA_UID.1/EAC2_\ Terminal_EAC2PP, see also the Application Note below. FMT_SMR.1.1 238 [assignment: integrity errors] 239 [assignment: user data attributes] 240 [assignment: action to be taken] 241 [selection: allocation of the resource to, de-allocation of the resource from] 242 [assignment: list of objects] Security Target TCOS ID Version 2.0 Release 1/P6022y 102/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall maintain the roles 1. Manufacturer, 2. Personalization Agent, 3. Country Verifying Certification Authority, 4. Document Verifier, 5. Terminal, 6. PACE terminal, 7. EAC2 terminal, if the eID, ePassport and/or eSign application are active, 8. EAC1 terminal, if the ePassort application is active, 9. Electronic document holder243 . FMT_SMR.1.2 The TSF shall be able to associate users with roles. 476 The following SFRs are defined in [MREDPP]. They concern loading applications onto the IC during manufacturing and relate directly to OT.Cap_Avail_Loader. 477 FMT_LIM.1/Loader Limited Capabilities Hierarchical to: No other components. Dependencies: FMT_LIM.2 Limited availability: fulfilled by FMT_LIM.2. FMT_LIM.1.1/Loader The TSF shall be designed and implemented in a manner that limits their capabilities so that in conjunction with ‘Limited availability (FMT_LIM.2)’ the following policy is enforced: Deploying Loader func- tionality after TOE Delivery244 does not allow stored user data to be disclosed or manipulated by unauthorized users245 478 Application Note 74: FMT_LIM.1/Loader supplements FMT_LIM.2/Loader allowing for non-overlapping loading of user data and protecting the TSF against misuses of the Loader for attacks against the TSF. The TOE Loader may allow for correction of already loaded user data before the assigned action e.g. before blocking the TOE Loader for TOE Delivery to the end-customer or any intermediate step on the life cycle of the Security IC or the smartcard. 479 FMT_LIM.2/Loader Limited Availability Hierarchical to: No other components. Dependencies: FMT_LIM.1 Limited capabilities: fulfilled by FMT_LIM.1. FMT_LIM.1.2/Loader The TSF shall be designed and implemented in a manner that limits their availability so that in conjunction with “Limited capabilities 243 [assignment: the authorized identified roles] 244 [assignment: action] 245 [assignment: Limited capability and availability policy] Security Target TCOS ID Version 2.0 Release 1/P6022y 103/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 (FMT_LIM.1)” the following policy is enforced: The TSF prevents de- ploying the Loader functionality after TOE delivery246.247 480 Application Note 75:: The Loader functionality relies on a secure boot loading procedure in a secure environment before TOE delivery to the assigned user and preventing to de- ploy the Loader of the Security IC after an assigned action, e.g. after blocking the Loader for TOE delivery to the end-user. 481 The following SFRs are imported from [EAC2PP]. They concern mainly applications with EAC2-protected data. • FMT_MTD.1/CVCA_INI_EAC2PP • FMT_MTD.1/CVCA_UPD_EAC2PP • FMT_SMF.1/EAC2PP • FMT_SMR.1/PACE_EAC2PP This SFR is combined with FMT_SMR.1/PACE_EAC1PP into to by FMT_SMR.1 above. • FMT_MTD.1/DATE_EAC2PP • FMT_MTD.1/PA_EAC2PP • FMT_MTD.1/SK_PICC_EAC2PP • FMT_MTD.1/KEY_READ_EAC2PP • FMT_MTD.1/Initialize_PIN_EAC2PP • FMT_MTD.1/Change_PIN_EAC2PP • FMT_MTD.1/Resume_PIN_EAC2PP • FMT_MTD.1/Unblock_PIN_EAC2PP • FMT_MTD.1/Activate_PIN_EAC2PP • FMT_MTD.3/EAC2PP • FMT_LIM.1/EAC2PP 482 Application Note 76: The SFR below concerns the whole TOE, not just applications with EAC2-protected data. • FMT_LIM.2/EAC2PP 483 Application Note 77: The SFRs below concerns the whole TOE, not just applications with EAC2-protected data. • FMT_MTD.1/INI_ENA_EAC2PP • FMT_MTD.1/INI_DIS_EAC2PP 484 The following SFRs are imported due to claiming [EAC1PP]. They mainly concern appli- cations with EAC1-protected data. • FMT_SMF.1/EAC1PP • FMT_SMR.1/PACE_EAC1PP This SFR is combined with FMT_SMR.1/PACE_EAC2PP into FMT_SMR.1 • FMT_LIM.1/EAC1PP This SFR is equivalent to FMT_LIM.1/EAC2PP, listed here only for the sake of completeness. • FMT_LIM.2/EAC1PP This SFR is equivalent to FMT_LIM.2/EAC2PP, listed here only for the sake of completeness. • FMT_MTD.1/INI_ENA_EAC1PP (equivalent to FMT_MTD.1/INI_ENA_EAC2PP, listed here only for the sake of completeness) • FMT_MTD.1/INI_DIS_EAC1PP (equivalent to FMT_MTD.1/INI_DIS_EAC2PP, listed here only for the sake of completeness) 246 [assignment: action] 247 [assignment: Limited capability and availability policy] Security Target TCOS ID Version 2.0 Release 1/P6022y 104/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 • FMT_MTD.1/CVCA_INI_EAC1PP • FMT_MTD.1/CVCA_UPD_EAC1PP (equivalent to FMT_MTD.1/CVCA_UPD_ EAC2PP, listed here only for the sake of completeness) • FMT_MTD.1/DATE_EAC1PP This SFR is equivalent to FMT_MTD.1/DATE_EAC2PP. 485 Note that FMT_MTD.1/DATE_EAC2PP generalizes the notion of Domestic Extended In- spection System to EAC1 terminals with appropriate authorization level. This does not violate strict conformance to [EAC1PP]. • FMT_MTD.1/CAPK_EAC1PP • FMT_MTD.1/PA_EAC1PP (equivalent to FMT_MTD.1/PA_ EAC2PP, listed here only for the sake of completeness) • FMT_MTD.1/KEY_READ_EAC1PP • FMT_MTD.3/EAC1PP 486 The following SFRs are imported due to claiming [MREDONPP]. • FMT_SMF.1/UPD • FMT_MTD.1/UPD_SK_PICC • FMT_MTD.1/UPD_KEY_READ • FMT_SMR.1/UPD 487 The following SFRs are imported due to claiming [SSCDPP]. They mostly concern the security management of an eSign application. • FMT_SMR.1/SSCDPP (covered by FMT_SMR.1) • FMT_SMF.1/SSCDPP • FMT_MOF.1/SSCDPP • FMT_MSA.1/Admin_SSCDPP • FMT_MSA.1/Signatory_SSCDPP • FMT_MSA.2/SSCDPP • FMT_MSA.3/SSCDPP • FMT_MSA.4/SSCDPP • FMT_MTD.1/Admin_SSCDPP • FMT_MTD.1/Signatory_SSCDPP 488 FMT_SMF.1/EAC2PP Specification of Management Functions Hierarchical to: No other components. Dependencies: No dependencies FMT_SMF.1.1/EAC2PP The TSF shall be capable of performing the following management functions: 1. Initialization, 2. Pre-Personalization, 3. Personalization, 4. Configuration, 5. Resume and unblock the PIN (if any)248, 6. Activate and deactivate the PIN (if any)249. 248 unblocking eSign-PIN is managed by FMT_SMF.1/SSCD 249 [assignment: list of management functions to be provided by the TSF] Security Target TCOS ID Version 2.0 Release 1/P6022y 105/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 489 FMT_SMF.1/EAC1PP Specification of Management Functions Hierarchical to: No other components. Dependencies: No dependencies FMT_SMF.1.1/EAC1PP The TSF shall be capable of performing the following management functions: 1. Initialization, 2. Personalization, 3. Pre-Personalization, 4. Configuration250. 490 Application Note 78: For the explanation on the role Manufacturer please refer to the Ap- plication Note 26; on the role Personalization Agent – to the Application Note 55. 491 Application Note 79: 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. 492 FMT_LIM.1/EAC2PP Limited capabilities Hierarchical to: No other components. Dependencies: FMT_LIM.2 Limited availability: fulfilled by FMT_LIM.2. FMT_LIM.1.1/EAC2PP The TSF shall be designed in a manner that limits their capabilities so that in conjunction with ‘Limited availability (FMT_LIM.2)’ the fol- lowing 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. software to be reconstructed, 4. substantial information about construction of TSF to be gath- ered which may enable other attacks and 5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed251. 493 FMT_LIM.2/EAC2PP Limited availability Hierarchical to: No other components. Dependencies: FMT_LIM.1 Limited capabilities: fulfilled by FMT_LIM.1. FMT_LIM.2.1/EAC2PP 250 [assignment: list of management functions to be provided by the TSF] 251 [assignment: Limited capability and availability policy] Security Target TCOS ID Version 2.0 Release 1/P6022y 106/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall be designed in a manner that limits their availability so that in conjunction with ‘Limited capabilities (FMT_LIM.1)’ the fol- lowing 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. software to be reconstructed, 4. substantial information about construction of TSF to be gath- ered which may enable other attacks and 5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed 252. 494 FMT_MTD.1/INI_ENA_EAC2PP Management of TSF data – Writing Initializa- tion 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_EAC2PP The TSF shall restrict the ability to write253 the Initialization Data and Pre-personalization Data254 to the Manufacturer255. 495 FMT_MTD.1/INI_DIS_EAC2PP 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_EAC2PP The TSF shall restrict the ability to read out256 the Initialization Data and the Pre-personalization Data257 to the Personalization Agent258. 496 Application Note 80: The TOE may restrict the ability to write the Initialization Data and the Pre-personalization Data by (i) allowing writing these data only once and (ii) blocking the role Manufacturer at the end of the manufacturing phase. The Manufacturer may write the Initialization Data (as required by FAU_SAS.1) including, but being not limited to a unique identification of the IC being used to trace the IC in the life phases ‘manufacturing’ 252 [assignment: Limited capability and availability policy] 253 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 254 [assignment: list of TSF data] 255 [assignment: the authorized identified roles] 256 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 257 [assignment: list of TSF data] 258 [assignment: the authorized identified roles] Security Target TCOS ID Version 2.0 Release 1/P6022y 107/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 and ‘issuing’, but being not needed and may be misused in the ‘operational use’. There- fore, the read and use access shall be blocked in the ‘operational use’ by the Personali- zation Agent, when he switches the TOE from the life phase ‘issuing’ to the life phase ‘operational use’. Please also refer to the Application Note 55. 497 FMT_MTD.1/CVCA_INI_EAC2PP 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_EAC2PP The TSF shall restrict the ability to write259 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-3, A.6.2] 3. initial Current Date 4. none260 to the Personalization Agent261. 498 Application Note 81: The initial Country Verifying Certification Authority Public Key is writ- ten by the Personalization Agent in the issuing phase (cf. [EACTR-3, 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-3, 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 Personalization Agent without the self- signature (cf. [TCOSGD]). 499 FMT_MTD.1/CVCA_UPD_EAC2PP 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_EAC2PP 259 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 260 [assignment: list of TSF data] 261 [assignment: the authorized identified roles] Security Target TCOS ID Version 2.0 Release 1/P6022y 108/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall restrict the ability to update262 the 1. Country Verifying Certification Authority Public Key (PKCVCA), 2. metadata of the Country Verifying Certification Authority Certifi- cate (CCVCA) as required in [EACTR-3, A.6.2] 3. none263 to Country Verifying Certification Authority264. 500 Application Note 82: 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-3, 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-3, sec. 2.2.3 and 2.2.4]). 501 FMT_MTD.1/DATE_EAC2PP Management of TSF data – Current date Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_MTD.1.1/DATE_EAC2PP The TSF shall restrict the ability to modify265 the Current Date266 to 1. CVCA, 2. Document Verifier, 3. EAC2 terminal (EIS, ATT or SGT267) possessing an Accurate Terminal Certificate according to [EACTR-3]. 4. none268. 502 Application Note 83: The authorized roles are identified in their certificates (cf. [EACTR-3, 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-3, A.6.2.3, B.11.1, C.1.3, C.1.5, D.2] for details). 503 FMT_MTD.1/PA_EAC2PP Management of TSF data – Personalization Agent Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1 262 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 263 [assignment: list of TSF data] 264 [assignment: the authorized identified roles] 265 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 266 [assignment: list of TSF data] 267 [assignment: list of EAC2 terminal types] 268 [assignment: the authorized identified roles] Security Target TCOS ID Version 2.0 Release 1/P6022y 109/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_MTD.1.1/PA_EAC2PP The TSF shall restrict the ability to write269 the card/chip security object (SOC) and the document Security Object (SOD)270 to the Personalization Agent271. 504 Application Note 84: By writing SOC and SOD into the TOE, the Personalization Agent con- firms (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 personal- ization data is formally not addressed above. Nevertheless, FMT_MTD.1/PA shall be un- derstood 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 55. 505 FMT_MTD.1/SK_PICC_EAC2PP Management of TSF data – Chip Authen- tication 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_EAC2PP The TSF shall restrict the ability to load or create272 the Chip Au- thentication Private Key (SKPICC) and the Restricted Identification Private Key(s)273 to the Personalization Agent 274. 506 Application Note 85: The formulation Chip Authentication Private Key(s) MUST be inter- preted here to include the static keys of CA3 (i.e. SKPICC,1 and SKPICC,2) as well. 507 Application Note 86: 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 Personalization. 508 FMT_MTD.1/KEY_READ_EAC2PP 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. 269 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 270 [assignment: list of TSF data] 271 [assignment: the authorized identified roles] 272 [selection: create, load]/[selection: change_default, query, modify, delete, clear, [assignment: other operations]] 273 [assignment: list of TSF data] 274 [assignment: the authorized identified roles] Security Target TCOS ID Version 2.0 Release 1/P6022y 110/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FMT_MTD.1.1/KEY_READ_EAC2PP The TSF shall restrict the ability to read275 the 1. PACE passwords, 2. Personalization Agent Keys, 3. the Chip Authentication private key(s) (SKPICC) 4. the Restricted Identification private key(s) 5. none276 to none277. 509 FMT_MTD.1/KEY_READ_EAC1PP 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_EAC1PP The TSF shall restrict the ability to read278 the 1. PACE passwords 2. Chip Authentication Private Key 3. Personalization Agent Keys279 to none280. 510 Application Note 87: The formulation Chip Authentication Private Key MUST be inter- preted here to include the static keys of CA3 (i.e. SKPICC,1 and SKPICC,2) as well. 511 FMT_MTD.1/Resume_PIN_EAC2PP Management of TSF data – Resuming PIN Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1. FMT_MTD.1.1/Resume_PIN_EAC2PP The TSF shall restrict the ability to resume281 the suspended PIN282 to the electronic document holder283. 275 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 276 [assignment: list of TSF data] 277 [assignment: the authorized identified roles] 278 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 279 [assignment: list of TSF data] 280 [assignment: the authorized identified roles] 281 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 282 [assignment: list of TSF data] 283 [assignment: the authorized identified roles] Security Target TCOS ID Version 2.0 Release 1/P6022y 111/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 512 Application Note 88: Resuming is a two-step procedure, subsequently using PACE with the CAN and PACE with the PIN. It must be implemented according to [EACTR-2], and is relevant for the status as required by FIA_AFL.1/Suspend_PIN. The electronic document holder is authenticated as required by FIA_UAU.1/PACE using the PIN as the shared password. 513 FMT_MTD.1/Unblock_PIN_EAC2PP Management of TSF data – Unblocking PIN Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1. FMT_MTD.1.1/Unblock_PIN_EAC2PP The TSF shall restrict the ability to unblock284 the blocked PIN285 to 1. the electronic document holder (using the PUK for unblocking), 2. an EAC2 terminal of a type that has the terminal authorization level for PIN management286. 514 Application Note 89: The unblocking procedure must be implemented according to [EACTR-2, 2.5.2] and is relevant for the status as required by FIA_AFL.1/PIN_Blocking. It can be triggered by either (i) the electronic document holder being authenticated as re- quired by FIA_UAU.1/PACE using the PUK as the shared password or (ii) the ATT (FIA_UAU.1/Terminal) proved the Terminal Authorization Level being sufficient for PIN management (FDP_ACF.1/TRM). 515 FMT_MTD.1/Initialze_PIN_EAC2PP Management of TSF data – Activat- ing/Deactivating PIN Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1. FMT_MTD.1.1/Initialize_PIN_EAC2PP The TSF shall restrict the ability to write287 the initial PIN and PUK288 to the Personalization Agent289. 516 FMT_MTD.1/Activate_PIN_EAC2PP Management of TSF data – Activat- ing/Deactivating PIN Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by FMT_SMF.1. 284 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 285 [assignment: list of TSF data] 286 [assignment: the authorized identified roles] 287 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 288 [assignment: list of TSF data] 289 [assignment: the authorized identified roles] Security Target TCOS ID Version 2.0 Release 1/P6022y 112/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FMT_MTD.1.1/Activate_PIN_EAC2PP The TSF shall restrict the ability to activate and deactivate290 the PIN291 to An EAC2 terminal of a type that has the terminal authorization level for PIN management292. 517 Application Note 90: The activating/deactivating procedures must be implemented accor- ding to [EACTR-2, 2.5.2]. It can be triggered by the ATT (FIA_UAU.1/EAC2_Terminal) that proved a Terminal Authorization Level being sufficient for PIN management (FDP_ACF.1/TRM). 518 FMT_MTD.1/Change_PIN_EAC2PP Management of TSF data – Changing PIN Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled FMT_SMR.1 fulfilled. FMT_MTD.1.1/Change_PIN_EAC2PP The TSF shall restrict the ability to change293 the blocked PIN294 to295 1. the electronic document holder (using the PUK for unblocking), 2. an EAC2 terminal of a type that has the terminal authorization level for PIN management296. 519 FMT_MTD.1/CVCA_INI_EAC1PP 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 FMT_SMR.1 fulfilled FMT_MTD.1.1/CVCA_INI_EAC1PP 290 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 291 [assignment: list of TSF data] 292 [assignment: the authorized identified roles] 293 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 294 [assignment: list of TSF data] 295 [assignment: the authorized identified roles] 296 [assignment: the authorized identified roles that match the list of PIN changing rules conformant to [EACTR-2]] Security Target TCOS ID Version 2.0 Release 1/P6022y 113/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall restrict the ability to write297 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, part 3 sec. A.6.2.3] 3. initial Current Date 4. none298 to the Personalization Agent299. 520 Application Note 91: The initial Country Verifying Certification Authority Public Key is writ- ten by the Personalization Agent in the issuing phase (cf. [EACTR, part 3 sec. 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 Ter¬minal Authori- zation 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 Personalization Agent without the self- signature (cf. [TCOSGD]). 521 FMT_MTD.1/CVCA_UPD_EAC1PP Management of TSF data – Chip Authen- tication Private Key Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled FMT_SMR.1 fulfilled FMT_MTD.1.1/CVCA_UPD_EAC1PP The TSF shall restrict the ability to update300 the 1. Country Verifying Certification Authority Public Key, 2. Country Verifying Certification Authority Certificate301 to Country Verifying Certification Authority302. 522 FMT_MTD.1/CAPK_EAC1PP Management of TSF data – Chip Authentica- tion Private Key Hierarchical to: No other components. Dependencies: FMT_SMF.1 Specification of management functions: fulfilled FMT_SMR.1 fulfilled 297 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 298 [assignment: list of TSF data] 299 [assignment: the authorized identified roles] 300 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 301 [assignment: list of TSF data] 302 [assignment: the authorized identified roles] Security Target TCOS ID Version 2.0 Release 1/P6022y 114/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FMT_MTD.1.1/CAPK_EAC1PP The TSF shall restrict the ability to create or load303 the Chip Au- thentication Private Key304 to the Initialization/Completion Agent305 523 Application Note 92: A Chip Authentication Private Key, which is used in the next step or phase can be created or loaded by the actual user (Initialization or Completion Agent). 524 FMT_MTD.3/EAC2PP 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/EAC2PP The TSF shall ensure that only secure values of the certificate chain are accepted for TSF data of the Terminal Authentication Protocol 2 and the Terminal Access Control SFP306. Refinement: To determine if the certificate chain is valid, the TOE shall proceed the certificate validation according to [EACTR-3]. 525 FMT_MTD.3/EAC1PP 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/EAC1PP The TSF shall ensure that only secure values of the certificate chain are accepted for TSF data of the Terminal Authentication Protocol 1 and the Terminal Access Control SFP307. Refinement: The certificate chain is valid if and only if 1. the digital signature of the Inspection System Certificate can be verified as correct with the public key of the Document Verifier Certificate and the ex- piration date of the Inspection System Certificate is not before the Current Date of the TOE, 2. the digital signature of the Document Verifier Certificate can be verified as correct with the public key in the Certificate of the Country Verifying Cer- tification Authority and the expiration date of the Document Verifier Certi- ficate is not before the Current Date of the TOE, 303 [selection: create, load] 304 [assignment: list of TSF data] 305 [assignment: the authorized identified roles] 306 [assignment: list of TSF data] 307 [assignment: list of TSF data] Security Target TCOS ID Version 2.0 Release 1/P6022y 115/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 3. the digital signature of the Certificate of the Country Verifying Certification Authority can be verified as correct with the public key of the Country Veri- fying Certification Authority known to the TOE and the expiration date of the Certificate. The Inspection System Public Key contained in the Inspection System Certificate in a valid certificate chain is a secure value for the authentication reference data of the Extended Inspection System. The intersection of the Certificate Holder Authorizations contained in the certifi- cates of a valid certificate chain is a secure value for Terminal Authorization of a successful authenticated Extended Inspection System. 526 Application Note 93: The Terminal Authentication Version 1 is used as required by FIA_UAU.1/ EAC2_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. 527 This ST includes the SFRs of the SSCD PP [SSCDPP]. These items are applicable, if the eSign application is operational. SFR identifier Comments FMT_SMR.1/SSCDPP R.Sigy is represented by the electronic document holder, and R.Admin by the Personalization Agent, therefore it is covered by FMT_SMR.1 FMT_SMF.1/SSCDPP – FMT_MOF.1/SSCDPP – FMT_MSA.1/Admin_SSCDPP – FMT_MSA.1/Signatory_SSCDPP – FMT_MSA.2/SSCDPP – FMT_MSA.3/SSCDPP – FMT_MSA.4/SSCDPP – FMT_MTD.1/Admin_SSCDPP – FMT_MTD.1/Signatory_SSCDPP eSign-PIN can be unblocked using the card-global PUK. Although the PP allows using an additional eSign-specific eSign-PUK this is not implemented in the TOE. 528 Application Note 94: Note that the iterations /□□□_SSCD from [SSCDPP] are renamed here to /□□□_SSCDPP to avoid a redundant notation like /□□□_SSCD_SSCDPP. 529 FMT_SMF.1/SSCDPP Specification of Management Functions Hierarchical to: No other components. Dependencies: No dependencies FMT_SMF.1.1/SSCDPP The TSF shall be capable of performing the following management functions: Security Target TCOS ID Version 2.0 Release 1/P6022y 116/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 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. none308 . 530 FMT_MOF.1/SSCDPP Management of security functions behavior 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/SSCDPP. FMT_MOF.1.1/SSCDPP The TSF shall restrict the ability to enable309 the functions signature- creation function310 to R.Sigy311. 531 FMT_MSA.1/Admin_SSCDPP Management of security attributes Hierarchical to: No other components. Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control]: fulfilled by FDP_ACC.1/SCD/SVD_Generation_SSCD, FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1, FMT_SMF.1 Specification of Management Functions: fulfilled by FMT_SMF.1/SSCDPP FMT_MSA.1.1/Admin_SSCDPP The TSF shall enforce the SCD/SVD_Generation_SFP312 to restrict the ability to modify313 the security attributes SCD/SVD manage- ment314 to R.Admin315. 532 Application Note 95: The selection313 is made from a selection with the following assign- ment: [selection: change_default, query, modify, delete, none316]. 308 [assignment: list of management functions to be provided by the TSF]/[assignment: list of other security management functions to be provided by the TSF] 309 [selection: determine the behavior of, disable, enable, modify the behavior of] 310 [assignment: list of functions] 311 [assignment: the authorized identified roles] 312 [assignment: access control SFP(s), information flow control SFP(s)] 313 [selection: change_default, query, modify, delete, [assignment: other operations]] 314 [assignment: list of security attributes] 315 [assignment: the authorized identified roles] 316 [assignment: other operations] Security Target TCOS ID Version 2.0 Release 1/P6022y 117/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 533 FMT_MSA.1/Signatory_SSCDPP 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_SSCD FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_SMF.1 Specification of Management Functions: fulfilled by FMT_SMF.1/SSCDPP FMT_MSA.1.1/Signatory_SSCDPP The TSF shall enforce the Signature-creation_SFP317 to restrict the ability to modify318 the security attributes SCD operational319 to R.Sigy320. 534 FMT_MSA.2/SSCDPP 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_SSCD, FDP_ACC.1/Signature_Creation_SSCD FMT_MSA.1 Management of security attributes: fulfilled by FMT_MSA.1/Admin_SSCDPP, FMT_MSA.1/Signatory_SSCDPP FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_MSA.2.1/SSCDPP The TSF shall ensure that only secure values are accepted for SCD/SVD Management and SCD operational321. 535 Application Note 96: 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. 536 FMT_MSA.3/SSCDPP Static attribute initialization Hierarchical to: No other components. Dependencies: FMT_MSA.1 Management of security attributes: fulfilled by FMT_MSA.1/Admin_SSCDPP, FMT_MSA.1/Signatory_SSCDPP. FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1 FMT_MSA.3.1/SSCDPP 317 [assignment: access control SFP(s), information flow control SFP(s)] 318 [selection: change_default, query, modify, delete, [assignment: other operations]] 319 [assignment: list of security attributes] 320 [assignment: the authorized identified roles] 321 [selection: list of security attributes] Security Target TCOS ID Version 2.0 Release 1/P6022y 118/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall enforce the SCD/SVD_Generation_SFP, SVD_ Transfer_SFP and Signature-creation_SFP322 to provide restricti- ve323 default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/SSCDPP The TSF shall allow the R.Admin324 to specify alternative initial val- ues to override the default values when an object or information is created. 537 FMT_MSA.4/SSCDPP 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_SSCD, FDP_ACC.1/Signa- ture_Creation_SSCD FMT_MSA.4.1/SSCDPP The TSF shall use the following rules to set the value of security at- tributes: 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 single operation325. 538 Application Note 97: Because the TOE does not support SCD/SVD generation by the Sig- natory alone, the rule (2) is not relevant here. 539 FMT_MTD.1/Admin_SSCDPP 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/SSCDPP FMT_MTD.1.1/Admin_SSCDPP The TSF shall restrict the ability to create326 the RAD327 to R.Ad- min328. 322 [assignment: access control SFP, information flow control SFP] 323 [selection choose one of: restrictive, permissive, [assignment: other property]] 324 [assignment: the authorized identified roles] 325 [assignment: rules for setting the values of security attributes] 326 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 327 [assignment: list of TSF data] 328 [assignment: the authorized identified roles] Security Target TCOS ID Version 2.0 Release 1/P6022y 119/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 540 FMT_MTD.1/Signatory_SSCDPP 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/SSCDPP FMT_MTD.1.1/Signatory_SSCDPP The TSF shall restrict the ability to modify, unblock329 the RAD330 to R.Sigy331. 541 Application Note 98: The selection329 is made from a selection with the following assign- ment: [selection: change_default, query, modify, delete, unblock332]. 542 Application Note 99: The access rights can be described in FMT_MSA.1/SEF in more de- tail. The “authorized identified roles” could therefore be interpreted in a wider scope in- cluding the context where the command is allowed to be executed. 543 The following SFRs are imported due to claiming [MREDONPP]. 544 FMT_SMF.1/UPD Specification of Management Functions in- cluding Updates Hierarchical to: No other components. Dependencies: No dependencies. FMT_SMF.1.1/UPD The TSF shall be capable of performing the following management functions: 1. Updating the TOE software with the mechanism TCOS update mechanism specified in [TCOSGD]333. 334. 545 FMT_MTD.1/UPD_SK_PICC Management of TSF Data – Secret Update Keys Hierarchical to: No other components. Dependencies: FMT_SMR.1: fulfilled FMT_SMF.1: fulfilled FMT_MTD.1.1/UPD_SK_PICC 329 [selection: change_default, query, modify, delete, clear, create, load, [assignment: other operations]] 330 [assignment: list of TSF data] 331 [assignment: the authorized identified roles] 332 [assignment: other operations] 333 [assignment: list of technical specification(s) defining an update mechanism] 334 [assignment: list of management functions to be provided by the TSF] Security Target TCOS ID Version 2.0 Release 1/P6022y 120/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall restrict the ability to create335 the Secret Cryptogra- phic Update Keys336 to the to the update key installation agent.337. 546 FMT_MTD.1/UPD_KEY_READ Management of TSF data – Secret Update Keys Hierarchical to: No other components. Dependencies: FMT_SMF.1: fulfilled FMT_SMR.1: fulfilled FMT_MTD.1.1/UPD_KEY_READ The TSF shall restrict the ability to read338 the 1. Secret Cryptographic Update Keys339 2. none340 to none341. 547 FMT_SMR.1/UPD Security roles Hierarchical to: No other components. Dependencies: FIA_UID.1: fulfilled FMT_SMR.1.1/UPD The TSF shall maintain the roles 1. terminal 2. update terminal 3. update key installation agent 4. none342 FMT_SMR.1.2/UPD The TSF shall be able to associate users with roles. 6.1.7 Class FPT Protection of the Security Functions 548 The following security functional requirements are imported from [EAC2PP], and address the protection against forced illicit information leakage, including physical manipulation. • FPT_EMS.1/EAC2PP 549 Application Note 100: Note that the PIN in the above SFR refers here to both the PIN for an eID application, and also the PIN for an eSign application, if they exist on card. 335 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 336 [selection: list of, or reference specifying the Secret Cryptographic Update Keys required for the update procedure] 337 [assignment: the authorized identified roles] 338 [selection: change_default, query, modify, delete, clear, [assignment: other operations]] 339 [assignment: list of or reference specifying the Secret Cryptographic Update Keys required for the update procedure] 340 [assignment: list of TSF data] 341 [assignment: the authorized identified roles] 342 [assignment: list of TSF data] Security Target TCOS ID Version 2.0 Release 1/P6022y 121/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 • FPT_FLS.1/EAC2PP • FPT_TST.1/EAC2PP • FPT_PHP.3/EAC2PP 550 The following SFRs are imported due to claiming [EAC1PP]. They mostly concern the protection of security functionality related to EAC1-protected data. • FPT_TST.1/EAC1PP (equivalent to FPT_TST.1/EAC2PP, listed here only for the sake of completeness) • FPT_FLS.1/EAC1PP (equivalent to FPT_FLS.1/EAC2PP, listed here only for the sake of completeness) • FPT_PHP.3/EAC1PP (equivalent to FPT_PHP.3/EAC2PP, listed here only for the sake of completeness) • FPT_EMS.1/EAC1PP 551 The following SFRs are imported due to claiming [MREDONPP]. • FPT_EMS.1/UPD • FPT_FLS.1/UPD • FPT_TST.1/UPD 552 The following SFRs are imported due to claiming [SSCDPP]. They mostly concern the protection of security functionality related to eSign application (if available). • FPT_EMS.1/SSCDPP • FPT_FLS.1/SSCDPP(subsumed by FPT_FLS.1/EAC2PP) • FPT_PHP.1/SSCDPP • FPT_PHP.3/SSCDPP(subsumed by FPT_PHP.3/EAC2PP) • FPT_TST.1/SSCDPP(subsumed by FPT_FPT_TST.1/EAC2PP) 553 The TOE shall prevent inherent and forced illicit information leakage for User Data and TSF-data. The security functional requirement FPT_EMS.1 addresses the inherent leak- age. 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)”, “Lim- ited availability (FMT_LIM.2)” and “Resistance to physical attack (FPT_PHP.3)” together with the SAR “Security architecture description” (ADV_ARC.1) prevent bypassing, deacti- vation and manipulation of the security features or misuse of TOE functions. 554 FPT_EMS.1/EAC2PP TOE Emanation Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMS.1.1/EAC2PP The TOE shall not emit power variations, timing variations during command execution343 in excess of non-useful information344 ena- bling access to345 1. the session keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA-KEnc, both CA2 and CA3) , 343 [assignment: types of emissions] 344 [assignment: specified limits] 345 [assignment: list of types of TSF data] Security Target TCOS ID Version 2.0 Release 1/P6022y 122/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 2. the ephemeral private key ephem-SKPICC-PACE, 3. the Chip Authentication private key (SKPICC), both CA2 and CA3, 4. the PIN, PUK, 5. the additional Chip Authentication 3 private sector keys (SKICC,1 and SKICC,2) 6. none346 and347 7. the Restricted Identification private key(s) SKID, 8. none348. FPT_EMS.1.2/EAC2PP The TSF shall ensure any users349 are unable to use the following in- terface electronic document’s contactless/contact-based interface and card circuit contacts350 to gain access to351 1.the session keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA- KEnc, both CA2 and CA3), 2.the ephemeral private key ephem - SKPICC- PACE, 3. the Chip Authentication private key (SKPICC), both CA2 and CA3, 4. the PIN, PUK, 5. the session keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA-KEnc), 6. the additional Chip Authentication 3 private sector keys (SKICC,1 and SKICC,2) 7. none352 and353 8. the Restricted Identification private key(s) SKID, 9. none354. 555 Application Note 101: Note that the PIN in the above SFR refers here to both the PIN for an eID application, and also the PIN for an eSign application, if they exist on card. The above SFR is refined from [EAC2PP] by adding all relevant key material from Chip Au- thentication 3 in addition to the key material from Chip Authentication 2, as well as the additional assignment to cover the private sector keys. Thus, the set of keys that need to be protected is a superset of the ones of the SFR from [EAC2PP]. Hence, the requirement is stricter than the one from [EAC2PP], and the refinement operation is justified. A refine- ment is used here to ensure that emissions via contact-based interfaces must not be ob- servable as well. This extends the scope of emission analysis by creating a stricter re- quirement. Hence, the refinement is justified. 346 [assignment: list of additional types of TSF data] 347 [assignment: list of types of user data] 348 [assignment: list of additional types of user data] 349 [assignment: type of users] 350 [assignment: type of connection] 351 [assignment: list of types of TSF data] 352 [assignment: list of additional types of TSF data] 353 [assignment: list of types of user data] 354 [assignment: list of additional types of user data] Security Target TCOS ID Version 2.0 Release 1/P6022y 123/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 556 FPT_EMS.1/EAC1PP TOE Emanation – PACE protocol Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMS.1.1/EAC1PP The TOE shall not emit power variations, timing variations during command execution355 in excess of non-useful information356 ena- bling access to357 1. Chip Authentication (Version 1) Session Keys 2. PACE session Keys (PACE-KMAC, PACE-KEnc), 3. the ephemeral private key ephem - SKPICC- PACE, 4. the ephemeral private key SKMap,PICC-PACE-CAM 5. none358 6. Personalization Agent Key(s), 7. Chip Authentication (Version 1) Private Key, 8. none359. FPT_EMS.1.2/EAC1PP The TSF shall ensure any users360 are unable to use the following in- terface smart card circuit contacts361 to gain access to362 1. Chip Authentication (Version 1) Session Keys 2. PACE session Keys (PACE-KMAC, PACE-KEnc), 3. the ephemeral private key ephem - SKPICC- PACE, 4. the ephemeral private key SKMap,PICC-PACE-CAM 5. none363 6. Personalization Agent Key(s), 7. Chip Authentication (Version 1) Private Key, 8. none364. 557 Application Note 102: This SFR covers the definition of FPT_EMS.1 in [EAC1PP] and ex- tends it by 4. of FPT_EMS.1.1 and FPT_EMS.1.2. Also, 1. and 7. of both FPT_\ EMS.1.1 and FPT_EMS.1.2 are slightly refined in order not to confuse Chip Authentication 1 with Chip Authentication 2 or Chip Authentication 3. Note that FPT_EMS.1 in [EAC1PP] is solely concerned with Chip Authentication 1, but since it was the first version of the proto- col at the time, it was simply called 'Chip Authentication' back then. 558 W.r.t. PACE-CAM, note the significance of protecting SKMap,PICC-PACE-CAM. Whereas when running PACE and CA1 separately, gaining knowledge of the ephemeral key SKPICC- PACE enables the attacker to decrypt the current PACE session, an attacker that gains 355 [assignment: types of emissions] 356 [assignment: specified limits] 357 [assignment: list of types of TSF data] 358 [assignment: list of additional types of TSF data] 359 [assignment: list of additional types of user data] 360 [assignment: type of users] 361 [assignment: type of connection] 362 [assignment: list of types of (further) TSF data] 363 [assignment: list of additional types of TSF data] 364 [assignment: list of additional types of user data] Security Target TCOS ID Version 2.0 Release 1/P6022y 124/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 knowledge of the ephemeral key SKMap,PICC-PACE-CAM can not only decrypt the session but also easily reveal the static secret chip authentication key SKPICC: Let • denote the group operation (i.e. addition or multiplication), and let i(x) denote the inverse of x. Since the chip sends CAPICC = SKMap,PICC-PACE-CAM • i(SKPICC) to the terminal, a malicious at- tacker that gains knowledge of SKMap,PICC-PACE-CAM can reveal SKPICC by computing SKPICC = i(CAPICC) • SKMap,PICC-PACE-CAM. 559 FPT_EMS.1/UPD TOE Emanation Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMS.1.1/UPD The TOE shall not emit power variations, timing variations during command execution365 in excess of non-useful information366 ena- bling access to Secret Update Key367 and any stored user data368. FPT_EMS.1.2/UPD The TSF shall ensure any users369 are unable to use the following in- terface electronic document’s contactless/contact-based interface and circuit contacts370 to gain access to Secret Update Key 371 and any stored user data372. 560 Application Note 103: The TOE shall prevent attacks against the listed secret data where the attack is based on external observable physical phenomena of the TOE. Such attacks may be observable at the interfaces of the TOE, originate from internal operation of the TOE, or be caused by an attacker that varies the physical environment under which the TOE operates. 561 FPT_EMS.1/SSCDPP TOE Emanation Hierarchical to: No other components. Dependencies: No dependencies. FPT_EMS.1.1/SSCDPP 365 [assignment: types of emissions] 366 [assignment: specified limits] 367 [assignment: list of types of TSF data] 368 [assignment: list of additional types of user data] 369 [assignment: type of users] 370 [assignment: type of connection] 371 [assignment: list of types of (further) TSF data] 372 [assignment: list of types of user data] Security Target TCOS ID Version 2.0 Release 1/P6022y 125/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TOE shall not emit power variations, timing variations during command execution373 in excess of non-useful information374 ena- bling access to RAD375 and SCD376. FPT_EMS.1.2/SSCDPP The TSF shall ensure any users377 are unable to use the following in- terface the contactless interface and circuit contacts378 to gain access to RAD379 and SCD380. 562 FPT_FLS.1/UPD Failure with preservation of secure state Hierarchical to: No other components. Dependencies: No dependencies. FPT_FLS.1.1/UPD The TSF shall preserve a secure state when the following types of failures occur: 1. Failure during a transmission of the update package data file 2. Failure detected by TSF according to FPT_TST.1 3. Failure detected after a failed update 4. none381. 563 Application Note 104: The secure state after a failed update usually reverts to the previous TOE software version. Nevertheless, this capability has limits, since the atomicity of the software update mechanism can technically only be achieved up to a certain extent. 564 FPT_FLS.1/EAC2PP Failure with preservation of secure state Hierarchical to: No other components. Dependencies: No dependencies. FPT_FLS.1.1/EAC2PP 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. none382. 373 [assignment: types of emissions] 374 [assignment: specified limits] 375 [assignment: list of types of TSF data] 376 [assignment: list of additional types of user data] 377 [assignment: type of users] 378 [assignment: type of connection] 379 [assignment: list of types of (further) TSF data] 380 [assignment: list of types of user data] 381 [assignment: list of types of failures in the TSF] 382 [assignment: list of types of failures in the TSF] Security Target TCOS ID Version 2.0 Release 1/P6022y 126/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 565 FPT_PHP.1/SSCDPP Passive detection of physical attack Hierarchical to: No other components. Dependencies: No dependencies FPT_PHP.1.1/SSCDPP The TSF shall provide unambiguous detection of physical tampering that might compromise the TSF. FPT_PHP.1.2/SSCDPP The TSF shall provide the capability to determine whether physical tampering with the TSF’s devices or TSF’s elements has occurred. 566 FPT_PHP.3/EAC2PP Resistance to physical attack Hierarchical to: No other components. Dependencies: No dependencies FPT_PHP.3.1/EAC2PP The TSF shall resist physical manipulation and physical probing383 to the TSF384 by responding automatically such that the SFRs are al- ways enforced. 567 Application Note 105: 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. 568 FPT_TST.1/EAC2PP TSF Testing Hierarchical to: No other components. Dependencies: No dependencies FPT_TST.1.1/EAC2PP The TSF shall run a suite of self tests during initial start-up385 to demonstrate the correct operation of the TSF386. FPT_TST.1.2/EAC2PP The TSF shall provide authorized users with the capability to Verify the integrity of the TSF data387. FPT_TST.1.3/EAC2PP 383 [assignment: physical tampering scenarios] 384 [assignment: list of TSF devices/elements] 385 [selection: during initial start-up, periodically during normal operation, at the request of the authorized user, at the condi- tions [assignment: conditions under which self test should occur]] 386 [selection: [assignment: parts of TSF], the TSF] 387 [selection: [assignment: parts of TSF data], TSF data] Security Target TCOS ID Version 2.0 Release 1/P6022y 127/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall provide authorized users with the capability to Verify the integrity of stored TSF executable code388. 569 FPT_TST.1/UPD TSF Testing Hierarchical to: No other components. Dependencies: No dependencies FPT_TST.1.1/UPD The TSF shall run a suite of self tests during initial start-up389 to demonstrate the correct operation of the TSF390. FPT_TST.1.2/UPD The TSF shall provide authorized users with the capability to verify the integrity of the TSF data391. FPT_TST.1.3/UPD The TSF shall provide authorized users with the capability to verify the integrity of stored TSF executable code392. 6.1.8 Class FTP Inter-TSF trusted channel 570 The following SFRs are imported from [EAC2PP]. • FTP_ITC.1/PACE_EAC2PP • FTP_ITC.1/CA2_EAC2PP393 571 The following SFR is imported due to claiming [EAC1PP]. It concerns applications with EAC1-protected data. • FTP_ITC.1/PACE_EAC1PP 572 The following SFR is imported due to claiming [MREDONPP]. • FTP_ITC.1/UPD 573 FTP_ITC.1/PACE_EAC2PP Inter-TSF trusted channel after PACE Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/PACE_EAC2PP The TSF shall provide a communication channel between itself and another trusted IT product a PACE terminal that is logically 388 [selection: [assignment: parts of TSF], TSF] 389 [selection: during initial start-up, periodically during normal operation, at the request of the authorized user, at the condi- tions [assignment: conditions under which self test should occur]] 390 [selection: [assignment: parts of TSF], the TSF] 391 [selection: [assignment: parts of TSF data], TSF data] 392 [selection: [assignment: parts of TSF], TSF] 393 Note,that in[ MREDPP] this SFR is identified as FTP_ITC.1/CA_EAC2PP. Security Target TCOS ID Version 2.0 Release 1/P6022y 128/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 distinct from other communication channels and provides as- sured identification of its end points and protection of the channel data from modification or disclosure. The trusted channel shall be established by performing the PACE protocol according to [EACTR-2]. FTP_ITC.1.2/PACE_EAC2PP The TSF shall permit another trusted IT product a PACE termi- nal394 to initiate communication via the trusted channel. FTP_ITC.1.3/PACE_EAC2PP The TSF shall initiate enforce communication via the trusted channel for any data exchange between the TOE and a PACE terminal after PACE395. 574 Application Note 106: The trusted channel is established after successful performing the PACE protocol (FIA_UAU.1/PACE). If the PACE was successfully performed, secure mes- saging is immediately started using the derived session keys (PACE-KMAC, PACE-KEnc): this secure messaging enforces preventing tracing while establishing Chip Authentication; the cryptographic primitives being used for the secure messaging are as required by FCS_COP.1/AES and FCS_COP.1/CMAC. The PACE secure messaging session is immediately superseded by a CA secure 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/PIN_Blocking. 575 FTP_ITC.1/CA2_EAC2PP Inter-TSF trusted channel Hierarchical to: No other components. Dependencies: No dependencies. FTP_ITC.1.1/CA2_EAC2PP The TSF shall provide a communication channel between itself and another trusted IT product an EAC2 terminal that is logically distinct from other communication channels and provides as- sured identification of its end points and protection of the channel data from modification or disclosure. The trusted channel shall be established by performing the CA2 protocol according to [EACTR-2]. FTP_ITC.1.2/CA2_EAC2PP The TSF shall permit another trusted IT product an EAC2 termi- nal396 to initiate communication via the trusted channel. FTP_ITC.1.3/CA2_EAC2PP 394 [selection: the TSF, another trusted IT product] 395 [assignment: list of functions for which a trusted channel is required] 396 [selection: the TSF, another trusted IT product] Security Target TCOS ID Version 2.0 Release 1/P6022y 129/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall initiate enforce communication via the trusted channel for any data exchange between the TOE and an EAC2 terminal after Chip Authentication397. 576 Application Note 107: Please note that the control on user data stored in the TOE is ad- dressed by FDP_ACF.1/TRM. 577 Application Note 108: The requirement FTP_ITC.1/CA2 also covers a secure transport of (i) SVD from the TOE to CGA as well as of (ii) VAD from HID and of (iii) DTBS from SCA to the TOE. It also covers TOE’s capability to generate and to provide CGA with evidence that can be used as a guarantee of the validity of SVD. The current SFR reflects the main additional feature concerning the eSign application comparing to [SSCDPP]. 578 FTP_ITC.1/CA3 Inter-TSF trusted channel Chip Authentication 3 Hierarchical to: No other components. Dependencies: No dependencies FTP_ITC.1.1/CA3 The TSF shall provide a communication channel between itself and an- other trusted IT product an EAC2 terminal 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 dis- closure. The trusted channel shall be established by performing the CA3 protocol according to [EACTR-2-v2.20]. FTP_ITC.1.2/CA3 The TSF shall permit another trusted IT product an EAC2 terminal398 to initiate communication via the trusted channel. FTP_ITC.1.3/CA3 The TSF shall initiateenforce399 communication via the trusted channel for any data exchange between the TOE and an EAC2 terminal after Chip Authentication 3.400. 579 Application Note 109: The TOE responds only to commands establishing secure messag- ing channels. 580 FTP_ITC.1/UPD Inter-TSF trusted channel Hierarchical to: No other components. Dependencies: No dependencies FTP_ITC.1.1/UPD 397 [assignment: list of functions for which a trusted channel is required] 398 [selection: the TSF, another trusted IT product] 399 Refinement: The trusted IT product is the terminal. The word “initiate” is changed to “enforce”, because the TOE is a pas- sive device that cannot initiate any communication, but can enforce secured communication if required for an object of the object system and the TOE can close the trusted channel after integrity violation of a received command. 400 [assignment: list of functions for which a trusted channel is required] Security Target TCOS ID Version 2.0 Release 1/P6022y 130/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 The TSF shall provide a communication channel between itself and another trusted IT product an update terminal that is logically dis- tinct from other communication channels and provides assured iden- tification of its end points and protection of the channel data from modification or disclosure. FTP_ITC.1.2/UPD The TSF shall permit another trusted IT product an update termi- nal401 to initiate communication via the trusted channel. FTP_ITC.1.3/UPD The TSF shall initiate enforce communication via the trusted chan- nel for any data exchange between the TOE and the update termi- nal402. 581 FTP_ITC.1/PACE_EAC1PP Inter-TSF trusted channel – PACE Hierarchical to: No other components. Dependencies: No dependencies FTP_ITC.1.1/PACE_EAC1PP The TSF shall provide a communication channel between itself and an- other trusted IT product that is logically distinct from other communica- tion channels and provides assured identification of its end points and protection of the channel data from modification or disclosure. FTP_ITC.1.2/PACE_EAC1PP The TSF shall permit another trusted IT product403 to initiate communi- cation via the trusted channel. FTP_ITC.1.3/PACE_EAC1PP The TSF shall initiate enforce404 communication via the trusted channel for any data exchange between the TOE and the Terminal405. 582 Application Note 110: The trusted IT product is the terminal. The TOE enforces the trusted channel by means of PACE protocol after establishing a communication channel and read- ing the ATS. 401[selection: the TSF, another trusted IT product] 402[assignment: list of functions for which a trusted channel is required] 403 [selection: the TSF, another trusted IT product] 404 Refinement: The trusted IT product is the terminal. The word “initiate” is changed to “enforce”, as the TOE is a passive device that cannot initiate any communication. All communication is initiated by the Terminal, and the TOE enforces the trusted channel. 405 [assignment: list of functions for which a trusted channel is required] Security Target TCOS ID Version 2.0 Release 1/P6022y 131/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 6.2 Security Assurance Requirements for the TOE 583 The assurance requirements for the evaluation of the TOE, its development and operating environment are to choose as the predefined assurance package EAL4 augmented by the following components: ▪ ALC_DVS.2 (Sufficiency of security measures), ▪ ATE_DPT.2 (Testing: security enforcing modules) and ▪ AVA_VAN.5 (Advanced methodical vulnerability analysis). 584 The Protection Profiles BSI-CC-PP0035 [ICPP] and BSI-CC-PP0082 [MREDPP, chap. 6.2.1] define refinements to the TOE Assurance Requirements which are considered by the TOE Developer under the corresponding assurance packages. 6.3 Security Requirements Rationale 585 A detailed justification required for suitability of the security functional requirements to achieve the security objectives is given in the PP ([MREDPP, chap. 6.3.1]) and is therefore not repeated here. 6.3.1 Rationale for SFR’s Dependencies 586 The following table provides an overview for security functional requirements coverage also giving an evidence for sufficiency and necessity of the SFRs chosen. It uses the corresponding Tables from the Protection Profiles ([MREDPP], [MREDONPP], [EAC2PP], [EAC1PP], [PACEPP] and [SSCDPP]). Note that the SFRs and objectives related to the hardware ST are not considered here. OT.Update_Mechanism OT.Enc_Sign_Update OT.Update_Terminal_Auth OT.Attack_Detection OT.Key_Secrecy OT.Cap_Avail_Loader OT.Non_Interfere OT.Chip_Auth_Proof OT.Sens_Data_Conf OT.Chip_Auth_Proof_PACE_CAM OT.AC_Pers_EAC2 OT.CA2 OT.CA3 OT.RI_EAC2 OT.Sens_Data_EAC2 OT.AC_Pers OT.Data_Authenticity OT.Data_Confidentiality OT.Data_Integrity OT.Identification OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Malfunction OT.Prot_Phys-Tamper OT.Tracing OT.DTBS_Integrity_TOE OT.EMSEC_Design OT.Lifecycle_Security OT.SCD_Secrecy OT.SCD_SVD_Corresp OT.SCD_Unique OT.SCD/SVD_Auth_Gen OT.Sig_Secure OT.Sigy_SigF OT.Tamper_ID OT.Tamper_Resistance FAU_SAS.1/EAC2PP x x FAU_SAS.1/UPD x x FCS_CKM.1/CA_EAC1PP x x x x x x FCS_CKM.1/CA3 x x x x x x FCS_CKM.1/CAM x x x x FCS_CKM.1/UPD_ITC x x FCS_CKM.1/UPD_DEC x x FCS_CKM.1/UPD_INT x x FCS_CKM.1/DH_PACE_EAC1PP x x x FCS_CKM.1/DH_PACE_EAC2PP x x x x FCS_CKM.1/SSCDPP x x x x FCS_CKM.4/UPD x x FCS_CKM.4/EAC2PP x x x x FCS_CKM.4/SSCDPP x x FCS_COP.1/CA_ENC_EAC1PP x x FCS_COP.1/CA_MAC_EAC1PP x x FCS_COP.1/CAM x x x x FCS_COP.1/UPD_ITC x x FCS_COP.1/UPD_DEC x x FCS_COP.1/UPD_INT x x FCS_COP.1/UPD_SIG x x FCS_COP.1/PACE_ENC_EAC1PP x Security Target TCOS ID Version 2.0 Release 1/P6022y 132/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 OT.Update_Mechanism OT.Enc_Sign_Update OT.Update_Terminal_Auth OT.Attack_Detection OT.Key_Secrecy OT.Cap_Avail_Loader OT.Non_Interfere OT.Chip_Auth_Proof OT.Sens_Data_Conf OT.Chip_Auth_Proof_PACE_CAM OT.AC_Pers_EAC2 OT.CA2 OT.CA3 OT.RI_EAC2 OT.Sens_Data_EAC2 OT.AC_Pers OT.Data_Authenticity OT.Data_Confidentiality OT.Data_Integrity OT.Identification OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Malfunction OT.Prot_Phys-Tamper OT.Tracing OT.DTBS_Integrity_TOE OT.EMSEC_Design OT.Lifecycle_Security OT.SCD_Secrecy OT.SCD_SVD_Corresp OT.SCD_Unique OT.SCD/SVD_Auth_Gen OT.Sig_Secure OT.Sigy_SigF OT.Tamper_ID OT.Tamper_Resistance FCS_COP.1/PACE_ENC_EAC2PP x x x FCS_COP.1/PACE_MAC_EAC1PP x x FCS_COP.1/PACE_MAC_EAC2PP x x FCS_COP.1/SHA_EAC2PP x x x x x FCS_COP.1/SIG_VER_EAC1PP x x FCS_COP.1/SIG_VER_EAC2PP x x x x FCS_COP.1/SSCDPP x x FCS_RND.1/EAC2PP x x x x X FDP_ACC.1/SCD/SVD_Generation_SSCD x x FDP_ACC.1/Signature-creation_SSCDPP x x FDP_ACC.1/SVD_Transfer_SSCDPP x FDP_ACC.1/TRM_EAC2PP x x x x FDP_ACC.1/UPD x x FDP_ACF.1/UPD x x FDP_ACF.1/SCD/SVD_Genera- tion_SSCDPP x x FDP_ACF.1/Signature-creation_SSCDPP x x FDP_ACF.1/SVD_Transfer_SSCDPP x FDP_ACF.1/TRM x x x x x x FDP_IFC.1/UPD x x FDP_IFF.1/UPD x x FDP_RIP.1/UPD x FDP_RIP.1/EAC2PP x x x x x x FDP_RIP.1/SSCDPP x x FDP_SDI.2/DTBS_SSCDPP x x FDP_SDI.2/Persistent_SSCDPP x x x FDP_UCT.1/TRM_EAC2PP x x x FDP_UIT.1/TRM_EAC2PP x x x FIA_AFL.1/Block_PIN_EAC2PP x x x x x x FIA_AFL.1/PACE_EAC1PP FIA_AFL.1/PACE_EAC2PP x FIA_AFL.1/UPD x x FIA_AFL.1/SSCDPP x FIA_AFL.1/Suspend_PIN_EAC2PP x x x x FIA_API.1/CA_EAC2PP x x x x x FIA_API.1/CA3 x x x x x x FIA_API.1/EAC1PP x FIA_API.1/PACE_CAM x x x x FIA_API.1/RI_EAC2PP x FIA_UAU.1/EAC2_Terminal_EAC2PP x x x x x FIA_UAU.1/PACE_EAC1PP x x x x x FIA_UAU.1/PACE_EAC2PP x x x x FIA_UAU.1/UPD x x FIA_UAU.1/SSCDPP x x FIA_UAU.4/PACE_EAC1PP x x x x x FIA_UAU.4/PACE_EAC2PP x x x x x FIA_UAU.5/PACE_EAC1PP x x x x x FIA_UAU.5/PACE_EAC2PP x x x x x x FIA_UAU.6/CA_EAC2PP x x x x FIA_UAU.6/CA3 x x x x x FIA_UAU.6/EAC_EAC1PP x x x x x FIA_UAU.6/PACE_EAC2PP x x x FIA_UID.1/EAC2_Terminal_EAC2PP x x x x x FIA_UID.1/PACE_EAC1PP x x x x x x FIA_UID.1/PACE_EAC2PP x x x x x FIA_UID.1/UPD x x FIA_UID.1/SSCDPP x x FMT_LIM.1/EAC2PP x FMT_LIM.1/Loader x FMT_LIM.2/EAC2PP x FMT_LIM.2/Loader x FMT_MOF.1/SSCDPP x x FMT_MSA.1/Admin_SSCDPP x x Security Target TCOS ID Version 2.0 Release 1/P6022y 133/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 OT.Update_Mechanism OT.Enc_Sign_Update OT.Update_Terminal_Auth OT.Attack_Detection OT.Key_Secrecy OT.Cap_Avail_Loader OT.Non_Interfere OT.Chip_Auth_Proof OT.Sens_Data_Conf OT.Chip_Auth_Proof_PACE_CAM OT.AC_Pers_EAC2 OT.CA2 OT.CA3 OT.RI_EAC2 OT.Sens_Data_EAC2 OT.AC_Pers OT.Data_Authenticity OT.Data_Confidentiality OT.Data_Integrity OT.Identification OT.Prot_Abuse-Func OT.Prot_Inf_Leak OT.Prot_Malfunction OT.Prot_Phys-Tamper OT.Tracing OT.DTBS_Integrity_TOE OT.EMSEC_Design OT.Lifecycle_Security OT.SCD_Secrecy OT.SCD_SVD_Corresp OT.SCD_Unique OT.SCD/SVD_Auth_Gen OT.Sig_Secure OT.Sigy_SigF OT.Tamper_ID OT.Tamper_Resistance FMT_MSA.1/Signatory_SSCDPP x x FMT_MSA.2/SSCDPP x x x FMT_MSA.3/SSCDPP x x x FMT_MSA.4/SSCDPP x x x x FMT_MTD.1/UPD_SK_PICC x x x FMT_MTD.1/UPD_KEY_READ x x x FMT_MTD.1/Activate_PIN_EAC2PP x x x x x FMT_MTD.1/Admin_SSCDPP x x FMT_MTD.1/CAPK_EAC1PP x x x FMT_MTD.1/Change_PIN_EAC2PP x x x x x FMT_MTD.1/CVCA_INI_EAC1PP x FMT_MTD.1/CVCA_INI_EAC2PP x x x x FMT_MTD.1/CVCA_UPD_EAC1PP x x x x FMT_MTD.1/CVCA_UPD_EAC2PP x x x x FMT_MTD.1/DATE_EAC2PP x x x x x FMT_MTD.1/INI_DIS_EAC2PP x x FMT_MTD.1/INI_ENA_EAC2PP x x FMT_MTD.1/Initialize_PIN_EAC2PP x x x x FMT_MTD.1/KEY_READ_EAC1PP x x x x x x FMT_MTD.1/KEY_READ_EAC2PP x x x x x FMT_MTD.1/PA_EAC1PP x x x x FMT_MTD.1/PA_EAC2PP x x x x x x FMT_MTD.1/Resume_PIN_EAC2PP x x x x x FMT_MTD.1/Signatory_SSCDPP x x FMT_MTD.1/SK_PICC_EAC2PP x x x x x FMT_MTD.1/Unblock_PIN_EAC2PP x x x x FMT_MTD.3/EAC1PP x FMT_MTD.3/EAC2PP x x x x FMT_SMF.1/EAC1PP x x x x x x FMT_SMF.1/EAC2PP x x x x x x FMT_SMF.1/UPD x FMT_SMF.1/SSCDPP x x x FMT_SMR.1 x x x x x x x x x x x FMT_SMR.1/UPD FPT_EMS.1/EAC1PP x x x FPT_EMS.1/EAC2PP x x FPT_EMS.1/UPD x FPT_EMS.1/SSCDPP x x x FPT_FLS.1/UPD x FPT_FLS.1/EAC2PP x x FPT_PHP.1/SSCDPP x x FPT_PHP.3/EAC2PP x x x FPT_TST.1/UPD x FPT_TST.1/EAC2PP x x x x x FTP_ITC.1/CA_EAC2PP x x x x FTP_ITC.1/CA3 x x x x x FTP_ITC.1/UPD x x FTP_ITC.1/PACE_EAC1PP x x x x FTP_ITC.1/PACE_EAC2PP x x x x x Table 8: SFR coverage 587 The dependency analysis for the security functional requirements given in the correspond- ing Tables of the Protection Profiles ([MREDPP], [EAC2PP], [EAC1PP], [PACEPP] and [SSCDPP]) shows that the mutual support and internal consistency between all defined functional requirements is satisfied or justified. Security Target TCOS ID Version 2.0 Release 1/P6022y 134/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 6.3.2 Security Assurance Requirements Rationale 588 The assurance package of the Protection Profile was chosen based on the pre-defined assurance package EAL4. This package permits to gain maximum assurance from posi- tive security engineering based on good commercial development practices which, though rigorous, do not require substantial specialist knowledge, skills, and other resources. EAL4 is the highest level, at which it is likely to retrofit to an existing product line in an econom- ically feasible way. EAL4 is applicable in those circumstances where users require a mod- erate to high level of independently assured security in conventional commodity TOEs and are prepared to incur additional security specific engineering costs. 589 The Selection of the component ALC_DVS.2 provides a higher assurance of the security of the travel document’s development and manufacturing especially for the secure han- dling of the travel document’s material. 590 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. It is required in the Protection Profile BSI-CC-PP-0084-2014 [ICPP] and is therefore in- cluded in this ST. 591 The Selection of the component AVA_VAN.5 provides a higher assurance of the security by vulnerability analysis to assess the resistance to penetration attacks performed by an attacker possessing a high attack potential. 592 The set of assurance components being part of EAL4 fulfils all dependencies a priori. 593 The component ALC_DVS.2 has no dependencies. 594 The component ATE_DPT.2 has the following dependencies: ADV_ARC.1, ADV_TDS.3 and ADV_FUN.1. All of these are met or exceeded in the EAL4 assurance package. 595 The component AVA_VAN.5 has the following dependencies: ADV_ARC.1, ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, AGD_OPE.1, AGD_PRE.1, and ATE_DPT.1. All of these are met or exceeded in the EAL4 assurance package. 596 Note that the Protection Profile BSI-PP-0087 [MREDPP] refined the Security Assurance Requirements ALC_DEL, ALC_DVS, ALC_CMS, ALC_CMC, ADV_ARC, ADV_FSP, ATE_COV, AGD_OPE, AVA_VAN, ATE_FUN, and ATE_IND. They are all considered for the TOE. Security Target TCOS ID Version 2.0 Release 1/P6022y 135/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 7 TOE Summary Specification 597 This section presents an overview of the security functionalities implemented by the TOE and the assurance measures applied to ensure their correct implementation. 598 According to the SFRs the TOE provides the following functionalities • General protection of User data and TSF data • Identification and authentication • Access control • Cryptographic functions • Protection of communication • Accuracy of the TOE security functionality / Self-protection 599 Almost any security function is supported by some coordinated and matching SFRs. In the following the most important SFRs are associated to security functions implemented by the TOE. 7.1 General Protection of User Data and TSF Data 600 According to the SFRs FDP_ACC.1 and FDP_ACF.1 and their iterations the access to User Data is restricted by defined rules laid down in the certified object system. The details can be found in the corresponding SFPs. Note that the TOE enforces these access rules, but there is no a priori protection of a said object. The access rights may be provided by certificates. The TOE is able to interpret these certificates accordingly. 601 Residual information of sensitive data in previously used resources will not be available after its usage (FDP_RIP.1). Session keys and message authentication keys will be de- stroyed after reset or termination of the secure messaging channel (FCS_CKM.4). The TOE hides the correlation of power or timing variations and the command execution ac- cessing sensitive user data as different keys and passwords (FPT_EMS.1). In case of a malfunction, operating errors or integrity check failures the TOE enters a secure state (FPT_FLS.1). This is supported by the functional services of the hardware. 602 The TOE executes self tests (FPT_TST.1) to demonstrate the correct operation of the TSF and its confidentiality protection capabilities. In case of failures, FPT_FLS.1 requires the preservation of a secure state in order to protect the user data, TSF data and security services. 603 The SFRs supporting protection and the management of User and TSF data are listed below: FDP_SDI.2/DTBS_SSCDPP FDP_SDI.2/Persistent_SSCDPP FMT_MSA.1/Admin_SSCDPP FMT_MSA.1/Signatory_SSCDPP FMT_MSA.2/SSCDPP FMT_MSA.3/SSCDPP FMT_MSA.4/SSCDPP FMT_MTD.1/Activate_PIN_EAC2PP FMT_MTD.1/Admin_SSCDPP Security Target TCOS ID Version 2.0 Release 1/P6022y 136/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FMT_MTD.1/CAPK_EAC1PP FMT_MTD.1/Change_PIN_EAC2PP FMT_MTD.1/CVCA_INI_EAC1PP FMT_MTD.1/CVCA_INI_EAC2PP FMT_MTD.1/CVCA_UPD_EAC1PP FMT_MTD.1/CVCA_UPD_EAC2PP FMT_MTD.1/DATE_EAC2PP FMT_MTD.1/INI_DIS_EAC2PP FMT_MTD.1/INI_ENA_EAC2PP FMT_MTD.1/Initialize_PIN_EAC2PP FMT_MTD.1/KEY_READ_EAC1PP FMT_MTD.1/KEY_READ_EAC2PP FMT_MTD.1/PA_EAC2PP FMT_MTD.1/Resume_PIN_EAC2PP FMT_MTD.1/Signatory_SSCDPP FMT_MTD.1/SK_PICC_EAC2PP FMT_MTD.1/Unblock_PIN_EAC2PP FMT_MTD.1/UPD_KEY_READ FMT_MTD.1/UPD_SK_PICC FMT_MTD.3/EAC1PP FMT_MTD.3/EAC2PP 7.2 Identification and Authentication 604 The protocols for identification and authentication of users and devices are described in the TCOS Guidance [TCOSGD]. The roles assigned after successful authentication are listed in FMT_SMR.1 and its iterations. 605 The security and the reliability of the identification and authentication are supported by the correct key agreement (FIA_UAU.1, FIA_UAU.4, FIA_UAU.5 and FIA_UAU.6) and the quality of random numbers (FCS_RND.1). This concerns also the authentication via the contactless. As soon the authentication state is left, the session keys cannot be used an- ymore (FCS_CKM.4). 606 User is authenticated with means of PACE passwords, PINs and PUKs, which are bound by corresponding failure or usage counters (FIA_AFL.1). A Terminal is authenticated by using a correct key derived from the provided certificate and the authentication context. 607 Before a user or device is identified only dedicated commands can be executed. This is supported by the iterated SFRs FIA_UID.1. 608 The SFRs supporting identification and authentication are listed below: FIA_API.1/RI_EAC2PP FIA_UAU.1/EAC2_Terminal_EAC2PP FIA_UAU.1/PACE_EAC1PP FIA_UAU.1/PACE_EAC2PP FIA_UAU.1/SSCDPP Security Target TCOS ID Version 2.0 Release 1/P6022y 137/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FIA_UAU.1/UPD FIA_UAU.4/PACE_EAC1PP FIA_UAU.4/PACE_EAC2PP FIA_UAU.5/PACE_EAC1PP FIA_UAU.5/PACE_EAC2PP FIA_UAU.6/CA_EAC2PP FIA_UAU.6/CA3 FIA_UAU.6/EAC_EAC1PP FIA_UAU.6/PACE_EAC2PP FIA_UID.1/EAC2_Terminal_EAC2PP FIA_UID.1/PACE_EAC1PP FIA_UID.1/PACE_EAC2PP FIA_UID.1/SSCDPP FIA_UID.1/UPD FMT_SMR.1 FMT_SMR.1/UPD 7.3 Access Control 609 The access to User Data is restricted according to the different iterations of the SFRs FDP_ACC.1 and FDP_ACF.1. 610 The access to the TOE security functions and the TSF data is controlled by the function- ality of the class FMT. 611 The management of the authentication data and corresponding security attributes is im- plemented according [MREDPP]. The TOE disallows the export of session and authenti- cation keys, passwords and other sensitive user and TSF data. Note that the TOE en- forces the access rights of elements of the object system, i.e. data specified as unpro- tected will be exposed by the TOE. For details refer to the Administrator’s Guidance [TCOSGD]. 612 The SFRs supporting access control are listed below: FDP_ACC.1/SCD/SVD_Generation_SSCD FDP_ACC.1/Signature-creation_SSCDPP FDP_ACC.1/SVD_Transfer_SSCDPP FDP_ACC.1/TRM_EAC2PP FDP_ACC.1/UPD FDP_ACF.1/SCD/SVD_Generation_SSCDPP FDP_ACF.1/Signature-creation_SSCDPP FDP_ACF.1/SVD_Transfer_SSCDPP FDP_ACF.1/TRM FDP_ACF.1/UPD FDP_IFC.1/UPD FDP_IFF.1/UPD FDP_RIP.1/EAC2PP Security Target TCOS ID Version 2.0 Release 1/P6022y 138/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FDP_RIP.1/SSCDPP FDP_RIP.1/UPD FMT_MOF.1/SSCDPP FMT_SMF.1/EAC1PP FMT_SMF.1/EAC2PP FMT_SMF.1/SSCDPP FMT_SMF.1/UPD 7.4 Cryptographic Functions 613 The TOE provides a hybrid deterministic random number generator of class DRG.4 ac- cording to [AIS31] (FCS_RND.1). 614 The TOE implements cryptographic checksum functions, including hash functions used for signature verification and key generation and derivation and message authentication codes (MACs) addressed by FCS_COP.1. 615 The TOE provides the symmetric encryption algorithm AES with standardized key lengths of 128, 192 and 256 bits (FCS_COP.1). 616 The TOE implements asymmetric crypto algorithms used for encryption/decryption, key agreement and digital signatures based elliptic curves. The Selection of the curve used for ECC based algorithm might be a security issue. The TOE supports only the curves defined in [ECCTR] and [FIPS186]. 617 Cryptographic functions are necessary for different security protocols implemented by the TOE, e.g. PACE, Chip and Terminal Authentication, or the Update procedure. 618 Cryptographic keys are explicitly deleted by overwriting the memory data with zeros or random numbers, e.g. the new key according to FCS_CKM.4. 619 SFRs supporting cryptographic functions are listed below: FCS_CKM.1/CA_EAC1PP FCS_CKM.1/CA3 FCS_CKM.1/CAM FCS_CKM.1/DH_PACE_EAC1PP FCS_CKM.1/DH_PACE_EAC2PP FCS_CKM.1/SSCDPP FCS_CKM.1/UPD_DEC FCS_CKM.1/UPD_INT FCS_CKM.1/UPD_ITC FCS_CKM.4/EAC2PP FCS_CKM.4/SSCDPP FCS_CKM.4/UPD FCS_COP.1/CA_ENC_EAC1PP FCS_COP.1/CA_MAC_EAC1PP FCS_COP.1/CAM FCS_COP.1/PACE_ENC_EAC1PP FCS_COP.1/PACE_ENC_EAC2PP Security Target TCOS ID Version 2.0 Release 1/P6022y 139/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 FCS_COP.1/PACE_MAC_EAC1PP FCS_COP.1/PACE_MAC_EAC2PP FCS_COP.1/SHA_EAC2PP FCS_COP.1/SIG_VER_EAC1PP FCS_COP.1/SIG_VER_EAC2PP FCS_COP.1/SSCDPP FCS_COP.1/UPD_DEC FCS_COP.1/UPD_INT FCS_COP.1/UPD_ITC FCS_COP.1/UPD_SIG FCS_RND.1/EAC2PP 7.5 Protection of Communication 620 The secure data exchange in a trusted channel is required by FTP_ITC.1. It is supported by cryptographic operations. The TOE enforces a protected communication over the con- tactless interface by means of the PACE protocol. It is supported by FDP_UCT.1 and FDP_UIT.1. 621 The randomness of the parameters of the PACE protocol is guaranteed by the RNG class DRG.4 (FCS_RND.1/PACE). 622 The strength of algorithms for ensuring confidentiality and integrity is supplied by FCS_COP.1. 623 The SFRs supporting cryptographic functions are listed below: FDP_UCT.1/TRM_EAC2PP FDP_UIT.1/TRM_EAC2PP FTP_ITC.1/CA_EAC2PP FTP_ITC.1/CA3 FTP_ITC.1/PACE_EAC1PP FTP_ITC.1/PACE_EAC2PP FTP_ITC.1/UPD 7.6 Accuracy of the TOE security functionality /Self-protection 624 The operating system of the TOE protects the security functionality of the TOE as soon as it installed during Installation Phase. The TOE will not emit physical or logical data infor- mation on security User Data outside the secure channels controlled by the operating system (FPT_EMS.1). User data and TSF data are protected by the TOE if processed or transferred within different parts of the TOE according to the TOE Data Processing Policy of the hardware ST. 625 The TOE will resist physical manipulation and probing and enter a secure state in case a failure occurs. This functionality is supported also by the hardware, which was approved in a separate evaluation process. 626 Dedicated test software is no more available after the TOE is finished (FMT_LIM.1, FMT_LIM.2). These functions are disabled for the TOE in the operational life cycle phase. Security Target TCOS ID Version 2.0 Release 1/P6022y 140/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 627 During TOE manufacturing the chip hardware provides means to store Initialization Data to identify the hardware. 628 The SFRs supporting self-protection and assurance of the cryptographic functionality are listed below: FAU_SAS.1/EAC2PP FAU_SAS.1/UPD FIA_AFL.1/Block_PIN_EAC2PP FIA_AFL.1/PACE_EAC2PP FIA_AFL.1/SSCDPP FIA_AFL.1/Suspend_PIN_EAC2PP FIA_AFL.1/UPD FIA_API.1/CA_EAC2PP FIA_API.1/CA3 FIA_API.1/EAC1PP FIA_API.1/PACE_CAM FMT_LIM.1/EAC2PP FMT_LIM.1/Loader FMT_LIM.2/EAC2PP FMT_LIM.2/Loader FPT_EMS.1/EAC1PP FPT_EMS.1/EAC2PP FPT_EMS.1/SSCDPP FPT_EMS.1/UPD FPT_FLS.1/EAC2PP FPT_FLS.1/UPD FPT_PHP.1/SSCDPP FPT_PHP.3/EAC2PP FPT_TST.1/EAC2PP FPT_TST.1/UPD 7.7 Statement of Compatibility 629 This is the statement of compatibility between this Composite Security Target and the Security Target Chip of the underlying hardware [HWST]. 7.7.1 Relevance of Hardware TSFs 630 In the following lists the relevance of the hardware security services (SS) and functions (SF) for the composite security target is considered. Relevant: • SS.RNG: Random Number Generator • SS.TDES: Triple-DES (TDES) Co-processor • SS.AES: AES Co-processor Security Target TCOS ID Version 2.0 Release 1/P6022y 141/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 • SS.CRC: Cyclic Redundancy Check • SF.OPC: Control of Operating Conditions • SF.PHY: Protection against Physical Manipulation • SF:PUF: User Data Protection using PUF • SF.LOG: Logical Protection • SF.MEM_ACC: Memory Access Control • SF.SFR_ACC: Special Function Register Access Control Not relevant: • SS.RECONFIG: Customer Reconfiguration • SF.COMP: Protection of Mode Control • SF.FFW: Firmware Firewall • SF.FIRMWARE: Firmware Support 7.7.2 Security Requirements Security Functional Requirements 631 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 TOE related to the Composite ST: 632 The Security Requirements of the TOE of the classes FAU, FCS; FIA, FDP, FMT and FTP are specific for the Operating System and have no conflicts with the underlying hardware. 633 The Security Requirements of the TOE of the classes FPT are supported by the Security Feature SF.OPC of the hardware ([HWST]) and the AVA_VAN.5 evaluation (FPT_EMS). The requirements FPT_FLS and FPT_PHP are also not conflicting with the requirements for the hardware. They support each other. The requirements for test (FPT_TST) in the operating system are supported by various tests of the hardware, and there are no con- flicts with the underlying hardware. Security Requirements of the hardware 634 The Security Requirements of the TOE’s hardware based on PP-0084 [ICPP, sec.6.1] can be mapped to Security Requirements of the TOE. They show no conflict between each other. • FAU_SAS.1[HW] is covered by FAU_SAS.1/EAC2PP and FAU_SAS.1/UPD of the Composite ST • FDP_IFC.1 concerns information flow policy between parts of the hardware • FDP_SDC.1, FDP_SDI.1 concerns low level stored data protection (confidentiality, integrity) • FDP_ITT.1 concerns basic internal transfer protection of the hardware • FMT_LIM.1[HW] is covered by FMT_LIM.1 EAC2PP and FMT_LIM.1/Loader of the Composite ST • FMT_LIM.2[HW] is covered by FMT_LIM.2/EAC2PP and FMT_LIM.2/Loader of the Composite ST • FRU_FLT.2, FPT_FLS.1 covered by FPT_FLS.1/EAC2PP, FPT_FLS.1/UPD and FPT_FLS.1/SSCDPP of the Composite ST • FPT_ITT.1 concerns basic hardware internal TSF data transfer protection • FPT_PHP.3 concerns the resistance to physical attacks and is covered by FPT_PHP.3/EAC2PP Security Target TCOS ID Version 2.0 Release 1/P6022y 142/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 635 The additional Security Requirements of the TOE’s hardware defined in [HWST] can be mapped to Security Requirements of the TOE too. They show no conflict between each other. • FCS_CKM.1[PUF], FCS_CKM.4[PUF], FCS_COP.1[PUF_AES], FCS_COP.1\ [PUF_MAC]: concerns internal data protection and therefore does not conflict with key generation in this ST. • FCS_COP.1[AES]: covered by FCS_COP.1/CA_ENC_EAC1PP, FCS_COP.1/ CA_\ MAC_EAC1PP, FCS_COP.1/PACE_ENC_EAC1PP, FCS_COP.1/PACE_ENC_\ EAC2PP, FCS_COP.1/PACE_MAC_EAC1PP, FCS_COP.1/PACE_MAC_EAC2PP of the Composite ST • FCS_CKM.4[TDES]: is covered by FCS_CKM.4/EAC2PP of the Composite ST • FCS_COP.1[TDES]: matches FCS_COP.1.1/CA_ENC_EAC1PP, FCS_COP.1.1/ CA_MAC_EAC1PP, FCS_COP.1.1/PACE_ENC_EAC1PP and FCS_COP.1/ PACE_MAC_EAC1PP, which uses TDES due to interoperability reasons. • FCS_RNG.1[HW]: matches FCS_RNG.1 of the Composite ST • FDP_ACC.1 concerns the Memory Access Control Policy on software tasks ac- cessing assigned data in memories, this is covered by FDP_ACC.1 and its iterations of the Composite TOE. • FDP_ACF.1 describes the Memory Access Control policy enforced by the hard- ware, this is covered by policy enforcing FDP_ACF.1 of the Composite TOE and its iterations • FDP_SDI.1[EEPROM, RAM], FDP_SDI.2{HW, FW, EEPROM, RAM,ROM] con- cerns low level stored data protection and monitoring and does not conflict with the requirements of this ST • FMT_MSA.1 concerns the management of security attributes on hardware’s level, does not conflict with the SFRs of the TOE • FMT_MSA.3 concerns the management of security attributes on hardware’s level, does not conflict with the SFRs of the TOE • FMT_SMF.1 concerns the access of the configuration registers of the Memory Management Unit, does not conflict with the SFRs of the TOE • FPT_PHP.3 concerns the resistance to physical attacks and is covered by FPT_PHP.3/EAC2PP of the TOE Security Target TCOS ID Version 2.0 Release 1/P6022y 143/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 Security Assurance Requirements 636 The level of assurance of the TOE is EAL 4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5. 637 The chosen level of assurance of the hardware is EAL 6 augmented with ALC_FLR.1 and ASE_TSS.2. This includes ALC_DVS.2, ATE_DPT.3 and AVA_VAN.5. 638 This shows that the Assurance Requirements of the TOE matches the Assurance Re- quirements of the hardware. 7.7.3 Security Objectives 639 The Security Objectives of the TOE and the hardware can be mapped or are not relevant. They show no conflict between each other. 640 The following Security Objectives of the TOE are related to the Composite ST and are not relevant for the hardware: • OT.Cap_Avail_Loader • OT.Non_Interfere • OT.Chip_Auth_Proof • OT.Sens_Data_Conf • OT.Chip_Auth_Proof_PACE_CAM • OT.AC_Pers_EAC2 • OT.CA2 • OT.CA3 • OT.RI_EAC2 • OT.Sens_Data_EAC2 • OT.AC_Pers • OT.Data_Authenticity • OT.Data_Confidentiality • OT.Data_Integrity • OT.Identification • OT.Tracing • OT.DTBS_Integrity_TOE • OT.SCD_Secrecy • OT.SCD_SVD_Corresp • OT.SCD_Unique • OT.SCD/SVD_Auth_Gen • OT.Sig_Secure • OT.Sigy_SigF • OT.Tamper_ID • OT.Update_MechanismTOE • OT.Enc_Sign_Update • OT.Update_Terminal_Auth • OT.Attack_Detection • OT.Key_Secrecy 641 Security Objectives of the TOE related to the Composite ST and that can be mapped to Objectives of the hardware: • OT.Prot_Abuse-Func • OT.Prot_Inf_Leak Security Target TCOS ID Version 2.0 Release 1/P6022y 144/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 • OT.Prot_Malfunction • OT.Prot_Phys-Tamper • OT.EMSEC_Design • OT.Lifecycle_Security • OT.Tamper_Resistance 642 The following Security Objectives of the Hardware are covered by objectives of the TOE • O.Leak-Forced and O.Leak-Inherent are covered by OT.Prot_Inf_Leak • O.Phys-Probing is covered by OT.Prot_Phys-Tamper • O.Malfunction is covered by OT.Prot_Malfunction • O.Phys-Manipulation is covered by OT.Prot_Phys-Tamper • O.Abuse-Func is covered by • O.Identification is covered by OT.Identification • O.RND, O.TDES, O.AES are covered by OT.Data_Authenticity, OT.Data_Confiden- tiality, OT.Data_Integrity for the TOE using this hardware functionality 643 The remaining objectives of the hardware concern the internal processing of the hardware and are not related to specific objectives of the TOE. They do not conflict to each other: • O.CUST_RECONF_PLAIN • O.EEPROM_INTEGRITY • O.FM_FW • O.MEM_ACCESS • O.SFR_ACCESS • O.PUF 644 The Security Objectives for the Environment of the TOE are related to the life cycle phase “Operational Use” and do not conflict with the Security Objectives for the hardware which are related to the manufacturing process. Therefore they do not conflict to each other. 645 Security Objective for the environment of TOE’s hardware: • OE.Resp-Appl • OE.Process-Sec-IC 646 Security Objective for the environment of composite TOE: • OE.Lim_Block_Loader • OE.Auth_Key_Travel_Document • OE.Authoriz_Sens_Data • OE.Exam_Travel_Document • OE.Ext_Insp_Systems • OE.Ext_Insp_Systems • OE.Chip_Auth_Key • OE.RestrictedIdentity • OE.Terminal_Authentication • OE.Legislative_Compliance • OE.Passive_Auth_Sign • OE.Personalization • OE.Terminal • OE.Travel_Document_Holder • OE.CGA_QCert • OE.DTBS_Intend Security Target TCOS ID Version 2.0 Release 1/P6022y 145/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 • OE.DTBS_Protect • OE.HID_VAD • OE.Signatory • OE.SSCD_Prov_Service • OE.SVD_Auth • OE.Code_Confidentiallity • OE.Secure_Environment • OE.Eligible_Terminals_Only 7.7.4 Conclusion 647 No contradictions between the Security Targets of the TOE and the underlying hardware can be found. 7.8 Assurance Measures 648 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 Security Assurance Requirements for the TOE. Development ADV_ARC.1 Security Architecture Description TCOS ID 2.0 Release 1 ADV_FSP.4 Functional Specification TCOS ID 2.0 Release 1 ADV_IMP.1 Implementation of the TSF TCOS ID 2.0 Release 1 ADV_TDS.3 Modular Design of TCOS ID 2.0 Release 1 Guidance documents AGD_OPE.1 User Guidance TCOS ID 2.0 Release 1 AGD_PRE.1 Administrator Guidance TCOS ID 2.0 Release 1 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 ID 2.0 Release 1 ALC_TAT.1, ALC_DVS.2 Development Tools and Development Security for TCOS ID 2.0 Release 1 Tests ATE_COV.2, ATE_DPT.2 Test Documentation for TCOS ID 2.0 Release 1 ATE_FUN.1 Test Documentation of the Functional Testing Vulnerability assessment AVA_VAN.5 Independent Vulnerability Analysis TCOS ID 2.0 Release 1 649 The developer team uses a configuration management system that supports the genera- tion of the TOE. The configuration management system is well documented and identifies all different configuration items. The configuration management tracks the implementation representation, design documentation, test documentation, user documentation, adminis- trator documentation, and security flaws. The security of the configuration management is described in detail in a separate document. 650 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 Security Target TCOS ID Version 2.0 Release 1/P6022y 146/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 the user’s version. The Administrator and the User are provided with necessary documen- tation for installation, personalization and start-up of the TOE. 651 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 design requirements. 652 The tools used in the development environment are appropriate to protect the confidenti- ality 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. 653 The development department is equipped with organizational and personnel means that are necessary to develop the TOE. The testing and the vulnerability analysis require tech- nical and theoretical know-how available at T-Systems International GmbH. 654 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 ID Version 2.0 Release 1/P6022y 147/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 Appendix Glossary and Acronyms 655 The terminology and abbreviations of Common Criteria version 3.1 [CC], Revision 5 apply to this ST. The following table is taken over from the PP [MREDPP] Acronyms Acronym Term CAP Composed Assurance Package CC Common Criteria EAL Evaluation Assurance Level IC Integrated Circuit OS Operating System OSP Organizational Security Policy PKI Public Key Infrastructure PP Protection Profile SAR Security Assurance Requirement SFP Security Function Policy SFR Security Functional Requirement SPD Security Problem Definition ST Security Target TOE Target of Evaluation Security Target TCOS ID Version 2.0 Release 1/P6022y 148/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 References [AIS31] Bundesamt für Sicherheit in der Informationstechnik, Anwendungshinweise und Interpre- tationen zum Schema (AIS), AIS 31, A proposal for Functionality classes for random num- ber generators Version 2.0 vom 18.09.2011, Bundesamt für Sicherheit in der Informati- onstechnik (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) [ANSX9.63] American National Standard X9.63-2001, Public Key Cryptography for the Financial Ser- vices Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography, 2005-11 [ALGO] ETSI Technical Specification TS 119 312: Electronic Signatures and Infrastructures (ESI); Cryptographic Suites; European Telecommunication Standards Institute (ETSI), version 1.2.1 or later, 2017-0511 [CC] Common Criteria for Information Technology Security Evaluation, Version 3.1, Part 1: Introduction and general model; Version 3.1, April 2017, CCMB-2017-04-001, Part 2: Security functional components; Version 3.1, April 2017, CCMB-2017-04-002, Part 3: Security assurance components; Version 3.1, April 2017, CCMB-2017-04-003 Common Methodology for Information Technology Security Evaluation, Evaluation metho- dology, Version 3.1, April 2017, CCMB-2017-04-004 [EACTR] Technical Guideline TR-03110: Advanced Security Mechanisms for Machine Readable Travel Documents, Bundesamt für Sicherheit in der Informationstechnik (BSI), Part 1 – eMRTDs with BAC/PACEv2 and EACv1, version 2.20, 2015-02 Part 2 – Protocols for electronic IDentification, Authentication and trust Services (eIDAS), version 2.21, 2016-12 Part 3 – Common Specifications, version 2.21, 2016-12 Part 4 – Applications and Document Profiles, version 2.21, 2016-12 [BACPP] CC Protection Profile Machine Readable Travel Document with “ICAO Application” Machine Readable Travel Document with „ICAO Application", Basic Access Control, BSI- CC-PP-0055-2009, Version 1.10, 25th March 2009, Registered and Certified by Bun- desamt für Sicherheit in der Informationstechnik under BSI-PP-0055-2009, 2009-03 [EAC1PP] CC Protection Profile Machine Readable Travel Document with “ICAO Application” Exten- ded Access Control with PACE (EAC PP) Version 1.3.2, Registered and Certified by Bun- desamt für Sicherheit in der Informationstechnik under BSI-PP-0056-V2-2012-MA02, 2012-12 Security Target TCOS ID Version 2.0 Release 1/P6022y 149/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 [EAC2PP] CC Protection Profile Electronic Document implementing Extended Access Control Version 2 defined in BSI TR-03110 Version 1.01, Registered and Certified by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC-PP-0086-2015, 2015-05 [ECCTR] Technical Guideline TR-03111: Elliptic Curve Cryptography, Version 2.0, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2012-08 [eIDAS] Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014 on electronic identification and trust services for electronic transactions in the inter- nal market and repealing Directive 1999/93/EC, Official Journal of the EU, 2014 L 257/73, 2014-08-28 Commission Implementing Decision (EU) 2016/650 of 25 April 2016, laying down stand- ards for the security assessment of qualified signature and seal creation devices pursuant to Articles 30(3) and 39(2) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market, Official Journal 2016 of the EU, L 109/40, 2016-04-26 [FIPS180] Federal Information Processing Standards Publication FIPS PUB 180-4, Secure Hash Standard (SHS), 2012-03 [FIPS186] Federal Information Processing Standards Publication FIPS PUB 186-4, Digital Signature Standard (DSS), July 2013 [FIPS197] Federal Information Processing Standards Publication 197, Advanced Encryption Stand- ard (AES), U.S. Department of Commerce/National Institute of Standards and Technology, 2001-11-26 [HWCR] Certification Report of the underlying hardware platform, BSI-DSZ-CC-1059-V2-2019 for NXP Secure Smart Card Controller P6022y VB* including IC Dedicated Software from NXP Semiconductors Germany GmbH, Bundesamt für Sicherheit in der Informationstech- nik (BSI), 2019-06 [HWST] Security Target of the underlying hardware platform, NXP Secure Smart Card Controller P6022y VB, Security Target Lite, NXP Semiconductors, Rev. 2.2, 27 November 2018, BSI-DSZ-CC-1059-V2-2019 [ICAOSAC] ICAO Machine Readable Travel Documents, Technical Report, Supplemental Access Control for Machine Readable Travel Documents, Version 1.01, ICAO, 2010-11 [ICAO9303] ICAO Doc 9303, Machine Readable Travel Documents, Seventh Edition, 2015 [ISO7816] ISO 7816-4:2013, Identification cards – Integrated circuit cards with contacts, Part 4: Or- ganization, security and commands for interchange, ISO, 2013-04 Security Target TCOS ID Version 2.0 Release 1/P6022y 150/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 [ISO9796-2] ISO/IEC 9796-2:2010 Information technology—Security techniques—Digital signature schemes giving message recovery – Part 2: Integer factorization based mechanisms, ISO, 2010-12 [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 cards – Proximity cards, Parts 1-4 and Amendments, 2008-2014 [MREDPP] CC Protection Profile Machine-Readable Electronic Documents based on BSI TR-03110 for Official Use [MR.ED-PP], Version 2.03, Registered and Certified by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC-PP-0087-V2-MA-01, 2016-07 [MREDONPP] CC Protection Profile Machine-Readable Electronic Documents – Optionales Nachladen (Optional Post-Emission Updates) [MR.ED-ON-PP], Version 0.9.2, Registered and Certi- fied by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC-PP-0090-2016, 2016-08 [PACEPP] CC Protection Profile Machine Readable Travel Document using Standard Inspection Pro- cedure with PACE, Version 1.01, Registered and Certified by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC-PP-0068-V2-2011-MA01, 2014-07 [ICPP] Security IC Platform Protection Profile with Augmentation Packages Version 1.0, Regis- tered and Certified by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC- PP-0084-2014, 2014-01 [RFC5639] M. Lochter, J. Merkle, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, RFC 5639, IETF, 2010-03 [SP800-38A] Recommendation for Block Cipher Modes of Operation: Methods and Techniques, NIST Special Publication 800-38A, National Institute of Standards and Technology, December 2001 [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 [SP800-67] Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, NIST Special Publication 800-67, Revised January 2012, National Institute of Standards and Technology, 2012-01 Security Target TCOS ID Version 2.0 Release 1/P6022y 151/151 Specification of the Security Target TCOS ID Version 2.0 Release 1 Version: 2.0.1 Stand: 2019-07-26 T-Systems International GmbH, 2019 [SSCDPP] Protection Profiles for Secure Signature Creation Device – Part 2: Device with Key Gener- ation, EN 419211-2:2013, CEN/ISSS, Certified by Bundesamt für Sicherheit in der Infor- mationstechnik under BSI-CC-PP-0059-2009-MA-02, 2016-06 [TCOSGD] Administrator’s Guidance TCOS ID Version 2.0 Release 1, T-Systems International GmbH, Version 1.0, 2019-07 [TR02102] Technische Richtlinie TR-02102 Kryptographische Verfahren Empfehlungen und Schlüs- sellängen, Version 2015-01, Bundesamt für Sicherheit in der Informationstechnik (BSI), 2015-02