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