ePass Applet on
JCOP 4 C1
Security Target
Version 1.3/Status 19.12.2023
Author : G+D ePayments GmbH
Status : Final
Rating : Public
File : ePass Applet on
JCOP4_C1_ASE_v13.doc
© Copyright 2023 by
Giesecke+Devrient ePayments GmbH
Prinzregentenstr. 161
D-81677 München
This document as well as the information or material contained is copyrighted. Any use not explicitly
permitted by copyright law requires prior consent of Giesecke+Devrient ePayments GmbH. This applies to
any reproduction, revision, translation, storage on microfilm as well as its import and processing in
electronical systems, in particular.
The information or material contained in this document is property of Giesecke+Devrient ePayments
GmbH and any recipient of this document shall not disclose or divulge, directly or indirectly, this
document or the information or material contained herein without the prior written consent of
Giesecke+Devrient ePayments GmbH.
All copyrights, trademarks, patents and other rights in connection herewith are expressly reserved to
Giesecke+Devrient ePayments GmbH and no license is created hereby.
Subject to technical changes.
All brand or product names mentioned are trademarks or registered trademarks of their respective holders.
1 ST Introduction
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 3 of 104
Contents
Contents.......................................................................................................................................................................... 3
1 ST Introduction .................................................................................................................................5
1.1 ST Reference.....................................................................................................................................5
1.2 TOE Reference..................................................................................................................................5
1.2.1 Sections Overview............................................................................................................................................ 5
1.2.2 Typographic Conventions................................................................................................................................. 6
1.2.3 Change History................................................................................................................................................. 6
1.2.4 Tables ............................................................................................................................................................... 6
1.2.5 Application notes of the PP .............................................................................................................................. 6
2 TOE Overview ..................................................................................................................................7
2.1 TOE Definition..................................................................................................................................7
2.1.1 TOE Operational Usage.................................................................................................................................... 7
2.1.2 TOE Major Security Features........................................................................................................................... 8
2.2 TOE Description ...............................................................................................................................8
2.2.1 Component Overview....................................................................................................................................... 8
2.3 TOE life cycle .................................................................................................................................10
3 Conformance Claims.......................................................................................................................12
3.1 CC conformance claims ..................................................................................................................12
3.2 PP claim ..........................................................................................................................................12
3.3 Package claim..................................................................................................................................12
3.4 Statement of Compatibility concerning Composite Security Target ..............................................13
3.4.1 Used configuration of the platform................................................................................................................. 13
3.4.2 Assessment of the Platform TSFs................................................................................................................... 13
3.4.3 Assessment of the Platform SFRs................................................................................................................... 16
3.4.4 Assessment of the Platform Objectives .......................................................................................................... 25
3.4.5 Assessment of Platform Threats ..................................................................................................................... 27
3.4.6 Assessment of Platform Organisational Security Policies.............................................................................. 28
3.4.7 Assessment of Platform Operational Environment......................................................................................... 29
3.4.8 Assessment of Platform assurance requirements............................................................................................ 31
4 Security Problem Definition ...........................................................................................................32
5 Security objectives ..........................................................................................................................33
5.1 Security Objectives defined in the claimed PPs..............................................................................33
5.2 Security Objectives defined in this ST............................................................................................33
5.3 Security Objective Rationale...........................................................................................................33
6 Extended Components Definition...................................................................................................34
7 Security Requirements ....................................................................................................................35
7.1 TOE Security functional requirements............................................................................................35
7.1.1 Common SFRs from [PP_BAC] and [PP_SAC] ............................................................................................ 38
7.1.2 SFRs specifically from [PP_SAC].................................................................................................................. 40
7.1.3 SFRs specifically from [PP_BAC] ................................................................................................................. 57
7.1.4 SFRs specifically from [PP_EAC] and for the Active Authentication (AA).................................................. 72
7.2 Security Assurance Requirements...................................................................................................90
7.3 Security Requirements Rationale....................................................................................................90
1 ST Introduction
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 4 of 104
7.3.1 Security Functional Requirements Rationale ................................................................................................. 90
7.3.2 Rationale for SFR’s Dependencies................................................................................................................. 90
7.3.3 Security Assurance Requirements Rationale.................................................................................................. 91
7.3.4 Security Requirements – Internal Consistency............................................................................................... 91
8 TOE summary specification............................................................................................................92
8.1 TOE Security functions...................................................................................................................92
8.1.1 SF_AccessControl .......................................................................................................................................... 92
8.1.2 SF_Authentication.......................................................................................................................................... 94
8.1.3 SF_AssetProtection ........................................................................................................................................ 96
8.1.4 SF_TSFProtection .......................................................................................................................................... 96
8.1.5 SF_KeyManagement ...................................................................................................................................... 96
8.2 Assurance measures ........................................................................................................................97
8.3 Association tables of SFRs and TSF...............................................................................................98
9 References, and Abbreviations......................................................................................................101
9.1 References.....................................................................................................................................101
9.2 Abbreviations ................................................................................................................................103
1 ST Introduction
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 5 of 104
1 STIntroduction
This document is the Security Target for the TOE ePass Applet on JCOP 4 C1.
1.1 ST Reference
Title: Security Target ePass Applet on JCOP 4 C1
Reference: ePass Applet on JCOP 4 C1_ASE
TOE Version: 1.0
Document Version Number: Version 1.3/Status 19.12.2023
Origin: Giesecke+Devrient Mobile Security GmbH
Author: G+D / stut
Compliant to: [PP_EAC], [PP_SAC] and [PP_BAC]
1.2 TOE Reference
TOE Reference: ePass Applet on JCOP 4 C1
The TOE Name is ePass Applet on JCOP 4 C1, Version 1.0
The TOE is a secure chip implementing an ePassport.
The TOE is subject to a composite certification based on JCOP 4, JCOP version: JCOP 4
P71 v4.7 R1.02.4 (Certificate: NSCIB-CC-180212), [JCOP4 ST].
HW-Part of TOE:
NXP N7121, Micro Controler version: R4 configuration only (Certificate: BSI-DSZ-CC-
1136-V3-2022-MA-01), [NXP ST].
TOE identification: To verify the correctness of the TOE the Personalization Agent has
to verify the version of the ePass Applet. The description of Applet version and which
command to send, and which is the expected value can be found at section 2.1.4 in
[UGPerso].
1.2.1 Sections Overview
Section 1 provides the introductory material for the Security Target.
Section 2 provides general purpose and TOE description.
Section 3 contains the conformance claims for the TOE.
Section 4 contains the security problem definition.
1 ST Introduction
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 6 of 104
Section 5 contains the security objectives for the TOE and its environment, including the
security objectives rationale.
Section 6 contains the extended components definition.
Section 7 contains the security functional requirements, including the security
requirements rationale.
Section 8 contains the TOE summary specification.
Section 9 contains references and abbreviations.
1.2.2 Typographic Conventions
• This typeface is used to highlight assignments, selections and refinements for
SFRs completed by the ST author.
• This typeface used to highlight assignments and selections for SFRs defined
in the PP.
1.2.3 Change History
Version Date Changes Responsible
1.3 19.12.23 Final version stut
1.2.4 Tables
Table 1 Relevant platform TSF-groups and their correspondence............................................................... 16
Table 2 TOE SFRs equivalent from both [PP_SAC] and [PP_BAC].......................................................... 35
Table 3 TOE SFRs equivalent from [PP_SAC].......................................................................................... 36
Table 4 TOE SFRs equivalent from [PP_BAC]........................................................................................... 37
Table 5 TOE SFRs equivalent from [PP_EAC]........................................................................................... 37
Table 6 TOE SFRs introduced in this ST..................................................................................................... 38
Table 7 Overview on authentication SFRs................................................................................................... 76
Table 8: Reference of Assurance Measures ................................................................................................. 97
Table 9: SFRs and TSF - Coverage............................................................................................................ 100
1.2.5 Application notes of the PP
When applicable the application notes of the PP are discussed in Application Note
(of the ST author).
2 TOE Overview
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 7 of 104
2 TOEOverview
2.1 TOE Definition
The Target of Evaluation (TOE) described in this ST is an electronic passport
representing a smart card implementing [ICAO_9303_10], [ICAO_9303_11], [TR-
03110_1] and [TR-03110_3].
This smart card / passport provides the following application:
• the travel document containing the related user data as well as data needed for
authentication with BAC, PACE, EAC or AA protocols (incl. PACE/BAC
passwords); this application is intended to be used by governmental
organisations as a machine readable travel document (MRTD).
The TOE comprises of at least
• the circuitry of the travel document’s chip (the integrated circuit, IC),
• the IC Dedicated Software with the parts IC Dedicated Test Software and IC
Dedicated Support Software,
• the IC Embedded Software (operating system),
• the ePassport application and
• the associated guidance documentation.
After mask development under the responsibility of G+D, the cards are delivered in
an initialized state to the personalizer.
2.1.1 TOE Operational Usage
A State or Organization issues MRTDs to be used by the holder for international
travel. The traveler presents a MRTD to the inspection system to prove his or her
identity. The MRTD in context of this ST contains (i) visual (eye readable)
biographical data and portrait of the holder, (ii) a separate data summary (MRZ data)
for visual and machine reading using OCR methods (see [ICAO_9303_1]) in the
Machine readable zone (MRZ) and (iii) data elements on the MRTD’s chip. The
authentication of the traveller is based on (i) the possession of a valid travel
document personalised for a holder with the claimed identity as given on the
biographical data page and (ii) biometrics using the reference data stored in the travel
document. The issuing State or Organisation ensures the authenticity of the data of
genuine travel documents. The receiving State trusts a genuine travel document of an
issuing State or Organisation.
2 TOE Overview
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 8 of 104
2.1.2 TOE Major Security Features
The following TOE security features are the most significant for its operational use:
• Verifying authenticity and integrity as well as securing confidentiality of user
data in the communication channel between the TOE and the connected
terminal supporting the protocols BAC, SAC(PACE) as per
[ICAO_9303_11] and EAC as per [TR-03110_1]
• Averting of inconspicuous tracing of the travel document as per [TR-
03110_1]
• Self-protection of the TOE security functionality and the data stored inside as
per [TR-03110_1]
• Means to check authenticity of the terminal, Terminal Authentication as per
[TR-03110_1]
• Means to prove authenticity of the chip by means of Active Authentication or
Chip Authentication as per [TR-03110_1]
• Chip authentication followed by terminal authentication used as a
precondition to provide access to biometric data known as EAC, as per [TR-
03110_1]
For the organizations responsible for the operation of inspection systems please note
that:
• to any BIS (Basic Inspection system) terminal using BAC, the TOE will be
conformant to [PP_BAC] only,
• to any BIS (Basic Inspection system) terminal using PACE but not using EAC,
the TOE will be conformant to [PP_SAC] only,
• to any EIS (Extended inspection system) terminal using PACE and EAC, the
TOE will be conformant to [PP_EAC] only.
2.2 TOE Description
2.2.1 Component Overview
The TOE is a dual interface (with contactless and contact interface) smart card with
Java Card OS and ePassport application. This is based on the requirements from the
ICAO for machine readable travel documents, i.e. [ICAO_9303_10],
[ICAO_9303_11], [TR-03110_1] and [TR-03110_3].
The TOE operating system does not include other applications than the ePassport
application.
2 TOE Overview
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 9 of 104
The OS platform called JCOP 4 P71 [JCOP4 ST] is a Java Card OS and offers
services for:
• The standard Java Card features like API, the Java Card Runtime
Environment and the Java Card Virtual Machine
• Proprietary PACE API providing special countermeasures against side
channel leakage
• GP for content management
• Crypto operation via the contactless interface and contact interface
• Communication via the contactless interface and contact interface.
It is certified in Common Criteria under the Certificate NSCIB CC-22-180212/2
[JCOP4 Cert].
ePass Applet on JCOP 4 C1 is a Java Card applet which provides the functions of the
electronic Passport as per [ICAO_9303_10], [ICAO_9303_11], [TR-03110_1] and
[TR-03110_3].
The installation of ePass Applet on JCOP 4 C1 is done by the initializer
(G+D/Veridos).
The applet uses the services of the Java Card OS described above. It manages the
various stages of the product’s lifecycle once the application is onto the hardware up
to its end of life. The application implements the protocols:
o BAC
o PACE
o EAC1 (EAC)
o AA
It does not implement any cryptographic primitives, as these are provided by the
underlying Java Card OS. Further it manages file access control and authentication
failure handling. Also the application controls the secure messaging including error
handling using the Java Card OS Crypto services, which subsequently relies on the
features of the underlying hardware providing high integrity and side channel
protection. The claims in terms of SFRs in this ST target the ePass Applet on JCOP 4
C1.
The product containing the TOE is based on and designed to be compliant to the
following specifications:
• The Java Card specification (see: [JCVM31], [JCRE301], [JCAPI305],
[JCAPI31]);
2 TOE Overview
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 10 of 104
These industry standards are aimed at defining a framework with which Applications
can be developed, managed and used on a Java Card Platform Embedded Software
like case JCOP 4 [JCOP4 ST].
Note that after JCOP 4 P71 [JCOP4 ST] is initialized and the TOE is delivered to the
personalizer no GP commands for content management are available so that the
customer will not be able to load and install 3rd party applications.
The physical scope of the TOE is:
• the TOE documentation (pdf documents, that are to be delivered PGP-encrypted
electronically or per CD or delivered in a printed version):
• Main Guidance [UGMain]
• Preparative Guidance, [UGPre]
• Operative Guidance, [UGOpe]
• Personalization Concept [UGPerso]
• Usage Phase Commands [UGUsage]
• Operative Guidance of the underlying JCOP 4 Java Card Plattform,
[UGD_JCOP]
• the ePass Applet on the Java Card OS platform JCOP 4 [JCOP4 ST] on a NXP
chip (NXP P71 (Certificate: BSI-DSZ-CC-1107-V3-2022), [NXP ST]]) as a dual
interface (with contactless and contact interface) card (send per postal service in a
sealed way).
Please note:
C1 is the version of the ePass Applet.
2.3 TOE life cycle
The [PP_EAC], [PP_SAC] and [PP_BAC] define the lifecycle phases for the TOE as
follows:
1. Development
- Step 1: Development of hardware and IC dedicated software (firmware)
- Step 2: Development of IC embedded software
2. Manufacturing
2 TOE Overview
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 11 of 104
- Step 3: manufacturing of IC and IC dedicated software. As the TOE does not
provide any user ROM, manufacturing of IC embedded software parts in ROM are
not relevant here.
- Step 4 (optional): Combination of IC with contactless interface of the travel
document
- Step 5 (Prepersonalization): loading on the device the executable Java Card OS
image. Loading of the application JC package containing the TOE code, eDL and
eID code. Then the ePass Applet is initialized on JCOP 4. After this step the TOE is
delivered to the customer.
3. Personalisation of Travel Document
- Step 6: this step is performed by the customer. The customer receives from
Infineon or G+D/Veridos the TOE composed of the following components:
• The underlying hardware
• The initialized ePass Applet on JCOP 4 C1
The customer then performs the personalisation with biometric data and
configuration of the TSF if necessary.
4. Operational Use
- Step 7: once the personalization of the product is finished, the Java Card OS JCOP
4 [JCOP4 ST] is switched to its proprietary privacy mode usage of the TOE by the
personalizer.
Privacy mode switches identification commands from JCOP 4 OS and ePass Applet
to disallow tracking of the end user.
Only ePass Applet commands for the operational phase are allowed in this mode.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 12 of 104
3 ConformanceClaims
3.1 CC conformance claims
This ST claims conformance to:
• Common Criteria for Information Technology Security Evaluation,
Part 1: Introduction and general model, April 2017, version 3.1, revision
5, CCMB-2017-04-001 [CC1],
• Common Criteria for Information Technology Security Evaluation,
Part 2: Security functional requirements, April 2017, version 3.1,
revision 5, CCMB-2017-04-002 [CC2],
• Common Criteria for Information Technology Security Evaluation,
Part 3: Security assurance requirements, April 2017, version 3.1, revision
5, CCMB-2017-04-003 [CC3].
as follows
• Part 2 extended,
• Part 3 conformant.
3.2 PP claim
This ST claims strict conformance
- to [PP_BAC], if a BIS chooses BAC as authentication method
- to [PP_SAC], if a BIS chooses PACE as authentication method
- to [PP_EAC], if a EIS choses PACE as authentication method and
additionally uses Extended Access Control, which consists of two parts (i) the
Chip Authentication Protocol Version 1 (v.1) and (ii) the Terminal
Authentication Protocol Version 1 (v.1) as defined in [TR-03110_1].
3.3 Package claim
• The assurance level for the TOE is EAL5 augmented with the components
ALC_DVS.2 and AVA_VAN.5 in case PACE is used and EAC is not used
and conform to [PP_SAC].
• The assurance level for the TOE is EAL5 augmented with the components
ALC_DVS.2 and AVA_VAN.5 in case PACE and EAC are used and
conform to [PP_EAC].
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 13 of 104
• The assurance level for the TOE is EAL4 augmented with the components
ALC_DVS.2 and ATE_DPT.2 in case BAC is chosen as authentication
method whereby conformancy to [PP_BAC] is claimed.
3.4 Statement of Compatibility concerning Composite
Security Target
3.4.1 Used configuration of the platform
In the Platform ST [JCOP4 ST] , chapter 1.3.1.3.2 in table 5 the different JCOP
configurations and versions are described.
This TOE uses the JCOP 4 configuration and version:
• Configuration Banking & Secure ID JCOP 4 P71 v4.7 R1.02.4,
• R4 configuration only.
The TOE uses the NXP Secure Smart Card Controller NP7121 [NXP ST], chapter
1.4.1, table 3, with the following memory sizes and TOE configuration options:
• NVM size of 150 Kbytes
• User Mode customer (no access to the System Mode of the logical card B)
• No use of the Flash Loader.
3.4.2 Assessment of the Platform TSFs
The following table lists all Security Functionalities of the underlying Platform ST
[JCOP4 ST] and shows, which Security Functionalities of the Platform ST are
relevant for this Composite ST and which are irrelevant. The first column addresses
specific Security Functionality of the underlying platform, which is assigned to
Security Functionalities of the Composite ST in the second column. The last column
provides additional information on the correspondence if necessary.
Platform TSF-group Correspondence in this ST References/Remarks
SF.JCVM No correspondence, internal
Java card mechanisms.
This security function provides the
Java Card Virtual Machine including
byte code interpretation and the Java
Card Firewall
SF.CONFIG SF_AccessControl
SF_Authentication
This security function provides means
to store Initialization Data and Pre-
personalization Data before TOE
delivery
SF.OPEN SF_Authentication,
SF_KeyManagement
This security function provides the
card content management functionality
according the GlobalPlatform
Specification
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 14 of 104
SF.CRYPTO SF_Authentication,
SF_KeyManagement
This security function provides key
creation, key management, key
deletion and cryptographic
functionality
SF.RNG SF_Authentication This security function provides secure
random number generation
SF.DATA_STORAGE SF_TSFProtection This security function provides a
secure data storage for confidential
data. It is used to store cryptographic
keys and to store PINs
SF.PUF No correspondence, PUF is not
used by the TOE.
This security function implements a
mechanism to seal/unseal the user
data stored in shared memory against
unintended disclosure. SF.PUF
encrypts/decrypts the user data with
a cryptographic key which is derived
from the PUF data and stored directly
in the hardware. SF.PUF calculates a
MAC as a PUF authentication value.
SF.PUF serves to seal/unseal the user
data stored in the memory. The user
data stored in the memory can be
encrypted/decrypted using the PUF
block. A MAC (message
authentication code) can be calculated
as a PUF authentication value. Hence,
the user data can be
sealed within the TOE and can be
solely unsealed by the TOE. The
cryptographic key for
sealing/unsealing of the user data is
generated with the help of a key
derivation function based on the PUF
block and the Random Number
Generator (RNG). The PUF block
provides the PUF data to the key
derivation function and thereby the
cryptographic key is derived. If the
TOE is powered off, the PUF data is
not available from the PUF block.
SF.EXT_MEM No correspondence since it is
not used by the TOE.
This security function
providesmechanisms to access
memory subsystems which are not
directly addressable by the Java Card
runtime environment (Java Card RE)
on the Java Card platform.
SF.OM No correspondence, internal
Java card mechanisms.
This security function provides the
object management for Java objects.
SF.MM No correspondence, internal
Java card mechanisms.
This security function provides
deletion of memory for transient
arrays, global arrays, and logical
channels according to the Java Card
Runtime Environment Specification
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 15 of 104
SF.PIN SF_Authentication,
SF_KeyManagement
This security function provides secure
PIN management specified in the Java
Card API Specification and the
GlobalPlatform Specification.
SF.PERS_MEM No correspondence, internal
Java card mechanisms.
This security function provides atomic
write operations and transaction
management according to the Java
Card Runtime Environment
Specification
SF.EDC SF_TSFProtection This security function provides an
Java API for user applications to
perform high performing integrity
checks based on a checksum on Java
arrays. The API throws a Java
Exception in case the checksum in
invalid.
SF.HW-EXC No correspondence, internal
Java card mechanisms.
This security function provides
software exception handler to react on
unforeseen events
captured by the hardware (hardware
exceptions).
SF.RM No correspondence since it is
not used by the TOE.
This security function provides
restricted mode that is entered when
the Attack Counter reaches its
limit. In restricted mode only limited
functionality is available. Only the
issuer is able to reset the Attack
Counter to leave the restricted mode.
SF.PID No correspondence since it is
not used by the TOE.
This security function provides a
platform identifier. This platform
identifier is generated during the card
image generation. The platform
identifier contains IDs for:
• NVM content (stored during
romizing)
• Patch Level (stored during romizing,
can be changed during personalization
if patch is loaded)
ROM code (stored during romizing)
ROM code checksum (stored during
romizing or during first TOE boot).
It identifies unambiguously the NVM
and ROM part of the TOE.
SF.SMG_NSC SF_Authentication,
SF_KeyManagement
The 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
or PINs.
SF.ACC_SBX No correspondence since it is
not used by the TOE.
This security function provides an
environment to securely execute non-
certified native code from third parties.
SF.MOD_INVOC No correspondence since it is
not used by the TOE.
This security functi limits the
invocation of code inside a Module to
such Modules whose security attribute
Module Presence has the restrictive
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 16 of 104
default value “present”.
SF.SENS_RES No correspondence since it is
not used by the TOE.
This security function ensures that
sensitive methods of the Java Card
API store their results
so that callers of these methods can
assert their return values. If such a
method returns abnormally with an
exception then the stored result is
tagged as Unassigned and any
subsequent assertion of the result will
fail.
Table 1 Relevant platform TSF-groups and their correspondence
3.4.3 Assessment of the Platform SFRs
The following table provides an assessment of all Platform SFRs. The Platform SFRs
are listed in the order used within the security target of the platform [JCOP4 ST].
Platform SFR Correspondence in this ST References/Remarks
CoreG_LC Security Functional Requirements (chapter 7.2.1 in platform ST)
Firewall Policy (chapter 7.2.1.1 in platform ST)
FDP_ACC.2[FIREWALL] No correspondence Out of scope (internal Java Card
Firewall. The resulting requirements
for applets are reflected in the User
Guidance of the TOE. No
contradiction to this ST.
FDP_ACF.1[FIREWALL] No correspondence Out of scope (internal Java Card
Firewall). The resulting requirements
for applets are reflected in the User
Guidance of the TOE. No
contradiction to this ST.
FDP_IFC.1[JCVM] No correspondence Out of scope (internal Java Virtual
Machine). No contradiction to this
ST.
FDP_IFF.1[JCVM] No correspondence Out of scope (internal Java Virtual
Machine). No contradiction to this
ST.
FDP_RIP.1[OBJECTS] No correspondence. Out of scope (internal Java Card
Firewall). No contradiction to this
ST.
FMT_MSA.1[JCRE] No correspondence Out of scope (internal Java Card
Firewall). No contradiction to this
ST.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 17 of 104
Platform SFR Correspondence in this ST References/Remarks
FMT_MSA.1[JCVM] No correspondence Out of scope (internal Java Card
Firewall). No contradiction to this
ST.
FMT_MSA.2[FIREWALL-
JCVM]
No correspondence Out of scope (internal Java Card
Firewall). The resulting requirements
for applets are reflected in the User
Guidance of the TOE. No contradic-
tion to this ST.
FMT_MSA.3[FIREWALL] No correspondence Out of scope (internal Java Card
Firewall). The resulting requirements
for applets are reflected in the User
Guidance of the TOE. No contradic-
tion to this ST.
FMT_MSA.3[JCVM] No correspondence Out of scope (internal Java Card
Firew
a
l
l
). No contradiction to this ST.
FMT_SMF.1 No correspondence Out of scope (internal Java Card
Firewall). No contradiction to this
ST.
FMT_SMR.1 No correspondence Out of scope (internal Java Card
Firewall). No contradiction to this
ST.
Application Programming Interface (chapter 7.2.1.2 in platform ST)
FCS_CKM.1 No correspondence. Out of scope. The TOE uses the spe-
cific Document Basic Access Key
Derivation Algorithm. There are no
contradictions to this ST.
FCS_CKM.4 FCS_CKM.4 The requirements are compatible
(physically overwriting the keys,
physically overwriting the keys with
zeros). Thus, all internal Java Card
key objects fulfill the requirement of
this ST. There are no contradictions.
FCS_COP.1.1[PUF_AES],
FCS_COP.1.1[PUF_MAC],
FCS_COP.1.1[TripleDES],
FCS_COP.1.1[AES],
FCS_COP.1.1[RSACipher],
FCS_COP.1.1[ECDHPACEKe
yAgreement],
FCS_COP.1.1[PIV],
FCS_COP.1.1[ECDH_P1363],
FCS_COP.1.1[DESMAC],
FCS_COP.1.1[AESMAC],
FCS_COP.1.1[RSASIGNATU
REPKCS1,
FCS_COP.1.1[ECSignature
], FCS_COP.1.1[ECAdd],
FCS_COP.1.1[SHA],
FCS_COP.1.1[AES_CMAC],
FCS_COP.1/SHA,
FCS_COP.1/ENC,
FCS_COP.1/AUTH,
FCS_COP.1/MAC
FCS_COP.1/PACE_ENC
FCS_COP.1/PACE_MAC
V FCS_COP.1/CA_ENC
FCS_COP.1/CA_MAC
FCS_COP.1/SIG_VER
FCS_COP.1/SIG_GEN
The requirements of this ST,
FCS_COP.1.1/SHA are equivalent to
a subset of the platform
requirements: FCS_COP.1.1[SHA];
FCS_COP.1/ENC corresponds to the
platform SFR
FCS_COP.1.1[TripleDES];
FCS_COP.1/AUTH corresponds to
the platform SFR
FCS_COP.1.1[AES];
FCS_COP.1/MAC corresponds to the
platform SFR
FCS_COP.1.1[DESMAC].
No contradictions to this ST.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 18 of 104
Platform SFR Correspondence in this ST References/Remarks
FCS_COP.1.1[DAP]
FCS_RNG.1 FCS_RND.1 In this ST, random numbers
according to AIS20 class DRG.3 are
required. The platform generates
random numbers with a defined
quality metric (DRG.3) that can be
used directly.
FDP_RIP.1[ABORT] No correspondence. Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_RIP.1[APDU] No correspondence. Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_RIP.1[GlobalArray_Refin
ed]
No correspondence. Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_RIP.1[bArray] No correspondence. Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_RIP.1[KEYS] No correspondence. Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_RIP.1[TRANSIENT] No correspondence. Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_ROL.1[FIREWALL] No correspondence. Out of scope (internal Java Card
Firewall). The resulting requirements
for applets are reflected in the User
Guidance of the TOE. No contradic-
tion to this ST.
Card Security Management (chapter 7.2.1.3 in platform ST)
FAU_ARP.1 FPT_FLS.1, FPT_FLS.1/BAC
FPT_PHP.3
Not directly corresponding, but plat-
form SFR is basis of fulfillment of
FPT_FLS.1 and FPT_PHP.3.
Internal counter for security
violations complement Java Card OS
mechanisms- No contradiction to
this ST.
FDP_SDI.2[DATA] FPT_FLS.1, FPT_FLS.1/BAC
FPT_PHP.3
Not directly corresponding, but plat-
form SFR is basis of fulfillment of
FPT_FLS.1 and FPT_PHP.3. No
con- tradiction to this ST.
FDP_SDI.2[SENSITIVE_RES
ULTS]
FPT_FLS.1, FPT_FLS.1/BAC
FPT_PHP.3
Not directly corresponding, but plat-
form SFR is basis of fulfillment of
FPT_FLS.1 and FPT_PHP.3. No
con- tradiction to this ST.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 19 of 104
Platform SFR Correspondence in this ST References/Remarks
FPR_UNO.1 FPT_EMSEC.1
FPT_EMS.1
FPT_EMS.1/EAC
Not directly corresponding, but rele-
vant for the fullfillment of
FPT_EMSEC.1. No contradiction to
this ST.
FPT_FLS.1 FPT_FLS.1, FPT_FLS.1/BAC The fulfillment of the platform SFR
ispart of the basis of the fulfillment
of the SFR of this ST. Internal
countermeasures for detecting
security violations complement Java
Card OS mechanisms. No
contradiction tothis ST.
FPT_TDC.1 No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
AID Management (chapter 7.2.1.4 in platform ST)
FIA_ATD.1[AID] No correspondence. Out of scope (internal Java Card fun
tionality). No contradiction to this
ST.
FIA_UID.2[AID] No correspondence Out of scope (internal Java Card fun
tionality). No contradiction to this
ST.
FIA_USB.1[AID] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_MTD.1[JCRE] No correspondence Out of scope (internal Java Card fun
tionality). No contradiction to this
ST.
FMT_MTD.3[JCRE] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
INSTG Security Functional Requirements (chapter 7.2.2 in platform ST)
This group consists of the SFRs related to the installation of the applets, which addresses security aspects
outside the runtime.
FDP_ITC.2[Installer] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_SMR.1[Installer] No correspondence Out of scope (internal Java Card func
tionality). No contradiction to this
ST.
FPT_FLS.1[Installer] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this ST.
FPT_RCV.3[Installer] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this ST.
ADELG Security Functional Requirements (chapter 7.2.3 in platform ST)
This group consists of the SFRs related to the deletion of applets and/or packages, enforcing the applet
deletion manager (ADEL) policy on security aspects outside the runtime.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 20 of 104
Platform SFR Correspondence in this ST References/Remarks
FDP_ACC.2[ADEL] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this
ST.
FDP_ACF.1[ADEL] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this
ST.
FDP_RIP.1[ADEL] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this
ST.
FMT_MSA.1[ADEL] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this
ST.
FMT_MSA.3[ADEL] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this
ST.
FMT_SMF.1[ADEL] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this
ST.
FMT_SMR.1[ADEL] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this
ST.
FPT_FLS.1[ADEL] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this
ST.
ODELG Security Functional Requirements (chapter 7.2.5 in platform ST)
The following requirements concern the object deletion mechanism. This mechanism is triggered by the
applet that owns the deleted objects by invoking a specific API method.
FDP_RIP.1[ODEL] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this
ST.
FPT_FLS.1[ODEL] FPT_FLS.1, FPT_FLS.1/BAC The fulfillment of the platform SFR
is part of the basis of the fulfillment
of the SFR of this ST. Internal
countermeasures for detecting
security violations complement Java
Card OS mechanisms. No
contradiction to this ST.
CARG Security Functional Requirements (chapter 7.2.6 in platform ST)
This group includes requirements for preventing the installation of packages that has not been bytecode
verified, or that has been modified after bytecode verification.
FDP_UIT.1[CCM] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this
ST.
FDP_UIT.1[CCMRefined] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_ROL.1[CCM] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 21 of 104
Platform SFR Correspondence in this ST References/Remarks
FTP_ITC.2[CCM] No correspondence Out of scope (internal Java Card func-
tionality). No contradiction to this
ST.
FPT_FLS.1[CCM] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_ACC.1[SD] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_ACF.1[SD] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_MSA.1[SD] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_MSA.3[SD] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_SMF.1[SD] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_SMR.1[SD] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FCO_NRO.2[SC] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_IFC.2[SC] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_IFF.1[SC] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_MSA.1[SC] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_MSA.3[SC] No correspondence Out of scope (internal Java Card
func-tionality). No contradiction
to this ST.
FMT_SMF.1[SC] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FIA_UID.1[SC] No correspondence Out of scope (internal Java Card
func-tionality). No contradiction
to this ST.
FIA_UAU.1[SC] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 22 of 104
Platform SFR Correspondence in this ST References/Remarks
FIA_UAU.4[SC] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FTP_ITC.1[SC] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
EMG Security Functional Requirements (chapter 7.2.7 in platform ST)
FDP_ACC.1[EXT-MEM] No correspondence Out of scope since nomemory space
different from that of the Java Card
System is used by this TOE. No
contradiction to this ST.
FDP_ACF.1[EXT-MEM] No correspondence Out of scope since nomemory space
different from that of the Java Card
System is used by this TOE. No
contradiction to this ST.
FMT_MSA.1[EXT-MEM] No correspondence Out of scope since nomemory space
different from that of the Java Card
System is used by this TOE. No
contradiction to this ST.
FMT_MSA.3[EXT-MEM] No correspondence Out of scope since nomemory space
different from that of the Java Card
System is used by this TOE. No
contradiction to this ST.
FMT_SMF.1[EXT-MEM] No correspondence Out of scope since nomemory space
different from that of the Java Card
System is used by this TOE. No
contradiction to this ST.
ConfG Security Functional Requirements (chapter 7.2.8 in platform ST)
FDP_IFC.2[CFG] No correspondence Out of scope (internal Java Card
functionality). No contradiction
to this ST.
FDP_IFF.1[CFG] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_MSA.3[CFG] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_SMR.1[CFG] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_SMF.1[CFG] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 23 of 104
Platform SFR Correspondence in this ST References/Remarks
FIA_UID.1[CFG] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
SecBoxG Security Functional Requirements (chapter 7.2.9 in platform ST)
FDP_ACC.2[SecureBox] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_ACF.1[SecureBox] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_MSA.1[SecureBox] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_MSA.3[SecureBox] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_SMF.1[SecureBox] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
ModDesG Security Functional Requirements (chapter 7.2.10 in platform ST)
FDP_IFC.1[MODULAR-
DESIGN]
No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_IFF.1[MODULAR-
DESIGN]
No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FIA_ATD.1[MODULAR-
DESIGN]
No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FIA_USB.1[MODULAR-
DESIGN]
No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_MSA.1[MODULAR-
DESIGN]
No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_MSA.3[MODULAR-
DESIGN]
No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 24 of 104
Platform SFR Correspondence in this ST References/Remarks
FMT_SMF.1.1[MODULAR-
DESIGN]
No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_SMR.1.1[MODULAR-
DESIGN]
No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FPT_FLS.1[MODULAR-
DESIGN]
No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FIA_UID.1[MODULAR-
DESIGN]
No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
RMG Security Functional Requirements (chapter 7.2.11 in platform ST)
FDP_ACC.2[RM] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FDP_ACF.1[RM] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_MSA.3[RM] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_MSA.1.1[RM] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FMT_SMF.1.1[RM] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FIA_UID.1[RM] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FIA_UAU.1[RM] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
Further Security Functional Requirements (chapter 7.2.12 in platform ST)
FAU_SAS.1[SCP] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 25 of 104
Platform SFR Correspondence in this ST References/Remarks
FCS_RNG.1 FCS_RND.1 In this ST, random numbers
according to AIS20 class DRG.3
are required. The platform
generates random numbers with a
defined quality metric (DRG.3) that
can be used directly.
FIA_AFL.1[PIN] No correspondence Out of scope (internal Java Card
functionality). No contradiction to
this ST.
FPT_EMSEC.1 FPT_EMSEC.1 The fulfillment of the platform SFR is
part of the basis of the fulfillment of
the SFR of this ST. Internal
countermeasures for detecting security
violations complement Java Card OS
mechanisms. No contradiction to this
ST.
FPT_PHP.3 FPT_PHP.3
FPT_EMSEC.1
FPT_EMS.1
FPT_EMS.1/EAC
The fulfillment oft he SFR in this ST
is based on the platform SFR (together
with additional countermeasures).
FCS_CKM.2 No correspondence Out of scope (managed within Java
Card OS). No contradiction to this
ST.
FCS_CKM.3 No correspondence Out of scope (managed within Java
Card OS). No contradiction to this
ST.
3.4.4 Assessment of the Platform Objectives
The following table provides an assessment of all relevant Platform objectives.
Platform Objective Correspondence in this ST References/Remarks
OT.SID No correspondence Out of scope. No contradiction to
this ST.
OT.SID_MODULE No correspondence Out of scope. No contradiction to
this ST.
OT.FIREWALL No correspondence Out of scope. No contradiction to
this ST.
OT.GLOBAL_ARRAYS_CO
NFID
OT.Data-Confidentiality No contradiction to this ST.
OT.GLOBAL_ARRAYS_I
NTEG
OT.Data-Integrity No contradiction to this ST.
OT.NATIVE No correspondence Out of scope. No contradiction to
this ST.
OT.OPERATE No correspondence Out of scope. No contradiction to
this ST.
OT.REALLOCATION No correspondence Out of scope. No contradiction to
this ST.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 26 of 104
Platform Objective Correspondence in this ST References/Remarks
OT.RESOURCES No correspondence Out of scope. No contradiction to
this ST.
OT.SENSITIVE_RESULT
S_INTEG
OT.Prot_Phys-Tamper The objectives are related. No
contradiction to this ST.
OT.ALARM No correspondence Out of scope. No contradiction to
this ST.
OT.CIPHER No correspondence Indirectly relevant for the correct
function of the TOE of this ST,
but no corresponding objectives
for the TOE of this ST. No
contradictions.
OT.RNG No correspondence Indirectly relevant for the correct
function of the TOE of this ST,
but no corresponding objectives
for the TOE of this ST. No
contradictions.
OT.KEY-MNGT No correspondence Out of scope. No contradiction to
this ST.
OT.PIN-MNGT No correspondence Out of scope. No contradiction to
this ST.
OT.TRANSACTION No correspondence Out of scope. No contradiction to
this ST.
OT.OBJ-DELETION No correspondence Out of scope. No contradiction to
this ST.
OT.APPLI-AUTH No correspondence Out of scope. No contradiction to
this ST.
OT.DOMAIN-RIGHTS No correspondence Out of scope. No contradiction to
this ST.
OT.COMM_AUTH No correspondence Out of scope. No contradiction to
this ST.
OT.COMM_INTEGRITY No correspondence Out of scope. No contradiction to
this ST.
OT.COMM_CONFIDENTI
ALITY
No correspondence Out of scope. No contradiction to
this ST.
OT.EXT-MEM No correspondence Out of scope. No contradiction to
this ST.
OT.CARD-MANAGEMENT No correspondence Out of scope. No contradiction to
this ST.
OT.SCP.IC OT.Prot_Phys-Tamper The objectives are related. No
con- tradiction to this ST.
OT.SCP.RECOVERY OT.Prot_Malfunction The objectives are related. No
contradiction to this ST.
OT.SCP.SUPPORT No correspondence Out of scope. No contradiction to
this ST.
OT.IDENTIFICATION No correspondence Out of scope. No contradiction to
this ST.
OT.SEC_BOX_FW No correspondence Out of scope. No contradiction to
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 27 of 104
Platform Objective Correspondence in this ST References/Remarks
this ST.
OT.RNG No correspondence Indirectly relevant for the correct
function of the TOE of this ST,
but no corresponding objectives
for the TOE of this ST. No
contradictions.
OT.CARD-
CONFIGURATION
No correspondence Out of scope. No contradiction to
this ST.
OT.ATTACK-COUNTER OT.Prot_Phys-Tamper The objectives are related. No
contradiction to this ST.
OT.RESTRICTED-MODE No correspondence Out of scope. No contradiction to
this ST.
3.4.5 Assessment of Platform Threats
The following table provides an assessment of all relevant Platform threats.
Platform Threat Correspondence in this
ST
References/Remarks
T.CONFID-APPLI-DATA No correspondence Out of scope. No contradiction
to this ST.
T.CONFID-JCS-CODE No correspondence Out of scope. No contradiction
to this ST.
T.CONFID-JCS-DATA T.Information_Leakage No contradiction to this ST.
T.INTEG-APPLI-CODE T.Information_Leakage No contradiction to this ST.
T.INTEG-APPLI-CODE.LOAD No correspondence Out of scope. No contradiction
to this ST.
T.INTEG-APPLI-DATA T.Forgery No contradiction to this ST.
T.INTEG-APPLI-DATA.LOAD No correspondence Out of scope. No contradiction
to this ST.
T.INTEG-JCS-CODE No correspondence Out of scope. No contradiction
to this ST.
T.INTEG-JCS-DATA No correspondence Out of scope. No contradiction
to this ST.
T.SID.1 No correspondence Out of scope. No contradiction
to this ST.
T.SID.2 No correspondence Out of scope. No contradiction
to this ST.
T.EXE-CODE.1 No correspondence Out of scope. No contradiction
to this ST.
T.EXE-CODE.2 No correspondence Out of scope. No contradiction
to this ST.
T.NATIVE No correspondence Out of scope. No contradiction
to this ST.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 28 of 104
Platform Threat Correspondence in this
ST
References/Remarks
T.MODULE_EXEC No correspondence Out of scope. No
contradiction to this ST.
T.RESOURCES No correspondence Out of scope. No contradiction
to this ST.
T.UNAUTHORIZED_CARD_MNGT No correspondence Out of scope. No
contradiction to this ST.
T.COM_EXPLOIT No correspondence Out of scope. No
contradiction to this ST.
T.LIFE_CYCLE No correspondence Out of scope. No
contradiction to this ST.
T.OBJ-DELETION No correspondence Out of scope. No
contradiction to this ST.
T.PHYSICAL T.Phys-Tamper No contradiction to this ST.
T.OS_OPERATE No correspondence Out of scope. No
contradiction to this ST.
T.RND T.Phys-Tamper No contradiction to this ST.
T.CONFIG No correspondence Out of scope. No
contradiction to this ST.
T.SEC_BOX_BORDER No correspondence Out of scope. No
contradiction to this ST.
T.MODULE_REPLACEMENT No correspondence Out of scope. No
contradiction to this ST.
T.ATTACK-COUNTER T.Phys-Tamper No contradiction to this ST.
3.4.6 Assessment of Platform Organisational Security Policies
The platform ST contains the Organisational Security Policy
“OSP.VERIFICATION” that focuses on the integrity of loaded applets. This policy
does not contradict to the policies of this ST.
Platform OSP Relevance for Composite ST
OSP.VERIFICATION Relevant.
The secure development of the TOE guarantees that all the bytecodes is
verified at least once, before the loading, before the installation or
before the execution in order to ensure that each bytecode is valid at
execution time.
OSP.PROCESS-TOE Relevant.
An accurate identification is established for the TOE only during
initialisation and personalisation of the TOE but not for the TOE usage
phase.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 29 of 104
OSP.KEY-CHANGE Not relevant.
The Application Provider (AP) does not change its initial security
domain keys (APSD) before any operation on its Security Domain.
OSP.SECURITY-DOMAINS Not relevant.
Security domains cannot be dynamically created, deleted and blocked
during usage phase in post-issuance mode.
This Composite TOE does not support applet loading post-issuance.
OSP.SECURE-BOX Not relevant.
There is no execution of untrusted native code possible by the
Composite TOE.
3.4.7 Assessment of Platform Operational Environment
3.4.7.1 Assessment of Platform Assumptions
In the first column, the following table lists all assumptions of the Platform ST. The
last column provides an explanation of relevance for the Composite TOE.
Platform Assumption Relevance for Composite ST
A.APPLET Not relevant.
A.APPLET states that applets loaded post-issuance do not contain na-
tive methods.
This Composite TOE does not support applet loading post-issuance.
A.VERIFICATION Not relevant.
This assumption targets the applet code verification.
This Composite TOE does not support applet loading post-issuance.
A.USE_DIAG Relevant.
The operational environment supports and uses the secure
communication protocols offered by the TOE
A.USE_KEYS Relevant.
The keys which are stored outside the TOE and which are used for
secure communication and authentication between Smart Card and
terminals are protected for confidentiality and integrity in their own
storage environment.
A.PROCESS-SEC-IC Relevant.
The Phases after TOE Delivery are assumed to be protected
appropriately
A.APPS-PROVIDER Not relevant.
A.APPS-PROVIDER states that AP is a trusted actor that provides
basic or secure applications.
This Composite TOE does not support applet loading post-issuance.
A.VERIFICATION-
AUTHORITY
Not relevant.
This assumption targets the applet code verification.
This Composite TOE does not support applet loading post-issuance.
3.4.7.2 Assessment of Platform Objectives for the Operational Environment
There are the following Platform Objectives for the Operational Environment that
have to be considered.
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 30 of 104
Platform Objective for the Environment Relevance for Composite ST
OE.APPLET Not relevant.
The platform objective for the environment states that
applets loaded post-issuance do not contain native methods.
This Composite TOE does not support applet loading post-
issuance.
OE.VERIFICATION Not relevant.
The platform objective for the environment targets the
applet code verification.
This Composite TOE does not support applet loading post-
issuance.
OE.CODE-EVIDENCE Not relevant.
The platform objective for the environment focusses on
application code loaded pre-issuance or post-issuance.
This Composite TOE does not support applet loading post-
issuance.
This Composite TOE does not have other applet besides the
TOE
OE.APPS-PROVIDER Not relevant.
A.APPS-PROVIDER states that AP is a trusted actor that
provides basic or secure applications.
This Composite TOE does not support applet loading post-
issuance.
OE.VERIFICATION-AUTHORITY Not relevant.
This assumption targets the applet code verification.
This Composite TOE does not support applet loading post-
issuance.
OE.KEY-CHANGE Not relevant.
OE.KEY-CHANGE covers the switch to trusted keys for
the AP.
This Composite TOE does not support key changes for the
security domain initial keys before any operation on it.
OE.SECURITY-DOMAINS Not relevant.
This TOE does not support Security domains that can be
dynamically created, deleted and blocked during usage phase
in post-issuance mode.
OE.USE_DIAG Relevant.
The TOE provides secure TOE communication protocols.
OE.USE_KEYS Relevant.
During the TOE usage, the terminal or system in interaction
with the TOE, shall ensure the protection (integrity and
confidentiality) of their own keys by operational means and/or
procedures.
OE.PROCESS_SEC_IC Relevant.
The Phases after TOE Delivery are assumed to be protected
appropriately
3 Conformance Claims
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 31 of 104
3.4.8 Assessment of Platform assurance requirements
The Platform-ST requires EAL 6 augmented with ASE_TSS.2.
This ST requires EAL 5 augmented with the components ALC_DVS.2 and
AVA_VAN.5.
Therefore, the assurance requirements for this TOE are a subset of the assurance
requirements of the Platform TOE.
4 Security Problem Definition
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 32 of 104
4 SecurityProblemDefinition
All assets, subjects and external entities, threats, organisational security policies and
assumptions from [PP_EAC], [PP_SAC] and [PP_BAC]section 3 “Security Problem
Definition” are applicable for this TOE.
5 Security objectives
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 33 of 104
5 Securityobjectives
Here follows a concise description of the security objectives applying to this ST
followed by a the security objective rationale.
5.1 Security Objectives defined in the claimed PPs
All Security Objectives provided by the TOE or by the operational environment as
well as the security objectives rationale from the claimed PPs [PP_EAC], [PP_SAC]
and [PP_BAC] section 4 “Security Objectives” are applicable for this TOE.
5.2 Security Objectives defined in this ST
The following security objectives are defined additionally in this ST to formally
express the extra features of the TOE not present in the claimed PPs:
OT.Active_Auth Travel document’s chip authenticity
The TOE shall support the Basic Inspection Systems to verify the identity and
authenticity of the travel document’s chip as issued by the identified issuing State or
Organisation by means of the Active Authentication as defined in [ICAO_9303_1].
The authenticity proof provided by travel document’s chip shall be protected against
attacks with high attack potential.
OE.Active_Auth_Key_MRTD MRTD Active Authentication Key
The issuing State or Organization has to establish the necessary public key
infrastructure in order to (i) generate the MRTD’s Active Authentication Key Pair,
(ii) sign and store the Active Authentication Public Key in the Active Authentication
Public Key data in EF.DG15 and (iii) support inspection systems of receiving States
or organizations to verify the authenticity of the MRTD’s chip used for genuine
MRTD by certification of the Active Authentication Public Key by means of the
Document Security Object.
5.3 Security Objective Rationale
The Security Objective Rationale from the claimed PPs [PP_EAC], [PP_SAC] and
[PP_BAC] stays the same here.
The additionally defined security objectives in this ST OT.Active_Auth and
OE.Active_Auth_Key_MRTD above counters the threat T.Counterfeit (threat defined in
[PP_EAC].
6 Extended Components Definition
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 34 of 104
6 ExtendedComponentsDefinition
[PP_EAC], [PP_SAC] and [PP_BAC] respective sections 5 “Extended Components
Definition” are applicable for this TOE.
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 35 of 104
7 SecurityRequirements
7.1 TOE Security functional requirements
The security functional requirements (SFR) for this TOE are defined in this chapter.
This ST covers the three PPs [PP_SAC], [PP_EAC] and [PP_BAC] each two of
which have a non empty intersection of SFRs. In the rest of this section we provide a
classification of the SFRs of these PPs depending on where these SFRs are declared
and if they need a refinement here in this ST.
Table 2 lists all SFRs appearing both in [PP_SAC] and [PP_BAC].
Table 3 lists all SFRs declared in [PP_SAC].
Table 4 lists all SFRs specific to [PP_BAC]. Note that some of the SFRs appear in
both [PP_SAC] and [PP_BAC] with same name but different content. In such cases
the SFR is iterated with either the extension …/BAC or …/PACE.
Table 5 lists all SFRs specific to [PP_EAC]. Note that [PP_EAC] is an extension of
[PP_SAC], therefore all SFRs of [PP_SAC] are SFRs in [PP_EAC], i.e. the SFRs
listed in Table 3 and Table 4 are also SFRs of [PP_EAC].
Table 6 lists the SFRs introduced in this ST which are related to the Active
Authentication mechanism supported by the TOE.
TOE SFRs equivalent from both [PP_SAC] and
[PP_BAC]
FCS_CKM.4
FCS_RND.1
FMT_MTD.1/INI_ENA
FPT_TST.1
FPT_PHP.3
Table 2 TOE SFRs equivalent from both [PP_SAC] and [PP_BAC]
TOE SFRs equivalent from [PP_SAC]
FCS_CKM.1/DH_PACE
FCS_COP.1/PACE_ENC
FCS_COP.1/PACE_MAC
FIA_AFL.1/PACE
FIA_UID.1/PACE
FIA_UAU.1/PACE
FIA_UAU.4/PACE
FIA_UAU.5/PACE
FIA_UAU.6/PACE
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 36 of 104
FDP_ACC.1/TRM
FDP_ACF.1/TRM
FDP_UCT.1/TRM
FDP_UIT.1/TRM
FDP_RIP.1
FTP_ITC.1/PACE
FAU_SAS.1
FMT_LIM.1
FMT_LIM.2
FMT_SMF.1
FMT_SMR.1/PACE
FMT_MTD.1/INI_DIS
FMT_MTD.1/KEY_READ
FMT_MTD.1/PA
FPT_EMS.1
FPT_FLS.1
Table 3 TOE SFRs equivalent from [PP_SAC]
TOE SFRs equivalent from [PP_BAC]
FCS_CKM.1
FCS_COP.1/SHA
FCS_COP.1/ENC
FCS_COP.1/AUTH
FCS_COP.1/MAC
FIA_UID.1
FIA_UAU.1
FIA_UAU.4
FIA_UAU.5
FIA_UAU.6
FIA_AFL.1
FDP_ACC.1
FDP_ACF.1
FDP_UCT.1
FDP_UIT.1
FAU_SAS.1/BAC
FMT_SMF.1/BAC
FMT_LIM.1/BAC
FMT_LIM.2/BAC
FMT_MTD.1/INI_DIS/BAC
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 37 of 104
FMT_MTD.1/KEY_WRITE
FMT_MTD.1/KEY_READ_BAC
FMT_SMR.1
FPT_EMSEC.1
FPT_FLS.1/BAC
Table 4 TOE SFRs equivalent from [PP_BAC]
TOE SFRs equivalent from [PP_EAC]
FCS_CKM.1/CA
FCS_COP.1/CA_ENC
FCS_COP.1/SIG_VER
FCS_COP.1/CA_MAC
FIA_UID.1/PACE_EAC
FIA_UAU.1/PACE_EAC
FIA_UAU.4/PACE_EAC
FIA_UAU.5/PACE_EAC
FIA_UAU.6/EAC
FIA_API.1
FDP_ACC.1/TRM_EAC
FDP_ACF.1/TRM_EAC
FMT_SMR.1/PACE_EAC
FMT_MTD.1/CVCA_INI
FMT_MTD.1/CVCA_UPD
FMT_MTD.1/DATE
FMT_MTD.1/CAPK
FMT_MTD.1/KEY_READ_EAC
FMT_MTD.3
FPT_EMS.1/EAC
Table 5 TOE SFRs equivalent from [PP_EAC]
TOE SFRs introduced in this ST
FIA_API.1/AA
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 38 of 104
FMT_MTD.1/AAPK
FCS_COP.1/SIG_GEN
Table 6 TOE SFRs introduced in this ST
7.1.1 Common SFRs from [PP_BAC] and [PP_SAC]
7.1.1.1 Class FCS: Cryptographic Support
FCS_CKM.4 Cryptographic key destruction
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]: fulfilled by
FCS_CKM.1/DH_PACE and FCS_CKM.1/CA
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method overwriting the key
value with zero values1 that meets the following: none2.
Application Note 1 (of the ST author): The TOE destroys any session keys
after detection of an error in verification of the MAC of a received command. The
PACE Session Keys are destroyed after generation of the Chip Authentication
Session Key (i.e. successfully performing the Chip Authentication) and changing
the secure messaging to the Chip Authentication Session Keys. The TOE clears
the memory area of any session keys before starting the communication with the
terminal in a new after-reset-session as required by FDP_RIP.1. Concerning the
Chip Authentication keys FCS_CKM.4 is also fulfilled by FCS_CKM.1/CA.
Random Number Generation (FCS_RND.1)
The TOE meets the requirement “Quality metric for random numbers
(FCS_RND.1)” as specified below (Common Criteria Part 2 extended).
FCS_RND.1 Quality metric for random numbers
Hierarchical to: No other components.
Dependencies: No dependencies.
1 [assignment: cryptographic key destruction method]
2 [assignment: list of standards]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 39 of 104
FCS_RND.1.1 The TSF shall provide a mechanism to generate random
numbers that meet DRG.3 according to AIS20 [AES]
Federal Information Processing Standards Publication 197, ADVANCED
ENCRYPTION
STANDARD (AES), U.S. DEPARTMENT OF COMMERCE/National Institute of Standard
and Technology, November 26, 2001
[AIS20]3.
Application Note 2 (of the ST author): The TOE generates random numbers
used for the authentication protocols e. g. as required by FIA_UAU.4/PACE.
7.1.1.2 Class FMT Security Management
FMT_MTD.1/INI_ENA Management of TSF data – Writing Initialisation and
Pre-personalisation Data
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by
FMT_SMF.1
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/INI_ENA The TSF shall restrict the ability to write 4 the
Initialisation Data and Pre-personalisation Data5 to the
Manufacturer. 6
7.1.1.3 Class FPT Protection of the Security Functions
FPT_TST.1 TSF testing
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_TST.1.1 The TSF shall run a suite of self tests during initial start-up,
periodically during normal operation, at the condition7 Reset of the TOE8 to
demonstrate the correct operation of the TSF9.
3 [assignment: a defined quality metric]
4 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
5 [assignment: list of TSF data]
6 [assignment: the authorised identified roles]
7 [selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the conditions]
8 [assignment: conditions under which self test should occur]
9 [selection: [assignment: parts of TSF], the TSF]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 40 of 104
FPT_TST.1.2 The TSF shall provide authorised users with the capability to
verify the integrity of the TSF data10.
FPT_TST.1.3 The TSF shall provide authorised users with the capability to
verify the integrity of stored TSF executable code11.
FPT_PHP.3 Resistance to physical attack
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_PHP.3.1 The TSF shall resist physical manipulation and physical probing 12 to
the TSF 13 by responding automatically such that the SFRs are always
enforced.
Application Note 3 (of the ST author): The TOE implements appropriate
measures to continuously counter physical manipulation and physical probing.
Due to the nature of these attacks (especially manipulation) the TOE can by no
means detect attacks on all of its elements. Therefore, permanent protection
against these attacks is required ensuring that the TSP could not be violated at
any time. Hence, ‘automatic response’ means here (i) assuming that there might
be an attack at any time and (ii) countermeasures are provided at any time.
7.1.2 SFRs specifically from [PP_SAC]
FCS_COP.1/PACE_ENC Cryptographic operation – Encryption / Decryption
AES/3DES
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]: fulfilled by
FCS_CKM.1/DH_PACE
FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4
FCS_COP.1.1/PACE_ENC The TSF shall perform secure messaging –
encryption and decryption14 in accordance with a specified
cryptographic algorithm AES and 3DES15 in CBC mode16
10 [selection: [assignment: parts of TSF], TSF data]
11 [selection: [assignment: parts of TSF], the TSF]
12 [assignment: physical tampering scenarios]
13 [assignment: list of TSF devices/elements]
14 [assignment: list of cryptographic operations]
15 [selection: AES, 3DES]
16 [assignment: cryptographic algorithm]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 41 of 104
and cryptographic key sizes 112, 128, 192 and 25617 18 bit
19 that meet the following: compliant to [ICAO_9303_1]20.
Application Note 4 (of the ST author): TOE implements the cryptographic
primitives (i.e. Triple-DES and AES) for secure messaging with encryption of the
transmitted data and encrypting the nonce in the first step of PACE. The related
keys are agreed between the TOE and the terminal as part of the PACE protocol
according to FCS_CKM.1/DH_PACE /(PACE-KEnc).
FCS_COP.1/PACE_MAC Cryptographic operation – MAC
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation] ]: fulfilled by
FCS_CKM.1/DH_PACE
FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4
FCS_COP.1.1/PACE_MAC The TSF shall perform secure messaging –
message authentication code21 in accordance with a
specified cryptographic algorithm CMAC and Retail-MAC22
23 24 and cryptographic key sizes 112, 128, 192 and 25625
26 bit 27 that meet the following: compliant
to [ICAO_9303_1]28.
Application Note 5 (of the ST author): The TOE implements the cryptographic
primitives (i.e. CMAC and Retail-MAC) for secure messaging with message
authentication code over transmitted data. The keys are agreed between the TOE and
the terminal as part of the PACE protocol according to FCS_CKM.1/DH_PACE
17 For 3DES 112 bit cryptographic key size, for AES 128, 192 and 256 bit cryptographic key size
18 [selection: 128, 192, 256]
19 [assignment: cryptographic key sizes]
20 [assignment: list of standards]
21 [assignment: list of cryptographic operations]
22 For AES CMAC is used as MAC mechanism, for 3DES Retail-MAC is used as MAC mechanism
23 [selection: CMAC, Retail-MAC]
24 [assignment: cryptographic algorithm]
25 For Retail-MAC 112 bit cryptographic key size, for CMAC 128, 192 and 256 bit cryptographic key size
26 [selection: 112, 128, 192, 256]
27 [assignment: cryptographic key sizes]
28 [assignment: list of standards]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 42 of 104
7.1.2.1 Class FCS: Cryptographic Support
FCS_CKM.1/DH_PACE Cryptographic key generation – Diffie-Hellman for
PACE session keys
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]: not fulfilled, but justified.
Justification: A Diffie-Hellman key agreement is used in order to avoid
key distribution, therefore FCS_CKM.2 makes no sense in this case.
FCS_CKM.4 Cryptographic key destruction: fulfilled by FCS_CKM.4
FCS_CKM.1.1/DH_PACE The TSF shall generate cryptographic keys in
accordance with a specified cryptographic key generation
algorithm ECDH compliant to [TR-3111]29,30 and specified
cryptographic key sizes 112 bits31, 128 bits, 192 bits and
256 bits32,33 that meet the following: [ICAO_SAC]34.
Application Note 6: The TOE generates a shared secret value with the terminal
during PACE Protocol, see [ICAO_SAC]. This protcol is based on the ECDH
compliant to TR-03111 [TR-3111] (i.e. the elliptic curve cryptographic algorithm,
ECKA, cf. [ICAO_SAC] and [TR-3111] for details). The shared secret value is
used to derive session keys for message encryption and message
authentication according to [ICAO_SAC] for the TSF required by
FCS_COP.1/PACE_ENC and FCS_COP.1/PACE_MAC.
Application Note 7: FCS_CKM.1/DH_PACE implicitly contains the
requirements for the hashing functions used for key derivation by demanding
compliance to [ICAO_SAC].
7.1.2.2 Class FIA Identification and Authentication
FIA_AFL.1/PACE Authentication failure handling – PACE authentication
using nonblocking authorisation data
Hierarchical to: No other components.
Dependencies: UAU.1 Timing of authentication: fulfilled by FIA_UAU.1/PACE
29
[selection: Diffie-Hellman-Protocol compliant to PKCS#3, ECDH compliant to [TR-3111]]
30 [assignment: cryptographic key generation algorithm]
31 Cryptographic key size of 2-key Triple-DES session keys
32 Cryptographic key sizes of AES session keys
33 [assignment: cryptographic key sizes]
34 [assignment: list of standards]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 43 of 104
FIA_AFL.1.1/PACE The TSF shall detect when 635 36 unsuccessful
authentication attempts occurs related to authentication attempts using the
PACE password as shared password37.
FIA_AFL.1.2/PACE When the defined number of unsuccessful
authentication attempts has been met38, the TSF shall delay
each following authentication attempt until the next successful
authentication attempt by approx. 1-10 seconds, the delay
increasing on every unsuccessful authentication attempts39.
Application Note 8: The open assignment operation shall be performed according
to a concrete implementation of the TOE, whereby actions to be executed by the
TOE may either be common for all data concerned (PACE passwords, see
[ICAO_SAC]) or for an arbitrary subset of them or may also separately be defined
for each datum in question.Since all non-blocking authorisation data (PACE
passwords) being used as a shared secret within the PACE protocol do not possess
a sufficient entropy52, the TOE shall not allow a quick monitoring of its behaviour
(e.g. due to a long reaction time) in order to make the first step of the skimming
attack53 requiring an attack potential beyond high, so that the threat T.Tracing can
be averted in the frame of the security policy of the current PP.One of some
opportunities for performing this operation might be ‘consecutively increase the
reaction time of the TOE to the next authentication attempt using PACE passwords’.
FIA_UID.1/PACE Timing of identification
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UID.1.1/PACE The TSF shall allow
1. to establish the communication channel,
2. carrying out the PACE Protocol according to [ICAO_SAC]
3. to read the Initialization Data if it is not disabled by TSF according to
FMT_MTD.1/INI_DIS
4. none 40
on behalf of the user to be performed before the user is identified.
FIA_UID.1.2/PACE The TSF shall require each user to be successfully
identified before allowing any other TSF-mediated actions on
behalf of that user.
35 [assignment: positive integer number]
36 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]]
37 [assignment: list of authentication events]
38 [selection: met ,surpassed]
39 [assignment: list of actions]
40 [assignment: list of TSF-mediated actions]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 44 of 104
Application Note 9: User identified after a successfully performed PACE
protocol is a terminal. Please note that neither CAN nor MRZ effectively
represent secrets, but are restricted revealable; i.e. it is either the travel
document holder itself or an authorised other person or device (Basic Inspection
System with PACE).
FIA_UAU.1/PACE Timing of authentication
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/PACE
FIA_UAU.1.1/PACE The TSF shall allow
1. to establish the communication channel,
2. carrying out the PACE Protocol according to [ICAO_SAC],
3. to read the Initialisation Data if it is not disabled by TSF according
to FMT_MTD.1/INI_DIS,
4. none41
on behalf of the user to be performed before the user is
authenticated.
FIA_UAU.1.2/PACE The TSF shall require each user to be successfully
authenticated before allowing any other TSF-mediated actions
on behalf of that user.
Application Note 10: The user authenticated after a successfully performed
PACE protocol is a PACE authenticated BIS-PACE terminal. Please note that
neither CAN nor MRZ effectively represent secrets but are restricted revealable;
i.e. it is either the travel document holder itself or an authorised other person or
device (BIS-PACE).
If PACE was successfully performed, secure messaging is started using the
derived PACE Session Keys (PACE-KMAC, PACE-KEnc, cf. FTP_ITC.1/PACE.
FIA_UAU.4/PACE Single-use authentication of the Terminal by the TOE
Hierarchical to: No other components.
Dependencies: No dependencies.
41 [assignment: list of TSF-mediated actions]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 45 of 104
FIA_UAU.4.1/PACE The TSF shall prevent reuse of authentication data
related to
1. PACE Protocol according to [ICAO_SAC]
2. Authentication Mechanism based on AES42
3. none43
Application Note 11: For the PACE protocol, the TOE randomly selects a
nonce s of 128 bits length being (almost) uniformly distributed.
FIA_UAU.5/PACE Multiple authentication
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.5.1/PACE The TSF shall provide
1. PACE Protocol according to [ICAO_SAC],
2. Passive Authentication according to [TR-03110_3],
3. Secure messaging MAC-ENC mode according to [ICAO_SAC],
4. Symmetric Authentication Mechanism based on AES,44
5. none45
to support user authentication.
FIA_UAU.5.2/PACE The TSF shall authenticate any user’s claimed identity
according to the following rules:
1. Having successfully run the PACE protocol the TOE accepts only
received commands with correct message authentication code sent
by means of secure messaging with the key agreed with the
terminal by means of the PACE protocol.
2. The TOE accepts the authentication attempt as Personalisation Agent
by the Authentication Mechanism with Personalisation Agent
Keys46.
3. none.47
42 [selection: Triple-DES, AES or other approved algorithms]
43 [assignment: identified authentication mechanism(s)]
44 [selection: Triple-DES, AES or other approved algorithms]
45 [assignment: list of multiple authentication mechanism(s)]
46 [selection: the Authentication Mechanism with Personalization Agent Keys]
47 [assignment: rules describing how the multiple authentication mechanisms provide authentication]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 46 of 104
Application Note 12: Please note that Passive Authentication does not
authenticate any TOE’s user, but provides evidence enabling an external entity
(the terminal connected) to prove the origin of ePassport application.
FIA_UAU.6/PACE Re-authenticating of Terminal by the TOE
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.6.1/PACE The TSF shall re-authenticate the user under the
conditions each command sent to the TOE after successful
run of the PACE protocol shall be verified as being sent by
the PACE terminal. 48
Application Note 13: The PACE protocol specified in [ICAO_SAC] starts secure
messaging used for all commands exchanged after successful PACE
authentication. The TOE checks each command by secure messaging in
encrypt-then-authenticate mode based on CMAC or Retail-MAC, whether it was
sent by the successfully authenticated terminal (see FCS_COP.1/PACE_MAC
for further details). The TOE does not execute any command with incorrect
message authentication code. Therefore, the TOE re-authenticates the terminal
connected, if a secure messaging error occurred, and accepts only those
commands received from the initially authenticated terminal.
7.1.2.3 Class FDP User Data Protection
FDP_ACC.1/TRM Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control: fulfilled by
FDP_ACF.1/TRM
FDP_ACC.1.1/TRM The TSF shall enforce the Access Control SFP49 on
terminals gaining access to the User Data stored in the travel
document and data in EF.SOD of the logical travel document50.
Application Note 14: (of the ST author): The assignment in
FDP_ACC.1.1/TRM may be used in order to extend the
subjects and objects needed for additional security
48 [assignment: list of conditions under which re-authentication is required]
49 [assignment: access control SFP]
50 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 47 of 104
functionalities as e.g by Extende Access Control. This is done
by the ST writer.
FDP_ACF.1/TRM Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control: fulfilled by
FDP_ACC.1/TRM
FMT_MSA.3 Static attribute initialisation: not fulfilled, but
justified
The access control TSF according to FDP_ACF.1/TRM uses
security attributes having been defined during the personalisation
and fixed over the whole life time of the TOE. No management of
these security attributes (i.e. SFR FMT_MSA.1 and FMT_MSA.3)
is necessary here.
FDP_ACF.1.1/TRMThe TSF shall enforce the Access Control SFP51 to objects
based on the following:
1. Subjects:
a. Terminal
b. BIS-PACE;
2. Objects:
a. data in EF.DG1, EF.DG2 and EF.DG5 to
EF.DG16, EF.SOD and EF.COM of the logical travel
document
b. data in EF.DG3 of the logical travel document,
c. data in EF.DG4 of the logical travel document,
3. Security attributes:
a. Authentication status of terminals52
4. none53.
FDP_ACF.1.2/TRM The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is
allowed: A BIS-PACE is allowed to read data objects from
FDP_ACF.1.1/TRM according to [ICAO_SAC] after a
51 [assignment: access control SFP]
52 [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]
53 [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]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 48 of 104
successful PACE authentication as required by
FIA_UAU.1/PACE.54
FDP_ACF.1.3/TRMThe TSF shall explicitly authorize access of subjects to objects
based on the following additional rules: none55.
FDP_ACF.1.4/TRM The TSF shall explicitly deny access of subjects to objects
based on the following rules:
1. Any terminal being not authenticated as PACE
authenticated BIS-PACE is not allowed to read, to write,
to modify, to use any User Data stored on the travel
document.
2. Terminals not using secure messaging are not allowed
to read, to write, to modify, to use any data stored on the
travel document.
3. none.56
Application Note 15: The assignment in FDP_ACF.1.1/TRM may be used in
order to extend the subjects and objects and corresponding security attributes
for documents with more types of security levels as e.g. some data groups
additionally secured by Extended Access Control. The assignment in
FDP_ACF.1.4/TRM may be used in order to deny access to DG3 and DG4 as it
is recommended [ICAO_9303_1] or to further regulate the access to the objects
of FDP_ACF.1.1/TRM. This can be done by the ST writer or in a PP claiming
conformance to PACE PP.
Application Note 16: Please note that the Document Security Object (SOD)
stored in EF.SOD (see [TR-03110_3]) does not belong to the user data, but to
the TSF data. The Document Security Object can be read out by the PACE
authenticated BIS-PACE, see [TR-03110_3]).
Application Note 17: Please note that the control on the user data transmitted
between the TOE and the PACE terminal is addressed by FTP_ITC.1/PACE.
FDP_RIP.1 Subset residual information protection
Hierarchical to: No other components.
Dependencies: No dependencies.
54 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]
55 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
56 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 49 of 104
FDP_RIP.1.1 The TSF shall ensure that any previous information content of
a resource is made unavailable upon the deallocation of the
resource from57 the following objects:
1. Session Keys (immediately after closing related
communication session),
2. the ephemeral private key ephem SKPICC PACE (by
having generated a DH shared secret K58),
3. none59.
Application Note 18: The functional family FDP_RIP possesses such a general
character, so that it is applicable not only to user data (as assumed by the class
FDP), but also to TSF-data; in this respect it is similar to the functional family
FPT_EMS. Applied to cryptographic keys, FDP_RIP.1 requires a certain quality
metric (‘any previous information content of a resource is made unavailable’) for
key’s destruction in addition to FCS_CKM.4 that merely requires a fact of key
destruction according to a method/standard.
FDP_UCT.1/TRM Basic data exchange confidentiality – MRTD
Hierarchical to: No other components.
Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path] fulfilled by FTP_ITC.1/PACE
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control] fulfilled by
FDP_ACC.1/TRM
FDP_UCT.1.1/TRM The TSF shall enforce the Access Control SFP60
to be able to
transmit and receive61
user data in a manner protected from
unauthorised disclosure.
FDP_UIT.1/TRM Data exchange integrity
Hierarchical to: No other components.
Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path] fulfilled by FTP_ITC.1/PACE
[FDP_ACC.1 Subset access control, or
57 [selection: allocation of the resource to, deallocation of the resource from]
58 according to [TR-03110_3], sec. 4.2.1, #3.b
59 [assignment: list of objects]
60 [assignment: access control SFP(s) and/or information flow control SFP(s)]
61 [selection: transmit, receive]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 50 of 104
FDP_IFC.1 Subset information flow control] fulfilled by
FDP_ACC.1/TRM
FDP_UIT.1.1/TRM The TSF shall enforce the Access Control SFP62
to be able to
transmit and receive63
user data in a manner protected from
modification, deletion, insertion and replay64
errors.
FDP_UIT.1.2/TRM The TSF shall be able to determine on receipt of user data,
whether modification, deletion, insertion and replay65
has occurred.
7.1.2.4 Class FTP Trusted Path/Channels
FTP_ITC.1/PACE Inter-TSF trusted channel after PACE
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_ITC.1.1/PACE The TSF shall provide a communication channel between
itself and another trusted IT product that is logically distinct from
other communication channels and provides assured identification of
its end points and protection of the channel data from modification or
disclosure.
FTP_ITC.1.2/PACE The TSF shall permit another trusted IT product to initiate
communication via the trusted channel.
FTP_ITC.1.3/PACE The TSF shall initiate enforce communication via the trusted
channel for any data exchange between the TOE and the Terminal. 66
Application Note 19: The trusted IT product is the terminal. In
FTP_ITC.1.3/PACE, the word ´initiate´ is changed to ‘enforce´, as the TOE is a
passive device that can not initiate the communication. All the communication
are initiated by the Terminal, and the TOE enforce the trusted channel.
Application Note 20: The trusted channel is established after successful
performing the PACE protocol (FIA_UAU.1/PACE). If the PACE was
successfully performed, secure messaging is immediately started using the
derived session keys (PACE-K
MAC
, PACE-K
Enc
): this secure messaging enforces
preventing tracing while Passive Authentication and the required properties of
operational trusted channel; the cryptographic primitives being used for the
secure messaging are as required by FCS_COP.1/PACE_ENC and
FCS_COP.1/PACE_MAC.
62 [assignment: access control SFP(s) and/or information flow control SFP(s)]
63 [selection: transmit, receive]
64 [selection: modification, deletion, insertion, replay]
65 [selection: modification, deletion, insertion, replay]
66 [assignment: list of functions for which a trusted channel is required]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 51 of 104
The establishing phase of the PACE trusted channel does not enable tracing
due to the requirements FIA_AFL.1/PACE.
Application Note 21: Please note that the control on the user data stored in the
TOE is addressed by FDP_ACF.1/TRM.
7.1.2.5 Class FAU Security Audit
FAU_SAS.1 Audit storage
Hierarchical to: No other components.
Dependencies: No dependencies.
FAU_SAS.1.1 The TSF shall provide the Manufacturer67 with the capability to store
the Initialisation and Pre-Personalisation Data 68 in the audit records.
Application Note 22: The Manufacturer role is the default user identity
assumed by the TOE in the life cycle phase ‘manufacturing’. The IC
manufacturer and the travel document manufacturer in the Manufacturer role
write the Initialisation and/or Pre-personalisation Data as TSF-data into the TOE.
The audit records are usually write-only-once data of the travel document (see
FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS). Please note that there could also
be such audit records which cannot be read out, but directly used by the TOE.
7.1.2.6 Class FMT Security Management
FMT_LIM.1 Limited capabilities
Hierarchical to: No other components.
Dependencies: FMT_LIM.2 Limited availability: fulfilled by FMT_LIM.2
FMT_LIM.1.1 The TSF shall be designed in a manner that limits their
capabilities so that in conjunction with “Limited availability (FMT_LIM.2)”
the following policy is enforced:
Deploying Test Features after TOE Delivery does not allow
1. User Data to be manipulated and disclosed,
2. TSF data to be disclosed or manipulated,
3. software to be reconstructed,
4. substantial information about construction of TSF to be
gathered which may enable other attacks69 and
5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed70.
67 [assignment: authorised users]
68 [assignment: list of audit information]
69 [assignment: Limited capability and availability policy]
70 [assignment: Limited capability and availability policy]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 52 of 104
FMT_LIM.2 Limited availability
Hierarchical to: No other components.
Dependencies: FMT_LIM.1 Limited capabilities fulfilled by FMT_LIM.2.
FMT_LIM.2.1 The TSF shall be designed in a manner that limits their
availability so that in conjunction with “Limited capabilities
(FMT_LIM.1)” the following policy is enforced:
Deploying Test Features after TOE Delivery does not allow
1. User Data to be manipulated and disclosed,
2. TSF data to be manipulated or disclosed
3. software to be reconstructed,
4. substantial information about construction of TSF to be
gathered which may enable other attacks71 and
5. sensitive User Data (EF.DG3 and EF.DG4) to be
disclosed72.
Application Note 23: Note that the term “software” in item 4 of FMT_LIM.1.1 and
FMT_LIM.2.1 refers to both IC Dedicated and IC Embedded Software.
Application Note 24 (by the ST author): FMT_LIM.1.1 and FMT_LIM.2.1 are
considered equivalent for [PP_EAC] as the operation performed is exactly the
same as the one stated in there.
FMT_SMF.1 Specification of Management
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions:
1. Initialization,
2. Pre-personalisation,
3. Personalisation
4. Configuration.73
71 [assignment: Limited capability and availability policy]
72 [assignment: Limited capability and availability policy]
73 [assignment: list of management functions to be provided by the TSF]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 53 of 104
FMT_SMR.1/PACE Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification: fulfilled by
FIA_UID.1/PACE
See also the Application Note 20a below.
FMT_SMR.1.1/PACE The TSF shall maintain the roles
1. Manufacturer,
2. Personalisation Agent,
3. Terminal,
4. PACE authenticated BIS-PACE,
5. none74.
FMT_SMR.1.2/PACE The TSF shall be able to associate users with roles.
Application Note 25: For explanation on the role Manufacturer and
Personalisation Agent please refer to the glossary. The role Terminal is the
default role for any terminal being recognised by the TOE as not PACE
authenticated BIS-PACE (‘Terminal’ is used by the travel document presenter).
The TOE recognises the travel document holder or an authorised other person
or device (BIS-PACE) by using PACE authenticated BIS-PACE
(FIA_UAU.1/PACE).
FMT_MTD.1/INI_DIS Management of TSF data – Reading and Using
Initialisation and Pre-personalisation Data
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by
FMT_SMF.1
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/INI_DISThe TSF shall restrict the ability to read out75 the Initialisation
Data and the Pre-personalisation Data 76 to the Personalisation
Agent. 77
74 [assignment: the authorised identified roles]
75 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
76 [assignment: list of TSF data]
77 [assignment: the authorised identified roles]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 54 of 104
Application Note 26: The TOE may restrict the ability to write the Initialisation
Data and the Pre-personalisation Data by (i) allowing writing these data only
once and (ii) blocking the role Manufacturer at the end of the manufacturing
phase. The Manufacturer may write the Initialisation Data (as required by
FAU_SAS.1) including, but being not limited to a unique identification of the IC
being used to trace the IC in the life cycle phases ‘manufacturing’ and ‘issuing’,
but being not needed and may be misused in the ‘operational use’. Therefore,
read and use access to the Initialisation Data shall be blocked in the ‘operational
use’ by the Personalisation Agent, when he switches the TOE from the life cycle
phase ‘issuing’ to the life cycle phase ‘operational use’.
FMT_MTD.1/KEY_READ Management of TSF data –Key Read
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by
FMT_LIM.1 Limited capabilities
Hierarchical to: No other components.
Dependencies: FMT_LIM.2 Limited availability: fulfilled by FMT_LIM.2
FMT_LIM.1.1 The TSF shall be designed in a manner that limits their
capabilities so that in conjunction with “Limited availability (FMT_LIM.2)”
the following policy is enforced:
Deploying Test Features after TOE Delivery does not allow
User Data to be manipulated and disclosed,
6. TSF data to be disclosed or manipulated,
7. software to be reconstructed,
8. substantial information about construction of TSF to be
gathered which may enable other attacks and
9. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed.
10.
11. FMT_LIM.2 Limited availability
12. Hierarchical to: No other components.
13. Dependencies: FMT_LIM.1 Limited capabilities fulfilled by
FMT_LIM.2.
14.
15. FMT_LIM.2.1 The TSF shall be designed in a manner
that limits their availability so that in conjunction with “Limited
capabilities (FMT_LIM.1)” the following policy is enforced:
Deploying Test Features after TOE Delivery does not allow
User Data to be manipulated and disclosed,
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 55 of 104
TSF data to be manipulated or disclosed
software to be reconstructed,
substantial information about construction of TSF to be gathered which may
enable other attacks and
sensitive User Data (EF.DG3 and EF.DG4) to be disclosed.
Application Note 23: Note that the term “software” in item 4 of FMT_LIM.1.1 and
FMT_LIM.2.1 refers to both IC Dedicated and IC Embedded Software.
Application Note 24 (by the ST author): FMT_LIM.1.1 and FMT_LIM.2.1 are
considered equivalent for [PP_EAC] as the operation performed is
exactly the same as the one stated in there.
FMT_SMF.1
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/KEY_READ The TSF shall restrict the ability to read78 the
1. PACE passwords,
2. Personalization Agent Keys
3. none79
to none80.
FMT_MTD.1/PA Management of TSF data – Personalisation Agent
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by
FMT_SMF.1
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/PA The TSF shall restrict the ability to write 81 the Document
Security Object (SOD)82 to the Personalisation Agent. 83
Application Note 27: By writing SOD into the TOE, the Personalisation Agent
confirms (on behalf of DS) the correctness and genuineness of all the
personalisation data related. This consists of user- and TSF- data.
78 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
79 [assignment: list of TSF data]
80 [assignment: the authorised identified roles]
81 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
82 [assignment: list of TSF data]
83 [assignment: the authorised identified roles]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 56 of 104
7.1.2.7 Class FPT Protection of the Security Functions
FPT_EMS.1 TOE Emanation
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_EMS.1.1 The TOE shall not emit information about IC power
consumption and command execution time84 in excess of non
useful information85 enabling access to
1. PACE Session Keys (PACE-KMAC, PACE-KENC)
2. the ephemeral private key ephem SKPICC-PACE
3. Personalisation Agent Key(s)
4. none86.
FPT_EMS.1.2 The TSF shall ensure any users87 are unable to use the
following interface travel document’s contactless/contact interface
and circuit contacts 88 to gain access to
1. PACE Session Keys (PACE-KMAC, PACE-KENC)
2. the ephemeral private key ephem SKPICC-PACE
3. Personalisation Agent Key(s)
4. none89.
Application Note 28: The TOE prevents attacks against the listed secret data
where the attack is based on external observable physical phenomena of the
TOE. Such attacks may be observable at the interfaces of the TOE or may be
originated from internal operation of the TOE or may be caused by an attacker
that varies the physical environment under which the TOE operates. The set of
measurable physical phenomena is influenced by the technology employed to
implement the smart card. The travel document’s chip can provide a smart card
contactless interface and contact based interface according to ISO/IEC 7816-2
[ISO/IEC 7816-2] as well (in case the package only provides a contactless
interface the attacker might gain access to the contacts anyway). Examples of
measurable phenomena include, but are not limited to variations in the power
consumption, the timing of signals and the electromagnetic radiation due to
internal operations or data transmissions.
84 [assignment: types of emissions]
85 [assignment: specified limits]
86 [assignment: list of types of user data]
87 [assignment: type of users]
88 [assignment: type of connection]
89 [assignment: list of types of user data]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 57 of 104
FPT_FLS.1 Failure with preservation of secure state
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_FLS.1.1 The TSF shall preserve a secure state when the following
types of failures occur:
1. Exposure to operating conditions causing a TOE malfunction,
2. Failure detected by TSF according to FPT_TST.1,
3. none90
7.1.3 SFRs specifically from [PP_BAC]
For the dependencies of the SFRs specifically from [PP_BAC] please refer to
[PP_BAC] section 6.3.2 “Dependency Rationale”
7.1.3.1 Class FCS: Cryptographic Support
FCS_CKM.1 Cryptographic key generation – Generation of Document Basic
Access Keys by the TOE
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with
a specified cryptographic key generation algorithm Document Basic Access Key
Derivation Algorithm91 and specified cryptographic key sizes 112 bits92 that meet
the following: [TR-03110_1]93.
Application Note 29 (edited by the ST author): The TOE is equipped with the
Document Basic Access Key generated and downloaded by the Personalization
Agent. The Basic Access Control Authentication Protocol described in [TR-
03110_1], produces agreed parameters to generate the Triple-DES key and the
Retail-MAC message authentication keys for secure messaging by the algorithm
in [TR-03110_1]. The algorithm uses the random number RND.ICC generated by
TSF as required by FCS_RND.1.
90 [assignment: list of types of failures in the TSF]
91 [assignment: cryptographic key generation algorithm]
92 [assignment: cryptographic key sizes]
93 [assignment: list of standards]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 58 of 104
FCS_COP.1/SHA Cryptographic operation – Hash for key derivation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/SHA The TSF shall perform hashing94 in accordance
with a specified cryptographic algorithm SHA-195,96 and cryptographic key sizes
none97 that meet the following: FIPS 180-298,99.
Application Note 30: This SFR requires the TOE to implement the hash
function SHA-1 for the cryptographic primitive to derive the Basic Access Control
Authentication Mechanism (see also FAU_UAU.4) according to [ICAO_9303_1].
FCS_COP.1/ENC Cryptographic operation – Symmetric Encryption /
Decryption Triple DES
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/ENC The TSF shall perform secure messaging (BAC) –
encryption and decryption100 in accordance with a specified cryptographic
algorithm Triple-DES in CBC mode101 and cryptographic key sizes 112 bits102
that meet the following: FIPS 46-3 [DES] and [ICAO_9303_1]; normative
appendix 5, A5.3103.
Application Note 31: This SFR requires the TOE to implement the
cryptographic primitive for secure messaging with encryption of the transmitted
data. The keys are agreed between the TOE and the terminal as part of the
94 [assignment: list of cryptographic operations]
95 [selection: SHA-1 or other approved algorithms]
96 [assignment: cryptographic algorithm]
97 [assignment: cryptographic key sizes]
98 [assignment: list of standards]
99 [selection: FIPS 180-2 or other approved standards]
100 [assignment: list of cryptographic operations]
101 [assignment: cryptographic algorithm]
102 [assignment: cryptographic key sizes]
103 [assignment: list of standards]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 59 of 104
Basic Access Control Authentication Mechanism according to the FCS_CKM.1
and FIA_UAU.4.
FCS_COP.1/AUTH Cryptographic operation – Authentication
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/AUTH The TSF shall perform symmetric authentication –
encryption and decryption104 in accordance with a specified cryptographic
algorithm AES105,106 and cryptographic key sizes 128 bits107,108 that meet the
following: FIPS197 [AES] 109,110.
Application Note 32: This SFR requires the TOE to implement the
cryptographic primitive for authentication attempt of a terminal as
Personalization Agent by means of the symmetric authentication mechanism (cf.
FIA_UAU.4).
FCS_COP.1/MAC Cryptographic operation – Retail MAC
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/MAC The TSF shall perform secure messaging – message
authentication code111 in accordance with a specified cryptographic algorithm
Retail-MAC112 and cryptographic key sizes 112 bits113 that meet the following:
104 [assignment: list of cryptographic operations]
105 [selection: Triple-DES, AES]
106 [assignment: cryptographic algorithm]
107 [selection: 112, 128, 168, 192, 256]
108 [assignment: cryptographic key sizes]
109 [selection: FIPS 46-3, FIPS 197]
110 [assignment: list of standards]
111 [assignment: list of cryptographic operations]
112 [assignment: cryptographic algorithm]
113 [assignment: cryptographic key sizes]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 60 of 104
ISO 9797 (MAC algorithm 3, block cipher DES, Sequence Message Counter,
padding mode 2)114.
Application Note 33: This SFR requires the TOE to implement the
cryptographic primitive for secure messaging with encryption and message
authentication code over the transmitted data. The key is agreed between the
TSF by the Basic Access Control Authentication Mechanism according to the
FCS_CKM.1 and FIA_UAU.4.
7.1.3.2 Class FIA Identification and Authentication
FIA_UID.1 Timing of identification
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UID.1.1 The TSF shall allow
1. to read the Initialization Data in Phase 2 “Manufacturing”,
2. to read random identifier in Phase 3 “Personalization of the MRTD”,
3. to read the random identifier in Phase 4 “Operational Use”115
on behalf of the user to be performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
Application Note 34: The IC manufacturer and the MRTD manufacturer write the
Initialization Data and/or Pre-personalization Data in the audit records of the IC
during the Phase 2 “Manufacturing”. The audit records can be written only in the
Phase 2 Manufacturing of the TOE. At this time the Manufacturer is the only user
role available for the TOE. The MRTD manufacturer may create the user role
Personalization Agent for transition from Phase 2 to Phase 3 “Personalization of
the MRTD”. The users in role Personalization Agent identify themselves by means
of selecting the authentication key. After personalization in the Phase 3 (i.e. writing
the digital MRZ and the Document Basic Access Keys) the user role Basic
Inspection System is created by writing the Document Basic Access Keys. The
Basic Inspection System is identified as default user after power up or reset of the
TOE i.e. the TOE will use the Document Basic Access Key to authenticate the user
as Basic Inspection System.
Application Note 35: In the “Operational Use” phase the MRTD must not allow
anybody to read the ICCSN, the MRTD identifier or any other unique identification
before the user is authenticated as Basic Inspection System (cf. T.Chip_ID). Note
that the terminal and the MRTD’s chip use a (randomly chosen) identifier for the
communication channel to allow the terminal to communicate with more then one
114 [assignment: list of standards]
115 [assignment: list of TSF-mediated actions]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 61 of 104
RFID. If this identifier is randomly selected it will not violate the OT.Identification. If
this identifier is fixed the ST writer should consider the possibility to misuse this
identifier to perform attacks addressed by T.Chip_ID.
The TOE shall meet the requirement “Timing of authentication (FIA_UAU.1)” as
specified below (Common Criteria Part 2).
FIA_UAU.1 Timing of authentication
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FIA_UAU.1.1 The TSF shall allow
1. To read the Initialization Data in Phase 2 “Manufacturing”,
2. to read the random identifier in Phase 3 “Personalization of the MRTD”,
3. to read the random identifier in Phase 4 “Operational Use”116
on behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully
authenticated before allowing any other TSF-mediated actions on behalf of that
user.
Application Note 36: The Basic Inspection System and the Personalization Agent
authenticate themselves.
The TOE shall meet the requirements of “Single-use authentication mechanisms
(FIA_UAU.4)” as specified below (Common Criteria Part 2).
FIA_UAU.4 Single-use authentication mechanisms – Single-use authentication
of the Terminal by the TOE
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to
1. Basic Access Control Authentication Mechanism,
2. Authentication Mechanism based on AES117,118.
116 [assignment: list of TSF-mediated actions]
117 [assignment: identified authentication mechanism(s)]
118 [selection: Triple-DES, AES or other approved algorithms]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 62 of 104
Application note 37: The authentication mechanisms may use either a challenge
freshly and randomly generated by the TOE to prevent reuse of a response
generated by a terminal in a successful authentication attempt. However, the
authentication of Personalisation Agent may rely on other mechanisms ensuring
protection against replay attacks, such as the use of an internal counter as a
diversifier.
Application note 38: The Basic Access Control Mechanism is a mutual device
authentication mechanism defined in [6]. In the first step the terminal authenticates
itself to the MRTD’s chip and the MRTD’s chip authenticates to the terminal in the
second step. In this second step the MRTD’s chip provides the terminal with a
challenge-response-pair which allows a unique identification of the MRTD’s chip
with some probability depending on the entropy of the Document Basic Access
Keys. Therefore the TOE shall stop further communications if the terminal is not
successfully authenticated in the first step of the protocol to ulfil the security
objective OT.Identification and to prevent T.Chip_ID.
The TOE shall meet the requirement “Multiple authentication mechanisms
(FIA_UAU.5)” as specified below (Common Criteria Part 2).
FIA_UAU.5 Multiple authentication mechanisms
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.5.1 The TSF shall provide
1. Basic Access Control Authentication Mechanism,
2. Symmetric Authentication Mechanism based on AES119,120
to support user authentication.
FIA_UAU.5.2 The TSF shall authenticate any user’s claimed identity
according to the following rules:
1. The TOE accepts the authentication attempt as Personalization Agent by
one of the following mechanism(s) Symmetric Authentication Mechanism
with Personalization Agent Key121.
2. The TOE accepts the authentication attempt as Basic Inspection System
only by means of Basic Access Control Authentication Mechanism with the
Document Basic Access Keys122.
119 [assignment: identified authentication mechanism(s)]
120 [selection: Triple-DES, AES]
121 [selection: the Basic Access Control Authentication Mechanism with the Personalization Agent Keys, the Symmetric Authentication Mechanism with the
Personalization Agent Key, [assignment other]]
122 [assignment: rules describing how the multiple authentication mechanisms provide authentication]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 63 of 104
Application note 39: In case the ‘Common Criteria Protection Profile Machine
Readable Travel Document with „ICAO Application", Extended Access Control’
[PP_EAC] should also be fulfilled the Personalization Agent should not be
authenticated by using the BAC or the symmetric authentication mechanism as
they base on the two-key Triple-DES. The Personalization Agent could be
authenticated by using the symmetric AES-based authentication mechanism or
other (e.g. the Terminal Authentication Protocol using the Personalization Key, cf.
[PP_EAC] FIA_UAU.5.2).
Application note 40: The Basic Access Control Mechanism includes the secure
messaging for all commands exchanged after successful authentication of the
inspection system. The Personalization Agent may use Symmetric Authentication
Mechanism without secure messaging mechanism as well if the personalization
environment prevents eavesdropping to the communication between TOE and
personalization terminal. The Basic Inspection System may use the Basic Access
Control Authentication Mechanism with the Document Basic Access Keys.
The TOE shall meet the requirement “Re-authenticating (FIA_UAU.6)” as specified
below (Common Criteria Part 2).
FIA_UAU.6 Re-authenticating – Re-authenticating of Terminal by the TOE
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions
each command sent to the TOE during a BAC mechanism based communication
after successful authentication of the terminal with Basic Access Control
Authentication Mechanism123.
Application Note 41: The Basic Access Control Mechanism specified in
[ICAO_9303_1] includes the secure messaging for all commands exchanged after
successful authentication of the Inspection System. The TOE checks by secure
messaging in MAC_ENC mode each command based on Retail-MAC whether it
was sent by the successfully authenticated terminal (see FCS_COP.1/MAC for
further details). The TOE does not execute any command with incorrect message
authentication code. Therefore the TOE re-authenticates the user for each received
command and accepts only those commands received from the previously
authenticated BAC user.
Application Note 42: Note that in case the TOE should also fulfil [PP_EAC] the
BAC communication might be followed by a Chip Authentication mechanism
establishing a new secure messaging that is distinct from the BAC based
communication. In this case the condition in FIA_UAU.6 above should not
contradict to the option that commands are sent to the TOE that are no longer
meeting the BAC communication but are protected by a more secure
communication channel established after a more advanced authentication process.
123 [assignment: list of conditions under which re-authentication is required]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 64 of 104
The TOE shall meet the requirement “Authentication failure handling (FIA_AFL.1)”
as specified below (Common Criteria Part 2).
FIA_AFL.1 Authentication failure handling (FIA_AFL.1)
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication.
FIA_AFL.1.1 The TSF shall detect when an administrator configurable positive
integer within range of acceptable values 1 to 15 consecutive124 unsuccessful
authentication attempts occur related to the BAC mechanism125.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts
has been met126, the TSF shall mute the TOE at the 16th unsuccessful
authentication attempts127.
Application Note 43 (edited by the ST Author): These assignments are assigned
to ensure especially the strength of authentication function as terminal part of the
Basic Access Control Authentication Protocol to resist enhanced basic attack
potential.
The terminal challenge eIFD and the TSF response eICC are described in
[ICAO_9303_11], Appendix C. The refinement by inclusion of the word
“consecutive” allows the TSF to return to normal operation of the BAC
authentication protocol (without time out) after successful run of the BAC
authentication protocol. The unsuccessful authentication attempt shall be stored
non-volatile in the TOE thus the “consecutive unsuccessful authentication
attempts” are count independent on power-on sessions but reset to zero after
successful authentication only.
7.1.3.3 Class FDP User Data Protection
Subset access control (FDP_ACC.1)
The TOE shall meet the requirement “Subset access control (FDP_ACC.1)” as
specified below (Common Criteria Part 2).
FDP_ACC.1 Subset access control – Basic Access Control
Hierarchical to: No other components.
124 [selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of acceptable values]]
125 [assignment: list of authentication events]
126 [assignment: met or surpassed]
127 [assignment: list of actions]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 65 of 104
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.1.1 The TSF shall enforce the Basic Access Control SFP128 on
terminals gaining write, read and modification access to data in the EF.COM,
EF.SOD, EF.DG1 to EF.DG16 of the logical MRTD129.
Security attribute based access control (FDP_ACF.1)
The TOE shall meet the requirement “Security attribute based access control
(FDP_ACF.1)” as specified below (Common Criteria Part 2).
FDP_ACF.1 Security attribute based access control – Basic Access Control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
FDP_ACF.1.1 The TSF shall enforce the Basic Access Control SFP130 to
objects based on the following:
i. Subjects:
1. Personalization Agent,
2. Basic Inspection System,
3. Terminal,
ii. Objects:
1. data EF.DG1 to EF.DG16 of the logical MRTD,
2. data in EF.COM,
3. data in EF.SOD
iii. Security attributes:
1. authentication status of terminals131
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is allowed:
1. the successfully authenticated Personalization Agent is allowed to write and
to read the data of the EF.COM, EF.SOD, EF.DG1 to EF.DG16 of the logical
MRTD,
128 [assignment: access control SFP]
129 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
130 [assignment: access control SFP]
131 [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]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 66 of 104
2. the successfully authenticated Basic Inspection System is allowed to read
the data in EF.COM, EF.SOD, EF.DG1, EF.DG2 and EF.DG5 to EF.DG16 of
the logical MRTD132
FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects
based on the following additional rules: none133.
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects
based on the rule:
1. Any terminal is not allowed to modify any of the EF.DG1 to EF.DG16 of the
logical MRTD,
2. Any terminal is not allowed to read any of the EF.DG1 to EF.DG16 of the
logical MRTD.
3. The Basic Inspection System is not allowed to read the data in EF.DG3 and
EF.DG4.134
Application Note 44: The inspection system needs special authentication and
authorization for read access to DG3 and DG4 not defined in this protection profile
(cf. [PP_EAC] for details).
Inter-TSF-Transfer
Application Note 45: FDP_UCT.1 and FDP_UIT.1 require the protection of the
User Data transmitted from the TOE to the terminal by secure messaging with
encryption and message authentication codes after successful authentication of the
terminal. The authentication mechanisms as part of Basic Access Control
Mechanism include the key agreement for the encryption and the message
authentication key to be used for secure messaging.
The TOE shall meet the requirement “Basic data exchange confidentiality
(FDP_UCT.1)” as specified below (Common Criteria Part 2).
FDP_UCT.1 Basic data exchange confidentiality - MRTD
Hierarchical to: No other components.
Dependencies: FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_UCT.1.1 The TSF shall enforce the Basic Access Control SFP135 to be
able to transmit and receive136 user data in a manner protected from unauthorized
disclosure.
132 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]
133 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
134 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
135 [assignment: access control SFP(s) and/or information flow control SFP(s)]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 67 of 104
FDP_UIT.1 Data exchange integrity - MRTD
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
FDP_UIT.1.1 The TSF shall enforce the Basic Access Control SFP137 to be
able to transmit and receive138 user data in a manner protected from modification,
deletion, insertion and replay139 errors.
FDP_UIT.1.2 The TSF shall be able to determine on receipt of user data,
whether modification, deletion, insertion and replay140 has occurred.
7.1.3.4 Class FAU Security Audit
FAU_SAS.1/BAC Audit storage
Hierarchical to: No other components.
Dependencies: No dependencies.
FAU_SAS.1.1/BAC The TSF shall provide the Manufacturer141 with the
capability to store the IC Identification Data142 in the audit records.
Application Note 46: The Manufacturer role is the default user identity assumed
by the TOE in the Phase 2 Manufacturing. The IC manufacturer and the MRTD
manufacturer in the Manufacturer role write the Initialization Data and/or Pre-
personalization Data as TSF Data of the TOE. The audit records are write-only-
once data of the MRTD’s chip (see FMT_MTD.1.1/INI_DIS).
7.1.3.5 Class FMT Security Management
FMT_SMF.1/BAC Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
136 [selection: transmit, receive]
137 [assignment: access control SFP(s) and/or information flow control SFP(s)]
138 [selection: transmit, receive]
139 [selection: modification, deletion, insertion, replay]
140 [selection: modification, deletion, insertion, replay]
141 [assignment: authorised users]
142 [assignment: list of audit information]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 68 of 104
FMT_SMF.1.1/BAC The TSF shall be capable of performing the following
management functions:
1. Initialization,
2. Pre-Personalization,
3. Personalization143
The TOE shall meet the requirement “Security roles (FMT_SMR.1)” as specified
below (Common Criteria Part 2).
FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification.
FMT_SMR.1.1 The TSF shall maintain the roles
1. Manufacturer,
2. Personalization Agent,
3. Basic Inspection System.144
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Application Note 47: The SFR FMT_LIM.1 and FMT_LIM.2 address the
management of the TSF and TSF data to prevent misuse of test features of the
TOE over the life cycle phases.
The TOE shall meet the requirement “Limited capabilities (FMT_LIM.1)” as
specified below (Common Criteria Part 2 extended).
FMT_LIM.1/BAC Limited capabilities
Hierarchical to: No other components.
Dependencies: FMT_LIM.2 Limited availability
FMT_LIM.1.1/BAC The TSF shall be designed in a manner that limits their
capabilities so that in conjunction with ‘Limited availability (FMT_LIM.2)’ the
following policy is enforced:
Deploying test features after TOE delivery do not allow
1. User Data to be disclosed or manipulated,
2. TSF data to be disclosed or manipulated,
3. software to be reconstructed and
4. substantial information about construction of TSF to be gathered which may enable other
attacks.145
143 [assignment: list of management functions to be provided by the TSF]
144 [assignment: the authorised identified roles]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 69 of 104
The TOE shall meet the requirement “Limited availability (FMT_LIM.2)” as specified
below (Common Criteria Part 2 extended).
FMT_LIM.2/BAC Limited availability
Hierarchical to: No other components.
Dependencies: FMT_LIM.1 Limited capabilities
FMT_LIM.2.1/BAC The TSF shall be designed in a manner that limits their
availability so that in conjunction with ‘Limited capabilities (FMT_LIM.1)’ the
following policy is enforced:
Deploying test features after TOE delivery do not allow
1. User Data to be manipulated,
2. TSF data to be disclosed or manipulated,
3. software to be reconstructed and
4. substantial information about construction of TSF to be gathered which may enable other
attacks.146
Application Note 48: The formulation of “Deploying Test Features …” in
FMT_LIM.2.1 might be a little bit misleading since the addressed features are no
longer available (e.g. by disabling or removing the respective functionality).
Nevertheless the combination of FMT_LIM.1 and FMT_LIM.2 is introduced provide
an optional approach to enforce the same policy. Note that the term “software” in
item 3 of FMT_LIM.1.1 and FMT_LIM.2.1 refers to both IC Dedicated and IC
Embedded Software.
Application Note 49: The following SFR are iterations of the component
Management of TSF data (FMT_MTD.1). The TSF data include but are not limited
to those identified below.
FMT_MTD.1/INI_DIS/BAC Management of TSF data – Disabling of Read Access
to Initialization and Pre-personalization Data
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MTD.1.1/INI_DIS/BAC The TSF shall restrict the ability to disable read
access for users to147 the Initialization Data148 to the Personalization Agent149.
145 [assignment: limited capability and availability policy]
146 [assignment: limited capability and availability policy]
147 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
148 [assignment: list of TSF data]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 70 of 104
Application Note 50: According to P.Manufact the IC Manufacturer and the MRTD
Manufacturer are the default users assumed by the TOE in the role Manufacturer
during the Phase 2 “Manufacturing” but the TOE is not requested to distinguish
between these users within the role Manufacturer. The TOE restricts the ability to
write the Initialization Data and the Pre-personalization Data by blocking the role
Manufacturer at the end of the Phase 2. The IC Manufacturer writes the
Initialization Data which includes but are not limited to the IC Identifier as required
by FAU_SAS.1. The Initialization Data provides a unique identification of the IC
which is used to trace the IC in the Phase 2 and 3 “Personalization” but is not
needed and may be misused in the Phase 4 “Operational Use”. Therefore the
external read access shall be blocked. The MRTD Manufacturer will write the Pre-
personalization Data.
FMT_MTD.1/KEY_WRITE Management of TSF data – Key Write
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MTD.1.1/KEY_WRITE The TSF shall restrict the ability to write150 the
Document Basic Access Keys151 to the Personalization Agent152.
FMT_MTD.1/KEY_READ_BAC Management of TSF data –Key Read
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MTD.1.1/KEY_READ/BAC The TSF shall restrict the ability to read153
the Document Basic Access Keys and Personalization Agent Keys154 to none155.
Application Note 51: The Personalization Agent generates, stores and ensures
the correctness of the Document Basic Access Keys.
7.1.3.6 Class FPT Protection of the Security Functions
FPT_EMSEC.1 TOE Emanation
149 [assignment: the authorised identified roles]
150 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
151 [assignment: list of TSF data]
152 [assignment: the authorised identified roles]
153 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
154 [assignment: list of TSF data]
155 [assignment: the authorised identified roles]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 71 of 104
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_EMSEC.1.1 The TOE shall not emit information about IC power
consumption and command execution time156 in excess of non useful
information157 enabling access to Personalization Agent Key(s)158 and logical
MRTD data159.
FPT_EMSEC.1.2 The TSF shall ensure any unauthorized users160 are unable to
use the following interface smart card circuit contacts161 to gain access to
Personalization Agent Key(s)162 and logical MRTD data163.
Application Note 52 (edited by the ST author): The TOE shall prevent attacks
against the listed secret data where the attack is based on external observable
physical phenomena of the TOE. Such attacks may be observable at the interfaces
of the TOE or may be originated from internal operation of the TOE or may be
caused by an attacker that varies the physical environment under which the TOE
operates. The set of measurable physical phenomena is influenced by the
technology employed to implement the smart card. The MRTD’s chip has to
provide a smart card contactless interface but may have also (not used by the
terminal but maybe by an attacker) sensitive contacts according to ISO/IEC 7816-2
[ISO/IEC 7816-2] as well. Examples of measurable phenomena include, but are not
limited to variations in the power consumption, the timing of signals and the
electromagnetic radiation due to internal operations or data transmissions.
The following security functional requirements address the protection against
forced illicit information leakage including physical manipulation.
The TOE shall meet the requirement “Failure with preservation of secure state
(FPT_FLS.1)” as specified below (Common Criteria Part 2).
FPT_FLS.1/BAC Failure with preservation of secure state
Hierarchical to: No other components.
Dependencies: No dependencies.
156 [assignment: types of emissions]
157 [assignment: specified limits]
158 [assignment: type of users]
159 [assignment: list of types of user data]
160 [assignment: type of users]
161 [assignment: type of connection]
162 [assignment: type of users]
163 [assignment: list of types of user data]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 72 of 104
FPT_FLS.1.1/BAC The TSF shall preserve a secure state when the following types
of failures occur:
1. Exposure to out-of-range operating conditions where therefore a malfunction
could occur,
2. failure detected by TSF according to FPT_TST.1164
7.1.4 SFRs specifically from [PP_EAC] and for the Active Authentication
(AA)
7.1.4.1 Class Cryptographic support (FCS)
FCS_CKM.1/CA Cryptographic key generation
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1/CA The TSF shall generate cryptographic keys in accordance with
a specified cryptographic key generation algorithm ECDH compliant to ISO
15946165,166 and specified cryptographic key sizes 112 bits167, 128, 192, 256
bits168, 192 bits – 521 bits169,170 that meet the following: based on an ECDH
protocol compliant to TR03111 [TR-3111]171.
Application note 53: FCS_CKM.1/CA implicitly contains the requirements for the
hashing functions used for key derivation by demanding compliance to [TR-
03110_1]].
Application Note 54 (edited by the ST author): The TOE generates a shared
secret value with the terminal during the Chip Authentication Protocol, see [TR-
03110_1], sec. 3.1 and Annex A.1. This protocol is based on the ECDH compliant
to ISO 15946 (i.e. an elliptic curve cryptography algorithm) (cf. [TR-03110_1],
Annex A.1, [TR-3111] and [ISO15946-3] for details). The shared secret value is
164 [assignment: list of types of failures in the TSF]
165
[selection: based on the key Diffie-Hellman key derivation Protocol compliant to PKCS#3, ECDH compliant to ISO 15946]
166 [assignment: cryptographic key generation algorithm]
167 Bit length of 2-key Triple DES session keys
168 Bit length of AES session keys
169 Bit length of the curve
170 [assignment: cryptographic key sizes]
171 [assignment: list of standards]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 73 of 104
used to derive Triple-DES key for encryption and the Retail-MAC Chip Session
Keys according to the Document Basic Access Key Derivation Algorithm [TR-
03110_1], for the TSF required by FCS_COP.1/ and FCS_COP.1.1/MAC.
Application note 55: The TOE shall implement the hash function SHA-1 for the
cryptographic primitive to derive the keys for secure messaging from any shared
secrets of the Authentication Mechanisms. The Chip Authentication Protocol v.1
may use SHA-1 (cf. [TR-03110_1]). The TOE may implement additional hash
functions SHA-224 and SHA-256 for the Terminal Authentication Protocol v.1 (cf. .
[TR-03110_1] for details).
Application note 56: The TOE shall destroy any session keys in accordance with
FCS_CKM.4 from [7] after (i) detection of an error in a received command by
verification of the MAC and (ii) after successful run of the Chip Authentication
Protocol v.1. (iii) The TOE shall destroy the PACE Session Keys after generation of
a Chip Authentication Session Keys and changing the secure messaging to the
Chip Authentication Session Keys. (iv) The TOE shall clear the memory area of
any session keys before starting the communication with the terminal in a new
after-reset-session as required by FDP_RIP.1. Concerning the Chip Authentication
keys FCS_CKM.4 is also fulfilled by FCS_CKM.1/CA.
7.1.4.1.1 Cryptographic operations (FCS_COP.1)
FCS_COP.1/CA_ENC Cryptographic operation – Symmetric Encryption /
Decryption
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/CA_ENC The TSF shall perform secure messaging –
encryption and decryption172 in accordance with a specified cryptographic algorithm
Triple-DES in CBC mode, AES173 and cryptographic key sizes 112 bits, 128 bits174
that meet the following: FIPS PUB 46-3 [ANSIX962], FIPS PUB 197 [SP800-20]
Chapter 5175.
172 [assignment: list of cryptographic operations]
173 [assignment: cryptographic algorithm]
174 [assignment: cryptographic key sizes]
175 [assignment: list of standards]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 74 of 104
Application Note 57: This SFR requires the TOE to implement the cryptographic
primitives (Triple-DES and AES) for secure messaging with encryption of the
transmitted data. The keys are agreed between the TOE and the terminal as part of
the Chip Authentication Protocol Version 1 according to the FCS_CKM.1/CA.
FCS_COP.1/SIG_VER Cryptographic operation – Signature verification
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/SIG_VER The TSF shall perform digital signature verification176 in
accordance with a specified cryptographic algorithm ECDSA with SHA-1, SHA-224,
SHA-256, SHA-384, and SHA-512177 and cryptographic key sizes 192-521
bits178,179 that meet the following: ISO/IEC 14888-3 [ISO/IEC 14888-3], Chapter
6.4180.
Application Note 58 (edited by the ST author): The signature verification is used
to verify the card verifiable certificates and the authentication attempt of the
terminal creating a digital signature for the TOE challenge.
Application Note 59 (written by the ST author): The TOE uses the following
ECC brainpool curves: P224r1, P256r1, P320r1, P384r1, P512r1, see chapter
1.3.2 [TR-3116-2] and NIST curves: P-224 (sec224r1), P-256 (secp256r1), P-384
(secp384r1) and P-521 (secp521r1), see [TR-03110_3].
Application Note 60 (written by the ST author): Padding is applied as described
in Section 6.4.3.5 of ISO/IEC 14888-3 ISO/IEC 14888-3]. For example in case of
SHA-512 hash function and P-521 curve, the hash-code H = h(M) of message M is
converted to an integer according to the conversion rule BS2I given in Annex B of
ISO14888-3.
FCS_COP.1/SIG_GEN Cryptographic operation – Signature generation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1
Cryptographic key generation]: This SFR is not used to calculate any
176 [assignment: list of cryptographic operations]
177 [assignment: cryptographic algorithm]
178 [assignment: cryptographic key sizes]
179 Bit length of curve
180 [assignment: list of standards]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 75 of 104
shared secrets, nor does it import user data. Therefore there is no need
for security attributes.
FCS_CKM.4 Cryptographic key destruction: Fulfilled by FCS_CKM.4
FCS_COP.1.1/SIG_GEN The TSF shall perform signature generation181
in
accordance with a specified cryptographic algorithm RSA182
and cryptographic key
sizes 2048, 4096 bits and from 2000 bit to 4096 bit in one bit steps or ECDSA with
SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512183 and cryptographic key
sizes 192-521 bits184
that meet the following scheme 1 of [ISO9796-2] chapter 8
and [PKCS1] chapter 8.2 (RSASSA-PKCS1-v1_5) for RSA signatures and [TR-
03110_1] for ECDSA signatures185
.
FCS_COP.1/CA_MAC Cryptographic operation – MAC
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2
Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/CA_MAC The TSF shall perform secure messaging – message
authentication code186 in accordance with a specified cryptographic algorithm Triple-
DES in CBC mode, AES 187 and cryptographic key sizes 112 bits, 128 bits188 that
meet the following: FIPS PUB 46-3 [ANSIX962], FIPS PUB 197 [SP800-20]
Chapter 5189.
Application Note 61 (edited by the ST author): The TOE implements the
cryptographic primitive for secure messaging with encryption and message authentication code
over the transmitted data. The key is agreed between the TSF by Chip Authentication Protocol
Version 1 according to the FCS_CKM.1/CA. Furthermore the SFR is used for authentication
attempts of a terminal as Personalisation Agent by means of the authentication mechanism.
181 [assignment: list of cryptographic operations]
182 [assignment: cryptographic algorithm]
183 [assignment: cryptographic algorithm]
184 [assignment: cryptographic key sizes]
185 [assignment: list of standards]
186 [assignment: list of cryptographic operations]
187 [assignment: cryptographic algorithm]
188 [assignment: cryptographic key sizes]
189 [assignment: list of standards]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 76 of 104
7.1.4.2 Class FIA Identification and Authentication
Application Note 50a: The Table 7 provides an overview of the authentication
mechanisms used.
Name SFR for the TOE
Authentication Mechanism for
Personalization Agents
FIA_UAU.4/PACE
Chip Authentication Protocol v.1
FIA_AFL.1,
FIA_UAU.5/PACE,
FIA_UAU.6/EAC
Terminal Authentication Protocol v.1 FIA_UAU.5/PACE
PACE protocol190
FIA_UAU.1/PACE
FIA_UAU.5/PACE
FIA_AFL.1/PACE
Passive Authentication FIA_UAU.5/PACE FIA_API.1/AA
Table 7 Overview on authentication SFRs
Note the Chip Authentication Protoco Version 1 as defined in this security target191
includes
− the asymmetric key agreement to establish symmetric secure messaging keys
between the TOE and the terminal based on the Chip Authentication Public Key
and the Terminal Public Key used later in the Terminal Authentication Protocol
Version1,
− the check whether the TOE is able to generate the correct message
authentication code with the expected key for any message received by the
terminal.
The Chip Authentication Protocol v.1 may be used independent of the Terminal
Authentication Protocol v.1. But if the Terminal Authentication Protocol v.1 is used
the terminal shall use the same public key as presented during the Chip
Authentication Protocol v.1.
The TOE shall meet the requirement “Timing of identification (FIA_UID.1)” as specified
below (Common Criteria Part 2).
FIA_UID.1/PACE_EAC Timing of identification
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UID.1.1/PACE_EAC The TSF shall allow
1. to establish the communication channel,
190 Only listed for information purposes
191 The BAC Authentication Protocol is included here as part of the Chip Authentication Protocol because it is a necessary condition to read the
EF.DG14.
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 77 of 104
2. carrying out the PACE Protocol according to [ICAO_SAC],
3. to read the Initialisation Data if it is not disabled by TSF according to
FMT_MTD.1/INI_DIS
4. to carry out the Chip Authentication Protocol Version 1 according to [TR-
03110_1]
5. to carry out the Terminal Authentication Protocol Version 1 according
to [TR-03110_1]
6. none192
on behalf of the user to be performed before the user is identified.
FIA_UID.1.2/PACE_EAC The TSF shall require each user to be successfully
identified before allowing any other TSF-mediated actions on behalf of that user.
Application Note 62: The SFR FIA_UID.1/PACE in the [PP_EAC] covers the
definition in PACE PP [PP_SAC] and extends it by EAC aspect 4. This extension does
not conflict with the strict conformance to PACE PP [PP_SAC].
Application Note 63: In the Phase 2 “Manufacturing of the TOE” the Manufacturer
is the only user role known to the TOE which writes the Initialization Data and/or
Pre-personalization Data in the audit records of the IC. The MRTD manufacturer
may create the user role Personalization Agent for transition from Phase 2 to
Phase 3 “Personalization of the MRTD”. The users in role Personalization Agent
identify themselves by means of selecting the authentication key. After
personalization in the Phase 3 the Document Basic Access Keys, the Chip
Authentication data and Terminal Authentication Reference Data are written into
the TOE. The Basic Inspection System (cf. PP MRTD BAC [PP_BAC]) is identified
as default user after power up or reset of the TOE i.e. the TOE will use the
Document Basic Access Key to run the BAC Authentication Protocol, to gain
access to the Chip Authentication Reference Data and to run the Chip
Authentication Protocol (i.e. the BAC mechanism is not seen as an independent
mechanism in this ST, it is a mandatory part within the Chip Authentication
Protocol, and thus noted here for reasons of completeness). After successful
authentication of the chip the terminal may identify itself as (i) Extended Inspection
System by selection of the templates for the Terminal Authentication Protocol or (ii)
if necessary and available by symmetric authentication as Personalization Agent
(using the Personalization Agent Key).
Application Note 64: User identified after a successfully performed PACE protocol
is a terminal. Please note that neither CAN nor MRZ effectively represent secrets,
but are restricted revealable; i.e. it is either the travel document holder itself or an
authorised other person or device (Basic Inspection System with PACE).
Application Note 65: In the life-cycle phase ‘Manufacturing’ the Manufacturer is
the only user role known to the TOE. The Manufacturer writes the Initialisation Data
192 [assignment: list of TSF-mediated actions]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 78 of 104
and/or Pre-personalisation Data in the audit records of the IC.Please note that a
Personalisation Agent acts on behalf of the travel document Issuer under his and
CSCA and DS policies. Hence, they define authentication procedure(s) for
Personalisation Agents. The TOE must functionally support these authentication
procedures being subject to evaluation within the assurance components
ALC_DEL.1 and AGD_PRE.1. The TOE assumes the user role ‘Personalisation
Agent’, when a terminal proves the respective Terminal Authorisation Level as
defined by the related policy (policies).
FIA_UAU.1/PACE_EAC Timing of authentication
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FIA_UAU.1.1/PACE_EAC The TSF shall allow
1. to establish the communication channel,
2. carrying out the PACE Protocol according to [ICAO_SAC],
3. to read the Initialization Data if it is not disabled by TSF according to FMT_MTD.1/INI_DIS,
4. to identify themselves by selection of the authentication key,
5. to carry out the Chip Authentication Protocol Version 1 according to [TR-03110_1]
6. to carry out the Terminal Authentication Protocol Version 1 according to [TR-03110_1]
7. none193
on behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2/PACE_EAC The TSF shall require each user to be
successfully authenticated before allowing any other TSF-mediated actions on
behalf of that user.
Application Note 66: The SFR FIA_UAU.1/PACE. in the current PP [PP_EAC]
covers the definition in PACE PP [PP_SAC] and extends it by EAC aspect 5. This
extension does not conflict with the strict conformance to PACE PP.
Application Note 67: The user authenticated after a successfully performed PACE
protocol is a terminal. Please note that neither CAN nor MRZ effectively represent
secrets, but are restricted revealable; i.e. it is either the travel document holder
itself or an authorised other person or device (BIS-PACE).If PACE was
successfully performed, secure messaging is started using the derived session
keys (PACE-K
MAC
, PACE-K
Enc
), cf. FTP_ITC.1/PACE.
FIA_UAU.4/PACE_EAC Single-use authentication mechanisms – Single-use
authentication of the Terminal by the TOE
Hierarchical to: No other components.
193 [assignment: list of TSF-mediated actions]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 79 of 104
Dependencies: No dependencies.
FIA_UAU.4.1/PACE_EAC The TSF shall prevent reuse of authentication
data related to
1. PACE Protocol according to [ICAO_SAC],
2. Authentication Mechanism based on AES,194
3. Terminal Authentication Protocol v.1 according to [TR-03110_1]195
Application note 68: The SFR FIA_UAU.4.1 in the current PP [PP_EAC] covers the
definition in PACE PP [PP_SAC] and extends it by the EAC aspect 3. This extension
does not conflict with the strict conformance to PACE PP. The generation of random
numbers (random nonce) used for the authentication protocol (PACE) and Terminal
Authentication as required by FIA_UAU.4/PACE is required by FCS_RND.1 from
[PP_SAC].
Application Note 69: The authentication mechanisms may use either a challenge
freshly and randomly generated by the TOE to prevent reuse of a response
generated by a terminal in a successful authentication attempt. However, the
authentication of Personalization Agent may rely on other mechanisms ensuring
protection against replay attacks, such as the use of an internal counter as a
diversifier.
FIA_UAU.5/PACE_EAC Multiple authentication mechanisms
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.5.1/PACE_EAC The TSF shall provide
1. PACE Protocol according to [ICAO_SAC],
2. Passive Authentication according to [ICAO_9303_1],
3. Secure messaging in MAC-ENC mode according to [ICAO_SAC],
4. Symmetric Authentication Mechanism based on AES196,197
5. Terminal Authentication Protocol v.1 according to [TR-03110_1],
to support user authentication.
FIA_UAU.5.2/PACE_EAC The TSF shall authenticate any user’s claimed
identity according to the following rules:
194 [selection: Triple-DES, AES or other approved algorithms]
195 [assignment: identified authentication mechanism(s)]
196 [assignment: identified authentication mechanism(s)]
197 [selection: Triple-DES, AES or other approved algorithms]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 80 of 104
1. Having successfully run the PACE protocol the TOE accepts only received
commands with correct message authentication code sent by means of secure
messaging with the key agreed with the terminal by means of the PACE
protocol.
2. The TOE accepts the authentication attempt as Personalization Agent by the Symmetric
Authentication Mechanism with Personalization Agent Key198.
3. After run of the Chip Authentication Protocol Version 1 the TOE accepts only received
commands with correct message authentication code sent by means of secure messaging
with key agreed with the terminal by means of the Chip Authentication Mechanism v.1.
4. The TOE accepts the authentication attempt by means of the Terminal Authentication
Protocol only if the terminal uses the public key presented during the Chip Authentication
Protocol and the secure messaging established by the Chip Authentication Mechanism
v.1.199
5. none200.
Application Note 70: The SFR FIA_UAU.5.1/PACE in the current PP [PP_EAC]
covers the definition in PACE PP [PP_SAC] and extends it by EAC aspects 4), 5),
and 6). The SFR FIA_UAU.5.2/PACE in the current PP covers the definition in
PACE PP [PP_SAC] and extends it by EAC aspects 2), 3), 4) and 5). These
extensions do not conflict with the strict conformance to PACE PP.
FIA_UAU.6/EAC Re-authenticating – Re-authenticating of Terminal by the TOE
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.6.1/EAC The TSF shall re-authenticate the user under the conditions
each command sent to the TOE after successful run of the Chip Authentication
Protocol Version 1 shall be verified as being sent by the Inspection System201.
Application Note 71: The Basic Access Control Mechanism and the Chip
Authentication Protocol specified in [TR-03110_1] include secure messaging for all
commands exchanged after successful authentication of the Inspection System.
The TOE checks by secure messaging in MAC_ENC mode each command based
on Retail-MAC whether it was sent by the successfully authenticated terminal (see
FCS_COP.1.1/MAC for further details). The TOE does not execute any command
with incorrect message authentication code. Therefore the TOE reauthenticates the
user for each received command and accepts only those commands received from
the previously authenticated user.
FIA_API.1 Authentication Proof of Identity
198 [selection: the Symmetric Authentication Mechanism with Personalization Agent Key, the Terminal Authentication Protocol with Personalization Agent
Keys]
199 [assignment: rules describing how the multiple authentication mechanisms provide authentication]
200 [assignment: rules describing how the multiple authentication mechanisms provide authentication]
201 [assignment: list of conditions under which re-authentication is required]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 81 of 104
Hierarchical to: No other components.
Dependencies:No dependencies.
FIA_API.1.1 The TSF shall provide a Chip Authentication Protocol Version 1
according to [TR-03110_1]202 to prove the identity of the TOE203.
Application note 72: This SFR requires the TOE to implement the Chip
Authentication Mechanism v.1 specified in [TR-03110_1]. The TOE and the
terminal generate a shared secret using the Diffie-Hellman Protocol (DH or EC-DH)
and two session keys for secure messaging in ENC_MAC mode according to
[ICAO_9303_1]. The terminal verifies by means of secure messaging whether the
travel document’s chip was able or not to run his protocol properly using its Chip
Authentication Private Key corresponding to the Chip Authentication Key
(EF.DG14).
FIA_API.1/AA Authentication Proof of Identity – MRTD
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_API.1.1/AA The TSF shall provide the Active Authentication Mechanism
according to [TR-03110_1]204 to prove the identity of the TOE205.
7.1.4.3 Class FDP User Data Protection
FDP_ACC.1/TRM_EAC Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.1.1/TRM_EAC The TSF shall enforce the Access Control SFP206 on
terminals gaining access to the User Data and data stored in EF.SOD of the logical
travel document207.
202 [assignment: authentication mechanism]
203 [assignment: authorized user or role]
204 [assignment: authentication mechanism]
205 [assignment: authorized user or role]
206 [assignment: access control SFP]
207 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 82 of 104
Application note 73: The SFR FIA_ACC.1.1 in the current PP [PP_EAC] covers the
definition in PACE PP [PP_SAC] and extends it by data stored in EF.SOD of the
logical travel document. This extension does not conflict with the strict conformance to
PACE PP.
The TOE shall meet the requirement “Security attribute based access control
(FDP_ACF.1)” as specified below (Common Criteria Part 2).
FDP_ACF.1/TRM_EAC Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
FDP_ACF.1.1/TRM_EAC The TSF shall enforce the Access Control SFP208 to
objects based on the following:
1. Subjects:
a. Terminal,
b. BIS-PACE,
c. Extended Inspection System
2. Objects:
a. data EF.DG1, EF.DG2 and EF.DG5 to EF.DG16, EF.SOD and
EF.COM of the logical travel document,
b. data EF.DG3 of the logical travel document,
c. data in EF.DG4 of the logical travel document,
d. all TOE intrinsic secret cryptographic keys stored in the travel
document209
3. Security attributes:
a. PACE Authentication
b. Terminal Authentication v.1
c. Authorisation of the Terminal210
FDP_ACF.1.2/TRM_EAC The TSF shall enforce the following rules to determine if
an operation among controlled subjects and controlled objects is allowed: A BIS-
208 [assignment: access control SFP]
209 e.g. Chip Authentication Version 1 and ephemeral keys
210 [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]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 83 of 104
PACE is allowed to read data objects from FDP_ACF.1.1/TRM according to
[ICAO_SAC] after a successful PACE authentication as required by
FIA_UAU.1/PACE211.
FDP_ACF.1.3/TRM_EAC The TSF shall explicitly authorize access of subjects to
objects based on the following additional rules: none212.
FDP_ACF.1.4/TRM_EAC The TSF shall explicitly deny access of subjects to
objects based on the rule:
1. Any terminal being not authenticated as PACE authenticated BIS-PACE
is not allowed to read, to write, to modify, to use any User Data stored on
the travel document.
2. Terminals not using secure messaging are not allowed to read, to write,
to modify, to use any data stored on the travel document.
3. Any terminal being not successfully authenticated as Extended
Inspection System with the Read access to DG 3 (Fingerprint) granted by
the relative certificate holder authorization encoding is not allowed to
read the data objects 2b) of FDP_ACF.1.1/TRM.
4. Any terminal being not successfully authenticated as Extended
Inspection System with the Read access to DG 4 (Iris) granted by the
relative certificate holder authorization encoding is not allowed to read
the data objects 2c) of FDP_ACF.1.1/TRM.
5. Nobody is allowed to read the data objects 2d) of FDP_ACF.1.1/TRM,
6. Terminals authenticated as CVCA or as DV are not allowed to read data
in the EF.DG3 and EF.DG4213.
Application note 74: The SFR FDP_ACF.1.1/TRM in the current PP [PP_EAC]
covers the definition in PACE PP [PP_SAC] and extends it by additional subjects
and objects. The SFRs FDP_ACF.1.2/TRM and FDP_ACF.1.3/TRM in the current
PP cover the definition in PACE PP [PP_SAC]. The SFR FDP_ACF.1.4/TRM in the
current PP covers the definition in PACE PP [PP_SAC] and extends it by 3) to
6).These extensions do not conflict with the strict conformance to PACE PP.
Application Note 75: The relative certificate holder authorization encoded in the
CVC of the inspection system is defined in [TR-03110_1]. The TOE verifies the
certificate chain established by the Country Verifying Certification Authority, the
Document Verifier Certificate and the Inspection System Certificate (cf.
FMT_MTD.3). The Terminal Authorization is the intersection of the Certificate
211 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects]
212 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
213 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 84 of 104
Holder Authorization in the certificates of the Country Verifying Certification
Authority, the Document Verifier Certificate and the Inspection System Certificate in
a valid certificate chain.
Application Note 76: Please note that the Document Security Object (SOD) stored
in EF.SOD (see [ICAO_9303_1]) does not belong to the user data, but to the TSF
data. The Document Security Object can be read out by Inspection Systems using
PACE, see [ICAO_SAC].
Application note 77: FDP_UCT.1/TRM and FDP_UIT.1/TRM require the
protection of the User Data transmitted from the TOE to the terminal by secure
messaging with encryption and message authentication codes after successful
Chip Authentication Version 1 to the Inspection System. The Password
Authenticated Connection Establishment, and the Chip Authentication Protocol v.1
establish different key sets to be used for secure messaging (each set of keys for
the encryption and the message authentication key).
7.1.4.4 Class FMT Security Management
Application note 58a: The SFR FMT_SMR.1/PACE provides basic requirements
to the management of the TSF data.
FMT_SMR.1/PACE_EAC Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification.
FMT_SMR.1.1/PACE_EAC The TSF shall maintain the roles
1. Manufacturer,
2. Personalization Agent,
3. Terminal,
4. PACE authenticated BIS-PACE,
5. Country Verifying Certification Authority,
6. Document Verifier,
7. Domestic Extended Inspection System,
8. Foreign Extended Inspection System.214
FMT_SMR.1.2/PACE_EAC The TSF shall be able to associate users with
roles.
Application note 78: The SFR FMT_SMR.1.1/PACE in the current PP [PP_EAC]
covers the definition in PACE PP [PP_SAC] and extends it by 5) to 8). This extension
does not conflict with the strict conformance to PACE PP.
214 [assignment: the authorised identified roles]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 85 of 104
Application note 79: The SFR FMT_LIM.1 and FMT_LIM.2 address the
management of the TSF and TSF data to prevent misuse of test features of the
TOE over the life cycle phases.
Application note 80: The following SFR are iterations of the component
Management of TSF data (FMT_MTD.1). The TSF data include but are not limited
to those identified below.
FMT_MTD.1/CVCA_INI Management of TSF data – Initialization of CVCA
Certificate and Current Date
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MTD.1.1/CVCA_INI The TSF shall restrict the ability to write215 the
1. initial Country Verifying Certification Authority Public Key,
2. initial Country Verifying Certification Authority Certificate,
3. initial Current Date
4. none216
to the Personalization Agent217.
Application Note 81 (edited by the ST author): The initial Country Verifying
Certification Authority Public Key is written by the Personalization Agent (cf. [TR-
03110_1], sec. 2.2.6). The initial Country Verifying Certification Authority Public
Keys (and their updates later on) are used to verify the Country Verifying
Certification Authority Link-Certificates. The initial Country Verifying Certification
Authority Certificate and the initial Current Date is needed for verification of the
certificates and the calculation of the Terminal Authorization.
FMT_MTD.1/CVCA_UPD Management of TSF data – Country Verifying
Certification Authority
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MTD.1.1/CVCA_UPD The TSF shall restrict the ability to update218 the
1. Country Verifying Certification Authority Public Key,
215 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
216 [assignment: list of TSF data]
217 [assignment: the authorised identified roles]
218 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 86 of 104
2. Country Verifying Certification Authority Certificate219
to Country Verifying Certification Authority220.
Application Note 82 (edited by the ST author): The Country Verifying
Certification Authority updates its asymmetric key pair and distributes the public
key be means of the Country Verifying CA Link-Certificates (cf. [TR-03110_1], sec.
2.2). The TOE updates its internal trust-point if a valid Country Verifying CA Link-
Certificates (cf. FMT_MTD.3) is provided by the terminal (cf. [TR-03110_1], sec.
2.2.3 and 2.2.4).
FMT_MTD.1/DATE Management of TSF data – Current date
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MTD.1.1/DATE The TSF shall restrict the ability to modify221 the Current
date222 to
1. Country Verifying Certification Authority,
2. Document Verifier,
3. Domestic Extended Inspection System223.
Application Note 83 (edited by the ST author): The authorized roles are
identified in their certificate (cf. [TR-03110_1], sec. 2.2.4 and Table A.5) and
authorized by validation of the certificate chain (cf. FMT_MTD.3). The authorized
role of the terminal is part of the Certificate Holder Authorization in the card
verifiable certificate provided by the terminal for the identification and the Terminal
Authentication (cf. [TR-03110_1], annex A.3.3, for details).
FMT_MTD.1/CAPK Management of TSF data – Chip Authentication Private Key
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MTD.1.1/CAPK The TSF shall restrict the ability to create, load224 the
Chip Authentication Private Key225 to the Manufacturer and the Personalization
Agent226.
219 [assignment: list of TSF data]
220 [assignment: the authorised identified roles]
221 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
222 [assignment: list of TSF data]
223 [assignment: the authorised identified roles]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 87 of 104
Application note 84 (edited by the ST author): The verb “load” means here that
the Chip Authentication Private Key is generated securely outside the TOE and
written into the TOE memory. The verb “create” means here that the Chip
Authentication Private Key is generated by the TOE itself.
FMT_MTD.1/KEY_READ_EAC Management of TSF data –Key Read
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MTD.1.1/KEY_READ_EAC The TSF shall restrict the ability to read227
the
1. PACE passwords,
2. Chip Authentication Private Key,
3. Personalization Agent Keys
4. Active Authentication Private Key228
to none229.
Application note 85 (of the ST author): A refinement has been added to this SFR
to also cover the private key for the Active Authentication mechanism.
Application note 86: The SFR FMT_MTD.1/KEY_READ in the current PP [PP_EAC]
covers the definition in PACE PP [PP_SAC] and extends it by additional TSF data.
This extension does not conflict with the strict conformance to PACE PP.
FMT_MTD.3 Secure TSF data
Hierarchical to: No other components.
Dependencies: FMT_MTD.1 Management of TSF data
FMT_MTD.3.1 The TSF shall ensure that only secure values of the certificate
chain are accepted for TSF data of the Terminal Authentication Protocol v.1 and
the Access Control230.
Refinement: The certificate chain is valid if and only if
224 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
225 [assignment: list of TSF data]
226 [assignment: the authorised identified roles]
227 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
228 [assignment: list of TSF data]
229 [assignment: the authorised identified roles]
230 [assignment: list of TSF data]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 88 of 104
(1) the digital signature of the Inspection System Certificate can be
verified as correct with the public key of the Document Verifier
Certificate and the expiration date of the Inspection System Certificate
is not before the Current Date of the TOE,
(2) the digital signature of the Document Verifier Certificate can be verified
as correct with the public key in the Certificate of the Country Verifying
Certification Authority and the expiration date of the Document Verifier
Certificate is not before the Current Date of the TOE,
(3) the digital signature of the Certificate of the Country Verifying
Certification Authority can be verified as correct with the public key of
the Country Verifying Certification Authority known to the TOE and the
expiration date of the Certificate of the Country Verifying Certification
Authority is not before the Current Date of the TOE.
The Inspection System Public Key contained in the Inspection System
Certificate in a valid certificate chain is a secure value for the authentication
reference data of the Extended Inspection System.
The intersection of the Certificate Holder Authorizations contained in the
certificates of a valid certificate chain is a secure value for Terminal
Authorization of a successful authenticated Extended Inspection System.
Application note 87: The Terminal Authentication is used for Extended Inspection
System as required by FIA_UAU.4 and FIA_UAU.5. The Terminal Authorization is
used as TSF data for access control required by FDP_ACF.1.
FMT_MTD.1/AAPK Management of TSF data – Active Authentication Private
Key
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by
FMT_SMF.1
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1/PACE
FMT_MTD.1.1/AAPK The TSF shall restrict the ability to create, load231 the
Active Authentication Private Key232 to the Manufacturer and the Personalization
Agent233.
7.1.4.5 Class FPT Protection of the Security Functions
FPT_EMS.1/EAC TOE Emanation
231 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
232 [assignment: list of TSF data]
233 [assignment: the authorised identified roles]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 89 of 104
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_EMS.1.1/EAC The TOE shall not emit information about IC power
consumption and command execution time234 in excess of non useful
information235 enabling access to
1. Chip Authentication Session Keys
2. PACE Session Keys (PACE-KMAC, PACE-KENC)
3. the ephemeral private key ephem SKPICC-PACE
4. Active Authentication Private Key236
5. Personalisation Agent Key(s)
6. Chip Authentication Private Key237 and
7. none238.
FPT_EMS.1.2/EAC The TSF shall ensure any users239 are unable to use the
following interface smart card circuit contacts240 to gain access to
1. Chip Authentication Session Keys
2. PACE Session Keys (PACE-KMAC, PACE-KENC)
3. the ephemeral private key ephem SKPICC-PACE
4. Active Authentication Private Key241
5. Personalisation Agent Key(s)
6. Chip Authentication Private Key242 and
7. none243.
Application note 88: The SFR FPT_EMS.1.1 in the current PP [PP_EAC] covers the
definition in PACE PP and extends it by EAC aspects 1., 5. and 6. The SFR
FPT_EMS.1.2 in the current PP covers the definition in PACE PP [PP_SAC] and
extends it by EAC aspects 4) and 5). These extensions do not conflict with the strict
conformance to PACE PP.
234 [assignment: types of emissions]
235 [assignment: specified limits]
236 [assignment: list of types of TSF data]
237 [assignment: list of types of TSF data]
238 [assignment: list of types of user data]
239 [assignment: type of users]
240 [assignment: type of connection]
241 [assignment: list of types of TSF data]
242 [assignment: list of types of user data]
243 [assignment: list of types of user data]
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 90 of 104
Application Note 89 (edited by the ST author): The TOE prevents attacks
against the listed secret data where the attack is based on external observable
physical phenomena of the TOE. Such attacks may be observable at the interfaces
of the TOE or may be originated from internal operation of the TOE or may be
caused by an attacker that varies the physical environment under which the TOE
operates. The set of measurable physical phenomena is influenced by the
technology employed to implement the smart card. The travel document’s chip can
provide a smart card contactless interface and contact based interface according to
ISO/IEC 7816-2 [ISO/IEC 7816-2] as well (in case the package only provides a
contactless interface the attacker might gain access to the contacts anyway).
Examples of measurable phenomena include, but are not limited to variations in
the power consumption, the timing of signals and the electromagnetic radiation due
to internal operations or data transmissions.
7.2 Security Assurance Requirements
For the BAC feature, the TOE claims EAL 4 augmented with ALC_DVS.2 and
ATE_DPT.2, therefore [PP_BAC] section 6.2 “Security Assurance Requirements for the
TOE” applies.
For PACE and PACE-EAC features, the current document claims EAL5 augmented
with ALC_DVS.2 and AVA_VAN.5 therefore it claims a higher assurance level
compared to [PP_SAC] and [PP_EAC], section 6.2 respectively.
7.3 Security Requirements Rationale
7.3.1 Security Functional Requirements Rationale
Respective sections 6.3.1 “Security Functional Requirements Rationale” of [PP_SAC],
[PP_BAC] and [PP_EAC] are applicable for this chapter.
For the additionally defined SFRs in this ST, FIA_API.1/AA, FMT_MTD.1/AAPK and
FCS_COP.1/SIG_GEN formalizing the Active Authentication feature they meet the
security objective OT.Active_Auth together with FMT_MTD.1.1/KEY_READ_EAC,
FPT_EMS.1/EAC from [PP_EAC].
7.3.2 Rationale for SFR’s Dependencies
[PP_SAC], [PP_BAC] and [PP_EAC] section 6.3.2 “Rationale for SFR’s
Dependencies” are also applicable for this chapter.
The dependency analysis for the Active Authentication Mechanism (FIA_API.1/AA,
FMT_MTD.1/AAPK and FCS_COP.1/SIG_GEN) has directly been made within the
description of each SFR in section 7.1 above.
7 Security Requirements
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 91 of 104
7.3.3 Security Assurance Requirements Rationale
[PP_BAC] section 6.3.3 “Security Assurance Requirements Rationale “ is applicable for
this chapter. Additionally due to the old CC version on which PP0055 is based
ATE_DPT.2 is added.
[PP_EAC] and [PP_SAC] and their respective sections 6.3.3 “Security Assurance
Requirements Rationale“ are also applicable for this chapter with one additional
rationale justifying the security assurance dependencies.
With the exception of ALC_DVS.2 and AVA_VAN.5, all assurance components are
part of the EAL5 package, which by package design does not have any dependency
conflicts and is hierarchical to EAL4. The assurance components ALC_DVS.2 and
AVA_VAN.5 are also part of the assurance requirements from [PP_SAC], where
assurance dependencies are met as is shown in section 6.3.3 from [PP_SAC].
EAL5+ augmented with ALC_DVS.2 and AVA_VAN.5 is appropriate for this TOE,
because this assurance level is requested by several states. The assurance expectations
for this kind of application are high due to the sensitivity of data stored by the TOE.
Therefore several governmental organizations request for an increased assurance level.
7.3.4 Security Requirements – Internal Consistency
The rationale for the internal consistency of the SFRs from [PP_SAC], [PP_BAC] and
[PP_EAC] section 6.3.4 “Security Requirements – Internal Consistency” are also
applicable to this chapter.
The additions made to include the Active Authentication Mechanism (FIA_API.1/AA,
FMT_MTD.1/AAPK and FCS_COP.1/SIG_GEN, see also chapter 7.3.1) have been
integrated in a consistent way to the model designed by the Protection Profiles, e. g. by
using the subject, object and operation definitions.
The assurance package EAL5 and EAL4 are pre-defined sets of internally consistent
assurance requirements. The dependency analysis for the sensitive assurance
components in [PP_SAC], [PP_EAC] and [PP_BAC] section 7.3.3 “Security Assurance
Requirements Rationale” together with the additional rational from section 7.3.3 show
that the assurance requirements are internally consistent as all (additional) dependencies
are satisfied and no inconsistency appears.
The rationale for internal consistency between functional and assurance requirements
from [PP_SAC], [PP_EAC] and and [PP_BAC] section 6.3.4 “Security Requirements –
Internal Consistency” are also applicable to this chapter.
8 TOE summary specification
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 92 of 104
8 TOEsummaryspecification
8.1 TOE Security functions
This chapter gives the overview description of the different TOE Security Functions
composing the TSF.
8.1.1 SF_AccessControl
The TOE provides access control mechanisms that allow among others the maintenance
of different users (Manufacturer, Personalisation Agent, Country Verifying Certification
Authority (CVCA), Document Verifier (DV), domestic Extended Inspection System,
foreign Extended Inspection System).
The TOE restricts the ability to write the Initialisation Data and Pre-personalisation Data
to the Manufacturer. Manufacturer is the only role with the capability to store the IC
Identification Data in the audit records. Users of role Manufacturer are assumed default
users by the TOE during the Phase 2.
Personalisation Agent is the only role with the ability:
• to disable read access for users to the Initialisation Data.
• to write the initial CVCA Public Key, the initial CVCA Certificate, and the initial
Current Date.
• to write the Document Basic Access Keys and the chip authentication private key
(which may also be written by the manufacturer).
• to write and to read the data of the EF.COM, EF.SOD, EF.DG1 to EF.DG16 of the
logical travel document after successful authentication.
No terminal is allowed
• to modify any of the EF.DG1 to EF.DG16 of the logical MRTD,
• to read any of the EF.DG1 to EF.DG16 of the logical MRTD.
The access control mechanisms ensure that nobody is allowed to read the Document
Basic Access Keys and the Personalization Agent Keys.
The access control mechanisms ensure that only the Country Verifying Certification
Authority has the ability to update the CVCA Public Key and the CVCA Certificate.
The access control mechanisms ensure that only authenticated Extended Inspection
System with the Read access to
• DG 3 (Fingerprint) is allowed to read the data in EF.DG3 of the logical travel
document.
8 TOE summary specification
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 93 of 104
• DG 4 (Iris) is allowed to read the data in EF.DG4 of the logical travel document.
The successfully with PACE authenticated Basic Inspection System (BIS-PACE)
terminal is allowed to read data from EF.DG1, EF.DG2, EF.DG3, EF.DG4 and EF.DG5
to EF.DG16 of the logical travel document, read data of the logical document.
The TOE maintains the role Basic Inspection System.
The successfully authenticated Basic Inspection System is allowed to read data in
EF.COM, EF.SOD, EF.DG1, EF.DG2 and EF.DG5 to EF.DG16 of the logical MRTD.
Terminals not using secure messaging are not allowed to read, to modify, to write or to
use any data stored on the travel document
The TOE recognises the travel document holder or an authorised other person or device
(BIS-PACE) by using PACE authenticated BIS-PACE.
In all other cases, reading any of the EF.DG3 to EF.DG4 of the logical travel document
is explicitly denied.
The access control mechanisms ensure that nobody is allowed to read the Document
Basic Access Keys, the Chip Authentication Private Key, the Personalisation Agent
Keys, and the Active Authentication Private Key.
A terminal authenticated as CVCA or as DV is explicitly denied to read data in the
EF.DG3 and EF.DG4.
Any terminal is explicitly denied to modify any of the EF.DG1 to EF.DG16 of the
logical travel document.
Only secure values of the certificate chain are accepted for TSF data of the Terminal
Authentication Protocol and the Access Control.
Test features of the TOE are not available for the user in Phase 4. Deploying test
features after TOE delivery does not allow User Data to be manipulated, sensitive User
Data (EF.DG3 and EF.DG4) to be disclosed, TSF data to be disclosed or manipulated,
software to be reconstructed and substantial information about construction of TSF to be
gathered which may enable other attacks.
The access control mechanisms allow the execution of certain security relevant actions
(e.g. self-tests) without successful user authentication.
All security attributes under access control are modified in a secure way so that no
unauthorised modifications are possible.
The TOE provides management functions for configuration, initialization, pre-
personalization and personalization.
The TOE does not allow user data to be disclosed after TOE delivery.
The TOE provides the manufacuterer and the peresonalization agent to create and load
the Active Authentication Private key.
8 TOE summary specification
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 94 of 104
The TOE allows the personalization agent to read out the initialisation data and the pre-
personalization data.
The TOE provides the CVCA, DV and Domestic Extended Inspection system the ability
to modify the current date.
The TOE allows the Personalization agent to write the document security object (SOd).
The TOE allows nobody to read the PACE passwords.
8.1.2 SF_Authentication
After activation or reset of the TOE no user is authenticated.
TSF-mediated actions on behalf of a user require the user’s prior successful
identification and authentication.
The TOE contains a deterministic random number generator rated DRG.3 according to
AIS20 [AES] Federal Information Processing Standards Publication 197,
ADVANCED ENCRYPTION
STANDARD (AES), U.S. DEPARTMENT OF COMMERCE/National Institute of Standard
and Technology, November 26, 2001
[AIS20] that provides random numbers used authentication. The seed for the
deterministic random number generator is provided by the PTG.2 true random number
generator [AIS31] of the underlying IC.
The TOE supports user authentication by the following means:
• Basic Access Control Authentication Mechanism (if a BIS chooses BAC as
authentication method)
• PACE Protocol (PACE with generic mapping and PACE-CAM)
• Terminal Authentication Protocol
• Secure messaging in MAC-ENC mode
• Symmetric Authentication Mechanism based on AES
• Chip Authentication authenticates the Genreral inspection system
Proving the identity of the TOE is supported by the following means:
• Chip Authentication Protocol
• Active Authentication Mechanism
The TOE prevents reuse of authentication data related to:
• Terminal Authentication Protocol
• Symmetric Authentication Mechanism based on AES
The Personalisation Agent authenticates himself to the TOE by use of the
Personalisation Agent Keys with the following cryptographic mechanism:
• Symmetric Authentication Mechanism based on AES
8 TOE summary specification
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 95 of 104
After completion of the PACE, the BAC or the Chip Authentication Protocol, the TOE
accepts commands with correct message authentication code only. These commands
must have been sent via secure messaging using the key previously agreed with the
terminal during the last authentication.
The TOE accepts terminal authentication attempts by means of the Terminal
Authentication Protocol only via secure messaging that was established by the preceding
Chip Authentication Protocol.
The TOE verifies each command received after successful completion of the Chip
Authentication Protocol as having been sent by the terminal.
The TOE enforces the Access Control SFP to transmit and receive user data in a manner
protected from unauthorised disclosure and modification, deletion, insertion and replay
errors
Protection of user data transmitted from the TOE to the terminal is achieved by means
of secure messaging with encryption and message authentication codes. After Chip
Authentication or PACE or BAC authentication, user data in transit is protected from
unauthorized disclosure, modification, deletion, insertion and replay attacks.
The TOE enforces the Basic Access Control SFP to transmit and receive user data in a
manner protected from unauthorised disclosure and modification, deletion, insertion and
replay errors.
The TOE detects when 15 unsuccessful authentication attempts occurs related to
authentication attempts using the PACE password as shared password and when the
defined number of unsuccessful authentication attempts has been met, the TOE delays
each following authentication attempt until the next successful authentication attempt by
approx. 1-10 seconds, the delay increasing on every unsuccessful authentication
attempts.
The TOE detects when an administrator configurable positive integer within range of
acceptable values 1 to 15 consecutive unsuccessful authentication attempts occurs
related to the BAC mechanism. When the defined number of unsuccessful
authentication attempts has been met, the TOE waits for an administrator configurable
time (1 to 10 seconds) between receiving the terminal challenge eIFD and sending the
TSF response eICC during the BAC authentication attempts.
The TOE performs hashing with SHA-1 for the BAC key derivation.
The TOE performs digital signature generation in accordance with a specified
cryptographic algorithm RSA or ECDSA.
The TOE performs digital singature verification in accordance with a specifioed
cryptographic algorithm ECDSA with SHA.
The TOE performs symmetric authentication –encryption and decryption in accordance
with a specifioed cryptographic algorithm AES.
The TOE allows to read out the initialization data in phase 2 Manufacturing, to read the
random identifier in phase 3 Personalization of the MRTD and phase 4 Operational Use.
8 TOE summary specification
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 96 of 104
The TOE allows establishing a communication protocol and to read out initializatoin
data if not restricted to the Personalization Agent.
The TOE allows authentication by selection of the authentication key.
The TOE prevents reuse of authentication data related to BAC and PACE.
The TSF provides chip authentication protocol version 1 and active authentication to
prove the identity of the TOE.
The TSF provide Passive Authentication according to [ICAO_9303_1] and according to
[TR-03110_3].
8.1.3 SF_AssetProtection
The TOE hides information about IC power consumption and command execution time
ensuring that no confidential information can be derived from this information.
8.1.4 SF_TSFProtection
The TOE detects physical tampering of the TSF with sensors for operating voltage,
clock frequency, temperature and electromagnetic radiation.
The TOE is resistant to physical tampering on the TSF. If the TOE detects with the
above mentioned sensors, that it is not supplied within the specified limits, a security
reset is initiated and the TOE is not operable until the supply is back in the specified
limits. The design of the hardware protects it against analyzing and physical tampering.
The TOE demonstrates the correct operation of the TSF by among others verifying the
integrity of the TSF and TSF data and verifying the absence of fault injections. In the
case of inconsistencies in the calculation of the signature and fault injections during the
operation of the TSF the TOE preserves a secure state.
8.1.5 SF_KeyManagement
The TOE supports onboard generation of cryptographic keys based on the ECDH
compliant [TR-3111] as well as generation of RSA and ECC key pairs.
The TOE generates Document Basic Access Keys using the Document basis access key
derviation algorithm.
The TOE supports overwriting the cryptographic keys with zero values as follows:
• the BAC Session Keys after detection of an error in a received command by
verification of the MAC, and after successful run of the Chip Authentication
Protocol,
• the PACE Session Keys after detection of an error in a received command by
verification of the MAC, and after successful run of the Chip Authentication
Protocol,
• the Chip Authentication Session Keys after detection of an error in a received
command by verification of the MAC,
8 TOE summary specification
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 97 of 104
• any session keys before starting the communication with the terminal in a new
power-on-session,
• deallocation of the ephemeral private key (ephem SKPICC PACE).
8.2 Assurance measures
This chapter describes the Assurance Measures fulfilling the requirements listed in
chapter 7.
The following table lists the Assurance measures and references the corresponding
documents describing the measures.
Assurance
Measures
Description
AM_ADV The representation of the TSF is described in the
documentation for functional specification, in the
documentation for the formal security policy
model,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
operational guidance documentation and in the
documentation for preparative procedures.
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 evaluator uses the development and guidance
documentation by the developer as a basis for his
vulnerability analysis.
Table 8: Reference of Assurance Measures
8 TOE summary specification
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 98 of 104
8.3 Association tables of SFRs and TSF
TOE SFR / Security Function
SF_AccessControl
SF_Authentication
SF_AssetProtection
SF_TSFProtection
SF_KeyManagement
FAU_SAS.1 x
FAU_SAS.1/BAC x
FCS_CKM.1 x
FCS_CKM.1/CA x
FCS_CKM.1/DH_PACE x
FCS_CKM.4 x
FCS_COP.1/CA_ENC x
FCS_COP.1/CA_MAC x
FCS_COP.1/PACE_ENC x
FCS_COP.1/PACE_MAC x
FCS_COP.1/SHA x
FCS_COP.1/MAC x
FCS_COP.1/SIG_VER x
FCS_COP.1/SIG_GEN x
FCS_COP.1/ENC x
FCS_COP.1/AUTH x
FCS_RND.1 x
FDP_ACC.1/TRM x
FDP_ACC.1/TRM_EAC x
FDP_ACF.1 x
FDP_ACF.1/TRM x
FDP_ACF.1/TRM_EAC x
FDP_RIP.1 x
FDP_UCT.1/TRM x
FDP_UIT.1/TRM x
FIA_AFL.1 x
FIA_AFL.1/PACE x
FIA_UID.1 x
8 TOE summary specification
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 99 of 104
TOE SFR / Security Function
SF_AccessControl
SF_Authentication
SF_AssetProtection
SF_TSFProtection
SF_KeyManagement
FIA_UID.1/PACE x
FIA_UID.1/PACE_EAC x
FIA_UAU.1 x
FIA_UAU.1/PACE x
FIA_UAU.1/PACE_EAC x
FIA_UAU.4 x
FIA_UAU.4/PACE x
FIA_UAU.4/PACE_EAC x
FIA_UAU.5 x
FIA_UAU.5/PACE x
FIA_UAU.5/PACE_EAC x
FIA_UAU.6 x
FIA_UAU.6/PACE x
FIA_UAU.6/EAC x
FIA_API.1 x
FIA_API.1/AA x
FDP_ACC.1 x
FDP_UCT.1 x
FDP_UIT.1 x
FMT_SMF.1 x
FMT_SMF.1/BAC x
FMT_SMR.1 x
FMT_SMR.1/PACE x
FMT_SMR.1/PACE_EAC x
FMT_LIM.1 x
FMT_LIM.1/BAC x
FMT_LIM.2 x
FMT_LIM.2/BAC x
FMT_MTD.1/AAPK x
8 TOE summary specification
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 100 of 104
TOE SFR / Security Function
SF_AccessControl
SF_Authentication
SF_AssetProtection
SF_TSFProtection
SF_KeyManagement
FMT_MTD.1/INI_ENA x
FMT_MTD.1/INI_DIS x
FMT_MTD.1/INI_DIS/BAC x
FMT_MTD.1/CVCA_INI x
FMT_MTD.1/CVCA_UPD x
FMT_MTD.1/DATE x
FMT_MTD.1/KEY_WRITE x
FMT_MTD.1/CAPK x
FMT_MTD.1/KEY_READ x
FMT_MTD.1/KEY_READ_BAC x
FMT_MTD.1/KEY_READ_EAC x
FMT_MTD.1/PA x
FMT_MTD.3 x
FPT_EMS.1 x
FPT_EMS.1/EAC x
FPT_EMSEC.1 x
FPT_TST.1 x
FPT_FLS.1 x
FPT_FLS.1/BAC x
FPT_PHP.3 x
FTP_ITC.1/PACE x
Table 9: SFRs and TSF - Coverage
9 References, and Abbreviations
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 101 of 104
9 References,andAbbreviations
9.1 References
[AES] Federal Information Processing Standards Publication 197, ADVANCED ENCRYPTION
STANDARD (AES), U.S. DEPARTMENT OF COMMERCE/National Institute of Standard
and Technology, November 26, 2001
[AIS20] Anwendungshinweise und Interpretationen zum Schema (AIS), AIS 20, Version 3, 15.05.2013,
Funktionalitätsklassen und Evaluierungsmethodologie für deterministische
Zufallszahlengeneratoren, Zertifizierungsstelle des BSI.
[AIS31] Anwendungshinweise und Interpretationen zum Schema (AIS), AIS 31,
Funktionalitätsklassen und Evaluierungsmethodologie für physikalische
Zufallszahlengeneratoren, Version 3, 15.05.2013
[ANSIX962] ANSI X9.62:2005, Public Key Cryptography for the Financial Services Industry, The Elliptic
Curve Digital Signature Algorithm (ECDSA)
[CC1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
general model. Version 3.1, Revision 5, April 2017. CCMB-2017-04-001.
[CC2] Common Criteria for Information Technology Security Evaluation, Part 2: Security functional
requirements. Version 3.1, Revision 5, April 2017. CCMB-2017-04-002.
[CC3] Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance
components. Version 3.1, Revision 5, April 2017. CCMB-2017-04-003.
[DES] FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION FIPS PUB 46-
3, DATA ENCRYPTION STANDARD (DES), Reaffirmed 1999 October 25, U.S.
DEPARTMENT OF COMMERCE/National Institute of Standards and Technology
[ICAO_9303_1] ICAO Doc 9303, Machine Readable Travel Documents, part 1 – Machine Readable Passports,
Seventh Edition, 2015, International Civil Aviation Organization
[ICAO_9303_10] International Civil Aviation Organization, DOC 9303 Machine Readable Travel Documents
Seventh Edition – 2015, Part 10: Logical Data Structure (LDS) for Storage of Biometrics and
Other Data in the Contactless Integrated Circuit (IC)
[ICAO_9303_11] International Civil Aviation Organization, DOC 9303 Machine Readable Travel Documents
Seventh Edition – 2015 Part 11: Security Mechanisms for MRTD's
[ICAO_SAC] International Civil Aviation Organization Machine Readable Travel DocumentsTechnical
Report Supplemental Access Control for Machine Readable Travel Documents Version 1.00,
November 2010
[ISO9796-2] ISO/IEC 9796-2, Information Technology – Security Techniques – Digital Signature Schemes
giving message recovery – Part 2: Integer factorisation based mechanisms, Dezember 2010
[ISO9797-1] ISO/IEC 9797-1:2011: Information technology – Security techniques –Message Authentication
Codes (MACs) – Part 1: Mechanisms using a block cipher.
[ISO/IEC 7816-2] ISO/IEC 7816: Identification cards — Integrated circuit cards, Version Second Edition, 2008
9 References, and Abbreviations
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 102 of 104
[ISO11770-3] ISO/IEC 11770-3:2015: Information technology – Security techniques – Key management-
Part 3: Mechanisms using asymmetric techniques
[ISO/IEC 14888-3] ISO/IEC 14888-3: Information technology – Security techniques – Digital signatures with
appendix – Part 3: Certificate-based mechanisms, 1999
[ISO15946-3] ISO/IEC 15946-3: Information technology — Security techniques — Cryptographic
techniques based on elliptic curves — Part 3: Key establishment, 2002
[ISO18031] ISO/IEC 18031:2011: Information technology – Security techniques – Random bit generation
[JCOP4 Cert] Assurance Continuity Maintenance Report JCOP 4 P71, NSCIB-CC-180212-5MA1, 23.01.2023
[JCOP4 ST] JCOP 4 P71 Security Target Lite, Security Target for JCOP 4 P71/SE050, Rev. 4.11, 03.01.2023,
NXP Semiconductors
[JCAPI31] Java Card Platform, versions 3.1, Classic Edition, Application Programming Interface,
November 2019. Published by Sun Microsystems, Inc.
[JCAPI305] Java Card API, Classic Edition. Version 3.0.5, 2015 (Oracle)
[JCRE301] Java Card 3 Platform Runtime Environment Specification, Classic Edition. Version 3.1.,
November 2019 (Oracle)
[JCSPP] Java Card System - Open Configuration Protection Profile Version 3.1, April 2020, developed
by Oracle Corporation, BSI-CC-PP-0099-V2-2020
[JCVM31] Java Card 3 Platform Virtual Machine Specification, Classic Edition. Version 3.1., November
2019 (Oracle)
[NXP ST] NXP Secure Smart Card Controller N7121 with IC Dedicated Software and Crypto Library
(R1/R2/R3/R4), Security Target, Rev. 2.6, 13 June 2022, BSI-DSZ-CC-1136-V3-2022-MA-01.
[PKCS1] PKCS #1: RSA Encryption Standard – An RSA Laboratories Technical Note, Version 2.2,
November, 2016
[PP_BAC] Common Criteria Protection Profile Machine Readable Travel Document with „ICAO
Application", Basic Access Control, BSI-CC-PP-0055, Version 1.10, 25th March 2009
[PP_EAC] Common Criteria Protection Profile Machine Readable Travel Document with „ICAO
Application", Extended Access Control with PACE (EAC PP), BSI-CC-PP-0056-V2-2012,
Version 1.3.2, 05th December 2012
[PP_SAC] Common Criteria Protection Profile Machine Readable Travel Document using Standard
Inspection Procedure with PACE (PACE PP), BSI-CC-PP-0068-V2-2011-MA-01, Version 1.0.1,
22th July 2014
[RFC5639] RFC 5639, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve
Generation, BSI and secunet, March 2010, ISSN 2070-1721
[SP800-20] NIST Special Publication 800-20, Modes of Operation Validation System for the Triple Data
Encryption Algorithm, US Department of Commerce, October 1999
[TR-03110_1] Federal Office for Information Security (BSI) Technical Guideline TR-03110-1 Advanced
Security Mechanisms for Machine Readable Travel Documents and eIDAS Token Part 1 -
eMRTDs with BAC/PACEv2 and EACv1 Version 2.20, 26. February 2015
9 References, and Abbreviations
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 103 of 104
[TR-03110_3] Federal Office for Information Security (BSI) Technical Guideline TR-03110-3 Advanced
Security Mechanisms for Machine Readable Travel Documents and eIDAS Token Part 3 -
Common Specifications Version 2.21, 21 December 2016
[TR-3111] Bundesamt für Sicherheit in der Informationstechnik (BSI), Technical Guideline TR-03111
Elliptic Curve Cryptography, TR-03111, 17.04.2009
[TR-3116-2] Technische Richtlinie TR-03116-2, eCard-Projekte der Bundesregierung, Teil 2 – Hoheitliche
Ausweisdokumente, Stand 2010, Bundesamt für Sicherheit in der Informationstechnik (BSI)
[UGPre] Guidance Documentation for the Initialization and Personalization Phase ePass Applet on
JCOP 4 C1, G+D, Version 0.5, 20.11.2023
[UGOpe] Guidance Documentation for the Usage Phase ePass Applet on JCOP 4 C1, G+D, Version 0.2,
31.07.2023
[UGD_JCOP] JCOP 4 P71, User manual for JCOP 4 P71, Rev. 4.3, DocNo 469543, 09 September 2022, NXP
Semiconductors.
[UGPerso] EPASS Applet EPASS10-200 Personalization Concept, Giesecke & Devrient, Version 1.3,
08.09.2023
[UGUsage] EPASS Applet EPASS10-200 Usage Phase Commands, Giesecke & Devrient, Version 1.3,
08.09.2023
[UGMain] Guidance Documentation ePass Applet on JCOP 4 C1, Giesecke & Devrient, Version 0.3,
05.09.2023
9.2 Abbreviations
API Application Programming Interface
BIS Basic Inspection System
EIS Extended Inspection System
CAP Converted Applet
CC Common Criteria
DES Data Encryption Standard
DS Dedicated software
EAL Evaluation Assurance Level
ECC Elliptic Curve Cryptography
HW Hardware
9 References, and Abbreviations
Security TargetePass Applet on JCOP 4 C1 /Version 1.3/Status 19.12.2023 Page 104 of 104
IC Integrated Circuit
IT Information Technology
JCRE Java Card Runtime Environment
JCVM Java Card Virtual Machine
OS Operating System
PIN Personal Identification Number
PP Protection Profile
RAM Random Access memory
ROM Read-Only Memory
RSA Rivest, Shamir and Adleman
SF Security Function
SFP Security Function Policy
SFR Security Functional Requirement
SHA Secure Hash Algorithm
ST Security Target
SW Software
TOE Target of Evaluation
TSC TSF Scope of Control
TSF TOE Security Functions
TSFI TSF Interface
TSP TOE Security Policy
End of Document