IDentity Applet v3.4/eIDAS Security Target
Page 1 of 191
ID&TRUST
IDENTITY APPLET V3.4-P2/EIDAS
ELECTRONIC IDENTITY CARD WITH PACE-GM,
PACE-CAM, EXTENDED ACCESS CONTROL V1
AND V2, RESTRICTED IDENTIFICATION AND ACTIVE
AUTHENTICATION
SECURITY TARGET
COMMON CRITERIA / ISO 15408
EAL4+
2022
Classification: Public
© Copyright
ID&Trust Ltd.
IDentity Applet v3.4/eIDAS Security Target
Page 2 of 191
Revision history
Version Date Information
V1.00 18.08.2020 Final version
V1.01 16.09.2020 Minor modification
V1.02 13.10.2020 Update references
V1.03 13.05.2022 Updated TOE identification data, TOE name, ST Title, TOE Description
and Bibliography.
V1.04 19.07.2022 Update Bibliography and Platform’s Certification IDs.
v1.05 19.09.2022 Update Bibliography and Platform’s Certification IDs.
v1.06 01.02.2023 Update Bibliography and TOE Reference
IDentity Applet v3.4/eIDAS Security Target
Page 3 of 191
Table of Contents
1. ST INTRODUCTION ........................................................................................................... 8
1
1.1. ST REFERENCE ........................................................................................................ 8
2
1.2. TOE Reference ....................................................................................................... 8
3
1.3. TOE Overview......................................................................................................... 9
4
1.3.1. TOE TYPE......................................................................................................... 9
5
1.3.2. TOE DEFINITION AND OPERATIONAL USAGE.......................................................11
6
1.3.3. TOE MAJOR SECURITY FEATURES FOR OPERATIONAL USE .................................12
7
1.3.4. NON-TOE HARDWARE/SOFTWARE/FIRMWARE.....................................................12
8
1.4. TOE DESCRIPTION ..................................................................................................14
9
1.4.1. PRODUCT TYPE ................................................................................................14
10
1.4.2. COMPONENTS OF THE TOE ...............................................................................15
11
1.4.3. TOE LIFE CYCLE ..............................................................................................18
12
1.4.4. TOE SECURITY FUNCTIONS...............................................................................20
13
1.4.5. FEATURES OF THE IDENTITY APPLET..................................................................21
14
2. CONFORMANCE CLAIMS ..................................................................................................33
15
2.1. CC Conformance Claim .........................................................................................33
16
2.2. PP Claim................................................................................................................33
17
2.3. Package Claim.......................................................................................................35
18
2.4. Conformance Rationale..........................................................................................36
19
2.5. Statement of Compatibility......................................................................................38
20
2.5.1. SECURITY FUNCTIONALITIES..............................................................................38
21
2.5.2. OSPS ..............................................................................................................39
22
2.5.3. SECURITY OBJECTIVES .....................................................................................39
23
2.5.4. SECURITY REQUIREMENTS ................................................................................44
24
2.5.5. ASSURANCE REQUIREMENTS.............................................................................54
25
2.6. Analysis..................................................................................................................54
26
IDentity Applet v3.4/eIDAS Security Target
Page 4 of 191
3. SECURITY PROBLEM DEFINITION......................................................................................55
27
3.1. Introduction ............................................................................................................55
28
3.1.1. ASSETS............................................................................................................55
29
3.1.2. SUBJECTS ........................................................................................................57
30
3.2. Threats...................................................................................................................60
31
3.2.1. THREATS FROM EAC1PP..................................................................................61
32
3.2.2. THREATS FROM EAC2PP..................................................................................61
33
3.2.3. THREATS FROM PACEPP .................................................................................61
34
3.2.4. THREATS FROM SSCDPP .................................................................................62
35
3.3. Organizational Security Policies .............................................................................62
36
3.3.1. OSPS FROM EAC1PP ......................................................................................62
37
3.3.2. OSPS FROM EAC2PP ......................................................................................63
38
3.3.3. OSPS FROM PACEPP......................................................................................63
39
3.3.4. OSPS FROM SSCDPP......................................................................................63
40
3.3.5. ADDITIONAL OSPS............................................................................................64
41
3.4. Assumptions ..........................................................................................................65
42
3.4.1. ASSUMPTIONS FROM EAC1PP ..........................................................................65
43
3.4.2. ASSUMPTIONS FROM EAC2PP ..........................................................................65
44
3.4.3. ASSUMPTIONS FROM PACEPP..........................................................................65
45
3.4.4. ASSUMPTIONS FROM SSCDPP..........................................................................65
46
4. SECURITY OBJECTIVES ...................................................................................................66
47
4.1. Security Objectives for the TOE .............................................................................66
48
4.1.1. SECURITY OBJECTIVES FOR THE TOE FROM EAC1PP........................................66
49
4.1.2. SECURITY OBJECTIVES FOR THE TOE EAC2PP .................................................67
50
4.1.3. SECURITY OBJECTIVES FOR THE TOE PACEPP.................................................67
51
4.1.4. SECURITY OBJECTIVES FOR THE TOE SSCDPP.................................................68
52
4.1.5. ADDITIONAL SECURITY OBJECTIVES FOR THE TOE .............................................69
53
4.2. Security Objectives for the Operational Environment..............................................69
54
IDentity Applet v3.4/eIDAS Security Target
Page 5 of 191
4.2.1. SECURITY OBJECTIVES FROM EAC1PP .............................................................69
55
4.2.2. SECURITY OBJECTIVES FROM EAC2PP .............................................................69
56
4.2.3. SECURITY OBJECTIVES FROM PACEPP.............................................................70
57
4.2.4. SECURITY OBJECTIVES FROM SSCDPP.............................................................70
58
4.2.5. ADDITIONAL SECURITY OBJECTIVES FOR THE ENVIRONMENT...............................70
59
4.3. Security Objective Rationale ..................................................................................71
60
5. EXTENDED COMPONTENTS DEFINITION ............................................................................75
61
6. SECURITY REQUIREMENTS ..............................................................................................76
62
6.1. Security Functional Requirements..........................................................................77
63
6.1.1. Class FCS.......................................................................................................78
64
6.1.2. Class FIA ........................................................................................................96
65
6.1.3. Class FDP.....................................................................................................115
66
6.1.4. Class FTP .....................................................................................................130
67
6.1.5. Class FAU.....................................................................................................133
68
6.1.6. Class FMT.....................................................................................................133
69
6.1.7. Class FPT .....................................................................................................158
70
6.2. Security Assurance Requirements for the TOE ....................................................165
71
6.3. Security Requirements Rationale .........................................................................166
72
6.3.1. Security Functional Requirements Rationale.................................................166
73
6.3.2. Rationale for SFR’s Dependencies................................................................170
74
6.3.3. Security Assurance Requirements Rationale ................................................170
75
6.3.4. Security Requirements – Internal Consistency ..............................................171
76
7. TOE SUMMARY SPECIFICATION .....................................................................................173
77
7.1. TOE Security Functions .......................................................................................173
78
7.1.1. TSF.AccessControl .......................................................................................173
79
7.1.2. TSF.Authenticate ..........................................................................................174
80
7.1.3. TSF.SecureManagement ..............................................................................177
81
7.1.4. TSF.CryptoKey..............................................................................................178
82
IDentity Applet v3.4/eIDAS Security Target
Page 6 of 191
7.1.5. TSF.AppletParametersSign...........................................................................180
83
7.1.6. TSF.Platform.................................................................................................180
84
7.2. Assurance Measures............................................................................................183
85
7.3. Fulfillment of the SFRs.........................................................................................183
86
7.4. Correspondence of SFR and TOE mechanisms...................................................187
87
8. GLOSSARY AND ABBREVIATIONS ....................................................................................188
88
9. BIBLIOGRAPHY..............................................................................................................189
89
90
IDentity Applet v3.4/eIDAS Security Target
Page 7 of 191
List of Tables
Table 1 Overview of identifiers of current ST and PPs........................................................... 9
91
Table 2 IDentity Applet Suite v3.4 functionalities ..................................................................10
92
Table 3 Terminals and access control in European Passport ...............................................22
93
Table 4 Terminals and access control in Identity Card with Protected MRTD Application.....26
94
Table 5 Terminals and access control in Identity Card with EU-compliant MRTD Application
95
.............................................................................................................................................30
96
Table 6 Classification of Platform-TSFs................................................................................39
97
Table 7 Mapping of security objectives for the TOE..............................................................43
98
Table 8 Mapping of Security requirements ...........................................................................53
99
Table 9 Security Objective Rationale....................................................................................72
100
Table 10 Overview of authentication and identification SFRs ...............................................96
101
Table 11 Coverage of Security Objectives for the TOE by SFRs ........................................167
102
Table 12 Assurance measures and corresponding documents...........................................183
103
IDentity Applet v3.4/eIDAS Security Target
Page 8 of 191
1. ST INTRODUCTION
104
This section provides document management and overview information required to register
105
the Security Target (ST) and to enable a potential user of the ST to determine, whether the ST
106
is of interest.
107
1.1. ST REFERENCE
108
Title: Security Target ID&Trust IDentity Applet v3.4-p2/eIDAS - Electronic
109
Identity Card with PACE-GM, PACE-CAM, Extended Access
110
Control v1 and v2, Restricted Identification and Active
111
Authentication
112
Author: ID&Trust Ltd.
113
Version Number: v1.06
114
Date: 01.02.2023
115
1.2.TOE Reference
116
The Security Target refers to the product “ID&Trust IDentity Applet Suite v3.4” for CC
117
evaluation.
118
TOE Name: IDentity Applet v3.4-p2/eIDAS on NXP JCOP 4 P71
119
TOE short name: IDentity Applet v3.4/eIDAS
120
TOE Identification
121
Data:
122
Applet version
123
number IDentity Applet V3.4/eIDAS v3.4.7470
124
Patch version
125
number: 024A
126
Evaluation Criteria: [4]
127
Evaluation
128
Assurance Level: EAL EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and
129
AVA_VAN.5 as defined in [3].
130
IDentity Applet v3.4/eIDAS Security Target
Page 9 of 191
Developer: ID&Trust Ltd.
131
Evaluation Sponsor: NXP Semiconductors Germany GmBH, Troplowitzstraße 20, 22529
132
Hamburg, Germany
133
1.3.TOE Overview
134
This ST claims strict conformance to [5], [6], [13] and [20]. There, slightly different terminology
135
is used. For the ease of understanding, Table 1 gives a brief translation for the used
136
terminology. Compound words that contain terminology of the table should be replaced
137
accordingly.
138
This ST PACE PP [13] EAC1PP [5] EAC2PP [6]
electronic
document
travel document travel document electronic document
electronic
document
presenter
traveler traveler electronic document
presenter
EAC1 protected
data
- sensitive (user) data -
EAC2 protected
data
- - Sensitive User Data
common user data user data user data common user data
PACE terminal BIS-PACE BIS-PACE PACE terminal
EAC1 terminal - Extended Inspection
System
-
EAC2 terminal - - EAC2 terminal
Table 1 Overview of identifiers of current ST and PPs
139
1.3.1. TOE TYPE
140
IDentity Applet Suite v3.4 is a highly configurable eID solution. It is able to satisfy multiple
141
different application requirements even within a single applet instance. The Application part of
142
the TOE, the applet functionalities are distributed according to the following table:
143
Application Function Standard Protection Profile
(certified or in
progress)
IDentity/PKI Flexible PKI token CEN TS 14890-1/2
IAS-ECC 1.0.1 [30]
-
IDentity/IAS European card for e-
Services and National e-
ID applications
CEN/TS 15480-
IAS-ECC 1.0.1 [30]
-
IDentity/QSCD Qualified Signature
Creation Device
CEN/TS 15480-2
IAS-ECC 1.0.1 [30]
REGULATION (EU) No
910/2014
[14]
[15]
IDentity Applet v3.4/eIDAS Security Target
Page 10 of 191
BSI TR-03117
IDentity/IDL International Driving
License
ISO/IEC 18013 -
IDentity/EDL European Driving
License
2012/383/EC -
IDentity/eVR Electronic Vehicle
Registration
1999/37/EC -
IDentity/eHC Electronic Health
Insurance
CEN/CWA 15794 -
IDentity/BAC Basic Access Control
(BAC)
ICAO Doc 9303 [8] BSI-CC-PP-0055
IDentity-J Basic Access Control
(BAC)
Password Authenticated
Connection
Establishment (PACE)
ICAO Doc 9303 [8] JISEC500 [32]
JISEC499 [33]
IDentity/PACE-
EAC1
Password Authenticated
Connection
Establishment (PACE)
Extended Access
Control v1 (EAC1)
ICAO Doc 9303 [8]
ICAO TR-SAC [7]
BSI TR-03110 v2.21
[16][17][18][19]
BSI-CC-PP-0068-
V2-2011 [13]
BSI-CC-PP-0056-
V2-2012 [5]
IDentity/eIDAS Password Authenticated
Connection
Establishment (PACE)
Extended Access
Control v2 (EAC2)
ICAO TR-SAC [7]
BSI TR-03110 v2.21
[16][17][18][19]
BSI-CC-PP-0087
[20]
Table 2 IDentity Applet Suite v3.4 functionalities
144
All the functions are supplied by the applet “IDentity Applet Suite v3.4”, the behaviour of the
145
applet changes according to the configuration applied during the personalization phase of
146
IDentity Applet life cycle and the environmental behaviour of the usage phase.
147
The scope of the current ST is only concerned with applet behaviour of configuration
148
IDentity Applet v3.4/eIDAS.
149
The Target of Evaluation (TOE) is contactless smart card with the IDentity Applet Suite v3.4
150
configured as IDentity Applet v3.4/eIDAS. The TOE is applicable as an electronic document
151
(with three applications: ePassport, eID and eSign), which compliance to relevant eIDAS
152
standards [16], [17], [18] and provide all necessary security protocols (such as PACE, EAC1,
153
EAC2, etc).
154
IDentity Applet v3.4/eIDAS Security Target
Page 11 of 191
1.3.2. TOE DEFINITION AND OPERATIONAL USAGE
155
The Target of Evaluation (TOE) is a smartcard programmed according to [16] [17]. The
156
smartcard contains multiple applications (at least one). The programmed smartcard is called
157
an electronic document as a whole. Here, an application is a collection of data(groups) and
158
their access conditions. We mainly distinguish between common user data, and sensitive user-
159
data. Depending on the protection mechanisms involved, these user data can further be
160
distinguished as follows:
161
• EAC1-protected data: Sensitive User Data protected by EAC1 (cf. [16]),
162
• EAC2-protected data: Sensitive User Data protected by EAC2 (cf. [17]), and
163
• all other (common) user data: Other user data are protected by Password Authenticated
164
Connection Establishment (PACE, cf. also [17]). Note that EAC1 recommends, and EAC2
165
requires prior execution of PACE.
166
1. Application note (taken from [20], application note 1.)
167
Due to migration periods, some developers have to implement products that function-ally
168
support both PACE and Basic Access Control (BAC), i.e. Supplemental Access Control (SAC)
169
[8].However, any product using BAC is not conformant to the current ST; i.e. the TOE may
170
functionally support BAC, but, while performing BAC, it is acting outside of the security policy
171
defined by the current ST.
172
In addition to the above user data, there are also data required for TOE security functionality
173
(TSF). Such data is needed to execute the access control protocols, to verify integrity and
174
authenticity of user data, or to generate cryptographic signatures.
175
Application considered in [16] and [17] are
176
1. an electronic passport (ePass) application
177
2. an electronic identity (eID) application, and
178
3. a signature (eSign) application.
179
The TOE shall comprise at least:
180
1. the circuitry of the chip, including all integrated circuit (IC) dedicated software that is
181
active in the operational phase of the TOE,
182
2. the IC embedded software, i.e. the operating system,
183
3. all access mechanisms, associated protocols and corresponding data,
184
4. one or several applications, and
185
5. the associated guidance documentation.
186
IDentity Applet v3.4/eIDAS Security Target
Page 12 of 191
2. Application note (taken from [20], application note 2)
187
Since contactless interface parts (e.g. the antenna) may impact specific aspects of vulnerability
188
assessment and are thus relevant for security, such parts might be considered as a part of the
189
TOE. The decision upon this is up to the certification body in charge that defines the evaluation
190
methodology for the assessment of the contactless interface.
191
1.3.3. TOE MAJOR SECURITY FEATURES FOR OPERATIONAL USE
192
The following TOE security features are the most significant for its operational use:
193
The TOE ensures that
194
• only authenticated terminals can get access to the User Data stored on the TOE and
195
use security functionality of the electronic document according to the access rights of
196
the terminal,
197
• the Electronic Document Holder can control access by consciously presenting his
198
electronic document and/or by entering his secret PIN,
199
• authenticity and integrity of user data can be verified,
200
• confidentiality of user data in the communication channel between the TOE and the
201
connected terminal is provided,
202
• inconspicuous tracing of the electronic document is averted,
203
• its security functionality and the data stored inside are self-protected, and
204
• digital signatures can be created, if the TOE contains an eSign application.
205
• Optionally support the Active Authetnication and Chip Authentication mapping.
206
1.3.4. NON-TOE HARDWARE/SOFTWARE/FIRMWARE
207
In order to be powered up and to communicate with the external world, the TOE needs a
208
terminal (card reader) supporting the communication according to [12] and [11]; the latter only
209
if the card has a contactless interface. Akin to [16] and [17] the TOE shall be able to recognize
210
the following terminal types:
211
PACE terminal
212
A PACE terminal is a basic inspection system according to [16], [17] resp. It performs the
213
standard inspection procedure, i.e. PACE followed by Passive Authentication, cf. [16].
214
Afterwards user data are read by the terminal. A PACE terminal is allowed to read only
215
common user data.
216
For more information see: PACE Terminal
217
IDentity Applet v3.4/eIDAS Security Target
Page 13 of 191
EAC1 terminal
218
An EAC1 terminal is an extended inspection system according to [16]. It performs the
219
advanced inspection procedure ([16]) using EAC1, i.e. PACE, then Chip Authentication 1
220
followed by Passive Authentication, and finally Terminal Authentication 1. Afterwards user data
221
are read by the terminal. An EAC1 terminal is allowed to read both EAC1 protected data, and
222
common user data.
223
For more information see: EAC1 Terminal / EAC2 Terminal
224
EAC2 terminal
225
An EAC2 terminal is an extended inspection system performing the general authentication
226
procedure according to [17] using EAC2, i.e. PACE, then Terminal Authentication 2 followed
227
by Passive Authentication, and finally Chip Authentication 2. Depending on its authorization
228
level, an EAC2 terminal is allowed to read out some or all EAC2 protected Sensitive User Data,
229
and common user data.
230
For more information see: EAC1 Terminal / EAC2 Terminal
231
In general, the authorization level of a terminal is determined by the effective terminal
232
authorization. The authorization is calculated from the certificate chain presented by the
233
terminal to the TOE. It is based on the Certificate Holder Authorization Template (CHAT). A
234
CHAT is calculated as an AND-operation from the certificate chain of the terminal and the
235
electronic document presenter's restricting input at the terminal. The final CHAT reflects the
236
effective authorization level and is then sent to the TOE [18]. For the access rights, cf. also the
237
SFR component FDP_ACF.1/TRM in Chapter 6.1.3.
238
All necessary certificates of the related public key infrastructure – Country Verifying
239
Certification Authority (CVCA) Link Certificates, Document Verifiers Certificates and Terminal
240
Certificates – must be available in the card verifiable format defined in [18].
241
The term terminal within this ST usually refers to any kind of terminal, if not explicitly mentioned
242
otherwise.
243
The current TOE knows three different configuration as described in 1.4.5 Features of the
244
IDentity Applet. According to the each configuration the following tables give an overview which
245
of the above terminals are related to what application, and which data group is accessible.
246
European Passport configuration
247
Terminal/Application ePassport eID eSign
IDentity Applet v3.4/eIDAS Security Target
Page 14 of 191
PACE terminal Common user data n.a. n.a.
EAC1 terminal Common user data
and EAC1 protected
data
n.a. n.a.
EAC2 terminal none n.a. n.a.
Identity Card with Protected MRTD Application configuration
248
Terminal/Application ePassport eID eSign
PACE terminal none none none
EAC1 terminal none none none
EAC2 terminal Common user data
EAC2 protected
data
Common user data
EAC2 protected
data
EAC2 protected
data
Identity Card with EU-compliant MRTD Application configuration
249
Terminal/Application ePassport eID eSign
PACE terminal Common user data None None
EAC1 terminal Common user data
and EAC1 protected
data
None None
EAC2 terminal none common user data
EAC2 protected
data
EAC2 protected
data
Other terminals than the above are out of scope of this ST. In particular, terminals using Basic
250
Access Control (BAC) may be functionally supported by the electronic document, but if the
251
TOE is operated using BAC, it is not in a certified mode.
252
1.4. TOE DESCRIPTION
253
1.4.1. PRODUCT TYPE
254
The TOE type addressed by the current ST is a smartcard programmed according to [16] and
255
[17]. The smartcard contains IDentity Applet v3.4/eIDAS, which may be contain multiple
256
applications (at least one). The smartcard with IDentity Applet v3.4/eIDAS is called an
257
electronic document as a whole.
258
Justification: TOE type definitions of the claimed PPs ([5], [6], [14]) differ slightly. We argue
259
that these differences do not violate consistency:
260
The TOE type defined both in [5] and [6] is a smartcard. Whereas [5] references [16] (and also
261
[8] and related ICAO specifications, however [16] is fully compatible with those ICAO
262
specifications, and they are mostly listed there for the sake of completeness and the context
263
of use) w.r.t. programming of the card, [17] is given as a reference in [6]. Reference [16] defines
264
the EAC1 protocol, whereas EAC2 is defined in [17]. Thus, this difference in reference is
265
IDentity Applet v3.4/eIDAS Security Target
Page 15 of 191
introduced just due to different applications on the card, that do not contradict each other. The
266
term 'travel document' of [5] is here understood in a more broader sense (cf. also Table 1 ),
267
since the document can also be used in contexts other than just traveling.
268
The TOE type definition given in [14] is “a combination of hardware and software configured
269
to securely create, use and manage signature-creation data (SCD)”. The definition of hardware
270
and software in this ST is more specific by explicitly mentioning a smartcard and the software
271
on the card. However, the very fundamental purpose of a smartcard is to store data on it in a
272
protected way. Hence, the TOE type definition of this ST is also not inconsistent with the one
273
of [14].
274
The typical life cycle phases for the current TOE type are development, manufacturing, card
275
issuing and operational use. The life cycle phase development includes development of the IC
276
itself and IC embedded software. Manufacturing includes IC manufacturing and smart card
277
manufacturing, and installation of a card operating system. Card issuing includes installation
278
of the smart card applications and their electronic personalization, i. e. tying the application
279
data up to the Electronic Document Holder.
280
Operational use of the TOE is explicitly in the focus of [20]. Nevertheless, some TOE
281
functionality might not be directly accessible to the end-user during operational use. Some
282
single properties of the manufacturing and the card issuing life cycle phases that are significant
283
for the security of the TOE in its operational phase are also considered by the current ST.
284
Conformance with [20] requires that all life cycle phases are considered to the extent that is
285
required by the assurance package chosen here for the TOE; c.f. also chapter 6.2
286
1.4.2. COMPONENTS OF THE TOE
287
Micro Controller
288
The Micro Controller is a secure smart card controller from NXP from the SmartMX3 family.
289
The Micro Controller contains a co-processor for symmetric cipher, supporting DES operations
290
and AES, as well as an accelerator for asymmetric algorithms. The Micro Controller further
291
contains a physical random number generator. The supported memory technologies are
292
volatile (Random Access Memory (RAM)) and non-volatile (Read Only Memory (ROM) and
293
FLASH) memory. Access to all memory types is controlled by a Memory Management Unit
294
(MMU) which allows to separate and restrict access to parts of the memory.
295
IC dedicated software – Micro Controller Firmware
296
IDentity Applet v3.4/eIDAS Security Target
Page 16 of 191
The Micro Controller Firmware is used for testing of the Micro Controller at production, for
297
booting of the Micro Controller after power-up or after reset, for configuration of communication
298
devices and for writing data to non-volatile memory.
299
IC dedicated software – Crypto Library
300
The Crypto Library provides implementations for symmetric and asymmetric cryptographic
301
operations, hashing, the generation of hybrid deterministic and hybrid physical random
302
numbers and further tools like secure copy and compare. The supported asymmetric
303
cryptographic operations are ECC and RSA. These algorithms use the Public Key Crypto
304
Coprocessor (PKCC) of the Micro Controller for the cryptographic operations.
305
Micro Controller, IC dedicated software (Micro Controller Firmware, Crypto Library) are
306
covered by the following certification: Certification ID: BSI-DSZ-CC-1136-V3-2022
307
Evaluation level EAL6+ ALC_FLR.1 and ASE_TSS.2 according to Security IC Platform
308
Protection Profile with Augmentation Packages Version 1.0, 13 January 2014, BSI-CC-00084-
309
2014.
310
IC Embedded Software
311
Certification ID: CC-22-180212/2
312
JCOP4 consists of Java Card Virtual Machine (JCVM), Java Card Runtime Environment
313
(JCRE), Java Card API (JCAPI), Global Platform (GP) framework, Configuration Module, etc.
314
OS Name: JCOP 4 Operating System
315
Applied OS
316
configuration: Banking & Secure ID
317
318
Product
319
Identification: JCOP 4 v4.7 R1.01.4
320
321
Evaluation Level: CC EAL 6+ with ASE_TSS.2, ALC_FLR.1 according to Java Card
322
System – Open Configuration Protection Profile, version 3.0.5, Certified
323
by Bundesamt für Sicherheit in der Informationstechnik (BSI, BSI-CC-
324
PP-0099-2017).
325
Platform UGD: [24]
326
ID&Trust IDentity Applet Suite – accomplishing IDentity Applet v3.4/eIDAS
327
Product name: ID&Trust IDentity Applet Suite
328
Version: 3.4
329
IDentity Applet v3.4/eIDAS Security Target
Page 17 of 191
Application name1
: IDentity Applet v3.4/eIDAS
330
TOE Guidance
331
Documentation: 2
IDentity Applet Administrator’s Guide [21]
332
IDentity Applet User’s Guide [22]
333
The composite part always means IDentity Applet v3.4/eIDAS
334
The logical architecture of the TOE:
335
336
1. Figure TOE Boundaries
337
The TOE is a composite TOE and the dashed line denotes the whole TOE. The underlying
338
certified hardware platform and JCOP 4 OS are marked with purple and green. In this ST the
339
common short name of certified hardware platform and JCOP 4 OS is Platform.
340
The blue box marks the application layer. The ID&Trust IDentity Applet Suite v3.4 could be
341
loaded in the Flash. During the creation phase an instance is created in the Flash and after
342
1 The applet is provided in cap file format.
2 The AGD documents provided in electronic document format.
IDentity Applet v3.4/eIDAS Security Target
Page 18 of 191
several configuration steps it will be personalized as IDentity Applet v3.4/eIDAS. For details
343
please see: section 1.4.3 TOE life cycle and [23].
344
The boxes marked with white are not certified.
345
1.4.3. TOE LIFE CYCLE
346
The TOE life cycle is described in terms of the above mentioned four life cycle phases. Akin to
347
[10], the TOE life-cycle is additionally subdivided into seven steps.
348
Phase 1: Development
349
Step 1
350
The TOE is developed in phase 1. NXP develops the integrated circuit, the IC dedicated
351
software and the guidance documentation associated with these TOE components.
352
Step 2
353
The software developer uses the guidance documentation for the integrated circuit and the
354
guidance documentation for relevant parts of the IC dedicated software, and develops the IC
355
embedded software (operating system), the electronic document application(s) and the
356
guidance documentation associated with these TOE components. The operating system is
357
developed by NXP as well. The IDentity Applet v3.4 is developed by ID&Trust Ltd.
358
The manufacturing documentation of the IC including the IC dedicated software and the
359
embedded software in the non-volatile non-programmable memories is securely delivered to
360
the IC manufacturer. The IC embedded software in the non-volatile programmable memories,
361
the application(s), and the guidance documentation is securely delivered to the electronic
362
document manufacturer.
363
Phase 2: Manufacturing
364
Step 3
365
In a first step, the TOE integrated circuit is produced. The circuit contains the electronic
366
document's chip dedicated software, and the parts of the electronic document's chip
367
embedded software in the non-volatile non-programmable memory (ROM). The IC
368
manufacturer writes IC identification data onto the chip in order to track and control the IC as
369
dedicated electronic document material during IC manufacturing, and during delivery to the
370
IDentity Applet v3.4/eIDAS Security Target
Page 19 of 191
electronic document manufacturer. The IC is securely delivered from the IC manufacturer to
371
the electronic document manufacturer. If necessary, the IC manufacturer adds parts of the IC
372
embedded software in the non-volatile programmable memory, e. g. EEPROM or in FLASH.
373
Step 4 (optional)
374
If the electronic document manufacturer delivers a packaged component, the IC is combined
375
with hardware for the contact based or contactless interface.
376
Step 5
377
The electronic document manufacturer
378
1. if necessary, adds the IC embedded software, or parts of it in the non-volatile
379
programmable memories, e. g. EEPROM or FLASH,
380
2. creates the application(s), and
381
3. equips the electronic document's chip with pre-personalization data.
382
Creation of the application(s) implies the creation of the master file (MF), dedicated files (DFs),
383
and elementary files (EFs) according to [12]. How this process is handled internally depends
384
on the IC and IC embedded software.
385
The pre-personalized electronic document together with the IC identifier is securely delivered
386
from the electronic document manufacturer to the Personalization Agent. The electronic
387
document manufacturer also provides the relevant parts of the guidance documentation to the
388
Personalization Agent.
389
Phase 3: Personalization of the Electronic Document
390
Step 6
391
The personalization of the electronic document includes
392
1. the survey of the Electronic Document Holder’s biographical data,
393
2. the enrollment of the Electronic Document Holder's biometric reference data, such as
394
a digitized portrait or other biometric reference data,
395
3. printing the visual readable data onto the physical part of the electronic document, and
396
4. configuration of the TSF, if necessary.
397
IDentity Applet v3.4/eIDAS Security Target
Page 20 of 191
Configuration of the TSF is performed by the Personalization Agent and includes, but is not
398
limited to, the creation of the digitized version of the textual, printed data, the digitized version
399
of e.g. a portrait, or a cryptographic signature of a cryptographic hash of the data that are
400
stored on the chip. The personalized electronic document, if required together with appropriate
401
guidance for TOE use, is handed over to the Electronic Document Holder for operational use.
402
3. Application note (taken from [20], Application Note 3)
403
TSF data are data for the operation of the TOE upon which the enforcement of the SFRs relies
404
[1]. Here TSF data include, but are not limited to, the Personalization Agent's authentication
405
key(s).
406
Phase 4: Operational Use
407
Step 7
408
The chip of the TOE is used by the electronic document and terminals that verify the chip's
409
data during the phase operational use. The user data can be read and modified according to
410
the security policy of the issuer.
411
4. Application note (taken from [20], application note 4)
412
This ST considers at least the first phase and parts of the second phase, i.e. Step 1 up to Step
413
3, as part of the evaluation. Therefore, the TOE delivery is defined to occur, according to CC,
414
after Step 3. Since specific production steps of the second phase are of minor security
415
relevance (e.g. plastic card or booklet manufacturing and antenna integration) these are not
416
part of the CC evaluation under ALC. Nevertheless, the decision about this has to be taken by
417
the certification body resp. the national body of the issuer or organization. In this case the
418
national body of the issuer is responsible for these specific production steps.
419
Note that the personalization process and its environment may depend on specific security
420
needs of the issuer. All production, generation and installation procedures after TOE delivery
421
up to the phase operational use have to be considered in the product evaluation process under
422
assurance class AGD. Therefore, the security target has to outline how to split up P.Manufact,
423
P.Personalisation and related security objectives into aspects relevant before vs. those
424
relevant after TOE delivery.
425
Some production steps, e. g. Step 4 in Phase 2 may also take place in the Phase 3.
426
1.4.4. TOE SECURITY FUNCTIONS
427
TSF Description
TSF.AccessControl The TOE enforces access control in order to ensure only for
authorised users to access User Data and TSF-data and
maintains different security roles.
IDentity Applet v3.4/eIDAS Security Target
Page 21 of 191
TSF.Authenticate The TOE supports several authentication mechanisms in
order to authenticate the Users, Terminals and to prove the
genuineness of the electronic document.
The supported mechanism and protocols are based on
ICAO and BSI standards [7], [8], [16], [17] and [18].
TSF.SecureManagement The TOE enforces the secure management of the security
attributes, data and functions. Furthermore the TOE restricts
the available commands in each TOE life-cycle phase.
TSF.CryptoKey The TOE uses several cryptographic services such as digital
signature creation and verification, asymmetric and
symmetric cryptography, random number generation and
complete key management.
TSF.AppletParametersSign The TOE enforces the integrity of itself in each life cycle
phases.
TSF.Platform The TOE relies on the certified functions and services of the
Platform. This TSF is collection of those SFRs, which are
uses these functions and services.
1.4.5. FEATURES OF THE IDENTITY APPLET
428
Taking into consideration the [20] the current ST makes distinct the following configuration:
429
• European Passport
430
• Identity Card with Protected MRTD Application
431
• Identity Card with EU-compliant MRTD Application
432
1.4.5.1. European Passport
433
Passwords
434
• MRZ [16]
435
• CAN [16]
436
Authentication Procedure
437
This configuration requires implementation t the following Authentication Procedure for access
438
to DG3 and DG4 (Sensitive User Data) of the ePassport Application:
439
• Advanced Inspection procedure [16]
440
Applications
441
• ePassport Application
442
Protocols
443
• PACE (Generic Mapping, Integrated Mapping and Chip Authentication Mapping) [9],
444
[16]
445
• Active Authentication [7] (optionally)
446
• EAC1 [16]
447
IDentity Applet v3.4/eIDAS Security Target
Page 22 of 191
o Terminal Authentication version 1 [16]
448
o Chip Authentication version 1 [16]
449
Data Groups
450
According to [16].
451
Data types in:
452
• Common user data: All DG, which require only BAC/PACE protocol
453
• EAC1 protected data: All DG,which require EAC1 protocol
454
The authorization level of EAC1 terminal is determined by the effective authorization calculated
455
by from the certificate chain.
456
Terminals and access control
457
Data types PACE terminal EAC1 terminal EAC2 terminal
common user data X X -
EAC1 protected data - X -
Table 3 Terminals and access control in European Passport
458
Security Functional Requirements
459
TOE SFR / Application
ePas
sport
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 -
FCS_CKM.1/DH_PACE_EAC1PP X
FCS_CKM.4/EAC1PP X
FCS_COP.1/PACE_ENC_EAC1PP X
FCS_COP.1/PACE_MAC_EAC1PP X
FCS_RND.1/EAC1PP X
FCS_CKM.1/CA_EAC1PP X
FCS_COP.1/CA_ENC_EAC1PP X
FCS_COP.1/SIG_VER_EAC1PP X
FCS_COP.1/CA_MAC_EAC1PP X
FCS_CKM.1/CA2 -
FCS_CKM.1/RI -
FCS_CKM.1/AA X
FCS_COP.1/AA X
FCS_CKM.1/CAM X
FCS_COP.1/CAM X
FCS_CKM.1/SSCDPP -
FCS_COP.1/SSCDPP -
FIA_AFL.1/Suspend_PIN_EAC2PP X
IDentity Applet v3.4/eIDAS Security Target
Page 23 of 191
FIA_AFL.1/Block_PIN_EAC2PP X
FIA_API.1/CA_EAC2PP -
FIA_API.1/RI_EAC2PP -
FIA_UID.1/PACE_EAC2PP -
FIA_UID.1/EAC2_Terminal_EAC2PP -
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 -
FIA_UID.1/PACE_EAC1PP X
FIA_UAU.1/PACE_EAC1PP X
FIA_UAU.4/PACE_EAC1PP X
FIA_UAU.5/PACE_EAC1PP X
FIA_UAU.6/PACE_EAC1PP X
FIA_UAU.6/EAC_EAC1PP X
FIA_API.1/EAC1PP X
FIA_API.1/PACE_CAM X
FIA_API.1/AA X
FIA_AFL.1/PACE_EAC1PP X
FIA_UID.1/SSCDPP -
FIA_AFL.1/SSCDPP -
FIA_UAU.1/SSCDPP -
FDP_ACC.1/TRM_EAC2PP -
FDP_ACF.1/TRM X
FDP_RIP.1/EAC2PP -
FDP_UCT.1/TRM_EAC2PP -
FDP_UIT.1/TRM_EAC2PP -
FDP_ACC.1/TRM_EAC1PP X
FDP_RIP.1/EAC1PP X
FDP_UCT.1/TRM_EAC1PP X
FDP_UIT.1/TRM_EAC1PP X
FDP_ACC.1/SCD/SVD_Generation_S
SCDPP
-
FDP_ACF.1/SCD/SVD_Generation_S
SCDPP
-
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 -
FTP_ITC.1/PACE_EAC2PP -
FTP_ITC.1/CA_EAC2PP -
FTP_ITC.1/PACE_EAC1PP X
FAU_SAS.1/EAC2PP -
FAU_SAS.1/EAC1PP X
FMT_MTD.1/CVCA_INI_EAC2PP -
FMT_MTD.1/CVCA_UPD_EAC2PP -
FMT_SMF.1/EAC2PP -
IDentity Applet v3.4/eIDAS Security Target
Page 24 of 191
FMT_SMR.1 X
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_SMR.1/SSCDPP -
FMT_SMF.1/SSCDPP -
FMT_MOF.1/SSCDPP -
FMT_MSA.1/Admin_SSCDPP -
FMT_MSA.1/SignatorySSCDPP -
FMT_MSA.2/SSCDPP -
FMT_MSA.3/SSCDPP -
FMT_MSA.4/SSCDPP -
FMT_MTD.1/Admin_SSCDPP -
FMT_MTD.1/Signatory_SSCDPP -
FMT_LIM.1/EAC2PP -
FMT_LIM.2/EAC2PP -
FMT_MTD.1/INI_ENA_EAC2PP -
FMT_MTD.1/INI_DIS_EAC2PP -
FMT_SMF.1/EAC1PP X
FMT_LIM.1/EAC1PP X
FMT_LIM.2/EAC1PP X
FMT_MTD.1/INI_ENA_EAC1PP X
FMT_MTD.1/INI_DIS_EAC1PP X
FMT_MTD.1/CVCA_INI_EAC1PP X
FMT_MTD.1/CVCA_UPD_EAC1PP X
FMT_MTD.1/DATE_EAC1PP X
FMT_MTD.1/CAPK_EAC1PP X
FMT_MTD.1/PA_EAC1PP X
FMT_MTD.1/KEY_READ_EAC1PP X
FMT_MTD.3/EAC1PP X
FMT_LIM.1/Loader X
FMT_LIM.2/Loader X
FMT_MTD.1/AA_Private_Key X
FPT_EMS.1/EAC2PP -
FPT_FLS.1/EAC2PP -
FPT_TST.1/EAC2PP -
FPT_PHP.3/EAC2PP -
FPT_TST.1/EAC1PP X
FPT_FLS.1/EAC1PP X
FPT_PHP.3/EAC1PP X
FPT_EMS.1/EAC1PP X
FPT_EMS.1/SSCDPP -
FPT_FLS.1/SSCDPP -
FPT_PHP.1/SSCDPP -
FPT_PHP.3/SSCDPP -
FPT_TST.1/SSCDPP -
IDentity Applet v3.4/eIDAS Security Target
Page 25 of 191
1.4.5.2. Identity Card with Protected MRTD Application
460
Passwords
461
• MRZ [16]
462
• CAN [16]
463
• PIN [17]
464
• PUK [17]
465
While it is technically possible to grant access to the electronic signature functionality by
466
inputting only CAN, this technical option is not allowed in this ST. This is due to the fact that
467
solely the signatory – which is here the Electronic Document Holder – shall be able to generate
468
an electronic signature on his own behalf.
469
Authentication Procedure
470
This configuration requires implementation at the following Authentication Procedure for
471
access any User Data stored on the TOE:
472
• General Authentication Procedure [17]
473
Applications
474
• ePassport Application
475
• eID Application
476
• eSign Application
477
Protocols
478
• PACE (Generic Mapping, Integrated Mapping) [17]
479
• EAC2 [17]
480
o Terminal Authentication version 2 [17]
481
o Chip Authentication version 2 [17]
482
• Restricted Identification [17]
483
Data Groups
484
According to [17].
485
According to [9] and [16].
486
Data type in:
487
• EAC2 protected data: All DG in ePassport, eID and eSign application.
488
IDentity Applet v3.4/eIDAS Security Target
Page 26 of 191
The authorization level of EAC2 terminal is determined by the effective authorization calculated
489
by from the certificate chain.
490
Terminals and access control
491
Data type PACE terminal EAC1 terminal EAC2 terminal
Common user data - - X
EAC2 protected data - - X
Table 4 Terminals and access control in Identity Card with Protected MRTD Application
492
TOE SFR / Application ePassport eID eSign
FCS_CKM.1/DH_PACE_EAC2PP X X X
FCS_COP.1/SHA_EAC2PP X X X
FCS_COP.1/SIG_VER_EAC2PP X X X
FCS_COP.1/PACE_ENC_EAC2PP X X X
FCS_COP.1/PACE_MAC_EAC2PP X X X
FCS_CKM.4/EAC2PP X X X
FCS_RND.1/EAC2PP X X X
FCS_CKM.1/DH_PACE_EAC1PP - - -
FCS_CKM.4/EAC1PP - - -
FCS_COP.1/PACE_ENC_EAC1PP - - -
FCS_COP.1/PACE_MAC_EAC1PP - - -
FCS_RND.1/EAC1PP - - -
FCS_CKM.1/CA_EAC1PP - - -
FCS_COP.1/CA_ENC_EAC1PP - - -
FCS_COP.1/SIG_VER_EAC1PP - - -
FCS_COP.1/CA_MAC_EAC1PP - - -
FCS_CKM.1/CA2 X X X
FCS_CKM.1/RI - X -
FCS_CKM.1/AA - - -
FCS_COP.1/AA - - -
FCS_CKM.1/CAM - - -
FCS_COP.1/CAM - - -
FCS_CKM.1/SSCDPP - - X
FCS_COP.1/SSCDPP - - X
FIA_AFL.1/Suspend_PIN_EAC2PP X X X
FIA_AFL.1/Block_PIN_EAC2PP X X X
FIA_API.1/CA_EAC2PP X X X
FIA_API.1/RI_EAC2PP - X -
FIA_UID.1/PACE_EAC2PP X X X
FIA_UID.1/EAC2_Terminal_EAC2PP X X X
FIA_UAU.1/PACE_EAC2PP X X X
FIA_UAU.1/EAC2_Terminal_EAC2PP X X X
FIA_UAU.4/PACE_EAC2PP X X X
FIA_UAU.5/PACE_EAC2PP X X X
FIA_UAU.6/CA_EAC2PP X X X
FIA_AFL.1/PACE_EAC2PP X X X
FIA_UAU.6/PACE_EAC2PP X X X
FIA_UID.1/PACE_EAC1PP - - -
FIA_UAU.1/PACE_EAC1PP - - -
FIA_UAU.4/PACE_EAC1PP - - -
FIA_UAU.5/PACE_EAC1PP - - -
IDentity Applet v3.4/eIDAS Security Target
Page 27 of 191
FIA_UAU.6/PACE_EAC1PP - - -
FIA_UAU.6/EAC_EAC1PP - - -
FIA_API.1/EAC1PP - - -
FIA_API.1/PACE_CAM - - -
FIA_API.1/AA - - -
FIA_AFL.1/PACE_EAC1PP - - -
FIA_UID.1/SSCDPP - - X
FIA_AFL.1/SSCDPP - - X
FIA_UAU.1/SSCDPP - - X
FDP_ACC.1/TRM_EAC2PP X X X
FDP_ACF.1/TRM X X X
FDP_RIP.1/EAC2PP X X X
FDP_UCT.1/TRM_EAC2PP X X X
FDP_UIT.1/TRM_EAC2PP X X X
FDP_ACC.1/TRM_EAC1PP - - -
FDP_RIP.1/EAC1PP - - -
FDP_UCT.1/TRM_EAC1PP - - -
FDP_UIT.1/TRM_EAC1PP - - -
FDP_ACC.1/SCD/SVD_Generation_SSCD
PP
- - X
FDP_ACF.1/SCD/SVD_Generation_SSCD
PP
- - X
FDP_ACC.1/SVD_Transfer_SSCDPP - - X
FDP_ACF.1/SVD_Transfer_SSCDPP - - X
FDP_ACC.1/Signature-creation_SSCDPP - - X
FDP_ACF.1/Signature-creation_SSCDPP - - X
FDP_RIP.1/SSCDPP - - X
FDP_SDI.2/Persistent_SSCDPP - - X
FDP_SDI.2/DTBS_SSCDPP - - X
FTP_ITC.1/PACE_EAC2PP X X X
FTP_ITC.1/CA_EAC2PP X X X
FTP_ITC.1/PACE_EAC1PP - - -
FAU_SAS.1/EAC2PP X X X
FAU_SAS.1/EAC1PP - - -
FMT_MTD.1/CVCA_INI_EAC2PP X X X
FMT_MTD.1/CVCA_UPD_EAC2PP X X X
FMT_SMF.1/EAC2PP X X -
FMT_SMR.1 X X X
FMT_MTD.1/DATE_EAC2PP X X X
FMT_MTD.1/PA_EAC2PP X X X
FMT_MTD.1/SK_PICC_EAC2PP X X X
FMT_MTD.1/KEY_READ_EAC2PP X X -
FMT_MTD.1/Initialize_PIN_EAC2PP X X -
FMT_MTD.1/Change_PIN_EAC2PP X X
FMT_MTD.1/Resume_PIN_EAC2PP X X
FMT_MTD.1/Unblock_PIN_EAC2PP X X
FMT_MTD.1/Activate_PIN_EAC2PP X X
FMT_MTD.3/EAC2PP X X
FMT_SMR.1/SSCDPP - - X
FMT_SMF.1/SSCDPP - - X
FMT_MOF.1/SSCDPP - - X
FMT_MSA.1/Admin_SSCDPP - - X
FMT_MSA.1/SignatorySSCDPP - - X
FMT_MSA.2/SSCDPP - - X
IDentity Applet v3.4/eIDAS Security Target
Page 28 of 191
FMT_MSA.3/SSCDPP - - X
FMT_MSA.4/SSCDPP - - X
FMT_MTD.1/Admin_SSCDPP - - X
FMT_MTD.1/Signatory_SSCDPP - - X
FMT_LIM.1/EAC2PP X X X
FMT_LIM.2/EAC2PP X X X
FMT_MTD.1/INI_ENA_EAC2PP X X X
FMT_MTD.1/INI_DIS_EAC2PP X X X
FMT_SMF.1/EAC1PP - - -
FMT_LIM.1/EAC1PP - - -
FMT_LIM.2/EAC1PP - - -
FMT_MTD.1/INI_ENA_EAC1PP - -
FMT_MTD.1/INI_DIS_EAC1PP - - -
FMT_MTD.1/CVCA_INI_EAC1PP - - -
FMT_MTD.1/CVCA_UPD_EAC1PP - - -
FMT_MTD.1/DATE_EAC1PP - - -
FMT_MTD.1/CAPK_EAC1PP - - -
FMT_MTD.1/PA_EAC1PP - - -
FMT_MTD.1/KEY_READ_EAC1PP - - -
FMT_MTD.3/EAC1PP - - -
FMT_LIM.1/Loader - X X
FMT_LIM.2/Loader - X X
FMT_MTD.1/AA_Private_Key - - -
FPT_EMS.1/EAC2PP X X X
FPT_FLS.1/EAC2PP X X X
FPT_TST.1/EAC2PP X X X
FPT_PHP.3/EAC2PP X X X
FPT_TST.1/EAC1PP - -
FPT_FLS.1/EAC1PP - -
FPT_PHP.3/EAC1PP - -
FPT_EMS.1/EAC1PP - -
FPT_EMS.1/SSCDPP - - X
FPT_FLS.1/SSCDPP - - X
FPT_PHP.1/SSCDPP - - X
FPT_PHP.3/SSCDPP - - X
FPT_TST.1/SSCDPP - - X
1.4.5.3. Identity Card with EU-compliant MRTD Application
493
Passwords
494
• MRZ [16]
495
• CAN [16]
496
• PIN [17]
497
• PUK [17]
498
While it is technically possible to grant access to the electronic signature functionality by
499
inputting only CAN, this technical option is not allowed in this ST. This is due to the fact that
500
solely the signatory – which is here the Electronic Document Holder – shall be able to generate
501
an electronic signature on his own behalf.
502
IDentity Applet v3.4/eIDAS Security Target
Page 29 of 191
Authentication Procedure
503
This configuration requires implementation at the following Authentication Procedure for
504
access to non-sensitive user data of the ePassport Application:
505
• Advanded Inspection Procedure [16]
506
This configuration requires implementation ot the following Authentication Procedure for
507
access any further User Data stored on the TOE:
508
• General Authentication Procedure [17]
509
Applications
510
• ePassport Application
511
• eID Application
512
• eSign Application
513
Protocols
514
• PACE (Generic Mapping, Integrated Mapping and Chip Authentication Mapping) [9]
515
[16] and [17]
516
• Active Authentication [7] (optionally)
517
• EAC1 [16]
518
o Terminal Authentication version 1 [16]
519
o Chip Authentication version 1 [16]
520
• EAC2 [17]
521
o Terminal Authentication version 2 [17]
522
o Chip Authentication version 2 [17]
523
• Restricted Identification [17]
524
Data Groups
525
According to [17].
526
Data types in Table 5 Terminals and access control in Identity Card with EU-compliant MRTD
527
Application:
528
• Common user data: All DG, which require only BAC/PACE protocol in ePassport;
529
• EAC1 protected data: All DG,which require EAC1 protocol in ePassport;
530
• EAC2 protected data: All DG in eID and eSign application.
531
IDentity Applet v3.4/eIDAS Security Target
Page 30 of 191
The authorization level of EAC1 and EAC2 terminals are determined by the effective
532
authorization calculated by from the certificate chain.
533
Terminals and access control
534
Data
types
PACE
terminal
EAC1
terminal
EAC2
terminal
Common
user data
X X X
EAC1
protected
data
- X -
EAC2
protected
data
- - X
Table 5 Terminals and access control in Identity Card with EU-compliant MRTD Application
535
536
TOE SFR / Application ePassport eID eSign
FCS_CKM.1/DH_PACE_EAC2PP - X X
FCS_COP.1/SHA_EAC2PP - X X
FCS_COP.1/SIG_VER_EAC2PP - X X
FCS_COP.1/PACE_ENC_EAC2PP - X X
FCS_COP.1/PACE_MAC_EAC2PP - X X
FCS_CKM.4/EAC2PP - X X
FCS_RND.1/EAC2PP - X X
FCS_CKM.1/DH_PACE_EAC1PP X - -
FCS_CKM.4/EAC1PP X - -
FCS_COP.1/PACE_ENC_EAC1PP X - -
FCS_COP.1/PACE_MAC_EAC1PP X - -
FCS_RND.1/EAC1PP X - -
FCS_CKM.1/CA_EAC1PP - - -
FCS_COP.1/CA_ENC_EAC1PP - - -
FCS_COP.1/SIG_VER_EAC1PP X - -
FCS_COP.1/CA_MAC_EAC1PP X - -
FCS_CKM.1/CA2 - X X
FCS_CKM.1/RI - X -
FCS_CKM.1/AA X - -
FCS_COP.1/AA X - -
FCS_CKM.1/CAM X - -
FCS_COP.1/CAM X - -
FCS_CKM.1/SSCDPP - - X
FCS_COP.1/SSCDPP - - X
FIA_AFL.1/Suspend_PIN_EAC2PP X X X
FIA_AFL.1/Block_PIN_EAC2PP X X X
FIA_API.1/CA_EAC2PP - X X
FIA_API.1/RI_EAC2PP - X -
FIA_UID.1/PACE_EAC2PP - X X
FIA_UID.1/EAC2_Terminal_EAC2PP - X X
FIA_UAU.1/PACE_EAC2PP - X X
FIA_UAU.1/EAC2_Terminal_EAC2PP - X X
IDentity Applet v3.4/eIDAS Security Target
Page 31 of 191
FIA_UAU.4/PACE_EAC2PP - X X
FIA_UAU.5/PACE_EAC2PP - X X
FIA_UAU.6/CA_EAC2PP - X X
FIA_AFL.1/PACE_EAC2PP - X X
FIA_UAU.6/PACE_EAC2PP - X X
FIA_UID.1/PACE_EAC1PP X - -
FIA_UAU.1/PACE_EAC1PP X - -
FIA_UAU.4/PACE_EAC1PP X - -
FIA_UAU.5/PACE_EAC1PP X - -
FIA_UAU.6/PACE_EAC1PP X - -
FIA_UAU.6/EAC_EAC1PP X - -
FIA_API.1/EAC1PP X - -
FIA_API.1/PACE_CAM X - -
FIA_API.1/AA X - -
FIA_AFL.1/PACE_EAC1PP X - -
FIA_UID.1/SSCDPP - - X
FIA_AFL.1/SSCDPP - - X
FIA_UAU.1/SSCDPP - - X
FDP_ACC.1/TRM_EAC2PP - X X
FDP_ACF.1/TRM X X X
FDP_RIP.1/EAC2PP - X X
FDP_UCT.1/TRM_EAC2PP - X X
FDP_UIT.1/TRM_EAC2PP - X X
FDP_ACC.1/TRM_EAC1PP X - -
FDP_RIP.1/EAC1PP X - -
FDP_UCT.1/TRM_EAC1PP X - -
FDP_UIT.1/TRM_EAC1PP X - -
FDP_ACC.1/SCD/SVD_Generation_SSCD
PP
- - X
FDP_ACF.1/SCD/SVD_Generation_SSCD
PP
- - X
FDP_ACC.1/SVD_Transfer_SSCDPP - - X
FDP_ACF.1/SVD_Transfer_SSCDPP - - X
FDP_ACC.1/Signature-creation_SSCDPP - - X
FDP_ACF.1/Signature-creation_SSCDPP - - X
FDP_RIP.1/SSCDPP - - X
FDP_SDI.2/Persistent_SSCDPP - - X
FDP_SDI.2/DTBS_SSCDPP - - X
FTP_ITC.1/PACE_EAC2PP - X X
FTP_ITC.1/CA_EAC2PP - X X
FTP_ITC.1/PACE_EAC1PP X - -
FAU_SAS.1/EAC2PP - X X
FAU_SAS.1/EAC1PP X - -
FMT_MTD.1/CVCA_INI_EAC2PP - X X
FMT_MTD.1/CVCA_UPD_EAC2PP - X X
FMT_SMF.1/EAC2PP - X -
FMT_SMR.1 X X X
FMT_MTD.1/DATE_EAC2PP - X X
FMT_MTD.1/PA_EAC2PP - X X
FMT_MTD.1/SK_PICC_EAC2PP - X X
FMT_MTD.1/KEY_READ_EAC2PP - X -
FMT_MTD.1/Initialize_PIN_EAC2PP - X -
FMT_MTD.1/Change_PIN_EAC2PP - X
FMT_MTD.1/Resume_PIN_EAC2PP - X
IDentity Applet v3.4/eIDAS Security Target
Page 32 of 191
FMT_MTD.1/Unblock_PIN_EAC2PP - X
FMT_MTD.1/Activate_PIN_EAC2PP - X
FMT_MTD.3/EAC2PP - X
FMT_SMR.1/SSCDPP - - X
FMT_SMF.1/SSCDPP - - X
FMT_MOF.1/SSCDPP - - X
FMT_MSA.1/Admin_SSCDPP - - X
FMT_MSA.1/SignatorySSCDPP - - X
FMT_MSA.2/SSCDPP - - X
FMT_MSA.3/SSCDPP - - X
FMT_MSA.4/SSCDPP - - X
FMT_MTD.1/Admin_SSCDPP - - X
FMT_MTD.1/Signatory_SSCDPP - - X
FMT_LIM.1/EAC2PP - X X
FMT_LIM.2/EAC2PP - X X
FMT_MTD.1/INI_ENA_EAC2PP - X X
FMT_MTD.1/INI_DIS_EAC2PP - X X
FMT_SMF.1/EAC1PP X - -
FMT_LIM.1/EAC1PP X - -
FMT_LIM.2/EAC1PP X - -
FMT_MTD.1/INI_ENA_EAC1PP X -
FMT_MTD.1/INI_DIS_EAC1PP X - -
FMT_MTD.1/CVCA_INI_EAC1PP X - -
FMT_MTD.1/CVCA_UPD_EAC1PP X - -
FMT_MTD.1/DATE_EAC1PP X - -
FMT_MTD.1/CAPK_EAC1PP X - -
FMT_MTD.1/PA_EAC1PP X - -
FMT_MTD.1/KEY_READ_EAC1PP X - -
FMT_MTD.3/EAC1PP - - -
FMT_LIM.1/Loader X X X
FMT_LIM.2/Loader X X X
FMT_MTD.1/AA_Private_Key X - -
FPT_EMS.1/EAC2PP - X X
FPT_FLS.1/EAC2PP - X X
FPT_TST.1/EAC2PP - X X
FPT_PHP.3/EAC2PP - X X
FPT_TST.1/EAC1PP X -
FPT_FLS.1/EAC1PP X -
FPT_PHP.3/EAC1PP X -
FPT_EMS.1/EAC1PP X -
FPT_EMS.1/SSCDPP - - X
FPT_FLS.1/SSCDPP - - X
FPT_PHP.1/SSCDPP - - X
FPT_PHP.3/SSCDPP - - X
FPT_TST.1/SSCDPP - - X
5. Application note (from the ST author)
537
Taking into consideration the [20] specifies authentication and communication protocols that
538
have to be used for the eSign application for the TOE, all the EAC2 relevant SFR are listed to
539
the eSign application as well. These SFRs contribute to secure Signature Verification Data
540
(SVD) export, Data To Be Signed (DTBS) import, and Verification Authentication Data (VAD)
541
import functionality.
542
IDentity Applet v3.4/eIDAS Security Target
Page 33 of 191
2. CONFORMANCE CLAIMS
543
2.1.CC Conformance Claim
544
This ST claims conformance to
545
• Common Criteria for Information Technology Security Evaluation, Part 1: Introduction
546
and general model; CCMB-2017-04-001, Version 3.1, Revision 5, April 2017, [1]
547
• Common Criteria for Information Technology Security Evaluation, Part 2: Security
548
functional components; CCMB-2017-04-002, Version 3.1, Revision 5, April 2017, [2]
549
• Common Criteria for Information Technology Security Evaluation, Part 3: Security
550
assurance components; CCMB-2017-04-003, Version 3.1, Revision 5, April 2017, [3]
551
as follows
552
Part 2 extended,
553
Part 3 conformant.
554
The
555
• Common Methodology for Information Technology Security Evaluation, Evaluation
556
methodology; CCMB-2017-04-004, Version 3.1, Revision 5, April 2017, [4]
557
has to be taken into account.
558
2.2.PP Claim
559
This ST claims strict conformance to the following protection profile:
560
Title: Machine-Readable Electronic Documents based on BSI TR-03110
561
for Official Use [MR.ED-PP] [20]
562
Sponsor: Bundesamt für Sicherheit in der Informationstechnik (BSI)
563
CC version: 3.1 (Revision 3.4)
564
Assurance Level: EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5.
565
General Status: Final
566
Version number: 1.01
567
Registration: BSI-CC-PP-0087
568
IDentity Applet v3.4/eIDAS Security Target
Page 34 of 191
Keywords: ICAO, PACE, EAC, Extended Access Control, ID-Card, electronic
569
document, smart card, TR-03110
570
571
Since the [20] claims strict conformance to [5], [6] and [14], this ST also claims strict
572
conformance to
573
Title: Machine Readable Travel Document with „ICAO Application”,
574
Extended Access Control with PACE (EAC PP) [5]
575
Sponsor: Bundesamt für Sicherheit in der Informationstechnik
576
CC Version: 3.1 (revision 3)
577
Assurance Level: EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5
578
General Status: Final
579
Version number: version 1.3.2
580
Registration: BSI-CC-PP-0056-V2-2012
581
Keywords: ICAO, Machine Readable Travel Document, Extended Access Control,
582
PACE, Supplemental Access Control (SAC)
583
584
Title: Common Criteria Protection Profile Electronic Document
585
implementing Extended Access Control Version 2 defined in BSI
586
TR-03110 [6]
587
Editor/Sponsor: Bundesamt für Sicherheit in der Informationstechnik (BSI)
588
CC Version: 3.1 (Revision 4)
589
Assurance Level: EAL4 augmented ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5.
590
General Status: final
591
Version Number: Version 1.01
592
Registration: BSI-CC-PP-0086
593
Keywords: EAC2, eID-Application, eID-Card, PACE
594
595
Title: Protection profiles for Secure signature creation device — Part 2:
596
Device with key generation
597
Author: CEN / CENELEC (TC224/WG17)
598
CC Version: 3.1 (Revision 3)
599
Assurance Level: EAL4 augmented with AVA_VAN.5
600
Version Number: Version 2.0.1
601
IDentity Applet v3.4/eIDAS Security Target
Page 35 of 191
Registration: BSI-CC-PP-0059-2009-MA-01
602
Keywords: secure signature-creation device, electronic signature, digital signature
603
6. Application note (taken from [20] Application note 7)
604
This conformance claim covers the part of the security policy for the eSign application of the
605
TOE corresponding to the security policy defined in [14], and hence is applicable, if the eSign
606
application is operational. In addition to [14], the current ST specifies authentication and
607
communication protocols (at least PACE) that have to be used for the eSign application of the
608
TOE. These protocols contribute to secure Signature Verification Data (SVD) export, Data To
609
Be Signed (DTBS) import, and Verification Authentication Data (VAD) import functionality.
610
Since [5] and [6] claim strict conformance to [13], this ST implicitly also claims strict
611
conformance to
612
Title: Machine Readable Travel Document using Standard Inspection
613
Procedure with PACE (PACE PP) [13]
614
Sponsor: Bundesamt für Sicherheit in der Informationstechnik
615
CC Version: 3.1 (revision 4)
616
Assurance Level: EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5
617
General Status: Final
618
Version number: Version 1.01
619
Registration: BSI-CC-PP-0068-V2-2011-MA-01
620
Keywords: ePassport, travel document, ICAO, PACE, Standard Inspection
621
Procedure, Supplemental Access Control (SAC)
622
623
However since [5] and [6] already claim strict conformance to [13], this implicit conformance
624
claim is formally mostly ignored within this ST for the sake of presentation; but if necessary to
625
yield a better overview however, references to [13] are given or the relation with [13] is
626
explained.
627
2.3.Package Claim
628
The current ST is conformant to the following packages:
629
Assurance package EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5 as
630
defined in [3].
631
IDentity Applet v3.4/eIDAS Security Target
Page 36 of 191
2.4.Conformance Rationale
632
This ST conforms to the PPs [20], [5], [6] and [14]. This implies for this ST:
633
1. The TOE type of this ST is the same as the TOE type of the claimed PPs:
634
The Target of Evaluation (TOE) is an electronic document implemented as a smart
635
card programmed according to [16] and [17], and additionally representing a
636
combination of hardware and software configured to securely create, use and manage
637
signature-creation data , for the eSign application.
638
2. The security problem definition (SPD) of this ST contains the SPD of the claimed PPs.
639
The SPD contains all threats, organizational security policies and assumptions of the
640
claimed PPs.
641
The current ST extended the OSP P.Terminal because of the optional Active
642
Authentication function of TOE.
643
3. The security objectives for the TOE in this ST include all the security objectives for the
644
TOE of the claimed PPs. This objective does not weaken the security objectives of the
645
claimed PPs.
646
In addition, the OT.Chip_Auth_Proof_PACE_CAM security objective is defined in the
647
ST because of the Chip Authentication mapping and OT.Chip_Auth_Proof_AA
648
because of the Active Authentication protocol.
649
4. The security objectives for the operational environment in this ST include all security
650
objectives for the operational environment of the claimed PPs.
651
In addition the OE.Auth_Key_AA and OE.Exam_Electronic_Document_AA security
652
objectives are defined in the ST because of the Active Authentication protocol. These
653
additions were necessary because none of the original security objectives for the TOE
654
or OSPs do not concern the obligations of States or Organization in connection with
655
Active Authentication protocol.
656
5. Those SFR, which are refined in order to ensure the unified terminology usage, are not
657
detailed in the following.
658
The SFRs specified in this ST include all security functional requirements (SFRs)
659
specified in the claimed PPs. We especially point to the following three refined SFRs
660
within [20]:
661
The SFR FIA_UAU.1/SSCDPP is redefined from [14] by additional assignments. Note
662
that this does not violate strict conformance to [14].
663
Multiple iterations of FDP_ACF.1 and FMT_SMR.1 exist from imported PPs to define
664
the access control SFPs and security roles for (common) user data, EAC1-protected
665
IDentity Applet v3.4/eIDAS Security Target
Page 37 of 191
user data, and EAC2-protected user data. These access control SFPs and security
666
roles are unified to FDP_ACF.1/TRM and FMT_SMR.1.
667
The following SFRs were iterated from FCS_CKM.1, FCS_COP.1 and FIA_API.1 to
668
the ST because of PACE-CAM:
669
• FCS_CKM.1/CAM
670
• FCS_COP.1/CAM
671
• FIA_API.1/PACE_CAM
672
The following SFR was extended to the ST because of PACE-CAM:
673
• FPT_EMS.1/EAC1PP
674
The following SFRs were refined to the ST because of PACE-CAM:
675
• FIA_UID.1/PACE_EAC1PP
676
• FIA_UAU.5/PACE_EAC1PP
677
The following SFRs were iterated from FCS_CKM.1, FCS_COP.1, FIA_API.1 and
678
FMT_MTD.1 to the ST because of Active Authentication protocol:
679
• FCS_CKM.1/AA
680
• FCS_COP.1/AA
681
• FIA_API.1/AA
682
• FMT_MTD.1/AA_Private_Key
683
The following SFRs was extended to the ST because of Active Authentication protocol:
684
• FIA_UAU.1/PACE_EAC1PP
685
• FPT_EMS.1/EAC1PP
686
The following SFRs were refined to the ST because of Active Authentication protocol:
687
• FIA_UAU.4/PACE_EAC1PP
688
• FMT_MTD.1/KEY_READ_EAC1PP
689
The following SFRs are iterated from FCS_CKM.1 because the TOE supports the Chip
690
Authentication version 2 and Restricted Identification key pair(s) generation on the TOE
691
as described in FMT_MTD.1/SK_PICC_EAC2PP. Furthermore, these SFRs were
692
refined to emphasize the purpose of the SFRs:
693
• FCS_CKM.1/CA2
694
• FCS_CKM.1/RI
695
The following SFR is refined because the electronic document manufacturer may
696
generate or load the private keys:
697
• FMT_MTD.1/SK_PICC_EAC2PP
698
The following SFR is slightly refined in order not to confuse Chip Authentication 1 with
699
Chip Authentication 2:
700
IDentity Applet v3.4/eIDAS Security Target
Page 38 of 191
• FDP_RIP.1/EAC2PP
701
These additional SFRs do not affect the strict conformance. All assignments and selections of
702
the security functional requirements are defined in the [6] section 6.1 and in this ST Security
703
Functional Requirements.
704
The extension of the OSP P.Terminal do not affect the strict conformance because it do not
705
modify the original requirements only added new requirements concern the Active
706
Authentication protocol.
707
The SARs specified in this ST are the same as specified in the claimed PPs or extend them.
708
2.5.Statement of Compatibility
709
2.5.1. SECURITY FUNCTIONALITIES
710
The following table contains the security functionalities of the [23] and of current ST, showing
711
which Functionality correspond to the [23] and which has no correspondence. This statement
712
is compliant to the requirements of [25].
713
A classification of SFs of the [23] has been made. Each TSF has been classified as ‘relevant’
714
or ‘not relevant’ for current ST.
715
Platform Security
Functionality
Corresponding TOE
Security Functionality
Relevant or not
relevant
Remarks
SF.JCVM TSF.Platform Relevant Java Card Virtual
Machine
SF.CONFIG TSF.Platform Relevant Configuration
Management
SF.OPEN TSF.AccessControl
TSF.Authenticate
TSF.Platform
Relevant Card Content
Management
SF.CRYPTO TSF.AppletParametersSi
gn
TSF.Authenticate
TSF.CryptoKey
TSF.Platform
Relevant Cryptographic
Functionality
SF.RNG TSF.CryptoKey
TSF.Platform
Relevant Random Number
Generator
SF.DATA_STORAG
E
TSF.AccessControl
TSF.AppletParametersSi
gn
TSF.CryptoKey
TSF.Platform
Relevant Secure Data
Storage
IDentity Applet v3.4/eIDAS Security Target
Page 39 of 191
Platform Security
Functionality
Corresponding TOE
Security Functionality
Relevant or not
relevant
Remarks
SF.PUF - Relevant User Data
Protection using
PUF
SF.EXT_MEM - Not relevant External Memory
SF.OM TSF.Platform Relevant Java Object
Management
SF.MM - Not relevant Memory
Management
SF.PIN TSF.AppletParametersSi
gn
TSF.Authenticate
Relevant PIN Management
SF.PERS_MEM TSF.Platform Relevant Persistent Memory
Management
SF.SENS_RES - Not relevant Sensitive Result
SF.EDC TSF.Platform Relevant Error Detection
Code API
SF.HW_EXC TSF.Platform Relevant Hardware
Exception Handling
SF.RM - Not relevant Restricted Mode
SF.PID - Not relevant Platform
Identification
SF.SMG_NSC TSF.Platform Relevant No Side-Channel
SF.ACC_SBX - Not relevant Secure Box
SF.MOD_INVOC - Not relevant Module Invocation
Table 6 Classification of Platform-TSFs
716
All the above SFs of [23], which are indicated as relevant are relevant for this ST.
717
2.5.2. OSPS
718
P.Card_PKI, P.Trustworthy_PKI, P.Terminal, P.Sensitive_Data, P.Personalisation,
719
P.EAC2_Terminal, P.RestrictedIdentity and P.Terminal_PKI are not applicable to the Platform
720
and therefore not mappable for [23].
721
The OSP.VERIFICATION, OSP.PROCESS-TOE, OSP.KEY-CHANGE are covered by the
722
ALC class, furthermore P.Manufact, P.Pre-Operational and P.Lim_Block_Loader correspond
723
to these OSPs.
724
OSP.SECURE-BOX and OSP.SECURITY-DOMAINS do not deal with any additional security
725
components.
726
2.5.3. SECURITY OBJECTIVES
727
These objectives from [23] can be mapped to this ST’s objectives as shown in the following
728
table, so they are relevant.
729
Objective from the Platform ST Objective from this ST
OT.ALARM OT.SCD_Secrecy
IDentity Applet v3.4/eIDAS Security Target
Page 40 of 191
OT.Tamper_Resistance
OT.Data_Integrity
OT.Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.CARD-CONFIGURATION OT.Prot_Abuse-Func
OT.CARD-MANAGEMENT OT.AC_Pers
OT.AC_Pers
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Identification
OT.Sens_Data_Conf
OT.AC_PERS_EAC2
OT.CIPHER OT.Lifecycle_Security
OT.SCD_Unique
OT.SCD_SVD_Corresp
OT.SCD_Secrecy
OT.AC_Pers
OT.Active_Auth_Proof
OT.Chip_Auth_Proof
OT.Chip_Auth_Proof_PACE_CAM
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Sens_Data_Conf
OT.CA2
OT.COMM_AUTH OT.Lifecycle_Security
OT.Sig_Secure
OT.TOE_QSCD_Auth
OT.AC_Pers
OT.Chip_Auth_Proof
OT.Chip_Auth_Proof_PACE_CAM
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Identification
OT.Sens_Data_Conf
OT.Tracing
OT.Sens_Data_EAC2
OT.COMM_CONFIDENTIALITY OT.Lifecycle_Security
OT.Sig_Secure
OT.TOE_QSCD_Auth
OT.TOE_TC_SVD_Exp
OT.AC_Pers
OT.Chip_Auth_Proof
OT.Chip_Auth_Proof_PACE_CAM
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
IDentity Applet v3.4/eIDAS Security Target
Page 41 of 191
OT.Identification
OT.Sens_Data_Conf
OT.Tracing
OT.RI_EAC2
OT.Sens_Data_EAC2
OT.COMM_INTEGRITY OT.Lifecycle_Security
OT.AC_Pers
OT.Chip_Auth_Proof
OT.Chip_Auth_Proof_PACE_CAM
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Identification
OT.Sens_Data_Conf
OT.Tracing
OT.Sig_Secure
OT.TOE_QSCD_Auth
OT.TOE_TC_SVD_Exp
OT.RI_EAC2
OT.Sens_Data_EAC2
OT.COMM_AUTH OT.AC_Pers
OT.Chip_Auth_Proof
OT.Chip_Auth_Proof_PACE_CAM
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Identification
OT.Sens_Data_Conf
OT.Tracing
OT.RI_EAC2
OT.AC_PERS_EAC2
OT.Sens_Data_EAC2
OT.DOMAIN-RIGHTS OT.AC_Pers
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Identification
OT.Sens_Data_Conf
OT.GLOBAL_ARRAYS_CONFID OT.SCD_Secrecy
OT.Sigy_SigF
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Sens_Data_EAC2
OT.IDENTIFICATION OT.AC_Pers
OT.Identification
OT.KEY-MNGT OT.Lifecycle_Security
OT.SCD_Unique
OT.SCD_SVD_Corresp
IDentity Applet v3.4/eIDAS Security Target
Page 42 of 191
OT.SCD_Secrecy
OT.Sig_Secure
OT.TOE_QSCD_Auth
OT.TOE_TC_SVD_Exp
OT.Sigy_SigF
OT.AC_Pers
OT.Chip_Auth_Proof
OT.Chip_Auth_Proof_PACE_CAM
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Prot_Inf_Leak
OT.Prot_Malfunction
OT.Sens_Data_Conf
OT.CA2
OT.RI_EAC2
OT.Sens_Data_EAC2
OT.OPERATE OT.SCD_Secrecy
OT.Data_Integrity
OT.Prot_Inf_Leak
OT.Prot_Malfunction
OT.Prot_Phys-Tamper
OT.PIN-MNGT OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Prot_Inf_Leak
OT.Prot_Malfunction
OT.Sens_Data_EAC2
OT.REALLOCATION OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Sens_Data_EAC2
OT.RESOURCES OT.Data_Integrity
OT.Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.RND OT.AC_Pers
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Sens_Data_Conf
OT.Sens_Data_EAC2
OT.RNG OT.AC_Pers
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Sens_Data_Conf
OT.Sens_Data_EAC2
OT.SCP.IC OT.AC_Pers
OT.Data_Integrity
OT.Prot_Inf_Leak
IDentity Applet v3.4/eIDAS Security Target
Page 43 of 191
OT.Prot_Phys-Tamper
OT.SCP.RECOVERY OT.Data_Integrity
OT.Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.SCP.SUPPORT OT.AC_Pers
OT.Chip_Auth_Proof
OT.Chip_Auth_Proof_PACE_CAM
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Sens_Data_Conf
OT.Tracing
OT.CA2
OT.RI_EAC2
OT.Sens_Data_EAC2
OT.SID_MODULE OT.Prot_Inf_Leak
OT.Prot_Malfunction
OT.TRANSACTION OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Sens_Data_EAC2
Table 7 Mapping of security objectives for the TOE
730
The following objectives of [23] are not relevant for or cannot be mapped to the TOE of this
731
ST:
732
• OT.SID
733
• OT.APPLI-AUTH
734
• OT.ATTACK-COUNTER
735
• OT.EXT-MEM
736
• OT.FIREWALL
737
• OT.Global_ARRAYS_INTEG
738
• OT.NATIVE
739
• OT.OBJ-DELETION
740
• OT.RESTRICTED-MODE
741
• OT.SEC_BOX_FW
742
• OT.SENSITIVE_RESULT_INTEG
743
cannot be mapped because these are out of scope.
744
The objectives for the operational environment can be mapped as follows:
745
Objective from the
Platform-ST
Classification
of OE
Objective from this ST
OE.APPLET CfPOE Covered by ALC class
IDentity Applet v3.4/eIDAS Security Target
Page 44 of 191
OE.PROCESS_SEC_IC CfPOE Covered by the Platform’s certification and ALC class
OE.VERIFICATION CfPOE Covered by ALC class
OE.CODE-EVIDENCE CfPOE Covered by ALC class
OE.USE_DIAG SgOE Covered by OE.Terminal, OE.Exam_Travel_Document,
OE.Prot_Logical_Travel_Document and OE.SSCD_Prov_Service
OE.USE_KEYS SgOE Covered by OE.Terminal, OE.Exam_Travel_Document,
OE.Prot_Logical_Travel_Document, OE.Terminal_Authentication and
OE.HID_VAD
OE.APPS-PROVIDER CfPOE Covered by ALC class
OE.VERIFICATION-
AUTHORITY
CfPOE Covered by ALC class
OE.KEY-CHANGE CfPOE Covered by ALC class
OE.SECURITY-
DOMAINS
CfPOE Covered by ALC class
There is no conflict between security objectives of this ST and the [23].
746
2.5.4. SECURITY REQUIREMENTS
747
The Security Requirements of the Platform ST can be mapped as follows:
748
Platform SFR Corresponding
TOE SFR
Category of Platform’s
SFRs
Remarks
FAU_ARP.1 FPT_PHP.3/EAC2PP
FPT_PHP.3/EAC1PP
FPT_PHP.3/SSCDPP
RP_SFR-MECH FAU_ARP.1 facilitate to
protect the TOE as required
by these SFRs./SSCD
FAU_SAS.1[SCP] FAU_SAS.1/EAC2PP
FAU_SAS.1/EAC1PP
RP_SFR-MECH FAU_SAS.1[SCP] covers these
SFRs.
FCO_NRO.2[SC] - IP_SFR -
FCS_CKM.1t - IP_SFR -
FCS_COP.1 FCS_CKM.1/DH_PACE_E
AC2PP
FCS_CKM.1/DH_PACE_E
AC1PP
RP_SFR-SERV FCS_COP.1.1[ECDHPACEKeyA
greement] is applied for key
agreement during the PACE
and CA2 protocols.
FCS_COP1.1[SHA] is applied
for session key derivation
during PACE, protocols.
IDentity Applet v3.4/eIDAS Security Target
Page 45 of 191
Platform SFR Corresponding
TOE SFR
Category of Platform’s
SFRs
Remarks
FCS_CKM.1/CAM RP_SFR-SERV FCS_COP.1.1[ECDHPACEKeyA
greement] is applied for key
agreement during the PACE-
CAM.
FCS_CKM.1/CA2 RP_SFR-SERV FCS_CKM.1.1 is applied for
generation chip
authentication key(s) pair on
the TOE:
FCS_CKM.1/RI RP_SFR-SERV FCS_CKM.1.1 is applied for
generation chip restricted
identification key pair(s) on
the TOE:
FCS_CKM.1/AA RP_SFR-SERV FCS_CKM.1.1 is applied for
generation chip active
authentication key pair on
the TOE:
FCS_CKM.1/SSCDPP RP_SFR-SERV FCS_CKM.1.1 is applied for
generation chip SCD/SVD key
pair on the TOE:
FCS_COP.1/PACE_ENC_
EAC2PP
RP_SFR-SERV FCS_COP1.1[AES] is applied
for nonce encryption during
the PACE protocol.
FCS_COP1.1[AES] is applied
for encryption and decryption
during secure messaging
(PACE)
FCS_COP.1/PACE_ENC_
EAC1PP
RP_SFR-SERV FCS_COP1.1[AES] or
FCS_COP.1[TripleDES] is
applied for nonce encryption
during the PACE-CAM
protocol.
FCS_COP1.1[AES] or
FCS_COP.1[TripleDES] is
applied for encryption and
decryption during secure
messaging (PACE).
FCS_COP.1/SHA_EAC2P
P
RP_SFR-SERV FCS_COP1.1[SHA] is applied
for session key derivation
during CA2 and ephemeral
key compression (CA2 and
TA2).
FCS_COP.1/CAM RP_SFR-SERV FCS_COP.1.1[AES] is applied
for message encryption of
Chip Authentication Data.
FCS_CKM.1/CA_EAC1PP RP_SFR-SERV FCS_COP.1.1[ECDHPACEKeyA
greement] is applied for key
agreement related to CA1
FCS_COP1.1[SHA] is applied
for session key derivation
during CA1.
FCS_COP.1/SIG_VER_EA
C2PP
RP_SFR-SERV FCS_COP.1.1[RSASignaturePK
CS1]
orFCS_COP.1.1[ECSignature]
IDentity Applet v3.4/eIDAS Security Target
Page 46 of 191
Platform SFR Corresponding
TOE SFR
Category of Platform’s
SFRs
Remarks
for digital signature
verification related to TA2.
FCS_COP.1/PACE_MAC_
EAC2PP
RP_SFR-SERV FCS_COP.1.1[AESMAC] is
applied to generate and verify
the message authentication
codes.
FCS_COP.1/PACE_MAC_
EAC1PP
RP_SFR-SERV FCS_COP.1.1[DESMAC] or
FCS_COP.1.1[AESMAC] is
applied to generate and verify
the message authentication
codes.
FCS_COP.1/CA_ENC_EA
C1PP
RP_SFR-SERV FCS_COP.1[TripleDES] or
FCS_COP1.1[AES] is applied
for encryption and decryption
during secure messaging
(CA1)
FCS_COP.1/CA_MAC_E
AC1PP
RP_SFR-SERV FCS_COP.1.1[DESMAC] or
FCS_COP.1.1[AESMAC] is
applied to generate and verify
the message authentication
codes (CA1)
FCS_COP.1/SIG_VER_EA
C1PP
RP_SFR-SERV FCS_COP.1.1[RSASignaturePK
CS1]
orFCS_COP.1.1[ECSignature]
for digital signature
verification related to TA1.
FCS_COP.1/AA RP_SFR-SERV FCS_COP.1.1[RSASignaturePK
CS1]
orFCS_COP.1.1[ECSignature]
for digital signature
generation related to Active
Authentication.
FCS_COP.1/SSCDPP RP_SFR-SERV FCS_COP.1.1[RSASignaturePK
CS1] or
FCS_COP.1.1[ECSignature]
for digital signature creation.
FIA_API.1/CA_EAC2PP RP_SFR-SERV FCS_COP.1 fAESMAC] is
applied for generating the
authentication token.
FIA_API.1/RI_EAC2PP RP_SFR-SERV FCS_COP.1.1[ECDHPACEKeyA
greement] is applied for key
agreement related to RI
FCS_COP1.1[SHA] is applied
for restricted identification.
FIA_UAU.5/PACE_EAC2
PP
RP_SFR-SERV FCS_COP1.1[AESMAC] is
applied during PACE secure
messaging the verify the
message authentication
codes.
FCS_COP1.1[AESMAC] is
applied during CA secure
messaging to verify the
IDentity Applet v3.4/eIDAS Security Target
Page 47 of 191
Platform SFR Corresponding
TOE SFR
Category of Platform’s
SFRs
Remarks
message authentication
codes.
FCS_COP1.1[AESMAC] is
applied during secure
messaging to verify the
message authentication
codes.
FCS_COP1.1[SHA] is applied
for public key compression (in
case DH).
FIA_UAU.5/PACE_EAC1
PP
RP_SFR-SERV FCS_COP1.1[DESMAC] or
FCS_COP1.1[AESMAC] is
applied during PACE secure
messaging the verify the
message authentication
codes.
FCS_COP1.1[DESMAC] or
FCS_COP1.1[AESMAC] is
applied during CA secure
messaging to verify the
message authentication
codes.
FCS_COP1.1[DESMAC] or
FCS_COP1.1[AESMAC] is
applied during secure
messaging (based on
Personalisation Agent Key) to
verify the message
authentication codes.
FCS_COP1.1[SHA] is applied
for public key compression (in
case DH).
FIA_UAU.6/PACE_EAC2
PP
FIA_UAU.6/PACE_EAC1
PP
RP_SFR-SERV FCS_COP1.1[DESMAC] or
FCS_COP1.1[AESMAC] is
applied during PACE secure
messaging the verify the
message authentication
codes
FIA_UAU.6/EAC_EAC1P
P
RP_SFR-SERV FCS_COP.1.1[AESMAC] o
FCS_COP.1[DESMAC] is
applied for message
authentication code
generation and verification
related to PACE.
FIA_UAU.6/CA_EAC2PP RP_SFR-SERV FCS_COP.1.1[AESMAC] is
applied for message
authentication code
generation and verification
related to CA2.
FIA_UAU.6/EAC_EAC1P
P
RP_SFR-SERV FCS_COP.1.1[AESMAC] o
FCS_COP.1[DESMAC] is
applied for message
authentication code
IDentity Applet v3.4/eIDAS Security Target
Page 48 of 191
Platform SFR Corresponding
TOE SFR
Category of Platform’s
SFRs
Remarks
generation and verification
related to CA1.
FIA_API.1/EAC1PP RP_SFR-SERV FCS_COP1.1[AESMAC] is
applied for message
authentication code
verification related to CA1.
FIA_API.1/AA RP_SFR-SERV FCS_COP.1.1[RSASignaturePK
CS1] or
FCS_COP.1.1[ECSignature] is
applied for digital signature
verification for Active
Authentication protocol..
FIA_API.1/PACE_CAM RP_SFR-SERV FCS_COP.1.1[AESMAC] is
applied for chip
authentication data
generation related to PACE-
CAM.
FDP_UCT.1/TRM_EAC1P
P
RP_SFR-SERV FCS_COP.1.1[RSASignaturePK
CS1] or
FCS_COP.1.1[ECSignature] is
applied for digital signature
verification for TA.
FDP_UIT.1/TRM_EAC1P
P
RP_SFR-SERV FCS_COP1.1[DESMAC] or
FCS_COP1.1[AESMAC] is
applied during PACE secure
messaging the verify the
message authentication
codes.
FCS_COP1.1[DESMAC] or
FCS_COP1.1[AESMAC] is
applied during CA secure
messaging to verify the
message authentication
codes.
FCS_COP1.1[DESMAC] or
FCS_COP1.1[AESMAC] is
applied during secure
messaging (based on
Personalisation Agent Key) to
verify the message
authentication codes.
FCS_COP1.1[SHA] is applied
for public key compression (in
case DH).
FTP_ITC.1/PACE_EAC2P
P
RP_SFR-SERV FCS_COP.1[AES] and or
FCS_COP.1[AESMAC] are
applied during secure
messaging to protect against
disclosure and modification
FTP_ITC.1/CA_EAC2PP RP_SFR-SERV FCS_COP.1[AES] and
FCS_COP.1[AESMAC] are
applied during secure
IDentity Applet v3.4/eIDAS Security Target
Page 49 of 191
Platform SFR Corresponding
TOE SFR
Category of Platform’s
SFRs
Remarks
messaging to protect against
disclosure and modification
FTP_ITC.1/PACE_EAC1P
P
RP_SFR-SERV FCS_COP.1[TripleDES] or
FCS_COP.1[AES] and
FCS_COP.1[DESMAC] or
FCS_COP.1[AESMAC] are
applied during secure
messaging to protect against
disclosure and modification
FMT_MTD.3/EAC2PP
FMT_MTD.3/EAC1PP
RP_SFR-SERV FCS_COP.1.1[RSASignaturePK
CS1] or
FCS_COP.1.1[ECSignature] is
applied for digital signature
verification for TA1 and TA2.
FCS_RNG.1 FCS_RND.1/EAC2PP RP_SFR-SERV FCS_RNG.1 provides nonce
and challenge generation for
PACE and TA2.
FCS_RND.1/EAC1PP RP_SFR-SERV FCS_COP.1[TripleDES] or
FCS_COP.1[AES] is applied
during secure messaging to
protect the confidentiality of
transmitted and received
user data.
FIA_UAU.4/PACE_EAC2
PP
RP_SFR-SERV FCS_RNG.1 is applied to
generate fresh nonce for
PACE and TA2
FIA_UAU.4/PACE_EAC1
PP
RP_SFR-SERV FCS_RNG.1 is applied to
generate fresh nonce for
PACE, TA1 and Active
Authentication.
FDP_UCT.1/TRM_EAC2P
P
RP_SFR-SERV FCS_COP.1[AESMAC] is
applied during secure
messaging to protect the
integrity of transmitted and
received user data.
FDP_UIT.1/TRM_EAC2P
P
RP_SFR-SERV FCS_COP.1[AES] is applied
during secure messaging to
protect the confidentiality of
transmitted and received
user data.
FCS_CKM.4 FCS_CKM.4/EAC2PP RP_SFR-SERV FCS_CKM.4 of the Platform
matches this SFR..
FCS_RNG.1[HDT
]
- IP_SFR -
FDP_ACC.2[FIRE
WALL]
- IP_SFR
FDP_ACF.1[FIRE
WALL]
- IP_SFR
FDP_ACC.1[SD] - IP_SFR -
FDP_ACF.1[SD] - IP_SFR
FDP_ACC.2[ADE
L]
- IP_SFR -
IDentity Applet v3.4/eIDAS Security Target
Page 50 of 191
Platform SFR Corresponding
TOE SFR
Category of Platform’s
SFRs
Remarks
FDP_ACF.1[ADE
L]
- IP_SFR
FDP_ACC.2[RM] - IP_SFR -
FDP_ACC.1[EXT-
MEM]
- IP_SFR
FDP_ACF.1[EXT-
MEM]
- IP_SFR -
FDP_ACC.2[Secu
reBox]
- IP_SFR
FDP_ACF.1[Secu
reBox]
- IP_SFR
FDP_ACF.1[RM] - IP_SFR -
FDP_IFC.1[JCVM
]
- IP_SFR -
FDP_IFC.2[SC] - IP_SFR -
FDP_IFC.2[CFG] FMT_LIM.1/Loader
FMT_LIM.2/Loader
FMT_LIM.1/EAC2PP
FMT_LIM.2/EAC2PP
FMT_LIM.1/EAC1PP
FMT_LIM.2/EAC1PP
RP_SFR-MECH FDP_IFC.2[CFG] applied to
protect the TOE in
operational phase.
FDP_IFC.1[MOD
ULAR-DESIGN]
- IP_SFR
FDP_IFF.1[JCVM
]
- IP_SFR -
FDP_IFF.1[SC] FMT_MTD.1/INI_ENA_E
AC2PP
FMT_MTD.1/INI_DIS_E
AC2PP
FMT_MTD.1/INI_ENA_E
A1PP
FMT_MTD.1/INI_DIS_E
AC1PP
RP_SFR-MECH FDP_IFF.1[SC] applied to
control the writing of
initialization and pre-
personalization data as
required by these SFRs.
FDP_IFF.1[CFG] - IP_SFR -
FDP_IFF.1[MOD
ULAR-DESIGN]
- IP_SFR -
FDP_ITC.2[CCM] - IP_SFR -
FDP_RIP.1[OBJE
CTS]
- IP_SFR -
FDP_RIP.1[ABO
RT]
- IP_SFR -
FDP_RIP.1[APD
U]
- IP_SFR -
FDP_RIP.1[bArra
y]
- IP_SFR -
FDP_RIP.1[Glob
alArray_Refined
]
- IP_SFR -
FDP_RIP.1[KEYS] FDP_RIP.1/EAC2PP
FDP_RIP.1/EAC1PP
FDP_RIP.1/SSCDPP
RP_SFR-MECH FDP_RIP.1[KEYS] is applied to
destroy the secure message
session keys, the PACE
IDentity Applet v3.4/eIDAS Security Target
Page 51 of 191
Platform SFR Corresponding
TOE SFR
Category of Platform’s
SFRs
Remarks
ephemeral private key and
SCD.
FDP_RIP.1[TRAN
SIENT]
- IP_SFR -
FDP_RIP.1[ADEL
]
- IP_SFR -
FDP_RIP.1[ODEL
]
- IP_SFR -
FDP_ROL.1[FIRE
WALL]
- IP_SFR -
FDP_ROL.1[CCM
]
- IP_SFR -
FDP_SDI.2[DATA
]
FPT_TST.1/EAC2PP
FPT_TST.1/EAC1PP
FPT_TST.1/SSCDPP
RP_SFR-MECH FDP_SDI.2[DATA] checks the
integrity of TSF data.
FDP_SDI.2/DTBS_SSCDP
P
RP_SFR-MECH FDP_SDI.2[DATA] is applied
to protect DTBS against
integrity errors.
FDP_SDI.2/Persistent_S
SCDPP
RP_SFR-MECH FDP_SDI.2[DATA] is applied
to protect SCD against
integrity errors.
FDP_SDI.2[SENS
ITIVE_RESULT]
- IP_SFR -
FDP_UIT.1[CCM] - IP_SFR -
FIA_AFL.1[PIN] FIA_AFL.1/PACE_EAC2P
P
IP_SFR FIA_AFL.1[PIN] is applied for
PIN management.
FIA_AFL.1/SSCDPP IP_SFR FIA_AFL.1[PIN] is applied for
PIN management.
FIA_ATD.1[AID] - IP_SFR -
FIA_ATD.1[MOD
ULAR-DESIGN]
- IP_SFR -
FIA_UID.1[SC] FIA_UID.1/PACE_EAC2P
P
FIA_UID.1/EAC2_Termin
al_EAC2PP
FIA_UID.1/PACE_EAC1P
P
RP_SFR-MECH FIA_UID.1[SC] handled the
identifier data of the TOE.
FIA_UID.1[CFG] - IP_SFR -
FIA_UID.1[RM] - IP_SFR -
FIA_UID.2[AID] - IP_SFR -
FIA_UID.1[MOD
ULAR-DESIGN]
- IP_SFR -
FIA_USB.1[AID] - IP_SFR -
FIA_USB.1[MOD
ULAR-DESIGN]
- IP_SFR -
FIA_UAU.1[RM] - IP_SFR
FIA_UAU.1[SC] FIA_UAU.1/EAC2_Termi
nal_EAC2PP
FIA_UAU.1/PACE_EAC2
PP
FIA_UAU.1/PACE_EAC1
PP
RP_SFR-MECH FIA_UAU.1[SC] handled the
identifier data of the TOE.
IDentity Applet v3.4/eIDAS Security Target
Page 52 of 191
Platform SFR Corresponding
TOE SFR
Category of Platform’s
SFRs
Remarks
FIA_UAU.4[SC] - IP_SFR -
FMT_MSA.1[JCR
E]
- IP_SFR -
FMT_MSA.1[JCV
M]
- IP_SFR -
FMT_MSA.1[AD
EL]
- IP_SFR -
FMT_MSA.1[SC] - IP_SFR -
FMT_MSA.1[EXT
-MEM]
- IP_SFR -
FMT_MSA.1[Sec
ureBox]
- IP_SFR -
FMT_MSA.1[CF
G]
- IP_SFR -
FMT_MSA.1[SD] - IP_SFR -
FMT_MSA.1[RM
]
- IP_SFR -
FMT_MSA.1[MO
DULAR-DESIGN]
- IP_SFR -
FMT_MSA.2[FIR
EWALL-JCVM]
- IP_SFR -
FMT_MSA.3[FIR
EWALL]
- IP_SFR -
FMT_MSA.3[JCV
M]
- IP_SFR -
FMT_MSA.3[AD
EL]
- IP_SFR -
FMT_MSA.3[EXT
-MEM]
- IP_SFR -
FMT_MSA.3[Sec
ureBox]
- IP_SFR -
FMT_MSA.3[CF
G]
- IP_SFR -
FMT_MSA.3[SD] - IP_SFR -
FMT_MSA.3[SC] - IP_SFR -
FMT_MSA.3[RM
]
- IP_SFR -
FMT_MSA.3[MO
DULAR-DESIGN]
- IP_SFR -
FMT_MTD.1[JCR
E]
- IP_SFR -
FMT_MTD.3[JCR
E]
- IP_SFR -
FMT_SMF.1 - IP_SFR -
FMT_SMF.1[AD
EL]
- IP_SFR -
FMT_SMF.1[EXT
-MEM]
- IP_SFR -
FMT_SMF.1[Sec
ureBox]
- IP_SFR -
IDentity Applet v3.4/eIDAS Security Target
Page 53 of 191
Platform SFR Corresponding
TOE SFR
Category of Platform’s
SFRs
Remarks
FMT_SMF.1[CFG
]
- IP_SFR -
FMT_SMF.1[SD] - IP_SFR -
FMT_SMF.1[SC] - IP_SFR -
FMT_SMF.1[RM
]
- IP_SFR -
FMT_SMF.1[MO
DULAR-DESIGN]
- IP_SFR -
FMT_SMR.1 - IP_SFR -
FMT_SMR.1[INS
TALLER]
- IP_SFR -
FMT_SMR.1[AD
EL]
- IP_SFR -
FMT_SMR.1[CF
G]
- IP_SFR -
FMT_SMR.1[SD] - IP_SFR -
FMT_SMR.1[MO
DULAR-DESIGN]
- IP_SFR -
FPR_UNO.1 - IP_SFR -
FPT_EMSEC.1 FPT_EMS.1/EAC2PP
FPT_EMS.1/EAC1PP
FPT_EMS.1/SSCDPP
RP_SFR-MECH FPT_EMSEC.1 of the Platform
matches these SFRs.
FPT_FLS.1 FPT_FLS.1/EAC2PP
FPT_FLS.1/EAC1PP
FPT_FLS.1/SSCDPP
RP_SFR-MECH FPT_FLS.1 of the Platform
ensures the secure state of
the TOE as required by
FPT_FLS.1
FPT_FLS.1[INSTA
LLER]
- IP_SFR -
FPT_FLS.1[ADEL] - IP_SFR -
FPT_FLS.1[ODEL
]
- IP_SFR -
FPT_FLS.1[CCM] - IP_SFR -
FPT_FLS.1[MOD
ULAR-DESIGN]
- IP_SFR -
FPT_TDC.1 - IP_SFR -
FPT_RCV.3[INST
ALLER]
- IP_SFR -
FPT_PHP.3 FPT_PHP.3/EAC2PP
FPT_PHP.3/EAC1PP
FPT_PHP.1/SSCDPP
FPT_PHP.3/SSCDPP
RP_SFR-MECH FPT_PHP.3 of the Platform
matches these SFRs.
FTP_ITC.1[SC] - IP_SFR -
ADV_SPM.1 - IP_SFR -
Table 8 Mapping of Security requirements
749
The FMT_LIM.1/EAC2PP, FMT_LIM.2/EAC2PP, FMT_LIM.1/EAC1PP and
750
FMT_LIM.2/EAC1PP are not covered directly by [23]. As described in [20] the purposes of
751
these SFRs is to prevent misuse of test features of the TOE over the life cycle phases.
752
IDentity Applet v3.4/eIDAS Security Target
Page 54 of 191
According to [23] the Platform consists of the Micro Controller, CryptoLibrary and Operation
753
System, which are certified as well. By the Micro Controller the limited availability and capability
754
of test features are ensured after Manufacturing phase of the TOE. FMT_LIM.1 and
755
FMT_LIM.2 is covered by the following Security Functions of Micro Controller ST: TSF.Control.
756
For details please check: [34]
757
To sum up the above-mentioned Security Functions of Micro Controller ensure that the test
758
features of TOE cannot be misused.
759
The Personalization Agent (FMT_SMR.1) may use the GlobalPlatform function of the Platform.
760
The TOE initialization and pre-personalization (FMT_SMF.1/EAC2PP and
761
FMT_SMF.1/EAC1PP) rely on the Platform functions.
762
763
2.5.5. ASSURANCE REQUIREMENTS
764
This ST requires EAL 4 according to Common Criteria V3.1 R5 augmented by ALC_DVS.2,
765
ATE_DPT.2 and AVA_VAN.5.
766
The [23] requires EAL 6 according to Common Criteria V3.1 R5 augmented by: ASE_TSS.2
767
and ALC_FLR.1.
768
As EAL 6 covers all assurance requirements of EAL 4 all non-augmented parts of this ST will
769
match to the [23] assurance requirements.
770
2.6.Analysis
771
Overall there is no conflict between security requirements of this ST and [23].
772
IDentity Applet v3.4/eIDAS Security Target
Page 55 of 191
3. SECURITY PROBLEM DEFINITION
773
3.1.Introduction
774
3.1.1. ASSETS
775
3.1.1.1.Primary Assets
776
As long as they are in the scope of the TOE, the primary assets to be protected by the TOE
777
are listed below. For a definition of terms used, but not defined here, see the Glossary.
778
Authenticity of the Electronic Document’s Chip
779
The authenticity of the electronic document’s chip personalized by the issuing state or
780
organization for the Electronic Document Holder, is used by the electronic document presenter
781
to prove his possession of a genuine electronic document.
782
Generic Security Property: Authenticity
783
This asset is equal to the one(s) of [5] and [6], which itself stem from [13].
784
Electronic Document Tracing Data
785
Technical information about the current and previous locations of the electronic document
786
gathered unnoticeable by the Electronic Document Holder recognizing the TOE not knowing
787
any PACE password. TOE tracing data can be provided / gathered.
788
Generic Security Property: Unavailability
789
This asset is equal to the one(s) of [5] and [6], which itself stem from [13]. Note that
790
unavailability here is required for anonymity of the Electronic Document Holder.
791
Sensitive User Data
792
User data, which have been classified as sensitive data by the electronic document issuer, e.
793
g. sensitive biometric data. Sensitive user data are a subset of all user data, and are protected
794
by EAC1, EAC2, or both.
795
Generic Security Properties: Confidentiality, Integrity, Authenticity
796
IDentity Applet v3.4/eIDAS Security Target
Page 56 of 191
User Data stored on the TOE
797
All data, with the exception of authentication data, that are stored in the context of the
798
application(s) on the electronic document. These data are allowed to be read out, used or
799
modified either by a PACE terminal, or, in the case of sensitive data, by an EAC1 terminal or
800
an EAC2 terminal with appropriate authorization level.
801
Generic Security Properties: Confidentiality, Integrity, Authenticity
802
This asset is included from [5] and [6] respectively. In these protection profiles it is an extension
803
of the asset defined in [13]. This asset also includes ”SVD” (Integrity and Authenticity only),
804
“SCD” of [14].
805
User Data transferred between the TOE and the Terminal
806
All data, with the exception of authentication data, that are transferred (both directions) during
807
usage of the application(s) of the electronic document between the TOE and authenticated
808
terminals.
809
Generic Security Properties: Confidentiality, Integrity, Authenticity
810
This asset is included from [5] and [6] respectively. In these protection profiles it is an extension
811
of the asset defined in [13]. As for confidentiality, note that even though not each data element
812
being transferred represents a secret, [16], [17] resp. require confidentiality of all transferred
813
data by secure messaging in encrypt-then-authenticate mode. This asset also includes “DTBS”
814
of [14].
815
3.1.1.2.Secondary Assets
816
In order to achieve a sufficient protection of the primary assets listed above, the following
817
secondary assets also have to be protected by the TOE.
818
Accessibility to the TOE Functions and Data only for Authorized Subjects
819
Property of the TOE to restrict access to TSF and TSF-Data stored in the TOE to authorized
820
subjects only.
821
Generic Security Property: Availability
822
Genuineness of the TOE
823
Property of the TOE to be authentic in order to provide claimed security functionality in a proper
824
way.
825
IDentity Applet v3.4/eIDAS Security Target
Page 57 of 191
Generic Security Property: Availability
826
Electronic Document Communication Establishment Authorization Data
827
Restricted-revealable authorization information for a human user being used for verification of
828
the authorization attempts as an authorized user (PACE password). These data are stored in
829
the TOE and are not send to it.
830
Restricted-revealable here refers to the fact that if necessary, the Electronic Document Holder
831
may reveal her verification values of CAN and MRZ to an authorized person, or to a device
832
that acts according to respective regulations and is considered trustworthy.
833
Generic Security Properties: Confidentiality, Integrity
834
Secret Electronic Document Holder Authentication Data
835
Secret authentication information for the Electronic Document Holder being used for
836
verification of the authentication attempts as authorized Electronic Document Holder (PACE
837
passwords).
838
Generic Security Properties: Confidentiality, Integrity
839
TOE internal Non-Secret Cryptographic Material
840
Permanently or temporarily stored non-secret cryptographic (public) keys and other non-secret
841
material used by the TOE in order to enforce its security functionality.
842
Generic Security Properties: Integrity, Authenticity
843
TOE internal Secret Cryptographic Keys
844
Permanently or temporarily stored secret cryptographic material used by the TOE in order to
845
enforce its security functionality.
846
Generic Security Properties: Confidentiality, Integrity
847
7. Application note (taken from [20], application note 8)
848
The above secondary assets represent TSF and TSF-Data in the sense of CC.
849
3.1.2. SUBJECTS
850
This ST considers the following external entities and subjects:
851
IDentity Applet v3.4/eIDAS Security Target
Page 58 of 191
Attacker
852
A threat agent (a person or a process acting on his behalf) trying to undermine the security
853
policy defined by the current ST, especially to change properties of the assets that have to be
854
maintained. The attacker is assumed to possess at most high attack potential. Note that the
855
attacker might capture any subject role recognized by the TOE.
856
Country Signing Certification Authority (CSCA)
857
An organization enforcing the policy of the electronic document issuer, i.e. confirming
858
correctness of user and TSF data that are stored within the electronic document. The CSCA
859
represents the country specific root of the public key infrastructure (PKI) for the electronic
860
document and creates Document Signer Certificates within this PKI. The CSCA also issues a
861
self-signed CSCA certificate that has to be distributed to other countries by secure diplomatic
862
means, see [7].
863
Country Verifying Certification Authority (CVCA)
864
The Country Verifying Certification Authority (CVCA) enforces the privacy policy of the issuing
865
state or organization, i. e. enforcing protection of Sensitive User Data that are stored in the
866
electronic document. The CVCA represents the country specific root of the PKI of EAC1
867
terminals, EAC2 terminals respectively, and creates Document Verifier Certificates within this
868
PKI. Updates of the public key of the CVCA are distributed as CVCA Link-Certificates.
869
Document Signer (DS)
870
An organization enforcing the policy of the CSCA. A DS signs the Document Security Object
871
that is stored on the electronic document for Passive Authentication. A Document Signer is
872
authorized by the national CSCA that issues Document Signer Certificate, see [7]. Note that
873
this role is usually delegated to a Personalization Agent.
874
Document Verifier (DV)
875
An organization issuing terminal certificates as a Certificate Authority, authorized by the
876
corresponding CVCA to issue certificates for EAC1 terminals, EAC2 terminals respectively,
877
see [18].
878
Electronic Document Holder
879
A person the electronic document issuer has personalized the electronic document for.
880
Personalization here refers to associating a person uniquely with a specific electronic
881
document. This subject includes “Signatory” as defined [14].
882
IDentity Applet v3.4/eIDAS Security Target
Page 59 of 191
Electronic Document Presenter
883
A person presenting the electronic document to a terminal and claiming the identity of the
884
Electronic Document Holder. Note that an electronic document presenter can also be an
885
attacker. Moreover, this subject includes “user” as defined in [14].
886
Manufacturer
887
Generic term comprising both the IC manufacturer that produces the integrated circuit, and the
888
electronic document manufacturer that creates the electronic document and attaches the IC to
889
it. The manufacturer is the default user of the TOE during the manufacturing life cycle phase.
890
When referring to the role manufacturer, the TOE itself does not distinguish between the IC
891
manufacturer and the electronic document manufacturer.
892
PACE Terminal
893
A technical system verifying correspondence between the password stored in the electronic
894
document and the related value presented to the terminal by the electronic document
895
presenter. A PACE terminal implements the terminal part of the PACE protocol and
896
authenticates itself to the electronic document using a shared password (CAN, eID-PIN, eID-
897
PUK or MRZ). A PACE terminal is not allowed reading Sensitive User Data.
898
Personalization Agent
899
An organization acting on behalf of the electronic document issuer that personalizes the
900
electronic document for the Electronic Document Holder. Personalization includes some or all
901
of the following activities:
902
(i) establishing the identity of the Electronic Document Holder for the biographic data
903
in the electronic document,
904
(ii) enrolling the biometric reference data of the Electronic Document Holder,
905
(iii) writing a subset of these data on the physical electronic document (optical
906
personalization) and storing them within the electronic document's chip (electronic
907
personalization),
908
(iv) writing document meta data (i. e. document type, issuing country, expiry date, etc.)
909
(v) writing the initial TSF data, and
910
(vi) signing the Document Security Object, and the elementary files EF.CardSecurity
911
and the EF.ChipSecurity (if applicable [7], [18]) in the role DS. Note that the role
912
Personalization Agent may be distributed among several institutions according to
913
IDentity Applet v3.4/eIDAS Security Target
Page 60 of 191
the operational policy of the electronic document issuer. This subject includes
914
“Administrator” as defined in [14].
915
EAC1 Terminal / EAC2 Terminal
916
A terminal that has successfully passed the Terminal Authentication protocol (TA) version 1 is
917
an EAC1 terminal, while an EAC2 terminal needs to have successfully passed TA version 2.
918
Both are authorized by the electronic document issuer through the Document Verifier of the
919
receiving branch (by issuing terminal certificates) to access a subset or all of the data stored
920
on the electronic document.
921
Terminal
922
A terminal is any technical system communicating with the TOE through the contactless or
923
contact-based interface. The role terminal is the default role for any terminal being recognized
924
by the TOE as neither being authenticated as a PACE terminal nor an EAC1 terminal nor an
925
EAC2 terminal.
926
3.2.Threats
927
This section describes the threats to be averted by the TOE independently or in collaboration
928
with its IT environment. These threats result from the assets protected by the TOE and the
929
method of the TOE's use in the operational environment.
930
T.InconsistentSec
931
Inconsistency of security measures
932
Adverse action: An attacker gains read or write access to user data or TOE data
933
without being allowed to, due to an ambiguous/unintended
934
configuration of the TOE's internal access conditions of user or
935
TSF data. This may lead to a forged electronic document or
936
misuse of user data.
937
Threat agent: having high attack potential, being in possession of one or more
938
legitimate electronic documents
939
Asset: authenticity, integrity and confidentiality of User Data stored on
940
the TOE
941
IDentity Applet v3.4/eIDAS Security Target
Page 61 of 191
T.Interfere
942
Interference of security protocols
943
Adverse action: An attacker uses an unintended interference of implemented
944
security protocols to gain access to user data.
945
Threat agent: having high attack potential, being in possession of one or more
946
legitimate electronic documents
947
Asset: authenticity, integrity and confidentiality of User Data stored on
948
the TOE
949
3.2.1. THREATS FROM EAC1PP
950
This ST includes the following threats from [5]. They concern EAC1-protected data.
951
• T.Counterfeit
952
• T.Read_Sensitive_Data
953
Due to identical definitions and names they are not repeated here. For the remaining threats
954
from [5], cf. Chapter 3.2.3.
955
3.2.2. THREATS FROM EAC2PP
956
This ST includes the following threats from the [6]. They concern EAC2-protected data.
957
• T.Counterfeit/EAC2
958
• T.Sensitive_Data
959
Due to identical definitions and names, they are not repeated here.
960
3.2.3. THREATS FROM PACEPP
961
Both [5] and [6] claim [13], and thus include the threats formulated in [13]. We list each threat
962
only once here. Due to identical definitions and names, their definitions are not repeated here.
963
IDentity Applet v3.4/eIDAS Security Target
Page 62 of 191
• T.Abuse-Func
964
• T.Eavesdropping
965
• T.Forgery
966
• T.Information_Leakage
967
• T.Malfunction
968
• T.Phys-Tamper
969
• T.Skimming
970
• T.Tracing
971
3.2.4. THREATS FROM SSCDPP
972
The current ST also includes all threats of [14]. These items are applicable if the eSign
973
application is operational.
974
• T.DTBS_Forgery
975
• T.Hack_Phys
976
• T.SCD_Derive
977
• T.SCD_Divulge
978
• T.Sig_Forgery
979
• T.SigF_Misuse
980
• T.SVD_Forgery
981
Due to identical definitions and names, their definitions are not repeated here.
982
3.3.Organizational Security Policies
983
The TOE shall comply with the following Organizational Security Policies (OSP) as security
984
rules, procedures, practices, or guidelines imposed by an organization upon its operations (see
985
[1], sec. 3.2). This ST includes the OSPs from the claimed protection profiles as listed below
986
and provides no further OSPs.
987
3.3.1. OSPS FROM EAC1PP
988
This ST includes the following OSPs from [5], if the TOE contains EAC1-protected data.
989
IDentity Applet v3.4/eIDAS Security Target
Page 63 of 191
• P.Personalisation
990
• P.Sensitive_Data
991
Due to identical definitions and names, they are not repeated here. For the remaining OSPs
992
from [5], see the next sections.
993
3.3.2. OSPS FROM EAC2PP
994
This ST includes the following OSPs from [6]. They mainly concern EAC2-protected data.
995
• P.EAC2_Terminal
996
• P.RestrictedIdentity
997
• P.Terminal_PKI
998
Due to identical definitions and names, their definitions are not repeated here. For the
999
remaining OSPs from [6], cf. the next section.
1000
3.3.3. OSPS FROM PACEPP
1001
This ST includes the following OSPs from [13], since both [5] and [6] claim [13]. We list each
1002
OSP only once here. Due to identical definitions and names, their definitions are not repeated
1003
here as well.
1004
• P.Card_PKI
1005
• P.Manufact
1006
• P.Pre-Operational
1007
• P.Trustworthy_PKI
1008
3.3.4. OSPS FROM SSCDPP
1009
The current ST also includes all OSPs of [14]. They are applicable, if the eSign application is
1010
included.
1011
• P.CSP_QCert
1012
• P.QSign
1013
• P.Sig_Non-Repud
1014
• P.Sigy_SSCD
1015
Due to identical definitions and names, their definitions are not repeated here.
1016
IDentity Applet v3.4/eIDAS Security Target
Page 64 of 191
3.3.5. ADDITIONAL OSPS
1017
The next OSP addresses the need of a policy for the document manufacturer. It is formulated
1018
akin to [10].
1019
P.Lim_Block_Loader
1020
The composite manufacturer uses the Loader for loading of Security IC Embedded Software,
1021
user data of the Composite Product or IC Dedicated Support Software in charge of the IC
1022
Manufacturer. She limits the capability and blocks the availability of the Loader in order to
1023
protect stored data from disclosure and manipulation.
1024
The ST includes the following OSP from [13], since both [5] and [6] claim [13], but the
1025
P.Terminal was extended because the Active Authentication protocol. The extension is
1026
marked with bold and the other part of the OSP remained unchanged.
1027
P.Terminal
1028
The PACE terminal shall operate their terminals as follows:
1029
1. The related terminals (PACE terminal) shall be used by terminal operators and by travel
1030
document holders as defined in [9].
1031
2. They shall implement the terminal parts of the PACE protocol [9], of the Passive
1032
Authentication [9] and use them in this order3
. The PACE terminal shall use randomly and
1033
(almost) uniformly selected nonce, if required by the protocols (for generating ephemeral
1034
keys for Diffie-Hellmann).
1035
Furthermore the PACE terminal and EAC1 terminal shall implement the terminal parts
1036
of the Active Authentication protocol as described in [9].
1037
3. The related terminals need not to use any own credentials.
1038
4. They shall also store the Country Signing Public Key and the Document Signer Public Key
1039
(in form of CCSCA and CDS) in order to enable and to perform Passive
1040
Authentication(determination of the authenticity of data groups stored in the travel
1041
document, [9]).
1042
5. The related terminals and their environment shall ensure confidentiality and integrity of
1043
respective data handled by them (e.g. confidentiality of PACE passwords, integrity of PKI
1044
certificates, etc.), where it is necessary for a secure operation of the TOE according to the
1045
[13].
1046
3 This order is commensurate with [9].
IDentity Applet v3.4/eIDAS Security Target
Page 65 of 191
Justification: The modification of P.Terminal is extended the original OSP in order to support
1047
the Active Authentication protocol. Taking into consideration the extension is not modify the
1048
original OSP, but added further requirements, this extension is not hurt the strict conformance
1049
as determined in PP Claim.
1050
3.4.Assumptions
1051
The assumptions describe the security aspects of the environment in which the TOE will be
1052
used or is intended to be used. This ST includes the assumptions from the claimed protection
1053
profiles as listed below and defines no further assumptions.
1054
3.4.1. ASSUMPTIONS FROM EAC1PP
1055
This ST includes the following assumptions from the [5]. They concern EAC1-protected data.
1056
• A.Auth_PKI
1057
• A.Insp_Sys
1058
Due to identical definitions and names, their definitions are not repeated here. For the
1059
remaining assumptions from [5], see the next sections.
1060
3.4.2. ASSUMPTIONS FROM EAC2PP
1061
[6] only includes the assumption from [13] (see below) and defines no other assumption.
1062
3.4.3. ASSUMPTIONS FROM PACEPP
1063
This ST includes the following assumptions from [13], since both [5] and [6] claim [13].
1064
• A.Passive_Auth
1065
Due to an identical definition and name, its definition is not repeated here as well.
1066
3.4.4. ASSUMPTIONS FROM SSCDPP
1067
The current ST also includes all assumptions of [14]. These items are applicable, if the eSign
1068
application is included.
1069
• A.CGA
1070
• A.SCA
1071
Due to identical definitions and names their definitions are not repeated here.
1072
IDentity Applet v3.4/eIDAS Security Target
Page 66 of 191
4. SECURITY OBJECTIVES
1073
This chapter describes the security objectives for the TOE and for the TOE environment. The
1074
security objectives for the TOE environment are separated into security objectives for the
1075
development, and production environment and security objectives for the operational
1076
environment.
1077
4.1.Security Objectives for the TOE
1078
This section describes the security objectives for the TOE, addressing the aspects of identified
1079
threats to be countered by the TOE, and organizational security policies to be met by the TOE.
1080
OT.Non_Interfere
1081
No interference of Access Control Mechanisms
1082
The various implemented access control mechanisms must be consistent. Their
1083
implementation must not allow to circumvent an access control mechanism by exploiting an
1084
unintended implementational interference of one access control mechanism with another one.
1085
OT.Chip_Auth_Proof_AA
1086
Proof of the electronic documents authenticity with Active Authentication
1087
The TOE must support the Terminal to verify the identity and authenticity of the electronic
1088
document as issued by the identified issuing State or Organisation by means of the Active
1089
Authentication protocol as defined in [7], [9]. The authenticity proof provided by electronic
1090
document shall be protected against attacks with high attack potential.
1091
4.1.1. SECURITY OBJECTIVES FOR THE TOE FROM EAC1PP
1092
This ST includes the following additional security objectives for the TOE from [5] that are not
1093
included in [13]. They concern EAC1-protected data.
1094
• OT.Chip_Auth_Proof
1095
• OT.Sens_Data_Conf
1096
Due to identical definitions and names, their definitions are not repeated here. For the
1097
remaining security objectives from [5], see the next sections.
1098
In addition, the following security objective is defined here:
1099
IDentity Applet v3.4/eIDAS Security Target
Page 67 of 191
OT.Chip_Auth_Proof_PACE_CAM
1100
Proof of the electronic document’s chip authenticity
1101
The TOE must support the terminals to verify the identity and authenticity of the Electronic
1102
document’s chip as issued by the identified issuing State or Organization by means of the
1103
PACE-Chip Authentication Mapping (PACE-CAM) as defined in [9]. The authenticity proof
1104
provided by electronic document’s chip shall be protected against attacks with high attack
1105
potential.
1106
Application note 8 (from ST author)
1107
PACE-CAM enables much faster authentication of the of the chip than running PACE with
1108
General Mapping (according to [16]) followed by CA1. OT.Chip_Auth_Proof_PACE_CAM is
1109
intended to require the Chip to merely provide an additional means – with the same level of
1110
security – of authentication.
1111
4.1.2. SECURITY OBJECTIVES FOR THE TOE EAC2PP
1112
This ST includes the following additional security objectives for the TOE from [6] that are not
1113
included in [13]. They concern EAC2-protected data.
1114
• OT.AC_Pers_EAC2
1115
• OT.CA2
1116
• OT.RI_EAC2
1117
• OT.Sens_Data_EAC2
1118
Due to identical definitions and names, their definitions are not repeated here. For the
1119
remaining security objectives from [6], see the next sections.
1120
4.1.3. SECURITY OBJECTIVES FOR THE TOE PACEPP
1121
Both [5] and [6] claim [13]. Therefore, the following security objectives are included as well.
1122
We list them only once here.
1123
IDentity Applet v3.4/eIDAS Security Target
Page 68 of 191
• OT.AC_Pers
1124
• OT.Data_Authenticity
1125
• OT.Data_Confidentiality
1126
• OT.Data_Integrity
1127
• OT.Identification
1128
• OT.Prot_Abuse-Func
1129
• OT.Prot_Inf_Leak
1130
• OT.Prot_Malfunction
1131
• OT.Prot_Phys-Tamper
1132
• OT.Tracing
1133
Due to identical definitions and names, their definitions are not repeated here.
1134
4.1.4. SECURITY OBJECTIVES FOR THE TOE SSCDPP
1135
The current ST also includes all security objectives for the TOE of [14]. These items are
1136
applicable, if an eSign application is included.
1137
• OT.DTBS_Integrity_TOE
1138
• OT.EMSEC_Design
1139
• OT.Lifecycle_Security
1140
• OT.SCD_Secrecy
1141
• OT.SCD_SVD_Corresp
1142
• OT.SCD_Unique
1143
• OT.SCD/SVD_Gen
1144
• OT.Sig_Secure
1145
• OT.Sigy_SigF
1146
• OT.Tamper_ID
1147
• OT.Tamper_Resistance
1148
Due to identical definitions and names, their definitions are not repeated here as well. Note
1149
that all are formally included here, but careful analysis reveals that OT.SCD_Secrecy,
1150
OT.DTBS_Integrity_TOE, OT.EMSEC_Design, OT.Tamper_ID, and OT.Tamper_Resistance
1151
are actually fully or partly covered by security objectives included from [13].
1152
IDentity Applet v3.4/eIDAS Security Target
Page 69 of 191
4.1.5. ADDITIONAL SECURITY OBJECTIVES FOR THE TOE
1153
A loader is a part of the chip operating system that allows to load data, i.e. the file-
1154
system/applet containing (sensitive) user data, TSF data etc. into the Flash memory after
1155
delivery of the smartcard to the document manufacturer.
1156
The following objective for the TOE addresses limiting the availability of the loader, and is
1157
formulated akin to [10].
1158
OT.Cap_Avail_Loader
1159
The TSF provides limited capability of the Loader functionality of the TOE embedded software
1160
and irreversible termination of the Loader in order to protect user data from disclosure and
1161
manipulation.
1162
4.2.Security Objectives for the Operational Environment
1163
4.2.1. SECURITY OBJECTIVES FROM EAC1PP
1164
This ST includes the following security objectives for the TOE from the [5]. They mainly concern
1165
EAC1-protected data.
1166
• OE.Auth_Key_Travel_Document
1167
• OE.Authoriz_Sens_Data
1168
• OE.Exam_Travel_Document
1169
• OE.Ext_Insp_Systems
1170
• OE.Prot_Logical_Travel_Document
1171
Due to identical definitions and names, their definitions are not repeated here. For the
1172
remaining ones, see the next sections
1173
4.2.2. SECURITY OBJECTIVES FROM EAC2PP
1174
This ST includes the following security objectives for the TOE from the [6]. They mainly concern
1175
EAC2-protected data.
1176
IDentity Applet v3.4/eIDAS Security Target
Page 70 of 191
• OE.Chip_Auth_Key
1177
• OE.RestrictedIdentity
1178
• OE.Terminal_Authentication
1179
Due to identical definitions and names, their definitions are not repeated here. For the
1180
remaining ones, see the next section.
1181
4.2.3. SECURITY OBJECTIVES FROM PACEPP
1182
Both [5] and [6] claim [13]. Therefore, the following security objectives on the operational
1183
environment are included as well. We repeat them only once here.
1184
• OE.Legislative_Compliance
1185
• OE.Passive_Auth_Sign
1186
• OE.Personalisation
1187
• OE.Terminal
1188
• OE.Travel_Document_Holder
1189
Due to identical definitions and names, they are not repeated here as well.
1190
4.2.4. SECURITY OBJECTIVES FROM SSCDPP
1191
The current ST also includes all security objectives for the TOE of [14]. These items are
1192
applicable, if an eSign application is included.
1193
• OE.CGA_QCert
1194
• OE.DTBS_Intend
1195
• OE.DTBS_Protect
1196
• OE.HID_VAD
1197
• OE.Signatory
1198
• OE.SSCD_Prov_Service
1199
• OE.SVD_Auth
1200
Due to identical definitions and names, their definitions are not repeated here.
1201
4.2.5. ADDITIONAL SECURITY OBJECTIVES FOR THE ENVIRONMENT
1202
The following objective on the environment is defined akin to the objective from [10].
1203
IDentity Applet v3.4/eIDAS Security Target
Page 71 of 191
OE.Lim_Block_Loader
1204
The manufacturer will protect the Loader functionality against misuse, limit the capability of the
1205
Loader and terminate irreversibly the Loader after intended usage of the Loader.
1206
Justification: This security objective directly addresses the threat OT.Non_Interfere. This
1207
threat concerns the potential interference of different access control mechanisms, which could
1208
occur as a result of combining different applications on a smartcard. Such combination does
1209
not occur in one of the claimed PPs. Hence, this security objective for the environment does –
1210
neither mitigate a threat of one of the claimed PPs that was addressed by security objectives
1211
of that PP,– nor does it fulfill any organizational security policy of one of the claimed PPs that
1212
was meant to be addressed by security objectives of the TOE of that PP.
1213
The following objectives on the environment are introduced because of the Active
1214
Authentication
1215
• OE.Auth_Key_AA
1216
Electronic document Active Authentication key pair
1217
The issuing State or Organisation has to establish the necessary infrastructure in order to (i)
1218
generate the electronic document’s Active Authentication Key Pair, (ii) sign (Passive
1219
Authentication) and store the Active Authentication Public Key in the Active Authentication
1220
Public Key data in EF.DG15 and (iii) support Terminals of receiving States or Organisations to
1221
verify the authenticity of the electronic document used for genuine electronic document.
1222
• OE.Exam_Electronic_Document_AA
1223
Examination of the genuineness of the electronic document with Active Authentication
1224
The Terminal of the receiving State or Organisation perform the Active Authentication protocol
1225
according to [7] and [9] in order to verify the genuineness of the presented electronic document.
1226
4.3.Security Objective Rationale
1227
Table 9 provides an overview of the security objectives' coverage. According to [1], the tracing
1228
between security objectives and the security problem definition must ensure that 1) each
1229
security objective traces to at least one threat, OSP and assumption, 2) each threat, OSP and
1230
assumption has at least one security objective tracing to it, and 3) the tracing is correct (i.e.
1231
the main point being that security objectives for the TOE do not trace back to assumptions).
1232
IDentity Applet v3.4/eIDAS Security Target
Page 72 of 191
This is illustrated in the following way:
1233
1. can be inferred for security objectives from claimed PPs by looking up the security
1234
objective rationale of the claimed PPs and for newly introduced security objectives
1235
because of [20] or the newly introduced functions (i.e. OE.Lim_Block_Loader,
1236
OT.Cap_Avail_Loader, OT.Chip_Auth_Proof_AA, OE.Auth_Key_AA,
1237
OE.Exam_Electronic_Document_AA and OT.Chip_Auth_Proof_PACE_CAM) by
1238
checking the columns of Table 9 ,
1239
2. can be inferred for threats, OSPs and assumptions from the claimed PPs by looking up
1240
the security objective rationale of the claimed PPs and for newly introduced or
1241
extended4
threats, OSPs and assumptions by checking the rows of Table 9 , and
1242
3. simply by checking the columns of Table 9 and the security objective rationales from
1243
the claimed PPs.
1244
OT.Chip_Auth_Proof_AA
OT.AC_Pers
OT.AC_Pers_EAC2
OT.Cap_Avail_Loader
OT.Chip_Auth_Proof_PACE_CAM
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Non_Interfere
OT.Sens_Data_Conf
[5]
OT.Sens_Data_EAC2
OE.Auth_Key_AA
OE.Exam_Electronic_Document_AA
OE.Lim_Block_Loader
T.InconsistentSec - X X X - X X X X X X - - X
T.Interfere - - - - - - - - X - - - -
T.Counterfeit X - - - X - - - - - - X X
P.Terminal - - - - - - - - - - - - X
P.Lim_Block_Loader - - - X - - - - X - - - - X
Table 9 Security Objective Rationale
1245
The threat T.InconsistentSec addresses attacks on the confidentiality and the integrity of User
1246
Data stored on the TOE, facilitated by the data not being protected as intended.
1247
OT.AC_Pers and OT.AC_Pers_EAC2 define the restriction on writing or modifying data;
1248
OT.Data_Authenticity, OT.Data_Confidentiality, OT.Data_Integrity, OT.Sens_Data_Conf
1249
(from [5]), and OT.Sens_Data_EAC2 require the security of stored user data as well as user
1250
data that are transferred between the TOE and a terminal to be secure w.r.t. authenticity,
1251
integrity and confidentiality.
1252
4 Only the impact of the modification is marked in the table.
IDentity Applet v3.4/eIDAS Security Target
Page 73 of 191
OT.Non_Interfere requires the TOE's access control mechanisms to be implemented
1253
consistently and their implementations not to allow to circumvent an access control mechanism
1254
by exploiting an unintended implementational interference of one access control mechanism
1255
with another one. OT.Cap_Avail_Loader requires the TOE to provide limited capability of the
1256
loader functionality and irreversible termination of the loader in order to protect stored user
1257
data.
1258
OE.Lim_Block_Loader requires the manufacturer to protect the loader functionality against
1259
misuse, limit the capability of the loader, and terminate irreversibly the loader after intended
1260
usage of the loader.
1261
The combination of these security objectives cover the threat posed by T.InconsistentSec.
1262
The threat T.Interfere addresses the attack on user data by exploiting the unintended
1263
interference of security protocols. This is directly countered by OT.Non_Interfere, requiring the
1264
TOE's access control mechanisms to be implemented consistently, and their implementations
1265
to not allow to circumvent an access control mechanism by exploiting an unintended
1266
implementational interference of one access control mechanism with another one.
1267
The threat T.Counterfeit (from [5]) is countered in [5] by OT.Chip_Auth_Proof. That security
1268
objectives addresses the implementation of the Chip Authentication Protocol Version 1 (CA1)
1269
and thus counters the thread of counterfeiting an electronic document containing an ePassport
1270
application. Here, the additional security objective for the TOE
1271
OT.Chip_Auth_Proof_PACE_CAM is introduced. It ensures that the chip in addition to CA1
1272
also supports the PACE-Chip Authentication Mapping (PACE-CAM) protocol, which supports
1273
the same security functionality as CA1 does. PACE-CAM enables much faster authentication
1274
of the of the chip than running PACE with general mapping followed by CA1.
1275
Furthermore T.Counterfeit is countered by OT.Chip_Auth_Proof_AA, OE.Auth_Key_AA and
1276
OE.Exam_Electronic_Document_AA. These security objectives addresses the implementation
1277
of the Active Authentication and thus counters the thread of counterfeiting an electronic
1278
document containing an ePassport application. It ensures that the chip supports the Active
1279
Authentication protocol, which supports to verify that the electronic document is genuine
1280
(similar as Chip Authentication without secure messaging).
1281
The OSP P.Lim_Block_Loader addresses limiting the capability and blocking the availability
1282
of the Loader in order to protect stored data from disclosure and manipulation. This is
1283
addressed by OT.Cap_Avail_Loader, which requires the TOE to provide a limited capability of
1284
IDentity Applet v3.4/eIDAS Security Target
Page 74 of 191
the loader functionality and irreversible termination of the loader in order to protect stored user
1285
data; by OT.Non_Interfere, which requires the TOE's access control mechanisms to be
1286
implemented consistently and their implementations not to allow to circumvent an access
1287
control mechanism by exploiting an unintended implementational interference of one access
1288
control mechanism with another one; and by OE.Lim_Block_Loader, which requires the
1289
manufacturer to protect the Loader functionality against misuse, limit the capability of the
1290
Loader and terminate irreversibly the Loader after intended usage of the Loader.
1291
The OSP P.Terminal is extended to support the Active Authentication protocol. With this
1292
extension the P.Terminal countered by the security objective
1293
OE.Exam_Electronic_Document_AA. The OE.Exam_Electronic_Document_AA enforces
1294
the terminal parts of the Active Authentication.
1295
IDentity Applet v3.4/eIDAS Security Target
Page 75 of 191
5. EXTENDED COMPONTENTS DEFINITION
1296
This ST includes all extended components from the claimed PPs. This includes
1297
• FAU_SAS.1 from the family FAU_SAS from [13]
1298
• FCS_RND.1 from the family FCS_RND from [13]
1299
• FMT_LIM.1 and FMT_LIM.2 from the family FMT_LIM [13]
1300
• FPT_EMS.1 from the family FPT_EMS from [13]
1301
• FIA_API.1 from the family FIA_API from [6]
1302
For precise definitions we refer to [13] and [6].
1303
IDentity Applet v3.4/eIDAS Security Target
Page 76 of 191
6. SECURITY REQUIREMENTS
1304
This part defines detailed security requirements that shall be satisfied by the TOE. The
1305
statement of TOE security requirements shall define the functional and assurance security
1306
requirements that the TOE must satisfy in order to meet the security objectives for the TOE.
1307
Common Criteria allows several operations to be performed on security requirements on the
1308
component level: refinement, selection, assignment and iteration, cf. sec. 8.1 of [1]. Each of
1309
these operations is used in this ST.
1310
The refinement operation is used to add detail to a requirement, and thus further restricts a
1311
requirement. Refinements of security requirements are denoted in such a way that added
1312
words are in bold text and removed words are crossed out.
1313
The selection operation is used to select one or more options provided by CC in stating a
1314
requirement. Selections that have been made by the PP author are denoted as underlined text.
1315
Selections to be filled in by the ST author appear in square brackets with an indication that a
1316
selection has to be made, [selection:], and are italicized. Selections filled in by the ST author
1317
are denoted as double underlined text and a foot note where the selection choices from the
1318
PP are listed.
1319
The assignment operation is used to assign a specific value to an unspecified parameter,
1320
such as the length of a password. Assignments that have been made by the PP author are
1321
denoted as underlined text. Assignments to be filled in by the ST author appear in square
1322
brackets with an indication that an assignment has to be made [assignment:], and are italicized.
1323
In some cases the assignment made by the PP authors defines a selection to be performed
1324
by the ST author. Thus this text is underlined and italicized like this. Assignments filled in by
1325
the ST author are denoted as double underlined text.
1326
The iteration operation is used when a component is repeated with varying operations.
1327
Iteration is denoted by showing a slash “/”, and the iteration indicator after the component
1328
identifier. For the sake of better readability, the iteration operation may also be applied to a
1329
non-repeated single component in order to indicate that such component belongs to a certain
1330
functional cluster. In such a case, the iteration operation is applied to only one single
1331
component.
1332
IDentity Applet v3.4/eIDAS Security Target
Page 77 of 191
In order to distinguish between SFRs defined here and SFRs that are taken over from PPs to
1333
which this ST claims strict conformance, the latter are iterated resp. renamed in the following
1334
way:
1335
/EAC1PP or /XXX_EAC1PP [5],
1336
/EAC2PP or /XXX_EAC2PP for [6],
1337
and /SSCDPP or /XXX_SSCDPP for [14].
1338
6.1.Security Functional Requirements
1339
The statements of security requirements must be internally consistent. As several different PPs
1340
with similar SFRs are claimed, great care must be taken to ensure that these several iterated
1341
SFRs do not lead to inconsistency.
1342
Despite this ST claims strict conformance to [13], SFRs can be safely ignored in this ST as
1343
long as [5] and [6] are taken into account.
1344
One must remember that each of these iterated SFRs mostly concerns different (groups of)
1345
user and TSF data for each protocol (i.e. PACE, EAC1 and EAC2). Three cases are
1346
distinguished:
1347
1. The SFRs apply to different data that are accessible by executing different protocols.
1348
Hence, they are completely separate. An example is FCS_CKM.1/DH_PACE from [5]
1349
and [6]. No remark is added in such case in the text below.
1350
2. The SFRs are equivalent. Then we list them all for the sake of completeness. Hence,
1351
it suffices to consider only one iteration. For such SFRs, we explicitly give a remark. An
1352
example is FIA_AFL.1/PACE from [5] and [6].
1353
3. The SFRs do not apply to different data or protocols, but are also not completely
1354
equivalent. Then these multiple SFRs are refined in such a way, that one common
1355
component is reached that subsumes all iterations that stem from the inclusions of the
1356
claimed PPs. An example is FDP_ACF.1, which is combined here from [5] and [6].
1357
Such a case is also explicitly mentioned in the text.
1358
Thus internal consistency is not violated.
1359
IDentity Applet v3.4/eIDAS Security Target
Page 78 of 191
6.1.1. Class FCS
1360
The following SFRs are imported due to claiming [6]. They concern cryptographic support for
1361
applications that contain EAC2-protected data groups.
1362
• FCS_CKM.1/DH_PACE_EAC2PP
1363
• FCS_COP.1/SHA_EAC2PP
1364
• FCS_COP.1/SIG_VER_EAC2PP
1365
• FCS_COP.1/PACE_ENC_EAC2PP
1366
• FCS_COP.1/PACE_MAC_EAC2PP
1367
• FCS_CKM.4/EAC2PP
1368
• FCS_RND.1/EAC2PP
1369
FCS_CKM.1/DH_PACE_EAC2PP
1370
Cryptographic Key Generation – Diffie-Hellman for PACE and CA2 Session Keys
1371
Hierarchical to: No other components
1372
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
1373
FCS_COP.1 Cryptographic operation] not fulfilled, but
1374
justified:
1375
A Diffie-Hellman key agreement is used in order to
1376
have no key distribution, therefore FCS_CKM.2 makes
1377
no sense in this case.
1378
FCS_CKM.4 Cryptographic key destruction fulfilled by
1379
FCS_CKM.4/EAC2PP
1380
FCS_CKM.1.1/DH_PACE_EAC2PP
1381
The TSF shall generate cryptographic keys in accordance with a specified cryptographic
1382
key generation algorithm Diffie-Hellman-Protocol compliant to [27] and ECDH compliant
1383
to [26]]56
and specified cryptographic key sizes AES 128, 192, 2567
that meet the following:
1384
[17]8
1385
9. Application note (taken from [6], application note 10)
1386
5 [assignment: cryptographic key generation algorithm]
6 [selection: Diffie-Hellman-Protocol compliant to [27] , ECDH compliant to [26]]
7 [assignment: cryptographic key sizes]
8
[assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 79 of 191
In the above and all subsequent related SFRs, the reference w.r.t. the PACE protocol is
1387
changed to [17], whereas [13] references [7]. The difference between the two definitions is that
1388
[17] defines additional optional parameters for the command MSE:Set AT. This optional
1389
parameters (e.g. the CHAT) are technically required, since here Terminal Authentication 2
1390
(TA2) can be executed right after PACE (see FIA_UID.1/EAC2_Terminal_EAC2PP). As [7]
1391
does not consider TA2, no such definition is given there. These additional parameters are
1392
optional and not used during PACE itself (only afterwards). If PACE is run without TA2
1393
afterwards, access to data on the chip is given as specified by [13]. If TA2 is run afterwards,
1394
access to data on the chip can be further restricted w.r.t. to the authorization level of the
1395
terminal. Therefore, this change of references does not violate strict conformance to [13]. We
1396
treat this change of references as a refinement operation, and thus mark the changed
1397
reference using bold text.
1398
10. Application note (redefined by ST author, taken from [6], application note 11)
1399
Applied.
1400
11. Application note (taken from [6], application note 12)
1401
[13] considers Diffie-Hellman key generation only for PACE. Since the TOE is required to
1402
implement Chip Authentication 2 (cf. FIA_API.1/CA_EAC2PP), here
1403
FCS_CKM.1/DH_PACE_EAC2PP applies for CA2 as well.
1404
FCS_COP.1/SHA_EAC2PP
1405
Cryptographic operation – Hash for key derivation
1406
Hierarchical to: No other components
1407
Dependencies: [FDP_ITC.1 Import of user data without security
1408
attributes, or FDP_ITC.2 Import of user data with
1409
security attributes, or FCS_CKM.1 Cryptographic key
1410
generation] not fulfilled, but justified:
1411
A hash function does not use any cryptographic key;
1412
hence, neither a respective key import nor key
1413
generation can be expected here.
1414
FCS_CKM.4 Cryptographic key destruction not fulfilled,
1415
but justified:
1416
A hash function does not use any cryptographic key;
1417
hence, a respective key destruction cannot be
1418
expected here.
1419
FCS_COP.1.1/SHA_EAC2PP
1420
IDentity Applet v3.4/eIDAS Security Target
Page 80 of 191
The TSF shall perform hashing9
in accordance with a specified cryptographic algorithm
1421
SHA-1, SHA-224, SHA-256, SHA-384, SHA-51210
and cryptographic key sizes none11
that
1422
meet the following: [28]12
.
1423
12. Application note (taken from [6], application note 13)
1424
For compressing (hashing) an ephemeral public key for DH (TA2 and CA2), the hash function
1425
SHA-1 shall be used ([18]). The TOE shall implement as hash functions either SHA-1 or SHA-
1426
224 or SHA-256 for Terminal Authentication 2, cf. [18]. Within the normative Appendix of [18]
1427
‘Key Derivation Function’, it is stated that the hash function SHA-1 shall be used for deriving
1428
128-bit AES keys, whereas SHA-256 shall be used for deriving 192-bit and 256-bit AES keys.
1429
FCS_COP.1/SIG_VER_EAC2PP
1430
Cryptographic operation – Signature verification
1431
Hierarchical to: No other components
1432
Dependencies: [FDP_ITC.1 Import of user data without security
1433
attributes, or FDP_ITC.2 Import of user data with
1434
security attributes, or FCS_CKM.1 Cryptographic key
1435
generation] not fulfilled, but justified:
1436
The root key PKCVCA (initialization data) used for
1437
verifying the DV Certificate is stored in the TOE during
1438
its personalization in the card issuing life cycle phase13
.
1439
Since importing the respective certificates (Terminal
1440
Certificate, DV Certificate) does not require any special
1441
security measures except those required by the current
1442
SFR (cf. FMT_MTD.3/EAC2PP below), the current ST
1443
does not contain any dedicated requirement like
1444
FDP_ITC.2 for the import function.
1445
FCS_CKM.4 Cryptographic key destruction not fulfilled,
1446
but justified:
1447
Cryptographic keys used for the purpose of the current
1448
SFR (PKPCD, PKDV, PKCVCA) are public keys; they do
1449
not represent any secret, and hence need not to be
1450
destroyed.
1451
9
[assignment: list of cryptographic operations]
10 [assignment: cryptographic algorithm]
11
[assignment: cryptographic key sizes]
12
[assignment: list of standards]
13
as already mentioned, operational use of the TOE is explicitly in focus of the ST and in the [20]
IDentity Applet v3.4/eIDAS Security Target
Page 81 of 191
FCS_COP.1.1/SIG_VER_EAC2PP
1452
The TSF shall perform digital signature verification14
in accordance with a specified
1453
cryptographic algorithm RSA, RSA CRT and ECDSA15
and cryptographic key sizes RSA:
1454
RSA, RSA CRT: 1024, 1280, 1536, 1984, 2048, 3072, 4096 and from 2000 bit to 4096 bit
1455
in one bit steps; ECDSA: 160, 192, 224, 256, 320, 384, 521 bit16
that meet the following:
1456
[24], [29]17
.
1457
13. Application note (taken from [6], application note 14)
1458
This SFR is concerned with Terminal Authentication 2, cf. [17].
1459
14. Application note (from ST author)
1460
The TOE based on the Platform functionalities supports RSA and RSA-CRT digital signature
1461
algorithms and cryptographic key sizes 512 bits up to 4096 bits with equal security measures.
1462
However, to fend off attackers with high attack potential an adequate key length must be used.
1463
FCS_COP.1/PACE_ENC_EAC2PP
1464
Cryptographic operation – Encryption/Decryption AES
1465
Hierarchical to: No other components
1466
Dependencies: FDP_ITC.1 Import of user data without security
1467
attributes, or FDP_ITC.2 Import of user data with
1468
security attributes, or FCS_CKM.1 Cryptographic key
1469
generation] fulfilled by
1470
FCS_CKM.1/DH_PACE_EAC2PP
1471
FCS_CKM.4 Cryptographic key destruction fulfilled by
1472
FCS_CKM.4/EAC2PP
1473
FCS_COP.1.1/PACE_ENC_EAC2PP
1474
14 [assignment: list of cryptographic operations]
15 [assignment: cryptographic algorithm]
16 [assignment: cryptographic key sizes]
17 [assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 82 of 191
The TSF shall perform secure messaging – encryption and decryption18
in accordance
1475
with a specified cryptographic algorithm AES in CBC mode19
and cryptographic key sizes
1476
128, 192, 256 bit20
that meet the following: [18]21
1477
15. Application note (taken from [6], application note 15)
1478
This SFR requires the TOE to implement the cryptographic primitive AES for secure messaging
1479
with encryption of transmitted data. The related session keys are agreed between the TOE
1480
and the terminal as part of either the PACE protocol (PACE-KEnc) or Chip Authentication 2 (CA-
1481
KEnc) according to FCS_CKM.1/DH_PACE_EAC2PP. Note that in accordance with [18], 3DES
1482
could be used in CBC mode for secure messaging. Due to the fact that 3DES is not
1483
recommended any more (cf. [17]), 3DES in any mode is no longer applicable here.
1484
16. Application note (taken from [6], application note 16)
1485
Refinement of FCS_COP.1.1/PACE_ENC_EAC2PP, since here PACE must adhere to [18].
1486
All references (both the one in [13] and [18]) itself reference [12] for secure messaging. [18]
1487
however further restricts the available choice of key-sizes and algorithms. Hence, [18] is fully
1488
(backward) compatible to the reference given in [13].
1489
FCS_COP.1/PACE_MAC_EAC2PP
1490
Cryptographic operation – MAC
1491
Hierarchical to: No other components
1492
Dependencies: FDP_ITC.1 Import of user data without security
1493
attributes, or FDP_ITC.2 Import of user data with
1494
security attributes, or FCS_CKM.1 Cryptographic key
1495
generation] fulfilled by
1496
FCS_CKM.1/DH_PACE_EAC2PP
1497
FCS_CKM.4 Cryptographic key destruction fulfilled by
1498
FCS_CKM.4/EAC2PP
1499
FCS_COP.1.1/PACE_MAC_EAC2PP
1500
18 [assignment: list of cryptographic operations]
19
[selection: cryptographic algorithm]
20 [selection: 128, 192, 256 bit ]
21
[assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 83 of 191
The TSF shall perform secure messaging – message authentication code22
in accordance
1501
with a specified cryptographic algorithm CMAC23
and cryptographic key sizes 128, 192,
1502
256 bit24
that meet the following: [18]25
1503
17. Application note (redefined by ST author, taken from [6], application note 17)
1504
See 16. Application note (taken from [6], application note 16).
1505
18. Application note (taken from [6], application note 18)
1506
This SFR removes 3DES and restricts to CMAC compared to the SFR of [13] by selection.
1507
Hence, a minimum key-size of 128 bit is required.
1508
FCS_CKM.4/EAC2PP
1509
Cryptographic key destruction – Session keys
1510
Hierarchical to: No other components
1511
Dependencies: FDP_ITC.1 Import of user data without security
1512
attributes, or FDP_ITC.2 Import of user data with
1513
security attributes, or FCS_CKM.1 Cryptographic key
1514
generation] fulfilled by
1515
FCS_CKM.1/DH_PACE_EAC2PP and
1516
FCS_CKM.1/CA_EAC1PP
1517
FCS_CKM.4.1/EAC2PP
1518
The TSF shall destroy cryptographic keys in accordance with a specified cryptographic
1519
key destruction method physically overwriting the keys in a randomized manner26
that
1520
meets the following: provided by the underlying certified Platform27
.
1521
19. Application note
1522
In [13] concerning this component requires the destruction of PACE session keys after
1523
detection of an error in a received command by verification of the MAC. While the definition of
1524
FCS_CKM.4/EAC2PP remains unaltered, here this component also requires the destruction
1525
of sessions keys after a successful run of Chip Authentication 2. The TOE shall destroy the
1526
CA2 session keys after detection of an error in a received command by verification of the MAC.
1527
The TOE shall clear the memory area of any session keys before starting the communication
1528
with the terminal in a new after-reset-session as required by FDP_RIP.1/EAC2PP.
1529
22
[assignment: list of cryptographic operations]
23
[selection: cryptographic algorithm]
24 [selection: 112 128, 192, 256 bit]
25
[assignment: list of standards]
26 [assignment: cryptographic key destruction method]
27 [assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 84 of 191
FCS_RND.1/EAC2PP
1530
Quality metric for random numbers
1531
Hierarchical to: No other components
1532
Dependencies: No dependencies.
1533
FCS_RND.1.1/EAC2PP
1534
The TSF shall provide a mechanism to generate random numbers that meet DRG.328
.
1535
20. Application note
1536
In [13] concerning this component requires the TOE to generate random numbers (random
1537
nonce) for PACE. While the definition of FCS_RND.1/EAC2PP remains unaltered, here this
1538
component requires the TOE to generate random numbers (random nonce) for all
1539
authentication protocols (i.e. PACE, CA2), as required by FIA_UAU.4/PACE_EAC2PP.
1540
The following SFRs are imported due to claiming [5]. They concern cryptographic support for
1541
applications that contain EAC1-protected data groups.
1542
• FCS_CKM.1/DH_PACE_EAC1PP
1543
• FCS_CKM.4/EAC1PP
1544
(equivalent to FCS_CKM.4/EAC2PP, but listed here for the sake of completeness)
1545
• FCS_COP.1/PACE_ENC_EAC1PP
1546
• FCS_COP.1/PACE_MAC_EAC1PP
1547
21. Application note (redefined by ST author, taken from[20], application note 9)
1548
Applied.
1549
• FCS_RND.1/EAC1PP
1550
(equivalent to FCS_RND.1/EAC2PP, but listed here for the sake of completeness)
1551
• FCS_CKM.1/CA_EAC1PP
1552
• FCS_COP.1/CA_ENC_EAC1PP
1553
• FCS_COP.1/SIG_VER_EAC1PP
1554
• FCS_COP.1/CA_MAC_EAC1PP
1555
28 [assignment: a defined quality metric]
IDentity Applet v3.4/eIDAS Security Target
Page 85 of 191
FCS_CKM.1/DH_PACE_EAC1PP
1556
Cryptographic key generation – Diffie-Hellman for PACE session keys
1557
Hierarchical to: No other components
1558
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
1559
FCS_COP.1 Cryptographic operation].
1560
Justification: A Diffie-Hellman key agreement is used
1561
in order to have no key distribution, therefore
1562
FCS_CKM.2 makes no sense in this case.
1563
FCS_CKM.4 Cryptographic key destruction: fulfilled by
1564
FCS_CKM.4/EAC1PP
1565
FCS_CKM.1.1/DH_PACE_EAC1PP
1566
The TSF shall generate cryptographic keys in accordance with a specified cryptographic
1567
key generation algorithm Diffie-Hellman-Protocol compliant to [27], ECDH compliant to
1568
[26]2930
and specified cryptographic key sizes TDES 128, AES 128, 192 and 256 bits31
that
1569
meet the following:[7]32
1570
FCS_COP.1/PACE_ENC_EAC1PP
1571
Encryption / Decryption AES / 3DES
1572
Hierarchical to: No other components
1573
Dependencies: [FDP_ITC.1 Import of user data without security
1574
attributes, or FDP_ITC.2 Import of user data with
1575
security attributes, or FCS_CKM.1 Cryptographic key
1576
generation]: fulfilled by
1577
FCS_CKM.1/DH_PACE_EAC1PP.
1578
FCS_CKM.4 Cryptographic key destruction: fulfilled by
1579
FCS_CKM.4/EAC1PP.
1580
FCS_COP.1.1/PACE_ENC_EAC1PP
1581
29 [assignment: cryptographic key generation algorithm]
30 [selection: Diffie-Hellman-Protocol compliant to [27] , ECDH compliant to [26] ]
31 [assignment: cryptographic key sizes]
32 [assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 86 of 191
The TSF shall perform secure messaging – encryption and decryption33
in accordance
1582
with a specified cryptographic algorithm AES, 3DES34
in CBC mode35
and cryptographic
1583
key sizes 3DES 112, AES 128, 192, 256 bit3637
that meet the following: compliant to [7]38
.
1584
FCS_COP.1/PACE_MAC_EAC1PP
1585
Cryptographic operation – MAC
1586
Hierarchical to: No other components
1587
Dependencies: [FDP_ITC.1 Import of user data without security
1588
attributes, or FDP_ITC.2 Import of user data with
1589
security attributes, or FCS_CKM.1 Cryptographic key
1590
generation]: fulfilled by
1591
FCS_CKM.1/DH_PACE_EAC1PP
1592
FCS_CKM.4 Cryptographic key destruction: fulfilled by
1593
FCS_CKM.4/EAC1PP.
1594
FCS_COP.1.1/PACE_MAC_EAC1PP
1595
The TSF shall perform secure messaging – message authentication code39
in accordance
1596
with a specified cryptographic algorithm CMAC, Retail-MAC4041
and cryptographic key
1597
sizes 3DES 112, AES 128, 192, 256 bit4243
that meet the following: compliant to [7]44
.
1598
FCS_CKM.1/CA_EAC1PP
1599
Cryptographic key generation – Diffie-Hellman for Chip Authentication session keys
1600
Hierarchical to: No other components
1601
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
1602
FCS_COP.1 Cryptographic operation] fulfilled by
1603
33 [assignment: list of cryptographic operations]
34 [selection: AES, 3DES]
35 [assignment: cryptographic algorithm]
36 [assignment: cryptographic key sizes]
37 [selection: 112, 128, 192, 256]
38 [assignment: list of standards]
39 [assignment: list of cryptographic operations]
40
[assignment: cryptographic algorithm]
41 [selection: CMAC, Retail-MAC]
42 [assignment: cryptographic key sizes]
43 [selection: 112, 128, 192, 256]
44 [assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 87 of 191
FCS_COP.1/CA_ENC_EAC1PP and
1604
FCS_COP.1/CA_MAC_EAC1PP
1605
FCS_CKM.4 Cryptographic key destruction fulfilled by
1606
FCS_CKM.4/EAC1PP.
1607
FCS_CKM.1.1/CA_EAC1PP
1608
The TSF shall generate cryptographic keys in accordance with a specified cryptographic
1609
key generation algorithm Diffie-Hellman protocol compliant to PKCS#3 and based on an
1610
ECDH protocol45
and specified cryptographic key sizes TDES 112, AES 128, 192 and 256
1611
bits46
that meet the following:based on the Diffie-Hellman key derivation protocol compliant
1612
to [27] and [16] , based on an ECDH protocol compliant to [26]4748
1613
22. Application note (taken from [5], application note 12)
1614
FCS_CKM.1/CA_EAC1PP implicitly contains the requirements for the hashing functions used
1615
for key derivation by demanding compliance to [16].
1616
23. Application note (taken from [5], application note 13)
1617
The TOE generates a shared secret value with the terminal during the Chip Authentication
1618
Protocol Version 1, see [16]. This protocol may be based on the Diffie-Hellman-Protocol
1619
compliant to PKCS#3 (i.e. modulo arithmetic based cryptographic algorithm, cf. [27]) or on the
1620
ECDH compliant to TR-03111 (i.e. an elliptic curve cryptography algorithm) (cf. [26], for
1621
details). The shared secret value is used to derive the Chip Authentication Session Keys used
1622
for encryption and MAC computation for secure messaging (defined in Key Derivation Function
1623
[16]).
1624
24. Application note (taken from [5], application note 14)
1625
The TOE shall implement the hash function SHA-1 for the cryptographic primitive to derive the
1626
keys for secure messaging from any shared secrets of the Authentication Mechanisms. The
1627
Chip Authentication Protocol v.1 may use SHA-1 (cf. [16]). The TOE may implement additional
1628
hash functions SHA-224 and SHA-256 for the Terminal Authentication Protocol v.1 (cf. [16] for
1629
details).
1630
25. Application note (taken from [5], application note 15)
1631
The TOE shall destroy any session keys in accordance with FCS_CKM.4 from [13] after (i)
1632
detection of an error in a received command by verification of the MAC and (ii) after successful
1633
run of the Chip Authentication Protocol v.1. (iii) The TOE shall destroy the PACE Session Keys
1634
after generation of a Chip Authentication Session Keys and changing the secure messaging
1635
to the Chip Authentication Session Keys. (iv) The TOE shall clear the memory area of any
1636
45 [assignment: cryptographic key generation algorithm]
46 [assignment: cryptographic key sizes]
47 [assignment: list of standards]
48 [selection: based on the Diffie-Hellman key derivation protocol compliant to [27] and [16] , based on an ECDH
protocol compliant to [26] ]
IDentity Applet v3.4/eIDAS Security Target
Page 88 of 191
session keys before starting the communication with the terminal in a new after-reset-session
1637
as required by FDP_RIP.1/EAC1PP. Concerning the Chip Authentication keys
1638
FCS_CKM.4/EAC1PP is also fulfilled by FCS_CKM.1/CA_EAC1PP.
1639
FCS_COP.1/CA_ENC_EAC1PP
1640
Cryptographic operation – Symmetric Encryption / Decryption
1641
Hierarchical to: No other components
1642
Dependencies: [FDP_ITC.1 Import of user data without security
1643
attributes, or FDP_ITC.2 Import of user data with
1644
security attributes, or FCS_CKM.1 Cryptographic key
1645
generation] fulfilled by FCS_CKM.1/CA_EAC1PP
1646
FCS_CKM.4 Cryptographic key destruction fulfilled by
1647
FCS_CKM.4/EAC1PP
1648
FCS_COP.1.1/CA_ENC_EAC1PP
1649
The TSF shall perform secure messaging – encryption and decryption49
in accordance
1650
with a specified cryptographic algorithm Triple-DES and AES50
and cryptographic key
1651
sizes Triple-DES:112, AES: 128, 192 and 256 bits51
that meet the following:[16]52
.
1652
26. Application note (taken from [5], application note 16)
1653
This SFR requires the TOE to implement the cryptographic primitives (e.g. Triple-DES and/or
1654
AES) for secure messaging with encryption of the transmitted data. The keys are agreed
1655
between the TOE and the terminal as part of the Chip Authentication Protocol Version 1
1656
according to the FCS_CKM.1/CA_EAC1PP.
1657
FCS_COP.1/SIG_VER_EAC1PP
1658
Cryptographic operation – Signature verification by electronic document
1659
Hierarchical to: No other components
1660
Dependencies: [FDP_ITC.1 Import of user data without security
1661
attributes, or FDP_ITC.2 Import of user data with
1662
security attributes, or FCS_CKM.1 Cryptographic key
1663
generation] fulfilled by FCS_CKM.1/CA_EAC1PP
1664
49 [assignment: list of cryptographic operations]
50 [assignment: cryptographic algorithm]
51 [assignment: cryptographic key sizes]
52 [assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 89 of 191
FCS_CKM.4 Cryptographic key destruction fulfilled by
1665
FCS_CKM.4/EAC1PP
1666
FCS_COP.1.1/SIG_VER_EAC1PP
1667
The TSF shall perform digital signature verification53
in accordance with a specified
1668
cryptographic algorithm RSA v1.5 with SHA-256 and SHA-512, RSA-PSS with SHA-256
1669
and SHA-512, ECDSA with SHA-256, SHA-224, SHA-384 and SHA-51254
and
1670
cryptographic key sizes RSA 2048, 4096 and from 2000 bit to 4096 bit in one bit steps,
1671
ECDSA 160, 192, 224, 256, 320, 384, 521 bits55
that meet the following: [24][29]56
.
1672
27. Application note (redefined by ST author, taken from [5], application note 17)
1673
Applied.
1674
28. Application note (from ST author)
1675
The TOE based on the Platform functionalities supports RSA and RSA-CRT digital signature
1676
algorithms and cryptographic key sizes 512 bits up to 4096 bits with equal security measures.
1677
However, to fend off attackers with high attack potential an adequate key length must be used.
1678
FCS_COP.1/CA_MAC_EAC1PP
1679
Cryptographic operation – MAC
1680
Hierarchical to: No other components
1681
Dependencies: [FDP_ITC.1 Import of user data without security
1682
attributes, or FDP_ITC.2 Import of user data with
1683
security attributes, or FCS_CKM.1 Cryptographic key
1684
generation] fulfilled by FCS_CKM.1/CA_EAC1PP
1685
FCS_CKM.4 Cryptographic key destruction fulfilled by
1686
FCS_CKM.4/EAC1PP
1687
FCS_COP.1.1/CA_MAC_EAC1PP
1688
53 [assignment: list of cryptographic operations]
54 [assignment: cryptographic algorithm]
55 [assignment: cryptographic key sizes]
56 [assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 90 of 191
The TSF shall perform secure messaging – message authentication code57
in accordance
1689
with a specified cryptographic algorithm CMAC or Retail-MAC58
and cryptographic key
1690
sizes 112, 128, 192 and 256 bits59
that meet the following: [16]60
.
1691
29. Application note (taken from [5], application note 18)
1692
This SFR requires the TOE to implement the cryptographic primitive for secure messaging with
1693
encryption and message authentication code over the transmitted data. The key is agreed
1694
between the TSF by Chip Authentication Protocol Version 1 according to the
1695
FCS_CKM.1/CA_EAC1PP. Furthermore, the SFR is used for authentication attempts of a
1696
terminal as Personalisation Agent by means of the authentication mechanism.
1697
The following SFRs are defined because the TOE supports the Chip Authentication version 2
1698
and Restricted Identification key pair(s) generation on the TOE as described in
1699
FMT_MTD.1/SK_PICC_EAC2PP.
1700
FCS_CKM.1/CA2
1701
Cryptographic key generation – Chip Authentication version 2 Key pair(s)
1702
Hierarchical to: No other components
1703
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
1704
FCS_COP.1 Cryptographic operation]
1705
fulfilled by FCS_COP.1/PACE_ENC_EAC2PP and
1706
FCS_COP.1/PACE_MAC_EAC2PP
1707
FCS_CKM.4 Cryptographic key destruction fulfilled by
1708
FCS_CKM.4/EAC2PP
1709
FCS_CKM.1.1/CA2
1710
The TSF shall generate cryptographic keys to Chip Authentication 2 in accordance with a
1711
specified cryptographic key generation algorithm RSA or ECC61
and specified cryptographic
1712
key sizes 1024, 1280, 1536, 1984, 2048, 3072 and 4096 bits or 160, 192, 224, 256, 384 and
1713
521 bits 62
that meet the following: [31]63
.
1714
30. Application note (from ST author)
1715
The TOE supports to create Chip Authentication version 2 Key pair(s) on the TOE as described
1716
in FMT_MTD.1/SK_PICC_EAC2PP. The TOE generates the key pair(s) in secure way, but the
1717
57 [assignment: list of cryptographic operations]
58 [assignment: cryptographic algorithm]
59 [assignment: cryptographic key sizes]
60 [assignment: list of standards]
61 [assignment: cryptographic key generation algorithm]
62 [assignment: cryptographic key sizes]
63 [assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 91 of 191
appropriate key size shall be assessed during the personalization of the TOE.
1718
The refinement was necessary for the sake of clarity.
1719
FCS_CKM.1/RI
1720
Cryptographic key generation – Restricted Identification Key pair (s)
1721
Hierarchical to: No other components
1722
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
1723
FCS_COP.1 Cryptographic operation] not fullfilled but
1724
justified: the crypgographic part of Restricted
1725
Identification protocol is not part of the TOE, so no
1726
cryptographic operation is related to FCS_CKM.1/RI.
1727
FCS_CKM.4 Cryptographic key destruction fullfilled by
1728
FCS_CKM.4/EAC2PP
1729
FCS_CKM.1.1/RI
1730
The TSF shall generate cryptographic keys to Restricted Identification in accordance with a
1731
specified cryptographic key generation algorithm RSA or ECC64
and specified cryptographic
1732
key sizes 1024, 1280, 1536, 1984, 2048, 3072 and 4096 bits or 160, 192, 224, 256, 384 and
1733
521 bits 65
that meet the following: [31][17]66
.
1734
31. Application note (from ST author)
1735
The TOE supports to create Restricted Identification Key pair(s) on the TOE as described in
1736
FMT_MTD.1/SK_PICC_EAC2PP. The TOE generates the key pair(s) in secure way, but the
1737
appropriate key size shall be assessed during the personalization of the TOE.
1738
The refinement was necessary for the sake of clarity.
1739
The following SFRs are new and concern cryptographic support for ePassport application in
1740
combination with [5] in case the Active Authentication protocol is active:
1741
• FCS_CKM.1/AA
1742
• FCS_COP.1/AA
1743
FCS_CKM.1/AA
1744
Cryptographic key generation – Active Authentication Key Pair
1745
Hierarchical to: No other components
1746
64 [assignment: cryptographic key generation algorithm]
65 [assignment: cryptographic key sizes]
66 [assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 92 of 191
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
1747
FCS_COP.1 Cryptographic operation]
1748
fulfilled by FCS_COP.1/AA
1749
FCS_CKM.4 Cryptographic key destruction fulfilled by
1750
FCS_CKM.4/EAC1PP
1751
FCS_CKM.1.1/AA
1752
The TSF shall generate cryptographic keys in accordance with a specified cryptographic key
1753
generation algorithm RSA or ECDSA67
and specified cryptographic key sizes 1024, 1280,
1754
1536, 1984, 2048, 3072 and 4096 bits or 160, 192, 224, 256, 384 and 521 bits 68
that meet the
1755
following: [7][9]69
.
1756
FCS_COP.1/AA
1757
Cryptographic operation – Active Authentication
1758
Hierarchical to: No other components
1759
Dependencies: [FDP_ITC.1 Import of user data without security
1760
attributes, FDP_ITC.2 Import of user data with security
1761
attribute or FCS_CKM.1 Cryptographic key generation]
1762
fulfilled by FCS_CKM.1/AA
1763
FCS_CKM.4 Cryptographic key destruction fulfilled by
1764
FCS_CKM.4/EAC1PP
1765
FCS_COP.1.1/AA
1766
The TSF shall perform digital signature creation70
in accordance with a specified
1767
cryptographic algorithm RSA or ECDSA71
and . cryptographic key sizes RSA with key
1768
sizes 2048-4096 and ECDSA with key sizes 160-52172
that meet the following: [7][9]73
.
1769
The following SFRs are new and concerns cryptographic support for ePassport applications in
1770
combination with [5].
1771
• FCS_CKM.1/CAM
1772
67 [assignment: cryptographic key generation algorithm]
68 [assignment: cryptographic key sizes]
69 [assignment: list of standards]
70 [assignment: list of cryptographic operations]
71 [assignment: cryptographic algorithm]
72 [assignment: cryptographic key sizes]
73 [assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 93 of 191
• FCS_COP.1/CAM
1773
FCS_CKM.1/CAM
1774
Cryptographic key generation – PACE-CAM public key and Diffie-Hellman for General Mapping in
1775
PACE-GM
1776
Hierarchical to: No other components
1777
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
1778
FCS_COP.1 Cryptographic operation]
1779
fulfilled by FCS_COP.1/CAM
1780
FCS_CKM.4 Cryptographic key destruction
1781
fulfilled by FCS_CKM.4/EAC1PP
1782
FCS_CKM.1.1/CAM
1783
The TSF shall generate cryptographic keys in accordance with a specified cryptographic
1784
key generation algorithm PACE-CAM in combination with PACE-GM74
and specified
1785
cryptographic key sizes AES 128, 192 and 256 bit75
that meet the following: [9]76
.
1786
32. Application note (from ST author)
1787
In the combined protocol PACE-CAM, after the completion of PACE in combination with the
1788
general mapping (PACE-GM), the chip authenticates itself by adding (multiplying) the
1789
randomly chosen nonce of the GM step with the inverse of the chip authentication secret key,
1790
and sends this value together with chip authentication public key to the card; cf.[9].
1791
FCS_COP.1/CAM
1792
Cryptographic operation – PACE-CAM
1793
Hierarchical to: No other components
1794
Dependencies: [FDP_ITC.1 Import of user data without security
1795
attributes, or FDP_ITC.2 Import of user data with
1796
security attributes, or FCS_CKM.1 Cryptographic key
1797
generation]
1798
fulfilled by FCS_CKM.1/CAM
1799
74 [assignment: cryptographic key generation algorithm]
75 [assignment: cryptographic key sizes]
76 [assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 94 of 191
FCS_CKM.4 Cryptographic key destruction
1800
fulfilled by FCS_CKM.4/EAC1PP
1801
FCS_COP.1.1/CAM
1802
The TSF shall perform the PACE-CAM protocol77
in accordance with a specified
1803
cryptographic algorithm PACE-CAM78
and cryptographic key sizes AES 128, 192 and 256
1804
bits79
that meet the following:[9]80
1805
33. Application note (from ST author)
1806
Whereas FCS_CKM.1/CAM addresses the Diffie-Hellman based key-derivation, this SFR is
1807
concerned with the correct implementation and execution of the whole PACE-CAM protocol.
1808
Note that in particular the last protocol step to authenticate the chip towards the terminal is an
1809
essential part of the protocol, and not addressed in FCS_CKM.1/CAM.
1810
The following SFRs are imported due to claiming [14]. They only concern the cryptographic
1811
support for an eSign application.
1812
• FCS_CKM.1/SSCDPP
1813
• FCS_CKM.4/SSCDPP
1814
(equivalent to FCS_CKM.4/EAC2PP, but listed here for the sake of completeness)
1815
• FCS_COP.1/SSCDPP
1816
FCS_CKM.1/SSCDPP
1817
Cryptographic key generation
1818
Hierarchical to: No other components
1819
Dependencies: FCS_CKM.2 Cryptographic key distribution, or
1820
FCS_COP.1 Cryptographic operation] fulfilled by
1821
FCS_COP.1/SSCDPP
1822
FCS_CKM.4 Cryptographic key destruction fulfilled by
1823
FCS_CKM.4/EAC2PP
1824
FCS_CKM.1.1/SSCDPP
1825
77 [assignment: list of cryptographic operations]
78 [assignment: cryptographic algorithm]
79 [assignment: cryptographic key sizes]
80 [assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 95 of 191
The TSF shall generate an SCD/SVD pair in accordance with a specified cryptographic
1826
key generation algorithm RSA or ECDSA81
and specified cryptographic key sizes 1024,
1827
1280, 1536, 1984, 2048, 3072 and 4096 bits or 160, 192, 224, 256, 384 and 521 bits82
1828
that meet the following: [23]83
.
1829
34. Application note (taken from [14], application note 5)
1830
The ST writer performed the missing operations in the element FCS_CKM.1.1/SSCDPP. The
1831
refinement in the element FCS_CKM.1.1 SSCDPP substitutes “cryptographic keys” by
1832
“SCD/SVD pairs” because it clearly addresses the SCD/SVD key generation.
1833
FCS_COP.1/SSCDPP
1834
Cryptographic operation
1835
Hierarchical to: No other components
1836
Dependencies: FDP_ITC.1 Import of user data without security
1837
attributes, FDP_ITC.2 Import of user data with security
1838
attribute or FCS_CKM.1 Cryptographic key generation]
1839
fulfilled by FCS_CKM.1/SSCDPP
1840
FCS_CKM.4 Cryptographic key destruction fulfilled by
1841
FCS_CKM.4/EAC2PP
1842
FCS_COP.1.1/SSCDPP
1843
The TSF shall perform digital signature creation84
in accordance with a specified
1844
cryptographic algorithm RSA according to RSASSA-PKCS1-v1_5, RSASSA-PSS or
1845
ECDSA according to ISO14883-385
and . cryptographic key sizes RSA with key sizes
1846
2048-4096 and ECDSA with key sizes 160-52186
that meet the following: [24] [29]87
.
1847
35. Application note (taken from [14], application note 7)
1848
Applied.
1849
36. Application note (from ST author)
1850
The underlying Platform supports RSA, RSA-CRT and ECDSA digital signature algorithms and
1851
cryptographic key sizes 2048 bits to 4096 bits (RSA) and 160 bits to 521 bits (ECDSA) with
1852
81 [assignment: cryptographic key generation algorithm]
82 [assignment: cryptographic key sizes]
83 [assignment: list of standards]
84 [assignment: list of cryptographic operations]
85 [assignment: cryptographic algorithm]
86 [assignment: cryptographic key sizes]
87 [assignment: list of standards]
IDentity Applet v3.4/eIDAS Security Target
Page 96 of 191
equal security measures. However, to fend off attackers with high attack potential an adequate
1853
key length must be used
1854
6.1.2. Class FIA
1855
Table 10 provides an overview of the authentication and identification mechanisms used.
1856
Name SFR for the TOE
PACE protocol FIA_UID.1/PACE_EAC2PP
FIA_UAU.5/PACE_EAC2PP
FIA_AFL.1/Suspend_PIN_EAC2PP
FIA_AFL.1/Block_PIN_EAC2PP
FIA_AFL.1/PACE_EAC2PP
FIA_AFL.1/PACE_EAC1PP
PACE-CAM protocol SFRs above for the PACE part; in addition, for the Chip
Authentication Mapping (CAM):
FIA_API.1/PACE_CAM
FIA_UAU.5/PACE_EAC1PP
Terminal Authentication
Protocol version 2
FIA_UAU.1/EAC2_Terminal_EAC2PP
FIA_UAU.5/PACE_EAC2PP
Chip Authentication Protocol
version 2
FIA_API.1/CA_EAC2PP
FIA_UAU.5/PACE_EAC2PP
FIA_UAU.6/PACE_EAC2PP
Terminal Authentication
Protocol version 1
FIA_UAU.1/PACE_EAC1PP
FIA_UAU.5/PACE_EAC1PP
Chip Authentication Protocol
version 1
FIA_API.1/EAC1PP
FIA_UAU.5/PACE_EAC1PP
FIA_UAU.6/EAC_EAC1PP
Active Authentication FIA_API.1/AA
FIA_UAU.1/PACE_EAC1PP
FIA_UAU.4/PACE_EAC1PP
Restricted Identification FIA_API.1/RI_EAC2PP
eSign-PIN FIA_UAU.1/SSCDPP
Table 10 Overview of authentication and identification SFRs
1857
6.1.2.1. SFRs for EAC2-protected Data
1858
The following SFRs are imported due to claiming [6]. They mainly concern authentication
1859
mechanisms related to applications with EAC2-protected data.
1860
• FIA_AFL.1/Suspend_PIN_EAC2PP
1861
• FIA_AFL.1/Block_PIN_EAC2PP
1862
• FIA_API.1/CA_EAC2PP
1863
• FIA_API.1/RI_EAC2PP
1864
• FIA_UID.1/PACE_EAC2PP
1865
• FIA_UID.1/EAC2_Terminal_EAC2PP
1866
IDentity Applet v3.4/eIDAS Security Target
Page 97 of 191
37. Application note (taken from [20], application note 10)
1867
The user identified after a successfully performed TA2 protocol is an EAC2 terminal. Note that
1868
TA1 is covered by FIA_UID.1/PACE_EAC1PP. In that case, the terminal identified is in addition
1869
also an EAC1 terminal.
1870
• FIA_UAU.1/PACE_EAC2PP
1871
• FIA_UAU.1/EAC2_Terminal_EAC2PP
1872
• FIA_UAU.4/PACE_EAC2PP
1873
38. Application note (taken from [6], application note 26)
1874
For PACE, the TOE randomly selects an almost uniformly distributed nonce of 128 bit length.
1875
The [20] and the current ST support a key derivation function based on AES; see [17]. For
1876
TA2, the TOE randomly selects a nonce rPICC of 64 bit length, see [17]. This SFR extends
1877
FIA_UAU.4/PACE_EAC1PP from [13] by assigning the authentication mechanism Terminal
1878
Authentication 2.
1879
• FIA_UAU.5/PACE_EAC2PP
1880
• FIA_UAU.6/CA_EAC2PP
1881
• FIA_AFL.1/PACE_EAC2PP
1882
• FIA_UAU.6/PACE_EAC2PP
1883
FIA_AFL.1/Suspend_PIN_EAC2PP
1884
Authentication failure handling – Suspending PIN
1885
Hierarchical to: No other components
1886
Dependencies: [FIA_UAU.1 Timing of authentication] fulfilled by
1887
FIA_UAU.1/PACE_EAC2PP
1888
FIA_AFL.1.1/Suspend_PIN_EAC2PP
1889
The TSF shall detect when an administrator configurable positive integer within [1-127]88
1890
unsuccessful authentication attempts occur related to consecutive failed authentication
1891
attempts using the PIN as the shared password for PACE89
.
1892
FIA_AFL.1.2/Suspend_PIN_EAC2PP
1893
88[selection: [assignment: positive integer number], an administrator configurable positive integer within
[assignment: range of acceptable values]]
89 [assignment: list of authentication events]
IDentity Applet v3.4/eIDAS Security Target
Page 98 of 191
When the defined number of unsuccessful authentication attempts has been met90
, the
1894
TSF shall suspend the reference value of the PIN according to [17]91
.
1895
39. Application note (taken from [6], application note 19)
1896
This SFR is not in conflict to FIA_AFL.1 from [13], since it just adds a requirement specific to
1897
the case where the PIN is the shared password. Thus, the assigned integer number for
1898
unsuccessful authentication attempts with any PACE password could be different to the integer
1899
for the case when using a PIN.
1900
FIA_AFL.1/Block_PIN_EAC2PP
1901
Authentication failure handling – Blocking PIN
1902
Hierarchical to: No other components
1903
Dependencies: [FIA_UAU.1 Timing of authentication] fulfilled by
1904
FIA_UAU.1/PACE_EAC2PP
1905
FIA_AFL.1.1/Block_PIN_EAC2PP
1906
The TSF shall detect when an administrator configurable positive integer within [1-127]92
1907
unsuccessful authentication attempts occur related to consecutive failed authentication
1908
attempts using the suspended93
PIN as the shared password for PACE94
.
1909
FIA_AFL.1.2/Block_PIN_EAC2PP
1910
When the defined number of unsuccessful authentication attempts has been met95
, the
1911
TSF shall block the reference value of PIN according to [17]96
.
1912
FIA_API.1/CA_EAC2PP
1913
Authentication Proof of Identity
1914
Hierarchical to: No other components
1915
Dependencies: No dependencies
1916
FIA_API.1.1/CA_EAC2PP
1917
90 [selection: met , surpassed]
91 [assignment: list of actions]
92 [selection: [assignment: positive integer number], an administrator configurable positive integer within
[assignment: range of acceptable values]]
93 as required by FIA_AFL.1/Suspend_PIN_EAC2PP
94 [assignment: list of authentication events]
95 [selection: met , surpassed]
96 [assignment: list of actions]
IDentity Applet v3.4/eIDAS Security Target
Page 99 of 191
The TSF shall provide the protocol Chip Authentication 2 according to [17]97
, to prove the
1918
identity of the TOE98
.
1919
FIA_API.1/RI_EAC2PP
1920
Authentication Proof of Identity
1921
Hierarchical to: No other components
1922
Dependencies: No dependencies
1923
FIA_API.1.1/RI_EAC2PP
1924
The TSF shall provide the Restricted Identification protocol according to [17]99
, to prove
1925
the identity of the TOE100
.
1926
40. Application note (taken from [6], application note 20)
1927
Restricted Identification provides a sector-specific identifier of every electronic document. It
1928
thus provides a pseudonymous way to identify the Electronic Document Holder in a case where
1929
the CHAT of the terminal does not allow to access Sensitive User Data that directly identify the
1930
Electronic Document Holder. Restricted Identification shall only be used after successfully
1931
running Terminal Authentication 2 and Chip Authentication 2. Note that Restricted Identification
1932
is optional according to [17], and thus the above SFR only applies if Restricted Identification is
1933
supported by the TOE.
1934
FIA_UID.1/PACE_EAC2PP
1935
Timing of identification
1936
Hierarchical to: No other components
1937
Dependencies: No dependencies
1938
FIA_UID.1.1/PACE_EAC2PP
1939
The TSF shall allow:
1940
1. to establish a communication channel,
1941
2. carrying out the PACE protocol according to [17]
1942
3. to read the Initialization Data if it is not disabled by TSF according to
1943
FMT_MTD.1/INI_DISFMT_MTD.1/INI_DIS_EAC2PP101
1944
97 [assignment: authentication mechanism]
98 [assignment: authorised user or role, or of the TOE itself]
99 [assignment: authentication mechanism]
100 [assignment: authorized user or role]
101 [assignment: list of TSF-mediated actions]
IDentity Applet v3.4/eIDAS Security Target
Page 100 of 191
4. none102
1945
on behalf of the user to be performed before the user is identified.
1946
FIA_UID.1.2/PACE_EAC2PP
1947
The TSF shall require each user to be successfully identified before allowing any other
1948
TSF-mediated actions on behalf of that user.
1949
41. Application note (taken from [6], application note 21)
1950
The user identified after a successful run of PACE is a PACE terminal. In case the PIN or PUK
1951
were used for PACE, the user identified is the Electronic Document Holder using a PACE
1952
terminal. Note that neither the CAN nor the MRZ effectively represent secrets, but are
1953
restricted-revealable; i.e. in case the CAN or the MRZ were used for PACE, it is either the
1954
Electronic Document Holder itself, an authorized person other than the Electronic Document
1955
Holder, or a device.
1956
42. Application note (from ST author)
1957
The refinement was necessary to ensure unified terminology usage of SFRs.
1958
FIA_UID.1/EAC2_Terminal_EAC2PP
1959
Timing of identification
1960
Hierarchical to: No other components
1961
Dependencies: No dependencies
1962
FIA_UID.1.1/EAC2_Terminal_EAC2PP
1963
The TSF shall allow
1964
1. to establish a communication channel,
1965
2. carrying out the PACE protocol according to [17],
1966
3. to read the Initialization Data if it is not disabled by TSF according to
1967
FMT_MTD.1/INI_DISFMT_MTD.1/INI_DIS_EAC2PP
1968
4. carrying out the Terminal Authentication protocol 2 according to [17]103
1969
5. none104
1970
on behalf of the user to be performed before the user is identified.
1971
FIA_UID.1.2/EAC2_Terminal_EAC2PP
1972
102 [assignment: list of TSF-mediated actions]
103 [assignment: list of TSF-mediated actions]
104 [assignment: list of TSF-mediated actions]
IDentity Applet v3.4/eIDAS Security Target
Page 101 of 191
The TSF shall require each user to be successfully identified before allowing any other
1973
TSF-mediated actions on behalf of that user.
1974
43. Application note (taken from [6], application note 22)
1975
The user identified after a successfully performed TA2 is an EAC2 terminal. The types of EAC2
1976
terminals are application dependent;
1977
44. Application note (taken from [6], application note 23)
1978
In the life cycle phase manufacturing, the manufacturer is the only user role known to the TOE.
1979
The manufacturer writes the initialization data and/or pre-personalization data in the audit
1980
records of the IC.
1981
Note that a Personalization Agent acts on behalf of the electronic document issuer under his
1982
and the CSCA's and DS's policies. Hence, they define authentication procedures for
1983
Personalization Agents. The TOE must functionally support these authentication procedures.
1984
These procedures are subject to evaluation within the assurance components ALC_DEL.1 and
1985
AGD_PRE.1. The TOE assumes the user role Personalization Agent, if a terminal proves the
1986
respective Terminal Authorization level (e. g. a privileged terminal, cf. [17]).
1987
45. Application note (from ST author)
1988
The refinement was necessary to ensure unified terminology usage of SFRs.
1989
FIA_UAU.1/PACE_EAC2PP
1990
Timing of authentication
1991
Hierarchical to: No other components
1992
Dependencies: [FIA_UID.1 Timing of identification]: fulfilled by
1993
FIA_UID.1/PACE_EAC2PP
1994
FIA_UAU.1.1/PACE_EAC2PP
1995
The TSF shall allow:
1996
1. to establish a communication channel,
1997
2. carrying out the PACE protocol according to [17],
1998
3. to read the Initialization Data if it is not disabled by TSF according to
1999
FMT_MTD.1/INI_DISFMT_MTD.1/INI_DIS_EAC2PP,
2000
4. none105
2001
on behalf of the user to be performed before the user is authenticated.
2002
FIA_UAU.1.2/PACE_EAC2PP
2003
105 [assignment: list of TSF-mediated actions]
IDentity Applet v3.4/eIDAS Security Target
Page 102 of 191
The TSF shall require each user to be successfully authenticated before allowing any other
2004
TSF-mediated actions on behalf of that user.
2005
46. Application note (taken from [6], application note 24)
2006
If PACE has been successfully performed, secure messaging is started using the derived
2007
session keys (PACE-KMAC, PACE-KEnc), cf. FTP_ITC.1/PACE_EAC2PP. 44. Application note
2008
(taken from [6], application note 23) also applies here.
2009
47. Application note (from ST author)
2010
The refinement was necessary to ensure unified terminology usage of SFRs.
2011
FIA_UAU.1/EAC2_Terminal_EAC2PP
2012
Timing of authentication
2013
Hierarchical to: No other components
2014
Dependencies: [FIA_UID.1 Timing of identification]: fulfilled by
2015
FIA_UAU.1/EAC2_Terminal_EAC2PP
2016
FIA_UAU.1.1/EAC2_Terminal_EAC2PP
2017
The TSF shall allow:
2018
1. to establish a communication channel,
2019
2. carrying out the PACE protocol according to [17],
2020
3. to read the Initialization Data if it is not disabled by TSF according to
2021
FMT_MTD.1/INI_DISFMT_MTD.1/INI_DIS_EAC2PP
2022
4. carrying out the Terminal Authentication protocol 2 according to [17]106
2023
on behalf of the user to be performed before the user is authenticated.
2024
FIA_UAU.1.2/EAC2_Terminal_EAC2PP
2025
The TSF shall require each user to be successfully authenticated before allowing any other
2026
TSF-mediated actions on behalf of that user.
2027
48. Application note (taken from [6], application note 25)
2028
The user authenticated after a successful run of TA2 is an EAC2 terminal. The authenticated
2029
terminal will immediately perform Chip Authentication 2 as required by
2030
FIA_API.1/CA_EAC2PP using, amongst other, Comp(ephem-PKPCD-TA) from the
2031
accomplished TA2. Note that Passive Authentication using SOC is considered to be part of
2032
CA2 within this ST.
2033
106 [assignment: list of TSF-mediated actions]
IDentity Applet v3.4/eIDAS Security Target
Page 103 of 191
49. Application note (from ST author)
2034
The refinement was necessary to ensure unified terminology usage of SFRs.
2035
FIA_UAU.4/PACE_EAC2PP
2036
Single-use authentication of the Terminals by the TOE
2037
Hierarchical to: No other components
2038
Dependencies: No dependencies
2039
FIA_UAU.4.1/PACE_EAC2PP
2040
The TSF shall prevent reuse of authentication data related to:
2041
1. PACE protocol according to [17],
2042
2. Authentication Mechanism based on AES107
2043
3. Terminal Authentication 2 protocol according to [17].108
2044
4. none109
2045
50. Application note (taken from [6], application note 26)
2046
For PACE, the TOE randomly selects an almost uniformly distributed nonce of 128 bit length.
2047
The [6] supports a key derivation function based on AES; see [17]. For TA2, the TOE randomly
2048
selects a nonce rPICC of 64 bit length, see [17]. This SFR extends FIA_UAU.4/PACE from [13]
2049
by assigning the authentication mechanism Terminal Authentication 2.
2050
FIA_UAU.5/PACE_EAC2PP
2051
Multiple authentication mechanisms
2052
Hierarchical to: No other components
2053
Dependencies: No dependencies
2054
FIA_UAU.5.1/PACE_EAC2PP
2055
The TSF shall provide
2056
1. PACE protocol according to [17],
2057
2. Passive Authentication according to [8]
2058
3. Secure messaging in MAC-ENC mode according to [18]
2059
4. Symmetric Authentication Mechanism based on TDES and AES110111
2060
107 [selection: Triple-DES , AES or other approved algorithms]
108 [assignment: identified authentication mechanism(s)]
109 [assignment: identified authentication mechanism(s)]
110 restricting the [selection: Triple-DES, AES or other approved algorithms]
111 [selection: AES or other approved algorithms]
IDentity Applet v3.4/eIDAS Security Target
Page 104 of 191
5. Terminal Authentication 2 protocol according to [17],
2061
6. Chip Authentication 2 according to [17]112113
2062
7. none114
2063
to support user authentication.
2064
FIA_UAU.5.2/PACE_EAC2PP
2065
The TSF shall authenticate any user’s claimed identity according to the following rules:
2066
1. Having successfully run the PACE protocol the TOE accepts only received
2067
commands with correct message authentication codes sent by secure messaging
2068
with the key agreed with the terminal by the PACE protocol.
2069
2. The TOE accepts the authentication attempt as Personalization Agent by
2070
Symmetric Authentication (Device authentication) according to [30]115
2071
3. The TOE accepts the authentication attempt by means of the Terminal
2072
Authentication 2 protocol,only if (i) the terminal presents its static public key PKPCD
2073
and the key is successfully verifiable up to the CVCA and (ii) the terminal uses the
2074
PICC identifier IDPICC = Comp(ephem-PKPICC-PACE) calculated during, and the
2075
secure messaging established by the, current PACE authentication.
2076
4. Having successfully run Chip Authentication 2, the TOE accepts only received
2077
commands with correct message authentication codes sent by secure messaging
2078
with the key agreed with the terminal by Chip Authentication 2.116
2079
5. none117
2080
51. Application note (taken from [6], application note 27)
2081
Refinement of FIA_UAU.5.2/PACE_EAC2PP, since here PACE must adhere to [17] and [18],
2082
cf. 9. Application note (taken from [6], application note 10). Since the formulation “MAC-ENC
2083
mode” is slightly ambiguous (there is only one secure messaging mode relevant both in [13]
2084
and here, and it is actually the same in both references), it is removed here by refinement in
2085
the third bullet point of FIA_UAU.5.1/PACE_EAC2PP.
2086
Remark: Note that 5. and 6. in FIA_UAU.5.1/PACE_EAC2PP and 3. and 4. of
2087
FIA_UAU.5.2/PACE_EAC2PP are additional assignments (using the open assignment
2088
operation) compared to [13].
2089
52. Application note (from ST author)
2090
112 Passive Authentication using SOC is considered to be part of CA2 within this ST.
113 [assignment: list of multiple authentication mechanisms]
114 [assignment: list of multiple authentication mechanisms]
115 [selection: the Authentication Mechanism with Personalization Agent Key(s)]
116 [assignment: rules describing how the multiple authentication mechanisms provide authentication]
117 [assignment: rules describing how the multiple authentication mechanisms provide authentication]
IDentity Applet v3.4/eIDAS Security Target
Page 105 of 191
Symmetric Authentication Mechanism implemented according to [30].
2091
FIA_UAU.6/CA_EAC2PP
2092
Re-authenticating of Terminal by the TOE
2093
Hierarchical to: No other components
2094
Dependencies: No dependencies
2095
FIA_UAU.6.1/CA_EAC2PP
2096
The TSF shall re-authenticate the user under the conditions each command sent to the
2097
TOE after a successful run of Chip Authentication 2 shall be verified as being sent by the
2098
EAC2 terminal118
.
2099
FIA_AFL.1/PACE_EAC2PP
2100
Authentication failure handling – PACE authentication using non-blocking authorisation data
2101
Hierarchical to: No other components
2102
Dependencies: [FIA_UAU.1 Timing of authentication]: fulfilled by
2103
FIA_UAU.1/PACE_EAC2PP
2104
FIA_AFL.1.1/PACE_EAC2PP
2105
The TSF shall detect when an administrator configurable positive integer number within
2106
[1-127]119
unsuccessful authentication attempt occurs related to authentication attempts
2107
using the PACE password as shared password.120
2108
FIA_AFL.1.2/PACE_EAC2PP
2109
When the defined number of unsuccessful authentication attempts has been met121
, the
2110
TSF shall delay each following authentication attempt until the next successful
2111
authentication.122
.
2112
53. Application note (from ST author)
2113
In line with [6] the shared password for PACE can be CAN, MRZ, PIN and PUK. The specific
2114
case of PIN is detailed in FIA_AFL.1/Suspend_PIN_EAC2PP and
2115
118 [assignment: list of conditions under which re-authentication is required]
119 [selection: [assignment: positive integer number], an administrator configurable positive integer within
[assignment: range of acceptable values]]
120 [assignment: list of authentication events]
121 [selection: met ,surpassed]
122 [assignment: list of actions]
IDentity Applet v3.4/eIDAS Security Target
Page 106 of 191
FIA_AFL.1/Block_PIN_EAC2PP and furthermore 39. Application note (taken from [6],
2116
application note 19).
2117
FIA_UAU.6/PACE_EAC2PP
2118
Re-authenticating of Terminal by the TOE
2119
Hierarchical to: No other components
2120
Dependencies: No dependencies
2121
FIA_UAU.6.1/PACE_EAC2PP
2122
The TSF shall re-authenticate the user under the conditions each command sent to the
2123
TOE after successful run of the PACE protocol shall be verified as being sent by the PACE
2124
terminal.123
2125
6.1.2.2. SFRs for EAC1-protected data
2126
• FIA_UID.1/PACE_EAC1PP
2127
• FIA_UAU.1/PACE_EAC1PP
2128
• FIA_UAU.4/PACE_EAC1PP
2129
• FIA_UAU.5/PACE_EAC1PP
2130
• FIA_UAU.6/PACE_EAC1PP
2131
(equivalent to FIA_UAU.6/PACE_EAC2PP, but listed here for the sake of completeness)
2132
• FIA_UAU.6/EAC_EAC1PP
2133
• FIA_API.1/EAC1PP
2134
• FIA_AFL.1/PACE_EAC1PP
2135
(equivalent to FIA_AFL.1/PACE_EAC2PP, but listed here for the sake of completeness)
2136
FIA_UID.1/PACE_EAC1PP
2137
Timing of identification
2138
Hierarchical to: No other components
2139
Dependencies: No dependencies
2140
FIA_UID.1.1/PACE_EAC1PP
2141
The TSF shall allow:
2142
123 [assignment: list of conditions under which re-authentication is required]
IDentity Applet v3.4/eIDAS Security Target
Page 107 of 191
1. to establish the communication channel,
2143
2. carrying out the PACE Protocol according to [7],
2144
3. to read the Initialization Data if it is not disabled by TSF according to
2145
FMT_MTD.1/INI_DIS FMT_MTD.1/INI_DIS_EAC1PP
2146
4. to carry out the Chip Authentication Protocol v.1 according to [16] or the Chip
2147
Authentication mapping (PACE-CAM) according to [9].
2148
5. to carry out the Terminal Authentication Protocol v.1 according to [16] resp.
2149
according to [9] if PACE-CAM is used. 124
2150
6. none125
.
2151
on behalf of the user to be performed before the user isidentified.
2152
FIA_UID.1.2/PACE_EAC1PP
2153
The TSF shall require each user to be successfully identified before allowing any other
2154
TSF-mediated actions on behalf of that user.
2155
54. Application note (from ST author)
2156
The SFR is refined here in order for the TSF to additionally provide the PACE-CAM protocol
2157
by referencing [9]. PACE-CAM combines PACE and Chip Authentication 1 for faster execution
2158
times. Hence, a TOE meeting the original requirement also meets the refined requirement.
2159
55. Application note (taken from [5], application note 20)
2160
The SFR FIA_UID.1/PACE in [5] covers the definition in [13] and extends it by EAC aspect 4.
2161
This extension does not conflict with the strict conformance to [13].
2162
56. Application note (taken from [5], application note 21)
2163
In the Phase 2 “Manufacturing” the Manufacturer is the only user role known to the TOE which
2164
writes the Initialization Data and/or Pre-personalisation Data in the audit records of the IC. The
2165
electronic document manufacturer may create the user role Personalisation Agent for transition
2166
from Phase 2 to Phase 3 “Personalisation of the Electronic Document”. The users in role
2167
Personalisation Agent identify themselves by means of selecting the authentication key. After
2168
personalisation in the Phase 3 the PACE domain parameters, the Chip Authentication data
2169
and Terminal Authentication Reference Data are written into the TOE. The Inspection System
2170
is identified as default user after power up or reset of the TOE i.e. the TOE will run the PACE
2171
protocol, to gain access to the Chip Authentication Reference Data and to run the Chip
2172
Authentication Protocol Version 1. After successful authentication of the chip the terminal may
2173
identify itself as (i) EAC1 terminal by selection of the templates for the Terminal Authentication
2174
Protocol Version 1 or (ii) if necessary and available by authentication as Personalisation Agent
2175
(using the Personalisation Agent Key).
2176
57. Application note (taken from [5], application note 22)
2177
124 [assignment: list of TSF-mediated actions]
125 [assignment: list of TSF-mediated actions]
IDentity Applet v3.4/eIDAS Security Target
Page 108 of 191
User identified after a successfully performed PACE protocol is a terminal. Please note that
2178
neither CAN nor MRZ effectively represent secrets, but are restricted revealable; i.e. it is either
2179
the electronic document holder itself or an authorised other person or device (PACE terminal).
2180
58. Application note (taken from [5], application note 23)
2181
In the life-cycle phase ‘Manufacturing’ the Manufacturer is the only user role known to the TOE.
2182
The Manufacturer writes the Initialisation Data and/or Pre-personalisation Data in the audit
2183
records of the IC.
2184
Please note that a Personalisation Agent acts on behalf of the electronic document Issuer
2185
under his and CSCA and DS policies. Hence, they define authentication procedure(s) for
2186
Personalisation Agents. The TOE must functionally support these authentication procedures
2187
being subject to evaluation within the assurance components ALC_DEL.1 and AGD_PRE.1.
2188
The TOE assumes the user role ‘Personalisation Agent’, when a terminal proves the respective
2189
Terminal Authorisation Level as defined by the related policy (policies).
2190
59. Application note (from ST author)
2191
The refinement was necessary to ensure unified terminology usage of SFRs.
2192
FIA_UAU.1/PACE_EAC1PP
2193
Timing of authentication
2194
Hierarchical to: No other components
2195
Dependencies: FIA_UID.1 Timing of identification fulfilled by
2196
FIA_UID.1/PACE_EAC1PP
2197
FIA_UAU.1.1/PACE_EAC1PP
2198
The TSF shall allow:
2199
1. to establish the communication channel,
2200
2. carrying out the PACE Protocol according to [7],
2201
3. to read the Initialization Data if it is not disabled by TSF according to
2202
FMT_MTD.1/INI_DIS FMT_MTD.1/INI_DIS_EAC1PP ,
2203
4. to identify themselves by selection of the authentication key
2204
5. to carry out the Chip Authentication Protocol Version 1 according to [16]
2205
6. to carry out the Terminal Authentication Protocol Version 1 according to [16]126
2206
7. to carry out the Active Authetnication Mechanism according to [9]127
2207
on behalf of the user to be performed before the user is authenticated.
2208
126 [assignment: list of TSF-mediated actions]
127 [assignment: list of TSF-mediated actions]
IDentity Applet v3.4/eIDAS Security Target
Page 109 of 191
FIA_UAU.1.2/PACE_EAC1PP
2209
The TSF shall require each user to be successfully authenticated before allowing any other
2210
TSF-mediated actions on behalf of that user.
2211
60. Application note (taken from [5], application note 24)
2212
The SFR FIA_UAU.1/PACE_EAC1PP in the current ST covers the definition in [13] and
2213
extends it by EAC aspect 5. This extension does not conflict with the strict conformance to
2214
[13].
2215
61. Application note (taken from [5], application note 25)
2216
The user authenticated after a successfully performed PACE protocol is a terminal. Please
2217
note that neither CAN nor MRZ effectively represent secrets but are restricted revealable; i.e.
2218
it is either the electronic document holder itself or an authorised another person or device
2219
(PACE terminal).
2220
If PACE was successfully performed, secure messaging is started using the derived session
2221
keys (PACE-KMAC, PACE-KEnc), cf. FTP_ITC.1/PACE_EAC1PP.
2222
62. Application note (from ST author)
2223
The refinement was necessary to ensure unified terminology usage of SFRs.
2224
FIA_UAU.4/PACE_EAC1PP
2225
Single-use authentication mechanisms - Single-use authentication of the Terminal by the TOE
2226
Hierarchical to: No other components
2227
Dependencies: No dependencies
2228
FIA_UAU.4.1/PACE_EAC1PP
2229
The TSF shall prevent reuse of authentication data related to
2230
1. PACE Protocol according to [7],
2231
2. Authentication Mechanism based on Triple-DES or AES128
2232
3. Terminal Authentication Protocol v.1 according to [16].129
2233
4. Active Authentication protocol according to [7], [9]
2234
63. Application note (taken from [5], application note 26)
2235
The SFR FIA_UAU.4.1/PACE_EAC1PP in the current ST covers the definition in [13] and
2236
extends it by the EAC aspect 3. This extension does not conflict with the strict conformance to
2237
[13]. The generation of random numbers (random nonce) used for the authentication protocol
2238
128 [selection: Triple-DES, AES or other approved algorithms]
129 [assignment: identified authentication mechanism(s)]
IDentity Applet v3.4/eIDAS Security Target
Page 110 of 191
(PACE) and Terminal Authentication as required by FIA_UAU.4/PACE_EAC1PP is required
2239
by FCS_RND.1 from [13].
2240
64. Application note (taken from [5], application note 27)
2241
The authentication mechanisms may use either a challenge freshly and randomly generated
2242
by the TOE to prevent reuse of a response generated by a terminal in a successful
2243
authentication attempt. However, the authentication of Personalisation Agent may rely on other
2244
mechanisms ensuring protection against replay attacks, such as the use of an internal counter
2245
as a diversifier.
2246
65. Application note (ST author)
2247
The refinement was necessary because the authentication data (nonce) is must not be reused
2248
during Active Authentication protocol according to [9].
2249
FIA_UAU.5/PACE_EAC1PP
2250
Multiple authentication mechanisms
2251
Hierarchical to: No other components
2252
Dependencies: No dependencies
2253
FIA_UAU.5.1/PACE_EAC1PP
2254
The TSF shall provide
2255
1. PACE Protocol according to [7] and PACE-CAM protocol according to [9]
2256
2. Passive Authentication according to [8]
2257
3. Secure messaging in MAC-ENC mode according to [7].
2258
4. Symmetric Authentication Mechanism based on Triple-DES or AES130
2259
5. Terminal Authentication Protocol v.1 according to [16],131
2260
to support user authentication
2261
FIA_UAU.5.2/PACE_EAC1PP
2262
The TSF shall authenticate any user’s claimed identity according to the following rules:
2263
1. Having successfully run the PACE protocol the TOE accepts only received
2264
commands with correct message authentication code sent by means of secure
2265
messaging with the key agreed with the terminal by means of the PACE protocol.
2266
130 [selection: Triple-DES, AES or other approved algorithms]
131 [assignment: list of multiple authentication mechanism]
IDentity Applet v3.4/eIDAS Security Target
Page 111 of 191
2. The TOE accepts the authentication attempt as Personalisation Agent by the
2267
Symmetric Authentication (Device authentication) according to [30]132
2268
3. After run of the Chip Authentication Protocol Version 1 the TOE accepts only
2269
received commands with correct message authentication code sent by means of
2270
secure messaging with key agreed with the terminal by means of the Chip
2271
Authentication Mechanism v1.
2272
4. The TOE accepts the authentication attempt by means of the Terminal
2273
Authentication Protocol v.1 only if the terminal uses the public key presented during
2274
the Chip Authentication Protocol v.1 and the secure messaging established by the
2275
Chip Authentication Mechanism v.1. or if the terminal uses the public key
2276
presented during PACE-CAM and the secure messaging established during
2277
PACE.133
2278
5. none134
2279
66. Application note (from ST author)
2280
The SFR is refined here in order for the TSF to additionally provide the PACE-CAM protocol
2281
by referencing [9]. PACE-CAM combines PACE and Chip Authentication 1 for faster execution
2282
times. Hence, a TOE meeting the original requirement also meets the refined requirement.
2283
67. Application note (taken from [5], application note 28)
2284
The SFR FIA_UAU.5.1/PACE_EAC1PP in the current ST covers the definition in [13] and
2285
extends it by EAC aspects 4), 5), and 6). The SFR FIA_UAU.5.2/PACE_EAC1PP in the current
2286
ST covers the definition in [13] and extends it by EAC aspects 2), 3), 4) and 5). These
2287
extensions do not conflict with the strict conformance to [13].
2288
FIA_UAU.6/EAC_EAC1PP
2289
Re-authenticating – Re-authenticating of Terminal by the TOE
2290
Hierarchical to: No other components
2291
Dependencies: No dependencies
2292
FIA_UAU.6.1/EAC_EAC1PP
2293
The TSF shall re-authenticate the user under the conditions each command sent to the
2294
TOE after successful run of the Chip Authentication Protocol Version 1 shall be verified as
2295
being sent by the Inspection System.135
2296
132 [selection: the Authentication Mechanism with Personalisation Agent Key(s)]
133 [assignment: rules describing how the multiple authentication mechanisms provide authentication ]
134 [assignment: rules describing how the multiple authentication mechanisms provide authentication]
135 [assignment: list of conditions under which re-authentication is required]
IDentity Applet v3.4/eIDAS Security Target
Page 112 of 191
68. Application note (taken from [5], application note 29)
2297
The Password Authenticated Connection Establishment and the Chip Authentication Protocol
2298
specified in [8] include secure messaging for all commands exchanged after successful
2299
authentication of the Inspection System. The TOE checks by secure messaging in MAC_ENC
2300
mode each command based on a corresponding MAC algorithm whether it was sent by the
2301
successfully authenticated terminal (see FCS_COP.1/CA_MAC_EAC1PP for further details).
2302
The TOE does not execute any command with incorrect message authentication code.
2303
Therefore the TOE re-authenticates the user for each received command and accepts only
2304
those commands received from the previously authenticated user.
2305
FIA_API.1/EAC1PP
2306
Authentication Proof of Identity
2307
Hierarchical to: No other components
2308
Dependencies: No dependencies
2309
FIA_API.1.1/EAC1PP
2310
The TSF shall provide a Chip Authentication Protocol Version 1 according to [16]136
to
2311
prove the identity of the TOE.137
2312
69. Application note (taken from [5], application note 30)
2313
This SFR requires the TOE to implement the Chip Authentication Mechanism v.1 specified in
2314
[16]. The TOE and the terminal generate a shared secret using the Diffie-Hellman Protocol
2315
(DH or ECDH) and two session keys for secure messaging in ENC_MAC mode according to
2316
[8]. The terminal verifies by means of secure messaging whether the electronic document’s
2317
chip was able or not to run his protocol properly using its Chip Authentication Private Key
2318
corresponding to the Chip Authentication Key (EF.DG14).
2319
The following SFR is newly defined in this ST and addresses the PACE-CAM protocol.
2320
FIA_API.1/PACE_CAM
2321
Authentication Proof of Identity
2322
Hierarchical to: No other components
2323
Dependencies: No dependencies
2324
FIA_API.1.1/PACE_CAM
2325
The TSF shall provide a protocol PACE-CAM [9]138
to prove the identity of the TOE.139
2326
136 [assignment: authentication mechanism]
137 [assignment: authorized user or role]
138 [assignment: authentication mechanism]
139 [assignment: authorized user or role, or of the TOE itself]
IDentity Applet v3.4/eIDAS Security Target
Page 113 of 191
The following SFR is newly defined in this ST and addresses the Active Authentication
2327
protocol:
2328
FIA_API.1/AA
2329
Authentication Proof of Identity
2330
Hierarchical to: No other components
2331
Dependencies: No dependencies
2332
FIA_API.1.1/AA
2333
The TSF shall provide a Active Authentication protocol according to [7] [9]140
to prove the
2334
identity of the TOE.141
2335
The following SFRs are imported due to claiming [14]. They concern access mechanisms for
2336
an eSign application, if available.
2337
• FIA_UID.1/SSCDPP
2338
• FIA_AFL.1/SSCDPP
2339
FIA_UID.1/SSCDPP
2340
Timing of identification
2341
Hierarchical to: No other components
2342
Dependencies: No dependencies
2343
FIA_UID.1.1/SSCDPP
2344
The TSF shall allow
2345
1. Self-test according to FPT_TST.1 FPT_TST.1/SSCDPP,
2346
2. none142
2347
on behalf of the user to be performed before the user is identified
2348
FIA_UID.1.2/SSCDPP
2349
140 [assignment: authentication mechanism]
141 [assignment: authorized user or role, or of the TOE itself ]
142 [assignment: list of additional TSF-mediated actions]
IDentity Applet v3.4/eIDAS Security Target
Page 114 of 191
The TSF shall require each user to be successfully identified before allowing any other
2350
TSF-mediated actions on behalf of that user.
2351
70. Application note (taken from [14], application note 11)
2352
Applied.
2353
71. Application note (from ST author)
2354
The refinement was necessary to ensure unified terminology usage of SFRs.
2355
FIA_AFL.1/SSCDPP
2356
Authentication failure handling
2357
Hierarchical to: No other components
2358
Dependencies: FIA_UAU.1 Timing of Authentication fulfilled by
2359
FIA_UAU.1/SSCDPP
2360
FIA_AFL.1.1/SSCDPP
2361
The TSF shall detect when an administrator configurable positive integer within 3-15143
2362
unsuccessful authentication attempts occur related to consecutive failed authentication
2363
attempts.144
2364
FIA_AFL.1.2/SSCDPP
2365
When the defined number of unsuccessful authentication attempts has been met145
, the
2366
TSF shall block RAD146
.
2367
72. Application note (taken from [14], application note 13)
2368
Applied
2369
6.1.2.3. SFRs for eSign-applications
2370
FIA_UAU.1/SSCDPP
2371
Timing of authentication
2372
Hierarchical to: No other components
2373
143 [selection: [assignment: positive integer number], an administrator configurable positive integer within
[assignment: range of acceptable values]]
144 [assignment: list of authentication events]
145 [selection: met ,surpassed]
146 [assignment: list of actions]
IDentity Applet v3.4/eIDAS Security Target
Page 115 of 191
Dependencies: FIA_UID.1 Timing of identification: fulfilled by
2374
FIA_UID.1/SSCDPP
2375
FIA_UAU.1.1/SSCDPP
2376
The TSF shall allow
2377
1. self test according to FPT_TST.1/SSCD FPT_TST.1/SSCDPP,
2378
2. identification of the user by means of TSF required by FIA_UID.1/SSCD
2379
FIA_UID.1/SSCDPP,
2380
3. establishing a trusted channel between CGA and the TOE by means of TSF
2381
required by FPT_ITC.1/CA_EAC2 FTP_ITC.1/CA_EAC2PP,
2382
4. establishing a trusted channel between HID and the TOE by means of TSF
2383
required by FPT_ITC.1/CA_EAC2 FTP_ITC.1/CA_EAC2PP,
2384
5. none147
2385
on behalf of the user to be performed before the user is authenticated.
2386
FIA_UAU.1.2/SSCDPP
2387
The TSF shall require each user to be successfully authenticated before allowing any other
2388
TSF-mediated actions on behalf of that user.
2389
73. Application note (from ST author)
2390
The refinement was necessary to ensure unified terminology usage of SFRs.
2391
6.1.3. Class FDP
2392
Multiple iterations of FDP_ACF.1 exist from imported PPs to define the access control SFPs
2393
for (common) user data, EAC1-protected user data, and EAC2-protected user data. The
2394
access control SFPs defined in FDP_ACF.1/EAC1PP from [5] and FDP_ACF.1/EAC2PP from
2395
[6] are unified in [20] to one single FDP_ACF.1/TRM, whereas the several iterations of
2396
FDP_ACF.1 from [14] stand separate. [20] takes FDP_ACF.1/EAC2PP as a base definition of
2397
functional elements, and it is refined in a way that it is compatible with FDP_ACF.1/EAC1PP.
2398
Hence highlighting refers to changes w.r.t. to FDP_ACF.1/EAC2PP. In the application note
2399
below, how FDP_ACF.1/EAC1PP is covered as well is explained.
2400
147 [assignment: list of additional TSF-mediated actions]
IDentity Applet v3.4/eIDAS Security Target
Page 116 of 191
Concerning FDP_ACF.1/TRM in [20] and the several iterations FDP_ACF.1 from [14], [20]
2401
remarks that FDP_ACF.1/TRM also concerns data and objects for signature generation. Note
2402
however, that FDP_ACF.1/TRM requires that prior to granting access to the signature
2403
application, in which the access controls defined in [14] apply, an EAC2 terminal and the
2404
Electronic Document Holder need to be authenticated. Hence, no inconsistency exists.
2405
FDP_ACF.1/TRM
2406
Security attribute based access control – Terminal Access
2407
Hierarchical to: No other components
2408
Dependencies: FDP_ACC.1 Subset access control fulfilled by
2409
FDP_ACC.1/TRM_EAC1PP and
2410
FDP_ACC.1/TRM_EAC2PP
2411
FMT_MSA.3 Static attribute initialization not fulfilled, but
2412
justified:
2413
The access control TSF according to FDP_ACF.1/TRM
2414
uses security attributes having been defined during the
2415
personalization and fixed over the whole life time of the
2416
TOE. No management of these security attributes (i.e.
2417
SFR FMT_MSA.1 and FMT_MSA.3) is necessary here.
2418
FDP_ACF.1.1/TRM
2419
The TSF shall enforce the Access Control SFP148
to objects based on the following:
2420
1) Subjects:
2421
a) Terminal,
2422
b) PACE terminal,
2423
c) EAC2 terminal Authentication Terminal and Signature Terminal according to
2424
[17]149
,
2425
d) EAC1 terminal;150
2426
2) Objects:
2427
148 [assignment: access control SFP]
149 [assignment: list of EAC2 terminal types]
150 [assignment: list of subjects and objects controlled under the indicated SFP, and, for each, the SFP-relevant
security attributes, or name groups of SFP-relevant security attributes] (added using open assignment of [6])
IDentity Applet v3.4/eIDAS Security Target
Page 117 of 191
a) all user data stored in the TOE; including sensitive EAC1-protected user
2428
data, and sensitive EAC2-protected user data.
2429
b) all TOE intrinsic secret (cryptographic) data
2430
3) Security attributes:
2431
a) Terminal Authorization Level (access rights)
2432
b) Authentication status of the Electronic Document Holder as a signatory (if an
2433
eSign application is included).151152
2434
FDP_ACF.1.2/TRM
2435
The TSF shall enforce the following rules to determine if an operation among controlled
2436
subjects and controlled objects is allowed:
2437
A PACE terminal is allowed to read data objects from FDP_ACF.1/TRM after successful
2438
PACE authentication according to [17] and/or [7], as required by FIA_UAU.1/PACE
2439
FIA_UAU.1/PACE_EAC2PP or FIA_UAU.1/PACE_EAC1PP.153
2440
FDP_ACF.1.3/TRM
2441
The TSF shall explicitly authorize access of subjects to objects based on the following
2442
additional rules: none.154
2443
FDP_ACF.1.4/TRM
2444
The TSF shall explicitly deny access of subjects to objects based on the following
2445
additional rules:
2446
1. Any terminal not being authenticated as a PACE terminal or an EAC2 terminal or
2447
an EAC1 terminal is not allowed to read, to write, to modify, or to use any user
2448
data stored on the electronic document.155
2449
2. Terminals not using secure messaging are not allowed to read, write, modify, or
2450
use any data stored on the electronic document.
2451
151 [assignment: list of subjects and objects controlled under the indicated SFP, and, for each, the SFP-relevant
security attributes, or name groups of SFP-relevant security attributes] (added using open assignment of [6])
152 [assignment: list of subjects and objects controlled under the indicated SFP, and, for each, the SFP-relevant
security attributes, or name groups of SFP-relevant security attributes] (all bullets in FDP_ACF.1.1/TRM w.r.t. [2])
153 [assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
154
[assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]
155 note that authentication of an EAC1 or EAC2 terminal to a TOE in certified mode implies a prior run of PACE.
IDentity Applet v3.4/eIDAS Security Target
Page 118 of 191
3. No subject is allowed to read ‘Electronic Document Communication Establishment
2452
Authorization Data’ stored on the electronic document
2453
4. No subject is allowed to write or modify ‘Secret Electronic Document Holder
2454
Authentication Data’ stored on the electronic document, except for PACE terminals
2455
or EAC2 terminals executing PIN management based on the following rules:
2456
1. CAN change
2457
2. Change PIN
2458
3. Resume PIN
2459
4. Unblock PIN
2460
5. Activate PIN
2461
6. Deactivate PIN according to [17].156
2462
5. No subject is allowed to read, write, modify, or use the private Restricted
2463
Identification key(s) and Chip Authentication key(s) stored on the electronic
2464
document.
2465
6. Reading, modifying, writing, or using Sensitive User Data that are protected only
2466
by EAC2, is allowed only to EAC2 terminals using the following mechanism:
2467
The TOE applies the EAC2 protocol (cf. FIA_UAU.5
2468
FIA_UAU.5/PACE_EAC2PP) to determine access rights of the terminal
2469
according to [17]. To determine the effective authorization of a terminal, the
2470
chip must calculate a bitwise Boolean ’and’ of the relative authorization
2471
contained in the CHAT of the Terminal Certificate, the referenced DV
2472
Certificate, and the referenced CVCA Certificate, and additionally the confined
2473
authorization sent as part of PACE. Based on that effective authorization and
2474
the terminal type drawn from the CHAT of the Terminal Certificate, the TOE
2475
shall grant the right to read, modify or write Sensitive User Data, or perform
2476
operations using these Sensitive User Data.
2477
7. No subject is allowed to read, write, modify or use the data objects 2b) of
2478
FDP_ACF.1/TRM.
2479
8. No subject is allowed to read Sensitive User Data that are protected only by EAC1,
2480
except an EAC1 terminal (OID inspection system) after EAC1, cf.
2481
FIA_UAU.1/EAC1 FIA_UAU.1/PACE_EAC1PP, that has a corresponding relative
2482
authorization level. This includes in particular EAC1-protected user data DG3 and
2483
DG4 from an ICAO-compliant ePass application, cf. [16] and [8].
2484
156 [assignment: list of rules for PIN management chosen from [17]]
IDentity Applet v3.4/eIDAS Security Target
Page 119 of 191
9. If Sensitive User Data is protected both by EAC1 and EAC2, no subject is allowed
2485
to read those data except EAC1 terminals or EAC2 terminals that access these
2486
data according to rule 6 or rule 8 above.
2487
10. Nobody is allowed to read the private signature key(s).157
2488
74. Application note (from ST author)
2489
The [20] uses the ‘Electronic Document Communication Establishment Authorization Data’
2490
expression in 3.1.1.2 Secondary Assets and “Communication Establishment Authorization
2491
Data” in FDP_ACF.1.4/TRM 3. In order to provide consistency in our ST, we use only the
2492
Electronic Document Communication Establishment Authorization Data.
2493
75. Application note (taken from [20], application note 11)
2494
The above definition is based on FDP_ACF.1/TRM_EAC2PP. We argue that it covers
2495
FDP_ACF.1/TRM_EAC1PP as well. Subject 1b and 1d are renamed here from
2496
FDP_ACF.1.1/TRM_EAC1PP according to Table 1 Objects in 2), in particular the term EAC1-
2497
protected user data, subsume all those explicitly enumerated in FDP_ACF.1.1/TRM_EAC1PP.
2498
Also, the security attribute 3a) Terminal Authorization Level here subsumes the explicitly
2499
enumerated attributes 3a) and 3b) of FDP_ACF.1.1/TRM_EAC1PP, but are semantically the
2500
same. Since in addition EAC2 protected data are stored in the TOE of this ST, additional
2501
subjects, objects and security attributes are listed here. However, since they apply to data with
2502
a different protection mechanism (EAC2), strict conformance is not violated.
2503
FDP_ACF.1.2/TRM uses the renaming of Table 1 , and references in addition [17]. However
2504
the references are compatible as justified in [6], yet both are mentioned here since [17] is the
2505
primary norm for an eID application, whereas [7] is normative for an ICAO compliant ePass
2506
application. Investigating the references reveals that access to data objects defined in
2507
FDP_ACF.1.1/TRM must be granted if these data are neither EAC1-protected, nor EAC2-
2508
protected.
2509
FDP_ACF.1.3/TRM is the same as in FDP_ACF.1.3/TRM_EAC2PP.
2510
References are changed in FDP_ACF.1.2/TRM_EAC1PP. It is already justified in [6] that
2511
definitions in [17] and [8] are compatible.
2512
FDP_ACF.1.3/TRM is taken over from [5] and [6] (same formulation in both).
2513
Rules 1 and 2 of FDP_ACF.1.4/TRM_EAC1PP in [5] are covered by their counterparts rule 1
2514
and rule 2 here. Rules 3 and 4, and rule 6 of FDP_ACF.1.4/TRM_EAC1PP in [5] are combined
2515
here to rule 8, where terminals need the corresponding CHAT to read data groups. Rule 5 of
2516
[5] is here equivalent to rule 7. None of this conflict with strict conformance to [5]. Note that
2517
adding additional rules compared to FDP_ACF.1.4/TRM_EAC1PP here can never violate strict
2518
conformance, as these are rules that explicitly deny access of subjects to objects. Hence
2519
security is always increased.
2520
The above definition also covers FDP_ACF.1.1/TRM_EAC2PP and extends it by additional
2521
subjects and objects. Sensitive User Data in the definition of FDP_ACF.1.1/TRM_EAC2PP are
2522
here EAC2-protected Sensitive User Data. EAC1-protected data are added here by
2523
157 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
IDentity Applet v3.4/eIDAS Security Target
Page 120 of 191
refinement. Since the protection level and mechanisms w.r.t. to EAC2-protected data do not
2524
change, strict conformance is not violated.
2525
FDP_ACF.1.2/TRM_EAC2PP and FDP_ACF.1.3/TRM_EAC2PP are equivalent to the current
2526
definition.
2527
Rules 8, 9 and 10 are added here by open assignment from [6]. None of these conflicts with
2528
strict conformance.
2529
The dependency of this SFR is met by FDP_ACC.1/TRM_EAC1PP and
2530
FDP_ACC.1/TRM_EAC2PP. Note that the SFR in [5] applies the assignment operation,
2531
whereas in [6] (by referencing [13]) the assignment is left open. Hence, they are compatible.
2532
We remark that in order to restrict the access to user data as defined in the SFR
2533
FDP_ACC.1/TRM_EAC1PP, clearly access to objects 2b) of FDP_ACF.1.1/TRM must be
2534
restricted as well according to the SFP, otherwise access to user data is impossible to enforce.
2535
76. Application note (from ST author)
2536
The refinements were necessary to ensure unified terminology usage of SFRs.
2537
The following SFRs are imported due to claiming [6]. They concern access control mechanisms
2538
related to EAC2-protected data.
2539
• FDP_ACC.1/TRM_EAC2PP
2540
This SFR is equivalent to/covered by FDP_ACC.1/TRM_EAC1PP; cf the 75. Application note
2541
(taken from [20], application note 11).
2542
• FDP_ACF.1/TRM_EAC2PP
2543
This is SFR is equivalent to/covered by FDP_ACF.1/TRM.
2544
• FDP_RIP.1/EAC2PP
2545
• FDP_UCT.1/TRM_EAC2PP
2546
• FDP_UIT.1/TRM_EAC2PP
2547
FDP_ACC.1/TRM_EAC2PP
2548
Subset access control – Terminal Access
2549
Hierarchical to: No other components
2550
Dependencies: FDP_ACF.1 Security attribute based access control:
2551
fulfilled by FDP_ACF.1/TRM
2552
FDP_ACC.1.1/TRM_EAC2PP
2553
IDentity Applet v3.4/eIDAS Security Target
Page 121 of 191
The TSF shall enforce the Access Control SFP158
on terminals gaining access to the User
2554
Data stored in the travel document electronic document159
and none160
.
2555
77. Application note (taken from [20])
2556
This SFR is equivalent to/covered by FDP_ACC.1/TRM_EAC1PP; cf.75. Application note
2557
(taken from [20], application note 11).
2558
78. Application note (from ST author)
2559
The refinement was necessary to ensure unified terminology usage as described in Table 1
2560
Overview of identifiers of current ST and PPs.
2561
FDP_RIP.1/EAC2PP
2562
Subset residual information protection
2563
Hierarchical to: No other components
2564
Dependencies: No dependencies
2565
FDP_RIP.1.1_EAC2PP
2566
The TSF shall ensure that any previous information content of a resource is made
2567
unavailable upon the deallocation of the resource from161
the following objects:
2568
1. Session keys (PACE-KMAC, PACE-KEnc), (CA2-KMAC, CA2-KEnc) (immediately after
2569
closing related communication session),
2570
2. the ephemeral private key ephem-SKPICC-PACE (by having generated a DH shared
2571
secret K),
2572
3. Secret Electronic Document Holder Authentication Data, e.g. PIN and/or PUK
2573
(when their temporarily stored values are not used any more )162,
2574
4. none.163
2575
79. Application note (taken from [6], application note 30)
2576
The functional family FDP_RIP possesses such a general character, that it is applicable not
2577
only to user data (as assumed by the class FDP), but also to TSF-Data; in this respect it is
2578
similar to the functional family FPT_EMS. Applied to cryptographic keys, FDP_RIP.1/EAC2PP
2579
requires a certain quality metric (any previous information content of a resource is made
2580
158 [assignment: access control SFP]
159 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
160 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
161 [selection: allocation of the resource to, deallocation of the resource from]
162 [assignment: list of objects]
163 [assignment: list of objects]
IDentity Applet v3.4/eIDAS Security Target
Page 122 of 191
unavailable) for key destruction in addition to FCS_CKM.4/EAC2PP that merely requires to
2581
ensure key destruction according to a method/standard.
2582
Application note 80 (from ST author)
2583
The above SFR is slightly refined from [20] in order not to confuse Chip Authentication 1 with
2584
Chip Authentication 2.
2585
FDP_UCT.1/TRM_EAC2PP
2586
Basic data exchange confidentiality – MRTD
2587
Hierarchical to: No other components
2588
Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1
2589
Trusted path] fulfilled by FTP_ITC.1/PACE_EAC2PP
2590
[FDP_ACC.1 Subset access control, or FDP_IFC.1
2591
Subset information flow control] fulfilled by
2592
FDP_ACC.1/TRM_EAC2PP
2593
FDP_UCT.1.1/TRM_EAC2PP
2594
The TSF shall enforce the Access Control SFP164
to be able to transmit and receive165
2595
user data in a manner protected from unauthorised disclosure.
2596
FDP_UIT.1/TRM_EAC2PP
2597
TRM Data exchange integrity
2598
Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1
2599
Trusted path] fulfilled by FTP_ITC.1/PACE_EAC2PP
2600
[FDP_ACC.1 Subset access control, or FDP_IFC.1
2601
Subset information flow control] fulfilled by
2602
FDP_ACC.1/TRM_EAC2PP
2603
FDP_UIT.1.1/TRM_EAC2PP
2604
The TSF shall enforce the Access Control SFP166
to be able to transmit and receive167
2605
user data in a manner protected from modification, deletion, insertion and replay168
errors.
2606
164 [assignment: access control SFP(s) and/or information flow control SFP(s)]
165 [selection: transmit, receive]
166 [assignment: access control SFP(s) and/or information flow control SFP(s)]
167 [selection: transmit, receive]
168 [selection: modification, deletion, insertion, replay]
IDentity Applet v3.4/eIDAS Security Target
Page 123 of 191
FDP_UIT.1.2/TRM_EAC2PP
2607
The TSF shall be able to determine on receipt of user data, whether modification, deletion,
2608
insertion and replay169
has occurred.
2609
The following SFRs are imported due to claiming [5]. They concern access control mechanisms
2610
related to EAC1-protected data.
2611
• FDP_ACC.1/TRM_EAC1PP
2612
The above is equivalent FDP_ACC.1/TRM_EAC2PP, since EF.SOD (cf. FDP_ACC.1/TRM in
2613
[5]) can be considered user data.; cf. also the application note below FDP_ACF.1/TRM.
2614
• FDP_ACF.1/TRM_EAC1PP
2615
The above is covered by FDP_ACF.1/TRM; cf. Application Note there.
2616
• FDP_RIP.1/EAC1PP
2617
• FDP_UCT.1/TRM_EAC1PP
2618
(equivalent to FDP_UCT.1/TRM_EAC2PP, but listed here for the sake of completeness)
2619
• FDP_UIT.1/TRM_EAC1PP
2620
(equivalent to FDP_UIT.1/TRM_EAC2PP, but listed here for the sake of completeness)
2621
FDP_RIP.1/EAC1PP
2622
Subset residual information protection
2623
Hierarchical to: No other components
2624
Dependencies: No dependencies
2625
FDP_RIP.1.1/EAC1PP
2626
The TSF shall ensure that any previous information content of a resource is made
2627
unavailable upon the deallocation of the resource from170
the following objects:
2628
1. Session Keys (immediately after closing related communication session) ,
2629
169 [selection: modification, deletion, insertion, replay]
170 [selection: allocation of the resource to, deallocation of the resource from]
IDentity Applet v3.4/eIDAS Security Target
Page 124 of 191
2. the ephemeral private key ephem-SKPICC-PACE (by having generated a DH shared
2630
secret K171
),172
2631
3. none..173
2632
The following SFRs are imported due to claiming [14]. They concern access control
2633
mechanisms of an eSign application.
2634
• FDP_ACC.1/SCD/SVD_Generation_SSCDPP
2635
• FDP_ACF.1/SCD/SVD_Generation_SSCDPP
2636
• FDP_ACC.1/SVD_Transfer_SSCDPP
2637
• FDP_ACF.1/SVD_Transfer_SSCDPP
2638
• FDP_ACC.1/Signature-creation_SSCDPP
2639
• FDP_ACF.1/Signature-creation_SSCDPP
2640
• FDP_RIP.1/SSCDPP
2641
• FDP_SDI.2/Persistent_SSCDPP
2642
• FDP_SDI.2/DTBS_SSCDPP
2643
FDP_ACC.1/SCD/SVD_Generation_SSCDPP
2644
Subset access control
2645
Hierarchical to: No other components
2646
Dependencies: FDP_ACF.1 Security attribute based access control
2647
fulfilled by
2648
FDP_ACF.1/SCD/SVD_Generation_SSCDPP
2649
FDP_ACC.1.1/SCD/SVD_Generation_SSCDPP
2650
The TSF shall enforce the SCD/SVD Generation SFP174
on
2651
1. subjects: S.User,
2652
2. objects: SCD, SVD,
2653
3. operations: generation of SCD/SVD pair. 175
2654
FDP_ACF.1/SCD/SVD_Generation_SSCDPP
2655
Security attribute based access control
2656
171 according to [7]
172 [assignment: list of objects]
173 [assignment: list of objects]
174 [assignment: access control SFP]
175 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
IDentity Applet v3.4/eIDAS Security Target
Page 125 of 191
Hierarchical to: No other components
2657
Dependencies: FDP_ACC.1 Subset access control fulfilled by
2658
FDP_ACC.1/SCD/SVD_Generation_SSCDPP
2659
FMT_MSA.3 Static attribute initialisation fulfilled by
2660
FMT_MSA.3/SSCDPP
2661
FDP_ACF.1.1/SCD/SVD_Generation_SSCDPP
2662
The TSF shall enforce the SCD/SVD Generation SFP176
to objects based on the following:
2663
the user S.User is associated with the security attribute “SCD/SVD Management“.177
2664
FDP_ACF.1.2/SCD/SVD_Generation_SSCDPP
2665
The TSF shall enforce the following rules to determine if an operation among controlled
2666
subjects and controlled objects is allowed: S.User with the security attribute “SCD/SVD
2667
Management” set to “authorised” is allowed to generate SCD/SVD pair.178
2668
FDP_ACF.1.3/SCD/SVD_Generation_SSCDPP
2669
The TSF shall explicitly authorise access of subjects to objects based on the following
2670
additional rules: none.179
2671
FDP_ACF.1.4/SCD/SVD_Generation_SSCDPP
2672
The TSF shall explicitly deny access of subjects to objects based on the following
2673
additional rules: S.User with the security attribute “SCD/SVD management” set to “not
2674
authorised” is not allowed to generate SCD/SVD pair.180
2675
FDP_ACC.1/SVD_Transfer_SSCDPP
2676
Subset access control
2677
Hierarchical to: No other components
2678
176 [assignment: access control SFP]
177 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant
security attributes, or named groups of SFP-relevant security attributes]
178 [assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
179 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
180 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
IDentity Applet v3.4/eIDAS Security Target
Page 126 of 191
Dependencies: FDP_ACF.1 Security attribute based access control
2679
fulfilled by FDP_ACF.1/SVD_Transfer_SSCDPP
2680
FDP_ACC.1.1/SVD_Transfer_SSCDPP
2681
The TSF shall enforce the SVD Transfer SFP181
on
2682
1. subjects: S.User,
2683
2. objects: SVD
2684
3. operations: export.182
2685
FDP_ACF.1/SVD_Transfer_SSCDPP
2686
Security attribute based access control
2687
Hierarchical to: No other components
2688
Dependencies: FDP_ACC.1 Subset access control fulfilled by
2689
FDP_ACC.1/SVD_Transfer_SSCDPP
2690
FMT_MSA.3 Static attribute initialisation fulfilled by
2691
FMT_MSA.3/SSCDPP
2692
FDP_ACF.1.1/SVD_Transfer_SSCDPP
2693
The TSF shall enforce the SVD Transfer SFP183
to objects based on the following:
2694
1. the S.User is associated with the security attribute Role,
2695
2. the SVD.184
2696
FDP_ACF.1.2/SVD_Transfer_SSCDPP
2697
The TSF shall enforce the following rules to determine if an operation among controlled
2698
subjects and controlled objects is allowed: R.Admin185
is allowed to export SVD.186
2699
FDP_ACF.1.3/SVD_Transfer_SSCDPP
2700
181 [assignment: access control SFP]
182 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
183 [assignment: access control SFP]
184 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant
security attributes, or named groups of SFP-relevant security attributes]
185 [selection: R.Admin, R.Sigy]
186 [assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
IDentity Applet v3.4/eIDAS Security Target
Page 127 of 191
The TSF shall explicitly authorise access of subjects to objects based on the following
2701
additional rules: none.187
2702
FDP_ACF.1.4/SVD_Transfer_SSCDPP
2703
The TSF shall explicitly deny access of subjects to objects based on the following
2704
additional rules: none.188
2705
81. Application note (taken from [14], application note 9)
2706
Applied.
2707
FDP_ACC.1/Signature-creation_SSCDPP
2708
Subset access control
2709
Hierarchical to: No other components
2710
Dependencies: FDP_ACF.1 Security attribute based access control
2711
fulfilled by FDP_ACF.1/Signature-creation_SSCDPP
2712
FDP_ACC.1.1/Signature_Creation
2713
The TSF shall enforce the Signature Creation SFP189
on
2714
1. subjects: S.User,
2715
2. objects: DTBS/R, SCD,
2716
3. operations: signature creation.190
2717
FDP_ACF.1/Signature-creation_SSCDPP
2718
Security attribute based access control
2719
Hierarchical to: No other components
2720
Dependencies: FDP_ACC.1 Subset access control fulfilled by
2721
FDP_ACC.1/Signature-creation_SSCDPP
2722
FMT_MSA.3 Static attribute initialisation fulfilled by
2723
FMT_MSA.3/SSCDPP
2724
FDP_ACF.1.1/Signature_Creation_SSCDPP
2725
187 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
188 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
189 [assignment: access control SFP]
190 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
IDentity Applet v3.4/eIDAS Security Target
Page 128 of 191
The TSF shall enforce the Signature Creation SFP191
to objects based on the following:
2726
1. the user S.User is associated with the security attribute “Role” and
2727
2. the SCD with the security attribute “SCD Operational”.192
2728
FDP_ACF.1.2/Signature_Creation_SSCDPP
2729
The TSF shall enforce the following rules to determine if an operation among controlled
2730
subjects and controlled objects is allowed: R.Sigy is allowed to create electronic
2731
signatures for DTBS/R with SCD which security attribute “SCD operational” is set to
2732
“yes”.193
2733
FDP_ACF.1.3/Signature_Creation_SSCDPP
2734
The TSF shall explicitly authorise access of subjects to objects based on the following
2735
additional rules: none.194
2736
FDP_ACF.1.4/Signature_Creation_SSCDPP
2737
The TSF shall explicitly deny access of subjects to objects based on the following
2738
additional rules: S.User is not allowed to create electronic signatures for DTBS/R with SCD
2739
which security attribute “SCD operational” is set to “no”.195
2740
FDP_RIP.1/SSCDPP
2741
Subset residual information protection
2742
Hierarchical to: No other components
2743
Dependencies: No dependencies
2744
FDP_RIP.1.1_SSCDPP
2745
The TSF shall ensure that any previous information content of a resource is made
2746
unavailable upon the de-allocation of the resource from196
the following objects: SCD197
.
2747
191 [assignment: access control SFP]
192 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant
security attributes, or named groups of SFP-relevant security attributes]
193 [assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
194 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
195 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
196 [selection: allocation of the resource to, deallocation of the resource from]
197 [assignment: list of objects]
IDentity Applet v3.4/eIDAS Security Target
Page 129 of 191
FDP_SDI.2/Persistent_SSCDPP
2748
Stored data integrity monitoring and action
2749
Hierarchical to: FDP_SDI.1 Stored data integrity monitoring
2750
Dependencies: No dependencies
2751
FDP_SDI.2.1/Persistent_SSCDPP
2752
The TSF shall monitor user data stored in containers controlled by the TSF for integrity
2753
error198
on all objects, based on the following attributes: integrity checked stored data199
.
2754
FDP_SDI.2.2/Persistent_SSCDPP
2755
Upon detection of a data integrity error, the TSF shall
2756
1. prohibit the use of the altered data
2757
2. inform the S.Sigy about integrity error.200
2758
82. Application note (taken from [14])
2759
The [14] was defined the followings:
2760
The following data persistently stored by the TOE shall have the user data attribute "integrity
2761
checked persistent stored data":
2762
1) SCD
2763
2) SVD (if persistently stored by the TOE).
2764
The DTBS/R temporarily stored by the TOE has the user data attribute "integrity checked
2765
stored data"
2766
FDP_SDI.2/DTBS_SSCDPP
2767
Stored data integrity monitoring and action
2768
Hierarchical to: FDP_SDI.1 Stored data integrity monitoring
2769
Dependencies: No dependencies
2770
FDP_SDI.2.1/DTBS_SSCDPP
2771
198 [assignment: integrity errors]
199 [assignment: user data attributes]
200 [assignment: action to be taken]
IDentity Applet v3.4/eIDAS Security Target
Page 130 of 191
The TSF shall monitor user data stored in containers controlled by the TSF for integrity
2772
error201
on all objects, based on the following attributes: integrity checked stored DTBS.202
2773
FDP_SDI.2.2/DTBS_SSCDPP
2774
Upon detection of a data integrity error, the TSF shall
2775
1. prohibit the use of the altered data
2776
2. inform the S.Sigy about integrity error.203
2777
83. Application note (taken from [14], application note 10)
2778
The integrity of TSF data like RAD shall be protected to ensure the effectiveness of the user
2779
authentication. This protection is a specific aspect of the security architecture (cf.
2780
ADV_ARC.1).
2781
6.1.4. Class FTP
2782
The following SFRs are imported from [6].
2783
• FTP_ITC.1/PACE_EAC2PP
2784
• FTP_ITC.1/CA_EAC2PP
2785
FTP_ITC.1/PACE_EAC2PP
2786
Inter-TSF trusted channel after PACE
2787
Hierarchical to: No other components
2788
Dependencies: No dependencies
2789
FTP_ITC.1.1/PACE_EAC2PP
2790
The TSF shall provide a communication channel between itself and another trusted IT
2791
product a PACE terminal that is logically distinct from other communication channels and
2792
provides assured identification of its end points and protection of the channel data from
2793
modification or disclosure. The trusted channel shall be established by performing the
2794
PACE protocol according to [17].
2795
FTP_ITC.1.2/PACE_EAC2PP
2796
201 [assignment: list of objects]
202 [assignment: user data attributes]
203 [assignment: action to be taken]
IDentity Applet v3.4/eIDAS Security Target
Page 131 of 191
The TSF shall permit another trusted IT product a PACE terminal204
to initiate
2797
communication via the trusted channel.
2798
FTP_ITC.1.3/PACE_EAC2PP
2799
The TSF shall initiate enforce communication via the trusted channel for any data
2800
exchange between the TOE and a PACE terminal after PACE.205
2801
84. Application note (taken from [6], application note 31)
2802
The above definition refines FTP_ITC.1 from [13]. The definitions there are unclear as to what
2803
the “other trusted IT product” actually is. Since we distinguish here between trusted channels
2804
that are established once after PACE, and then then (re)established after CA2, the above
2805
refinement is necessary for clarification.
2806
FTP_ITC.1/CA_EAC2PP
2807
Inter-TSF trusted channel after CA2
2808
Hierarchical to: No other components
2809
Dependencies: No dependencies
2810
FTP_ITC.1.1/CA2_EAC2PP
2811
The TSF shall provide a communication channel between itself and another trusted IT
2812
product an EAC2 terminal that is logically distinct from other communication channels
2813
and provides assured identification of its end points and protection of the channel data
2814
from modification or disclosure. The trusted channel shall be established by
2815
performing the CA2 protocol according to [17].
2816
FTP_ITC.1.2/CA2_EAC2PP
2817
The TSF shall permit another trusted IT product an EAC2 terminal206
to initiate
2818
communication via the trusted channel.
2819
FTP_ITC.1.3/CA2_EAC2PP
2820
The TSF shall initiate enforce communication via the trusted channel for any data
2821
exchange between the TOE and an EAC2 terminal after Chip Authentication 2.207
2822
204 [selection: the TSF, another trusted IT product]
205 [assignment: list of functions for which a trusted channel is required]
206 [selection: the TSF, another trusted IT product]
207 [assignment: list of functions for which a trusted channel is required]
IDentity Applet v3.4/eIDAS Security Target
Page 132 of 191
85. Application note (taken from [6], application note 32)
2823
The trusted channel is established after successful performing the PACE protocol
2824
(FIA_UAU.1/PACE_EAC2PP), the TA2 protocol (FIA_UAU.1/EAC2_Terminal_EAC2PP) and
2825
the CA2 protocol (FIA_API.1/CA_EAC2PP). If Chip Authentication 2 was successfully
2826
performed, secure messaging is immediately restarted using the derived session keys (CA-
2827
KMAC, CA-KEnc)208. This secure messaging enforces the required properties of operational
2828
trusted channel; the cryptographic primitives being used for the secure messaging are as
2829
required by FCS_COP.1/PACE_ENC_EAC2PP and FCS_COP.1/PACE_MAC_EAC2PP.
2830
The following SFR is imported due to claiming [5]. It concerns applications with EAC1-
2831
protected data.
2832
• FTP_ITC.1/PACE_EAC1PP
2833
FTP_ITC.1/PACE_EAC1PP
2834
Inter-TSF trusted channel after PACE
2835
Hierarchical to: No other components
2836
Dependencies: No dependencies
2837
FTP_ITC.1.1/PACE_EAC1PP
2838
The TSF shall provide a communication channel between itself and another trusted IT
2839
product that is logically distinct from other communication channels and provides assured
2840
identification of its end points and protection of the channel data from modification or
2841
disclosure.
2842
FTP_ITC.1.2/PACE_EAC1PP
2843
The TSF shall permit another trusted IT product to initiate communication via the trusted
2844
channel.
2845
FTP_ITC.1.3/PACE_EAC1PP
2846
The TSF shall initiate enforce communication via the trusted channel for any data
2847
exchange between the TOE and the Terminal.209
2848
208 otherwise secure messaging is continued using the established PACE session keys, cf.
FTP_ITC.1/PACE_EAC1PP
209 [assignment: list of functions for which a trusted channel is required]
IDentity Applet v3.4/eIDAS Security Target
Page 133 of 191
6.1.5. Class FAU
2849
The following SFR is imported due to claiming [6]. It concerns applications with EAC2-
2850
protected data.
2851
• FAU_SAS.1/EAC2PP
2852
FAU_SAS.1/EAC2PP
2853
Audit storage
2854
Hierarchical to: No other components
2855
Dependencies: No dependencies
2856
FAU_SAS.1.1_EAC2PP
2857
The TSF shall provide the Manufacturer210
with the capability to store the Initialisation and
2858
Pre-Personalisation Data211
in the audit records.
2859
The following SFR is imported due to claiming [5]. It concerns applications with EAC1-
2860
protected data.
2861
• FAU_SAS.1/EAC1PP
2862
(equivalent to FAU_SAS.1/EAC2PP, but listed here for the sake of completeness)
2863
6.1.6. Class FMT
2864
FMT_SMR.1
2865
Security roles
2866
Hierarchical to: No other components
2867
Dependencies: FIA_UID.1 Timing of identification: fulfilled by
2868
FIA_UID.1/PACE_EAC1PP,
2869
FIA_UID.1/PACE_EAC2PP,
2870
FIA_UID.1/EAC2_Terminal_EAC2PP
2871
FMT_SMR.1.1
2872
210 [assignment: authorised users]
211 [assignment: list of management functions to be provided by the TSF]
IDentity Applet v3.4/eIDAS Security Target
Page 134 of 191
The TSF shall maintain the roles
2873
1. Manufacturer,
2874
2. Personalization Agent,
2875
3. Country Verifying Certification Authority (CVCA),
2876
4. Document Verifier (DV),
2877
5. Terminal,
2878
6. PACE Terminal,
2879
7. EAC2 terminal, if the eID, ePassport and/or eSign application are active,
2880
8. EAC1 terminal, if the ePassport application is active,
2881
9. Electronic Document Holder.212
2882
FMT_SMR.1.2
2883
The TSF shall be able to associate users with roles.
2884
The next SFRs are imported from [6]. They concern mainly applications with EAC2-protected
2885
data.
2886
• FMT_MTD.1/CVCA_INI_EAC2PP
2887
• FMT_MTD.1/CVCA_UPD_EAC2PP
2888
• FMT_SMF.1/EAC2PP
2889
• FMT_SMR.1/PACE_EAC2PP
2890
This SFR is combined with FMT_SMR.1/PACE_EAC1PP into to by FMT_SMR.1.
2891
• FMT_MTD.1/DATE_EAC2PP
2892
• FMT_MTD.1/PA_EAC2PP
2893
• FMT_MTD.1/SK_PICC_EAC2PP
2894
• FMT_MTD.1/KEY_READ_EAC2PP
2895
• FMT_MTD.1/Initialize_PIN_EAC2PP
2896
• FMT_MTD.1/Change_PIN_EAC2PP
2897
• FMT_MTD.1/Resume_PIN_EAC2PP
2898
• FMT_MTD.1/Unblock_PIN_EAC2PP
2899
• FMT_MTD.1/Activate_PIN_EAC2PP
2900
• FMT_MTD.3/EAC2PP
2901
212 [assignment: the authorized identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 135 of 191
• FMT_LIM.1/EAC2PP
2902
86. Application note (taken from [20], application note 12)
2903
The above SFR concerns the whole TOE, not just applications with EAC2-protected data.
2904
• FMT_LIM.2/EAC2PP
2905
87. Application note (taken from [20], application note 13)
2906
The above SFR concerns the whole TOE, not just applications with EAC2-protected data.
2907
• FMT_MTD.1/INI_ENA_EAC2PP
2908
• FMT_MTD.1/INI_DIS_EAC2PP
2909
FMT_MTD.1/CVCA_INI_EAC2PP
2910
Management of TSF data – Initialization of CVCA Certificate and Current Date
2911
Hierarchical to: No other components
2912
Dependencies: FMT_SMF.1 Specification of management functions:
2913
fulfilled by FMT_SMF.1/EAC2PP
2914
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/
2915
EAC2PP
2916
FMT_MTD.1.1/CVCA_INI_EAC2PP
2917
The TSF shall restrict the ability to write213
the
2918
1. initial CVCA Public Key ,
2919
2. meta-data of the initial CVCA Certificate as required in [17], resp. [18],
2920
3. initial Current Date,
2921
4. none214
2922
to the Personalization Agent.215216
.
2923
88. Application note (taken from [6], application note 36)
2924
213 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
214 [assignment: list of TSF data]
215 [assignment: the authorized identified roles]
216 [selection: the manufacturer, the personalization agent]
IDentity Applet v3.4/eIDAS Security Target
Page 136 of 191
The initial CVCA Public Key may be written by the manufacturer in the manufacturing phase
2925
or by the Personalization Agent in the issuing phase (cf. [17]). The initial CVCA Public Keys
2926
and their updates later on are used to verify the CVCA Link-Certificates.
2927
FMT_MTD.1/CVCA_UPD_EAC2PP
2928
Management of TSF data – Country Verifying Certification Authority
2929
Hierarchical to: No other components
2930
Dependencies: FMT_SMF.1 Specification of management functions:
2931
fulfilled by FMT_SMF.1/EAC2PP
2932
FMT_SMR.1 Security roles: fulfilled by
2933
FMT_SMR.1/PACE_EAC2PP
2934
FMT_MTD.1.1/CVCA_UPD_EAC2PP
2935
The TSF shall restrict the ability to update217
the
2936
1. CVCA Public Key (PKCVCA),
2937
2. meta-data of the CVCA Certificate as required by [17], resp. [18],218
2938
3. none219
2939
to the Country Verifying Certification Authority.220
2940
89. Application note (taken from [6], application note 37)
2941
The CVCA updates its asymmetric key pair and distributes the public key and related meta-
2942
data by means of CVCA Link-Certificates. The TOE updates its internal trust-point, if a valid
2943
CVCA Link-Certificate (cf. FMT_MTD.3/EAC2PP) is provided by the terminal (cf. [18]).
2944
FMT_SMF.1/EAC2PP
2945
Specification of Management Functions
2946
Hierarchical to: No other components
2947
Dependencies: No dependencies
2948
FMT_SMF.1.1/EAC2PP
2949
The TSF shall be capable of performing the following management functions:
2950
217 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
218 [assignment: list of TSF data]
219 [assignment: list of TSF data]
220 [assignment: the authorized identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 137 of 191
1. Initialization,
2951
2. Pre-Personalization,
2952
3. Personalization,
2953
4. Configuration,
2954
5. Resume and unblock the PIN (if any),
2955
6. Activate and deactivate the PIN (if any).221
2956
90. Application note (taken from [6], application note 33)
2957
The capability of PIN management gives additional security to the TOE.
2958
91. Application note (taken from [6], application note 34)
2959
The SFR is here refined by including mechanisms for PIN management. A TOE without PIN
2960
management functionality can only use a commonly shared secret (such as the MRZ – in the
2961
case of an ID document – or the CAN) during execution of PACE to control access to sensitive
2962
information. A PIN however must not be shared and thus can be kept secret by the user.
2963
Hence, this refinement of FMT_SMF.1/EAC2PP increases protection of user data by allowing
2964
PIN access, and thus does not violate strict conformity to [13].
2965
FMT_MTD.1/DATE_EAC2PP
2966
Management of TSF data – Current date
2967
Hierarchical to: No other components
2968
Dependencies: FMT_SMF.1 Specification of management functions
2969
fulfilled by FMT_SMF.1/EAC2PP
2970
FMT_SMR.1 Security roles fulfilled by
2971
FMT_SMR.1/PACE_EAC2PP
2972
FMT_MTD.1.1/DATE_EAC2PP
2973
The TSF shall restrict the ability to modify222
the current date223
to
2974
1. CVCA,
2975
2. Document Verifier,
2976
3. EAC2 terminal (Authentication Terminal and Signature Terminal224
) possessing an
2977
Accurate Terminal Certificate according to [18].225
2978
221 [assignment: list of management functions to be provided by the TSF]
222 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
223 [assignment: list of TSF data]
224 [assignment: list of EAC2 terminal types]
225 [assignment: the authorized identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 138 of 191
4. none226
2979
92. Application note (taken from [6], application note 38)
2980
The authorized roles are identified in their certificates (cf. [17]) and are authorized by validating
2981
the certificate chain up to the CVCA (cf. FMT_MTD.3/EAC2PP). The authorized role of a
2982
terminal is part of the Certificate Holder Authorization in the card verifiable certificate that is
2983
provided by the terminal within Terminal Authentication 2 (cf. [18]). Different types of EAC2
2984
terminals may exist, cf. [17].
2985
FMT_MTD.1/PA_EAC2PP
2986
Management of TSF data – Personalization Agent
2987
Hierarchical to: No other components
2988
Dependencies: FMT_SMF.1 Specification of management functions
2989
fulfilled by FMT_SMF.1/EAC2PP
2990
FMT_SMR.1 Security roles fulfilled by
2991
FMT_SMR.1/PACE_EAC2PP
2992
FMT_MTD.1.1/PA_EAC2PP
2993
The TSF shall restrict the ability to write227
the card/chip security object(s) (SOC) and
2994
the document Security Object (SOD)228
to the Personalization Agent229
.
2995
93. Application note (taken from [6], application note 39)
2996
Note that the card/chip security objects are mentioned here as well. These contain information,
2997
such as algorithm identifiers, only necessary for EAC2. All requirements formulated in [13] are
2998
thus met, and strict conformance is therefore not violated
2999
FMT_MTD.1/SK_PICC_EAC2PP
3000
Management of TSF data – Chip Authentication and Restricted Identification Private Key(s)
3001
Hierarchical to: No other components
3002
Dependencies: FMT_SMF.1 Specification of management functions
3003
fulfilled by FMT_SMF.1/EAC2PP
3004
FMT_SMR.1 Security roles fulfilled by
3005
FMT_SMR.1/PACE_EAC2PP
3006
226 [assignment: the authorized identified roles]
227 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
228 [assignment: list of TSF data]
229 [assignment: the authorized identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 139 of 191
FMT_MTD.1.1/SK_PICC_EAC2PP
3007
The TSF shall restrict the ability to create or load230231
the Chip Authentication private
3008
key(s) (SKPICC) and the Restricted Identification Private Key(s)232
to the Personalization
3009
Agent or the Manufacturer.233
3010
94. Application note (taken from [6], application note 40)
3011
Applied, see FCS_CKM.1/CA2 and FCS_CKM.1/RI.
3012
95. Application note (from ST author)
3013
The FMT_MTD.1/SK_PICC_EAC2PP was refined, because the Manufactuer means here the
3014
electronic document manufacturer, which may create the application and the file system as
3015
well. So the Manufacturer may generate or load the private keys.
3016
FMT_MTD.1/KEY_READ_EAC2PP
3017
Management of TSF data – Private Key Read
3018
Hierarchical to: No other components
3019
Dependencies: FMT_SMF.1 Specification of management functions
3020
fulfilled by FMT_SMF.1/EAC2PP
3021
FMT_SMR.1 Security roles fulfilled by
3022
FMT_SMR.1/PACE_EAC2PP
3023
FMT_MTD.1.1/KEY_READ_EAC2PP
3024
The TSF shall restrict the ability to read234
the
3025
1. PACE passwords,
3026
2. Personalization Agent Keys,
3027
3. the Chip Authentication private key(s) (SKPICC)
3028
4. the Restricted Identification private key(s)235
3029
5. none236
3030
230 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
231 [selection: create, load]
232 [assignment: list of TSF data]
233 [assignment: the authorized identified roles]
234 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
235 [assignment: list of TSF data]
236 [assignment: list of TSF data]
IDentity Applet v3.4/eIDAS Security Target
Page 140 of 191
to none237
3031
96. Application note (taken from [6], application note 41)
3032
FMT_MTD.1/KEY_READ_EAC2PP extends the SFR from [13] by additional assignments.
3033
FMT_MTD.1/Initialize_PIN_EAC2PP
3034
PIN Management of TSF data – Initialize PIN
3035
Hierarchical to: No other components
3036
Dependencies: FMT_SMF.1 Specification of management functions
3037
fulfilled by FMT_SMF.1/EAC2PP
3038
FMT_SMR.1 Security roles fulfilled by
3039
FMT_SMR.1/PACE_EAC2PP
3040
FMT_MTD.1.1/Initialize_PIN_EAC2PP
3041
The TSF shall restrict the ability to write238
the initial PIN and PUK239
to the Personalization
3042
Agent240
3043
FMT_MTD.1/Change_PIN_EAC2PP
3044
Management of TSF data – Changing PIN
3045
Hierarchical to: No other components
3046
Dependencies: FMT_SMF.1 Specification of management functions
3047
fulfilled by FMT_SMF.1/EAC2PP
3048
FMT_SMR.1 Security roles fulfilled by
3049
FMT_SMR.1/PACE_EAC2PP
3050
FMT_MTD.1.1/Change_PIN_EAC2PP
3051
The TSF shall restrict the ability to change241
the blocked PIN242
to
3052
1. Electronic Document Holder (using the PUK) with unauthenticated terminal
3053
237 [assignment: the authorized identified roles]
238 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
239 [assignment: list of TSF data]
240 [assignment: the authorized identified roles]
241 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
242 [assignment: list of TSF data]
IDentity Applet v3.4/eIDAS Security Target
Page 141 of 191
2. Authentication Terminal with the Terminal Authorisation level for PIN management
3054
according to [17].243244
3055
FMT_MTD.1/Resume_PIN_EAC2PP
3056
Management of TSF data – Resuming PIN
3057
Hierarchical to: No other components
3058
Dependencies: FMT_SMF.1 Specification of management functions
3059
fulfilled by FMT_SMF.1/EAC2PP
3060
FMT_SMR.1 Security roles fulfilled by
3061
FMT_SMR.1/PACE_EAC2PP
3062
FMT_MTD.1.1/Resume_PIN_EAC2PP
3063
The TSF shall restrict the ability to resume245
the suspended PIN246
to the Electronic
3064
Document Holder247
3065
97. Application note (taken from [6], application note 42)
3066
Resuming is a two-step procedure, subsequently using PACE with the CAN and PACE with
3067
the PIN. It must be implemented according to [17], and is relevant for the status as required by
3068
FIA_AFL.1/Suspend_PIN_EAC2PP. The Electronic Document Holder is authenticated as
3069
required by FIA_UAU.1/PACE_EAC2PP using the PIN as the shared password.
3070
FMT_MTD.1/Unblock_PIN_EAC2PP
3071
Management of TSF data – Unblocking PIN
3072
Hierarchical to: No other components
3073
Dependencies: FMT_SMF.1 Specification of management functions
3074
fulfilled by FMT_SMF.1/EAC2PP
3075
FMT_SMR.1 Security roles fulfilled by
3076
FMT_SMR.1/PACE_EAC2PP
3077
FMT_MTD.1.1/Unblock_PIN_EAC2PP
3078
243 [assignment: the authorized identified roles]
244 [assignment: the authorised identified roles that match the list of PIN changing rules conformant to [17]]
245 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
246 [assignment: list of TSF data]
247 [assignment: the authorized identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 142 of 191
The TSF shall restrict the ability to unblock248
the blocked PIN249
to
3079
1. the Electronic Document Holder (using the PUK for unblocking),
3080
2. an EAC2 terminal of a type that has the terminal authorization level for PIN
3081
management.250
3082
98. Application note (taken from [6], application note 43)
3083
The unblocking procedure must be implemented according to [17], and is relevant for the status
3084
as required by FIA_AFL.1/Block_PIN_EAC2PP. It can be triggered by either (i) the Electronic
3085
Document Holder being authenticated as required by FIA_UAU.1/PACE_EAC2PP using the
3086
PUK as the shared password or (ii) an EAC2 terminal (FIA_UAU.1/EAC2_Terminal_EAC2PP)
3087
that proved a terminal authorization level being sufficient for PIN management
3088
(FDP_ACF.1/TRM).
3089
FMT_MTD.1/Activate_PIN_EAC2PP
3090
Management of TSF data – Activating/Deactivating PIN
3091
Hierarchical to: No other components
3092
Dependencies: FMT_SMF.1 Specification of management functions
3093
fulfilled by FMT_SMF.1/EAC2PP
3094
FMT_SMR.1 Security roles fulfilled by
3095
FMT_SMR.1/PACE_EAC2PP
3096
FMT_MTD.1.1/Activate_PIN_EAC2PP
3097
The TSF shall restrict the ability to activate and deactivate251
the PIN252
to an EAC2
3098
terminal of a type that has the terminal authorization level for PIN management253
.
3099
99. Application note (taken from [6], application note 44)
3100
The activation/deactivation procedures must be implemented according to [17]. They can be
3101
triggered by an EAC2 terminal (FIA_UAU.1/EAC2_Terminal_EAC2PP) that proved a terminal
3102
authorization level sufficient for PIN management (FDP_ACF.1/TRM).
3103
FMT_MTD.3/EAC2PP
3104
Secure TSF data
3105
Hierarchical to: No other components
3106
248 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
249 [assignment: list of TSF data]
250 [assignment: the authorized identified roles]
251 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
252 [assignment: list of TSF data]
253 [assignment: the authorized identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 143 of 191
Dependencies: FMT_MTD.1 Management of TSF data fulfilled by
3107
FMT_MTD.1/CVCA_INI_EAC2PP,
3108
FMT_MTD.1/CVCA_UPD_EAC2PP,
3109
FMT_MTD.1/DATE_EAC2PP
3110
FMT_MTD.3.1_EAC2PP
3111
The TSF shall ensure that only secure values of the certificate chain are accepted for
3112
TSF data of the Terminal Authentication protocol 2 and the Access Control SFP254
.
3113
Refinement: To determine if the certificate chain is valid, the TOE shall proceed the
3114
certificate validation according to [18].
3115
100. Application note (taken from [6], application note 45)
3116
Terminal Authentication is used as required by (i) FIA_UID.1/EAC2_Terminal_EAC2PP and
3117
FIA_UAU.5/PACE_EAC2PP. The terminal authorization level derived from the CVCA
3118
Certificate, the DV Certificate and the Terminal Certificate is used as TSF-data for the access
3119
control required by FDP_ACF.1/TRM.
3120
In addition, this ST contains all remaining SFRs of the claimed [13].
3121
FMT_LIM.1/EAC2PP
3122
Limited capabilities
3123
Hierarchical to: No other components
3124
Dependencies: FMT_LIM.2 Limited availability: fulfilled by
3125
FMT_LIM.2/EAC2PP
3126
FMT_LIM.1.1_EAC2PP
3127
The TSF shall be designed in a manner that limits their capabilities so that in conjunction
3128
with ‘Limited availability (FMT_LIM.2)’ the following policy is enforced:
3129
Deploying test features after TOE delivery do not allow
3130
1. User Data to be manipulated and disclosed,
3131
2. TSF data to be manipulated or disclosed,
3132
3. software to be reconstructed,
3133
4. substantial information about construction of TSF to be gathered which may enable
3134
other attacks.255
and
3135
254 [assignment: list of TSF data]
255 [assignment: Limited capability and availability policy]
IDentity Applet v3.4/eIDAS Security Target
Page 144 of 191
5. EAC1 and EAC2 protected data 256
3136
Application note 101 (from ST author)
3137
The assignment was necessary to cover all protected user data.
3138
FMT_LIM.2/EAC2PP
3139
Limited availability
3140
Hierarchical to: No other components
3141
Dependencies: FMT_LIM.1 Limited capabilities: fulfilled by
3142
FMT_LIM.1/EAC2PP
3143
FMT_LIM.2.1_EAC2PP
3144
The TSF shall be designed in a manner that limits their availability so that in conjunction
3145
with ‘Limited capabilities (FMT_LIM.1)’ the following policy is enforced:
3146
Deploying test features after TOE delivery do not allow
3147
1. User Data to be manipulated and disclosed,
3148
2. TSF data to be manipulated or disclosed,
3149
3. software to be reconstructed,
3150
4. substantial information about construction of TSF to be gathered which may enable
3151
other attacks.257
and
3152
5. EAC1 and EAC2 protected data 258
3153
Application note 102 (from ST author)
3154
The assignment was necessary to cover all protected user data.
3155
FMT_MTD.1/INI_ENA_EAC2PP
3156
Management of TSF data – Writing Initialisation and Pre-personalisation Data
3157
Hierarchical to: No other components
3158
Dependencies: FMT_SMF.1 Specification of management functions:
3159
fulfilled by FMT_SMF.1/EAC2PP
3160
256 [assignment: Limited capability and availability policy]
257 [assignment: Limited capability and availability policy]
258 [assignment: Limited capability and availability policy]
IDentity Applet v3.4/eIDAS Security Target
Page 145 of 191
FMT_SMR.1 Security roles: fulfilled by
3161
FMT_SMR.1/PACE_EAC2PP
3162
FMT_MTD.1.1/INI_ENA_EAC2PP
3163
The TSF shall restrict the ability to write259
the Initialisation Data and Pre-personalisation
3164
Data260
to the Manufacturer.261
3165
FMT_MTD.1/INI_DIS_EAC2PP
3166
Management of TSF data – Reading and Using Initialisation and Pre-personalisation Data
3167
Hierarchical to: No other components
3168
Dependencies: FMT_SMF.1 Specification of management functions:
3169
fulfilled by FMT_SMF.1/EAC2PP
3170
FMT_SMR.1 Security roles: fulfilled by
3171
FMT_SMR.1/PACE_EAC2PP
3172
FMT_MTD.1.1/INI_DIS_EAC2PP
3173
The TSF shall restrict the ability to read out262
the Initialisation Data and the Pre-
3174
personalisation Data263
to the Personalisation Agent.264
3175
The following SFRs are imported due to claiming [5]. They mainly concern applications with
3176
EAC1-protected data.
3177
• FMT_SMF.1/EAC1PP
3178
• FMT_SMR.1/PACE_EAC1PP
3179
This SFR is combined with FMT_SMR.1/PACE_EAC2PP into FMT_SMR.1.
3180
• FMT_LIM.1/EAC1PP
3181
This SFR is equivalent to FMT_LIM.1/EAC2PP, but listed here for the sake of completeness.
3182
259 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
260 [assignment: list of TSF data]
261 [assignment: the authorised identified roles]
262 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
263 [assignment: list of TSF data]
264 [assignment: the authorized identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 146 of 191
• FMT_LIM.2/EAC1PP
3183
This SFR is equivalent to FMT_LIM.2/EAC2PP, but listed here for the sake of completeness.
3184
• FMT_MTD.1/INI_ENA_EAC1PP
3185
(equivalent to FMT_MTD.1/INI_ENA_EAC2PP, but listed here for the sake of completeness)
3186
• FMT_MTD.1/INI_DIS_EAC1PP
3187
(equivalent to FMT_MTD.1/INI_DIS_EAC2PP, but listed here for the sake of completeness)
3188
• FMT_MTD.1/CVCA_INI_EAC1PP
3189
• FMT_MTD.1/CVCA_UPD_EAC1PP
3190
• FMT_MTD.1/DATE_EAC1PP
3191
This SFR is equivalent to FMT_MTD.1/DATE_EAC2PP. Note that
3192
FMT_MTD.1/DATE_EAC2PP generalizes the notion of Domestic Extended Inspection System
3193
to EAC1 terminals with appropriate authorization level. This does not violate strict conformance
3194
to [5].
3195
• FMT_MTD.1/CAPK_EAC1PP
3196
• FMT_MTD.1/PA_EAC1PP
3197
• FMT_MTD.1/KEY_READ_EAC1PP
3198
• FMT_MTD.3/EAC1PP
3199
FMT_SMF.1/EAC1PP
3200
Specification of Management Functions
3201
Hierarchical to: No other components
3202
Dependencies: No dependencies
3203
FMT_SMF.1.1/EAC1PP
3204
The TSF shall be capable of performing the following management functions:
3205
1. Initialization,
3206
2. Pre-personalisation,
3207
3. Personalisation
3208
IDentity Applet v3.4/eIDAS Security Target
Page 147 of 191
4. Configuration.265
3209
FMT_MTD.1/CVCA_INI_EAC1PP
3210
Management of TSF data – Initialization of CVCA Certificate and Current Date
3211
Hierarchical to: No other components
3212
Dependencies: FMT_SMF.1 Specification of management functions
3213
fulfilled by FMT_SMF.1/EAC1PP
3214
FMT_SMR.1 Security roles fulfilled by
3215
FMT_SMR.1/PACE_EAC1PP
3216
FMT_MTD.1.1/CVCA_INI_EAC1PP
3217
The TSF shall restrict the ability to write266
the
3218
1. initial Country Verifying Certification Authority Public Key,
3219
2. initial Country Verifying Certification Authority Certificate,
3220
3. initial Current Date,
3221
4. none267268
3222
to Personalisation Agent269
.
3223
103. Application note (taken from [5], application note 41)
3224
Applied.
3225
FMT_MTD.1/CVCA_UPD_EAC1PP
3226
Management of TSF data – Country Verifying Certification Authority
3227
Hierarchical to: No other components
3228
Dependencies: FMT_SMF.1 Specification of management functions
3229
functions fulfilled by FMT_SMF.1/EAC1PP
3230
FMT_SMR.1 Security roles fulfilled by
3231
FMT_SMR.1/PACE_EAC1PP
3232
265 [assignment: list of management functions to be provided by the TSF]
266 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
267 [assignment: list of TSF data]
268 [assignment: list of TSF data]
269 [assignment: the authorised identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 148 of 191
FMT_MTD.1.1/CVCA_UPD_EAC1PP
3233
The TSF shall restrict the ability to update270
the
3234
1. Country Verifying Certification Authority Public Key,
3235
2. Country Verifying Certification Authority Certificate271
3236
to Country Verifying Certification Authority.272
3237
104. Application note (taken from [5], application note 42)
3238
The Country Verifying Certification Authority updates its asymmetric key pair and distributes
3239
the public key be means of the Country Verifying CA Link-Certificates (cf. [16]). The TOE
3240
updates its internal trust-point if a valid Country Verifying CA Link-Certificates (cf.
3241
FMT_MTD.3/EAC1PP) is provided by the terminal (cf. [16])
3242
FMT_MTD.1/CAPK_EAC1PP
3243
Management of TSF data – Chip Authentication Private Key
3244
Hierarchical to: No other components
3245
Dependencies: FMT_SMF.1 Specification of management functions
3246
functions fulfilled by FMT_SMF.1/EAC1PP
3247
FMT_SMR.1 Security roles fulfilled by
3248
FMT_SMR.1/PACE_EAC1PP
3249
FMT_MTD.1.1/CAPK_EAC1PP
3250
The TSF shall restrict the ability to create, load273274
the Chip Authentication Private Key275
3251
to Manufacturer or Personalisation Agent.276
3252
105. Application note (taken from [5], application note 44)
3253
Applied.
3254
FMT_MTD.1/PA_EAC1PP
3255
Management of TSF data – Personalisation Agent
3256
270 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
271 [assignment: list of TSF data]
272 [assignment: the authorised identified roles]
273 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
274 [selection: create, load]
275 [assignment: list of TSF data]
276 [assignment: the authorisedidentified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 149 of 191
Hierarchical to: No other components
3257
Dependencies: FMT_SMF.1 Specification of management functions:
3258
fulfilled by FMT_SMF.1/EAC1PP
3259
FMT_SMR.1 Security roles: fulfilled by
3260
FMT_SMR.1/PACE_EAC1PP
3261
FMT_MTD.1.1/PA_EAC1PP
3262
The TSF shall restrict the ability to write277
the Document Security Object (SOD)278
to the
3263
Personalisation Agent.279
3264
FMT_MTD.1/KEY_READ_EAC1PP
3265
Management of TSF data – Key Read
3266
Hierarchical to: No other components
3267
Dependencies: FMT_SMF.1 Specification of management functions:
3268
fulfilled by FMT_SMF.1/EAC1PP
3269
FMT_SMR.1 Security roles fulfilled by
3270
FMT_SMR.1/PACE_EAC1PPFMT_MTD.1.1/KEY_RE
3271
AD_EAC1PP
3272
The TSF shall restrict the ability to read280
the
3273
1. PACE passwords,
3274
2. Chip Authentication Private Key,
3275
3. Personalisation Agent Keys281
3276
4. Active Authentication Private Key
3277
to none282
3278
106. Application note (taken from [5], application note 45)
3279
277 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
278 [assignment: list of TSF data]
279 [assignment: the authorised identified roles]
280 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
281 [assignment: list of TSF data]
282 [assignment: the authorised identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 150 of 191
The SFR FMT_MTD.1/KEY_READ_EAC1PP in the ST covers the definition in [13] and
3280
extends it by additional TSF data. This extension does not conflict with the strict conformance
3281
to [13].
3282
107. Application note (ST author)
3283
The refinement was necessary because of the Active Authentication protocol.
3284
FMT_MTD.3/EAC1PP
3285
Secure TSF data
3286
Hierarchical to: No other components
3287
Dependencies: FMT_MTD.1 Management of TSF data fulfilled by
3288
FMT_MTD.1/CVCA_INI_EAC1PP and
3289
FMT_MTD.1/CVCA_UPD_EAC1PP
3290
FMT_MTD.3.1_EAC1PP
3291
The TSF shall ensure that only secure values of the certificate chain are accepted for
3292
TSF data of the Terminal Authentication Protocol v.1 and the Access Control.283
3293
Refinement: The certificate chain is valid if and only if
3294
1. the digital signature of the Inspection System Certificate can be verified as
3295
correct with the public key of the Document Verifier Certificate and the
3296
expiration date of the Inspection System Certificate is not before the Current
3297
Date of the TOE,
3298
2. the digital signature of the Document Verifier Certificate can be verified as
3299
correct with the public key in the Certificate of the Country Verifying
3300
Certification Authority and the expiration date of the Certificate of the Country
3301
Verifying Certification Authority is not before the Current Date of the TOE and
3302
the expiration date of the Document Verifier Certificate is not before the Current
3303
Date of the TOE,
3304
3. the digital signature of the Certificate of the Country Verifying Certification
3305
Authority can be verified as correct with the public key of the Country Verifying
3306
Certification Authority known to the TOE.
3307
283 [assignment: list of TSF data]
IDentity Applet v3.4/eIDAS Security Target
Page 151 of 191
The Inspection System Public Key contained in the Inspection System Certificate in
3308
a valid certificate chain is a secure value for the authentication reference data of the
3309
Extended Inspection System EAC1 terminal.
3310
The intersection of the Certificate Holder Authorizations contained in the
3311
certificates of a valid certificate chain is a secure value for Terminal Authorization
3312
of a successful authenticated Extended Inspection System EAC1 terminal.
3313
108. Application note (taken from [5], application note 46)
3314
The Terminal Authentication Version 1 is used for EAC1 terminal as required by
3315
FIA_UAU.4/PACE_EAC1PP and FIA_UAU.5/PACE_EAC1PP. The Terminal Authorization is
3316
used as TSF data for access control required by FDP_ACF.1/TRM.
3317
The following SFRs are imported due to claiming [14]. They mostly concern the security
3318
management of an eSign application.
3319
• FMT_SMR.1/SSCDPP
3320
• FMT_SMF.1/SSCDPP
3321
• FMT_MOF.1/SSCDPP
3322
• FMT_MSA.1/Admin_SSCDPP
3323
• FMT_MSA.1/SignatorySSCDPP
3324
• FMT_MSA.2/SSCDPP
3325
• FMT_MSA.3/SSCDPP
3326
• FMT_MSA.4/SSCDPP
3327
• FMT_MTD.1/Admin_SSCDPP
3328
• FMT_MTD.1/Signatory_SSCDPP
3329
FMT_SMR.1/SSCDPP
3330
Security roles
3331
Hierarchical to: No other components
3332
Dependencies: FIA_UID.1 Timing of identification fulfilled by
3333
FIA_UID.1/SSCDPP
3334
FMT_SMR.1.1/SSCDPP
3335
The TSF shall maintain the roles R.Admin and R.Sigy284
3336
284 [assignment: the authorised identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 152 of 191
FMT_SMR.1.2/SSCDPP
3337
The TSF shall be able to associate users with roles.
3338
FMT_SMF.1/SSCDPP
3339
Security Management Functions
3340
Hierarchical to: No other components
3341
Dependencies: No dependencies
3342
FMT_SMF.1.1/SSCDPP
3343
The TSF shall be capable of performing the following management functions:
3344
1. Creation and modification of RAD,
3345
2. Enabling the signature creation function,
3346
3. Modification of the security attribute SCD/SVD management, SCD operational,
3347
4. Change the default value of the security attribute SCD Identifier, 285
3348
5. Unblock the RAD286
3349
109. Application note (taken from [14], application note 14)
3350
Applied.
3351
FMT_MOF.1/SSCDPP
3352
Management of security functions behaviour
3353
Hierarchical to: No other components
3354
Dependencies: FMT_SMR.1 Security roles fulfilled by
3355
FMT_SMR.1/SSCDPP
3356
FMT_SMF.1 Specification of Management Functions
3357
fulfilled by FMT_SMF.1/SSCDPP
3358
FMT_MOF.1.1/SSCDPP
3359
The TSF shall restrict the ability to enable287
the functions signature creation function288
to
3360
R.Sigy289
.
3361
285 [assignment: list of other security management functions to be provided by the TSF]
286 [assignment: list of other security management functions to be provided by the TSF]
287 [selection: determine the behaviour of, disable, enable, modify the behaviour of]
288 [assignment: list of functions]
289 [assignment: the authorised identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 153 of 191
FMT_MSA.1/Admin_SSCDPP
3362
Management Security attributes
3363
Hierarchical to: No other components
3364
Dependencies: [FDP_ACC.1 Subset access control or
3365
FDP.IFC.1 Subset information flow control] fulfilled by
3366
FDP_ACC.1/SCD/SVD_Generation_SSCDPP
3367
FMT_SMR.1 Security roles fulfilled by
3368
FMT_SMR.1/SSCDPP
3369
FMT_SMF.1 Specification of Management Functions
3370
fulfilled by FMT_SMF.1/SSCDPP
3371
FMT_MSA.1.1/Admin_SSCDPP
3372
The TSF shall enforce the SCD/SVD Generation SFP290
to restrict the ability to modify,
3373
none291
the security attributes SCD/SVD management292
to R.Admin293
.
3374
FMT_MSA.1/SignatorySSCDPP
3375
Management Security attributes
3376
Hierarchical to: No other components
3377
Dependencies: [FDP_ACC.1 Subset access control or
3378
FDP.IFC.1 Subset information flow control] fulfilled by
3379
FDP_ACC.1/Signature-creation_SSCDPP
3380
FMT_SMR.1 Security roles fulfilled by
3381
FMT_SMR.1/SSCDPP
3382
FMT_SMF.1 Specification of Management Functions
3383
fulfilled by FMT_SMF.1/SSCDPP
3384
FMT_MSA.1.1/Signatory_SSCDPP
3385
290 [assignment: access control SFP(s), information flow control SFP(s)]
291 [assignment: other operations]
292 [assignment: list of security attributes]
293 [assignment: the authorized identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 154 of 191
The TSF shall enforce the SCD/SVD Generation SFP294
to restrict the ability to modify295
3386
the security attributes SCD operational296
to R.Sigy297
.
3387
FMT_MSA.2/SSCDPP
3388
Secure security attributes
3389
Hierarchical to: No other components
3390
Dependencies: [FDP_ACC.1 Subset access control or
3391
FDP.IFC.1 Subset information flow control] fulfilled by
3392
FDP_ACC.1/SCD/SVD_Generation_SSCDPP and
3393
FDP_ACC.1/Signature-creation_SSCDPP
3394
FMT_MSA.1 Management of security attributes fulfilled
3395
by FMT_MSA.1/Admin_SSCDPP and
3396
FMT_MSA.1/SignatorySSCDPP.
3397
FMT_SMR.1 Security roles fulfilled by
3398
FMT_SMR.1/SSCDPP
3399
FMT_MSA.2.1/ SSCDPP
3400
The TSF shall ensure that only secure values are accepted for SCD/SVD Management
3401
and SCD operational298
.
3402
110. Application note (taken from [14], application note 15)
3403
Applied.
3404
FMT_MSA.3/SSCDPP
3405
Static attribute initialisation
3406
Hierarchical to: No other components
3407
Dependencies: FMT_MSA.1 Management of security attributes fulfilled
3408
by FMT_MSA.1/Admin_SSCDPP and
3409
FMT_MSA.1/SignatorySSCDPP.
3410
294 [assignment: access control SFP(s), information flow control SFP(s)]
295 [selection: change_default, query, modify, delete, [assignment: other operations]]
296 [assignment: list of security attributes]
297 [assignment: the authorized identified roles]
298 [selection: list of security attributes]
IDentity Applet v3.4/eIDAS Security Target
Page 155 of 191
FMT_SMR.1 Security roles fulfilled by
3411
FMT_SMR.1/SSCDPP
3412
FMT_MSA.3.1/ SSCDPP
3413
The TSF shall enforce the SCD/SVD Generation SFP, SVD Transfer SFP and Signature
3414
Creation SFP299
to provide restrictive300
default values for security attributes that are used
3415
to enforce SFP.
3416
FMT_MSA.3.2/ SSCDPP
3417
The TSF shall allow the R.Admin301
to specify alternative initial values to override the
3418
default values when an object or information created.
3419
FMT_MSA.4/SSCDPP
3420
Security attribute value inharitance
3421
Hierarchical to: No other components
3422
Dependencies: [FDP_ACC.1 Subset access control or
3423
FDP.IFC.1 Subset information flow control] fulfilled by
3424
FDP_ACC.1/SCD/SVD_Generation_SSCDPP and
3425
FDP_ACC.1/Signature-creation_SSCDPP
3426
FMT_MSA.4/SSCDPP
3427
The TSF shall use the following rules to set the value of security attributes:
3428
1. If S.Admin successfully generates an SCD/SVD pair without S.Sigy being
3429
authenticated the security attribute “SCD operational of the SCD” shall be set to
3430
“no” as a single operation.
3431
2. If S.Sigy successfully generates an SCD/SVD pair the security attribute “SCD
3432
operational of the SCD” shall be set to “yes” as a single operation.302
3433
111. Application note (taken from [14], application note 16)
3434
The TOE may not support generating an SVD/SCD pair by the signatory alone, in which case
3435
rule (2) is not relevant.
3436
299 [assignment: access control SFP, information flow control SFP]
300 [selection, choose one of: restrictive, permissive, [assignment: other property]]
301 [assignment: the authorised identified roles]
302 [assignment: rules for setting the values of security attributes]
IDentity Applet v3.4/eIDAS Security Target
Page 156 of 191
FMT_MTD.1/Admin_SSCDPP
3437
Management of TSF data
3438
Hierarchical to: No other components
3439
Dependencies: FMT_SMR.1 Security roles fulfilled by
3440
FMT_SMR.1/SSCDPP
3441
FMT_SMF.1 Specification of Management Functions
3442
fulfilled by FMT_SMF.1/SSCDPP
3443
FMT_MTD.1.1/Admin_SSCDPP
3444
The TSF shall restrict the ability to create303
the RAD304
to R.Admin305
.
3445
FMT_MTD.1/Signatory_SSCDPP
3446
Management of TSF data
3447
Hierarchical to: No other components
3448
Dependencies: FMT_SMR.1 Security roles fulfilled by
3449
FMT_SMR.1/SSCDPP
3450
FMT_SMF.1 Specification of Management Functions
3451
fulfilled by FMT_SMF.1/SSCDPP
3452
FMT_MTD.1.1/Signatory_SSCDPP
3453
The TSF shall restrict the ability to modify306
,none307
the RAD308
to R.Sigy309
.
3454
112. Application note (taken from [14], application note 17)
3455
Applied.
3456
The following SFRs are defined here. The concern loading applications onto the IC during
3457
manufacturing and relate directly to OT.Cap_Avail_Loader.
3458
FMT_LIM.1/Loader
3459
Limited Capabilities
3460
303 [selection: change_default, query, modify, delete, clear, [assignment: other operations]
304 [assignment: list of TSF data]
305 [assignment: the authorised identified roles]
306 [selection: change_default, query, modify, delete, clear, [assignment: other operations]
307 [selection: change_default, query, modify, delete, clear, [assignment: other operations]
308 [assignment: list of TSF data]
309 [assignment: the authorised identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 157 of 191
Hierarchical to: No other components
3461
Dependencies: FMT_ LIM.2 Limited availability fulfilled by
3462
FMT_LIM.2/Loader
3463
FMT_LIM.1.1/Loader
3464
The TSF shall be designed and implemented in a manner that limits their capabilities so
3465
that in conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced:
3466
Deploying Loader functionality after the locking of the Loader310
does not allow stored user
3467
data to be disclosed or manipulated by unauthorized users.311
3468
113. Application note (taken from [20], application note 14)
3469
FMT_LIM.1/Loader supplements FMT_LIM.2/Loader allowing for non-overlapping loading of
3470
user data and protecting the TSF against misuses of the Loader for attacks against the TSF.
3471
The TOE Loader may allow for correction of already loaded user data before the assigned
3472
action e.g. before blocking the TOE Loader for TOE Delivery to the end-customer or any
3473
intermediate step on the life cycle of the Security IC or the smartcard.
3474
FMT_LIM.2/Loader
3475
Limited Availability
3476
Hierarchical to: No other components
3477
Dependencies: FMT_ LIM.1 Limited capabilities fulfilled by
3478
FMT_LIM.1/Loader
3479
FMT_LIM.2.1/Loader
3480
The TSF shall be designed and implemented in a manner that limits their availability so
3481
that in conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is enforced:
3482
The TSF prevents deploying the Loader functionality after the locking of the Loader.312313
3483
114. Application note (taken from [20], application note 15)
3484
The Loader functionality relies on a secure boot loading procedure in a secure environment
3485
before TOE delivery to the assigned user and preventing to deploy the Loader of the Security
3486
IC after an assigned action, e.g. after blocking the Loader for TOE delivery to the end-user.
3487
The following SFR is new and concern security management for ePassport application in
3488
combination with [5] in case the Active Authentication protocol is active:
3489
310 [assignment: action]
311 [assignment: Limited capability and availability policy]
312 [assignment: action]
313 [assignment: Limited capability and availability policy]
IDentity Applet v3.4/eIDAS Security Target
Page 158 of 191
FMT_MTD.1/AA_Private_Key
3490
Management of TSF data – Active Authentication Private Key
3491
Hierarchical to: No other components
3492
Dependencies: FMT_SMF.1 Specification of management functions
3493
fulfilled by FMT_SMF.1/EAC1PP
3494
FMT_SMR.1 Security roles fulfilled by
3495
FMT_SMR.1/PACE_EAC1PP
3496
FMT_MTD.1.1/AA_Private_Key
3497
The TSF shall restrict the ability to create or load314
the Active Authentication Private
3498
Key315
to the Personalization Agent.316
3499
6.1.7. Class FPT
3500
The following security functional requirements are imported from [6], and address the
3501
protection against forced illicit information leakage, including physical manipulation.
3502
• FPT_EMS.1/EAC2PP
3503
115. Application note (taken from [20], application note 16)
3504
Note that related to Application Note 6 of [20], the PIN in the above SFR refers here to both
3505
the PIN for an eID application, and also the PIN for an eSign application, if they exist on card.
3506
• FPT_FLS.1/EAC2PP
3507
• FPT_TST.1/EAC2PP
3508
• FPT_PHP.3/EAC2PP
3509
The following SFRs are imported due to claiming [5]. They mostly concern the protection of
3510
security functionality related to EAC1-protected data.
3511
• FPT_TST.1/EAC1PP
3512
(equivalent to FPT_TST.1/EAC2PP, but listed here for the sake of completeness)
3513
314 [assignment: change_default, query, modify, delete, clear, [assignment: other operations]]
315 [assignment: list of TSF data]
316 [assignment: the authorized identified roles]
IDentity Applet v3.4/eIDAS Security Target
Page 159 of 191
• FPT_FLS.1/EAC1PP
3514
(equivalent to FPT_FLS.1/EAC2PP, but listed here for the sake of completeness)
3515
• FPT_PHP.3/EAC1PP
3516
(equivalent to FPT_PHP.3/EAC2PP, but listed here for the sake of completeness)
3517
• FPT_EMS.1/EAC1PP
3518
The following SFRs are imported due to claiming [14]. They mostly concern the protection of
3519
security functionality related to eSign application (if available).
3520
• FPT_EMS.1/SSCDPP
3521
• FPT_FLS.1/SSCDPP
3522
(subsumed by FPT_FLS.1/EAC2PP)
3523
• FPT_PHP.1/SSCDPP
3524
• FPT_PHP.3/SSCDPP
3525
(subsumed by FPT_PHP.3/EAC2PP)
3526
• FPT_TST.1/SSCDPP
3527
(subsumed by FPT_TST.1/EAC2PP)
3528
FPT_EMS.1/EAC2PP
3529
TOE Emanation
3530
Hierarchical to: No other components
3531
Dependencies: No dependencies
3532
FPT_EMS.1.1/EAC2PP
3533
The TOE shall not emit variations in power consumption or timing during command
3534
execution317
in excess of non-useful information318
enabling access to
3535
1. the session keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA-KEnc),
3536
317 [assignment: types of emissions]
318 [assignment: specified limits]
IDentity Applet v3.4/eIDAS Security Target
Page 160 of 191
2. the ephemeral private key ephem-SKPICC-PACE, 319
3537
3. the Chip Authentication private keys (SKPICC)
3538
4. the PIN, PUK,
3539
5. none320
3540
and
3541
6. the Restricted Identification private key(s) SKID, 321
3542
7. none.322
3543
FPT_EMS.1.2/EAC2PP
3544
The TSF shall ensure any users323
are unable to use the following interface electronic
3545
document’s contactless/contact-based interface and circuit contacts324
to gain access to
3546
1. the session keys (PACE-KMAC, PACE-KEnc), (CA2-KMAC, CA2-KEnc),
3547
2. the ephemeral private key ephem -SKPICC-PACE1,
3548
3. the Chip Authentication private key(s) (SKPICC),
3549
4. the PIN, PUK,
3550
5. the session keys (PACE-KMAC, PACE-KEnc), (CA-KMAC, CA-KEnc)325
3551
6. none326
3552
and
3553
7. the Restricted Identification private key(s) SKID,327
3554
8. none.328
3555
116. Application note (taken from [6], application note 46)
3556
The TOE shall prevent attacks against the listed secret data where the attack is based on
3557
external observable physical phenomena of the TOE. Such attacks may be observable at the
3558
interfaces of the TOE, originate from internal operation of the TOE, or be caused by an attacker
3559
that varies the physical environment under which the TOE operates. The set of measurable
3560
physical phenomena is influenced by the technology employed to implement the smart card.
3561
Examples of measurable phenomena include, but are not limited to variations in power
3562
319 [assignment: list of types of TSF data ]
320 [assignment: list of types of TSF data]
321 [assignment: list of types of user data ]
322 [assignment: list of types of user data]
323 [assignment: type of users]
324 [assignment: type of connection]
325 [assignment: list of types of TSF data]
326 [assignment: list of types of TSF data]
327 [assignment: list of types of user data]
328 [assignment: list of types of user data]
IDentity Applet v3.4/eIDAS Security Target
Page 161 of 191
consumption, timing of signals, and electromagnetic radiation due to internal operations or
3563
data transmissions.
3564
Note that while the security functionality described in FPT_EMS.1/EAC2PP should be taken
3565
into account during development of the TOE, associated tests must be carried out as part of
3566
the evaluation, and not/not only during product development.
3567
Note that in the above SFR, all items in FPT_EMS.1/EAC2PP from 3. upwards are additional
3568
assignments. The first item is slightly refined to include CA-key(s).
3569
117. Application note (from ST author)
3570
The PIN in the above SFR refers here to both the PIN for an eID application, and also the PIN
3571
for an eSign application, if they exist on card.
3572
The above SFR is refined from [6] by adding all relevant key material from Chip Authentication
3573
2, the additional assignment to cover the private sector keys. Thus, the set of keys that need
3574
to be protected is a superset of the ones of the SFR from [6]. Hence, the requirement is stricter
3575
than the one from [6], and the refinement operation is justified.
3576
The FPT_EMS.1.2/EAC2PP is refined because in the [20] first and fifth point is identical and
3577
unnecessary to repeat the first point in the current ST.
3578
FPT_FLS.1/EAC2PP
3579
Failure with preservation of secure state
3580
Hierarchical to: No other components
3581
Dependencies: No dependencies
3582
FPT_FLS.1.1_EAC2PP
3583
The TSF shall preserve a secure state when the following types of failures occur:
3584
1. Exposure to operating conditions causing a TOE malfunction,
3585
2. Failure detected by TSF according to FPT_TST.1,329
3586
3. none.330
3587
FPT_TST.1/EAC2PP
3588
TSF testing
3589
Hierarchical to: No other components
3590
Dependencies: No dependencies
3591
FPT_TST.1.1/EAC2PP
3592
329 [assignment: list of types of failures in the TSF]
330 [assignment: list of types of failures in the TSF]
IDentity Applet v3.4/eIDAS Security Target
Page 162 of 191
The TSF shall run a suite of self tests during initial start-up, periodically during normal
3593
operation331
to demonstrate the correct operation of the TSF.332
3594
FPT_TST.1.2/EAC2PP
3595
The TSF shall provide authorised users with the capability to verify the integrity of the TSF
3596
data.333
3597
FPT_TST.1.3/EAC2PP
3598
The TSF shall provide authorised users with the capability to verify the integrity of stored
3599
TSF executable code.334
3600
FPT_PHP.3/EAC2PP
3601
Resistance to physical attack
3602
Hierarchical to: No other components
3603
Dependencies: No dependencies
3604
FPT_PHP.3.1_EAC2PP
3605
The TSF shall resist physical manipulation and physical probing335
to the TSF336
by
3606
responding automatically such that the SFRs are always enforced.
3607
FPT_EMS.1/EAC1PP
3608
TOE Emanation
3609
Hierarchical to: No other components
3610
Dependencies: No dependencies
3611
FPT_EMS.1.1/EAC1PP
3612
The TOE shall not emit variations in power consumption or timing during command
3613
execution337
in excess of non-useful information338
enabling access to
3614
1. Chip Authentication (Version 1) Session Keys,
3615
331 [selection: during initial start-up, periodically during normal operation, at the request of the authorised
user, at the conditions [assignment: conditions under which self test should occur]]
332 [selection: [assignment: parts of TSF], the TSF]
333 [selection: [assignment: parts of TSF], TSF data]
334 [selection: [assignment: parts of TSF], TSF]
335 [assignment: physical tampering scenarios]
336 [assignment: list of TSF devices/elements]
337 [assignment: types of emissions]
338 [assignment: specified limits]
IDentity Applet v3.4/eIDAS Security Target
Page 163 of 191
2. PACE session Keys (PACE-KMAC, PACE-KEnc),
3616
3. the ephemeral private key ephem SKPICC-PACE,
3617
4. the ephemeral private key SKMapPICC-PACE-CAM339
3618
5. Active Authentication Private Key340
3619
6. Personalisation Agent Key(s)
3620
7. Chip Authentication (Version 1) Private Key 341
and
3621
8. none 342
3622
FPT_EMS.1.2/EAC1PP
3623
The TSF shall ensure any users343
are unable to use the following interface smart card
3624
circuit contacts344
to gain access to
3625
1. Chip Authentication (Version 1) Session Keys,
3626
2. PACE session Keys (PACE-KMAC, PACE-KEnc),
3627
3. the ephemeral private key ephem SKPICC-PACE,
3628
4. the ephemeral private key SKMapPICC-PACE-CAM345
3629
5. Active Authentication Private Key346
3630
6. Personalisation Agent Key(s)
3631
7. Chip Authentication (Version 1) Private Key 347
and
3632
8. none.348
3633
118. Application note (from ST author)
3634
This SFR covers the definition of FPT_EMS.1 in [5] and extends it by 4. and 5. of
3635
FPT_EMS.1.1/EAC1PP and FPT_EMS.1.2/EAC1PP. Also, 1. and 7. of both
3636
FPT_EMS.1.1/EAC1PP and FPT_EMS.1.2/EAC1PP are slightly refined in order not to confuse
3637
Chip Authentication 1 with Chip Authentication 2.
3638
Note that FPT_EMS.1/EAC1PP in [5] is solely concerned with Chip Authentication 1, but since
3639
it was the first version of the protocol at the time, it was simply called 'Chip Authentication' back
3640
then.
3641
W.r.t. PACE-CAM, note the significance of protecting SKMap,PICC-PACE-CAM: Whereas when
3642
running PACE and CA1 separately, gaining knowledge of the ephemeral key SKPICC-PACE
3643
enables the attacker to decrypt the current PACE session, an attacker that gains knowledge
3644
339 [assignment: list of types of TSF data]
340 [assignment: list of types of TSF data]
341 [assignment: list of types of user data ]
342 [assignment: list of types of user data]
343 [assignment: type of users]
344 [assignment: type of connection]
345 [assignment: list of types of TSF data]
346 [assignment: list of types of TSF data]
347 [assignment: list of types of TSF data]
348 [assignment: list of types of user data]
IDentity Applet v3.4/eIDAS Security Target
Page 164 of 191
of the ephemeral key SKMap,PICC-PACE-CAM can not only decrypt the session but also easily
3645
reveal the static secret chip authentication key SKPICC: Let ° denote the group operation (i.e.
3646
addition or multiplication), and let i(x) denote the inverse of x. Since the chip sends CAPICC =
3647
SKMap,PICC-PACE-CAM ° i(SKPICC) to the terminal, a malicious attacker that gains knowledge of
3648
SKMap,PICC-PACE-CAM can reveal SKPICC by computing SKPICC = i(CAPICC) ° SKMap,PICC-PACE-
3649
CAM.
3650
Because of the Active Authentication is supported protocol by the TOE, the SFR is extended
3651
with Active Authentication Private Key.
3652
119. Application note (taken from[5], application note 48)
3653
Applied.
3654
FPT_EMS.1/SSCDPP
3655
TOE Emanation
3656
Hierarchical to: No other components
3657
Dependencies: No dependencies
3658
FPT_EMS.1.1_SSCD
3659
The TOE shall not emit emit variations in power consumption or timing during command
3660
execution349
in excess of non-useful information350
enabling access to RAD351
and SCD352
.
3661
FPT_EMS.1.2_SSCD
3662
The TSF shall ensure that unauthorized353
are unable to use the following interface
3663
electrical contacts354
to gain access to RAD355
and SCD356
.
3664
120. Application note (taken from [14], application note 18)
3665
The TOE shall prevent attacks against the SCD and other secret data where the attack is
3666
based on external observable physical phenomena of the TOE. Such attacks may be
3667
observable at the interfaces of the TOE or may origin from internal operation of the TOE or
3668
may origin by an attacker that varies the physical environment under which the TOE operates.
3669
The set of measurable physical phenomena is influenced by the technology employed to
3670
implement the TOE. Examples of measurable phenomena are variations in the power
3671
consumption, the timing of transitions of internal states, electromagnetic radiation due to
3672
internal operation, radio emission.
3673
349 [assignment: types of emissions]
350 [assignment: specified limits]
351 [assignment: list of types of TSF data]
352 [assignment: list of types of user data]
353 [assignment: type of users]
354 [assignment: type of connection]
355 [assignment: list of types of TSF data]
356 [assignment: list of types of user data]
IDentity Applet v3.4/eIDAS Security Target
Page 165 of 191
Due to the heterogeneous nature of the technologies that may cause such emanations,
3674
evaluation against state-of-the-art attacks applicable to the technologies employed by the TOE
3675
is assumed. Examples of such attacks are, but are not limited to, evaluation of TOE’s
3676
electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA),
3677
timing attacks, etc.
3678
FPT_PHP.1/SSCDPP
3679
Passive detection of physical attack
3680
Hierarchical to: No other components
3681
Dependencies: No dependencies
3682
FPT_PHP.1.1_SSCDPP
3683
The TSF shall provide unambiguous detection of physical tampering that might
3684
compromise the TSF.
3685
FPT_PHP.1.2_SSCDPP
3686
The TSF shall provide the capability to determine whether physical tampering with the
3687
TSF’s devices or TSF’s elements has occurred.
3688
6.2.Security Assurance Requirements for the TOE
3689
The assurance requirements for the evaluation of the TOE, its development and operating
3690
environment are to choose as the predefined assurance package EAL4 augmented by the
3691
following components:
3692
• ALC_DVS.2 (Sufficiency of security measures),
3693
• ATE_DPT.2 (Testing: security enforcing modules) and
3694
• AVA_VAN.5 (Advanced methodical vulnerability analysis).
3695
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 166 of 191
6.3.Security Requirements Rationale
3696
6.3.1. Security Functional Requirements Rationale
3697
The following table provides an overview for the coverage of the security functional requirements, and also gives evidence for sufficiency and
3698
necessity of the chosen SFRs.
3699
OT.CA2
OT.Chip_Auth_Proof[5]
OT.Chip_Auth_Proof_PACE_CAM
OT.Chip_Auth_Proof_AA
OT.Sens_Data_Conf
[5]
OT.AC_Pers_EAC2
OT.Sens_Data_EAC2
OT.Data_Integrity
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Identification
OT.AC_Pers
OT.Prot_Inf_Leak
OT.RI_EAC2
OT.Non_Interfere
OT.SCD/SVD_Gen
[14]
OT.Sigy_SigF
([14])
OT.Cap_Avail_Loader
Class FCS
FCS_CKM.1/CAM - - X - - - - X X X - - - - - - - -
FCS_COP.1/CAM - - X - - - - X X X - - - - - - - -
FCS_CKM.1/CA2 X - - - - - - - - - - - - - - - - -
FCS_CKM.1/RI - - - - - - - - - - - - - X - - - -
FCS_CKM.1/AA - - - X - - - - - - - - - - - - - -
FCS_COP.1/AA - - - X - - - - - - - - - - - - - -
Class FIA
FIA_UID.1/PACE_EAC1PP - - X - X - - X X X - X - - - - - -
FIA_UAU.1/PACE_EAC1PP - - - X X - - X X X - X - - - - - -
FIA_UAU.5/PACE_EAC1PP - - X - X - - X X X - X - - - - - -
FIA_API.1/PACE_CAM - - X - - - - X X X - - - - - - - -
FIA_UAU.1/SSCDPP - - - - - - - - - - - - - - - X X
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 167 of 191
OT.CA2
OT.Chip_Auth_Proof[5]
OT.Chip_Auth_Proof_PACE_CAM
OT.Chip_Auth_Proof_AA
OT.Sens_Data_Conf
[5]
OT.AC_Pers_EAC2
OT.Sens_Data_EAC2
OT.Data_Integrity
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Identification
OT.AC_Pers
OT.Prot_Inf_Leak
OT.RI_EAC2
OT.Non_Interfere
OT.SCD/SVD_Gen
[14]
OT.Sigy_SigF
([14])
OT.Cap_Avail_Loader
FIA_UAU.4/PACE_EAC1PP - - - X - - - X X X - - - - - - - -
FIA_API.1/AA - - - X - - - - - - - - - - - - - -
Class FDP
FDP_ACF.1/TRM - - - - X X X X - X - X - - X - - -
Class FMT
FMT_SMR.1 - X - - - X X X X X X X - - X - - -
FMT_LIM.1/Loader - - - - - - - - - - - - - - - - - X
FMT_LIM.2/Loader - - - - - - - - - - - - - - - - - X
FMT_MTD.1/KEY_READ_EAC1PP - X - X X - - X X X - X - - - - - -
FMT_MTD.1/AA_Private_Key - - X - - - - - - - X - - - - - -
Class FPT
FPT_EMS.1/EAC1PP - - - - - - - - - - - X X - X - - -
FPT_EMS.1/EAC2PP - - - - - X - - - - - - X - X - - -
FPT_EMS.1/SSCDPP - - - - - - - - - - - - - X - - -
Table 11 Coverage of Security Objectives for the TOE by SFRs
3700
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 168 of 191
According to [1], tracing between SFRs and security objectives must ensure that 1) each SFR
3701
traces back to at least one security objective, and 2) that each security objective for the TOE
3702
has at least one SFR tracing to it. This is illustrated for
3703
1. SFRs that have been newly added or refined within this ST or [20] by checking the rows
3704
of Table 11 , and for SFRs that are merely iterated or simply included due to claims of
3705
other protection profiles by looking up the rationale of that PP
3706
2. for newly introduced security objectives in this ST or [20] by checking the non-cursive
3707
columns of Table 11 , and for the other security objectives by looking up the rationale
3708
of that PP.
3709
In other words, in Table 11 , we list only:
3710
• SFRs that have been newly added or refined within this ST or [20]. Mere iterations or
3711
simple inclusions due to claims of other protection profiles are not listed, however. For
3712
their coverage we refer to the respective claimed PP.
3713
• Security objectives that are newly introduced in this ST or [20], and their related SFRs.
3714
• Security objectives for the TOE that are affected by the above newly added or refined
3715
SFRs.
3716
In case an SFR was refined in order to ensure the unified terminology usage, those SFRs are
3717
not listed in Table 11 or justifies below, because these refinements have no security impacts.
3718
Analogously, we limit our justification to the above SFRs and security objectives. For other
3719
security objectives, and for the justification of security objectives w.r.t. SFRs that are included
3720
or iterated from claimed protection profiles, we refer to the detailed rationales in [5], [6] and
3721
[14].
3722
OT.Chip_Auth_Proof_PACE_CAM is a newly introduced security objective that aims to
3723
ensure the authenticity of the electronic document's chip by the PACE-CAM protocol, in
3724
particular in the context of an ePassport application. This is supported by FCS_CKM.1/CAM
3725
for cryptographic key-generation, and FIA_API.1/PACE_CAM and FCS_COP.1/CAM for the
3726
implementation itself, as well as FIA_UID.1/PACE_EAC1PP and
3727
FIA_UAU.5/PACE_EAC1PP, the latter supporting the PACE protocol.
3728
OT.Chip_Auth_Proof_AA is a newly introduced security objective that aims to ensure the
3729
authenticity of the electronic document’s chip by the Active Authentication protocol, in
3730
particular in the context of an ePassport Application. This is supported by FCS_CKM.1/AA for
3731
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 169 of 191
cryptographic key generation, and FIA_API.1/AA, FIA_UAU.4/PACE_EAC1PP and
3732
FCS_COP.1/AA for the implementation itself. The FMT_MTD.1/KEY_READ_EAC1PP
3733
ensures the authenticity of the TOE, because it restricts the ability to read the Active
3734
Authentication private key to none. These do not affect the discussion of the rationale of [5].
3735
The OT.AC_Pers enforce that all TSF data can be written by authorized Personalisation Agent
3736
only and this is supported by FMT_MTD.1/AA_Private_Key for the Active Authentication key
3737
pair.
3738
FIA_UAU.1/SSCDPP is refined here in a way that the TOE supports additionally EAC2 based
3739
access control w.r.t. SSCD-related user data. This does not affect the discussion of the
3740
rationale of [14].
3741
FDP_ACF.1/TRM unifies the access control SFPs of FDP_ACF.1/TRM_EAC2PP and
3742
FDP_ACF.1/TRM_EAC1PP. Both access control SFPs however are maintained w.r.t.
3743
sensitive EAC1-protected data and EAC2-protected data. Thus the discussion of the rationale
3744
of [5] and [6] remains unaffected.
3745
FMT_SMR.1/EAC1PP and FMT_SMR.1/EAC2PP have been unified to FMT_SMR.1 by
3746
adding additional roles. For all security objectives affected, FMT_SMR.1 supports related roles
3747
analogously as in the discussion of the rationales of [5] and [6].
3748
The security objective OT.Cap_Avail_Loader is directly covered by the SFRs
3749
FMT_LIM.1/Loader and FMT_LIM.2/Loader, which limits the availability of the loader, as
3750
required by the objective.
3751
FPT_EMS.1/EAC1PP and FPT_EMS.1/EAC2PP together define all protected data. Since all
3752
previous data are included, the discussion of the rationales of [5] and [6] is not affected.
3753
The objective OT.Non_Interfere aims to ensure that no security related interferences between
3754
the implementations of the different access control mechanisms exist that allow unauthorized
3755
access of user or TSF-Data. This objective is fulfilled by enforcing the access control SFPs, in
3756
particular FDP_ACF.1/TRM in connection with FDP_ACC.1/TRM_EAC1PP. Related roles are
3757
supported by FMT_SMR.1. Interferences that are observable by emissions from the TOE are
3758
prevented due to FPT_EMS.1/EAC1PP, FPT_EMS.1/EAC2PP, and FPT_EMS.1/SSCDPP,
3759
where the set union of all defined data covers all relevant data.
3760
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 170 of 191
The security objective OT.CA2 aims at enabling verification of the authenticity of the TOE as
3761
a whole device. This objective is mainly achieved as described in [20]. The secure generation
3762
of cryptography key pair is ensured by FCS_CKM.1/CA2.
3763
The security objective OT.RI_EAC2 aims at providing a way to pseudonymously identify an
3764
electronic document holder without granting a terminal read access to sensitive user data. This
3765
objective is mainly achieved as described in [20]. The secure generation of cryptography key
3766
pair is ensured by FCS_CKM.1/RI.
3767
6.3.2. Rationale for SFR’s Dependencies
3768
The dependency analysis for the security functional requirements shows that the basis for
3769
mutual support and internal consistency between all defined functional requirements is
3770
satisfied. All dependencies between the chosen functional components are analyzed, and non-
3771
dissolved dependencies are appropriately explained.
3772
The dependency analysis has directly been made within the description of each SFR in Section
3773
6.1 above. All dependencies being expected by [2] and by extended components definition in
3774
Chapter 5 are either fulfilled, or their non-fulfillment is justified.
3775
6.3.3. Security Assurance Requirements Rationale
3776
The current assurance package was chosen based on the predefined assurance package
3777
EAL4. This package permits a developer to gain maximum assurance from positive security
3778
engineering based on good commercial development practices which, through rigorous, do not
3779
require substantial specialist knowledge, skills, and other resources. EAL4 is the highest level,
3780
at which it is likely to retrofit to an existing product line in an economically feasible way. EAL4
3781
is applicable in those circumstances where developers or users require a moderate to high
3782
level of independently assured security in conventional commodity TOEs and are prepared to
3783
incur additional security specific engineering costs.
3784
The selection of the component ALC_DVS.2 provides a higher assurance of the security of the
3785
electronic document’s development and manufacturing, especially for the secure handling of
3786
sensitive material.
3787
The selection of the component ATE_DPT.2 provides a higher assurance than the predefined
3788
EAL4 package due to requiring the functional testing of SFR-enforcing modules.
3789
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 171 of 191
The selection of the component AVA_VAN.5 provides a higher assurance than the predefined
3790
EAL4 package, namely requiring a vulnerability analysis to assess the resistance to
3791
penetration attacks performed by an attacker possessing a high attack potential (see also
3792
Table 3, entry ‘Attacker’). This decision represents a part of the conscious security policy for
3793
the electronic document required by the electronic document issuer and reflected by the
3794
current ST.
3795
The set of assurance requirements being part of EAL4 fulfills all dependencies a priori. The
3796
augmentation of EAL4 chosen comprises the following assurance components: ALC_DVS.2,
3797
ATE_DPT.2 and AVA_VAN.5. For these additional assurance components, all dependencies
3798
are met or exceeded in the EAL4 assurance package. Below we list only those assurance
3799
requirements that are additional to EAL4.
3800
ALC_DVS.2
3801
Dependencies:
3802
None
3803
ATE_DPT.2
3804
Dependencies:
3805
ADV_ARC.1, ADV_TDS.3, ATE_FUN.1
3806
fulfilled by ADV_ARC.1, ADV_TDS.3, ATE_FUN.1
3807
AVA_VAN.5
3808
Dependencies:
3809
ADV_ARC.1, ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, AGD_OPE.1, AGD_PRE.1,
3810
ATE_DPT.1
3811
fulfilled by ADV_ARC.1, ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, AGD_OPE.1,
3812
AGD_PRE.1, ATE_DPT.2
3813
6.3.4. Security Requirements – Internal Consistency
3814
The following part of the security requirements rationale shows that the set of security
3815
requirements for the TOE consisting of the security functional requirements (SFRs) and the
3816
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 172 of 191
security assurance requirements (SARs) are internally consistent. The analysis of the TOE´s
3817
security requirements with regard to their mutual support and internal consistency
3818
demonstrates:
3819
The dependency analysis in Section 6.3.2 for the security functional requirements shows that
3820
the basis for internal consistency between all defined functional requirements is satisfied. All
3821
dependencies between the chosen functional components are analyzed and non-satisfied
3822
dependencies are appropriately justified.
3823
All subjects and objects addressed by more than one SFR are also treated in a consistent way:
3824
the SFRs impacting them do not require any contradictory property or behavior of these
3825
‘shared’ items.
3826
The assurance package EAL4 is a predefined set of internally consistent assurance
3827
requirements. The dependency analysis for the sensitive assurance components in Section
3828
6.3.3 shows that the assurance requirements are internally consistent as all (additional)
3829
dependencies are satisfied and no inconsistency appears.
3830
Inconsistency between functional and assurance requirements can only arise due to
3831
functional-assurance dependencies not being met. As shown in Section 6.3.2 and Section
3832
6.3.3, the chosen assurance components are adequate for the functionality of the TOE. Hence,
3833
there are no inconsistencies between the goals of these two groups of security requirements.
3834
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 173 of 191
7. TOE SUMMARY SPECIFICATION
3835
7.1.TOE Security Functions
3836
7.1.1. TSF.AccessControl
3837
The TOE enforces access control in order to access User Data and TSF-data and maintains
3838
different security roles.
3839
SFR Description
FIA_AFL.1/Suspend_PIN_EAC2PP The TSF responsible to suspend the reference value
of PIN.
FIA_AFL.1/Block_PIN_EAC2PP The TSF responsible to block the reference value of
PIN.
FIA_AFL.1/SSCDPP The TSF responsible to block the reference value of
RAD.
FIA_UID.1/PACE_EAC2PP The TSF responsible to restrict other TSF-mediated
actions on behalf of that user before the user
identification.
FIA_UID.1/EAC2_Terminal_EAC2PP The TSF responsible to restrict other TSF-mediated
actions on behalf of that user before the user
identification.
FIA_UAU.1/PACE_EAC2PP The TSF responsible to restrict other TSF-mediated
actions on behalf of that user before the user
authentication.
FIA_UAU.1/EAC2_Terminal_EAC2PP The TSF responsible to restrict other TSF-mediated
actions on behalf of that user before the user
authentication.
FIA_AFL.1/PACE_EAC2PP The TSF responsible to delay each following
authentication attempt.
FIA_UID.1/PACE_EAC1PP The TSF responsible to restrict other TSF-mediated
actions on behalf of that user before the user
identification.
FIA_UAU.1/PACE_EAC1PP The TSF responsible to restrict other TSF-mediated
actions on behalf of that user before the user
authentication.
FIA_AFL.1/PACE_EAC1PP Equivalent to FIA_AFL.1/PACE_EAC2PP.
FIA_UID.1/SSCDPP The TSF responsible to restrict other TSF-mediated
actions on behalf of that user before the user
identification.
FIA_UAU.1/SSCDPP The TSF responsible to restrict other TSF-mediated
actions on behalf of that user before the user
authentication.
FDP_ACC.1/TRM_EAC2PP This TSF responsible to enforce the Access Control
SFP.
FDP_ACF.1/TRM This TSF responsible to enforce the Access Control
SFP.
FDP_ACC.1/TRM_EAC1PP Equivalent to FDP_ACC.1/TRM_EAC2PP.
FDP_ACC.1/SCD/SVD_Generation_SSCDPP This TSF responsible to enforce the SCD/SVD
Generation SFP.
FDP_ACF.1/SCD/SVD_Generation_SSCDPP This TSF responsible to enforce the SCD/SVD
Generation SFP.
FDP_ACC.1/SVD_Transfer_SSCDPP This TSF responsible to enforce the SVD Transfer
SFP.
FDP_ACF.1/SVD_Transfer_SSCDPP This TSF responsible to enforce the SVD Transfer
SFP.
FDP_ACC.1/Signature-creation_SSCDPP This TSF responsible to enforce the Signature
Creation SFP.
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 174 of 191
FDP_ACF.1/Signature-creation_SSCDPP This TSF responsible to enforce the Signature
Creation SFP.
FMT_MTD.1/CVCA_INI_EAC2PP This TSF responsible to restrict the ability to write
certain objects.
FMT_MTD.1/CVCA_UPD_EAC2PP This TSF responsible to restrict the ability to update
certain objects.
FMT_MTD.1/DATE_EAC2PP This TSF responsible to restrict the ability to modify the
current date.
FMT_MTD.1/PA_EAC2PP This TSF responsible to restrict the ability to write
certain objects.
FMT_MTD.1/SK_PICC_EAC2PP This TSF responsible to restrict the ability to create or
load the Chip Authentication private key(s) (SKPICC)
and the Restricted Identification Private Key(s).
FMT_MTD.1/KEY_READ_EAC2PP This TSF responsible to restrict the ability to read
certain objects.
FMT_SMR.1 This TSF responsible to maintain the Manufacturer,
Personalization Agent, Country Verifying Certification
Authority (CVCA), Document Verifier (DV), Terminal,
PACE Terminal, EAC2 terminal, if the eID, ePassport
and/or eSign application are active, EAC1 terminal, if
the ePassport application is active, Electronic
Document Holder roles.
FMT_SMR.1/SSCDPP This TSF responsible to maintain the R.Admin and
R.Sigy roles.
FMT_MOF.1/SSCDPP This TSF responsible to restrict the ability to enable the
functions signature creation function.
FMT_MSA.1/Admin_SSCDPP This TSF responsible to enforce the SCD/SVD
Generation SFP.
FMT_MSA.1/SignatorySSCDPP This TSF responsible to enforce the SCD/SVD
Generation SFP.
FMT_MSA.3/SSCDPP This TSF responsible to enforce the SCD/SVD
Generation SFP, SVD Transfer SFP and Signature
Creation SFP.
FMT_MTD.1/Admin_SSCDPP This TSF responsible to restrict the ability to create the
RAD.
FMT_MTD.1/Signatory_SSCDPP This TSF responsible to restrict the ability to modify the
RAD
FMT_MTD.1/CVCA_INI_EAC1PP This TSF responsible to shall restrict the ability to write
certain objects.
FMT_MTD.1/CVCA_UPD_EAC1PP This TSF responsible to restrict the ability to update
certain objects.
FMT_MTD.1/DATE_EAC1PP This TSF responsible to restrict the ability to modify the
current date.
FMT_MTD.1/CAPK_EAC1PP This TSF responsible to restrict the ability to create,
load the Chip Authentication Private Key.
FMT_MTD.1/PA_EAC1PP This TSF responsible to restrict the ability to write the
Document Security Object (SOD).
FMT_MTD.1/KEY_READ_EAC1PP This TSF responsible to restrict the ability to read
certain objects.
FMT_MTD.1/AA_Private_Key This TSF responsible to restrict the ability to create or
load the Active Authentication Private Key.
7.1.2. TSF.Authenticate
3840
The TOE supports several authentication mechanism in order to authenticate the Users,
3841
Terminals and to prove the genuineness of the electronic document.
3842
The supported mechanism and protocols are based on ICAO and BSI standards [7], [8], [16],
3843
[17] and [18].
3844
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 175 of 191
Supported authentication mechanism:
3845
• Password Authenticated Connection Establishment (PACE) [7], [16], [17].
3846
o Generic Mapping
3847
o Chip Authentication Mapping
3848
• Active Authentication [7]
3849
• Chip Authentication version 1 [16]
3850
• Terminal Authentication version 1 [16]
3851
• Chip Authentication version 2 [17]
3852
• Terminal Authentication version 2 [17]
3853
• Restricted Identification [17]
3854
• Symmetric Authentication (Device authentication) [30]
3855
• Symmetric Role Authentication [30]
3856
• User Verification [30]
3857
SFR Description
FIA_AFL.1/Suspend_PIN_EAC2PP This TSF responsible for PACE.
FIA_AFL.1/Block_PIN_EAC2PP This TSF responsible for PACE.
FIA_API.1/CA_EAC2PP This TSF responsible for Chip Authentication v2.
FIA_API.1/RI_EAC2PP This TSF responsible for Restricted Identification.
FIA_UID.1/PACE_EAC2PP This TSF responsible for PACE.
FIA_UID.1/EAC2_Terminal_EAC2PP This TSF responsible for PACE.
FIA_UAU.1/PACE_EAC2PP This TSF responsible for PACE.
FIA_UAU.1/EAC2_Terminal_EAC2PP This TSF responsible for PACE and Terminal
Authentication v2.
FIA_UAU.4/PACE_EAC2PP This TSF responsible for PACE, Terminal
Authentication v2 and Symmetric Authentication.
FIA_UAU.5/PACE_EAC2PP This TSF responsible for PACE, Terminal
Authentication v2, Chip Authentication v2 and
Symmetric Authentication.
FIA_UAU.6/CA_EAC2PP This TSF responsible for Chip Authentication v2.
FIA_AFL.1/PACE_EAC2PP This TSF responsible for PACE.
FIA_UAU.6/PACE_EAC2PP This TSF responsible for PACE.
FIA_UID.1/PACE_EAC1PP This TSF responsible for PACE, Chip Authentication
v1 and Chip Authentication Mapping (PACE-CAM).
FIA_UAU.1/PACE_EAC1PP This TSF responsible for PACE, Chip Authentication
v1, Terminal Authentication v1 and Chip Authentication
Mapping (PACE-CAM).
FIA_UAU.4/PACE_EAC1PP This TSF responsible for PACE, Symmetric
Authentication, Terminal Authentication v1 and Active
Authentication.
FIA_UAU.5/PACE_EAC1PP This TSF responsible for PACE, Chip Authentication
Mapping (PACE-CAM), Symmetric Authentication,
Terminal Authentication v1.
FIA_UAU.6/EAC_EAC1PP This TSF responsible for Chip Authentication v1
FIA_API.1/EAC1PP This TSF responsible for Chip Authentication v1
FIA_API.1/PACE_CAM This TSF responsible for Chip Authentication Mapping
FIA_API.1/AA This TSF responsible for Active Authentication
FIA_AFL.1/PACE_EAC1PP Equivalent to FIA_AFL.1/PACE_EAC2PP.
FIA_UAU.6/PACE_EAC1PP This TSF responsible for PACE.
FIA_AFL.1/SSCDPP This TSF responsible for User Verification.
FDP_ACF.1/TRM This TSF responsible for Terminal Authentication and
PACE.
FDP_ACF.1/SCD/SVD_Generation_SSCDPP This TSF responsible for User Verification
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 176 of 191
FDP_ACF.1/SVD_Transfer_SSCDPP This TSF responsible for R.Admin.
FDP_ACF.1/Signature-creation_SSCDPP This TSF responsible for User Verification.
FTP_ITC.1/PACE_EAC2PP This TSF responsible for PACE
FTP_ITC.1/CA_EAC2PP This TSF responsible for Chip Authentication v2
FTP_ITC.1/PACE_EAC1PP This TSF responsible for PACE.
FMT_MTD.1/CVCA_INI_EAC2PP This TSF responsible for authentication of the
Personalisation Agent.
FMT_MTD.1/CVCA_UPD_EAC2PP This TSF responsible for the authentication of Country
Verifying Certification Authority.
FMT_MTD.1/DATE_EAC2PP This TSF responsible for the authentication of CVCA,
DV and the EAC2 Terminal
FMT_MTD.1/PA_EAC2PP This TSF responsible for authentication of
Personalization Agent.
FMT_MTD.1/SK_PICC_EAC2PP This TSF responsible for authentication of the
Personalisation Agent.
FMT_MTD.1/Initialize_PIN_EAC2PP This TSF responsible for authentication of the
Personalisation Agent.
FMT_MTD.1/Change_PIN_EAC2PP This TSF responsible for authentication of Document
Holder and the EAC2 Terminal (with Terminal
Authorisation level for PIN management).
FMT_MTD.1/Resume_PIN_EAC2PP This TSF responsible for authentication of Document
Holder
FMT_MTD.1/Unblock_PIN_EAC2PP This TSF responsible for authentication of Document
Holder and the EAC2 Terminal (with Terminal
Authorisation level for PIN management).
FMT_MTD.1/Activate_PIN_EAC2PP This TSF responsible for authentication of the EAC2
Terminal (with Terminal Authorisation level for PIN
management).
FMT_MTD.3/EAC2PP This TSF responsible for the Terminal Authentication
v2.
FMT_SMF.1/SSCDPP This TSF responsible to provide the security functions.
FMT_MOF.1/SSCDPP This TSF responsible for authentication of R.Sigy
FMT_MSA.1/Admin_SSCDPP This TSF responsible for authentication of R.Admin
FMT_MSA.1/SignatorySSCDPP This TSF responsible for authentication of R.Sigy
FMT_MSA.3/SSCDPP This TSF responsible for authentication of R.Sigy and
R.Admin
FMT_MSA.4/SSCDPP This TSF responsible for authentication of R.Sigy and
R.Admin
FMT_MTD.1/Admin_SSCDPP This TSF responsible for authentication of R.Admin
FMT_MTD.1/Signatory_SSCDPP This TSF responsible for authentication of R.Sigy
FMT_MTD.1/CVCA_INI_EAC1PP This TSF responsible for authentication of
Personalization Agent.
FMT_MTD.1/CVCA_UPD_EAC1PP This TSF responsible for authentication of Country
Verifying Certification Authority.
FMT_MTD.1/DATE_EAC1PP This TSF responsible to equivalent to
FMT_MTD.1/DATE_EAC2PP.
FMT_MTD.1/CAPK_EAC1PP This TSF responsible for This TSF responsible for
authentication of Personalization Agent or the
Manufacturer.
FMT_MTD.1/PA_EAC1PP This TSF responsible for authentication of
Personalization Agent.
FMT_MTD.1/AA_Private_Key This TSF responsible for authentication of
Personalization Agent.
FMT_MTD.3/EAC1PP This TSF responsible for the Terminal Authentication
v2.
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 177 of 191
7.1.3. TSF.SecureManagement
3858
The TOE enforces the secure management of the security attributes, data and functions.
3859
Furthermore the TOE restricts the available commands in each TOE life-cycle phase.
3860
SFR Description
FMT_MTD.1/CVCA_INI_EAC2PP This TSF responsible to evaluate whether the
Personalisation Agent is authenticated, and it has right
to write initial CVCA Public Key, meta-data of the initial
CVCA Certificate and initial Current Date.
FMT_MTD.1/CVCA_UPD_EAC2PP This TSF responsible to evaluate whether the Country
Verifying Certification Authority is authenticated, and it
has right to update CVCA Public Key (PKCVCA) and
meta-data of the CVCA Certificate.
FMT_SMF.1/EAC2PP This TSF responsible to provide part of the security
functions.
FMT_MTD.1/DATE_EAC2PP This TSF responsible to evaluate whether a CVCA,
Document Verifier, or an EAC2 terminal is
authenticated and it has right to modify Current Date.
FMT_MTD.1/PA_EAC2PP This TSF responsible to evaluate whether a
Personalisation Agent is authenticated, and it has right
to write the card/chip security object(s) (SOC) and the
document Security Object (SOD).
FMT_MTD.1/SK_PICC_EAC2PP This TSF responsible to evaluate whether a
Personalisation Agent is authenticated, and it has right
to create or load the Chip Authentication private key(s)
(SKPICC) and the Restricted Identification Private
Key(s).
FMT_MTD.1/KEY_READ_EAC2PP This TSF responsible to restrict the ability to read
certain objects.
FMT_MTD.1/Initialize_PIN_EAC2PP This TSF responsible to evaluate whether a
Personalisation Agent is authenticated, and it has right
to write the initial PIN and PUK
FMT_MTD.1/Change_PIN_EAC2PP This TSF responsible to evaluate whether an
Electronic Document Holder is authenticated with PUK
or a Terminal with Terminal Authorisation level for PIN
management is authenticated and it has right to
change the blocked PIN.
FMT_MTD.1/Resume_PIN_EAC2PP This TSF responsible to evaluate whether an
Electronic Document Holder is authenticated, and it
has right to resume the suspended PIN.
FMT_MTD.1/Unblock_PIN_EAC2PP This TSF responsible to evaluate whether an
Electronic Document Holder is authenticated with PUK
or a Terminal with Terminal Authorisation level for PIN
management is authenticated and it has right to
unblock the blocked PIN.
FMT_MTD.1/Activate_PIN_EAC2PP This TSF responsible to evaluate whether a Terminal
with Terminal Authorisation level for PIN management
is authenticated and it has right to activate or
deactivate the PIN.
FMT_SMF.1/SSCDPP This TSF responsible to provide part of the security
functions.
FMT_MOF.1/SSCDPP This TSF responsible to evaluate whether a R.Sigy is
authenticated and it has right to enable the signature
creation function.
FMT_MSA.1/Admin_SSCDPP This TSF responsible to evaluate whether a R.Admin
is authenticated and it has right to modify the
SCD/SVD management security attribute.
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 178 of 191
FMT_MSA.1/SignatorySSCDPP This TSF responsible to evaluate whether a R.Sigy is
authenticated and it has right to modify the SCD/SVD
operational security attribute.
FMT_MSA.2/SSCDPP This TSF responsible to ensure that only secure values
are accepted for SCD/SVD Management and SCD
operational
FMT_MSA.3/SSCDPP This TSF responsible to provide restrictive default
values for security attributes.
FMT_MSA.4/SSCDPP This TSF responsible for security attribute value
inheritance.
FMT_MTD.1/Admin_SSCDPP This TSF responsible to evaluate whether a R.Admin
is authenticated, and it has right to create the RAD.
FMT_MTD.1/Signatory_SSCDPP This TSF responsible to evaluate whether a R.Sigy is
authenticated and it has right to modify the RAD.
FMT_MTD.1/CVCA_INI_EAC1PP This TSF responsible to evaluate whether the
Personalisation Agent is authenticated, and it has right
to write initial Country Verifying Certification Authority
Public Key, initial Country Verifying Certification
Authority Certificate, initial Current Date.
FMT_MTD.1/CVCA_UPD_EAC1PP This TSF responsible to evaluate whether the Country
Verifying Certification Authority is authenticated, and it
has right to update Country Verifying Certification
Authority Public Key, Country Verifying Certification
Authority Certificate.
FMT_SMF.1/EAC1PP This TSF responsible to provide part of the security
functions.
FMT_MTD.1/DATE_EAC1PP This TSF responsible to equivalent to
FMT_MTD.1/DATE_EAC2PP.
FMT_MTD.1/CAPK_EAC1PP This TSF responsible to evaluate whether a
Personalisation Agent or Manufacturer is
authenticated, and it has right to create or load the Chip
Authentication private key.
FMT_MTD.1/PA_EAC1PP This TSF responsible to evaluate whether a
Personalisation Agent is authenticated, and it has right
to write the document Security Object (SOD).
FMT_MTD.1/KEY_READ_EAC1PP This TSF responsible to restrict the ability to read
cryptographic keys.
FMT_MTD.1/AA_Private_Key This TSF responsible to evaluate whether a
Personalisation Agent is authenticated, and it has right
to create or load the Active Authentication Private Key.
7.1.4. TSF.CryptoKey
3861
The TOE uses several cryptographic services such as digital signature creation and
3862
verification, asymmetric and symmetric cryptography, random number generation and
3863
complete key management.
3864
Furthermore TSF.CryptoKey provides the secure messaging for the TOE.
3865
SFR Description
FCS_CKM.1/DH_PACE_EAC2PP This TSF responsible the Applet part of key agreement
for PACE.
FCS_COP.1/SHA_EAC2PP This TSF responsible the Applet part of hash
generation.
FCS_COP.1/SIG_VER_EAC2PP This TSF responsible the Applet part of digital
signature verification.
FCS_COP.1/PACE_ENC_EAC2PP This TSF responsible the Applet part of secure
messaging – encryption and decryption.
FCS_COP.1/PACE_MAC_EAC2PP This TSF responsible the Applet part of secure
messaging – message authentication code.
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 179 of 191
FCS_CKM.4/EAC2PP This TSF responsible the Applet part of cryptographic
key destruction.
FCS_RND.1/EAC2PP This TSF responsible the Applet part of random
number generation.
FCS_CKM.1/DH_PACE_EAC1PP This TSF responsible the Applet part of key agreement
for PACE.
FCS_CKM.4/EAC1PP Equivalent to FCS_CKM.4/EAC2PP.
FCS_COP.1/PACE_ENC_EAC1PP This TSF responsible the Applet part of secure
messaging – encryption and decryption.
FCS_COP.1/PACE_MAC_EAC1PP This TSF responsible the Applet part of secure
messaging – message authentication code.
FCS_RND.1/EAC1PP Equivalent to FCS_RND.1/EAC2PP.
FCS_CKM.1/CA_EAC1PP This TSF responsible the Applet part of key agreement
for Chip Authentication v1.
FCS_COP.1/CA_ENC_EAC1PP This TSF responsible the Applet part of secure
messaging – encryption and decryption.
FCS_COP.1/SIG_VER_EAC1PP This TSF responsible the Applet part of digital
signature verification.
FCS_COP.1/CA_MAC_EAC1PP This TSF responsible the Applet part of secure
messaging – message authentication code.
FCS_CKM.1/CA2 This TSF responsible the Applet part of Chip
Authentication version 2 Key pair(s) generation.
FCS_CKM.1/RI This TSF responsible the Applet part of Restricted
Identification Key pair (s) generation.
FCS_CKM.1/AA This TSF responsible the Applet part of Active
Authentication Key Pair generation.
FCS_COP.1/AA This TSF responsible the Applet part of digital
signature generation.
FCS_CKM.1/CAM This TSF responsible the Applet part of PACE-CAM
protocol implementation.
FCS_COP.1/CAM This TSF responsible the Applet part of PACE-CAM
protocol implementation.
FCS_CKM.1/SSCDPP This TSF responsible the Applet part of SCD/SVD pair
generation.
FCS_COP.1/SSCDPP This TSF responsible the Applet part of digital
signature creation.
FIA_API.1/CA_EAC2PP This TSF responsible the Applet part of cryptographic
operation for Chip Authentication v2.
FIA_API.1/RI_EAC2PP This TSF responsible the Applet part of cryptographic
operation for Restricted Identification.
FIA_API.1/EAC1PP This TSF responsible the Applet part of cryptographic
operation for Chip Authentication v1.
FIA_API.1/PACE_CAM This TSF responsible the Applet part of cryptographic
operation for Chip Authentication Mapping.
FIA_API.1/AA This TSF responsible the Applet part of cryptographic
operation for Active Authentication.
FDP_RIP.1/EAC2PP This TSF responsible to call the Platform functionalities
to destroy cryptographic keys.
FDP_UCT.1/TRM_EAC2PP This TSF responsible the Applet part of secure
messaging.
FDP_UIT.1/TRM_EAC2PP This TSF responsible the Applet part of secure
messaging.
FDP_RIP.1/EAC1PP This TSF responsible to call the Platform functionalities
to destroy cryptographic keys.
FDP_UCT.1/TRM_EAC1PP Equivalent to FDP_UCT.1/TRM_EAC2PP.
FDP_UIT.1/TRM_EAC1PP Equivalent to FDP_UIT.1/TRM_EAC2PP.
FDP_RIP.1/SSCDPP This TSF responsible the Applet part of de-allocation
of the resource SCD.
FTP_ITC.1/PACE_EAC2PP This TSF responsible the Applet part of cryptographic
operation for trusted channel.
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 180 of 191
FTP_ITC.1/CA_EAC2PP This TSF responsible the Applet part of cryptographic
operation for trusted channel.
FTP_ITC.1/PACE_EAC1PP This TSF responsible the Applet part of cryptographic
operation for trusted channel.
7.1.5. TSF.AppletParametersSign
3866
The TOE enforces the integrity of itself in each life cycle phases.
3867
SFR Description
FPT_TST.1/EAC2PP This TSF responsible for initial start-up, periodically
during normal operation testing.
FPT_TST.1/EAC1PP Equivalent to FPT_TST.1/EAC2PP.
FPT_TST.1/SSCDPP Subsumed by FPT_TST.1/EAC2PP.
7.1.6. TSF.Platform
3868
The TOE relies on the certified functions and services of the Platform. This TSF is collection
3869
of those SFRs, which are uses these functions and services.
3870
SFR Description
FCS_CKM.1/DH_PACE_EAC2PP This TSF responsible the Platform part of key
agreement for PACE.
FCS_COP.1/SHA_EAC2PP This TSF responsible the Platform part of hash
generation.
FCS_COP.1/SIG_VER_EAC2PP This TSF responsible the Platform part of digital
signature verification.
FCS_COP.1/PACE_ENC_EAC2PP This TSF responsible the Platform part of secure
messaging – encryption and decryption.
FCS_COP.1/PACE_MAC_EAC2PP This TSF responsible the Platform part of secure
messaging – message authentication code.
FCS_CKM.4/EAC2PP This TSF responsible the Platform part of
cryptographic key destruction.
FCS_RND.1/EAC2PP This TSF responsible the Platform part of random
number generation.
FCS_CKM.1/DH_PACE_EAC1PP This TSF responsible the Platform part of key
agreement for PACE.
FCS_CKM.4/EAC1PP Equivalent to FCS_CKM.4/EAC2PP.
FCS_COP.1/PACE_ENC_EAC1PP This TSF responsible the Platform part of secure
messaging – encryption and decryption.
FCS_COP.1/PACE_MAC_EAC1PP This TSF responsible the Platform part of secure
messaging – message authentication code.
FCS_RND.1/EAC1PP Equivalent to FCS_RND.1/EAC2PP.
FCS_CKM.1/CA_EAC1PP This TSF responsible the Platform part of key
agreement for Chip Authentication v1.
FCS_COP.1/CA_ENC_EAC1PP This TSF responsible the Platform part of secure
messaging – encryption and decryption.
FCS_COP.1/SIG_VER_EAC1PP This TSF responsible the Platform part of digital
signature verification.
FCS_COP.1/CA_MAC_EAC1PP This TSF responsible the Platform part of secure
messaging – message authentication code.
FCS_CKM.1/CA2 This TSF responsible the Platform part of Chip
Authentication version 2 Key pair(s) generation.
FCS_CKM.1/RI This TSF responsible the Platform part of Restricted
Identification Key pair(s) generation.
FCS_CKM.1/AA This TSF responsible the Platform part of Active
Authentication Key Pair generation.
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 181 of 191
FCS_COP.1/AA This TSF responsible the Platform part of digital
signature generation.
FCS_CKM.1/CAM This TSF responsible the Platform part of PACE-CAM
protocol implementation.
FCS_COP.1/CAM This TSF responsible the Platform part of PACE-CAM
protocol implementation.
FCS_CKM.1/SSCDPP This TSF responsible the Platform part of SCD/SVD
pair generation.
FCS_CKM.4/SSCDPP This TSF responsible the Platform part of
cryptographic key destruction.
FCS_COP.1/SSCDPP This TSF responsible the Platform part of digital
signature creation.
FIA_API.1/CA_EAC2PP This TSF responsible the Platform part of
cryptographic operation for Chip Authentication v2.
FIA_API.1/RI_EAC2PP This TSF responsible the Platform part of
cryptographic operation for Restricted Identification.
FIA_UID.1/PACE_EAC2PP This TSF responsible for the identifier data of the TOE.
FIA_UID.1/EAC2_Terminal_EAC2PP This TSF responsible for the identifier data of the TOE.
FIA_UAU.1/PACE_EAC2PP This TSF responsible for the identifier data of the TOE.
FIA_UAU.1/EAC2_Terminal_EAC2PP This TSF responsible for the identifier data of the TOE.
FIA_UID.1/PACE_EAC1PP This TSF responsible for the identifier data of the TOE.
FIA_UAU.1/PACE_EAC1PP This TSF responsible for the identifier data of the TOE.
FIA_UAU.4/PACE_EAC2PP This TSF responsible for fresh random numbers for
PACE, Terminal Authentication v2 and Symmetric
Authentication.
FIA_UAU.5/PACE_EAC2PP This TSF responsible for Platform part of cryptographic
operation for PACE, Terminal Authentication v2, Chip
Authentication v2 and Symmetric Authentication.
FIA_UAU.6/CA_EAC2PP This TSF responsible for Platform part of cryptographic
operation for Chip Authentication v2.
FIA_UAU.6/PACE_EAC2PP This TSF responsible for Platform part of cryptographic
operation for PACE.
FIA_UAU.4/PACE_EAC1PP This TSF responsible for Platform part of cryptographic
operation for PACE, Symmetric Authentication,
Terminal Authentication v1 and Active Authentication.
FIA_UAU.5/PACE_EAC1PP This TSF responsible for Platform part of cryptographic
operation for PACE, Chip Authentication Mapping
(PACE-CAM), Symmetric Authentication, Terminal
Authentication v1.
FIA_UAU.6/PACE_EAC1PP This TSF responsible for Platform part of cryptographic
operation for PACE.
FIA_UAU.6/EAC_EAC1PP This TSF responsible for Platform part of cryptographic
operation for Chip Authentication v1
FIA_API.1/EAC1PP This TSF responsible the Platform part of
cryptographic operation for Chip Authentication v1.
FIA_API.1/PACE_CAM This TSF responsible the Platform part of
cryptographic operation for Chip Authentication
Mapping.
FIA_API.1/AA This TSF responsible the Platform part of
cryptographic operation for Active Authentication.
FDP_RIP.1/EAC2PP This TSF responsible to make unavailable any
cryptographic data used in runtime cryptographic
computations.
FDP_UCT.1/TRM_EAC2PP This TSF responsible the Platform part of secure
messaging.
FDP_UIT.1/TRM_EAC2PP This TSF responsible the Platform part of secure
messaging.
FDP_RIP.1/EAC1PP This TSF responsible to make unavailable any
cryptographic data used in runtime cryptographic
computations.
FDP_UCT.1/TRM_EAC1PP Equivalent to FDP_UCT.1/TRM_EAC2PP.
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 182 of 191
FDP_UIT.1/TRM_EAC1PP Equivalent to FDP_UIT.1/TRM_EAC2PP.
FDP_RIP.1/SSCDPP This TSF responsible the Platform part of de-allocation
of the resource SCD.
FDP_SDI.2/Persistent_SSCDPP This TSF responsible for integrity of user data.
FDP_SDI.2/DTBS_SSCDPP This TSF responsible for integrity of user data.
FAU_SAS.1/EAC2PP This TSF responsible to store the Initialisation and Pre-
Personalisation Data in the audit records
FAU_SAS.1/EAC1PP Equivalent to FAU_SAS.1/EAC2PP.
FMT_SMR.1 This TSF responsible to provide part of the security
roles.
FMT_LIM.1/EAC2PP This TSF responsible to limit its capabilities to enforce
the policy as described in the SFR.
FMT_LIM.2/EAC2PP This TSF responsible to limit its availability to enforce
the policy as described in the SFR.
FMT_MTD.1/INI_ENA_EAC2PP This TSF responsible to restrict the ability to write the
Initialisation Data and Pre-personalisation Data to the
Manufacturer.
FMT_MTD.1/INI_DIS_EAC2PP This TSF responsible to restrict the ability to read out
the Initialisation Data and the Pre-personalisation Data
to the Personalisation Agent.
FMT_SMF.1/EAC2PP This TSF responsible to provide part of the security
functions.
FMT_SMF.1/EAC1PP This TSF responsible to provide part of the security
functions.
FMT_LIM.1/EAC1PP Equivalent to FMT_LIM.1/EAC2PP.
FMT_LIM.2/EAC1PP Equivalent to FMT_LIM.2/EAC2PP.
FMT_MTD.1/INI_ENA_EAC1PP Equivalent to FMT_MTD.1/INI_ENA_EAC2PP.
FMT_MTD.1/INI_DIS_EAC1PP Equivalent to FMT_MTD.1/INI_DIS_EAC2PP.
FPT_EMS.1/EAC2PP This TSF ensures that during command execution
there are no usable variations in power consumption
(measurable at e. g. electrical contacts) or timing
(measurable at e. g. electrical contacts) that might
disclose cryptographic keys.
FPT_FLS.1/EAC2PP This TSF responsible to preserve a secure state when
the failures occur.
FPT_TST.1/EAC2PP This TSF responsible for the integrity of stored TSF
executable code.
FPT_PHP.3/EAC2PP This TSF ensures resistance to physical attack.
FPT_TST.1/EAC1PP Equivalent to FPT_TST.1/EAC2PP.
FPT_FLS.1/EAC1PP Equivalent to FPT_FLS.1/EAC2PP.
FPT_PHP.3/EAC1PP Equivalent to FPT_PHP.3/EAC2PP
FPT_EMS.1/EAC1PP This TSF ensures that during command execution
there are no usable variations in power consumption
(measurable at e. g. electrical contacts) or timing
(measurable at e. g. electrical contacts) that might
disclose cryptographic keys.
FPT_EMS.1/SSCDPP This TSF ensures that during command execution
there are no usable variations in power consumption
(measurable at e. g. electrical contacts) or timing
(measurable at e. g. electrical contacts) that might
disclose cryptographic keys.
FPT_FLS.1/SSCDPP Equivalent to FPT_FLS.1/EAC2PP.
FPT_PHP.1/SSCDPP This TSF ensures the passive detection of physical
attack.
FPT_PHP.3/SSCDPP Subsumed by FPT_PHP.3/EAC2PP.
FPT_TST.1/SSCDPP Subsumed by FPT_TST.1/EAC2PP.
FMT_LIM.1/Loader This TSF responsible to limit its capabilities to enforce
the policy as described in the SFR.
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 183 of 191
FMT_LIM.2/Loader This TSF responsible to limit its availability to enforce
the policy as described in the SFR.
7.2.Assurance Measures
3871
This section describes the Assurance Measures fulfilling the requirements listed in section 6.2.
3872
The following table lists the Assurance measures and references the corresponding
3873
documents describing the measures.
3874
Assurance measures Description
AM_ADV The representing of the TSF is described in the
documentation for functional specification, in
the documentation for TOE design, in the
security architecture description and in the
documentation for implementation
representation.
AM_AGD The guidance documentation is described in
the User’s Guide documentation [22] and the
Administrator’s Guide documentation [21].
AM_ALC The life-cycle support of the TOE during its
development and maintenance is described in
the life-cycle documentation including
configuration management, delivery
procedures, development security as well as
development tools.
AM_ATE The testing of the TOE is described in the test
documentation.
AM_AVA The vulnerability assessment for the TOE is
described in the vulnerability analysis
documentation.
Table 12 Assurance measures and corresponding documents
3875
7.3.Fulfillment of the SFRs
3876
The following table shows the mapping of the SFRs to security functions of the TOE:
3877
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 184 of 191
TOE SFR / Security Function
TSF.AccessControl
TSF.Authenticate
TSF.SecureManagement
TSF.CryptoKey
TSF.AppletParametersSign
TSF.Platform
FCS_CKM.1/DH_PACE_EAC2P
P
- - - X - X
FCS_COP.1/SHA_EAC2PP - - - X - X
FCS_COP.1/SIG_VER_EAC2PP - - - X - X
FCS_COP.1/PACE_ENC_EAC2P
P
- - - X - X
FCS_COP.1/PACE_MAC_EAC2
PP
- - - X - X
FCS_CKM.4/EAC2PP - - - X - X
FCS_RND.1/EAC2PP - - - X - X
FCS_CKM.1/DH_PACE_EAC1P
P
- - - X - X
FCS_CKM.4/EAC1PP - - - X - X
FCS_COP.1/PACE_ENC_EAC1P
P
- - - X - X
FCS_COP.1/PACE_MAC_EAC1
PP
- - - X - X
FCS_RND.1/EAC1PP - - - X - X
FCS_CKM.1/CA_EAC1PP - - - X - X
FCS_COP.1/CA_ENC_EAC1PP - - - X - X
FCS_COP.1/SIG_VER_EAC1PP - - - X - X
FCS_COP.1/CA_MAC_EAC1PP - - - X - X
FCS_CKM.1/CA2 - - - X - X
FCS_CKM.1/RI - - - X - X
FCS_CKM.1/AA - - - X - X
FCS_COP.1/AA - - - X - X
FCS_CKM.1/CAM - - - X - X
FCS_COP.1/CAM - - - X - X
FCS_CKM.1/SSCDPP - - - X - X
FCS_COP.1/SSCDPP - - - X - X
FIA_AFL.1/Suspend_PIN_EAC2
PP
X X - - - -
FIA_AFL.1/Block_PIN_EAC2PP X X - - - -
FIA_API.1/CA_EAC2PP - X - X - X
FIA_API.1/RI_EAC2PP - X - X - X
FIA_UID.1/PACE_EAC2PP X X - - - X
FIA_UID.1/EAC2_Terminal_EAC
2PP
X X - - - X
FIA_UAU.1/PACE_EAC2PP X X - - - X
FIA_UAU.1/EAC2_Terminal_EA
C2PP
X X - - - X
FIA_UAU.4/PACE_EAC2PP - X - - - X
FIA_UAU.5/PACE_EAC2PP - X - - - X
FIA_UAU.6/CA_EAC2PP - X - - - X
FIA_AFL.1/PACE_EAC2PP X X - - - -
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 185 of 191
TOE SFR / Security Function
TSF.AccessControl
TSF.Authenticate
TSF.SecureManagement
TSF.CryptoKey
TSF.AppletParametersSign
TSF.Platform
FIA_UAU.6/PACE_EAC2PP - X - - - X
FIA_UID.1/PACE_EAC1PP X X - - - X
FIA_UAU.1/PACE_EAC1PP X X - - - X
FIA_UAU.4/PACE_EAC1PP - X - - - X
FIA_UAU.5/PACE_EAC1PP - X - - - X
FIA_UAU.6/PACE_EAC1PP - X - - - X
FIA_UAU.6/EAC_EAC1PP - X - - - X
FIA_API.1/EAC1PP - X - X - X
FIA_API.1/PACE_CAM - X - X - X
FIA_API.1/AA - X - X - X
FIA_AFL.1/PACE_EAC1PP X X - - - -
FIA_UID.1/SSCDPP X - - - - -
FIA_AFL.1/SSCDPP X X - - - -
FIA_UAU.1/SSCDPP X - - - - -
FDP_ACC.1/TRM_EAC2PP X - - - - -
FDP_ACF.1/TRM X X - - - -
FDP_RIP.1/EAC2PP - - - X - X
FDP_UCT.1/TRM_EAC2PP - - - X - X
FDP_UIT.1/TRM_EAC2PP - - - X - X
FDP_ACC.1/TRM_EAC1PP X - - - - -
FDP_RIP.1/EAC1PP - - - X - X
FDP_UCT.1/TRM_EAC1PP - - - X - X
FDP_UIT.1/TRM_EAC1PP - - - X - X
FDP_ACC.1/SCD/SVD_Generati
on_SSCDPP
X - - - - -
FDP_ACF.1/SCD/SVD_Generati
on_SSCDPP
X X - - - -
FDP_ACC.1/SVD_Transfer_SSC
DPP
X - - - - -
FDP_ACF.1/SVD_Transfer_SSC
DPP
X X - - - -
FDP_ACC.1/Signature-
creation_SSCDPP
X - - - - -
FDP_ACF.1/Signature-
creation_SSCDPP
X X - - - -
FDP_RIP.1/SSCDPP - - - X - X
FDP_SDI.2/Persistent_SSCDPP - - - - - X
FDP_SDI.2/DTBS_SSCDPP - - - - - X
FTP_ITC.1/PACE_EAC2PP - X - X - -
FTP_ITC.1/CA_EAC2PP - X - X - -
FTP_ITC.1/PACE_EAC1PP - X - X - -
FAU_SAS.1/EAC2PP - - - - - X
FAU_SAS.1/EAC1PP - - - - - X
FMT_MTD.1/CVCA_INI_EAC2PP X X X - - -
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 186 of 191
TOE SFR / Security Function
TSF.AccessControl
TSF.Authenticate
TSF.SecureManagement
TSF.CryptoKey
TSF.AppletParametersSign
TSF.Platform
FMT_MTD.1/CVCA_UPD_EAC2
PP
X X X - - -
FMT_SMF.1/EAC2PP - - X - - X
FMT_SMR.1 X - - - - X
FMT_MTD.1/DATE_EAC2PP X X X - - -
FMT_MTD.1/PA_EAC2PP X X X - - -
FMT_MTD.1/SK_PICC_EAC2PP X X X - - -
FMT_MTD.1/KEY_READ_EAC2P
P
X - X - - -
FMT_MTD.1/Initialize_PIN_EAC
2PP
- X X - - -
FMT_MTD.1/Change_PIN_EAC2
PP
- X X - - -
FMT_MTD.1/Resume_PIN_EAC2
PP
- X X - - -
FMT_MTD.1/Unblock_PIN_EAC
2PP
- X X - - -
FMT_MTD.1/Activate_PIN_EAC2
PP
- X X - - -
FMT_MTD.3/EAC2PP - X - - - -
FMT_SMR.1/SSCDPP X - - - - -
FMT_SMF.1/SSCDPP - X X - - -
FMT_MOF.1/SSCDPP X X X - - -
FMT_MSA.1/Admin_SSCDPP X X X - - -
FMT_MSA.1/SignatorySSCDPP X X X - - -
FMT_MSA.2/SSCDPP - - X - - -
FMT_MSA.3/SSCDPP X X X - - -
FMT_MSA.4/SSCDPP - X X - - -
FMT_MTD.1/Admin_SSCDPP X X X - - -
FMT_MTD.1/Signatory_SSCDPP X X X - - -
FMT_LIM.1/EAC2PP - - - - - X
FMT_LIM.2/EAC2PP - - - - - X
FMT_MTD.1/INI_ENA_EAC2PP - - - - - X
FMT_MTD.1/INI_DIS_EAC2PP - - - - - X
FMT_SMF.1/EAC1PP - - X - - X
FMT_LIM.1/EAC1PP - - - - - X
FMT_LIM.2/EAC1PP - - - - - X
FMT_MTD.1/INI_ENA_EAC1PP - - - - - X
FMT_MTD.1/INI_DIS_EAC1PP - - - - - X
FMT_MTD.1/CVCA_INI_EAC1PP X X X - - -
FMT_MTD.1/CVCA_UPD_EAC1
PP
X X X - - -
FMT_MTD.1/DATE_EAC1PP X X X - - -
FMT_MTD.1/CAPK_EAC1PP X X X - - -
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 187 of 191
TOE SFR / Security Function
TSF.AccessControl
TSF.Authenticate
TSF.SecureManagement
TSF.CryptoKey
TSF.AppletParametersSign
TSF.Platform
FMT_MTD.1/PA_EAC1PP X X X - - -
FMT_MTD.1/KEY_READ_EAC1P
P
X - X - - -
FMT_MTD.3/EAC1PP - X - - - -
FMT_LIM.1/Loader - - - - - X
FMT_LIM.2/Loader - - - - - X
FMT_MTD.1/AA_Private_Key X X X - - -
FPT_EMS.1/EAC2PP - - - - - X
FPT_FLS.1/EAC2PP - - - - - X
FPT_TST.1/EAC2PP - - - - X X
FPT_PHP.3/EAC2PP - - - - - X
FPT_TST.1/EAC1PP - - - - X X
FPT_FLS.1/EAC1PP - - - - - X
FPT_PHP.3/EAC1PP - - - - - X
FPT_EMS.1/EAC1PP - - - - - X
FPT_EMS.1/SSCDPP - - - - - X
FPT_FLS.1/SSCDPP - - - - - X
FPT_PHP.1/SSCDPP - - - - - X
FPT_PHP.3/SSCDPP - - - - - X
FPT_TST.1/SSCDPP - - - - X X
7.4.Correspondence of SFR and TOE mechanisms
3878
Each TOE security functional requirement is implemented by at least one TOE mechanism. In
3879
section 7.1 the implementing of the TOE security functional requirement is described in form
3880
of the TOE mechanism.
3881
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 188 of 191
8. GLOSSARY AND ABBREVIATIONS
3882
For Glossary and Acronyms please refer to the corresponding section of [20].
3883
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 189 of 191
9. BIBLIOGRAPHY
3884
[1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction
and General Model; CCMB-2017-04-001, Version 3.1, Revision 5, April 2017
[2] Common Criteria for Information Technology Security Evaluation, Part 2: Security
Functional Components; CCMB-2017-04-002, Version 3.1, Revision 5, April 2017
[3] Common Criteria for Information Technology Security Evaluation, Part 3: Security
Assurance Requirements; CCMB-2017-04-003, Version 3.1, Revision 5, April 2017
[4] Common Methodology for Information Technology Security Evaluation, Evaluation
Methodology; CCMB- 2017-04-004, Version 3.1, Revision 5, April 2017
[5] BSI: Common Criteria Protection Profile - Machine Readable Travel Document with
„ICAO Application”, Extended Access Control with PACE (EAC PP), BSI-CC-PP-0056-
V2-2012 v1.3.2 (5. December 2012)
[6] BSI: Common Criteria Protection Profile - ID-Card implementing Extended Access
Control 2 as defined in BSI TR-03110, BSI-CC-PP-0086-2015 v1.01 (May 20th, 2015)
[7] ICAO: Technical Report: Supplemental Access Control for Machine Readable Travel
Documents, Version - 1.1, 15. April 2014.
[8] ICAO: ICAO Doc 9303, Part 1: Machine Readable Passports, Volume 2: Specifications
for Electronically Enabled Passports with Biometric Identification Capability, Seventh
Edition, 2015
[9] ICAO: ICAO Doc 9303 - Machine Readable Travel Documents, 7th edition, 2015
[10] Inside Secure, Infineon Technologies AG, NXP Semiconductors Germany GmbH,
STMicroelectronics: Common Criteria Protection Profile - Security IC Platform Protection
Profile with Augmentation Packages, BSI-CC-PP-0084-2014, v1.0 (13.01.2014)
[11] ISO/IEC 14443 Identification cards — Contactless integrated circuit cards,
[12] ISO/IEC 7816-4:2013 Identification cards — Integrated circuit cards — Part 4:
Organization, security and commands for interchange,
[13] BSI: Common Criteria Protection Profile - Machine Readable Travel Document using
Standard Inspection Procedure with PACE (PACE PP), BSI-CC-PP-0068-V2-2011-MA-
01, v0.01, 22 July 2014
[14] EN 419211-2:2013 — Protection profiles for secure signature creation device — Part 2:
Device with key generation
[15] EN 419211-4:2013 — Protection profiles for secure signature creation device — Part 4:
Extension for device with key generation and trusted channel to certificate generation
application
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 190 of 191
[16] BSI: TR-03110-1 - Advanced Security Mechanisms for Machine Readable Travel
Documents. Part 1 - eMRTDs with BAC/PACEv2 and EACv1, v2.20 (26. February 2015)
[17] BSI: TR-03110-2 - Advanced Security Mechanisms for Machine Readable Travel
Documents and eIDAS token. Part 2 – Protocols for electronic IDentification,
Authentication and trust Services (eIDAS) Version 2.21, 21. December 2016
[18] BSI: TR-03110-3 - Advanced Security Mechanisms for Machine Readable Travel
Documents and eIDAS token. Part 3 - Common Specifications v2.21 (21. December
2016)
[19] BSI: TR-03110-4 - Advanced Security Mechanisms for Machine Readable Travel
Documents and eIDAS token. Part 4 – Applications and Document Profiles V2.21, 21.
December 2016
[20] BSI: Common Criteria Protection Profile - Machine-Readable Electronic Documents
based on BSI TR-03110 for Official Use [MR.ED-PP], BSI-CC-PP-0087 version 1.01,
May 20th
, 2015
[21] IDentity Applet Suite v3.4 Administrator’s Guide v3.4.1 (July 2020)
[22] IDentity Applet Suite v3.4 User’s Guide v3.4.5 (October 2022)
[23] JCOP 4 P71 Security Target Lite, Security Target for JCOP 4 P71/SE050 Rev. 4.8 — 8
August 2022
[24] JCOP 4 P71, User manual for JCOP 4 P71, Rev. 4.2, DocNo 469542, 05 August, 2022,
NXP Semiconductors
[25] Supporting Document Mandatory Technical Document Composite product evaluation for
Smart Cards and similar devices; Version 1.5.1, May 2018
[26] BSI: TR 03111: Elliptic Curve Cryptography, Version 2.0, 28. June 2012.
[27] RSA Laboratories: PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
Laboratories Technical Note, Version 1.4, Revised November 1, 1993
[28] National Institute of Standards and Technology: FIPS PUB 180-4: Secure hash standard,
March 2012.
[29] Published by Oracle. Java Card 3 Platform, Application Programming Interface, Classic
Edition, Version 3.0.5., May 2015.
[30] European card for e-Services and National e-ID applications, IAS ECC European Citizen
Card, Technical Specifications, Revisions 1.0.1.
[31] Bundesamt für Sicherheit in der Informationstechnik, Technische Richtlinie -
Kryptographische Verfahren: Empfehlungen und Schlüssellängen, 09. Januar 2013,
BSI-TR02102.
IDentity Applet v3.4/eIDAS Security Target
Confidential Page 191 of 191
[32] Protection Profile for ePassport IC with SAC (BAC+PACE) and Active Authentication,
version 1.0, March 8,2016, Passport Division, Consular Affairs Bureau, Ministry of
Foreign Affairs of Japan
[33] Protection Profile for ePassport IC with SAC (PACE) and Active Authentication, version
1.0, March 8,2016, Passport Division, Consular Affairs Bureau, Ministry of Foreign Affairs
of Japan
[34] NXP Secure Smart Card Controller N7121 with IC Dedicated Software and Crypto
Library (R1/R2/R3/R4) Security Target Lite, Rev. 2.6, 13 June 2022
[35] Certification Report - NXP Secure Smart Card Controller N7121 with IC NXP Secure
Smart Card Controller N7121 with IC Dedicated Software and Crypto Library
(R1/R2/R3/R4) BSI-DSZ-CC-1136-V3-2022