IDentity Applet v4.0/QSCD Security Target
Page 1 of 73
ID&TRUST
IDENTITY APPLET V4.0/QSCD
QUALIFIED ELECTRONIC SIGNATURE COMPLIANT
WITH IAS ECCV2 AND EIDAS
SECURITY TARGET
COMMON CRITERIA / ISO 15408
EAL5+
2026
Classification: Confidential
© Copyright
ID&Trust Ltd.
IDentity Applet v4.0/QSCD Security Target
Page 2 of 73
Revision History
Version Date Information
V1.0 12.01.2026 First release
IDentity Applet v4.0/QSCD Security Target
Page 3 of 73
Table of Contents
1. ST Introduction............................................................................................................... 9
1.1. ST Reference.......................................................................................................... 9
1.2. TOE Reference ....................................................................................................... 9
1.3. TOE Overview........................................................................................................10
1.3.1. TOE usage and major security features ..........................................................10
1.3.2. TOE type.........................................................................................................11
1.3.3. Non-TOE hardware/software/firmware ............................................................12
1.4. TOE Description.....................................................................................................12
1.4.1. Product type....................................................................................................12
1.4.2. Components of the TOE..................................................................................12
1.4.3. Operation of the TOE ......................................................................................14
1.4.4. TOE Definition.................................................................................................15
1.4.5. TOE life cycle..................................................................................................15
1.4.5.1. General....................................................................................................15
1.4.5.2. Preparation stage.....................................................................................16
1.4.5.3. Operational use stage ..............................................................................17
1.4.6. TOE security functions ....................................................................................18
2. Conformance Claims.....................................................................................................19
2.1. CC Conformance Claim .........................................................................................19
2.2. PP Claim, Package Claim ......................................................................................19
2.3. Conformance rationale...........................................................................................20
2.4. Statement of compatibility ......................................................................................20
2.4.1. Security Functionalities ...................................................................................20
2.4.2. OSPs ..............................................................................................................21
2.4.3. Security objectives ..........................................................................................22
2.4.4. Security requirements .....................................................................................24
2.5. Assurance requirements ........................................................................................28
2.6. Analysis..................................................................................................................28
3. Security Problem Definition ...........................................................................................29
3.1. Assets, users and threat agents .............................................................................29
3.1.1. Assets and objects..........................................................................................29
SCD...........................................................................................................................29
SVD...........................................................................................................................29
DTBS and DTBS/R....................................................................................................29
IDentity Applet v4.0/QSCD Security Target
Page 4 of 73
3.1.2. User and subjects acting for users ..................................................................29
User...........................................................................................................................29
Signatory ...................................................................................................................29
Administrator .............................................................................................................29
3.1.3. Threat agents..................................................................................................29
Attacker .....................................................................................................................29
3.2. Threats...................................................................................................................29
T.SCD_Divulg............................................................................................................29
T.SCD_Derive ...........................................................................................................30
T.Hack_Phys .............................................................................................................30
T.SVD_Forgery..........................................................................................................30
T.SigF_Misuse...........................................................................................................30
T.DTBS_Forgery........................................................................................................30
T.Sig_Forgery............................................................................................................30
3.3. Organizational Security Policies .............................................................................30
P.CSP_QCert ............................................................................................................30
P.QSign .....................................................................................................................30
P.Sigy_QSCD............................................................................................................31
P.Sig_Non-Repud......................................................................................................31
3.4. Assumptions ..........................................................................................................31
A.CGA .......................................................................................................................31
A.SCA........................................................................................................................31
4. Security Objectives........................................................................................................32
4.1. Security Objectives for the TOE .............................................................................32
OT.Lifecycle_Security................................................................................................32
OT.SCD/SVD_Auth_Gen...........................................................................................32
OT.SCD_Unique........................................................................................................32
OT.SCD_SVD_Corresp .............................................................................................32
OT.SCD_Secrecy ......................................................................................................32
OT.Sig_Secure ..........................................................................................................32
OT.Sigy_SigF ............................................................................................................32
OT.DTBS_Integrity_TOE ...........................................................................................33
OT.EMSEC_Design...................................................................................................33
OT.Tamper_ID...........................................................................................................33
OT.Tamper_Resistance.............................................................................................33
OT.TOE_QSCD_Auth................................................................................................33
OT.TOE_TC_SVD_Exp .............................................................................................33
IDentity Applet v4.0/QSCD Security Target
Page 5 of 73
OT.TOE_TC_VAD_Imp .............................................................................................33
OT.TOE_TC_DTBS_Imp ...........................................................................................33
4.2. Security Objectives for the Operational Environment..............................................34
OE.SVD_Auth............................................................................................................34
OE.CGA_Qcert..........................................................................................................34
OE.Dev_Prov_Service...............................................................................................34
OE.HID_TC_VAD_Exp ..............................................................................................34
OE.DTBS_Intend.......................................................................................................34
OE.SCA_TC_DTBS_Exp...........................................................................................35
OE.Signatory .............................................................................................................35
OE.CGA_QSCD_Auth ...............................................................................................35
OE.CGA_TC_SVD_Imp.............................................................................................35
4.3. Security Objectives Rationale.................................................................................36
4.4. Security Objectives Sufficiency ..............................................................................36
Countering of threats by security objectives...............................................................36
Enforcement of OSPs by security objectives..............................................................37
Upkeep of assumptions by security objectives...........................................................39
5. Extended Component Definition....................................................................................40
6. Security Requirements ..................................................................................................42
6.1. TOE Security Functional Requirements..................................................................42
6.1.1. Use of requirement specifications....................................................................42
6.1.2. Cryptographic support (FCS)...........................................................................42
FCS_CKM.1 ..............................................................................................................42
FCS_CKM.4 ..............................................................................................................43
FCS_COP.1...............................................................................................................43
6.1.3. User data protection (FDP) .............................................................................43
FDP_ACC.1/Signature_Creation ...............................................................................44
FDP_ACC.1/SCD/SVD_Generation...........................................................................44
FDP_ACF.1/SCD/SVD_Generation ...........................................................................44
FDP_ACC.1/SVD_Transfer .......................................................................................45
FDP_ACF.1/SVD_Transfer........................................................................................45
FDP_ACF.1/Signature creation..................................................................................46
FDP_DAU.2/SVD.......................................................................................................46
FDP_RIP.1 ................................................................................................................47
FDP_SDI.2/Persistent................................................................................................47
FDP_SDI.2/DTBS......................................................................................................48
FDP_UIT.1/DTBS ......................................................................................................48
IDentity Applet v4.0/QSCD Security Target
Page 6 of 73
6.1.4. Identification and authentication (FIA) .............................................................48
FIA_UID.1..................................................................................................................48
FIA_UAU.1 ................................................................................................................49
FIA_API.1 ..................................................................................................................49
FIA_AFL.1 .................................................................................................................50
6.1.5. Security management (FMT)...........................................................................50
FMT_SMR.1 ..............................................................................................................50
FMT_SMF.1...............................................................................................................50
FMT_MOF.1 ..............................................................................................................51
FMT_MSA.1/Admin ...................................................................................................51
FMT_MSA.1/Signatory...............................................................................................51
FMT_MSA.2 ..............................................................................................................52
FMT_MSA.3 ..............................................................................................................52
FMT_MSA.4 ..............................................................................................................52
FMT_MTD.1/Admin ...................................................................................................53
FMT_MTD.1/Signatory...............................................................................................53
6.1.6. Protection of the TSF (FPT) ............................................................................53
FPT_EMS.1...............................................................................................................53
FPT_FLS.1 ................................................................................................................54
FPT_PHP.1 ...............................................................................................................54
FPT_PHP.3 ...............................................................................................................54
FPT_TST.1................................................................................................................54
6.1.7. Trusted path/Channels (FTP)..........................................................................55
FTP_ITC.1/SVD.........................................................................................................55
FTP_ITC.1/VAD.........................................................................................................55
FTP_ITC.1/DTBS.......................................................................................................56
6.2. TOE Security Assurance Requirements .................................................................57
6.3. Security Requirements Rationale ...........................................................................57
6.3.1. Security Requirement Coverage .....................................................................57
6.3.2. TOE Security Requirements Sufficiency..........................................................58
6.4. Satisfaction of dependencies of security requirements...........................................60
6.5. Rationale for chosen security assurance requirements ..........................................62
7. TOE Summary Specification .........................................................................................63
7.1. TOE Security Functions .........................................................................................63
7.1.1. TSF.AccessControl .........................................................................................63
7.1.2. TSF.Authenticate ............................................................................................64
7.1.3. TSF.SecureManagement ................................................................................65
IDentity Applet v4.0/QSCD Security Target
Page 7 of 73
7.1.4. TSF.TrustedChannel.......................................................................................66
7.1.5. TSF.CryptoKey................................................................................................66
7.1.6. TSF.AppletparameterSign...............................................................................67
7.1.7. TSF.Platform...................................................................................................67
7.2. Fulfilment of the SFRs............................................................................................69
7.2.1. Correspondence of SFR and TOE mechanisms..............................................70
8. Glossary and Acronyms ................................................................................................71
9. Bibliography ..................................................................................................................72
IDentity Applet v4.0/QSCD Security Target
Page 8 of 73
List of Tables
1. Table Applet functionalities...............................................................................................11
2. Table Classification of Platform-TSFs...............................................................................21
3. Table Mapping of security objectives for the TOE.............................................................23
Table 4 Mapping of security objectives of the environment...................................................23
5. Table Mapping of Security requirements ..........................................................................28
6. Table Mapping of security problem definition to security objectives..................................36
7. Table Subjects and security attributes for access control .................................................44
9. Table Mapping of functional requirements to security objectives for the TOE ...................58
10. Table Functional Requirements Dependencies ..............................................................61
11. Table Satisfaction of dependencies of security assurance requirements ........................62
12. Table Mapping of SFRs to mechanisms of TOE .............................................................70
IDentity Applet v4.0/QSCD Security Target
Page 9 of 73
1. ST Introduction
This section provides document management and overview information that are required a potential
user of the TOE to determine, whether the TOE fulfils its requirements.
Throughout this document, the term QSCD refers to Qualified Signature Creation Device.
The TOE is a composite TOE. The Common Criteria Mandatory Technical Document Composite product
evaluation for Smart Cards and similar devices [8] contains all the relevant information about the
methodology to handle such a TOE. The developer followed the direction of the mandatory document,
and so should any relevant parties participate in the evaluation and certification of the TOE.
1.1. ST Reference
Title: Security Target IDentity Applet v4.0/QSCD - Qualified electronic signature
compliant with IAS ECCv2 and eIDAS
TOE: IDentity Applet v4.0/QSCD on NXP JCOP 4.5 P71
Author: ID&Trust Ltd.
Version number: v1.0
Date: 12.01.2026
The Security Target defines the security requirements of a Qualified Signature Creation Device (QSCD)
for the generation of signature-creation data (SCD) and the creation of qualified electronic signatures.
Additionally, the TOE of this ST supports its authentication as QSCD by the certificate generation
application (CGA) of the Certification service provider (CSP) and a trusted communication with this CGA
for protection of signature verification data (SVD) generated and exported by the TOE and imported by
CGA.
The TOE may implement additional functions and security requirements e.g. for editing and displaying
the data to be signed (DTBS), but these additional functions and security requirements are not subject
of this Security Target
1.2. TOE Reference
The Security Target refers to the product “ID&Trust IDentity Applet Suite v4.0” for CC evaluation.
TOE Name: IDentity Applet v4.0/QSCD on NXP JCOP 4.5 P71
TOE short name: IDentity Applet v4.0/QSCD
TOE Identification
Data: IDentity Applet/QSCD v4.0.9219
Platform Identification
Data:
Patch ID 0000000000000000
ROM ID B3375FE9B5508BC4
Build ID 6D20B6197D635E7C
Platform ID J3R6000373181200
The TOE name and the TOE identification data constitute the accurate TOE reference.
Evaluation Criteria: [4]
Evaluation
Assurance Level: EAL 5 augmented by ALC.DVS.2 and AVA_VAN.5
IDentity Applet v4.0/QSCD Security Target
Page 10 of 73
Developer: ID&Trust Ltd.
Evaluation Sponsor:NXP Semiconductors Netherlands B.V. 5656, AG Eindhoven, High Tech Campus
60
Keywords: Qualified Signature-Creation Device, QSCD, electronic signature, digital signature
1.3. TOE Overview
The TOE comprises:
I. Underlying platform of the TOE, which is evaluated by SGS Brightsight BV and certified by TÜV
Rheinland Nederland B.V.
Evaluation
assurance level: EAL6 augmented by ASE_TSS.2 and ALC_FLR.1.
CC Certification
number: NSCIB-CC-2300127-02
Long platform
name: JCOP 4.5 P71
Short name: JCOP 4.5
It consists of:
a) Micro Controller (a secure smart card controller from NXP from the SmartMX3 family);
b) IC Dedicated Software: MC FW Micro Controller Firmware and Crypto Library;
c) IC Embedded Software JCOP 4.5 P71 (Java Card Virtual Machine, Runtime Environment, Java
Card API, Global Platform (GP) Framework) and OS Updater.
II. the Application Part of the TOE:
ID&Trust IDentity Applet Suite v4.0/QSCD;
the associated guidance documentation [5], [6]
1.3.1. TOE usage and major security features
The TOE addressed by the current ST is a Qualified Signature Creation Device (QSCD) representing a
contact or contactless smart card which is able to generate signature creation data (SCD) and create
qualified electronic signatures. The TOE protects the SCD and ensures that only an authorized signatory
can use it.
The TOE meets all the following requirements as defined in the [24] (article 26):
a) it is uniquely linked to the signatory;
b) it is capable of identifying the signatory;
c) it is created using means that the signatory can maintain under his sole control;
d) it is linked to the data to which it relates in such a manner that any subsequent change of the
data is detectable.
The TOE supports and implements cryptographic mechanisms that are compliant with [32].
IDentity Applet is a highly configurable eID solution. It is able to satisfy multiple different application
requirements even within a single applet instance. The Application part of the TOE, the applet
functionalities are distributed according to the following table:
Application Function Standard Protection Profile
IDentity/PKI Flexible PKI token
CEN TS 14890-1/2
IAS-ECC 1.0.1 [23]
-
IDentity Applet v4.0/QSCD Security Target
Page 11 of 73
Application Function Standard Protection Profile
IDentity/IAS
European card for e-
Services and National e-
ID applications
CEN/TS 15480-2 [22]
IAS-ECC 1.0.1 [23]
-
IDentity/QSCD
Qualified Signature
Creation Device
CEN/TS 15480-2 [22]
IAS-ECC 1.0.1[23]
REGULATION (EU) No
910/2014 [24]
BSI TR-03117 [27]
[18]
[19]
[20]
IDentity/IDL
International Driving
License
ISO/IEC 18013
BSI-CC-PP-0055
[15]
IDentity/EDL
European Driving
License
2012/383/EC -
IDentity/eVR
Electronic Vehicle
Registration
1999/37/EC -
IDentity/eHC
Electronic Health
Insurance
CEN/CWA 15794 -
IDentity/BAC
Basic Access Control
(BAC)
ICAO Doc 9303 [13]
BSI-CC-PP-0055
[15]
IDentity-J
Basic Access Control
(BAC)
Password Authenticated
Connection
Establishment (PACE)
ICAO Doc 9303 [13]
JISEC500 [30]
JISEC499 [31]
IDentity/PACE
-EAC1
Password Authenticated
Connection
Establishment (PACE)
Extended Access Control
v1 (EAC1)
ICAO Doc 9303 [13]
ICAO TR-SAC [14]
BSI TR-03110 v2.21 [9],
[10], [11], [12]
BSI-CC-PP-0068-
V2-2011 [17]
BSI-CC-PP-0056-
V2-2012 [16]
IDentity/eIDAS
Password Authenticated
Connection
Establishment (PACE)
Extended Access Control
v2 (EAC2)
ICAO TR-SAC [14]
BSI TR-03110 v2.21 [9],
[10], [11], [12]
BSI-CC-PP-0087
[20]
1. Table Applet functionalities
All the functions are supplied by the applet “ID&Trust IDentity Applet Suite Version 4.0”, the behaviour
of the applet changes according to the configuration applied during the personalization phase of IDentity
Applet life cycle, and the environmental behaviour of the usage phase.
The scope of the current ST is only concerned with applet behaviour of configuration:
IDentity/QSCD.
For the TOE, beside the QSCD application other applications may be present on the Platform. They are
not relevant for the current ST and do not infer the Security Functions of the TOE. The TOE utilises the
evaluation of the underlying Platform.
Part of the TOE is the associated guidance documentation, the IDentity Applet Suite v4.0 Administrator’s
Guide [5] and IDentity Applet Suite v4.0 User’s Guide [6].
The intended customer of the product the Card Issuer, who is in charge of the issuance of the product
to the smartcard holders.
1.3.2. TOE type
The TOE is the Smart Card Integrated Circuit with Dedicated Software, Embedded Software and IDentity
Applet v4.0/QSCD.
IDentity Applet v4.0/QSCD Security Target
Page 12 of 73
1.3.3. Non-TOE hardware/software/firmware
There is no explicit non-TOE hardware, software or firmware required by the TOE to perform its claimed
security features. The TOE is defined to comprise the chip and the complete operating system and
application.
1.4. TOE Description
1.4.1. Product type
The TOE is a Smart Card Integrated Circuit with Dedicated Software, Embedded Software and IDentity
Applet 4.0/QSCD.
1.4.2. Components of the TOE
Micro Controller
The Micro Controller is a secure smart card controller from NXP’s SmartMX3 family. The Micro
Controller contains a co-processor for symmetric cryptographic operations, supporting DES and AES,
as well as an accelerator for asymmetric cryptographic algorithms. The Micro Controller further contains
a physical random number generator. The supported memory technologies are volatile (Random Access
Memory (RAM)) and non-volatile (Read Only Memory (ROM) and FLASH) memory.
Access to all memory types is controlled by a Memory Management Unit (MMU) which allows to
separate and restrict access to parts of the memory.
IC dedicated software - Micro Controller Firmware
The Micro Controller Firmware is used for testing of the Micro Controller at production, for booting of the
Micro Controller after power-up or after reset, for configuration of communication devices and for writing
data to volatile and non-volatile memory.
IC dedicated software - Crypto Library
The Crypto Library provides implementations for symmetric and asymmetric cryptographic operations,
hashing, the generation of hybrid deterministic and hybrid physical random numbers and further
functions like secure copy and compare. The supported asymmetric cryptographic operations are ECC
and RSA. These algorithms use the Public Key Crypto Coprocessor (PKCC) of the Micro Controller for
the cryptographic operations.
Micro Controller, IC dedicated software (Micro Controller Firmware, Crypto Library) are covered by
the following certification:
Certification ID: BSI-DSZ-CC-1149-V4-2025
Evaluation
Level: EAL6+ ALC_FLR.1 and ASE_TSS.2 according to Security IC Platform Protection
Profile with Augmentation Packages Version 1.0, 13 January 2014, BSI-CC-00084-2014.
IC Embedded Software
Certification ID: NSCIB-CC-2300127-02
OS Name: JCOP 4.5 Operating System
Applied OS
configuration: SECID
Product
Identification1: Platform ID = J3R6000373181200
1 As described in [28] section 2.
IDentity Applet v4.0/QSCD Security Target
Page 13 of 73
ROM ID = B3375FE9B5508BC4
Evaluation
Level: CC EAL 6+ with ASE_TSS.2, ALC_FLR.1 according to Java Card System – Open
Configuration Protection Profile, version 3.0.5, Certified by Bundesamt für Sicherheit in der
Informationstechnik (BSI, BSI-CC-PP-0099-2017).
Platform UGD: [28]
IDentity Applet – accomplishing IDentity application
Product name: ID&Trust IDentity Applet Suite
Version: 4.0
Applet name:2 IDentity Applet V4.0/QSCD
TOE Guidance
Documentation3: IDentity Applet Suite v4.0 Administrator’s Guide [5]
IDentity Applet Suite v4.0 User’s Guide [6]
The logical architecture of the TOE:
1. Figure TOE Boundaries
The TOE is a composite TOE, with the dashed line indicating the whole TOE. The certified hardware
platform and JCOP 4.5 OS, denoted by purple and green. Within this ST the joint reference for certified
hardware platform and JCOP 4.5 OS is referred to as the Platform.
The application layer is highlighted in the blue box marks. The ID&Trust IDentity Applet Suite v4.0 can
be loaded in the Flash. During the creation phase, an instance is created in the Flash and following
several configuration steps it will be personalized as IDentity Applet v4.0/QSCD. For a more in depth
understanding please refer to Section 1.4.5 TOE life cycle and [5].
2 The applet is provided in cap file format.
3 The AGD documents provided in electronic document format.
IDentity Applet v4.0/QSCD Security Target
Page 14 of 73
Boxes depicted in white are indicative of components that have not undergone certification.
1.4.3. Operation of the TOE
The TOE is an QSCD which can generate the SCD/SVD key pair.
The IDentity Applet v4.0/QSCD is linked to a card reader/writer (card terminal) via the HW and physical
interfaces of the smart card. The smart card has contact type and contactless type interfaces.
The TOE may be applied to a contact type card reader/writer or to a contactless card reader/writer. The
card reader/writer either is an intelligent device having the capability to use the TOE or it is connected
to a computer such as a personal computer and allows application programs (APs) to use the TOE.
The contact types interface of the TOE:
• Contact type (ISO/IEC 7816-3 complaint);
• Contactless type (ISO/IEC 14443 complaint);
The TOE is designed and produced in a secure environment.
A functional overview of the TOE in its distinct operational environments:
• The preparation environment, where it interacts with a certification service provider through a
certificate-generation application (CGA) to obtain a certificate for the signature verification data
(SVD) corresponding with signature creation data (SCD) the TOE has generated. The TOE can
export the SVD through a trusted channel allowing the CGA to check the authenticity of the
SVD. The initialization environment interacts further with the TOE to personalize it with the initial
value of the reference-authentication data (RAD)
• The signing environment where it interacts with a signer through a signature-creation application
(SCA) to sign data after authenticating the signer as its signatory. The signature-creation
application provides the unique representation of data to be signed, thereof (DTBS/R) as input
to the TOE signature-creation function and obtains the resulting digital signature. The TOE and
the SCA communicate through a trusted channel to ensure the integrity of the DTBS respective
DTBS/R.
• The management environments where it interacts with the user or an QSCD-Provisioning
service provider to perform management operations, e.g. for the signatory to reset a blocked
RAD. A single device, e.g. a smart card terminal, may provide the required secure environment
for management and signing
The signing environment, the management environment and the preparation environment are secure
and protect data exchanged with the TOE.
The TOE stores signature creation data and reference authentication data. The TOE may store multiple
instances of SCD. In this case the TOE provides a function to identify each SCD and the SCA can
provide an interface to the signer to select an SCD for use in the signature creation function of the
QSCD. The TOE protects the confidentiality and integrity of the SCD and restricts its use in signature
creation to its signatory. The digital signature created by the TOE may be used to create a qualified
electronic signature as defined in Article 25 of [24]. Determining the state of the certificate as qualified
is beyond the scope of this document.
The signature creation application is assumed to protect the integrity of the input it provides to the TOE
signature creation function as being consistent with the user data authorized for signing by the signatory.
Unless implicitly known to the TOE, the SCA indicates the kind of the signing input (as DTBS/R) it
provides and computes any hash values required. The TOE may augment the DTBS/R with signature
parameters it stores and then computes a hash value over the input as needed by the kind of input and
the used cryptographic algorithm.
The TOE stores signatory reference authentication data to authenticate a user as its signatory. The RAD
is a password e.g. PIN. The TOE protects the confidentiality and integrity of the RAD. The TOE may
provide a user interface to directly receive verification authentication data (VAD) from the user,
alternatively, the TOE receives the VAD from the signature creation application. If the signature creation
application handles, is requesting or obtaining a VAD from the user, it is assumed to protect the
confidentiality and integrity of this data.
A certification service provider and a QSCD-provisioning service provider interact with the TOE in the
secure preparation environment to perform any preparation function of the TOE required before control
of the TOE is given to the legitimate user. These functions may include:
IDentity Applet v4.0/QSCD Security Target
Page 15 of 73
• initializing the RAD,
• generating a key pair,
• storing personal information of the legitimate user.
The TOE and the CGA communicate through a trusted channel in order to protect the integrity and
authenticity of the SVD exported from the TOE.
The TOE supports Certificate Request Signature (CRS) to provide evidence about the validity of the
SVD for the CGA. The CRS also proves that the SVD belongs to the TOE.
The CRS key pair is generated separately from the SCD/SVD key pair on the TOE, but in case the
generation the latter key pair the TOE signs the SVD with the private key of CRS. So, the CGA is able
to verify the validity of the SVD by checking the CRS.
The TOE and the SCA communicate through a trusted channel in order to protect the integrity of the
DTBS/R.
1.4.4. TOE Definition
The TOE is a combination of hardware and software configured to securely create, use and manage
signature-creation data (SCD). The QSCD protects the SCD during its whole life cycle as to be used in
a signature-creation process solely by its signatory.
The TOE comprises all IT security functionality necessary to ensure the secrecy of the SCD and the
security of the electronic signature.
The TOE provides the following functions:
(1) to generate signature-creation data (SCD) and the correspondent signature-verification data
(SVD),
(2) to export the SVD for certification through a trusted channel to the CGA,
(3) to prove the identity as QSCD to external entities,
(4) to optionally, receive and store certificate info,
(5) to switch the TOE from a non-operational state to an operational state, and
(6) if in an operational state, to create digital signatures for data with the following steps:
(a) select an SCD if multiple are present in the QSCD,
(b) authenticate the signatory and determine its intent to sign,
(c) receive the unique representation of data to be signed thereof (DTBS/R) through a trusted
channel with SCA,
(d) apply an appropriate cryptographic signature-creation function using the selected SCD to the
DTBS/R.
The TOE is prepared for the signatory's use by
(1) generating at least one SCD/SVD pair, and
(2) personalizing for the signatory by storing in the TOE:
(a) the signatory’s reference authentication data (RAD)
(b) optionally, certificate info for at least one SCD in the TOE.
After preparation, the SCD shall be in a non-operational state. Upon receiving a TOE, the signatory shall
verify its non-operational state and change the SCD state to operational.
After preparation the intended, legitimate user should be informed of the signatory’s verification
authentication data (VAD) required for use of the TOE in signing. If the VAD is a password or PIN,
providing this information shall protect the confidentiality of the corresponding RAD. There is a special
VAD, which can be used only once in the TOE lifetime, the Signature Transport PIN, which has to be
changed to Signature PIN in order to create digital signatures.
If the use of an SCD is no longer required, then it can be destroyed (e.g. overwritten) as well as the
associated certificate info, if any exists
1.4.5. TOE life cycle
1.4.5.1. General
The TOE lifecycle distinguishes stages for development production, preparation and operational use.
1. Application note (from ST Author)
The IDentity Applet Life cycle has the following phases, which differ from the whole TOE Lifecycle:
IDentity Applet v4.0/QSCD Security Target
Page 16 of 73
• IDentity Applet
LOADED (Creation phase)
• IDentity Instance
Personalization Phase
SELECTABLE (Configuration Phase)
CONFIGURED (Initialization Phase)
Operational Phase
PERSONALIZED
LOCKED
BLOCKED
These phases are detailed in the ID&Trust Identity Applet Suite Administrator’s Guide [5]. These states
and phases are presented here, because of informational reasons, to serve better understanding.
The development phase comprises the development and production of the TOE. The development
phase is subject of the evaluation according to the assurance lifecycle (ALC) class. The development
phase ends with the delivery of the TOE to the QSCD-provisioning service.
2. Application note (from ST Author)
The delivery procedures between ID&Trust (applet developer) and the manufacturer:
1. The IDentity Applet Developer develops a new version of the IDentity Applet v4.0/QSCD.
2. After the new version is tested a new release is issued and stored in configuration
management system.
3. The new version of the IDentity Applet v4.0 is sent to as required by [28].
The operational usage of the TOE comprises the preparation stage and the operational use stage. The
TOE operational use stage begins when the signatory has obtained both the VAD and the TOE. Enabling
the TOE for signing requires at least one set of SCD stored in its memory.
The lifecycle may allow generation of SCD or SCD/SVD key pairs after delivery to the signatory as well,
depending on the application profile.
1.4.5.2. Preparation stage
An QSCD-provisioning service provider having accepted it from a manufacturer prepares the TOE for
use and delivers it to its legitimate user. The preparation phase ends when the legitimate user of the
TOE, having received it from an QSCD provisioning service enables if an SCD it holds for use in signing.
During preparation of the TOE, as specified above, an QSCD-provisioning service provider performs
the following tasks:
(1) Obtain information on the intended recipient of the device as required for the preparation
process and for identification as a legitimate user of the TOE.
(2) Generate a PIN and/or obtain a biometric sample of the legitimate user, store this data as
RAD in the TOE and prepare information about the VAD for delivery to the legitimate user.
(3) The TOE generating an SCD/SVD pair.
(4) Generate a certificate for at least one SCD as follows:
a. Initializes the security functions in the TOE for the identification as QSCD, for the
proof of this QSCD identity to external entities, and for the protected export of the
SVD.
b. Links the identity of the TOE as QSCD and the identity of the legitimate user as
potential applicant for certificates for SVD generated by the TOE.
(5) Optionally, present certificate info to the QSCD.
(6) Deliver the TOE and the accompanying VAD info to the legitimate user.
The SVD certification task (third list item above) of an QSCD-provisioning service provider as specified
in this ST may support a centralized, pre-issuing key generation process, with at least one key generated
and certified, before delivery to the legitimate user. Alternatively, or additionally, that task may support
key generation by the signatory after delivery and outside the secure preparation environment. A TOE
IDentity Applet v4.0/QSCD Security Target
Page 17 of 73
may support both key generation processes, for example with a first key generated centrally and
additional keys generated by the signatory in the operational use stage.
Data required for inclusion in the SVD certificate at least includes ([24] Annex I):
(a) the SVD which correspond to SCD under the control of the signatory;
(b) the name of the signatory or a pseudonym, which is to be identified as such;
(c) an indication of the beginning and end of the period of validity of the certificate.
The data included in the certificate may have been stored in the QSCD during personalization.
Before initiating the actual certificate signature, the certificate-generating application verifies the SVD
received from the TOE by:
(1) establishing the sender as genuine QSCD
(2) establishing the integrity of the SVD to be certified as sent by the originating QSCD,
(3) establishing that the originating QSCD has been personalized for the legitimate user,
(4) establishing correspondence between SCD and SVD, and
(5) an assertion that the signing algorithm and key size for the SVD are approved and appropriate
for the type of certificate.
The proof of correspondence between an SCD stored in the TOE and an SVD may be implicit in the
security mechanisms applied by the CGA. Optionally, the TOE may support a function to provide an
explicit proof of correspondence between an SCD it stores and an SVD realized by self-certification.
Such a function may be performed implicitly in the SVD export function and may be invoked in the
preparation environment without explicit consent of the signatory4.
Prior to generating the certificate, the certification service provider shall assert the identity of the
signatory specified in the certification request as the legitimate user of the TOE.
1.4.5.3. Operational use stage
In this lifecycle stage, the signatory can use the TOE to create advanced/qualified electronic signatures.
The TOE operational use stage begins when the signatory has obtained both the VAD and the TOE.
Enabling the TOE for signing requires at least one set of SCD stored in its memory.
The signatory can also interact with the QSCD to perform management tasks, e.g. reset a RAD value,
or use counter if the password/PIN in the reference data has been lost or blocked. Such management
tasks require a secure environment.
The signatory can render an SCD in the TOE permanently unusable. Rendering the last SCD in the
TOE permanently unusable ends the life of the TOE as QSCD.
The TOE may support functions to generate additional signing keys. If the TOE supports these functions,
it shall support further functions to securely obtain certificates for the new keys. For an additional key
the signatory may be allowed to choose the kind of certificate (qualified, or not) to obtain for the SVD of
the new key. The signatory may also be allowed to choose some of the data in the certificate request
for instance to use a pseudonym instead of the legal name in the certificate5. If the conditions to obtain
a qualified certificate are met the new key can also be used to create advanced electronic signatures.
The optional TOE functions for additional key generation and certification may require additional security
functions in the TOE and an interaction with the QSCD-Provisioning service provider in an environment
that is secure.
In the usage phase, SCD/SVD generation by the TOE and SVD export from the TOE may take place in
the preparation stage and/or in the operational use stage. The TOE then provides a trusted channel to
the CGA protecting the integrity of the SVD.
Before generating the certificate including the SVD exported from the TOE, the CGA additionally
establishes:
(1) the identity of the TOE as QSCD,
(2) that the originating QSCD has been personalized for the applicant for the certificate as
legitimate user, and
4 Self-certification of the SVD is effectively computing a digital signature with the corresponding SCD. A signing
operation requires explicit sole signatory control, this specific case, if supported, provides an exception to this rule
as, before being delivered to the signatory, such control is evidently impossible.
5 The certificate request in this case will contain the name of the signatory as the requester, as for instance it may
be signed by the signatory’s existing SCD.
IDentity Applet v4.0/QSCD Security Target
Page 18 of 73
(3) the correspondence between SCD stored in the QSCD and the received SVD.
The TOE life cycle as QSCD ends when all SCD stored in the TOE are destructed. This may include
deletion of the corresponding certificates.
1.4.6. TOE security functions
The following TOE ensured security functions are the most significant for its operational use:
• Only entities possessing authorization can get access to the use of the signature creation data
stored on the TOE and use functionality of card,
• Verifying authenticity and integrity as well as securing confidentiality of data in the
communication channel (trusted channel) between the TOE and the CGA connected,
• Self-protection of the TOE security functionality and the data stored inside.
• The TOE supports Certificate Request Signature (CRS) to provide evidence about the validity
of the SVD for the CGA.
• Post-issuance SCD/SVD key pair generation and certificate generation for R.Admin, if EAC2 is
applied.
• The TOE implement trusted channel for the protection of the DTBS/R
Above mentioned functions are described below informally, and in detail in section 7.1.
The TOE supports numerous certified security mechanism and algorithms to meet the
following SFRs: FTP_ITC.1/SVD, FTP_ITC.1/VAD, FTP_ITC.1/DTBS), meaning it
establishes a trusted channel (secure messaging) either with the CGA or the SCA:
1. Device authentication according to IAS-ECC [23] – supported symmetric and
asymmetric device authentication,
2. PACE [13], [11], and
3. EAC2 (Chip Authentication) [11].
IDentity Applet v4.0/QSCD Security Target
Page 19 of 73
2. Conformance Claims
2.1. CC Conformance Claim
This Security Target is conforming to
• Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
General Model; CCMB-2017-04-001, Version 3.1, Revision 5, April 2017 [1]
• Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional
Components; CCMB-2017-04-002, Version 3.1, Revision 5, April [2].
• Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Requirements; CCMB-2017-04-003, Version 3.1, Revision 5, April 2017 [3]
As follows
Part 2 extended (see Chapter 5 Extended components definition)
Part 3 conformant.
The
• Common Methodology for Information Technology Security Evaluation, Evaluation
Methodology; CCMB-2017-04-004, Version 3.1, Revision 5, April 2017 [4]
has been taken into account.
2.2. PP Claim, Package Claim
This Security Target claims strict conformance to the following PPs:
Title: Protection profiles for secure signature creation device — Part 2: Device with
key generation
Standard ID: EN 419211-2:2013
CC version: 3.1 (revision 4)
Assurance level: The minimum assurance level for this PP is EAL4 augmented with AVA_VAN.5
Title: Protection profiles for Secure signature creation device — Part 4: Device with
key generation and trusted communication with certificate generation application
Standard ID: EN 419211-4:2013
CC version: 3.1 (revision 4)
Assurance Level: The minimum assurance level for this PP is EAL4 augmented with AVA_VAN.5.
This ST is conforming to assurance package EAL4 augmented with AVA_VAN.5 defined in [3].
Title: Protection profiles for Secure signature creation device — Part 5: Extension
for device with key generation and trusted channel to signature creation application
Standard ID: EN 419211-5:2013
CC version: 3.1 (revision 4)
Assurance Level: The minimum assurance level for this PP is EAL4 augmented with AVA_VAN.5.
This ST is conforming to assurance package EAL5 augmented with ALC_DVS.2 and AVA_VAN.5
defined in [3].
IDentity Applet v4.0/QSCD Security Target
Page 20 of 73
2.3. Conformance rationale
The ST is built on the PPs referenced above, which according to the certifications conform to the CC
version stated above.
This ST is conformant with Common Criteria Part 2 [2] extended due to additional components as stated
in [18], and [19].
This ST is conformant to Common Criteria Part 3 [3].
The current ST refines the Assets, threats, objectives and SFR of [18], [19] and [20].
The Security Target claims strict conformance to three PPs: [18], [19] [20].
The Target of Evaluation (TOE) is Qualified Signature Creation Device (QSCD) for the generation of
signature-creation data (SCD) and the creation of qualified electronic signatures. It fulfils requirements
of [24]. The Security Target refers to the QSCD compliant configurations of the IDentity Applet Suite
v4.0. The IDentity Applet v4.0/QSCD is a Java Card Application used exclusively on the Platform, which
is a CC EAL6+ certified product.
The TOE is thus consistent with the TOE type in the PP.
3. Application note (from ST author)
The [18], [19] and [20] reference to Directive 1999/93/EC of the European Parliament and of the Council
of 13 December 1999 on a Community framework for electronic signatures, but it was repealed.
Legislation in force [24] do not influence the security aspects of the current ST.
The new regulation does not know the Secure Signature Creation Device (SSCD), but it introduced the
Qualified Signature Creation Device (QSCD) concept. For the aspect of security and the current ST it
means only changing in the name, so in the current ST the QSCD is used instead of SSCD, but it does
not affect the strict conformance to [18], [19] and [20].
The security problem definition of this security target is consistent with the statement of the security
problem definition in the PPs, as the security target claims strict conformance to the PPs and no other
threats.
The security objectives of the TOE of this security target are consistent with the statement of the
security objectives in the PPs as the security target claims strict conformance to the PPs.
The security objectives for the operational environment in this security target include all security
objectives for the operational environment from the PPs.
The security objectives do not affect the strict conformance.
The security requirements of this security target are consistent with the statement of the security
requirements in the PPs as the security target claims strict conformance to the PP. All assignments and
selections of the security functional requirements are defined in the PP section 9.1 and in this security
target section 6.1.
2.4. Statement of compatibility
2.4.1. Security Functionalities
The following table contains the security functionalities of the [7] and of this ST, showing which
Functionality correspond to the Platform-ST and which has no correspondence. This statement is
compliant to the requirements of [8].
A classification of TSFs of the [7] has been made. Each TSF has been classified as ‘relevant’ or ‘not
relevant’ for this ST.
Platform Security
Functionality
Corresponding
TOE Security Functionality
Relevant/N
ot relevant
Remarks
SF.JCVM TSF.Platform
TSF.AppletparameterSign
Relevant Java Card Virtual
Machine
IDentity Applet v4.0/QSCD Security Target
Page 21 of 73
Platform Security
Functionality
Corresponding
TOE Security Functionality
Relevant/N
ot relevant
Remarks
SF.CONFIG - Not relevant Configuration
Management
SF.OPEN TSF.Platform Relevant Card Content
Management
SF.CRYPTO TSF.Authenticate
TSF.CryptoKey
TSF.AppletparameterSign
TSF.Platform
Relevant Cryptographic
Functionality
SF.RNG TSF.Authenticate
TSF.CryptoKey
TSF.TrustedChannel
TSF.Platform
Relevant Random Number
Generator
SF.DATA_STORAGE TSF.AccessControl
TSF.Authenticate
TSF.CryptoKey
TSF.AppletparameterSign
TSF.Platform
Relevant Secure Data
Storage
SF.PUF - Not relevant User Data
Protection using
PUF
SF.OM TSF.AppletparameterSign
TSF.Platform
Relevant Java Object
Management
SF.MM - Not relevant Memory
Management
SF.PIN TSF.AccessControl
TSF.Authenticate
TSF.CryptoKey
TSF.AppletparameterSign
TSF.Platform
Relevant PIN Management
SF.BIO - Not relevant Biometric
Template
Management
SF.PERS_MEM TSF.AppletparameterSign
TSF.Platform
Relevant Persistent
Memory
Management
SF.EDC TSF.AppletparameterSign
TSF.Platform
Relevant Error Detection
Code API
SF.HW_EXC TSF.Platform Relevant Hardware
Exception
Handling
SF.PID - Not relevant Platform
Identification
SF.SMG_NSC TSF.Platform Relevant No Side-Channel
SF.ACC_SBX - Not relevant Secure Box
SF.MOD_INVOC - Not relevant Module Invocation
SF.SENS_RES - Not relevant Sensitive Result
SF.OSU - Not relevant OS Update
SF.MOD_DEL - Not relevant Module Deletion
2. Table Classification of Platform-TSFs
All the above Platform-TSFs which are indicated as relevant are relevant for this ST.
4. Application note (by the ST author)
The TSF.Platform Security functionality in the above list represents functionalities which are not directly
used in the IDentity Applet v4.0/QSCD, they are implicitly invoked by calls to the Platform, respectively
the JCOP operating system. These functions are called altogether as TSF.Platform.
2.4.2. OSPs
None of the OSPs of this ST are applicable to the Platform and therefore not mappable for the Platform-
ST.
IDentity Applet v4.0/QSCD Security Target
Page 22 of 73
The OSPs from the Platform-ST [7] are not deal with any additional security components.
2.4.3. Security objectives
These Platform-ST objectives can be mapped to this STs objectives as shown in the following table, so
they are relevant.
Objective from the Platform-ST Objective from this ST
OT.ALARM OT.SCD_Secrecy
OT.Tamper_Resistance
OT.CIPHER OT.Lifecycle_Security
OT.SCD_Unique
OT.SCD_SVD_Corresp
OT.SCD_Secrecy
OT.COMM_AUTH OT.Lifecycle_Security
OT.Sig_Secure
OT.TOE_QSCD_Auth
OT.COMM_CONFIDENTIALITY OT.Lifecycle_Security
OT.Sig_Secure
OT.TOE_QSCD_Auth
OT.TOE_TC_SVD_Exp
OT.TOE_TC_VAD_Imp
OT.TOE_TC_DTBS_Imp
OT.COMM_INTEGRITY OT.Lifecycle_Security
OT.Sig_Secure
OT.TOE_QSCD_Auth
OT.TOE_TC_SVD_Exp
OT.TOE_TC_VAD_Imp
OT.TOE_TC_DTBS_Imp
OT.GLOBAL_ARRAYS_CONFID OT.SCD_Secrecy
OT.Sigy_SigF
OT.KEY-MNGT OT.Lifecycle_Security
OT.SCD_Unique
OT.SCD_SVD_Corresp
OT.SCD_Secrecy
OT.Sig_Secure
OT.TOE_QSCD_Auth
OT.TOE_TC_SVD_Exp
OT.TOE_TC_VAD_Imp
OT.TOE_TC_DTBS_Imp
OT.Sigy_SigF
OT.OPERATE OT.SCD_Secrecy
OT.Tamper_Resistance
OT.Sigy_SigF
OT.PIN-MNGT OT.SCD_SVD_Corresp
OT.SCD_Secrecy
OT.Sig_Secure
OT.Sigy_SigF
OT.DTBS_Integrity_TOE
OT.Lifecycle_Security
OT.SCD_Secrecy
OT.Sig_Secure
OT.REALLOCATION OT.SCD_Secrecy
OT.Sigy_SigF
OT.RESOURCES OT.SCD_Secrecy
OT.Tamper_Resistance
OT.RND OT.TOE_QSCD_Auth
OT.SCP.IC OT.SCD_Secrecy
OT.Tamper_Resistance
OT.EMSEC_Design
OT.Tamper_ID
OT.SCP.RECOVERY OT.SCD_Secrecy
IDentity Applet v4.0/QSCD Security Target
Page 23 of 73
Objective from the Platform-ST Objective from this ST
OT.Tamper_Resistance
OT.SCP.SUPPORT OT.Lifecycle_Security
OT.SCD_Unique
OT.SCD_SVD_Corresp
OT.SCD_Secrecy
OT.Sig_Secure
OT.TOE_QSCD_Auth
OT.TOE_TC_SVD_Exp
OT.TOE_TC_VAD_Imp
OT.TOE_TC_DTBS_Imp
OT.SID_MODULE OT.SCD_Secrecy
OT.TRANSACTION OT.SCD_Secrecy
OT.Sigy_SigF
3. Table Mapping of security objectives for the TOE
The following Platform-ST objectives are not relevant for or cannot be mapped to the TOE of this ST:
• OT.APPLI-AUTH
• OT.AUTH-LOAD-UPDATE-IMAGE
• OT.BIO-MNGT
• OT.CARD-CONFIGURATION
• OT.CARD-MANAGEMENT
• OT.CONFID-UPDATE-IMAGE.LOAD
• OT.DOMAIN-RIGHTS
• OT.FIREWALL
• OT.GLOBAL_ARRAYS_INTEG
• OT.TOE_IDENTIFICATION
• OT.NATIVE
• OT.OBJ-DELETION
• OT.SEC_BOX_FW
• OT.SECURE_ACTIVATION_ADDITIONAL_CODE
• OT.SECURE_LOAD_ACODE
• OT.SENSITIVE_RESULTS_INTEG
• OT.SID
• OT.TOE_IDENTIFICATION
cannot be mapped because these are out of scope.
The objectives for the operational environment can be mapped as follows:
Security Objectives for
the environment of the
[7]
Classification of OE Comments
OE.APPLET CfPOE Covered by ALC class
OE.APPS-PROVIDER CfPOE Covered by ALC class
OE.CODE-EVIDENCE CfPOE Covered by ALC class
OE.CONFID-UPDATE-
IMAGE.CREATE
CfPOE Covered by ALC class
OE.KEY-CHANGE CfPOE Covered by ALC class
OE.PROCESS_SEC_IC CfPOE Covered by the Platform’s certification and
ALC class
OE.SECURITY-
DOMAINS
CfPOE Covered by ALC class
OE.USE_DIAG SgOE OE.Dev_Prov_Service
OE.USE_KEYS SgOE OE.HID_TC_VAD_Exp
OE.VERIFICATION CfPOE Covered by ALC class
OE.VERIFICATION-
AUTHORITY
CfPOE Covered by ALC class
IDentity Applet v4.0/QSCD Security Target
Page 24 of 73
Table 4 Mapping of security objectives of the environment
There is no conflict between security objectives of this ST and the Platform-ST.
2.4.4. Security requirements
The Security Requirements of the Platform-ST can be mapped as follows:
Platform SFR Corresponding
TOE SFR
Category of Platform’s SFR Remarks
FAU_ARP.1 FPT_PHP.3 RP_SFR-MECH FAU_ARP.1 facilitate to
protect the TOE as
required by FPT_PHP.3
FAU_SAS.1[SCP] - IP_SFR -
FCO_NRO.2[SC] - IP_SFR -
FCS_CKM.1 FCS_CKM.1 RP_SFR-SERV FCS.CKM.1 of the
Platform is applied to
generate SVD/SVD
keypair.
FCS_CKM.2 - IP_SFR -
FCS_CKM.3 - IP_SFR -
FCS_CKM.4 FCS_CKM.4 RP_SFR-SERV FCS.CKM.4. of the
Platform is applied to
destroy SCD.
FCS_COP.1 FCS_COP.1 RP_SFR-SERV FCS_COP.1.1[ECSignatu
re] is applied to generate
digital signature (EC)
FCS_COP.1.1[RSASignat
urePKCS1] is applied to
generate signature (RSA).
FCS_COP.1.1[SHA] is
applied, if the last part of
the hash calculation is
executed on the TOE.
FDP_DAU.2/SVD RP_SFR-SERV FCS_COP.1.1[RSASignat
urePKCS1] are applied
(depends on the selected
algorithm) for
FDP_DAU.2/SVD
FIA_API.1 RP_SFR-SERV In case active
authentication the
FCS_COP.1.1[ECSignatu
re] and
FCS_COP.1.1[RSASignat
urePKCS1] could be
applied.
FDP_UIT.1/DTBS RP_SFR-SERV FCS_COP1.1[DESMAC]
or
FCS_COP1.1[AESMAC]
is applied during PACE
secure messaging the
verify the message
authentication codes.
FCS_RNG.1 FIA_API.1 RP_SFR-SERV In case Symmetric
Authentication method to
generate secure random
the FCS_RNG.1 is
applied.
FTP_ITC.1/SVD RP_SFR-SERV In case Symmetric
Authentication method to
generate secure random
IDentity Applet v4.0/QSCD Security Target
Page 25 of 73
Platform SFR Corresponding
TOE SFR
Category of Platform’s SFR Remarks
the FCS_RNG.1 is
applied to provide trusted
channel.
FTP_ITC.1/VAD RP_SFR-SERV In case the trusted
channel establishment to
generate secure random.
FTP_ITC.1/DTBS RP_SFR-SERV In case the trusted
channel establishment to
generate secure random.
FDP_UIT.1/DTBS RP_SFR-SERV FCS_COP1.1[DESMAC]
or
FCS_COP1.1[AESMAC]
is applied during secure
messaging to protect the
confidentiality of
transmitted and received
user data.
FCS_RNG.1[HDT] - IP_SFR -
FDP_ACF.1[SD] - IP_SFR
FDP_ACC.1[SD] - IP_SFR -
FDP_ACF.1[FIREW
ALL]
- IP_SFR -
FDP_ACC.2[FIREW
ALL]
- IP_SFR -
FDP_ACC.2[ADEL] - IP_SFR -
FDP_ACC.2[Secure
Box]
- IP_SFR -
FDP_ACF.1[ADEL] - IP_SFR -
FDP_ACF.1[Secure
Box]
- IP_SFR -
FDP_IFC.1[JCVM] - IP_SFR -
FDP_IFC.2[SC] - IP_SFR -
FDP_IFC.2[CFG] - IP_SFR -
FDP_IFC.1[MODUL
AR-DESIGN]
- IP_SFR -
FDP_IFF.1[JCVM] - IP_SFR -
FDP_IFF.1[SC] - IP_SFR -
FDP_IFF.1[CFG] - IP_SFR -
FDP_IFF.1[MODUL
AR-DESIGN]
- IP_SFR -
FDP_ITC.2[CCM] - IP_SFR -
FDP_RIP.1[OBJEC
TS]
- IP_SFR -
FDP_RIP.1[ABORT
]
- IP_SFR -
FDP_RIP.1[APDU] - IP_SFR -
FDP_RIP.1[bArray] - IP_SFR -
FDP_RIP.1[GlobalA
rray_Refined]
- IP_SFR -
FDP_RIP.1[KEYS] FDP_RIP.1 RP_SFR-MECH FDP_RIP.1[KEYS] is
applied to destroy the
SCD in the transient
memory.
FDP_RIP.1[TRANSI
ENT]
- IP_SFR -
FDP_RIP.1[ADEL] - IP_SFR -
IDentity Applet v4.0/QSCD Security Target
Page 26 of 73
Platform SFR Corresponding
TOE SFR
Category of Platform’s SFR Remarks
FDP_RIP.1[ODEL] - IP_SFR -
FDP_ROL.1[FIREW
ALL]
- IP_SFR -
FDP_ROL.1[CCM] - IP_SFR -
FDP_SDI.2[DATA] FDP_SDI.2/Persis
tent
RP_SFR-MECH FDP_SDI.2[DATA] is
applied to protect SCD
against integrity errors.
FDP_SDI.2[SENSIT
IVE_RESULT]
FDP_SDI.2/DTBS RP_SFR-MECH FDP_SDI.2[DATA] is
applied to protect DTBS
against integrity errors.
FPT_TST.1 RP_SFR-MECH FDP_SDI.2[DATA] checks
the integrity of RAD.
- IP_SFR -
FDP_UIT.1[CCM] - IP_SFR -
FIA_AFL.1[BIO] - IP_SFR -
FIA_AFL.1[PIN] FIA_AFL.1 RP_SFR-SERV FIA_AFL.1[PIN] is applied
to protect the PIN code
against authentication
errors.
FIA_ATD.1[AID] - IP_SFR -
FIA_ATD.1[MODUL
AR-DESIGN]
- IP_SFR -
FIA_UID.1[SC] - IP_SFR -
FIA_UID.1[CFG] - IP_SFR -
FIA_UID.2[AID] - IP_SFR -
FIA_UID.1[MODUL
AR-DESIGN]
- IP_SFR -
FIA_USB.1[AID] - IP_SFR -
FIA_USB.1[MODUL
AR-DESIGN]
- IP_SFR -
FIA_UAU.1[SC] - IP_SFR -
FIA_UAU.4[SC] - IP_SFR -
FMT_MSA.1[JCRE] - IP_SFR -
FMT_MSA.1[JCVM] - IP_SFR -
FMT_MSA.1[ADEL] - IP_SFR -
FMT_MSA.1[SC] - IP_SFR -
FMT_MSA.1[Secur
eBox]
- IP_SFR -
FMT_MSA.1[CFG] - IP_SFR -
FMT_MSA.1[SD] - IP_SFR -
FMT_MSA.1[MODU
LAR-DESIGN]
- IP_SFR -
FMT_MSA.2[FIREW
ALL-JCVM]
- IP_SFR -
FMT_MSA.3[FIREW
ALL]
- IP_SFR -
FMT_MSA.3[JCVM] - IP_SFR -
FMT_MSA.3[ADEL] - IP_SFR -
FMT_MSA.3[Secur
eBox]
- IP_SFR -
FMT_MSA.3[CFG] - IP_SFR -
FMT_MSA.3[SD] - IP_SFR -
FMT_MSA.3[SC] - IP_SFR -
FMT_MSA.3[MODU
LAR-DESIGN]
- IP_SFR -
IDentity Applet v4.0/QSCD Security Target
Page 27 of 73
Platform SFR Corresponding
TOE SFR
Category of Platform’s SFR Remarks
FMT_MTD.1[JCRE] - IP_SFR -
FMT_MTD.3[JCRE] - IP_SFR -
FMT_SMF.1 - IP_SFR -
FMT_SMF.1[ADEL] - IP_SFR -
FMT_SMF.1[Secure
Box]
- IP_SFR -
FMT_SMF.1[CFG] - IP_SFR -
FMT_SMF.1[SD] - IP_SFR -
FMT_SMF.1[SC] - IP_SFR -
FMT_SMF.1[MODU
LAR-DESIGN]
- IP_SFR -
FMT_SMR.1 - IP_SFR -
FMT_SMR.1[INSTA
LLER]
- IP_SFR -
FMT_SMR.1[ADEL] - IP_SFR -
FMT_SMR.1[CFG] - IP_SFR -
FMT_SMR.1[SD] - IP_SFR -
FMT_SMR.1[MODU
LAR-DESIGN]
- IP_SFR -
FPR_UNO.1 - IP_SFR -
FPT_EMSEC.1 FPT_EMS.1 RP_SFR-MECH FPT_EMS.1 matches the
FPT_EMSEC.1 of the
Platform.
FPT_FLS.1 FPT_FLS.1 RP_SFR-MECH FPT_FLS.1 of the
Platform ensures the
secure state of the TOE
as required by FPT_FLS.1
FPT_FLS.1[INSTAL
LER]
- IP_SFR -
FPT_FLS.1[ADEL] - IP_SFR -
FPT_FLS.1[ODEL] - IP_SFR -
FPT_FLS.1[CCM] - IP_SFR -
FPT_FLS.1[MODUL
AR-DESIGN]
- IP_SFR -
FPT_TDC.1 - IP_SFR -
FPT_RCV.3[INSTA
LLER]
- IP_SFR -
FPT_PHP.3 FPT_PHP.1 RP_SFR-MECH FPT_PHP.3 of the
Platform covers the
requirement of
FPT_PHP.3
FTP_ITC.1[SC] FPT_PHP.3 RP_SFR-MECH FPT_PHP.3 matches the
FPT_PHP.3 of the
Platform.
- IP_SFR -
ADV_SPM.1 - IP_SFR -
FDP_IFC.2[OSU] - IP_SFR -
FDP_IFC.2[OSU] - IP_SFR -
FDP_IFC.2[OSU] - IP_SFR -
FDP_IFF.1[OSU] - IP_SFR -
FIA_UAU.1[OSU] - IP_SFR -
IDentity Applet v4.0/QSCD Security Target
Page 28 of 73
Platform SFR Corresponding
TOE SFR
Category of Platform’s SFR Remarks
FIA_UAU.4[OSU] - IP_SFR -
FIA_UID.1[OSU] - IP_SFR -
FMT_MSA.1[OSU] - IP_SFR -
FMT_MSA.1[OSU] - IP_SFR -
FMT_MSA.3[OSU] - IP_SFR -
FMT_MSA.3[OSU] - IP_SFR -
FMT_SMF.1[OSU] - IP_SFR -
FMT_SMF.1[OSU] - IP_SFR -
FMT_SMR.1[OSU] - IP_SFR -
FMT_SMR.1[OSU] - IP_SFR -
FMT_SMR.1[OSU] - IP_SFR -
FPT_FLS.1[OSU] - IP_SFR -
FDP_ACC.2[MDEL] - IP_SFR -
FDP_ACF.1[MDEL] - IP_SFR -
FDP_RIP.1[MDEL] - IP_SFR -
FMT_MSA.1[MDEL] - IP_SFR -
FMT_MSA.3[MDEL] - IP_SFR -
FMT_SMF.1[MDEL] - IP_SFR -
FMT_SMR.1[MDEL] - IP_SFR -
FPT_FLS.1[MDEL] - IP_SFR -
5. Table Mapping of Security requirements
2.5. Assurance requirements
This ST requires EAL 5 according to Common Criteria V3.1 R5 augmented by ALC_DVS.2 and
AVA_VAN.5.
The Platform-ST [7] requires EAL 6 according to Common Criteria V3.1 R5 augmented by: ASE_TSS.2
and ALC_FLR.1.
As EAL 6 covers all assurance requirements of EAL 5 augmented with AVA_VAN.5 and ALC_DVS.2 of
this ST will match to the Platform-ST [7] assurance requirements.
2.6. Analysis
Overall, there is no conflict between security requirements of this ST and the Platform-ST [7].
IDentity Applet v4.0/QSCD Security Target
Page 29 of 73
3. Security Problem Definition
3.1. Assets, users and threat agents
The Common Criteria define assets as entities that the owner of the TOE presumably places value upon.
The term “asset” is used to describe the threats in the operational environment of the TOE.
3.1.1. Assets and objects
SCD
Signature Creation Data
Private key used to perform an electronic signature operation. The confidentiality, integrity and
signatory’s sole control over the use of the SCD must be maintained.
SVD
Signature Verification Data
Public key linked to the SCD and used to perform digital signature verification. The integrity of the SVD
when it is exported must be maintained.
DTBS and DTBS/R
Data to be Sign
Set of data, or its representation, which the signatory intends to sign. Their integrity and the
unforgeability of the link to the signatory provided by the digital signature must be maintained.
3.1.2. User and subjects acting for users
User
End user of the TOE who can be identified as Administrator or Signatory. The subject S.User may act
as S.Admin in the role R.Admin or as S.Sigy in the role R.Sigy
Signatory
User who hold the TOE and use it on his own behalf or on behalf of the natural or legal person or entity
they represent. The subject S.Sigy is acting in the role R.Sigy for this user after successful authentication
as signatory.
Administrator
User who is in charge to perform the TOE initialization, TOE personalization or other TOE administrative
functions. The subject S.Admin is acting in the role R.Admin for this user after successful authentication
as administrator.
3.1.3. Threat agents
Attacker
Human or process acting on their behalf located outside the TOE. The main goal of the attacker is to
access the SCD or to falsify the electronic signature. The attacker has got a high attack potential and
knows no secret.
3.2. Threats
T.SCD_Divulg
Storing, copying, and releasing of the signature creation data
An attacker stores or copies the SCD outside the TOE. An attacker can obtain the SCD during
generation, storage and use for signature creation in the TOE.
IDentity Applet v4.0/QSCD Security Target
Page 30 of 73
T.SCD_Derive
Derive the signature creation data
An attacker derives the SCD from publicly known data, such as SVD corresponding to the SCD or
signatures created by means of the SCD or any other data exported outside the TOE, which is a threat
against the secrecy of the SCD.
T.Hack_Phys
Physical attacks through the TOE interfaces
An attacker interacts physically with the TOE to exploit vulnerabilities, resulting in arbitrary security
compromises. This threat is directed against SCD, SVD and DTBS.
T.SVD_Forgery
Forgery of the signature verification data
An attacker forges the SVD presented by the CSP to the CGA. This results in loss of SVD integrity in
the certificate of the signatory.
T.SigF_Misuse
Misuse of the signature creation function of the TOE
An attacker misuses the signature creation function of the TOE to create SDO for data the signatory has
not decided to sign. The TOE is subject to deliberate attacks by experts possessing a high attack
potential with advanced knowledge of security principles and concepts employed by the TOE.
T.DTBS_Forgery
Forgery of the DTBS/R
An attacker modifies the DTBS/R sent by the SCA. Thus the DTBS/R used by the TOE for signing does
not match the DTBS the signatory intended to sign.
T.Sig_Forgery
Forgery of the electronic signature
An attacker forges a signed data object, maybe using an electronic signature which has been created
by the TOE, and the violation of the integrity of the signed data object is not detectable by the signatory
or by third parties. The signature created by the TOE is subject to deliberate attacks by experts
possessing a high attack potential with advanced knowledge of security principles and concepts
employed by the TOE.
3.3. Organizational Security Policies
P.CSP_QCert
Qualified certificate
The CSP uses a trustworthy CGA to generate a qualified certificate or non-qualified certificate (cf. the
[24], article 3, clause 14, and Annex I) for the SVD generated by the QSCD. The certificates contain at
least the name of the signatory and the SVD matching the SCD implemented in the TOE under sole
control of the signatory. The CSP ensures that the use of the TOE as QSCD is evident with signatures
through the certificate or other publicly available information.
P.QSign
Qualified electronic signatures
The signatory uses a signature creation system to sign data with an advanced electronic signature (cf.
the [24], article 3, clause 15), which is a qualified electronic signature if it is based on a valid qualified
certificate (according to the [24] Annex I)6. The DTBS are presented to the signatory and sent by the
SCA as DTBS/R to the QSCD. The QSCD creates the electronic signature created with a SCD
6 It is a non-qualified advanced electronic signature if it is based on a non-qualified certificate for the SVD.
IDentity Applet v4.0/QSCD Security Target
Page 31 of 73
implemented in the QSCD that the signatory maintains under his sole control and is linked to the DTBS/R
in such a manner that any subsequent change of the data is detectable.
P.Sigy_QSCD
TOE as Qualified signature creation device
The TOE meets the requirements for an QSCD laid down in Annex II of the [24]. This implies the SCD
is used for digital signature creation under sole control of the signatory and the SCD can practically
occur only once.
P.Sig_Non-Repud
Non-repudiation of signatures
The life cycle of the QSCD, the SCD and the SVD shall be implemented in a way that the signatory is
not able to deny having signed data if the signature is successfully verified with the SVD contained in
their unrevoked certificate.
3.4. Assumptions
A.CGA
Trustworthy certification generation application
The CGA protects the authenticity of the signatory’s name or pseudonym and the SVD in the (qualified)
certificate by an advanced electronic signature of the CSP.
A.SCA
Trustworthy signature creation application
The signatory uses only a trustworthy SCA. The SCA generates and sends the DTBS/R of the data the
signatory wishes to sign in a form appropriate for signing by the TOE.
IDentity Applet v4.0/QSCD Security Target
Page 32 of 73
4. Security Objectives
4.1. Security Objectives for the TOE
OT.Lifecycle_Security
Lifecycle security
The TOE shall detect flaws during the initialization, personalization and operational usage. The TOE
shall securely destroy the SCD on demand of the signatory
5. Application note (taken from application note 1 from [18]):
The TOE may contain more than one set of SCD. There is no need to destroy the SCD in case of
repeated SCD generation. The signatory shall be able to destroy the SCD stored in the QSCD e.g. after
the (qualified) certificate for the corresponding SVD has been expired.
OT.SCD/SVD_Auth_Gen
Authorized SCD/SVD generation
The TOE shall provide security features to ensure that authorized users only may invoke the generation
of the SCD and the SVD.
OT.SCD_Unique
Uniqueness of the signature creation data
The TOE shall ensure the cryptographic quality of an SCD/SVD pair it creates as suitable for the
advanced or qualified electronic signature. The SCD used for signature creation shall practically occur
only once and shall not be reconstructable from the SVD. In that context ‘practically occur once’ means
that the probability of equal SCDs is negligible.
OT.SCD_SVD_Corresp
Correspondence between SVD and SCD
The TOE shall ensure the correspondence between the SVD and the SCD generated by the TOE. This
includes unambiguous reference of a created SVD/SCD pair for export of the SVD and in creating an
electronic signature creation with the SCD.
OT.SCD_Secrecy
Secrecy of the signature creation data
The secrecy of an SCD (used for signature creation) shall be reasonably assured against attacks with
a high attack potential.
6. Application note (taken from application note 2 from [18])
The TOE shall keep the confidentiality of the SCD at all times, in particular during SCD/SVD generation,
signature creation operation, storage and by destruction.
OT.Sig_Secure
Cryptographic security of the electronic signature
The TOE shall create digital signatures that cannot be forged without knowledge of the SCD through
robust encryption techniques. The SCD shall not be reconstructable using the digital signatures or any
other data exportable from the TOE. The digital signatures shall be resistant against these attacks, even
when executed with a high attack potential.
OT.Sigy_SigF
Signature creation function for the legitimate signatory only
The TOE shall provide the digital signature creation function for the legitimate signatory only and
protects the SCD against the use of others. The TOE shall resist attacks with high attack potential.
IDentity Applet v4.0/QSCD Security Target
Page 33 of 73
OT.DTBS_Integrity_TOE
DTBS/R integrity inside the TOE
The TOE must not alter the DTBS/R. As by definition of the DTBS/R this may consist of the DTBS
themselves, this objective does not conflict with a signature creation process where the TOE hashes
the provided DTBS (in part or entirely) for signature creation.
OT.EMSEC_Design
Provide physical-emanation security
The TOE shall be designed and built in such a way as to control the production of intelligible emanations
within specified limits.
OT.Tamper_ID
Tamper detection
The TOE shall provide system features that detect physical tampering of its components, and uses
those features to limit security breaches
OT.Tamper_Resistance
Tamper resistance
The TOE shall prevent or resist physical tampering with specified system devices and components.
OT.TOE_QSCD_Auth
Authentication proof as QSCD
The TOE shall hold unique identity and authentication data as QSCD and provide security mechanisms
to identify and to authenticate itself as QSCD.
OT.TOE_TC_SVD_Exp
TOE Trusted channel for SVD expor
The TOE shall provide a trusted channel to the CGA to protect the integrity of the SVD exported to the
CGA. The TOE shall enable the CGA to detect alteration of the SVD exported by the TOE.
OT.TOE_TC_VAD_Imp
Trusted channel of TOE for VAD import
The TOE shall provide a trusted channel for the protection of the confidentiality and integrity of the VAD
received from the HID as needed by the authentication method employed.
7. Application note (taken from application note 1 from [20])
This security objective for the TOE is partly covering OE.HID_VAD from the [18]. While OE.HID_VAD
in the [18] requires only the operational environment to protect VAD, this ST requires the HID and the
TOE to implement a trusted channel for the protection of the VAD: the HID exports the VAD and
establishes one end of the trusted channel according to OE.HID_TC_VAD_Exp, the TOE imports VAD
at the other end of the trusted channel according to OT.TOE_TC_VAD_Imp. Therefore [18] re-assigns
partly the VAD protection from the operational environment as described by OE.HID_VAD to the TOE
as described by OT.TOE_TC_VAD_Imp and leaves only the necessary functionality by the HID.
OT.TOE_TC_DTBS_Imp
Trusted channel of TOE for DTBS import
The TOE shall provide a trusted channel to the SCA to detect alteration of the DTBS/R received from
the SCA. The TOE must not generate electronic signatures with the SCD for altered DTBS.
8. Application note (taken from application note 2 from [20])
This security objective for the TOE is partly covering OE.DTBS_Protect from [18]. While
OE.DTBS_Protect in [18] requires only the operational environment to protect DTBS, this ST requires
the SCA and the TOE to implement a trusted channel for the protection of the DTBS: the SCA exports
the DTBS and establishes one end of the trusted channel according to OE.SCA_TC_DTBS_Exp, the
TOE imports DTBS at the other end of the trusted channel according to OT.TOE_TC_DTBS_Imp.
IDentity Applet v4.0/QSCD Security Target
Page 34 of 73
Therefore [18] re-assigns partly the DTBS protection from the operational environment as described by
OE.DTBS_Protect to the TOE as described by OT.TOE_TC_DTBS_Imp and leaves only the necessary
functionality by the SCA.
4.2. Security Objectives for the Operational Environment
OE.SVD_Auth
Authenticity of the SVD
The operational environment shall ensure the integrity of the SVD sent to the CGA of the CSP. The CGA
verifies the correspondence between the SCD in the QSCD of the signatory and the SVD in the qualified
certificate.
OE.CGA_Qcert
Generation of qualified certificates
The CGA shall generate a qualified certificate that includes (amongst others)
(a) the name of the signatory controlling the TOE,
(b) the SVD matching the SCD stored in the TOE and being under sole control of the signatory,
(c) the advanced signature of the CSP.
The CGA shall confirm with the generated qualified certificate that the SCD corresponding to
the SVD is stored in a QSCD.
OE.Dev_Prov_Service
Authentic QSCD provided by QSCD-provisioning service
The QSCD Provisioning Service handles authentic devices that implement the TOE, prepares the TOE
for proof as QSCD to external entities, personalises the TOE for the legitimate user as signatory, links
the identity of the TOE as QSCD with the identity of the legitimate user, and delivers the TOE to the
signatory. Note: This objective replaces OE.QSCD_Prov_Service from the [18], which is possible as it
does not imply any additional requirements for the operational environment when compared to
OE.QSCD_Prov_Service (OE.Dev_Prov_Service is a subset of OE.QSCD_Prov_Service).
OE.HID_TC_VAD_Exp
Trusted channel of HID for VAD export
The HID provides the human interface for user authentication. The HID will ensure confidentiality and
integrity of the VAD as needed by the authentication method employed including export to the TOE by
means of a trusted channel.
9. Application note (taken from application note 3 from [20])
This security objective for the TOE is partly covering OE.HID_VAD from the core PP. While
OE.HID_VAD [18] requires only the operational environment to protect VAD, this ST requires the HID
and the TOE to implement a trusted channel for the protection of the VAD:
• the HID exports the VAD and establishes one end of the trusted channel according to
OE.HID_TC_VAD_Exp,
• the TOE imports VAD at the other end of the trusted channel according to
OT.TOE_TC_VAD_Imp.
Therefore this ST re-assigns partly the VAD protection from the operational environment as described
by OE.HID_VAD to the TOE as described by OT.TOE_TC_VAD_Imp and leaves only the necessary
functionality by the HID.
OE.DTBS_Intend
SCA sends data intended to be signed
The signatory shall use a trustworthy SCA that
IDentity Applet v4.0/QSCD Security Target
Page 35 of 73
- generates the DTBS/R of the data that has been presented as DTBS and which the signatory
intends to sign in a form which is appropriate for signing by the TOE,
- sends the DTBS/R to the TOE and enables verification of the integrity of the DTBS/R by the
TOE,
- attaches the signature produced by the TOE to the data or provides it separately.
10. Application note (taken from application note 3 from [18])
The SCA should be able to support advanced electronic signatures. Currently, there exist three formats
defined by ETSI recognized as meeting the requirements needed by advanced electronic signatures:
CAdES, XAdES and PAdES. These three formats mandate to include the hash of the signer's public
key certificate in the data to be signed. In order to support for the mobility of the signer, it is
recommended to store the certificate info on the QSCD for use by SCA and identification of the
corresponding SCD if more than one SCD is stored on the QSCD.
OE.SCA_TC_DTBS_Exp
SCA protects the data intended to be signed
The SCA provides a trusted channel to the TOE for the protection of the integrity of the DTBS to ensure
that the DTBS/R cannot be altered undetected in transit between the SCA and the TOE.
11. Application note (taken from application note 4 from [20])
This security objective for the TOE is partly covering OE.DTBS_Protect from [18]. While
OE.DTBS_Protect in [18] requires only the operational environment to protect DTBS, this ST requires
the SCA and the TOE to implement a trusted channel for the protection of the DTBS: the SCA exports
the DTBS and establishes one end of the trusted channel according to OE.SCA_TC_DTBS_Exp, the
TOE imports DTBS at the other end of the trusted channel according to OT.TOE_TC_DTBS_Imp.
Therefore this ST re-assigns partly the DTBS protection from the operational environment as described
by OE.DTBS_Protect to the TOE as described by OT.TOE_TC_DTBS_Imp and leaves only the
necessary functionality by the SCA.
OE.Signatory
Trusted channel of SCA for DTBS export
The Signatory checks that the SCD stored in the QSCD received from QSCD-provisioning service is in
non-operational state. The signatory shall keep their VAD confidential
OE.CGA_QSCD_Auth
Pre-initialisation of the TOE for QSCD authentication
The CSP shall check by means of the CGA whether the device presented for application of a (qualified)
certificate holds unique identification as QSCD, successfully proved this identity as QSCD to the CGA,
and whether this identity is linked to the legitimate holder of the device as applicant for the certificate.
OE.CGA_TC_SVD_Imp
CGA trusted channel for SVD import
The CGA shall detect alteration of the SVD imported from the TOE with the claimed identity of the
QSCD.
The developer prepares the TOE by pre-initialisation for the delivery to the customer (i.e. the QSCD
provisioning service) in the development phase not addressed by a security objective for the operational
environment. The QSCD Provisioning Service performs initialisation and personalisation as TOE for the
legitimate user (i.e. the Device holder). If the TOE is delivered to the Device holder with SCD the TOE
is a QSCD. This situation is addressed by OE.QSCD_Prov_Service except the additional initialisation
of the TOE for proof as QSCD and trusted channel to the CGA. If the TOE is delivered to the Device
holder without a SCD the TOE will be a QSCD only after generation of the first SCD/SVD pair. Because
this SCD/SVD pair generation is performed by the signatory in the operational use stage the TOE
provides additional security functionality addressed by OT.TOE_QSCD_Auth and
OT.TOE_TC_SVD_Exp. But this security functionality must be initialised by the QSCD Provisioning
Service as described in OE.Dev_Prov_Service. Therefore, this ST substitutes OE.QSCD_Prov_Service
(from [18]) by OE.Dev_Prov_Service allowing generation of the first SCD/SVD pair after delivery of the
TOE to the Device holder and requiring initialisation of security functionality of the TOE. Nevertheless
the additional security functionality must be used by the operational environment as described in
IDentity Applet v4.0/QSCD Security Target
Page 36 of 73
OE.CGA_QSCD_Auth and OE.CGA_TC_SVD_Imp. This approach does not weaken the security
objectives of and requirements to the TOE but enforce more security functionality of the TOE for
additional method of use. Therefore, it does not conflict with the CC conformance claim to the [18].
4.3. Security Objectives Rationale
The following table provides an overview for security objectives coverage.
OT.Lifecycle_Security
OT.SCD/SVD_Auth_Gen
OT.SCD_Unique
OT.SCD_SVD_Corresp
OT.SCD_Secrecy
OT.Sig_Secure
OT.Sigy_SigF
OT.DTBS_Integrity_TOE
OT.EMSEC_Design
OT.Tamper_ID
OT.Tamper_Resistance
OT.TOE_QSCD_Auth
OT.TOE_TC_SVD_Exp
OT.TOE_TC_VAD_Imp
OT.TOE_TC_DTBS_Imp
OE.CGA_Qcert
OE.SVD_Auth
OE.Dev_Prov_Service
OE.HID_TC_VAD_Exp
OE.DTBS_Intend
OE.SCA_TC_DTBS_Exp
OE.Signatory
OE.CGA_QSCD_Auth
OE.CGA_TC_SVD_Imp
T.SCD_Divulg - - - - X - - - - - - - - - - - - - - - - - - -
T.SCD_Derive - X - - - X - - - - - - - - - - - - - - - - - -
T.Hack_Phys - - - - X - - - X X X - - - - - - - - - - - - -
T.SVD_Forgery - - - X - - - - - - - - X - - - X - - - - - - X
T.SigF_Misuse X - - - - - X X - - - - - X X - - - X X X X - -
T.DTBS_Forger
y
- - - - - - - X - - - - - - X - - - - X X - - -
T.Sig_Forgery - - X - - X - - - - - - - - - X - - - - - - - -
P.CSP_QCert X - - X - - - - - - - X - - - X - - - - - - X -
P.QSign - - - - - X X - - - - - - - - X - - - - - - - -
P.Sigy_QSCD X X X - X X X X X - X X X - - - - X - - - - X X
P.Sig_Non-
Repud
X - X X X X X X X X X X X X X X X X X X X X X X
A.CGA - - - - - - - - - - - - - - - X X - - - - - - -
A.SCA - - - - - - - - - - - - - - - - - - - X - - - -
6. Table Mapping of security problem definition to security objectives
4.4. Security Objectives Sufficiency
Countering of threats by security objectives
T.SCD_Divulg (Storing, copying, and releasing of the signature-creation data) addresses the threat
against the legal validity of electronic signature due to storage and copying of SCD outside the TOE, as
expressed in recital (18) of the Directive. This threat is countered by OT.SCD_Secrecy, which assures
the secrecy of the SCD used for signature creation.
T.SCD_Derive (Derive the signature creation data) deals with attacks on the SCD via public known data
produced by the TOE, which are the SVD and the signatures created with the SCD.
OT.SCD/SVD_Auth_Gen counters this threat by implementing cryptographically secure generation of
the SCD/SVD-pair. OT.Sig_Secure ensures cryptographically secure electronic signatures.
T.Hack_Phys (Exploitation of physical vulnerabilities) deals with physical attacks exploiting physical
vulnerabilities of the TOE. OT.SCD_Secrecy preserves the secrecy of the SCD. OT.EMSEC_Design
IDentity Applet v4.0/QSCD Security Target
Page 37 of 73
counters physical attacks through the TOE interfaces and observation of TOE emanations.
OT.Tamper_ID and OT.Tamper_Resistance counter the threat T.Hack_Phys by detecting and by
resisting tampering attacks.
T.SVD_Forgery (Forgery of the signature verification data) deals with the forgery of the SVD exported
by the TOE to the CGA for the generation of the certificate. T.SVD_Forgery is addressed by
OT.SCD_SVD_Corresp, which ensures correspondence between SVD and SCD and unambiguous
reference of the SVD/SCD pair for the SVD export and signature creation with the SCD, and
OE.SVD_Auth that ensures the integrity of the SVD exported by the TOE to the CGA and verification of
the correspondence between the SCD in the QSCD of the signatory and the SVD in the input it provides
to the certificate generation function of the CSP. Additionally T.SVD_Forgery is addressed by
OT.TOE_TC_SVD_Exp, which ensures that the TOE sends the SVD in a verifiable form through a
trusted channel to the CGA, as well as by OE.CGA_TC_SVD_Imp, which provides verification of SVD
authenticity by the CGA.
T.SigF_Misuse (Misuse of the signature creation function of the TOE) addresses the threat of misuse
of the TOE signature creation function to create SDO by others than the signatory to create an electronic
signature on data for which the signatory has not expressed the intent to sign, as required by paragraph
1(c) of Annex III. OT.Lifecycle_Security (Lifecycle security) requires the TOE to detect flaws during the
initialisation, personalisation and operational usage including secure destruction of the SCD, which may
be initiated by the signatory. OT.Sigy_SigF (Signature creation function for the legitimate signatory only)
ensures that the TOE provides the signature creation function for the legitimate signatory only.
OE.DTBS_Intend (Data intended to be signed) ensures that the SCA sends the DTBS/R only for data
the signatory intends to sign. The combination of OT.TOE_TC_DTBS_Imp (Trusted channel of TOE for
DTBS) and OE.SCA_TC_DTBS_Exp (Trusted channel of SCA for DTBS) counters the undetected
manipulation of the DTBS during the transmission form the SCA to the TOE. OT.DTBS_Integrity_TOE
(DTBS/R integrity inside the TOE) prevents the DTBS/R from alteration inside the TOE. If the SCA
provides a human interface for user authentication, OE.HID_TC_VAD_Exp (Trusted channel of HID for
VAD) requires the HID to protect the confidentiality and the integrity of the VAD as needed by the
authentication method employed. The HID and the TOE will protect the VAD by a trusted channel
between HID and TOE according to OE.HID_TC_VAD_Exp (Trusted channel of HID for VAD) and
OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD). OE.Signatory (Security obligation of the
signatory) ensures that the signatory checks that an SCD stored in the QSCD when received from an
QSCD-provisioning service provider is in non-operational state, i.e. the SCD cannot be used before the
signatory becomes control over the QSCD. OE.Signatory (Security obligation of the signatory) ensures
also that the signatory keeps their VAD confidential.
T.DTBS_Forgery (Forgery of the DTBS/R) addresses the threat arising from modifications of the
DTBS/R sent to the TOE for signing which than does not correspond to the DTBS/R corresponding to
the DTBS the signatory intends to sign. The threat T.DTBS_Forgery is addressed by the security
objectives OT.TOE_TC_DTBS_Imp (Trusted channel of TOE for DTBS) and OE.SCA_TC_DTBS_Exp
(Trusted channel of SCA for DTBS), which ensure that the DTBS/R is sent through a trusted channel
and cannot be altered undetected in transit between the SCA and the TOE. The TOE counters internally
this threat by the means of OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE) ensuring the
integrity of the DTBS/R inside the TOE. The TOE IT environment also addresses T.DTBS_Forgery by
the means of OE.DTBS_Intend, which ensures that the trustworthy SCA generates the DTBS/R of the
data that has been presented as DTBS and which the signatory intends to sign in a form appropriate for
signing by the TOE
T.Sig_Forgery (Forgery of the electronic signature) deals with non-detectable forgery of the electronic
signature. OT.Sig_Secure, OT.SCD_Unique and OE.CGA_Qcert address this threat in general.
OT.Sig_Secure (Cryptographic security of the electronic signature) ensures by means of robust
cryptographic techniques that the signed data and the electronic signature are securely linked together.
OT.SCD_Unique ensures that the same SCD cannot be generated more than once and the
corresponding SVD cannot be included in another certificate by chance. OE.CGA_Qcert prevents
forgery of the certificate for the corresponding SVD, which would result in false verification decision
concerning a forged signature.
Enforcement of OSPs by security objectives
P.CSP_QCert (CSP generates qualified certificates) provides that the TOE and the SCA may be
employed to sign data with (qualified) electronic signatures, as defined by the Regulation[24],
paragraph (63). Regulation [24], recital Article 29 refers to QSCDs to ensure the functionality of
IDentity Applet v4.0/QSCD Security Target
Page 38 of 73
advanced signatures. The OE.CGA_Qcert addresses the requirement of qualified (or advanced)
electronic signatures as being based on qualified (or non-qualified) certificates. According to
OT.TOE_QSCD_Auth the copies of the TOE will hold unique identity and authentication data as
QSCD and provide security mechanisms enabling the CGA to identify and to authenticate the TOE as
QSCD to prove this identity as QSCD to the CGA. The OE.CGA_QSCD_Auth ensures that the CSP
checks the proof of the device presented of the applicant that it is a QSCD. The
OT.SCD_SVD_Corresp ensures that the SVD exported by the TOE to the CGA corresponds to the
SCD stored in the TOE and used by the signatory. The OT.Lifecycle_Security ensures that the TOE
detects flaws during the initialisation, personalisation and operational usage.
P.QSign (Qualified electronic signatures) provides that the TOE and the SCA may be employed to sign
data with an advanced electronic signature, which is a qualified electronic signature if based on a valid
qualified certificate. OT.Sigy_SigF ensures signatory’s sole control of the SCD by requiring the TOE to
provide the signature creation function for the legitimate signatory only and to protect the SCD against
the use of others. OT.Sig_Secure ensures that the TOE creates electronic signatures, which cannot be
forged without knowledge of the SCD through robust encryption techniques. OE.CGA_Qcert addresses
the requirement of qualified or non-qualified electronic certificates building a base for the electronic
signature. OE.DTBS_Intend ensures that the SCA provides only those DTBS to the TOE, which the
signatory intends to sign.
P.Sigy_QSCD (TOE as Qualified signature creation device) requires the TOE to meet Annex III of the
regulation. The paragraph 1(a) of Annex III is ensured by OT.SCD_Unique requiring that the SCD
used for signature creation can practically occurs only once. The OT.SCD_Secrecy OT.Sig_Secure and
OT.EMSEC_Design and OT.Tamper_Resistance address the secrecy of the SCD (cf. paragraph 1(a)
of Annex III). OT.SCD_Secrecy and OT.Sig_Secure meet the requirement in paragraph 1(b) of Annex
III by the requirements to ensure that the SCD cannot be derived from SVD, the electronic signatures
or any other data exported outside the TOE. OT.Sigy_SigF meets the requirement in paragraph 1(c) of
Annex III by the requirements to ensure that the TOE provides the signature creation function for the
legitimate signatory only and protects the SCD against the use of others. OT.DTBS_Integrity_TOE
meets the requirements in paragraph 2 of Annex III as the TOE must not alter the DTBS/R. The usage
of SCD under sole control of the signatory is ensured by OT.Lifecycle_Security,
OT.SCD/SVD_Auth_Gen and OT.Sigy_SigF.
OE.Dev_Prov_Service (Authentic QSCD provided by QSCD Provisioning Service) ensures that the
legitimate user obtains a TOE sample as an authentic, initialised and personalised TOE from an QSCD
Provisioning Service through the TOE delivery procedure. If the TOE implements SCD generated under
control of the QSCD Provisioning Service the legitimate user receives the TOE as QSCD. If the TOE is
delivered to the legitimate user without SCD in the operational phase he or she applies for the (qualified)
certificate as the Device holder and legitimate user of the TOE. The CSP will use the TOE security
feature (addressed by the security objectives OT.TOE_QSCD_Auth and OT.TOE_TC_SVD_Exp to
check whether the device presented is a QSCD linked to the applicant as required by
OE.CGA_QSCD_Auth and the received SVD is sent by this QSCD as required by
OE.CGA_TC_SVD_Imp. Thus, the obligation of the QSCD provision service for the first SCD/SVD pair
is complemented in an appropriate way by the CSP for the SCD/SVD pair generated outside the secure
preparation environment.
P.Sig_Non-Repud (Non-repudiation of signatures) deals with the repudiation of signed data by the
signatory, although the electronic signature is successfully verified with the SVD contained in their
certificate valid at the time of signature creation. This policy is implemented by the combination of the
security objectives for the TOE and its operational environment, which ensures the aspects of
signatory’s sole control over and responsibility for the electronic signatures generated with the TOE.
OE.QSCD_Prov_Service (Authentic QSCD provided by QSCD-provisioning service) ensures that the
signatory uses an authentic TOE, initialised and personalised for the signatory. OE.CGA_QCert
(Generation of qualified certificates) ensures that the certificate allows to identify the signatory and thus
to link the SVD to the signatory. OE.SVD_Auth (Authenticity of the SVD) and OE.CGA_QCert
(Generation of qualified certificates) require the environment to ensure authenticity of the SVD as being
exported by the TOE and used under sole control of the signatory. OT.SCD_SVD_Corresp
(Correspondence between SVD and SCD) ensures that the SVD exported by the TOE corresponds to
the SCD that is stored in the TOE. OT.SCD_Unique (Uniqueness of the signature creation data)
provides that the signatory’s SCD can practically occur just once
IDentity Applet v4.0/QSCD Security Target
Page 39 of 73
OE.Signatory (Security obligation of the signatory) ensures that the signatory checks that the SCD,
stored in the QSCD received from an QSCD provisioning service is in non-operational state (i.e. the
SCD cannot be used before the signatory becomes into sole control over the QSCD). OT.Sigy_SigF
(Signature creation function for the legitimate signatory only) provides that only the signatory may use
the TOE for signature creation. As prerequisite OE.Signatory (Security obligation of the signatory)
ensures that the signatory keeps their VAD confidential. The confidentiality of VAD is protected during
the transmission between the HI device and TOE according to OE.HID_TC_VAD_Exp (Trusted channel
of HID for VAD) and OE.CGA_TC_SVD_Imp (Trusted channel of TOE for VAD). OE.DTBS_Intend (SCA
sends data intended to be signed), OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE),
OE.SCA_TC_DTBS_Exp (Trusted channel of SCA for DTBS) and OT.TOE_TC_DTBS_Imp (Trusted
channel of TOE for DTBS) ensure that the TOE generates electronic signatures only for a DTBS/R that
the signatory has decided to sign as DTBS. The robust cryptographic techniques required by
OT.Sig_Secure (Cryptographic security of the electronic signature) ensure that only this SCD may
generate a valid electronic signature that can be successfully verified with the corresponding SVD used
for signature verification. The security objective for the TOE OT.Lifecycle_Security (Lifecycle security),
OT.SCD_Secrecy (Secrecy of the signature creation data), OT.EMSEC_Design (Provide physical
emanations security), OT.Tamper_ID (Tamper detection) and OT.Tamper_Resistance (Tamper
resistance) protect the SCD against any compromise.
OE.Dev_Prov_Service ensures that the signatory uses an authentic TOE, initialised and personalised
for the signatory. OE.CGA_Qcert ensures that the certificate allows to identify the signatory and thus to
link the SVD to the signatory.
OE.SVD_Auth and OE.CGA_Qcert require the environment to ensure authenticity of the SVD as being
exported by the TOE and used under sole control of the signatory. OT.SCD_SVD_Corresp ensures that
the SVD exported by the TOE corresponds to the SCD that is implemented in the TOE.
OT.SCD_Unique provides that the signatory’s SCD can practically occur just once.
OE.Signatory (Security obligation of the signatory) ensures that the signatory checks that the SCD,
stored in the QSCD received from an QSCD provisioning service is in non-operational state (i.e. the
SCD cannot be used before the signatory becomes into sole control over the QSCD). OT.Sigy_SigF
(Signature creation function for the legitimate signatory only) pr ovides that only the signatory may use
the TOE for signature creation. As prerequisite OE.Signatory (Security obligation of the signatory)
ensures that the signatory keeps their VAD confidential. The confidentiality of VAD is protected during
the transmission between the HI device and TOE according to OE.HID_TC_VAD_Exp (Trusted channel
of HID for VAD) and OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD). OE.DTBS_Intend (SCA
sends data intended to be signed), OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE),
OE.SCA_TC_DTBS_Exp (Trusted channel of SCA for DTBS) and OT.TOE_TC_DTBS_Imp (Trusted
channel of TOE for DTBS) ensure that the TOE generates electronic signatures only for a DTBS/R that
the signatory has decided to sign as DTBS. The robust cryptographic techniques required by
OT.Sig_Secure (Cryptographic security of the electronic signature) ensure that only this SCD may
generate a valid electronic signature that can be successfully verified with the corresponding SVD used
for signature verification. The security objective for the TOE OT.Lifecycle_Security (Lifecycle security),
OT.SCD_Secrecy (Secrecy of the signature creation data), OT.EMSEC_Design (Provide physical
emanations security), OT.Tamper_ID (Tamper detection) and OT.Tamper_Resistance (Tamper
resistance) protect the SCD against any compromise
Upkeep of assumptions by security objectives
A.SCA (Trustworthy signature creation application) establishes the trustworthiness of the SCA with
respect to generation of DTBS/R. This is addressed by OE.DTBS_Intend (Data intended to be signed)
which ensures that the SCA generates the DTBS/R of the data that have been presented to the signatory
as DTBS and which the signatory intends to sign in a form which is appropriate for being signed by the
TOE.
A.CGA (Trustworthy certification generation application) establishes the protection of the authenticity
of the signatory's name and the SVD in the qualified certificate by the advanced signature of the CSP
by means of the CGA. This is addressed by OE.CGA_Qcert (Generation of qualified certificates), which
ensures the generation of qualified certificates, and by OE.SVD_Auth (Authenticity of the SVD), which
ensures the protection of the integrity of the received SVD and the verification of the correspondence
between the SVD and the SCD that is implemented by the QSCD of the signatory.
IDentity Applet v4.0/QSCD Security Target
Page 40 of 73
5. Extended Component Definition
The additional family FPT_EMS (TOE Emanation) of the Class FPT (Protection of the TSF) is defined
here to describe the IT security functional requirements of the TOE. The TOE shall prevent attacks
against the SCD and other secret data where the attack is based on external observable physical
phenomena of the TOE. Examples of such attacks are evaluation of TOE’s electromagnetic radiation,
simple power analysis (SPA), differential power analysis (DPA), timing attacks, radio emanation etc.
This family describes the functional requirements for the limitation of intelligible emanations. The family
FPT_EMS belongs to the Class FPT because it is the class for TSF protection. Other families within the
Class FPT do not cover the TOE emanation. The definition of the family FPT_EMS is taken from the
Protection Profile Secure Signature Creation Device [18].
The additional family FIA_API (a sensitive family of the Class FIA (Identification and authentication).
This family describes the functional requirements for the proof of the claimed identity for the
authentication verification by an external entity where the other families of the class FIA address the
verification of the identity of an external entity. The definition of the family FIA_API is taken from the
Protection Profile Secure Signature Creation Device [19].
FPT_EMS TOE Emanation
Family behaviour: This family defines requirements to mitigate intelligible emanations.
Component levelling:
FPT_EMS.1 TOE Emanation has two constituents:
FPT_EMS.1.1 Limit of Emissions requires to not emit intelligible emissions enabling access to TSF
data or user data.
FPT_EMS.1.2 Interface Emanation requires not emit interface emanation enabling access to TSF data
or user data.
Management: FPT_EMS.1 There are no management activities foreseen.
Audit: FPT_EMS.1 There are no actions identified that must be auditable if FAU_GEN (Security audit data
generation) is included in a protection profile or security target.
FPT_EMS.1 TOE Emanation
Hierarchical to: No other components
Dependencies: No dependencies.
FPT_EMS.1.1
The TOE shall not emit [assignment: types of emissions] in excess of [assignment: specified limits]
enabling access to [assignment: list of types of TSF data] and [assignment: list of types of user data].
FPT_EMS.1.2
The TSF shall ensure [assignment: type of users] are unable to use the following interface [assignment:
type of connection] to gain access to [assignment: list of types of TSF data] and [assignment: list of
types of user data].
FIA_API Authentication Proof of Identity
Family behaviour: This family defines functions provided by the TOE to prove their identity and to be
verified by an external entity in the TOE IT environment.
Component levelling:
FIA_API.1 Authentication Proof of Identity.
FPT_EMS TOE Emanation 1
FIA_API Authentication Proof of Identity 1
IDentity Applet v4.0/QSCD Security Target
Page 41 of 73
Management: FIA_API.1 The following actions could be considered for the management functions in
FMT: Management of authentication information used to prove the claimed identity.
Audit: There are no actions defined to be auditable.
FIA_API.1 Authentication Proof of Identity
Hierarchical to: No other components
Dependencies: No dependencies.
FIA_API.1.1
The TSF shall provide a [assignment: authentication mechanism] to prove the identity of the
[assignment: authorized user or role].
IDentity Applet v4.0/QSCD Security Target
Page 42 of 73
6. Security Requirements
6.1. TOE Security Functional Requirements
6.1.1. Use of requirement specifications
Common Criteria allows several operations to be performed on functional requirements; refinement,
selection, assignment, and iteration. Each of these operations is used in this ST and the underlying
PP. The footnotes in this ST indicate the operations of the PP and the ST as well.
A refinement operation is used to add detail to a requirement, and thus further restricts a
requirement. Refinement of security requirements is either (i) denoted by the word “refinement” in
bold text and the added or changed words are in bold text, or (ii) included in text as bold text and
marked by a footnote. In cases where words from a CC requirement were deleted, a separate
attachment indicates the words that were removed.
A selection operation is used to select one or more options provided by the CC or the underlying
PP in stating a requirement. A selection that has been made is indicated as underlined text and the
original text of the component is given by a footnote.
An assignment operation is used to assign a specific value to an unspecified parameter, such as
the length of a password. An assignment that that has been made is indicated as double underlined
text and the original text of the component is given by a footnote.
An iteration operation is used when a component is repeated with varying operations. Iteration is
denoted by showing a slash “/”, and the iteration indicator after the component identifier.
6.1.2. Cryptographic support (FCS)
12. Application note (taken from application note 4 from [18])
Applied.
FCS_CKM.1
Cryptographic key generation (from [18])
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 an SCD/SVD pair in accordance with a specified cryptographic key generation
algorithm RSA or ECDSA7 and specified cryptographic key sizes 1024-4096 or 160-521 bits8 that meet
the following: [7]9
13. Application note (taken from application note 5 from [18])
Applied.
14. Application note (from the ST author)
The underlying Platform supports RSA, RSA-CRT and ECDSA generation algorithms and cryptographic
key sizes 1024 bits to 4096 (RSA) and 160 bits to 521 bits (ECDSA). These key lengths are supported
with equivalent implementation-level security measures. However, to defend against attackers with high
attack potential, the actual key length chosen for use during the operational phase must be appropriate
and in line with current cryptographic recommendations. When selecting the key length, consideration
7 [assignment: cryptographic key generation algorithm]
8 [assignment: cryptographic key sizes]
9 [assignment: list of standards]
IDentity Applet v4.0/QSCD Security Target
Page 43 of 73
must be given to the expected lifetime of the TOE to ensure that the chosen cryptographic strength
remains sufficient throughout the entire operational.
FCS_CKM.4
Cryptographic key destruction (from [18])
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.1
The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction
method physically overwriting the keys in a randomized manner10 that meets the following: none.11
15. Application note (taken from application note 6 from [18])
Applied.
FCS_COP.1
Cryptographic operation (from [18])
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
The TSF shall perform digital signature creation12 in accordance with a specified cryptographic algorithm
RSA according to RSA PKCS#1 (v1.5) or PKCS#1-PSS with SHA-224, SHA-256, SHA-384, SHA-512
with key length 1024, 2048, 3072, 4096 bits or ECDSA according to NIST FIPS PUB 186-2 with SHA-
224, SHA-256, SHA-384 and SHA-512 with key length 160, 192, 224, 256, 384, 52113,14 that meet the
following: [25]15.
16. Application note (taken from application note 7 from [18])
Applied.
17. Application note (from the ST author)
The underlying Platform supports RSA, RSA-CRT and ECDSA signature algorithms and cryptographic
key length 1024 bits to 4096 bits (RSA) and 160 bits to 521 bits (ECDSA). These key lengths are
supported with equivalent implementation-level security measures. However, to defend against
attackers with high attack potential, the actual key length chosen for use during the operational phase
must be appropriate and in line with current cryptographic recommendations. When selecting the key
length, consideration must be given to the expected lifetime of the TOE to ensure that the chosen
cryptographic strength remains sufficient throughout the entire operational lifespan.
6.1.3. User data protection (FDP)
The security attributes and related status for the subjects and objects are:
10 [assignment: cryptographic key destruction method]
11 [assignment: list of standards]
12 [assignment: list of cryptographic operations]
13 [assignment: cryptographic algorithm]
14 [assignment: cryptographic key sizes]
15 [assignment: list of standards]
IDentity Applet v4.0/QSCD Security Target
Page 44 of 73
Subject or object the security
attribute is associated with
Security attribute type Value of the security attribute
S.User Role R.Admin – S.User acts as S.Admin
R.Sigy – S.User acts as S.Sigy
S.User SCD/SVD Management authorized,
not authorized
SCD SCD Operational no,
yes
SCD SCD Identifier arbitrary value
SVD (This ST does not define security
attributes for SVD)
(This ST does not define security
attributes for SVD)
7. Table Subjects and security attributes for access control
18. Application note (taken from application note 8 from [18])
Applied.
FDP_ACC.1/Signature_Creation
Subset access control (from [18])
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.1.1/Signature_Creation
The TSF shall enforce the Signature Creation SFP16 on
(1) subjects: S.User,
(2) objects: DTBS/R, SCD,
(3) operations: signature creation.17
FDP_ACC.1/SCD/SVD_Generation
Subset access control (from [18])
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.1.1/SCD/SVD_Generation
The TSF shall enforce the SCD/SVD_Generation_SFP18 on
(1) subjects: S.User,
(2) objects: SCD, SVD,
(3) operations: generation of SCD/SVD pair19
FDP_ACF.1/SCD/SVD_Generation
Security attribute based access control (from [18])
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
FDP_ACF.1.1/SCD/SVD_Generation
16 [assignment: access control SFP]
17 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
18 [assignment: access control SFP]
19 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
IDentity Applet v4.0/QSCD Security Target
Page 45 of 73
The TSF shall enforce the SCD/SVD_Generation_SFP20 to objects based on the following: the user
S.User is associated with the security attribute “SCD/SVD Management“21.
FDP_ACF.1.2/SCD/SVD_Generation_SFP
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed:
S.User with the security attribute “SCD / SVD Management” set to “authorized” is allowed to generate
SCD/SVD pair22
FDP_ACF.1.3/SCD/SVD_Generation
The TSF shall explicitly authorize access of subjects to objects based on the following additional rules:
none23.
FDP_ACF.1.4/ SCD/SVD_Generation
The TSF shall explicitly deny access of subjects to objects based on the following additional rules:
S.User with the security attribute “SCD / SVD management” set to “not authorized” is not allowed to
generate SCD/SVD pair24.
FDP_ACC.1/SVD_Transfer
Subset access control (from [21])
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.1.1/SVD_Transfer
The TSF shall enforce the SVD_Transfer_SFP25 on
(1) subjects: S.User,
(2) objects: SVD
(3) operations: export26.
FDP_ACF.1/SVD_Transfer
Security attribute based access control (from [18])
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
FDP_ACF.1.1/SVD_Transfer
The TSF shall enforce the SVD_Transfer_SFP27 to objects based on the following:
(1) the S.User is associated with the security attribute Role,
(2) the SVD28.
FDP_ACF.1.2/SVD_Transfer
20 [assignment: access control SFP]
21 [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]
22 [assignment: rules governing access among controlled subjects and controlled objects using
controlled operations on controlled objects]
23 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]
24 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
25 [assignment: access control SFP]
26 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
27 [assignment: access control SFP]
28 [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]
IDentity Applet v4.0/QSCD Security Target
Page 46 of 73
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed: R.Admin29 is allowed to export SVD30.
FDP_ACF.1.3/SVD_Transfer
The TSF shall explicitly authorize access of subjects to objects based on the following additional rules:
none31.
FDP_ACF.1.4/SVD_Transfer
The TSF shall explicitly deny access of subjects to objects based on the following additional rules:
none32.
19. Application note (taken from application note 9 from [18])
Applied.
FDP_ACF.1/Signature creation
Security attribute based access control (from [18])
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
FDP_ACF.1.1/Signature_creation
The TSF shall enforce the Signature creation_SFP33 to objects based on the following:
(1) the user S.User is associated with the security attribute “Role” and
(2) the SCD with the security attribute “SCD Operational”34.
FDP_ACF.1.2/Signature_creation
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed:
R.Sigy is allowed to create digital signatures for DTBS/R with SCD which security attribute “SCD
operational” is set to “yes”35.
FDP_ACF.1.3/Signature_creation
The TSF shall explicitly authorize access of subjects to objects based on the following additional rules:
none36.
FDP_ACF.1.4/Signature_creation
The TSF shall explicitly deny access of subjects to objects based on the following additional rules:
S.User is not allowed to create digital signatures for DTBS/R with SCD which security attribute “SCD
operational” is set to “no”37.
FDP_DAU.2/SVD
Data Authentication with Identity of Guarantor (from [19])
Hierarchical to: FDP_DAU.1 Basic Data Authentication
29 [selection: R.Admin, R.Sigy ]
30 [assignment: rules governing access among controlled subjects and controlled objects using
controlled operations on controlled objects]].
31 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]
32 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
33 [assignment: access control SFP]
34 [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]
35 [assignment: rules governing access among controlled subjects and controlled objects using
controlled operations on controlled objects]
36 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]
37 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
IDentity Applet v4.0/QSCD Security Target
Page 47 of 73
Dependencies: FIA_UID.1 Timing of identification
FDP_DAU.2.1/SVD
The TSF shall provide a capability to generate evidence that can be used as a guarantee of the validity
of SVD38.
FDP_DAU.2.2/SVD
The TSF shall provide CGA39 with the ability to verify evidence of the validity of the indicated information
and the identity of the user that generated the evidence.
20. Application note (from the ST author)
The TOE supports Certificate Request Signature (CRS) to provide evidence about the validity of the
SVD for the CGA. CRS also proves that the SVD belongs to the TOE.
FDP_RIP.1
Subset residual information protection (from [18])
Hierarchical to: No other components.
Dependencies: No dependencies.
FDP_RIP.1.1
The TSF shall ensure that any previous information content of a resource is made unavailable upon the
overwrite or deallocation of the resource from40 the following objects: SCD41.
21. Application note (from the ST author)
The TOE overwrites the previous SCD in case a new key pair generation.
The following data persistently stored by the TOE shall have the user data attribute "integrity checked
persistent stored data":
1. SCD
2. SVD (if persistently stored by the TOE).
The DTBS/R temporarily stored by the TOE has the user data attribute "integrity checked stored data":
FDP_SDI.2/Persistent
Stored data integrity monitoring and action (from [18])
Hierarchical to: FDP_SDI.1 Stored data integrity monitoring.
Dependencies: No dependencies
FDP_SDI.2.1/Persistent
The TSF shall monitor user data stored in containers controlled by the TSF for integrity error42 on all
objects, based on the following attributes: integrity checked stored data43.
FDP_SDI.2.2/Persistent
Upon detection of a data integrity error, the TSF shall
(1) prohibit the use of the altered data
(2) inform the S.Sigy about integrity error44.
38 [assignment: list of objects or information types]
39 [assignment: list of subjects]
40 [selection: allocation of the resource to, deallocation of the resource from]
41 [assignment: list of objects]
42 [assignment: integrity errors]
43 [assignment: user data attributes]
44 [assignment: action to be taken]
IDentity Applet v4.0/QSCD Security Target
Page 48 of 73
FDP_SDI.2/DTBS
Stored data integrity monitoring and action (from [18])
Hierarchical to: FDP_SDI.1 Stored data integrity monitoring.
Dependencies: No dependencies.
FDP_SDI.2.1/DTBS
The TSF shall monitor user data stored in containers controlled by the TSF for integrity error45 on all
objects, based on the following attributes: integrity checked stored DTBS46.
FDP_SDI.2.2/DTBS
Upon detection of a data integrity error, the TSF shall
(1) prohibit the use of the altered data
(2) inform the S.Sigy about integrity error47.
22. Application note (taken from application note 10 from [18])
Applied.
23. Application note (from the ST author)
There is no stored DTBS in the TOE, because the card only receives and immediately signs hash
(DTBS/R), not the DTBS
FDP_UIT.1/DTBS
Data exchange integrity (from [20])
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/DTBS
The TSF shall enforce the Signature Creation SFP48
to receive49
user data in a manner
protected from modification and insertion50
errors.
FDP_UIT.1.2/DTBS
The TSF shall be able to determine on receipt of user data, whether modification and
insertion51
has occurred.
6.1.4. Identification and authentication (FIA)
FIA_UID.1
Timing of identification (from [18])
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UID.1.1
The TSF shall allow
45 [assignment: integrity errors]
46 [assignment: user data attributes]
47 [assignment: action to be taken]
48 [assignment: access control SFP(s) and/or information flow control SFP(s)]
49 [selection: transmit, receive]
50 [selection: modification, deletion, insertion, replay]
51 [selection: modification, deletion, insertion, replay]
IDentity Applet v4.0/QSCD Security Target
Page 49 of 73
(1) Self-test according to FPT_TST.1,
(2) none5253
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.
24. Application note (taken from application note 11 from [18])
Applied.
FIA_UAU.1
Timing of authentication (from [19] and [20])
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification.
FIA_UAU.1.1
The TSF shall allow
(1) self-test according to FPT_TST.1,
(2) identification of the user by means of TSF required by FIA_UID.1,
(3) establishing a trusted channel between the CGA and the TOE by means of TSF required by
FTP_ITC.1/SVD, 5455
(4) establishing a trusted channel between the HID and the TOE by means of TSF required by
FTP_ITC.1/VAD,
(5) none5657
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.
25. Application note (taken from application note 1 from [19] and 5 from [20]))
Applied.
FIA_API.1
Authentication Proof of Identity (from [19])
Hierarchical to: No other components.
Dependencies: No dependencies
FIA_API.1.1
The TSF shall provide a symmetric or asymmetric authentication mechanism58 to prove the identity of
the QSCD59
52 [assignment: list of TSF-mediated actions]
53 [assignment: list of additional TSF-mediated actions]
54 [assignment: list of TSF-mediated actions]
55 [assignment: list of additional TSF-mediated actions]
56 [assignment: list of TSF-mediated actions]
57 [assignment: list of additional TSF-mediated actions]
58 [assignment: authentication mechanism]
59 [assignment: authorized user or rule]
IDentity Applet v4.0/QSCD Security Target
Page 50 of 73
26. Application note (taken from application note 2 from [19])
Applied.
27. Application note (from ST author)
The IDentity Applet supports several kind of symmetric or asymmetric authentication mechanisms,
which compliance with the followings:[22][23][27] In addition IDentity Applet supports Certificate
Request Signature, which implements a high secure way to prove the identity and authenticity of the
QSCD based on PKI, in addition proves the correspondence between SCD/SVD key pair in authentic
way.
The authentication mechanism is depended on the configured Application Profile.
FIA_AFL.1
Authentication failure handling (from [18])
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 3-1560 61, unsuccessful
authentication attempts occur related to consecutive failed authentication attempts62
FIA_AFL.1.2
When the defined number of unsuccessful authentication attempts has been met63, the TSF shall block
RAD64
28. Application note (taken from application note 13 from [18])
Applied.
29. Application note (from ST Author)
The PUK (personal unlocking key) is an optional security function of IDentity Applet, which meet the
requirements of FIA_AFL.1.1 and FIA_AFL.1.2 as described is current ST.
6.1.5. Security management (FMT)
FMT_SMR.1
Security roles (from [18])
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1
The TSF shall maintain the roles R.Admin and R.Sigy65.
FMT_SMR.1.2
The TSF shall be able to associate users with roles.
FMT_SMF.1
Specification of management functions (from [18])
Hierarchical to: No other components.
60 [assignment: positive integer number]
61 [selection: [assignment: positive integer number] an administrator configurable positive integer within
[assignment: range of acceptable values]]
62 [assignment: list of authentication events]
63 [selection: met,surpassed]
64 [assignment: list of actions]
65 [assignment: the authorized identified roles]
IDentity Applet v4.0/QSCD Security Target
Page 51 of 73
Dependencies: No dependencies
FMT_SMF.1.1
The TSF shall be capable of performing the following management functions:
(1) Creation and modification of RAD,
(2) Enabling the signature-creation function,
(3) Modification of the security attribute SCD/SVD management, SCD operational,
(4) Change the default value of the security attribute SCD Identifier,
(5) Unblock the RAD6667.
30. Application note (taken from application note 14 from [18])
Applied.
FMT_MOF.1
Management of security functions behaviour (from [18])
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management
Functions.
FMT_MOF.1.1
The TSF shall restrict the ability to enable68 the functions signature-creation function69 to R.Sigy70
FMT_MSA.1/Admin
Management of security attributes (from [18])
Hierarchical to: No other components.
Dependencies: [ FDP_ACC.1 Subset access control, or FDP_IFC.1
Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management
Functions
FMT_MSA.1.1/Admin
The TSF shall enforce the SCD/SVD_Generation_SFP71 to restrict the ability to modify, none72 the
security attributes SCD / SVD management73 to R.Admin74.
FMT_MSA.1/Signatory
Management of security attributes (from [18])
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1
Subset information flow control]
FMT_SMR.1 Security roles
66 [assignment: list of security management functions to be provided by the TSF]
67 [assignment: list of other security management functions to be provided by the TSF]
68 [selection: determine the behaviour of, disable, enable, modify the behaviour of]
69 [assignment: list of functions]
70 [assignment: the authorized identified roles]
71 [assignment: access control SFP(s), information flow control SFP(s)]
72 [selection: change_default, query, modify, delete, [assignment: other operations]]
73 [assignment: list of security attributes]
74 [assignment: the authorized identified roles]
IDentity Applet v4.0/QSCD Security Target
Page 52 of 73
FMT_SMF.1 Specification of Management
Functions
FMT_MSA.1.1/Signatory
The TSF shall enforce the Signature-creation_SFP75 to restrict the ability to modify76 the security
attributes SCD operational77 to R.Sigy78.
FMT_MSA.2
Secure security attributes (from [18])
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1
Subset information flow control]
FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.2.1
The TSF shall ensure that only secure values are accepted for SCD / SVD Management and SCD
operational79.
31. Application note (taken from application note 15 from [18])
Applied.
FMT_MSA.3
Static attribute initialization (from [18])
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1
The TSF shall enforce the SCD/SVD_Generation_SFP, SVD_Transfer_SFP and Signature-
creation_SFP80to provide restrictive81 default values for security attributes that are used to enforce the
SFP.
FMT_MSA.3.2
The TSF shall allow the R.Admin82 to specify alternative initial values to override the default values when
an object or information is created.
FMT_MSA.4
Security attribute value inheritance (from [18])
Hierarchical to: No other components.
Dependencies: [ FDP_ACC.1 Subset access control, or FDP_IFC.1
Subset information flow control]
FMT_MSA.4.1
The TSF shall use the following rules to set the value of security attributes:
75 [assignment: access control SFP(s), information flow control SFP(s)]
76 [selection: change_default, query, modify, delete, [assignment: other operations]]
77 [assignment: list of security attributes]
78 [assignment: the authorized identified roles]
79 [assignment: list of security attributes]
80 [assignment: access control SFP, information flow control SFP]
81 [selection, choose one of: restrictive, permissive, [assignment: other property]]
82 [assignment: the authorized identified roles
IDentity Applet v4.0/QSCD Security Target
Page 53 of 73
(1) If S.Admin successfully generates an SCD/SVD pair without S.Sigy being authenticated the security
attribute “SCD operational of the SCD” shall be set to “no” as a single operation.
(2) If S.Sigy successfully generates an SCD/SVD pair the security attribute “SCD operational of the
SCD” shall be set to “yes” as a single operation.83
32. Application note (taken from application note 16 from [18])
Applied.
FMT_MTD.1/Admin
Management of TSF data (from [18])
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management
Functions
FMT_MTD.1.1/Admin
The TSF shall restrict the ability to create84 the RAD85 to R.Admin86.
FMT_MTD.1/Signatory
Management of TSF data (from [18])
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management
Functions
FMT_MTD.1.1/Signatory
The TSF shall restrict the ability to modify, none8788 the RAD89 to R.Sigy90.
33. Application note (taken from application note 17 from [18])
Applied.
6.1.6. Protection of the TSF (FPT)
FPT_EMS.1
TOE Emanation (from [18])
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_EMS.1.1
The TOE shall not emit variations in power consumption or timing during command execution91 in excess
of non-useful information92 enabling access to RAD93 and SCD94.
FPT_EMS.1.2
83 [assignment: rules for setting the values of security attributes]
84 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
85 [assignment: list of TSF data]
86 [assignment: the authorized identified roles]
87 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
88 [assignment: other operations]
89 [assignment: list of TSF data]
90 [assignment: the authorized identified roles]
91 [assignment: types of emissions]
92 [assignment: specified limits]
93 [assignment: list of types of TSF data]
94 [assignment: list of types of user data]
IDentity Applet v4.0/QSCD Security Target
Page 54 of 73
The TSF shall ensure that unauthorized users95 are unable to use the following interface electrical
contacts and contactless I/O96 to gain access to RAD97 and SCD98.
34. Application note (taken from application note 18 from [18])
Applied.
FPT_FLS.1
Failure with preservation of secure state (from [18])
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) self-test according to FPT_TST fails,
(2) none99.
35. Application note (taken from application note 19 from [18])
Applied.
FPT_PHP.1
Passive detection of physical attack (from [18])
Hierarchical to: No other components.
Dependencies: No dependencies
FPT_PHP.1.1
The TSF shall provide unambiguous detection of physical tampering that might compromise the TSF.
FPT_PHP.1.2
The TSF shall provide the capability to determine whether physical tampering with the TSF’s devices or
TSF’s elements has occurred.
FPT_PHP.3
Resistance to physical attack (from [18])
Hierarchical to: No other components.
Dependencies: No dependencies
FPT_PHP.3.1
The TSF shall resist physical manipulation and physical probing 100 to the TSF101by responding
automatically such that the SFRs are always enforced.
36. Application note (taken from application note 20 from [18])
Applied
FPT_TST.1
TSF testing (from [18])
Hierarchical to: No other components.
95 [assignment: type of users]
96 [assignment: type of connection]
97 [assignment: list of types of TSF data]
98 [assignment: list of types of user data]
99 [assignment: list of types of failures in the TSF]
100 [assignment: physical tampering scenarios]
101 [assignment: list of TSF devices/elements]
IDentity Applet v4.0/QSCD Security Target
Page 55 of 73
Dependencies: No dependencies
FPT_TST.1.1
The TSF shall run a suite of self-tests during initial start-up, periodically during normal operation 102 to
demonstrate the correct operation of the TSF103
FPT_TST.1.2
The TSF shall provide authorized users with the capability to verify the integrity of TSF data104.
FPT_TST.1.3
The TSF shall provide authorized users with the capability to verify the integrity of TSF105
37. Application note (taken from application note 21 from [18]
Applied
6.1.7. Trusted path/Channels (FTP)
FTP_ITC.1/SVD
Inter-TSF trusted channel – CGA (from [19])
Hierarchical to: No other components
Dependencies: No dependencies
FTP_ITC.1.1/SVD
The TSF shall provide a communication channel between itself and another trusted IT product CGA 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/SVD
The TSF shall permit another trusted IT product106 to initiate communication via the trusted channel.
FTP_ITC.1.3/SVD
The TSF or the CGA shall initiate communication via the trusted channel for
(1) data Authentication with Identity of Guarantor according to FIA_API.1 and
FDP_DAU.2/SVD.
(2) none107108
38. Application note (taken from application note 3 and 4 from [19])
Applied
FTP_ITC.1/VAD
Inter-TSF trusted channel – TC Human Interface Device (from [20])
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_ITC.1.1/VAD
102 [selection: during initial start-up, periodically during normal operation, at the request of the
authorized user, at the conditions[assignment: conditions under which self-test should occur]]
103 [selection: [assignment: parts of TSF], the TSF]
104 [selection: [assignment: parts of TSF data], TSF data]
105 [selection: [assignment: parts of TSF], TSF]
106 [selection: the TSF, another trusted IT product]
107 [assignment: list of functions for which a trusted channel is required]
108 [assignment: list of other functions for which a trusted channel is required]
IDentity Applet v4.0/QSCD Security Target
Page 56 of 73
The TSF shall provide a communication channel between itself and another trusted IT product HID 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/VAD
The TSF shall permit the remote trusted IT product109 to initiate communication via the trusted channel.
FTP_ITC.1.3/VAD
The TSF or the HID shall initiate communication via the trusted channel for
(1) User authentication according to FIA_UAU.1,
(2) none110.
39. Application note (taken from application note 6 from [20])
Applied
FTP_ITC.1/DTBS
Inter-TSF trusted channel – Signature creation Application (from [20])
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_ITC.1.1/DTBS
The TSF shall provide a communication channel between itself and another trusted IT product SCA 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/DTBS
The TSF shall permit the remote trusted IT product111 to initiate communication via the trusted channel.
FTP_ITC.1.3/DTBS
The TSF or the SCA shall initiate communication via the trusted channel for
(1) signature creation,
(2) none112.
40. Application note (taken from application note 7 from [20])
Applied
109 [selection: the TSF, another trusted IT product ]
110 [assignment: list of functions for which a trusted channel is required]
111 [selection: the TSF, another trusted IT product ]
112 [assignment: list of functions for which a trusted channel is required]
IDentity Applet v4.0/QSCD Security Target
Page 57 of 73
6.2. TOE Security Assurance Requirements
The assurance requirements for the evaluation of the TOE, its development and operating
environment are to choose as the predefined assurance package EAL5 augmented by the
following components:
• ALC_DVS.2 (Sufficiency of security measures) and
• AVA_VAN.5 (Advanced methodical vulnerability analysis).
6.3. Security Requirements Rationale
6.3.1. Security Requirement Coverage
OT.Lifecycle_Security
OT.SCD/SVD_Auth_Gen
OT.SCD_Unique
OT.SCD_SVD_Corresp
OT.SCD_Secrecy
OT.Sig_Secure
OT.Sigy_SigF
OT.DTBS_Integrity_TOE
OT.EMSEC_Design
OT.Tamper_ID
OT.Tamper_Resistance
OT.TOE_QSCD_Auth
OT.TOE_TC_SVD_Exp
OT.TOE_TC_VAD_Imp
OT.TOE_TC_DTBS_Imp
FCS_CKM.1 X - X X X - - - - - - - - - -
FCS_CKM.4 X - - - X - - - - - - - - - -
FCS_COP.1 X - - - - X - - - - - - - - -
FDP_ACC.1/SCD/SVD_Generatio
n
X X - - - - - - - - - - - - -
FDP_ACC.1/SVD_Transfer X - - - - - - - - - - - X - -
FDP_ACC.1/Signature_Creation X - - - - - X - - - - - - - -
FDP_ACF.1/SCD/SVD_Generatio
n
X X - - - - - - - - - - - - -
FDP_ACF.1/SVD_Transfer X - - - - - - - - - - - X - -
FDP_ACF.1/Signature creation X - - - - - X - - - - - - - -
FDP_DAU.2/SVD - - - - - - - - - - - - X - -
FDP_RIP.1 - - - - X - X - - - - - - - -
FDP_SDI.2/Persistent - - - X X X - - - - - - - - -
FDP_SDI.2/DTBS - - - - - - X X - - - - - - -
FDP_UIT.1/DTBS - X
FIA_AFL.1 - - - - - - X - - - - - - - -
FIA_UAU.1 - X - - - - X - - - - X - -
FIA_API.1 - - - - - - - - - - - X - - -
FIA_UID.1 - X - - - - X - - - - - - - -
FMT_MOF.1 X - - - - - X - - - - - - - -
FMT_MSA.1/Admin X X - - - - - - - - - - - - -
FMT_MSA.1/Signatory X - - - - X - - - - - - - -
IDentity Applet v4.0/QSCD Security Target
Page 58 of 73
OT.Lifecycle_Security
OT.SCD/SVD_Auth_Gen
OT.SCD_Unique
OT.SCD_SVD_Corresp
OT.SCD_Secrecy
OT.Sig_Secure
OT.Sigy_SigF
OT.DTBS_Integrity_TOE
OT.EMSEC_Design
OT.Tamper_ID
OT.Tamper_Resistance
OT.TOE_QSCD_Auth
OT.TOE_TC_SVD_Exp
OT.TOE_TC_VAD_Imp
OT.TOE_TC_DTBS_Imp
FMT_MSA.2 X X - - - - X - - - - - - - -
FMT_MSA.3 X X - - - - X - - - - - - - -
FMT_MSA.4 X X - X - - X - - - - - - - -
FMT_MTD.1/Admin X - - - - - X - - - - - - - -
FMT_MTD.1/Signatory X - - - - - X - - - - - - - -
FMT_SMR.1 X - - - - - X - - - - - - - -
FMT_SMF.1 X - - X - - X - - - - - - - -
FPT_EMS.1 - - - - X - - - X - - - - - -
FPT_FLS.1 - - - - X - - - - - - - - - -
FPT_PHP.1 - - - - - - - - - X - - - - -
FPT_PHP.3 - - - - X - - - - - X - - - -
FPT_TST.1 X - - - X X - - - - - - - - -
FTP_ITC.1/SVD - - - - - - - - - - - - X - -
FTP_ITC.1/VAD - - - - - - - - - - - - - X -
FTP_ITC.1/DTBS - - - - - - - - - - - - - - X
8. Table Mapping of functional requirements to security objectives for the TOE
6.3.2. TOE Security Requirements Sufficiency
OT.Lifecycle_Security (Lifecycle security) is provided by the SFR for SCD/SVD generation
FCS_CKM.1, SCD usage FCS_COP.1 and SCD destruction FCS_CKM.4 ensure cryptographically
secure lifecycle of the SCD. The SCD/SVD generation is controlled by TSF according to
FDP_ACC.1/SCD/SVD_Generation and FDP_ACF.1/SCD/SVD_Generation. The SVD transfer for
certificate generation is controlled by TSF according to FDP_ACC.1/SVD_Transfer and
FDP_ACF.1/SVD_Transfer. The SCD usage is ensured by access control
FDP_ACC.1/Signature_Creation, FDP_ACF.1/Signature_creation which is based on the security
attribute secure TSF management according to FMT_MOF.1, FMT_MSA.1/Admin,
FMT_MSA.1/Signatory, FMT_MSA.2, FMT_MSA.3, FMT_MSA.4, FMT_MTD.1/Admin,
FMT_MTD.1/Signatory, FMT_SMF.1 and FMT_SMR.1. The test functions FPT_TST.1 provides failure
detection throughout the lifecycle.
OT.SCD/SVD_Auth_Gen (Authorized SCD/SVD generation) addresses that generation of a SCD/SVD
pair requires proper user authentication. The TSF specified by FIA_UID.1 and FIA_UAU.1 provide user
identification and user authentication prior to enabling access to authorized functions. The SFR
FDP_ACC.1/SCD/SVD_Generation and FDP_ACF.1/SCD/SVD_Generation provide access control for
the SCD/SVD generation. The security attributes of the authenticated user are provided by
FMT_MSA.1/Admin, FMT_MSA.2, and FMT_MSA.3 for static attribute initialization. The SFR
FMT_MSA.4 defines rules for inheritance of the security attribute “SCD operational” of the SCD.
OT.SCD_Unique (Uniqueness of the signature-creation data) implements the requirement of practically
unique SCD as laid down in Annex III, paragraph 1(a), which is provided by the cryptographic algorithms
specified by FCS_CKM.1.
OT.SCD_SVD_Corresp (Correspondence between SVD and SCD) addresses that the SVD
corresponds to the SCD implemented by the TOE. This is provided by the algorithms specified by
IDentity Applet v4.0/QSCD Security Target
Page 59 of 73
FCS_CKM.1 to generate corresponding SVD/SCD pairs. The security functions specified by
FDP_SDI.2/Persistent ensure that the keys are not modified, so to retain the correspondence. Moreover,
the SCD Identifier allows the environment to identify the SCD and to link it with the appropriate SVD.
The management functions identified by FMT_SMF.1 and by FMT_MSA.4 allow R.Admin to modify the
default value of the security attribute SCD Identifier.
OT.SCD_Secrecy (Secrecy of signature-creation data) is provided by the security functions specified
by the following SFR. FCS_CKM.1 ensures the use of secure cryptographic algorithms for SCD/SVD
generation. Cryptographic quality of SCD/SVD pair shall prevent disclosure of SCD by cryptographic
attacks using the publicly known SVD. The security functions specified by FDP_RIP.1 and FCS_CKM.4
ensure that residual information on SCD is destroyed after the SCD has been use for signature creation
and that destruction of SCD leaves no residual information.
The security functions specified by FDP_SDI.2/Persistent ensure that no critical data is modified which
could alter the efficiency of the security functions or leak information of the SCD. FPT_TST.1 tests the
working conditions of the TOE and FPT_FLS.1 guarantees a secure state when integrity is violated and
thus assures that the specified security functions are operational. An example where compromising error
conditions are countered by FPT_FLS.1 is fault injection for differential fault analysis (DFA).
SFR FPT_EMS.1 and FPT_PHP.3 require additional security features of the TOE to ensure the
confidentiality of the SCD.
OT.Sig_Secure (Cryptographic security of the digital signature) is provided by the cryptographic
algorithms specified by FCS_COP.1, which ensures the cryptographic robustness of the signature
algorithms. FDP_SDI.2/Persistent corresponds to the integrity of the SCD implemented by the TOE and
FPT_TST.1 ensure self-tests ensuring correct signature-creation.
OT.Sigy_SigF (Signature creation function for the legitimate signatory only) is provided by an SFR for
identification authentication and access control.
FIA_UAU.1 and FIA_UID.1 ensure that no signature generation function can be invoked before the
signatory is identified and authenticated. The security functions specified by FMT_MTD.1/Admin and
FMT_MTD.1/Signatory manage the authentication function. SFR FIA_AFL.1 provides protection against
a number of attacks, such as cryptographic extraction of residual information, or brute force attacks
against authentication. The security function specified by FDP_SDI.2/DTBS ensures the integrity of
stored DTBS and FDP_RIP.1 prevents misuse of any resources containing the SCD after de-allocation
(e.g. after the signature-creation process).
The security functions specified by FDP_ACC.1/Signature_Creation and
FDP_ACF.1/Signature_creation provide access control based on the security attributes managed
according to the SFR FMT_MTD.1/Signatory, FMT_MSA.2, FMT_MSA.3 and FMT_MSA.4. The SFR
FMT_SMF.1 and FMT_SMR.1 list these management functions and the roles. These ensure that the
signature process is restricted to the signatory. FMT_MOF.1 restricts the ability to enable the signature-
creation function to the signatory. FMT_MSA.1/Signatory restricts the ability to modify the security
attributes SCD operational to the signatory.
OT.DTBS_Integrity_TOE (DTBS/R integrity inside the TOE) ensures that the DTBS/R is not altered by
the TOE. The integrity functions specified by FDP_SDI.2/DTBS require that the DTBS/R has not been
altered by the TOE.
OT.EMSEC_Design (Provide physical emanations security) covers that no intelligible information is
emanated. This is provided by FPT_EMS.1.
OT.Tamper_ID (Tamper detection) is provided by FPT_PHP.1 by the means of passive detection of
physical attacks.
OT.Tamper_Resistance (Tamper resistance) is provided by FPT_PHP.3 to resist physical attacks.
OT.TOE_QSCD_Auth (Authentication proof as QSCD) requires the TOE to provide security
mechanisms to identify and to authenticate themselves as QSCD, which is directly provided by
FIA_API.1 (Authentication Proof of Identity). The SFR FIA_UAU.1 allows (additionally to the [18])
establishment of the trusted channel before (human) user is authenticated.
OT.TOE_TC_SVD_Exp (TOE trusted channel for SVD export) requires the TOE to provide a trusted
channel to the CGA to protect the integrity of the SVD exported to the CGA, which is directly provided
by
IDentity Applet v4.0/QSCD Security Target
Page 60 of 73
- The SVD transfer for certificate generation is controlled by TSF according to
FDP_ACC.1/SVD_Transfer and FDP_ACF.1/SVD_Transfer.
- FDP_DAU.2/SVD (Data Authentication with Identity of Guarantor), which requires the TOE to
provide CGA with the ability to verify evidence of the validity of the SVD and the identity of the
user that generated the evidence.
FTP_ITC.1/SVD Inter-TSF trusted channel), which requires the TOE to provide a trusted channel to the
CGA.
OT.TOE_TC_VAD_Imp (Trusted channel of TOE for VAD import) is provided by FTP_ITC.1/VAD
to provide a trusted channel to protect the VAD provided by the HID to the TOE.
OT.TOE_TC_DTBS_Imp (Trusted channel of TOE for DTBS) is provided by FTP_ITC.1/DTBS
to provide a trusted channel to protect the DTBS provided by the SCA to the TOE and by
FDP_UIT.1/DTBS, which requires the TSF to verify the integrity of the received DTBS.
6.4. Satisfaction of dependencies of security requirements
The following table provides an overview how the dependencies of the security functional requirements
are solved and a justification why some dependencies are not being satisfied.
Functional requirement Dependencies Satisfied by
FCS_CKM.1 [FCS_CKM.2 or
FCS_COP.1],
FCS_CKM.4
FCS_COP.1,
FCS_CKM.4
FCS_CKM.4 [FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.4]
FCS_CKM.1
FCS_COP.1 [FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1],
FCS_CKM.4
FCS_CKM.1,
FCS_CKM.4
FDP_ACC.1/SCD/SVD_Generation FDP_ACF.1 FDP_ACF.1/SCD/SVD_Generation
FDP_ACC.1/Signature_Creation FDP_ACF.1 FDP_ACF.1/Signature creation
FDP_ACC.1/SVD_Transfer FDP_ACF.1 FDP_ACF.1/SVD_Transfer
FDP_ACF.1/SCD/SVD_Generation FDP_ACC.1,
FMT_MSA.3
FDP_ACC.1/SCD/SVD_Generation,
FMT_MSA.3
FDP_ACF.1/Signature_Creation FDP_ACC.1,
FMT_MSA.3
FDP_ACC.1/Signature_Creation,
FMT_MSA.3
FDP_ACF.1/SVD_Transfer FDP_ACC.1,
FMT_MSA.3
FDP_ACC.1/SVD_Transfer,
FMT_MSA.3
FDP_DAU.2/SVD FIA_UID1. FIA_UID.1
FDR_RIP.1 No dependencies n/a
FDP_SDI.2/Persistent No dependencies n/a
FDP_SDI.2/DTBS No dependencies n/a
FDP_UIT.1/DTBS [FDP_ACC.1 or
FDP_IFC.1],
[FTP_ITC.1 or
FTP_TRP.1]
FDP_ACC.1/Signature_Creation
FTP_ITC.1/DTBS
FIA_AFL.1 FIA_UAU.1 FIA_UAU.1
FIA_UID.1 No dependencies n/a
FIA_UAU.1 FIA_UID.1 FIA_UID.1
FIA_API.1 No dependencies n/a
FMT_MOF.1 FMT_SMR.1,
FMT_SMF.1
FMT_SMR.1,
FMT_SMF.1
FMT_MSA.1/Admin [FDP_ACC.1 or
FDP_IFC.1],
FMT_SMR.1,
FMT_SMF.1
FDP_ACC.1/SCD/SVD_Generation,
FMT_SMR.1,
FMT_SMF.1
FMT_MSA.1/Signatory [FDP_ACC.1 or
FDP_IFC.1],
FDP_ACC.1/Signature_Creation,
FMT_SMR.1,
IDentity Applet v4.0/QSCD Security Target
Page 61 of 73
FMT_SMR.1,
FMT_SMF.1
FMT_SMF.1
FMT_MSA.2 [FDP_ACC.1 or
FDP_IFC.1],
FMT_MSA.1,
FMT_SMR.1
FDP_ACC.1/SCD/SVD_Generation,
FDP_ACC.1/Signature_Creation,
FMT_SMR.1,
FMT_MSA.1/Admin,
FMT_MSA.1/Signatory
FMT_MSA.3 FMT_MSA.1,
FMT_SMR.1
FMT_MSA.1/Admin,
FMT_MSA.1/Signatory,
FMT_SMR.1
FMT_MSA.4 [FDP_ACC.1 or
FDP_IFC.1]
FDP_ACC.1/SCD/SVD_Generation,
FDP_ACC.1/Signature_Creation
FMT_MTD.1/Admin FMT_SMR.1,
FMT_SMF.1
FMT_SMR.1,
FMT_SMF.1
FMT_MTD.1/Signatory FMT_SMR.1,
FMT_SMF.1
FMT_SMR.1,
FMT_SMF.1
FMT_SMF.1 No dependencies n/a
FMT_SMR.1 FIA_UID.1 FIA_UID.1
FPT_EMS.1 No dependencies n/a
FPT_FLS.1 No dependencies n/a
FPT_PHP.1 No dependencies n/a
FPT_PHP.3 No dependencies n/a
FPT_TST.1 No dependencies n/a
FTP_ITC.1/SVD No dependencies n/a
FTP_ITC.1/VAD No dependencies n/a
FTP_ITC.1/DTBS No dependencies n/a
9. Table Functional Requirements Dependencies
IDentity Applet v4.0/QSCD Security Target
Page 62 of 73
6.5. Rationale for chosen security assurance requirements
The assurance level for this security target is EAL5 augmented. EAL5 allows a developer to attain a
reasonably high assurance level without the need for highly specialized processes and practices. It is
considered to be the highest level that could be applied to an existing product line without undue
expense and complexity. As such, EAL5 is appropriate for commercial products that can be applied to
moderate to high security functions. The TOE described in this security target is just such a product.
Augmentation results from the selection of:
AVA_VAN.5 Advanced methodical vulnerability analysis
ALC_DVS.2 Sufficiency of security measures
The following table summarize the satisfaction of dependencies of security assurance requirements.
Assurance requirement(s) Dependencies Satisfied by
EAL5 package (dependencies of EAL5 package
are not reproduced here)
By construction, all dependencies
are satisfied in a CC EAL package
AVA_VAN.5 ADV_ARC.1, ADV_ARC.1,
ADV_FSP.4, ADV_FSP.4,
ADV_TDS.3, ADV_TDS.3,
ADV_IMP.1, ADV_IMP.1,
AGD_OPE.1, AGD_OPE.1,
AGD_PRE.1, AGD_PRE.1,
ATE_DPT.1 ATE_DPT.1
(all are included in EAL5 package)
10. Table Satisfaction of dependencies of security assurance requirements
ALC_DVS.2
Selection of component ALC_DVS.2 provides the necessary level of protection to maintain the
confidentiality and integrity of the TOE.
AVA_VAN.5
The TOE is intended to function in a variety of signature creation systems for qualified electronic
signatures. Due to the nature of its intended application, i.e., the TOE may be issued to users and may
not be directly under the control of trained and dedicated administrators. As a result, it is imperative that
misleading, unreasonable and conflicting guidance is absent from the guidance documentation, and that
secure procedures for all modes of operation have been addressed. Insecure states should be easy to
detect. The TOE shall be shown to be highly resistant to penetration attacks to meet the security
objectives OT.SCD_Secrecy, OT.Sigy_SigF and OT.Sig_Secure.
IDentity Applet v4.0/QSCD Security Target
Page 63 of 73
7. TOE Summary Specification
This chapter gives the overview description of the different TOE Security Functions composing the TSF.
The mapping in-between the TSFs and SFRs can be found in 11. Table Mapping of SFRs to
mechanisms of TOE.
7.1. TOE Security Functions
7.1.1. TSF.AccessControl
This function provides the access controls to data in the file system, initialization, personalization and
pre-personalization data. During earlier life phases, when the applet may not be present yet, the Platform
responsible for managing the accesses correctly.
The TOE provides access control mechanisms that allow the maintenance of different security roles
according to FMT_SMR.1 Security roles (R.Signatory and R.Administrator) and the access control
policies and functions (FDP_ACC.1/Signature_Creation, FDP_ACC.1/SCD/SVD_Generation,
FDP_ACF.1/SCD/SVD_Generation, FDP_ACC.1/SVD_Transfer, FDP_ACF.1/SVD_Transfer and
FDP_ACF.1/Signature creation).
Administrator role (R.Admin):
The TOE restricts the ability to the followings:
• create the RAD;
• specify alternative initial values to override the default values when an object or information is
created;
• to export SVD to CGA;
The TSF.AccessControl provides that the R.Admin role is only valid in Operational phase of IDentity
Applet life cycle.
Signatory role (R.Sigy)
The TOE restricts the ability to the followings
• enable the signature-creation function;
• modify the security attributes of SCD operational;
• modify or unblock the RAD;
• create digital signature only if the security attribute “SCD operational” is set to “yes”;
The TSF.AccessControl provides that the Signatory role is only valid in Operational phase of IDentity
Applet life cycle.
The TSF.AccessControl ensures that nobody is allowed to read all TOE intrinsic secret cryptographic
keys stored in the TOE, such as RAD, SCD.
The access control mechanisms allow the execution of certain security relevant actions (e.g. self-tests)
without successful user authentication.
The TSF provides functionality for the following SFRs:
• FDP_ACC.1/Signature_Creation: It is a requirement about access control and authentication,
the access control is provided by TSF.AccessControl.
• FDP_ACC.1/SCD/SVD_Generation: It is a requirement about access control and
authentication, the access control is provided by TSF.AccessControl.
• FDP_ACC.1/SVD_Transfer: It is a requirement about access control and authentication, the
access control is provided by TSF.AccessControl.
• FDP_ACF.1/SCD/SVD_Generation: It is a requirement about access control and authentication,
the access control is provided by TSF.AccessControl, the authentication control is provided by
TSF.Authenticate.
• FDP_ACF.1/SVD_Transfer: It is a requirement about access control and authentication, the
access control is provided by TSF.AccessControl, the authentication control is provided by
TSF.Authenticate.
IDentity Applet v4.0/QSCD Security Target
Page 64 of 73
• FDP_ACF.1/Signature_creation: It is a requirement about access control and authentication,
the access control is provided by TSF.AccessControl, the authentication control is provided by
TSF.Authenticate.
• FIA_AFL.1 The requirement is about to detect when an administrator configurable positive
integer unsuccessful authentication attempts occur related to consecutive failed authentication
attempts and after that block the RAD. It is provided by TSF.Authenticate and
TSF.AccessControl.
• FIA_UID.1: The requirement is about identification and authentication, what shall be accessed
before and after it. It is realized by TSF.AccessControl.
• FIA_UAU.1: The requirement is about authentication, and what can be accessed before and
after it. It is realized by TSF.AccessControl.
• FMT_MOF.1: This SFR requires the access control to signature-creation to the signatory and is
realized TSF.AccessControl. TSF.Authenticate, and TSF.SecureManagement.
• FMT_MSA.1/Admin: Requires that the SCD/SVD generation SFP to modify query the SCD/SVD
management to the Administrator. It is realized by TSF.AccessControl. TSF.Authenticate, and
TSF.SecureManagement.
• FMT_MSA.1/Signatory: Requires access control restrictions to modify the SCD operational
security attributes to the signatory. This is realized by TSF.AccessControl. TSF.Authenticate,
and TSF.SecureManagement.
• FMT_MSA.3: Requires the capability to perform authentication controls. This is realized by
TSF.AccessControl, TSF.Authenticate and TSF.SecureManagement.
• FMT_MTD.1/Admin This SFR requires RAD creation to the Signatory. It is realized by
TSF.AccessControl, TSF.Authenticate and TSF.SecureManagement
• FMT_MTD.1/Signatory: This SFR requires RAD modification to the Signatory. It is realized by
TSF.AccessControl, TSF.Authenticate and TSF.SecureManagement.
• FMT_SMR.1: Requires the maintenance of security roles, this is realized by
TSF.AccessControl, the authentication control is provided by TSF.Authenticate.
7.1.2. TSF.Authenticate
This TSF manages the identification and authentication of the Signatory and Administrator and enforces
role separation (FMT_SMR.1)
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 Platform contains a deterministic random number generator rated DRG.3 (high) according to AIS20
that provides random numbers used for the authentication.
The TSF.Authenticate provides the following authentication mechanism:
Compliance to [22], [23] and [29]:
• User verification
• Device authentication mechanism:
o Device authentication with privacy protection
o Symmetric authentication mechanism
• Role authentication
o Symmetric role authentication
o Asymmetric authentication based on RSA
Compliance to [27] and [12]:
• PACE
• Terminal Authentication
• Chip Authentication
The IDentity Applet is highly configurable according to the user’s needs. In current ST, the
TSF.Authenticate enforces to configure in the Personalisation phase of Applet life cycle and implement
in the Operational phase authentication mechanism as the follows:
Authentication of Signatory (authenticating the signer as its signatory) either by:
IDentity Applet v4.0/QSCD Security Target
Page 65 of 73
• User verification [29]
To proof the identity of the QSCD:
• Chip Authentication v2 [10];
• Symmetric authentication [23];
• Active Authentication [13];
• Certificate request signature.
Authentication for trusted channel between CGA and QSCD either by:
• Symmetric authentication [23];
• Terminal Authentication v2 [10].
This part of the TSF provides functionality for the following SFRs:
• FDP_ACF.1/SCD/SVD_Generation: It is a requirement about access control and authentication
(for details see the SFR), the access control is provided by TSF.AccessControl, the
authentication control is provided by TSF.Authenticate.
• FDP_ACF.1/SVD_Transfer: It is a requirement about access control and authentication (for
details see the SFR), the access control is provided by TSF.AccessControl, the authentication
control is provided by TSF.Authenticate.
• FDP_ACF.1/Signature_creation: It is a requirement about access control and authentication (for
details see the SFR), the access control is provided by TSF.AccessControl, the authentication
control is provided by TSF.Authenticate.
• FIA_AFL.1 The requirement is about to detect when an administrator configurable positive
integer unsuccessful authentication attempts occur related to consecutive failed authentication
attempts and after that block the RAD. It is provided by TSF.Authenticate and
TSF.AccessControl.
• FIA_API.1: The requirement is about identification and authentication and it is realized by
TSF.Authenticate, TSF.CryptoKey and TSF.Platform. It requires security mechanisms to
identify and to authenticate themselves as QSCD (Authentication Proof of Identity).
• FMT_SMR.1: Requires the maintenance of security roles, this is realized by
TSF.AccessControl, the authentication control is provided by TSF.Authenticate.
• FMT_SMF.1: Requires the capability to perform management functions. It is realized by
TSF.Authenticate and TSF.SecureManagement.
• FMT_MOF.1: This SFR requires the access control to signature-creation to the signatory and is
realized TSF.AccessControl. TSF.Authenticate, and TSF.SecureManagement.
• FMT_MSA.1/Admin: Requires that the SCD/SVD generation SFP to modify query the SCD/SVD
management to the Administrator. It is realized by TSF.AccessControl. TSF.Authenticate, and
TSF.SecureManagement.
• FMT_MSA.1/Signatory: Requires access control restrictions to modify the SCD operational
security attributes to the signatory. This is realized by TSF.AccessControl. TSF.Authenticate,
and TSF.SecureManagement.
• FMT_MSA.2 The requirement is about the necessary authentication to change the security
attributes of SCD/SVD management and SCD operation values. It is provided by
TSF.Authenticate and TSF.SecureManagement and TSF.Platform.
• FMT_MSA.3: Requires the capability to perform authentication controls. This is realized by
TSF.AccessControl, TSF.Authenticate and TSF.SecureManagement.
• FMT_MSA.4: Requires the capability to differentiate between actions made by certain users. It
is realized by TSF.Authenticate and TSF.SecureManagement.
• FMT_MTD.1/Admin This SFR requires RAD creation to the Signatory. It is realized by
TSF.AccessControl, TSF.Authenticate and TSF.SecureManagement
FMT_MTD.1/Signatory: This SFR requires RAD modification to the Signatory. It is realized by
TSF.AccessControl, TSF.Authenticate and TSF.SecureManagement.
7.1.3. TSF.SecureManagement
All security attributes are modified in a secure way so that no unauthorised modifications are possible.
IDentity Applet v4.0/QSCD Security Target
Page 66 of 73
The TSF.SecureManagement is responsible for the secure management of the security attributes, data
and functions
This part of the TSF provides functionality for the following SFRs:
• FMT_SMF.1: Requires the capability to perform management functions. It is realized by
TSF.Authenticate and TSF.SecureManagement.
• FMT_MOF.1: This SFR requires the access control to signature-creation to the signatory and is
realized TSF.AccessControl. TSF.Authenticate, and TSF.SecureManagement.
• FMT_MSA.1/Admin: Requires that the SCD/SVD generation SFP to modify query the SCD/SVD
management to the Administrator. It is realized by TSF.AccessControl. TSF.Authenticate, and
TSF.SecureManagement.
• FMT_MSA.1/Signatory: Requires access control restrictions to modify the SCD operational security
attributes to the signatory. This is realized by TSF.AccessControl. TSF.Authenticate, and
TSF.SecureManagement.
• FMT_MSA.2 The requirement is about the necessary authentication to change the security
attributes of SCD/SVD management and SCD operation values. It is provided by TSF.Authenticate
and TSF.SecureManagement and TSF.Platform.
• FMT_MSA.3: Requires the capability to perform authentication controls. This is realized by
TSF.AccessControl, TSF.Authenticate and TSF.SecureManagement.
• FMT_MSA.4: Requires the capability to differentiate between actions made by certain users. It is
realized by TSF.Authenticate and TSF.SecureManagement.
• FMT_MTD.1/Admin This SFR requires RAD creation to the Signatory. It is realized by
TSF.AccessControl, TSF.Authenticate and TSF.SecureManagement
FMT_MTD.1/Signatory: This SFR requires RAD modification to the Signatory. It is realized by
TSF.AccessControl, TSF.Authenticate and TSF.SecureManagement.
7.1.4. TSF.TrustedChannel
The TSF is responsible for the command and response exchanges between the TOE and the external
devices (e.g. CGA).
The cases when the TOE uses trusted channel are the following:
- SVD export (ENC+MAC)
- data Authentication with Identity of Guarantor
- communication with the HID to protect VAD
- communication with the SCA to protect DTBS
This function is responsible for confidentiality, data integrity and data authenticity. It provides
functionality for:
• FTP_ITC.1/SVD: This requirement is about the Trusted Channel which is provided by the
TSF.TrustedChannel and TSF.Platform.
• FTP_ITC.1/VAD This requirement is about the Trusted Channel which is provided by the
TSF.TrustedChannel and TSF.Platform.
• FTP_ITC.1/DTBS This requirement is about the Trusted Channel which is provided by the
TSF.TrustedChannel and TSF.Platform.
7.1.5. TSF.CryptoKey
TSF.CryptoKey is responsible for providing cryptographic support to all the other TSF including secure
key generation (SCD/SVD key pair), digital signature creation. In addition, it provides secure key
destruction method.
It provides functionality for:
• FCS_CKM.1: The SFR requires generation of cryptographic keys. It is realized by
TSF.CryptoKey and TSF.Platform.
IDentity Applet v4.0/QSCD Security Target
Page 67 of 73
• FCS_CKM.4: Requires the cryptographic key destruction according to a specified cryptographic
method. This is realized by TSF.CryptoKey and TSF.Platform.
• FCS_COP.1.: Requires a use of cryptographic operation. It is provided by TSF.CryptoKey and
TSF.Platform.
• FDP_DAU.2/SVD: The requirement is about to generate evidence that can be used as a
guarantee of the validity of SVD for the CGA. It is realized by the TSF.CryptoKey and
TSF.Platform.
• FDP_SDI.2/DTBS: Requires data integrity monitoring and prohibits the use of altered data. It is
provided by TSF.CryptoKey, TSF.AppletparameterSign and TSF.Platform.
FIA_API.1: The requirement is about identification and authentication and it is realized by
TSF.Authenticate, TSF.CryptoKey and TSF.Platform. It requires security mechanisms to identify and to
authenticate themselves as QSCD (Authentication Proof of Identity)
7.1.6. TSF.AppletparameterSign
During the IDentity Applet life cycle phases after LOADED state of the IDentity Applet the IDentity Applet
becomes the default Application and reaches SELECTABLE state of IDentity Applet. This phase is
called the Configuration phase of IDentity Applet. During this phase, the following steps are carried out:
• Applet configuration;
• File creation (all control parameters);
• Object creation (all control parameters and some usage parameters).
Certain configuration and control parameters are signed, and this signature is verified before closing the
Configuration phase of the Identity Applet. Only the unsigned parameters can be changed later in the
Initialization phase. This way only those Application Profiles can be applied which are validated by the
Developer and conform to the requirements. The Configuration phase cannot be finished by reaching
the CONFIGURED state of IDentity Applet, and the Initialization phase of IDentity Applet cannot be
started without successful signature verification. The lifecycle of the IDentity Applet and its details can
be found in the [5].
These signatures can be verified during the whole IDentity Applet life-cycle, thus the non-authorized
changed become detectable by applying this TSF.
The TSF provides functionality for the following SFRs:
• FDP_SDI.2/DTBS: Requires data integrity monitoring and prohibits the use of altered data. It is
provided by TSF.CryptoKey, TSF.AppletparameterSign and TSF.Platform.
• FPT_FLS.1: The requirement requires the preservation of a secure state when detecting
failures. This is provided by TSF.AppletparameterSign and TSF.Platform.
• FPT_TST.1: Requires self-test and capability to verify integrity of TSF and TSF data. This is
provided by TSF.AppletparameterSign and TSF.Platform
7.1.7. TSF.Platform
This TSF provides functionalities (such as CryptoLibrary, random number generation, etc.) to the
followings:
• generate SCD/SVD key pair;
• support digital signature generation
• provide secure key destruction method functionality;
• provide mechanism to generate random numbers (DRG.3 (high));
• prohibit the use of the altered persistent data and inform the S.Sigy about integrity error;
• insure that the TOE shall not emit variations in power consumption or timing during command
execution in excess of non-useful information enabling access to secret data;
• insure that any previous information content of a resource is made unavailable upon the
deallocation of the resource from the objects of session keys and ephemeral private key;
• insure that unauthorized are unable to use electrical contacts interface to gain access to secret
data;
IDentity Applet v4.0/QSCD Security Target
Page 68 of 73
• preserve a secure state when exposure to operating conditions causing a TOE malfunction or
failure is detected during self-tests;
• implements appropriate measures to continuously counter physical manipulation and physical
probing;
• run a suite of self-tests to demonstrate the correct operation of the TSF and to verify the integrity
of the TSF data and stored TSF executable code.
The Platform provides the following security functionality:
• SF.JCVM Java Card Virtual Machine
• SF.OPEN Card Content Management
• SF.CRYPTO Cryptographic Functionality
• SF.RNG Random Number Generator
• SF.DATA_STORAGE Secure Data Storage
• SF.OM Java Object Management
• SF.PIN PIN Management
• SF.PERS_MEM Persistent Memory Management
• SF.EDC Error Detection Code API
• SF.HW_EXC Hardware Exception Handling
• SF.SMG_NSC No Side-Channel
These provide functionality for the following SFRs:
• FCS_CKM.1: The SFR requires generation of cryptographic keys. It is realized by
TSF.CryptoKey and TSF.Platform.
• FCS_CKM.4: Requires the cryptographic key destruction according to a specified cryptographic
method. This is realized by TSF.CryptoKey and TSF.Platform.
• FCS_COP.1: Requires a use of cryptographic operation. It is provided by TSF.CryptoKey and
TSF.Platform.
• FDP_DAU.2/SVD: The requirement is about to generate evidence that can be used as a
guarantee of the validity of SVD for the CGA. It is realized by the TSF.CryptoKey and
TSF.Platform.
• FDP_RIP.1: This requirement is about to make unavailable any previous information content of
SCD. It is provided by TSF.Platform
• FDP_SDI.2/Persistent: Requires data integrity monitoring and prohibits the use of altered data.
It is provided by TSF.Platform.
• FDP_SDI.2/DTBS: Requires data integrity monitoring and prohibits the use of altered data. It is
provided by TSF.CryptoKey, TSF.AppletparameterSign and TSF.Platform.
• FDP_UIT.1/DTBS: The requirement is about the protection of the DTBS against modification
and insertion.
• FIA_API.1: The requirement is about identification and authentication and it is realized by
TSF.Authenticate, TSF.CryptoKey and TSF.Platform. It requires security mechanisms to
identify and to authenticate themselves as QSCD (Authentication Proof of Identity).
• FMT_MSA.2 The requirement is about the necessary authentication to change the security
attributes of SCD/SVD management and SCD operation values. It is provided by
TSF.Authenticate and TSF.SecureManagement and TSF.Platform.
• FPT_EMS.1: Requires that the TOE does not emit variations in power consumption or timing
during command execution and ensures that unauthorized users are unable to use the electrical
contact interface to gain access to RAD and SCD. This is mainly realized with TSF.Platform,
together with the following of JavaCard platform guidelines.
• FPT_FLS.1: The requirement requires the preservation of a secure state when detecting
failures. This is provided by TSF.AppletparameterSign and TSF.Platform.
• FPT_PHP.1: Requires detection of physical attack. This is realized by TSF.Platform.
• FPT_PHP.3: Requires resistance to physical manipulation and probing to the Platform. This is
realized by the TSF.Platform.
• FPT_TST.1: Requires self-test and capability to verify integrity of TSF and TSF data. This is
provided by TSF.AppletparameterSign and TSF.Platform.
IDentity Applet v4.0/QSCD Security Target
Page 69 of 73
• FTP_ITC.1/SVD: This requirement is about the Trusted Channel which is provided by the
TSF.TrustedChannel and TSF.Platform.
• FTP_ITC.1/VAD This requirement is about the Trusted Channel which is provided by the
TSF.TrustedChannel and TSF.Platform.
• FTP_ITC.1/DTBS This requirement is about the Trusted Channel which is provided by the
TSF.TrustedChannel and TSF.Platform.
7.2. Fulfilment of the SFRs
TOE SFR / Security Function
TSF.AccessControl
TSF.Authenticate
TSF.SecureManagement
TSF.TrustedChannel
TSF.CryptoKey
TSF.AppletparameterSign
TSF.Platform
FCS_CKM.1 - - - - X - X
FCS_CKM.4 - - - - X - X
FCS_COP.1 - - - - X - X
FDP_ACC.1/Signature_Creation X - - - - - -
FDP_ACC.1/SCD/SVD_Generation X - - - - - -
FDP_ACF.1/SCD/SVD_Generation X X - - - - -
FDP_ACC.1/SVD_Transfer X - - - - - -
FDP_ACF.1/SVD_Transfer X X - - - - -
FDP_ACF.1/Signature_creation X X - - - - -
FDP_DAU.2/SVD - - - - X X
FDP_RIP.1 - - - - - X
FDP_SDI.2/Persistent - - - - - - X
FDP_SDI.2/DTBS - - - - X X X
FDP_UIT.1/DTBS - - - - - - X
FIA_AFL.1 X X - - - -
FIA_UID.1 X - - - - - -
FIA_UAU.1 X - - - - - -
FIA_API.1 - X - - X - X
IDentity Applet v4.0/QSCD Security Target
Page 70 of 73
FMT_SMR.1 X X - - - - -
FMT_SMF.1 X X - - - -
FMT_MOF.1 X X X - - - -
FMT_MSA.1/Admin X X X - - - -
FMT_MSA.1/Signatory X X X - - - -
FMT_MSA.2 - X X - - - X
FMT_MSA.3 X X X - - - -
FMT_MSA.4 - X X - - - -
FMT_MTD.1/Admin X X X - - - -
FMT_MTD.1/Signatory X X X - - - -
FPT_EMS.1 - - - - - - X
FPT_FLS.1 - - - - - X X
FPT_PHP.1 - - - - - - X
FPT_PHP.3 - - - - - - X
FPT_TST.1 - - - - - X X
FTP_ITC.1/SVD - - - X - - X
FTP_ITC.1/VAD - - - X - - X
FTP_ITC.1/DTBS - - - X - - X
11. Table Mapping of SFRs to mechanisms of TOE
7.2.1. Correspondence of SFR and TOE mechanisms
Each TOE security functional requirement is implemented by at least one TOE mechanism. In section
7.1 the implementing of the TOE security functional requirement is described in form of the TOE
mechanism.
IDentity Applet v4.0/QSCD Security Target
Page 71 of 73
8. Glossary and Acronyms
For Glossary and Acronyms please refer to the corresponding section of [18], [19] and [20])
IDentity Applet v4.0/QSCD Security Target
Page 72 of 73
9. Bibliography
[1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
General Model; CCMB-2017-04-001, Version 3.1, Revision 5, April 2017
[2] Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional
Components; CCMB-2017-04-002, Version 3.1, Revision 5, April 2017
[3] Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Requirements; CCMB-2017-04-003, Version 3.1, Revision 5, April 2017
[4] Common Methodology for Information Technology Security Evaluation, Evaluation
Methodology; CCMB-2017-04-004, Version 3.1, Revision 5, April 2017
[5] IDentity Applet Suite v4.0 Administrator’s Guide
[6] IDentity Applet Suite v4.0 User’s Guide
[7] JCOP 4.5 P71 Security Target Lite, Rev. 2.9, 5 September 2025
[8] Supporting Document Mandatory Technical Document Composite product evaluation for
Smart Cards and similar devices; Version 1.5.1, May 2018
[9] BSI TR-03110-1 Advanced Security Mechanisms for Machine Readable Travel Documents –
Part 1 eMRTDs with BAC/PACEv2 and EACv1 - Version 2.20 26., February 2015
[10]BSI TR-03110-2 Advanced Security Mechanisms for Machine Readable Travel Documents –
Part 2 Protocols for electronic Identification, Authentication and trust Services (eIDAS) -
Version 2.21, 21. December 2016
[11]BSI TR-03110-3 Advanced Security Mechanisms for Machine Readable Travel Documents –
Part 3 Common Specifications – Version 2.2121. December 2016
[12]BSI TR-03110-4 Advanced Security Mechanisms for Machine Readable Travel Documents –
Part 4 Applications and Document Profiles – Version 2.21, 21. December 2016
[13]International Civil Aviation Organization (ICAO) Doc 9303 Machine Readable Travel
Documents, Seventh Edition, 2015
[14]International Civil Aviation Organization (ICAO) Supplemental Access Control for Machine
Readable Travel Documents, Version – 1.1, 15. April 2014
[15]Protection Profile — Machine Readable Travel Document with ICAO Application and Basic
Access Control (MRTD-PP), Version 1.10, BSI-CC-PP-0055, 25.03.2009
[16]Protection Profile — Machine Readable Travel Document with ICAO Application, Extended
Access Control with PACE (EAC PP), Version 1.3.2, BSI-CC-PP-0056-V2-2012, 05.12.2012
[17]Protection Profile — Machine Readable Travel Document using Standard Inspection
Procedure with PACE (PACE PP), Version 1.0, BSI-CC-PP-0068-V2-2011, 02.11.2011
[18]EN 419211-2:2013 — Protection profiles for secure signature creation device — Part 2:
Device with key generation
IDentity Applet v4.0/QSCD Security Target
Page 73 of 73
[19]EN 419211-4:2013 — Protection profiles for secure signature creation device — Part 4:
Extension for device with key generation and trusted channel to certificate generation
application
[20]EN 419211-5:2013 - Protection profiles for secure signature creation device - Part 5:
Extension for device with key generation and trusted channel to signature creation application
[21]BSI: Common Criteria Protection Profile - Machine-Readable Electronic Documents based on
BSI TR-03110 for Official Use [MR.ED-PP], BSI-CC-PP-0087 version 1.01, May 20th, 2015
[22]CEN/TS 15480-2 – Identification card systems - European Citizen Card - Part 2: Logical data
structures and card services
[23]European Card for e-Services and National e-ID Applications - IAS ECC, Revision 1.0.1,
21.03.2008
[24]Regulation (EU) No 910/2014 of the European Parliament and of the Council of 23 July 2014
on electronic identification and trust services for electronic transactions in the internal market
and repealing Directive 1999/93/EC [2014] OJ L 257/73
[25]Published by Oracle. Java Card 3 Platform, Application Programming Interface, Classic
Edition, Version 3.0.5., May 2015.
[26]Bundesamt für Sicherheit in der Informationstechnik (BSI), Technical Guideline TR-03111
Elliptic Curve Cryptography, TR-03111, Version 2.0 28.06.2012
[27]BSI Technische Richtlinie TR-03117 eCards mit kontaktloser Schnittstelle als sichere
Signaturerstellungseinheit version 1.0
[28]JCOP 4.5 P71, User manual for JCOP 4.5 P71, User Guidance and Administrator Manual,
NXP Semiconductors, Rev. 2.2 – 2025-06-05.
[29]Technical report – Signature creation and administration for eIDAS token Part 1. Functional
Specification – version 1.0, 2015.07.21
[30]Protection Profile for ePassport IC with SAC (BAC+PACE) and Active Authentication, version
1.0, March 8,2016, Passport Division, Consular Affairs Bureau, Ministry of Foreign Affairs of
Japan
[31]Protection Profile for ePassport IC with SAC (PACE) and Active Authentication, version 1.0,
March 8,2016, Passport Division, Consular Affairs Bureau, Ministry of Foreign Affairs of Japan
[32]ETSI TS 119 312 V1.5.1 (2024-12), Electronic Signatures and Trust Infrastructures (ESI);
Cryptographic Suites