Copyright 2010 © 1 FQR 110 4773 Ed3
Euterpe - IAS ECC v1.0.1 R1
Public Security target
June 10th
2010
Copyright 2010 © 1 FQR 110 4773 Ed3
Table of contents
1. INTRODUCTION ................................................................................................................................ 3
1.1. SECURITY TARGET REFERENCE ...................................................................................................... 3
1.2. REFERENCES ................................................................................................................................. 3
1.3. ABBREVIATIONS.............................................................................................................................. 4
2. TARGET OF EVALUATION DESCRIPTION..................................................................................... 6
2.1. TARGET OF EVALUATION OVERVIEW ............................................................................................... 6
2.1.1. TOE type ................................................................................................................................................6
2.1.2. Logical scope........................................................................................................................................7
2.1.3. Physical scope ......................................................................................................................................8
2.1.3.1. Case 1...........................................................................................................................................8
2.1.3.2. Case 2...........................................................................................................................................9
2.1.3.3. Physical overview......................................................................................................................9
2.1.4. Usage and major security features of the TOE.......................................................................................9
2.2. TARGET OF EVALUATION REFERENCE ........................................................................................... 11
2.3. DESCRIPTION OF THE EMBEDDED SOFTWARE................................................................................. 13
2.3.1. Description of data structure ................................................................................................................13
2.3.1.1. File and File System ...................................................................................................................13
2.3.1.2. Security Environment .................................................................................................................15
2.3.1.3. Security data Objects ..................................................................................................................16
2.3.2. Access Control Management................................................................................................................17
2.3.3. Authentication of entities .....................................................................................................................17
2.3.4. eServices...............................................................................................................................................18
2.3.5. Administration of the TOE...................................................................................................................18
2.3.6. Single Sign on feature (SSO) ...............................................................................................................19
2.3.7. Scope of evaluation ..............................................................................................................................20
2.4. INTENDED USAGE ......................................................................................................................... 20
2.5. LIFE CYCLE.................................................................................................................................. 21
2.5.1. Description of the TOE Environment...................................................................................................23
2.5.2. Development environment ...................................................................................................................23
2.5.2.1. Software development (phase 1).................................................................................................23
2.5.2.2. Hardware development (Phase 2) ...............................................................................................24
2.5.3. Production environment .......................................................................................................................24
2.5.3.1. Javacard open platform manufacturing (phase 3) .......................................................................24
2.5.3.2. Javacard open platform (JOP) packaging and initialization (phase 4)........................................25
2.5.3.3. Javacard open platform (JOP) pre-personnnalization (phase 5) .................................................25
2.5.4. Operational environment......................................................................................................................28
2.5.4.1. TOE personalization (phase 6)....................................................................................................29
2.5.4.2. TOE Usage (phase 7)..................................................................................................................29
2.5.5. Coverage of the different Life cycle state by the assurance components AGD & ALC.......................29
2.5.6. State of the TOE depending on the phase.............................................................................................30
2.5.7. Mapping with the life cycle and Subjects described in [SSCD2] and [SSCD3]...................................31
3. TARGET OF EVALUATION SECURITY ENVIRONMENT ............................................................. 34
3.1. REMOTE IT ENTITY ....................................................................................................................... 34
3.2. SUBJECTS.................................................................................................................................... 35
3.3. USER DATA .................................................................................................................................. 37
3.4. TSF DATA .................................................................................................................................... 38
3.5. ASSUMPTION................................................................................................................................ 40
3.5.1. Standard Assumption ...........................................................................................................................40
Copyright 2010 © 2 FQR 110 4773 Ed3
3.5.2. Complementary Assumption................................................................................................................40
3.6. THREATS...................................................................................................................................... 40
3.6.1. Standard threats....................................................................................................................................40
3.6.2. Complementary threats.........................................................................................................................41
3.7. ORGANIZATIONAL SECURITY POLICIES............................................................................................ 42
3.7.1. Standard organizational security policies.............................................................................................42
3.7.2. Complementary organizational security policies..................................................................................43
3.8. SECURITY OBJECTIVES FOR THE TOE ........................................................................................... 44
3.8.1. Standard security objectives of the TOE ..............................................................................................44
3.8.2. Complementary security objectives of the TOE...................................................................................45
3.9. SECURITY OBJECTIVES FOR THE ENVIRONMENT ............................................................................. 47
3.9.1. Standard security objectives of the Environment .................................................................................47
3.9.2. Complementary security objectives of the Environment......................................................................48
3.10. TOE SECURITY FUNCTIONAL REQUIREMENTS................................................................................. 50
3.10.1. FCS: CRYPTOGRAPHIC SUPPORT.................................................................................................50
3.10.2. FDP : USER DATA PROTECTION....................................................................................................54
3.10.3. FIA: IDENTIFICATION AND AUTHENTICATION........................................................................72
3.10.4. FMT: SECURITY MANAGEMENT ..................................................................................................75
3.10.5. FPT: PROTECTION OF THE TSF......................................................................................................78
3.10.6. FTP: TRUSTED PATH/CHANNELS .................................................................................................80
4. TOE SUMMARY SPECIFICATION.................................................................................................. 82
4.1. SECURITY FUNCTION OF THE TOE................................................................................................. 82
4.1.1. Security functions provided by the javacard open platform.................................................................82
4.1.2. Security functions added by the composite TOE .................................................................................83
4.2. SECURITY ASSURANCE REQUIRMENTS ........................................................................................... 88
4.2.1. Evaluation Assurance Level rationale ..................................................................................................88
4.2.2. ADV : Development.............................................................................................................................89
4.2.3. AGD : Guidance...................................................................................................................................89
4.2.4. ALC : Life Cycle..................................................................................................................................89
4.2.5. ASE : Security target............................................................................................................................89
4.2.6. ATE : Tests...........................................................................................................................................90
4.2.7. VAN : Vulnerability Analysis..............................................................................................................90
4.3. EAL AUGMENTATIONS RATIONALE ................................................................................................. 90
4.3.1. AVA_VAN.5 Advanced methodical vulnerability analysis.................................................................90
4.3.2. ALC_DVS.2 Sufficiency of security measures....................................................................................91
5. CONFORMANCE CLAIMS .............................................................................................................. 91
5.1. CONFORMANCE CLAIM TO CC....................................................................................................... 91
5.2. PROTECTION PROFILE REFERENCE................................................................................................ 91
5.3. CONFORMANCE CLAIM RATIONALE................................................................................................. 91
5.3.1. Rationale for TOE objectives...............................................................................................................92
5.3.2. Rationale for threats .............................................................................................................................92
5.3.3. Rationale for Assumptions ...................................................................................................................93
5.3.4. Rationale for Organisational Security Policies.....................................................................................93
5.3.5. Rationale for Environment objectives ..................................................................................................94
5.3.6. Rationale for Security requirments.......................................................................................................94
5.4. SECURITY OBJECTIVES RATIONALE................................................................................................ 95
6. ANNEX A : EXTENDED FAMILY .................................................................................................. 101
6.1. DEFINITION OF FPT_EMSEC ..................................................................................................... 101
6.2. DEFINITION OF FCS_RNG.......................................................................................................... 102
Copyright 2010 © 3 FQR 110 4773 Ed3
1. Introduction
1.1. Security Target Reference
The Security target is identified as follows:
Title: EUTERPE – Public Security target
Reference: FQR 110 4473 edition 3
Editor: Oberthur Technologies
CC version: 3.1 revision 2
EAL: EAL4 augmented with AVA_VAN.5 and ALC_DVS.2
1.2. References
[SSCD2]
Secure Signature-Creation Device Type2, 1.04, EAL
4+
[SSCD3]
Secure Signature-Creation Device Type3, 1.05, EAL
4+
[AGD_PRE]
FQR 110 4511 Ed8
Euterpe – AGD_PRE
[AGD_OPE]
FQR 110 4527 Ed7
Euterpe – AGD_OPE
[AGD_PRE_CLIO/THALIE] FQR 110 4379 Ed6
[AGD_OPE_ CLIO/THALIE] FQR 110 4483 Ed5
FQR 110 4730 Ed1
[PP9911]
Smart Card Integrated Circuit With Embedded
Software Protection Profile, version 2.0, June 1999.
Certified under the reference PP/9911, DCSSI
[AIS31]
Anwendungshinweise und Interpretationen zum
Schema, AIS31: Funktionalitätsklassen und
Evaluationsmethodologie für physikalische
Zufallszahlengeneratoren, Version 1, 25.09.2001,
Copyright 2010 © 4 FQR 110 4773 Ed3
Bundesamt für Sicherheit in der Informationstechnik
[FIPS180-2]
FIPS PUB 180-2, Secure Hash Standard", August
2002 , National Institute of Standards and Technology
[CC31-1]
Common Criteria for information Technology
Security Evaluation, Part 1: Introduction and general
model", September 2006, Version 3.1 revision 1
[CC31-2]
Common Criteria for information Technology
Security Evaluation, Part 2: Security Functional
requirements", September 2007, Version 3.1 revision 2
[CC31-3]
Common Criteria for information Technology
Security Evaluation, Part 3: Security Assurance
requirements", September 2007, Version 3.1 revision 2
[PKCS#1]
PKCS#1 The public Key Cryptography standards,
RSA Data Security Inc. 1993
[PKCS#3] PKCS#3
[IASECC] IAS ECC v1.0.1
[ISO7816-4]
Identification Cards _ Integrated Circuits Card _ Part
4 : Organisation, security and commands for
interchange : 2005
[ST_CLIO/THALIE]
ID One Cosmo v7.0 – Clio Security Target
Depending on the IC :
FQR 110 4621 Ed 1
FQR 110 4626 Ed 1
FQR 110 4627 Ed 1
ID One Cosmo v7.0 – Thalie Security Target
FQR 110 4635 Ed2
[GP] Card Specification - Version 2.1.1 - Mars, 2003
1.3. Abbreviations
ADF Application Dedicated File
AES Advanced Encryption Standard
AID Application Identifier
Copyright 2010 © 5 FQR 110 4773 Ed3
AMB Access Mode Byte
APDU Application Protocol Data Unit (command received/Data
sent by the chip)
API Application Programming Interfaces
CA Certification authority
CBC Cipher Block Chaining
CGA Certificate Generation Authority (Authority in charge of
generating the qualified certificate(s) )
C/S Client / Server
CSE Current Security Environment
DAP Data Authentication Pattern (enable to ensure integrity &
authenticity of javacard package when loaded)
DAPP Device Authentication with Privacy Protection
DES Data Encryption Standard
DF Dedicated File
DH Diffie Hellman
DTBS Data to be signed (Sent by the SCA)
DTBS Representation Representation of the Data to be signed
EAL Evaluation Assurance Level
EF Elementary File
EEPROM Electrically Erasable Programmable Read Only Memory
FID File identifier
GP Global Platform
HI Human Interface (used to enter the RAD and VAD by the
user)
IC Integrated Chip
ICC Integrated Chip card
IFD Interface Device
MAC Message Authentication code
PIN Personal Identification Number
PKI Public Key Infrastructure
RAD Reference Authentication Data (PIN stored)
RCA Root Certification Authority
ROM Read Only Memory
Copyright 2010 © 6 FQR 110 4773 Ed3
RSA Rivest Shamir Adleman
RSA CRT Rivest Shamir Adleman – Chinese Remainder Theorem
SCA Signature creation Application (Application requiring a
qualified signature to the chip)
SCB Security Condition Byte
SCD Signature Creation Data (Signature key)
SCP Secure Channel Procotol
SDO Security Data Object
SE Security Environment
SHA Secure hashing Algorithm
SSCD Secure Signature Creation Device
SSE Static Security Environment
SSESP Static Security Environment for Security Policies
SSO Single Sign On
SVD Signature Verification Data (Signature Verification key)
TOE Target of evaluation
URL Uniform Resource Locator
USB Universal Serial Bus
VAD Verification Authentication Data (PIN submitted by the
holder)
XML eXtensible Markup Language
2. Target Of Evaluation Description
2.1. Target Of Evaluation Overview
2.1.1. TOE type
The Target of Evaluation is an embedded software made of
• a javacard Applet ([Applet]) developed by Oberthur Technologies
• a javacard API ([API]) developed by Oberthur Technologies
• a javacard Interface ([ Interface]) developed by Oberthur Technologies
Composed with a javacard open platform developed by Oberthur Technologies on
which it is running.
Copyright 2010 © 7 FQR 110 4773 Ed3
2.1.2. Logical scope
As the underlying javacard open platform is certified as an javacard open platform, any
other javacard applet (s) may be loaded on the javacard open platform provided it
fulfills the recommendations indicated in the guidance documentation of the javacard
open platform ([AGD_PRE_CLIO/THALIE] and [AGD_OPE_CLIO/THALIE]) and of
the composite TOE ([AGD_PRE] and [AGD_OPE]). As a consequence, it (they) will not
endanger the results of the current evaluation. However, this (these) applet(s) will not
be part of the Target of Evaluation (TOE).
The logical scope of the TOE may be depicted as follows:
Javacard Open Platform
[API] [Interface]
[Applet]
Applet 1 Applet n
TOE
Limits of the TOE
Copyright 2010 © 8 FQR 110 4773 Ed3
2.1.3. Physical scope
The TOE may have two physical representations
2.1.3.1. Case 1
It may be made of two parts
• the javacard open platform [CLIO] with the card manager in state OP_READY,
INITIALIZED or SECURED with the DAP verification enforced..
• the cap files of the javacard packages protected with their DAP signature
The javacard open platform is self protected as it requires the authentication of its user
prior to any action (throught a GP authentication).
Copyright 2010 © 9 FQR 110 4773 Ed3
The Card Manager with DAP verification enforced ensures the integrity of the cap files.
The cap files are signed by “Oberthur Technologies” with a DAP private key, and
verified by the javacard open platform with the matching public key when they are
loaded.
2.1.3.2. Case 2
It may be made of the javacard open platform [CLIO] with the card manager in state
OP_READY, INITIALIZED or SECURED on which the the javacard packages have
already been loaded.
2.1.3.3. Physical overview
Once constructed, the TOE is a bare microchip with its external interfaces for
communication.
It may be used on several physical medium
• within an inlay, or eCover
• in a plastic card
• within a USB key
• ….
The physical medium on which the microchip is mounted is not part of the target of
evaluation
2.1.4. Usage and major security features of the TOE
The TOE intended usage is to be used as a “secure signature creation device” of type 2
or 3, with respect to the European regulation EU/1999/93.
Within the framework described by [SSCD2] and [SSCD3], the TOE enables
• to perform electronic qualified signature
• to authenticate the cardholder based on a RAD verification
• to authenticate one (or several) administrator(s) of the TOE, that may have special
rights to administrate the SCD and SVD (generation, import), using either
symmetric and/or asymmetric mechanisms or PIN verification
• to establish a trusted channel, protected in integrity and confidentiality, with
remote entities such as a SCA, a CGA or a SSCD type 1. It may be realized by
means of symmetric and/or asymmetric mechanisms
Copyright 2010 © 10 FQR 110 4773 Ed3
The scope of [SSCD2] and [SSCD3] is extended in several ways:
• A super Administrator has special rights to administrate the signature creation
function, the mode of communication, and the type of cryptographic mechanisms
to use.
• The TOE may hold more than one SCD. Several SCDs may be used by the
holder to sign documents
• SCD/SVD pairs and other cryptographic objects may be generated and/or
imported after issuance at any time according to the access rules required.
• RAD may be created at any time according to the access rules required.
• The TOE may be used to realize digital signature in contact and/or contactless
mode. To do so, the Personalization Agent shall ensure a correct security policy is
applied to each object/data.
• eServices features are added, enabling the cardholder to perform C/S
authentication, Encryption key decipherment….
• A complete access control over object is ensured, whatever their type is : File or
cryptographic objects (PIN, keys,…), ensuring it is not possible to bypass the
access rules.
The security functions the TOE provides are the following:
• SF.PIN_MGT: Management of the PIN. The TOE enable to create, set, change,
reset the PIN both trought APDU commands or by Shared interfaces. In any case,
the same security policy is applied.
• SF.SIG : Management of electronic signature according to the security
requirement of [SSCD2] and [SSCD3]
• SF.DEV_AUTH: provision of cryptographic means to perform mutual
authentication with remote entities such as the SCA, the CGA, the SSCD type 1
and initiate a trusted channel with them. It may use symmetric and asymmetric
scheme.
• SF.ADM_AUTH: provision of cryptographic means to perform authentication of
external entities to grant them some administration rights (on the TOE,
personalization rights, on the SCD management…). It may use symmetric and
asymmetric scheme.
• SF.SM : provision of cryptographic mechanisms to ensure a trusted channel with
remote entities such as the SCA, the CGA, the SSCD type 1
• SF.KEY_MGT: provision of the keys management. It enables to create, import
and generate the SCD and SVD, to export the SVD. It manages as well the
authentications and the eServices keys stored in the TOE and enable their import,
export and generation.
• SF.CONF: provides configuration management of the TOE. It enables to
activate/deactivate the use of hash off card for signature computation, the use of
Copyright 2010 © 11 FQR 110 4773 Ed3
symmetric and/or asymmetric authentication schemes, and the ability to
communicate in contactless mode.
• SF.ESERVICE: provision of eServices. The TOE enables to perform C/S
authentication, encryption key decipherment and certificate verification.
• SF.EAVESDROPPING_PROTECTION: Enforcement of the eavesdropping
protection in contactless mode. When used in contactless mode, the TOE applies
a restrictive security policy ensuring the sensitive data exchanged can not be read
or sent by an unauthenticated entity.
• SF.SAFESTATE_MGT : Insurance of a safe state. The TOE always remains in a
safe state, ensuring the protection of all the assets it contains.
• SF.PHYS: physical protection. The TOE provides protection against tampering
and the assets it stores can not be retrieved or altered by physical manipulation
The TOE is compliant with the specification [IASECC] and may be used for various
applications requiring qualified signature:
• Electronic signature application
• Electronic health card
• Electronic services cards
• ……
Depending on the use case and or the ability of the underlying javacard open platform,
this embedded software may be used
• in contact mode (T=0 and/or T=1 protocol)
• in contactless protocol (T=CL)
• in USB protocol
2.2. Target Of Evaluation Reference
The TOE is identified as follows:
TOE name
(commercial name):
ID-One IAS-ECC v1.0.1 R1
Guidance document
for preparation
FQR 110 4511 Ed8
Guidance document
for use
FQR 110 4527 Ed7
Guidance document
for preparation of
CLIO/THALIE
FQR 110 4379 Ed6
Copyright 2010 © 12 FQR 110 4773 Ed3
Guidance document
for operational user
of CLIO/THALIE
FQR 110 4483 Ed5
FQR 110 4730 Ed1
Software
identification
‘1121’
The TOE is made of a javacard applet [Applet], a javacard interface [Interface], a
javacard API [API] composed with a javacard open platform [JOP] already evaluated.
Name of [Applet]: IAS ECC Java Applet light
Version “V1.2”
Name of [API]: IAS ECC Javacard API
Version “V1.1”
Name of [Interface] Server Applet Manager javacard Interface
Version “V1.2”
Names of [JOP]:
ID-One Cosmo v7.0-a Large Dual
ID-One Cosmo v7.0-a Large
ID-One Cosmo v7.0-a Standard Dual
ID-One Cosmo v7.0-a Standard
ID-One Cosmo v7.0-a USB
ID-One Cosmo V7.0-n Large Dual
ID-One Cosmo V7.0-n Large Contact
ID-One Cosmo V7.0-n Standard Dual
ID-One Cosmo V7.0-n Standard
Certificates
ANSSI-CC-2009-36
(for the ID-One Cosmo v7.0-a Large Dual, ID-One Cosmo v7.0-a Large,
and ID-One Cosmo v7.0-a Standard Dual)
ANSSI-CC-2009-46
(for the ID-One Cosmo v7.0-a Standard)
ANSSI-CC-2009-47
(for the ID-One Cosmo v7.0-a USB)
ANSSI-CC-2009-48
Copyright 2010 © 13 FQR 110 4773 Ed3
(for the ID-One Cosmo v7.0-n range)
2.3. Description of the Embedded software
2.3.1. Description of data structure
The IAS ECC application manages two types of structures:
• The File, compliant with [ISO7816-4]
• The Security Data Objects, that are secure container storing cryptographic data
(PINs, Keys,….)
2.3.1.1. File and File System
The IAS ECC Application handles the following type of file (described in [ISO7816-4]):
• Transparent File - EF
• Application Dedicated File - ADF
• Dedicated File - DF
All these files are organized within a so called File System. It represents the hierarchy
between all the files. This Structure is compliant with [ISO7816-4].
At the top of the structure stands the Root, it is the default selected file at reset. Under
the Root, are located the Application Dedicated File.
Copyright 2010 © 14 FQR 110 4773 Ed3
Root File
Application dedicated
file
Application dedicated
file
dedicated file
dedicated file
Transparent file
Transparent file
Transparent file
Example of FileSystem Structure
Copyright 2010 © 15 FQR 110 4773 Ed3
The ADF and the Root may be selected by Application Identifier (AID) or by File
identifier (FID).
The Root, as well as each ADF and DF, may contain up to 255 files (EF or DF).
The Application enables to
• create, delete, activate, deactivate terminate all type of file (except the Application
dedicated file) to update the File System
• read, update, resize any transparent file (EF)
• Move within the FileStructure by use of file selection.
Each files is characterised by its own attributes, such as :
• Access conditions
• File identifier
• Location within the File System
• Size (for transparent file)
All the action to be performed on file is fully described in [IASECC].
2.3.1.2. Security Environment
The IAS ECC Application handles Security Environments. Three types of Security
Environment may be identified:
• Static Security Environment - SSE
• Static Security Environment for Security Policies – SSESP
• Current Security Environment - CSE
Basically a security environment contains several couple of cryptographic data. Each
cryptographic data contains :
• One or several key identifier : KEY_ID
• an algorithm identifier : ALGO_ID
• a mode of use : USE
These cryptographic data may be used
• to set up a ready to use cryptographic context to perform a cryptographic
operation (for signature, for C/S authentication,…). It is the case of SSE
• to define an access condition to fulfil : the key defined by the identifier KEY_ID
shall be used with the algorithm ALGO_ID and with the mode USE to grant an
access right.. It is the case of the SSESP
Copyright 2010 © 16 FQR 110 4773 Ed3
• to define the current cryptographic context to apply to realize a given service. It
is the case of the CSE. In particular, the CSE may be initialized from a SSE
The SSESP and SSE are attributes of the ADF and are stored in security Data Objects
located within an Application dedicated file (ADF)
The CSE is unique for the TOE at any moment
2.3.1.3. Security data Objects
The IAS ECC Application handles as well cryptographic data objects, called Security
Data Objects (SDO), dedicated to store the keys, the PIN, the Diffie Hellmann
parameters and the Security Environments, as well as their attributes. The following
types of SDO exist
• SDO PIN contains a Personal identification Number
• SDO RSA Public Key contains a RSA Public Key
• SDO RSA Private Key contains a RSA Private Key
• SDO Security Environment contains a Security Environment
• SDO Symmetric Key Set contains a Symmetric Key Set
• SDO Diffie Hellmann parameters contains a set of Diffie Helmann Domain
parameters
They may be located in any Dedicated file (DF) or Application Dedicated file (ADF).
The Application enables to create, update and use any of these SDO. The way the SDO
may be used depends on its type :
• SDO PIN may be changed, reset, verified
• SDO RSA Public Key may be used to verify a certificate
• SDO RSA Private Key may be used to sign, perform a C/S authentication or
decrypt a cryptogram
• SDO Security Environment may be changed, reset, verified
• SDO Symmetric Key Set may be used to verify an external authentication or to
perform a mutual authentication and establish a trusted channel.
• SDO Diffie Hellmann parameters may be used to establish a secure channel
(without authentication)
Each SDO is characterised by its own attributes, such as :
• Access conditions
Copyright 2010 © 17 FQR 110 4773 Ed3
• Location within the File System
• Size
• Type
• Content (Key, PIN or Diffie Hellman Parameters)
• Usage counter and tries counter
• Algorithm to be used
All the action to be performed on file is fully described in [IASECC].
2.3.2. Access Control Management
One of the Core feature of IAS ECC is to provide access condition management on any
access mode of any objects it handles:
• Files
• Security Data Objects
Access condition may be assigned to access mode on any of these objects.
The Access conditions encoding is the compact encoding described in [ISO7816-4],
enhanced as described in [IASECC]. It relies on access rules encoded by means on
Access Mode Bytes (AMB) and Security Conditions Bytes (SCB) described in [ISO7816-
4] and [IASECC].
Priori to any operation, the application checks the requested access rights are fulfilled.
Basically, the Access condition is granted if the security conditions are fulfilled.
Any access condition to fulfil is a combination of security conditions based on identified
keys/PIN/secrets:
• User Authentication (by PIN). May be used to authenticate the cardholder or a
remote administrator.
• Authentication of a remote administrator
• Mutual authentication with a remote IT
• Communication protected in integrity and confidentiality
2.3.3. Authentication of entities
Copyright 2010 © 18 FQR 110 4773 Ed3
The IAS ECC application enables to authenticate several entities to grant them some
rights :
• User Authentication (by PIN). May be used to authenticate the cardholder or a
remote administrator.
• Authentication of a remote administrator (based on symmetric or asymmetric
scheme)
• Mutual authentication with a remote IT and establishment of a trusted channel
protected in integrity and confidentiality (based on symmetric or asymmetric
scheme)
• Personalization Agent authentication (for the phase 6)
• TOE Administrator authentication (in phase 7)
These features of authentication are key factor as they are needed to grant access to
resources (Files or SDO) the IAS ECC application helds.
2.3.4. eServices
The IAS ECC application offers as well eServices features :
• C/S authentication : this feature enable to authenticate the TOE on behalf of the
cardholder’s PC to a remote webserver.
• Digital signature : this feature enable the cardholder to electronically signs
documents. The signature may be either advanced or qualified (compliant with
[SSCD2]and [SSCD3]).
• Encryption key decipherment : this feature enables the cardholder to store secret
data on an electronic vault. The key needed to decipher the key encrypting these
data is securely stored in the TOE. The cardholder’s PC sends the encrypted
encryption key to the TOE to get the plain encryption key.
• Certificate verification : this feature enables the TOE to verify a certificate issued
by a certification authority the TOE trusts. The trust is established by the transfer
to the TOE of a public RSA key of an authority certified by an authority whose
public key is present in the TOE (either permanently stored, either imported
through a certificate). This feature is used when the authentication key of a
remote entity is certified by a Root certification Authority (RCA)
2.3.5. Administration of the TOE
Copyright 2010 © 19 FQR 110 4773 Ed3
The IAS ECC application offers administration services. Upon successful authentication,
the TOE Administrator may modify the following attributes
• Communication medium : the administrator may restrict the ability to
communicate with the TOE in contact and/or contactless mode. If the TOE is to be
used in contactless mode, the TOE issuer shall ensure the security policy applied
to files and SDO is relevant. In particular, there should not be any free readable
data that could be used to track the holder, and any sensitive data shall be
transmitted throught a trusted channel ensuring protection against
eavesdropping.
• Hashing method to be used for digital signature : the administrator may restrict
the ability to perform electronic signature (advanced or qualified) on DTBS-
representation partly computed by the TOE. In such case, the digital signature
will only be done with last round of data hashing done on the TOE.
• Authentication mechanism to be used : the administrator may restrict the
cryptographic means to be used by the TOE to authenticate remote entities
(Administrator or Remote IT) : either symmetric and/or asymmetric
cryptography.
• Identification of the TOE : the administrator is entitled to identify the TOE
2.3.6. Single Sign on feature (SSO)
The IAS ECC application may behave as a Single Sign on (SSO). It provides access
points to any other applet willing to use a PIN stored in the Root. In particular it is
possible to :
• Check a PIN
• Change a PIN
• Reset a PIN
• Retrieve the remaining tries counter
• Retrieve the validation status
This feature is very convenient when the PIN(s) shall be shared with a legacy
application
Even though the IAS ECC application offers these entry points, it does still perform
access control it the same way it does when it receives incoming APDU to manage a
Copyright 2010 © 20 FQR 110 4773 Ed3
PIN. The access conditions on the PINs that are accessed by these entry points are still
enforced.
2.3.7. Scope of evaluation
The scope of evaluation encompasses all the features of the TOE. The File System
management is out of the scope of the evaluation, eventhough the access control
management (common to SDO and File) is covered.
2.4. Intended Usage
The TOE intended usage is to be used as a “secure signature creation device” of type 2
or 3, with respect to the European regulation EU/1999/93.
Within the framework described by [SSCD2] and [SSCD3], the TOE enables
• to perform electronic qualified signature
• to authenticate the cardholder based on a RAD verification
• to authenticate one (or several) administrator(s) of the TOE, that may have special
rights to administrate the SCD and SVD (generation, import), using either
symmetric and/or asymmetric mechanisms or PIN verification
• to establish a trusted channel, protected in integrity and confidentiality, with
remote entities such as a SCA, a CGA or a SSCD type 1. It may be realized by
means of symmetric and/or asymmetric mechanisms
The scope of [SSCD2] and [SSCD3] is extended in several ways:
• A super Administrator has special rights to administrate the signature creation
function, the mode of communication, and the type of cryptographic mechanisms
to use.
• The TOE may hold more than one SCD. Several SCDs may be used by the
holder to sign documents
• SCD/SVD pairs and other cryptographic objects may be generated and/or
imported after issuance at any time according to the access rules required.
• RAD may be created at any time according to the access rules required.
• The TOE may be used to realize digital signature in contact and/or contactless
mode. To do so, the Personalization Agent shall ensure a correct security policy is
applied to each object/data.
Copyright 2010 © 21 FQR 110 4773 Ed3
• eServices features are added, enabling the cardholder to perform C/S
authentication, Encryption key decipherment….
• A complete access control over object is ensured, whatever their type is : File or
cryptographic objects (PIN, keys,…), ensuring it is not possible to bypass the
access rules.
The TOE is compliant with the specification [IASECC] and may be used for various
applications requiring qualified signature:
• Electronic signature application
• Electronic health card
• Electronic services cards
• ……
2.5. Life Cycle
With respect to the Life cycle envisioned in [PP9911], seven different phases may be sorted out.
The life cycle of the composite TOE may be depicted as follows :
Copyright 2010 © 22 FQR 110 4773 Ed3
c
So ftw are dev elo pmen t
ID One C osm o v7.0 X XX
IC d atabase
con stru ctio n
T esting
IC ph oto mask
fabricatio n
micro mod ule
IC
man ufacturing
phase 1
phase 3
phase 2
phase 7
IC testing
phase 4
phase 5
E mbedding
phase 6
T esting
Pre-person alisatio n
T estin g P ersonalisation
Sm artcard p rod uct
E nd-u sage
S martcard
En d of life
Ap plicatio n
E nd -u sag e
A pplication
En d of life
Card printin g
IC M a nufacturer
S oftware
de velo pment
ID On e IAS EC C
Figure 1 : life cycle state of the composite TOE
Copyright 2010 © 23 FQR 110 4773 Ed3
2.5.1. Description of the TOE Environment
The TOE environment may be spitted into two different parts:
• The Development environment, in which the parts of TOE are designed,
tested and manufactured.
• The Production environment, in which the TOE is under construction. The
security requirements of the javacard open platform (JOP) are fulfilled and
assurance levels are met.
• The Operational environment, in which the TOE is self protected and can be
used as stated (personalized and used). Once personalized according to
[AGD_PRE], the TOE is constructed: the security requirements of the TOE
are fulfilled and the assurance levels are met.
2.5.2. Development environment
The development environment encompasses the environment in which the TOE is
developed, i.e
• the javacard open platform components
• the javacard applet and interface
2.5.2.1. Software development (phase 1)
This development environment of the Javacard Applet and javacard open platform
(JOP) is enforced by OBERTHUR TECHNOLOGIES.
The confidentiality and integrity of the cap files and of the javacard open platform is
covered by the evaluation of the development premises of OBERTHUR
TECHNOLOGIES.
To ensure security, access to development tools and products elements (PC, card
reader, documentation, source code...) is protected. The protection is based on
measures for prevention and detection of unauthorized access. Two levels of
protection are applied:
• Access control to OBERTHUR TECHNOLOGIES offices and sensitive areas.
• Access to development data through the use of a secure computer system to
design, implement and test software
The software development phase of the javacard open platform is covered by its
certificates
Copyright 2010 © 24 FQR 110 4773 Ed3
At the end of this phase:
• the cap files are available.
• if DAP feature is mandated, the DAP is computed and added to the cap files
• the javacard open platform (JOP) code is available
At the end of this phase 1, the cap files are protected in integrity if DAP is used.
2.5.2.2. Hardware development (Phase 2)
In this phase, the javacard open platform (JOP) is being built.
The cap files may be stored in the ROM code of the javacard open platform (JOP).
This phase takes place at the manufacturing site of the silicium provider.
The confidentiality and integrity of the javacard open platform is covered by the
evaluation of the development premises of the silicium manufacturer.
2.5.3. Production environment
The production environment encompasses the environments in which the parts of TOE
are gathered (javacard open platform and cap files). It corresponds to the production of
the javacard open platform (JOP)
It corresponds to the following steps:
• Software is engraved in the silicium to get the javacard open platform (JOP).
• The chip is mounted on a physical layout (card, USB token,..)
• The javacard open platform is prepersonalized
• The javacard open platform is personalized
• The cap files are loaded if needed in the javacard open platform (JOP)
• The Application is instanciated
2.5.3.1. Javacard open platform manufacturing (phase 3)
In this phase, the javacard open platform (JOP) is self protected.
The cap files may already be present in the ROM code of the javacard open platform
(JOP)
Copyright 2010 © 25 FQR 110 4773 Ed3
This phase takes place at the manufacturing site of the silicium provider.
Depending on the choice made for the optional code loading, it may be loaded
during this phase
At the end of phase 3, the javacard open platform (JOP) is self protected: all its security functions
are activated
At the end of phase 3, the cap files are protected in integrity if they are stored in the ROM code of
the javacard open platform (JOP).
2.5.3.2. Javacard open platform (JOP) packaging and initialization
(phase 4)
The Javacard open platform (JOP) is under the control of the Manufacturing Agent.
This subject is in charge of the Javacard open platform (JOP) packaging.
This phase span the phase 4 of the Javacard open platform (JOP) life cycle
2.5.3.3. Javacard open platform (JOP) pre-personnnalization (phase 5)
The Javacard open platform (JOP) and the cap files are under the control of the
Manufacturing Agent. This subject shall be authenticated prior to any action on the
javacard open platform.
During these phases, the Manufacturing Agent operates on the Javacard open
platform (JOP) and loads the cap files in the Javacard open platform (JOP) if needed.
Three situations may occur:
• The Javacard open platform (JOP) is pre-personnalized by OBERTHUR
TECHNOLOGIES in its manufacturing site and the cap files are loaded in
EEPROM
• The Javacard open platform (JOP) is pre-personalized and the cap files are
loaded in EEPROM while the DAP is enforced
• The cap files are already present in the ROM code of the javacard open
platform (JOP)
Copyright 2010 © 26 FQR 110 4773 Ed3
In any case, at the end of this phase, the composite TOE is produced and self
protected.
1 - OBERTHUR TECHNOLOGIES is in charge of the Javacard open platform (JOP)
is pre-personalization and the cap files are loaded in EEPROM
This phase is done in the manufacturing site of Vitré (France – 35). The procedures
and the IT infrastructure ensure the integrity and authenticity of the cap files.
In this case, this phase spans the following phases of the javacard open platform
(JOP):
• Phase 5
• Phase 6
• Phase 7
The following process will be applied:
• the javacard open platform (JOP) is switched in phase 5. The cap files may be
loaded and the applet may be instantiated in this phase
• the javacard open platform (JOP) is switched in phase 6. The cap files may be
loaded and the applet may be instantiated in this phase
• the javacard open platform (JOP) is switched in phase 7
During all these phases, the javacard open platform (JOP) is self-protected as it
requires the authentication of the Manufacturing Agent prior to any operation.
The cap files may be loaded in phase 5 or phase 6 of the javacard open platform
(JOP), i.e. without DAP.
At the end of this phase, the javacard open platform is switched in phase 7 (DAP
enforced)
Any other applet may be loaded at any time (phase 5, 6 or 7 of the javacard open
platform)
At the end of this phase, the TOE is self protected:
• The javacard open platform (JOP) is self protected. It requires an
authentication prior to any actions
• The Applet is instantiated. It requires an authentication prior to any actions
Copyright 2010 © 27 FQR 110 4773 Ed3
The cap files are protected in integrity by the security measures and procedures
ensured by the manufacturing site
2 - The Javacard open platform (JOP) is pre-personalized and the cap files are loaded
in EEPROM while the DAP is enforced.
In this case, this phase spans the following phases of the javacard open platform
(JOP):
• Phase 5
• Phase 6
• Phase 7
The following process will be applied:
• the javacard open platform (JOP) is switched in phase 5 and the DAP is
enforced
• the javacard open platform (JOP) is switched in phase 6 and the cap files are
loaded with DAP
• the javacard open platform (JOP) is switched in phase 7
During all these phases, the javacard open platform (JOP) is self-protected as it
requires the authentication of the Manufacturing Agent prior to any operation.
The cap files is loaded in phase 6 while the DAP is enforced in the javacard open
platform.
At the end of this phase, the javacard open platform is switched in phase 7
During this phase, any other applet may be loaded at any time (phase 5, 6 or 7 of the
javacard open platform)
The cap files are self protected as they are loaded in the javacard open platform
(JOP) with DAP.
The DAP generation is done in the development environment, covered by
ALC_DVS.2
3 - The cap files are already present in the ROM code of the javacard open platform
(JOP)
Copyright 2010 © 28 FQR 110 4773 Ed3
In this case, this phase spans the following phases of the javacard open platform
(JOP):
• Phase 5
• Phase 6
• Phase 7
The following process will be applied:
• the javacard open platform (JOP) is switched in phase 5 and the applet may
be instantiated in this phase.
• the javacard open platform (JOP) is switched in phase 6 and the applet may
be instantiated in this phase.
• the javacard open platform (JOP) is switched in phase 7 and the applet may
be instantiated in this phase.
During all these phases, the javacard open platform (JOP) is self-protected as it
requires the authentication of the Manufacturing Agent prior to any operation.
At the end of this phase, the javacard open platform is switched in phase 7 (DAP
enforced)
During this phase, any other applet may be loaded at any time (phase 5, 6 or 7 of the
javacard open platform)
The cap files are present in the ROM code of the javacard open platform and are
therefore protected in integrity
Note:
In this evaluation, the javacard packages are not loaded in the ROM code of the
javacard open platform
2.5.4. Operational environment
The operational environment encompasses the environments in which the TOE is
constructed. It corresponds to the following steps:
• Personalization of the IAS ECC Application
• Use of the IAS ECC Application
Copyright 2010 © 29 FQR 110 4773 Ed3
2.5.4.1. TOE personalization (phase 6)
The TOE is under the control of the Personalization Agent in charge of
personalizing the Applet. This subject shall be authenticated prior to any action on
the Javacard open platform.
This phase may not necessarily take place in a manufacturing site, but may be
performed anywhere. The Personalization Agent is responsible for ensuring a
sufficient level of security during this phase.
During this phase, the applet is personalized according to [AGD_PRE]: creation of
applicative data (SCD, SVD, RAD, File,…) and the TOE_Administrator Agent key
is loaded.
At the end of phase 6, the TOE is constructed
2.5.4.2. TOE Usage (phase 7)
The TOE is under the control of the User (Signatory and/or Administrator) and
TOE_Administrator.
During this phase, the TOE may be used to create a secure signature and manage
the SCD, the SVD and the RAD.
During this phase, the TOE may be used both in contact and/or contactless mode.
2.5.5. Coverage of the different Life cycle state by the assurance components
AGD & ALC
The following steps of the life cycle are covered as follows:
Life cycle phase Environment Covered by
Phase 1 Development
ALC [CLIO/THALIE]
ALC [EUTERPE]
Phase 2 Development ALC [CLIO/THALIE]
Phase 3 Development ALC [CLIO/THALIE]
Javacard open platform is self protected
Cap files are protected
Phase 4 Production of TOE AGD_PRE [CLIO/THALIE]
Phase 5 Production of TOE
AGD_PRE [CLIO/THALIE],
AGD_OPE [CLIO/THALIE],
ALC [EUTERPE] when done @ Vitré
TOE is self protected
Copyright 2010 © 30 FQR 110 4773 Ed3
Phase 6 Operationnal
AGD_OPE [CLIO/THALIE]
AGD_PRE [EUTERPE]
TOE is constructed
Phase 7 Operationnal
AGD_OPE [CLIO/THALIE]
AGD_OPE [EUTERPE]
2.5.6. State of the TOE depending on the phase
This chapters describes when the TOE is self protected depending on the case
1 - OBERTHUR TECHNOLOGIES is in charge of the Javacard open platform (JOP)
is pre-personalization and the cap files are loaded in EEPROM
Life
cycle
phase
State of the cap files at the end of the
phase
State of the JOP at
the end of the phase
State of the TOE at the
end of the phase
Phase 1 constructed but not self protected In construction In construction
Phase 2 N/A In construction In construction
Phase 3 N/A
constructed and self
protected
In construction and self
protected
Phase 4 N/A Self protected
In construction and self
protected
Phase 5
Loaded on the javacard Open platform
(JOP).
Application is instantiated
The cap file integrity is ensured by the
security measures and procedures of
the manufacturing site
Self protected
In construction and self
protected
Phase 6 Loaded in the JOP Self protected
Constructed and self
protected
Phase 7 Loaded in the JOP Self protected
Constructed and self
protected
2 - The Javacard open platform (JOP) is pre-personalized and the cap files are loaded
in EEPROM while the DAP is enforced.
Life
cycle
phase
State of the cap files at the end of the
phase
State of the JOP at
the end of the phase
State of the TOE at the
end of the phase
Phase 1 constructed and self protected (DAP) In construction In construction
Phase 2 N/A In construction In construction
Copyright 2010 © 31 FQR 110 4773 Ed3
Phase 3 N/A
constructed and self
protected
In construction and self
protected
Phase 4 N/A Self protected
In construction and self
protected
Phase 5
Self protected
Loaded on the javacard Open platform
(JOP).
Application is instantiated
constructed and self protected
Self protected
In construction and self
protected
Phase 6 Loaded in the JOP Self protected
Constructed and self
protected
Phase 7 Loaded in the JOP Self protected
Constructed and self
protected
3 - The cap files are already present in the ROM code of the javacard open platform
(JOP)
Life
cycle
phase
State of the cap files at the end of the
phase
State of the JOP at
the end of the phase
State of the TOE at the
end of the phase
Phase 1 constructed but not self protected In construction In construction
Phase 2 constructed but not self protected In construction In construction
Phase 3 constructed and self protected
constructed and self
protected
In construction and self
protected
Phase 4 N/A Self protected
In construction and self
protected
Phase 5
Application is instantiated
Self protected
Self protected
In construction and self
protected
Phase 6 Self protected Self protected
Constructed and self
protected
Phase 7 Self protected Self protected
Constructed and self
protected
2.5.7. Mapping with the life cycle and Subjects described in [SSCD2] and
[SSCD3]
The life cycle of the TOE is based on the one described in [PP9911]. This chapter focuses
on mapping it to the one described in [SSCD2] and [SSCD3].
Life cycle phase of the TOE Life cycle phase with respect to [SSCD2]
Copyright 2010 © 32 FQR 110 4773 Ed3
and [SSCD3]
Phase 1 Design
Phase 2 Fabrication
Phase 3 Fabrication
Javacard open platform is self protected and cap files are protected
Phase 4 N/A
Phase 5 Loading of application data
TOE is self protected
Phase 6 Personalization
TOE is constructed
Phase 7
Usage
Destruction
For each of these phases, the following subjects may interact with the TOE
Life cycle phase of the TOE Subject interacting with the TOE
Phase 1 OBERTHUR TECHNOLOGIES
Phase 2 OBERTHUR TECHNOLOGIES
Phase 3 OBERTHUR TECHNOLOGIES
Javacard open platform is self protected and cap files are protected
Phase 4
Manufacturing Agent
Offcard
Phase 5
Manufacturing Agent
Offcard
TOE is self protected
Phase 6
Personalization Agent
Offcard
TOE is constructed
Phase 7
User (Signatory or Administrator)
TOE_Administrator
Offcard
Presentation of the different subjects interacting with the TOE;
In phase 1 up to 3, the TOE is under the control of OBERTHUR TECHNOLOGIES. It is
in charge of designing and manufacturing the TOE.
In phase 4, the TOE is under the control of the Manufacturing Agent. It is in charge of
loading data within the TOE to make it operational. During this phase, the
Manufacturing agent ensures a sufficient level of security.
Copyright 2010 © 33 FQR 110 4773 Ed3
In phase 5, the TOE is under the control of the Manufacturing Agent. It is in charge of
loading the applet within the javacard platform. During this phase, the Manufacturing
agent ensures a sufficient level of security.
In phase 6, the TOE is under the control of the Personalization Agent. It is in charge of
loading data within the TOE to make it operational. During these phase, the
Personalization agent ensures a sufficient level of security.
In particular, in phase 6, the Personalization Agent may :
• Create and load the RAD
• Create and load the SCD/SVD
• Create and generate the SCD/SVD
• Export the SVD
• Create the security policies to be applied to files and objects
The Personalization Agent behaves as the Administrator and Signatory for the key
management features for this phase
In phase 7, the TOE is under the control of the Signatory and Administrator.
In particular, the Administrator may :
• Create the RAD
• Create the SCD/SVD
• Create the SCD/SVD
the Signatory or the Administrator may :
• Load the RAD
• Load the SCD/SVD
• Generate the SCD/SVD
• Export the SVD
and Signatory may
• sign DTBS/DTBS-representation
• change its RAD
During phase 7, another entity may manage the TOE : TOE_Administrator. It is in
charge of managing some features of the TOE such as :
• Allowing signing DTBS representation computed off card
• Allowing the authentication of remote IT or administrator by means of symmetric
and/or asymmetric scheme
• Allowing to restrict the contact and/or contactless interface for communication
Copyright 2010 © 34 FQR 110 4773 Ed3
3. Target Of Evaluation Security Environment
3.1. Remote IT entity
The following remote IT entity may interact with the TOE
Remote IT Description
SCA
This remote IT is in charge of sending the
DTBS/DTBS representation to the TOE
This remote IT is present in phase 7 of the life
cycle of the TOE
CGA
This remote IT is in charge of issuing a
(qualified) certificate as well as a link enabling
to find the (qualified) certificate matching the
SCD.
This remote IT is present in phase 6 and 7 of
the life cycle of the TOE
SSCD type 1
This remote IT is in charge of importing a
SCD/SVD pair on the TOE as well as a link
enabling to find the (qualified) certificate
matching the SCD.
This remote IT is present in phase 6 and 7 of
the life cycle of the TOE
IFD
In case the contactless is used to establish
communication with the TOE, the
communication shall be established with an
IFD, ensuring the communications are
protected by a secure channel.
The IFD is in charge as well the remote entity
interacting with the TOE in case eServices are
used
This entity shall be recognized by the TOE
issuer.
The IFD is considered as being part of the
remote IT (CGA, SSCD type 1 and SCA) with
which the TOE wants to communicat in a
secure manner.
This remote IT is present in phase 7 of the life
cycle of the TOE
HI
Human interface used by local users to enter
RAD or VAD.
The data entered are transmitted to the TOE
via a trusted path
Copyright 2010 © 35 FQR 110 4773 Ed3
It is very important to stress to these Remote IT are just an abstract point of view.
Depending on the use case, the following situation may arise
• Several Remote IT are realized by a single entity (e.g. SCA, CGA and SSCD type
1)
• A remote IT is as well a subject (e.g. the SCA is the Administrator, the CGA is the
TOE_Administrator,..)
Moreover, in phase 6, the SSCD type 1 remote IT is tightly linked to the subject
operating during this phase (i.e. S.Personnalizer). The SSCD securely transmits the SCD
to the TOE by mean of an encryption key. The encryption key is deduced from
diversifying data agreed during the authentication of the “Personalizer” with the TOE.
Therefore, in phase 6, the import of SCD from a SSCD type 1 requires S.Personnalizer to
be authenticated in a first step.
The Human interface (HI) used to enter the PIN is considered as being part of the SCA,
CGA or SSCD, depending on the case. It benefits from the trusted channel between the
TOE and the SCA, or the SSCD type 1 or the CGA to transmit the RAD or VAD to the
TOE.
3.2. Subjects
The following Subject interact with the TOE
Subject Description
S.User
End User of the TOE that can be identified as
S.Admin or S.Signatory
It is named User
S.Admin
User(s) who is in charge to perform the TOE
initialization, TOE personalization or other
TOE administrative functions
This User may operate during phase 7.
Depending on the use case envisioned, the
subject(s) S.SCA, S.CGA, S.SSCD or S.IFD
may be the subject S.Admin.
It is named Administrator
S.Signatory
User who holds the TOE and uses it on his
own behalf or on behalf of the natural or legal
person or entity he represents
It is named Signatory
S.TOE_Admin
User who is in charge to perform the
configuration management of the TOE
Copyright 2010 © 36 FQR 110 4773 Ed3
It is named TOE_Administrator
S.Personalizer
User who operates in Phase 6 of the life cycle.
It is in charge to perform the TOE initialization
and TOE personalization
It is named Personalizer
S.Manufacturer
User who operates in Phase 5. It is in charge of
physically building the javacard open
platform, e.g.
mounting the chip on the antenna
physically building the card
performing the graphical personalization
and performing some basic prepersonalisation
operation it is only entitled to perform
The action of this subject is covered by
[CLIO/THALIE]
It is named Manufacturer
S.SCA
It is the SCA seen as a subject interacting with
the TOE.
As such, depending on the use case, it might
belongs to the category S.Admin.
It is named SCA
S.CGA
It is the CGA seen as a subject interacting with
the TOE.
As such, depending on the use case, it might
belongs to the category S.Admin.
It is named CGA
S.SSCD
It is the SSCD seen as a subject interacting
with the TOE.
As such, depending on the use case, it might
belongs to the category S.Admin.
It is named SSCD
S.IFD
It is the IFD seen as a subject interacting with
the TOE.
As such, depending on the use case, it might
belongs to the category S.Admin.
It is named IFD
S.Offcard
Attacker as being a human or process acting on
his behalf being located outside the TOE. The
main goal of the attacker is to access the SCD
or to false the electronic signature. The attacker
has a high attack potential and knows no secret
Copyright 2010 © 37 FQR 110 4773 Ed3
3.3. User data
The following user data are managed by the TOE
User Data Description
D.DTBS
DTBS and DTBS representation ; set of data or its
representation which is intended to be signed
D.VAD
VAD : PIN code data entered by the End User (S.Signatory
or S.Admin) to authenticate itself or to perform a signature
operation
D.AUTH_CRYPTOGRAM
Authentication data used to authenticate subjects such as
• S.Admin
• S.TOE_Admin.
• S.Personalizer
• S.SCA
• S.CGA
• S.SSCD
• S.IFD
It is a cryptogram sent by the outside the TOE checks with
D.AUTH_KEYS
D.SIGNATURE
Electronic signature (unforceability of electronic signatures
must be assured)
D.DTBS
DTBS and DTBS representation stored within the TOE; set
of data or its representation which is intended to be signed
D.RAD
RAD : Reference PIN code authentication data used to
authenticate the End User (S.Signatory or S.Admin)
There might be several RAD within the TOE
D.SCD
SCD : private key used to perform an electronic signature
operation There might be several SCD within the TOE
D.SVD
SVD :public key linked to the SCD and used to perform an
electronic signature verification There might be several SVD
within the TOE
D.TOE_SerialNumber
Serial number of the TOE. This data is required to perform
device and external authentication. It is an
IDENTIFICATION_DATA
D.AUTH_KEYS
Group of keys stored on the TOE used to perform a mutual
authentication with subjects such as :
• S.Admin
• S.TOE_Admin.
• S.Personalizer
• S.SCA
• S.CGA
• S.SSCD
• S.IFD
Copyright 2010 © 38 FQR 110 4773 Ed3
Or used to authenticate external entities such as
• SSCD type 1 used to import a SCD
• SCA for signature creation
• CGA for certificate generation.
• IFD in case of contactless communication
These keys are secret data shared by the TOE and the
other entity (symmetric keys)
D.ESERVICES_KEYS
Group of keys/Parameters stored on the TOE used to
perform eServices such as
• Certificate verification – first key stored in the TOE
• Key Agreement Domain parameters
• Key Decryption keys
Some are public :
• Certificate verification – first key stored in the TOE
• Key Agreement Domain parameters
• Public portion of key decryption key
Some shall remain secret
• Private key of key decryption key
D.TOE_AUTH_PUBLIC_KEYS
Group of public key matching the private authentication
key of the TOE
D.TOE_AUTH_PRIVATE_KEYS
Group of authentication private key(s) of the TOE.
The authentication mechanism involved are
• C/S authentication
• DAPP Internal authentication
D.IDENTIFICATION_DATA
Data or group of data stored in the TOE, that may be used to
uniquely identify the TOE and therefore the TOE holder.
3.4. TSF data
The following TSF data are managed by the TOE
TSF Data Description
D.APPLI
The quality of the signature creation application (IAS
ECC) must be maintained so that it can participate to the
legal validity of electronic signature
D.SCD_ID
Identifier of the SCD. In order to identify the matching
certificate, each SCD shall be associated with an
identifier
D.EPHEMERAL_KEYS
The ephemeral key extracted from a certificate (CVC). It
may be used to
Copyright 2010 © 39 FQR 110 4773 Ed3
• Verify another certificate
• Authenticate a subject or a remote IT entity
The ephemeral key is a public portion of a RSA key pair.
It can only be extracted with a trusted key, i.e. a key
whose issuer is trusted (the public key is either stored in
the TOE or extracted from another certificate).
This category key is said to be ephemeral as it is not
stored in the TOE but has to be directly used to verify
another certificate or authenticate a subject or a remote
IT
In case of authentication protocol relying on asymmetric
scheme, it is used to authenticate entities such as
• a certificate issuer
• S.Admin
• S.SCA
• S.CGA
• S.SSCD
• S.IFD
Or used to authenticate external entities such as
• SSCD type 1 used to import a SCD
• SCA for signature creation
• CGA for certificate generation.
• IFD in case of contactless communication
D.STATE
Life Cycle state of the TOE. Its value is either
“SELECTABLE” (in phase 6) or “PERSONALIZED”. (in
phase 7)
D.Medium
Attribute of the TOE indicating which communication
medium can be used (contat and/or contactless)
D.HashOffCard
Attribute of the TOE indicating if qualified signature can
be performed on a hash computed off card
D.SymAuthMechanisms
Attribute of the TOE indicating if authentication
mechanisms based on symmetric scheme can be used
D.AsymAuthMechanisms
Attribute of the TOE indicating if authentication
mechanisms based on asymmetric scheme can be used
D.SM_DATA
Keys and data used by the TOE to establish and manage
a trusted channel in phase 7.
These data ensure identification of both parties (TOE
and the entity) and the protection in integrity and
confidentiality of data exchanged.
Copyright 2010 © 40 FQR 110 4773 Ed3
3.5. Assumption
3.5.1. Standard Assumption
A.CGA Trustworthy certification-generation application
The CGA protects the authenticity of the signatory’s name and the SVD in the qualified
certificate by an advanced signature of the CSP.
A.SCA Trustworthy signature-creation application
The signatory uses only a trustworthy SCA. The SCA generates and sends the DTBS-
representation of data the signatory wishes to sign in a form appropriate for signing by
the TOE.
A.SCD_Generate Trustworthy SCD/SVD generation
If a party other than the signatory generates the SCD/SVD-pair of a signatory, then
(a) this party will use a SSCD for SCD/SVD-generation,
(b) confidentiality of the SCD will be guaranteed until the SCD is under the sole
control of the signatory and
(c) the SCD will not be used for signature-creation until the SCD is under the sole
control of the signatory.
(d) The generation of the SCD/SVD is invoked by authorised users only
(e) The SSCD Type1 ensures the authenticity of the SVD it has created and
exported
3.5.2. Complementary Assumption
N/A
3.6. Threats
3.6.1. Standard threats
T.Hack_Phys Physical attacks through the TOE interfaces
An attacker interacts with the TOE interfaces to exploit vulnerabilities, resulting in
arbitrary security compromises. This threat addresses all the assets.
T.SCD_Divulg Storing ,copying, and releasing of the signature-creation data
An attacker can store, copy the SCD outside the TOE. An attacker can release the SCD
during generation, storage and use for signature-creation in the TOE.
T.SCD_Derive Derive the signature-creation data
Copyright 2010 © 41 FQR 110 4773 Ed3
An attacker derives the SCD from public known data, such as SVD corresponding to the
SCD or signatures created by means of the SCD or any other data communicated
outside the TOE, which is a threat against the secrecy of the SCD.
T.Sig_Forgery Forgery of the electronic signature
An attacker forges the signed data object maybe together with its electronic signature
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 generated by the TOE is
subject to deliberate attacks by experts possessing a high attack potential with advanced
knowledge of security principles and concepts employed by the TOE.
T.Sig_Repud Repudiation of signatures
If an attacker can successfully threaten any of the assets, then the non repudiation of the
electronic signature is compromised. The signatory is able to deny having signed data
using the SCD in the TOE under his control even if the signature is successfully verified
with the SVD contained in his un-revoked certificate.
T.SVD_Forgery Forgery of the signature-verification data
An attacker forges the SVD presented by the TOE. This result in loss of SVD integrity in
the certificate of the signatory.
T.DTBS_Forgery Forgery of the DTBS-representation
An attacker modifies the DTBS-representation sent by the SCA. Thus the DTBS-
representation used by the TOE for signing does not match the DTBS the signatory
intends to sign.
T.SigF_Misuse Misuse of the signature-creation function of the TOE
An attacker misuses the signature-creation function of the TOE to create Signed Data
Object 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.
3.6.2. Complementary threats
T.TOE_ID_Contactless Identification of the TOE
When the TOE is configured to be used in contactless mode, an attacker tries to trace the
movement of the TOE by identifying it remotely by establishing or listening a
communication through the contactless communication interface.
T.Skimming_Contactless Skimming of the TOE in contactless
Copyright 2010 © 42 FQR 110 4773 Ed3
When the TOE is configured to be used in contactless mode, an attacker imitates the
device to retrieve data from the TOE via the contact less communication channel of the
TOE.
T.Eavesdropping_Contactless Eavesdropping of the communication between TOE and
device
When the TOE is configured to be used in contactless mode, an attacker listens to the
communication between the TOE and a device in order to retrieve sensitive data.
T.Key_Divulg Storing ,copying, and releasing of a key stored in the TOE
An attacker can store, copy an authentication or eService key stored in the TOE outside
the TOE. An authentication key may be either used to authenticate an external entity or
the TOE, and may be symmetric or asymmetric. An attacker can release an
authentication or eService key during generation, storage and use in the TOE.
T.Key_Derive Derive a key
An attacker derives an authentication key (of the TOE or an external entity) or eService
key from public known data, such as the corresponding public key or cryptogram
created by means of the key or any other data communicated outside the TOE, which is
a threat against the secrecy of the key.
T.TOE_PublicAuthKey_Forgery Forgery of the public key of a TOE authentication key
An attacker forges the public key of a TOE authentication key presented by the TOE.
This results in loss of the public key integrity in the authentication certificate of the TOE.
T.Authentication_Replay Replay of an authentication of an external entity
An attacker retrieves by observation authentication data used by a third party during an
authentication sequence. The attacker tries to replay this authentication sequence to
grant access to the TOE.
3.7. Organizational security policies
3.7.1. Standard organizational security policies
P.CSP_QCert Qualified certificate
The CSP uses a trustworthy CGA to generate the qualified certificate for the SVD
generated by the SSCD. The qualified certificates contains at least the elements defined
in Annex I of the Directive, i.e., inter alia 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 is evident with signatures through the certificate or
other publicly available information.
Copyright 2010 © 43 FQR 110 4773 Ed3
P.QSign Qualified electronic signatures
The signatory uses a signature-creation system to sign data with qualified electronic
signatures. The DTBS are presented to the signatory by the SCA. The qualified electronic
signature is based on a qualified certificate and is created by a SSCD.
P.Sigy_SSCD TOE as secure signature-creation device
The TOE stores the SCD used for signature creation under sole control of the signatory.
The SCD used for signature generation can practically occur only once.
3.7.2. Complementary organizational security policies
P.EMSEC_Design The TOE is designed to reduce the E.M emanation
The cryptographic computation, memory access, and software execution are
implemented in such a way that they are not susceptible to leakage attacks
P.SecurityPolicy_Contactless Security policy definition.
All the data that may be accessed in contactless mode and that would lead to
unambiguously identify and track the TOE shall not be accessible in free mode. They
shall be accessed upon successful authentication of the entity willing to access it.
Moreover, the TOE shall enforce these data to be accessed through a communication
channel protected in confidentiality (for the sole recipient) and ensuring the
authentication of the sender. The subject in charge of creating these data that might be
accessed in contactless mode (Administrator, Signatory, Personalizer) shall enforce this
security policy.
P.LinkSCD_QualifiedCertificate Link between a SCD stored in the TOE and the relevant
qualified certificate
The Subject in charge of creating and updating the SCD (Personalization Agent,
Administrator, Signatory), or the remote IT entity involved in the updating process (the
SSCD, the CGA) shall ensure an unambiguous link between the SCD(s) and the
matching qualified certificate(s). This link might be figured out by a PKCS#15 structures,
an XML structure, an identifier .linking a SCD to the file containing the qualified
certificate or the URL hosting them. In particular, it implies it is updated, each time the
SCD is created, imported, erased or generated.
P.ControlOfAppletToBeLoaded_Contactless Control of the other applet that may be
loaded on the javacard open platform
When the TOE is configured to be used in contactless mode, the Administrator, the
Personalization Agent or the TOE_Administrator shall ensure that any applet that is
loaded on the javacard open platform does not enable to track/identify the TOE.
Copyright 2010 © 44 FQR 110 4773 Ed3
P.TOE_PublicAuthKey_Cert Certificate for asymmetric TOE authentication keys
The TOE contains certificate(s) issued by a known entity ensuring its public key
corresponding to its private key used for authentication is genuine.
P.TOE_Construction Construction of the TOE by the Personnalization Agent
The recommandations indicated in [AGD_PRE] required to construct the TOE are
correctly applied.
3.8. Security Objectives for the TOE
3.8.1. Standard security objectives of the TOE
OT.EMSEC_Design Provide physical emanations security
Design and build the TOE in such a way as to control the production of intelligible
emanations within specified limits.
OT.Lifecycle_Security Lifecycle security
The TOE shall detect flaws during the initialisation, personalisation and operational
usage. The TOE shall provide safe destruction techniques for the SCD in case of re-
import or re-generation.
OT.SCD_Secrecy Secrecy of the signature-creation data
The secrecy of the SCD (used for signature generation) is reasonably assured against
attacks with a high attack potential.
OT.SCD_SVD_Corresp Correspondence between SVD and SCD
The TOE shall ensure the correspondence between the SVD and the SCD. The TOE shall
verify on demand the correspondence between the SCD stored in the TOE and the SVD
if it has been sent to the TOE.
OT.SVD_Auth_TOE TOE ensures authenticity of the SVD
The TOE provides means to enable the CGA to verify the authenticity SVD that has been
exported by that TOE.
OT.Tamper_ID Tamper detection
The TOE provides system features that detect physical tampering of a system
component, and use those features to limit security breaches.
Copyright 2010 © 45 FQR 110 4773 Ed3
OT.Tamper_Resistance Tamper resistance
The TOE prevents or resists physical tampering with specified system devices and
components.
OT.Init SCD/SVD generation
The TOE provides security features to ensure that the generation of the SCD and the
SVD is invoked by authorized users only.
OT.SCD_Unique Uniqueness of the signature-creation data
The TOE shall ensure the cryptographic quality of the SCD/SVD pair for the qualified
electronic signature. The SCD used for signature generation can practically occur only
once and cannot be reconstructed from the SVD. In that context ‘practically occur once’
means that the probability of equal SCDs is negligible low.
OT.SCD_Transfer Secure transfer of SCD between SSCD
The TOE shall ensure the confidentiality of the SCD transferred between SSCDs.
OT.DTBS_Integrity_TOE Verification of the DTBS-representation integrity
The TOE shall verify that the DTBS-representation received from the SCA has not been
altered in transit between the SCA and the TOE. The TOE itself shall ensure that the
DTBS representation is not altered by the TOE as well. Note, that this does not conflict
with the signature-creation process where the DTBS itself could be hashed by the TOE.
OT.Sigy_SigF Signature generation function for the legitimate signatory only
The TOE provides the signature generation function for the legitimate signatory only
and protects the SCD against the use of others. The TOE shall resist attacks with high
attack potential.
OT.Sig_Secure Cryptographic security of the electronic signature
The TOE generates electronic signatures that cannot be forged without knowledge of the
SCD through robust encryption techniques. The SCD cannot be reconstructed using the
electronic signatures. The electronic signatures shall be resistant against these attacks,
even when executed with a high attack potential.
3.8.2. Complementary security objectives of the TOE
OT.Authentication_Secure Secure authentication mechanisms
The TOE enables to create/erase authentication keys used to provide authentication
mechanisms enabling to
• authenticate remote entities in order to grant them some access rights
• authenticate the TOE towards external entities, ensuring it is not cloned
Copyright 2010 © 46 FQR 110 4773 Ed3
The TOE generates and uses from remote entities authentication cryptogram that cannot
be forged without knowledge of the authentication key through robust encryption
techniques. The authentication key cannot be reconstructed using the authentication
cryptogram. The cryptogram shall be resistant against these attacks, even when
executed with a high attack potential. Moreover, the TOE uses freshly generated
random in authentication protocols in order to avoid replay attacks.
OT.Privacy_Contactless Privacy of sensitive data exchanged in contactless
When used in contactless, the TOE protects the access to sensitive data (RAD,
identification data). It enforces the RAD/VAD to be sent from an authenticated device in
a manner protected from disclosure, ensuring it can not be retrieved by an attacker.
Moreover, any identification data can only be returned to successfully authenticated
entities, in a way ensuring they are protected from disclosure and are issued by the
TOE.
OT.SCD/SVD_Management Management of SCD/SVD
The TOE enables to manage SCD/SVD. Each key (pair) and RAD may be created at any
time and used to perform qualified signature during the TOE life time. Several SCD,
SVD, and RAD may be present on the TOE and used by the same holder. The TOE
guarantees the SCD, SVD and RAD are independent from each other.
OT.Key_Lifecycle_Security Lifecycle security of the key(s) stored in the TOE
The TOE shall detect flaws during the initialisation, personalisation and operational
usage. The TOE shall provide safe destruction techniques for the authentication keys (of
the TOE and/or the external entities) and eServices keys it stores in case of erasure, re-
import or re-generation.
OT.Key_Secrecy Secrecy of the key(s) stored in the TOE
The secrecy of the authentication keys (of the TOE and/or the external entities) and
eServices keys stored in the TOE is reasonably assured against attacks with a high attack
potential.
OT.TOE_AuthKey_Unique Uniqueness of the TOE authentication key(s)
The TOE shall ensure the cryptographic quality of the asymmetric authentication key
pair used for the TOE authentication. The private key used for TOE authentication can
practically occur only once and cannot be reconstructed from the public key. In that
context ‘practically occur once’ means that the probability of equal TOE authentication
key is negligible low.
OT.LifeCycle_Management Management of the life cycle
Copyright 2010 © 47 FQR 110 4773 Ed3
The TOE provides a life cycle management enabling to separate its life cycle in two main
phases.
The first one (phase 6) is the one during the TOE is under the sole control of the
Personalization Agent. The following operation may be realized:
• The SCD, SVD may be created, generated, imported or erased
• The ESERVICES_KEYS,AUTH_KEYS, TOE_AUTH_PUBLIC_KEYS and
TOE_AUTH_PRIVATE_KEYS may be created, imported, generated or erased
• The RAD (s) may be created and loaded
• SVD may be exported
• TOE_AUTH_PUBLIC_KEYS may be exported
Once performed, the Personalization Agent switches the TOE in phase 7. This transition
is irreversible leaving the TOE under the sole control of the signatory,, the administrator
(including the SCA, CGA, SSCD, IFD) and the TOE_Administrator according to the
security rules set by the Personalization Agent.
OT.eServices Provision of eServices
The TOE provides eServices Mechanisms enabling to create, import, generate, export the
matching public key and erase eServices keys. These keys are used to
• decrypt encryption keys
• authenticate the TOE
• verify CVC certificates
3.9. Security objectives for the Environment
3.9.1. Standard security objectives of the Environment
OE.SCD_SVD_Corresp Correspondence between SVD and SCD
The SSCD Type1 shall ensure the correspondence between the SVD and the SCD. The
SSCD Type1 shall verify the correspondence between the SCD sent to the TOE and the
SVD sent to the CGA or TOE.
OE.SCD_Transfer Secure transfer of SCD between SSCD
The SSCD Type1 shall ensure the confidentiality of the SCD transferred to the TOE. The
SSCD Type1 shall prevent the export of a SCD that already has been used for signature
generation by the SSCD Type2. The SCD shall be deleted from the SSCD Type1
whenever it is exported into the TOE.
OE.SCD_Unique Uniqueness of the signature-creation data
Copyright 2010 © 48 FQR 110 4773 Ed3
The SSCD Type1 shall ensure the cryptographic quality of the SCD/SVD pair for the
qualified electronic signature. The SCD used for signature generation can practically
occur only once and cannot be reconstructed from the SVD. In that context ‘practically
occur once’ means that the probability of equal SCDs is negligible low.
OE.CGA_QCert Generation of qualified certificates
The CGA generates qualified certificates which include inter alia
(a) the name of the signatory controlling the TOE,
(b) the SVD matching the SCD implemented in the TOE under sole control of the
signatory,
(c) the advanced signature of the CSP.
OE.SVD_Auth_CGA CGA verifies the authenticity of the SVD
The CGA verifies that the SSCD is the sender of the received SVD and the integrity of
the received SVD. The CGA verifies the correspondence between the SCD in the SSCD
of the signatory and the SVD in the qualified certificate.
OE.HI_VAD Protection of the VAD
If an external device provides the human interface for user authentication, this device
will ensure confidentiality and integrity of the VAD as needed by the authentication
method employed.
OE.SCA_Data_Intend Data intended to be signed
The SCA
(a) generates the DTBS-representation 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,
(b) sends the DTBS-representation to the TOE and enables verification of the
integrity of the DTBS-representation by the TOE
(c) attaches the signature produced by the TOE to the data or provides it
separately.
3.9.2. Complementary security objectives of the Environment
OE.SecurityPolicy_Contactless Security policy definition.
All the data that may be accessed in contactless mode and that would lead to
unambiguously identify and track the TOE shall not be accessible in free mode. They
shall be assigned a relevant security policy ensuring they can only be accessed by a
successfully authenticated entity. Moreover, they shall only be transferred in a manner
Copyright 2010 © 49 FQR 110 4773 Ed3
ensuring protection in confidentiality (can only be retrieved by the entitled recipient)
and proving the authenticity of the sender.
OE.LinkSCD_QualifiedCertificate Link between a SCD stored in the TOE and the relevant
qualified certificate
The Subject in charge of creating and updating the SCD (Personalization Agent,
Administrator, Signatory), or the remote IT entity involved in the updating process (the
SSCD, the CGA) shall ensure an unambiguous link between the SCD(s) and the
matching (qualified) certificate(s). This link might be figured out by a PKCS#15
structures, an XML structure, an identifier .linking a SCD to the file containing the
qualified certificate or the URL hosting them. In particular, it implies it is updated, each
time the SCD is created, imported, erased or generated.
OE.ControlOfAppletToBeLoaded_Contactless Control of the other applet that may be
loaded on the javacard open platform
Prior to any applet loading, the entity in charge of administrating the javacard open
platform shall make sure the applet does not disclose identification data that may be
used by an attacker to track the TOE in contactless mode (e.g a static identifier in free
access,…)
OE.AuthKey_Transfer Secure transfer of Authentication key(s) to the TOE
The entity in charge of generating the authentication keys to be loaded in the TOE shall
ensure the confidentiality of the key(s) transferred to the TOE.
OE.AuthKey_Unique Uniqueness of the authentication key(s)
The entity in charge of generating the authentication keys to be loaded in the TOE shall
ensure the cryptographic quality of the authentication key(s). The authentication key
used for authentication can practically occur only once and, in case of a TOE
authentication key cannot be reconstructed from its public portion. In that context
‘practically occur once’ means that the probability of equal keys is negligible low.
OE.TOE_PublicAuthKey_Transfer Secure transfer of Public Authentication key(s) of the
TOE
The entity in charge of generating the authentication certificate from the TOE’s
authentication public key generated in the TOE shall ensure the authenticity of this data
when transferred from the TOE. This may be achieved by the retrieval of the public key
according to certain rules imposed to the TOE holders.
OE.TOE_Construction Construction of the TOE by the Personnalization Agent
Copyright 2010 © 50 FQR 110 4773 Ed3
The Personalization Agent in charge of administrating the TOE in phase 6 shall be a
trusted person and shall be skilled enough to correctly apply the recommandations
indicated in [AGD_PRE]. These recommandations are required to construct the TOE
3.10. TOE Security functional requirements
3.10.1. FCS: CRYPTOGRAPHIC SUPPORT
FCS_CKM.1 Cryptographic key generation
FCS CKM.1.1 / RSA
The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation
algorithm [RSA key generation] and specified cryptographic key sizes [1024 bits or 1536 bits or 2048
bits] that meet the [ANSI X9.31]
FCS CKM.1.1 / DES session keys
The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation
algorithm [DES key generation] and specified cryptographic key sizes [128 bits] that meet the [IASECC]
Refinement Note:
The hashing algorithm used by the TOE to generate the session keys from the Seed is the SHA-1
and SHA-256.
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.4.1 / SCD/SVD
The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction
method [overwriting the buffer containing the key with zero] that meets the following: [none].
Refinement:
This SFR applies to all asymmetric keys, whether it is a qualified signature key (SCD or SVD), a
TOE authentication key (TOE_AUTH_PUBLIC_KEYS and TOE_AUTH_PRIVATE_KEYS), an
eServices key (ESERVICES_KEYS except the Diffie Hellman Domain parameters).
Application note:
The cryptographic key SCD will be destroyed on demand of the Signatory or Administrator. The
destruction of the SCD is mandatory before the SCD is re-imported into the TOE.
FCS_CKM.4.1 / Symmetric keys
The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction
method [overwriting the buffer containing the key with zero] that meets the following: [none].
Application note:
The Symmetric DES key includes the keys used for the device authentication and the External
Role authentication based on the symmetric scheme (both belonging to AUTH_KEYS) as well as
the secure messaging session keys.
Copyright 2010 © 51 FQR 110 4773 Ed3
The destruction of the previous keys is mandatory when they are updated
FCS_COP Cryptographic operation
FCS_COP.1 Cryptographic operation
FCS_COP.1.1/ CORRESP
The TSF shall perform [SCD/SVD correspondence verification] in accordance with a specified
cryptographic algorithm [PKCS #1 V1.5 Block Type 1 with Message Digest Info with RSA CRT] and
cryptographic key sizes [1024 bits, 1536 bits or 2048 bits] that meet the following: [PKCS #1 v1.5].
FCS_COP.1.1/ SIGNING
The TSF shall perform [Digital signature-generation] in accordance with a specified cryptographic
algorithm [PKCS #1 V1.5 Block Type 1 with Message Digest Info addition with RSA CRT key] and
cryptographic key sizes [1024 bits, 1536 bits or 2048 bits] that meet the following: [PKCS #1 v1.5].
FCS_COP.1.1/ Diffie Hellman computation
The TSF shall perform [Key Agreement] in accordance with a specified cryptographic algorithm [Diffie
Hellmann] and cryptographic key sizes [1024 bits, 1536 bits or 2048 bits] that meet the following:
[PKCS#3].
FCS_COP.1.1/ Secure Messaging in Confidentiality
The TSF shall perform [Secure Messaging in confidentiality] in accordance with a specified
cryptographic algorithm [Retail MAC] and cryptographic key sizes [128 bits] that meet the following:
[IASECC].
Application Note: This algorithm is used during secure Messaging: in confidentiality of incoming
and outgoing data
FCS_COP.1.1/ Secure Messaging in Integrity
The TSF shall perform [Secure Messaging in integrity] in accordance with a specified cryptographic
algorithm [Triple DES CBC encryption/decryption] and cryptographic key sizes [128 bits] that meet the
following: [IASECC].
Application Note: This algorithm is used during secure Messaging: in integrity of incoming and
outgoing data
FCS_COP.1.1/ Data hashing
The TSF shall perform [data hashing] in accordance with a specified cryptographic algorithm [SHA-1 and
SHA-256] and cryptographic key sizes [none] that meet the following: [FIPS 140-2].
Application Note: This SFR corresponds to the data hashing used by the TOE.
FCS_COP.1.1/ C/S Authentication
Copyright 2010 © 52 FQR 110 4773 Ed3
The TSF shall perform [C/S Authentication] in accordance with a specified cryptographic algorithm
[PKCS #1 V1.5 Block Type 1 without Message Digest Info addition with RSA CRT key] and
cryptographic key sizes [1024 bits, 1536 bits or 2048 bits] that meet the following: [PKCS#1 v1.5].
FCS_COP.1.1/ Encryption key decipherment
The TSF shall perform [Encryption key decipherment] in accordance with a specified cryptographic
algorithm [PKCS #1 V1.5 Block Type 2 without Message Digest Info addition with RSA CRT key] and
cryptographic key sizes [1024 bits, 1536 bits or 2048 bits] that meet the following: [PKCS#1 v1.5].
FCS_COP.1.1/ Symmetric Role Authentication
The TSF shall perform [Symmetric Role Authentication] in accordance with a specified cryptographic
algorithm [based on Triple DES] and cryptographic key sizes [128 bits] that meet the following:
[IASECC].
FCS_COP.1.1/ Symmetric Device Authentication
The TSF shall perform [Symmetric Device Authentication] in accordance with a specified cryptographic
algorithm [based on Triple DES] and cryptographic key sizes [128 bits] that meet the following:
[IASECC].
FCS_COP.1.1/ Certificate Verification
The TSF shall perform [Certificate verification] in accordance with a specified cryptographic algorithm
[RSA with ISO9796-2 padding with partial recovery and with SHA-1 or SHA-256] and cryptographic
key sizes [1024 bits, 1536 bits or 2048 bits] that meet the following: [IASECC].
FCS_COP.1.1/ Asymmetric Role Authentication
The TSF shall perform [Asymmetric Role Authentication] in accordance with a specified cryptographic
algorithm [RSA with ISO9796-2 padding with partial recovery and with SHA-1 or SHA-256] and
cryptographic key sizes [1024 bits, 1536 bits or 2048 bits] that meet the following: [IASECC].
FCS_COP.1.1/ Asymmetric Internal DAPP Authentication
The TSF shall perform [Asymmetric Internal DAPP Authentication] in accordance with a specified
cryptographic algorithm [RSA with ISO9796-2 padding with partial recovery and with SHA-1 or SHA-
256] and cryptographic key sizes [1024 bits, 1536 bits or 2048 bits] that meet the following: [IASECC].
FCS_COP.1.1/ Asymmetric External DAPP Authentication
The TSF shall perform [Asymmetric External DAPP Authentication] in accordance with a specified
cryptographic algorithm [RSA with ISO9796-2 padding with partial recovery and with SHA-1 or SHA-
256] and cryptographic key sizes [1024 bits, 1536 bits or 2048 bits] that meet the following: [IASECC].
FCS_COP.1.1/ GP Authentication
Copyright 2010 © 53 FQR 110 4773 Ed3
The TSF shall perform [GP Authentication] in accordance with a specified cryptographic algorithm
[assignment: cryptographic algorithm] and cryptographic key sizes [128 bits] that meet the following:
[assignment: list of standards].
Refinement :
cryptographic algorithm list of standards
Triple DES SCP1 and SCP02 as defined in [GP]
AES SCP03 as defined in [GP]
Application Note: The type of algorithm used by the TOE depends on the
configuration set during the platform personalisation (For more details see
[AGD_CLIO/THALIE]. The algorithm selection is performed by the subject
R.Prepersonalizer and is covered by FMT_MTD.1/JCRE
FCS_COP.1.1/ GP secret data encryption
The TSF shall perform [GP secret data encryption] in accordance with a specified cryptographic
algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [128 bits] that meet the
following: [assignment: list of standards].
Refinement :
cryptographic algorithm list of standards
Triple DES SCP1 and SCP02 as defined in [GP]
AES SCP03 as defined in [GP]
Application Note: The type of algorithm used by the TOE depends on the
configuration set during the javacard open platform personalisation (For more
details see [AGD_CLIO/THALIE]). The algorithm selection is performed by the
subject R.Prepersonalizer and is covered by FMT_MTD.1/JCRE
FCS_RNG Random Number Generation
FCS_RNG.1 / Random Number Generation
FCS_RNG.1.1
The TSF shall provide a [hybrid] random number generator that implements: [none].
FCS_RNG.1.2
The TSF shall provide random numbers that meet [khi 2 test].
Copyright 2010 © 54 FQR 110 4773 Ed3
3.10.2. FDP : USER DATA PROTECTION
FDP_ACC Access Control Policy
FDP_ACC.1.1/SVD transfer SFP
The TSF shall enforce the [SVD transfer SFP] on [import and export of SVD by User or Personalizer].
FDP_ACC.1.1/Initialisation SFP
The TSF shall enforce the [Initialisation SFP] on [Generation of SCD/SVD pair by User or
Personalizer].
FDP_ACC.1.1/ Personalisation SFP
The TSF shall enforce the [Personalisation SFP] on [Creation of PIN RAD by Administrator or
Personalizer].
FDP_ACC.1.1/Signature-creation SFP
The TSF shall enforce the [Signature-creation SFP] on
[Sending of DTBS representation by SCA]
[Signing of DTBS-representation by Signatory].
FDP_ACC.1.1/SCD Import SFP
The TSF shall enforce the [SCD Import SFP] on [Import of SCD by User or Personalizer].
FDP_ACC.1.1/IAS ECC Administration SFP
The TSF shall enforce the [IAS ECC Administration SFP] on [Management of Medium, HashOffCard,
SymAuthMechanisms and AsymAuthMechanisms by the TOE Administrator or Personalizer].
FDP_ACC.1.1/Key Management SFP
The TSF shall enforce the [Key Management SFP] on [import of AUTH_KEYS,
TOE_AUTH_PRIVATE_KEYS, TOE_AUTH_PUBLIC_KEYS and ESERVICES_KEYS, generation of
TOE_AUTH_PRIVATE_KEYS/TOE_AUTH_PUBLIC_KEYS and ESERVICES_KEYS (except Diffie
Hellman Domain parameters), export of TOE_AUTH_PUBLIC_KEYS, public portion of
ESERVICES_KEYS (including Diffie Hellman Domain parameters ) by the User or Personalizer].
FDP_ACC.1.1/Protection against eavesdropping SFP
The TSF shall enforce the [Protection against eavesdropping SFP] on [receiving RAD, VAD, SVD,
DTBS, ESERVICES_KEYS, AUTH_KEYS, TOE_AUTH_PUBLIC_KEYS , TOE_AUTH_PRIVATE_KEYS
and exporting IDENTIFICATION_DATA, SVD, TOE_AUTH_PUBLIC_KEYS, public portion of
ESERVICES_KEYS (except Diffie Hellman Domain parameters) and SIGNATURE].
Copyright 2010 © 55 FQR 110 4773 Ed3
FDP_ACF Security attribute based access control
Here is a mapping between the user, subject, objet, attribute and attached status as defined in [SSCD2] &
[SSCD3].
General Attribute
Subject Attribute Status Remark
S.Admin
Several User with the
status S.Admin may
be distinguished by
the TOE
The Role S.Admin
may be granted upon
successful
authentication based
on a cryptographic
mean or on a RAD
(PIN) verification
This subject can only
interact in phase 7 of
the life cycle
S.Signatory
The Role S.Signatory
may be granted upon
successful
authentication based
on a RAD verification
This subject can only
interact in phase 7 of
the life cycle
User,
Personalizer
Role
S.Personalizer
The Role
S.Personalizer may
be granted upon
successful GP
authentication based
on a cryptographic
mean
This subject can only
interact in phase 6 of
the life cycle
Copyright 2010 © 56 FQR 110 4773 Ed3
Administration group
TOE Attributes Meaning Status Remark
Contact
Medium
Communication
medium allowed
Contactless
The TOE may be
configured to allow
communication in
contact and/or
contactless mode.
The
communication to
be used by the
TOE may be
changed in phase
6 by
S.Personalizer
and in phase 7 by
S.TOE_Admin
Authorized
HashOffCard
Qualified signature
computed over hash
computed off card
Not authorized
The TOE may be
configured to allow
the qualified
signature to be
computed from a
hash off card. It
may be changed in
phase 6 by
S.Personalizer
and in phase 7 by
S.TOE_Admin
Authorized
SymAuthMechanisms
Authentication
mechanisms based on
symmetric scheme
allowed
Not authorized
The TOE may be
configured to
enable/disable the
authentication
mechanism based
on symmetric
scheme. It may be
changed in phase
6 by
S.Personalizer
and in phase 7 by
S.TOE_Admin
Authorized
AsymAuthMechanisms
Authentication
mechanisms based on
asymmetric scheme
allowed
Not authorized
The TOE may be
configured to
enable/disable the
authentication
mechanism based
on asymmetric
scheme. It may be
changed in phase
6 by
S.Personalizer
Copyright 2010 © 57 FQR 110 4773 Ed3
and in phase 7 by
S.TOE_Admin
Copyright 2010 © 58 FQR 110 4773 Ed3
Initialisation attribute group
Subject Security Attribute Status Remark
Authorized
User, Personalizer
SCD/SVD
Management
Not authorized
The TOE controls the
access on every object it
possess, in particular the
SCD and the SVD.
In phase 6, the subject
with the role
S.Personalizer has the
attribute SCD/SVD
Management set to
Authorized.
In Phase 7, two access
mode may be
distinguished by the TOE
• SCD/SVD generation
(type 3)
• SCD/SVD import
(type 2)
The access condition is
granted to a User if the
following conditions are
fulfilled:
• The User is
successfully
authenticated
• The User was given
the right to manage
the SCD & SVD
(import and/or
generation) by the
TOE issuer.
If theses two conditions
are fulfilled, the attribute
SCD/SVD management
is set to authorized,
otherwise it is set to not
authorized
This subject can only
interact in phase 7 of the
life cycle
Copyright 2010 © 59 FQR 110 4773 Ed3
User Data Security Attribute Status Remark
No
SCD Secure SCD Import Allowed
Yes
The TOE controls the access on every
object it possess, in particular the SCD.
In phase 6, the key is imported from a
SSCD type 1. The SSCD securely
transmits the SCD to the TOE by mean
of an encryption key. The encryption
key is deduced from diversifying data
agreed during the authentication of
S.Personnalizer with the TOE.
Therefore, the security attribute Secure
SCD import is set to Yes when the
Subject has the role S.Personalizer
In phase 7, the access mode SCD
Import may be refined to ensure the
SCD is imported
• from an entitled entity (SSCD
type 1)
• through a trusted channel
ensuring the confidentiality and
integrity of the data exchanged
This refinement does not conflict with
SCD/SVD Management
The access condition is granted to a
remote entities if the following
conditions are fulfilled:
• The remote entities is
successfully authenticated
• The remote entities sends the
SCD through a secure channel
ensuring confidentiality and
integrity
If theses two conditions are fulfilled, the
attribute Secure SCD Import Allowed
is set to Yes, otherwise it is set to No
Copyright 2010 © 60 FQR 110 4773 Ed3
Signature-creation attribute group
User Data Security Attribute Status Remark
No
SCD SCD operational
Yes
The attribute SCD operational is granted by the
submission of the RAD by the User S.Signatory
No
DTBS
Sent by an authorized
SCA
Yes
The TOE imposes the DTBS to be sent just
before the signature computation request.
As the TOE controls the access on every object it
possess, in particular the SCD and the SVD,
requesting the SCD to be sent by an authorized
SCA will ensure the attribute Sent by an
authorized SCA for the DTBS is controlled.
Key Management group
Subject Security Attribute Status Remark
Authorized
User
SCA
CGA
SSCD type 1
IFD
Personalizer
Key import
Management
Not authorized
In phase 6, the subject with the role
S.Personalizer has the attribute
Key import Management set to
Authorized
In phase 7, the TOE controls the
access on every object it possess,
in particular a key belonging to the
AUTH_KEYS,
ESERVICES_KEYS,
TOE_AUTH_PRIVATE_KEYS or
TOE_AUTH_PUBLIC_KEYS.
The access condition is granted to
User, SCA, CGA, SSCD type 1 or
IFD if the following conditions are
fulfilled:
The Subject is successfully
authenticated
The Subject was given the right to
import a key (belonging to groups
indicated above)
If theses two conditions are fulfilled,
the attribute Key import
management is set to authorized,
otherwise it is set to not authorized
This subject can only interact in
phase 7 of the life cycle
Copyright 2010 © 61 FQR 110 4773 Ed3
Authorized
Key generation
Management
Not authorized
In phase 6, the subject with the role
S.Personalizer has the attribute
Key generation Management set to
Authorized
In phase 7, the TOE controls the
access on every object it possess,
in particular a key belonging to the
ESERVICES_KEYS (including
Diffie Hellmann Domain
parameters)
TOE_AUTH_PRIVATE_KEYS or
TOE_AUTH_PUBLIC_KEYS.
The access condition is granted to
User, SCA, CGA, SSCD type 1 or
IFD if the following conditions are
fulfilled:
The Subject is successfully
authenticated
The Subject was given the right to
generate a key (belonging to
groups indicated)
If theses two conditions are fulfilled,
the attribute Key generation
management is set to authorized,
otherwise it is set to not authorized
This subject can only interact in
phase 7 of the life cycle
Authorized
Key export
Management
Not authorized
In phase 6, the subject with the role
S.Personalizer has the attribute
Key export Management set to
Authorized
In phase 7, the TOE controls the
access on every object it possess,
in particular a key belonging to the
public portions of
ESERVICES_KEYS (including
Diffie Hellmann Domain
parameters, and
TOE_AUTH_PUBLIC_KEYS.
The access condition is granted to
User, SCA, CGA, SSCD type 1 or
IFD if the following conditions are
fulfilled:
The Subject is successfully
authenticated
The Subject was given the right to
export a key (belonging to groups
Copyright 2010 © 62 FQR 110 4773 Ed3
indicated)
If theses two conditions are fulfilled,
the attribute Key export
management is set to authorized,
otherwise it is set to not authorized
This subject can only interact in
phase 7 of the life cycle
Copyright 2010 © 63 FQR 110 4773 Ed3
Protection against eavesdropping group
User Security Attribute Status Remark
Not
authorized
IFD
Data exchange in
contactless
authorized
The TOE controls the access on every
object it possesses, in particular the
DTBS, VAD, SIGNATURE, RAD,
SVD, AUTH_KEYS,
ESERVICES_KEYS,
TOE_AUTH_PRIVATE_KEYS or
TOE_AUTH_PUBLIC_KEYS.
The access condition is granted to IFD
if the following conditions are fulfilled:
The Subject is successfully
authenticated
The Subject was given the right to
import/export the data
A secure channel exists in order to
protect the data exchange
If theses three conditions are fulfilled,
the attribute “Data exchange in
contactless “ is set to authorized,
otherwise it is set to not authorized
SVD transfer SFP
FDP_ACF.1.1/ SVD transfer SFP
The TSF shall enforce the [SVD transfer SFP] to objects based on [General attribute]
FDP_ACF.1.2/ SVD transfer SFP
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed:
(a) [In phase 7, the User with the security attribute "role" set to “Administrator” or
"Signatory" is allowed to export SVD]
(b) [In phase 6, the subject with the security attribute "role" set to “Personalizer” is allowed
to export SVD in phase 6.]
Refinement note:
Depending on the use case, the “role” allowed to export the SVD may be restricted to
“Administrator” (or one of its sub-subjects : SCA, CGA, SSCD, IFD) or to “Signatory”
FDP_ACF.1.3/ SVD transfer SFP
The TSF shall explicitly authorise access of subjects to objects based on the following additional rules:
[none]
FDP_ACF.1.4/ SVD transfer SFP
The TSF shall explicitly deny access of subjects to objects based on the rule: [none]
Application note:
The SVD may be exported in phase 6 & 7 of the life cycle
Copyright 2010 © 64 FQR 110 4773 Ed3
Initialisation SFP
FDP_ACF.1.1/ Initialisation SFP
The TSF shall enforce the [Initialisation SFP] to objects based on [General attribute] and [Initialisation
attribute group].
FDP_ACF.1.2/ Initialisation SFP
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed:
(a) [In phase 7, the user with the security attribute "role" set to "Administrator" or set to
"Signatory" and with the security attribute "SCD/SVD management" set to "authorised" is allowed
to generate SCD/SVD pair.]
(b) [In phase 6, the subject with the security attribute "role" set to "Personalizer" is allowed
to generate SCD/SVD pair.]
Refinement note:
Depending on the use case, the “role” allowed to generate the SCD/SVD may be restricted to
“Administrator” (or one of its sub-subjects : SCA, CGA, SSCD, IFD) or to “Signatory”
FDP_ACF.1.3/ Initialisation SFP
The TSF shall explicitly authorise access of subjects to objects based on the following additional rules:
[none]
FDP_ACF.1.4/ Initialisation SFP
The TSF shall explicitly deny access of subjects to objects based on the rule:
(a) [In phase 7, the user with the security attribute "role" set to "Administrator" or set to
"Signatory" and with the security attribute "SCD/SVD management" set to "not authorised" is not
allowed to generate SCD/SVD pair.]
(b) [In phase 6, the subject without the security attribute "role" set to " Personalizer " is not
allowed to generate SCD/SVD pair.]
Application note:
The Initialization SFP applies in phase 6 & 7 of the life cycle
SCD Import SFP
FDP_ACF.1.1/ SCD Import SFP
The TSF shall enforce the [SCD Import SFP] to objects based on [General attribute] and [Initialisation
attribute group].
FDP_ACF.1.2/ SCD Import SFP
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed:
(a) [In phase 7, the user with the security attribute "role" set to "Administrator" or set to
"Signatory" and with the security attribute "SCD/SVD management" set to "authorised" is allowed
to import SCD if the security attribute "secure SCD import allowed" is set to "yes".]
(b) [In phase 6, the subject with the security attribute "role" set to "Personalizer" is allowed
to import SCD]
Refinement note:
Depending on the use case, the “role” allowed to import the SCD may be restricted to
“Administrator” (or one of its sub-subjects : SCA, CGA, SSCD, IFD) or to “Signatory”
Copyright 2010 © 65 FQR 110 4773 Ed3
The role “Personalizer” implies that the security attribute “SCD/SVD Management” is set to
“authorized” and “secure SCD import allowed” is set to Yes.
FDP_ACF.1.3/ SCD Import SFP
The TSF shall explicitly authorise access of subjects to objects based on the following additional rules:
[none]
FDP_ACF.1.4/ SCD Import SFP
The TSF shall explicitly deny access of subjects to objects based on the rule:
(a) [In phase 7, the user with the security attribute "role" set to "Administrator" or to
"Signatory" and with the security attribute "SCD/SVD management" set to "not authorised" is not
allowed to import SCD if the security attribute "secure SCD import allowed" is set to "yes".]
(b) [In phase 7, the user with the security attribute "role" set to "Administrator" or to
"Signatory" and with the security attribute "SCD/SVD management" set to "authorised" is not
allowed to import SCD if the security attribute "secure SCD import allowed" is set to "no".]
(c) [In phase 6, the user without the security attribute "role" set to " Personalizer " is not
allowed to import SCD.]
Application note:
The SCD Import SFP applies in phase 6 & 7 of the life cycle
The SCD import SFP enables as well to erase the SCD
Personalisation SFP
FDP_ACF.1.1/ Personalisation SFP
The TSF shall enforce the [Personalisation SFP] to objects based on Personalisation SFP [General
attribute group]
FDP_ACF.1.2/ Personalisation SFP
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed:
(a) [In phase 7, the User with the security attribute "role" set to "Administrator" is allowed
to create the RAD]
(b) [In phase 6, the subject with the security attribute "role" set to "Personalizer" is allowed
to create the RAD]
Refinement note:
Depending on the use case, the “role Administrator” allowed to create the PIN may be restricted to
a sub-subjects or Administrator (SCA, CGA, SSCD, IFD)
FDP_ACF.1.3/ Personalisation SFP
The TSF shall explicitly authorise access of subjects to objects based on the following additional rules:
[none]
FDP_ACF.1.4/ Personalisation SFP
The TSF shall explicitly deny access of subjects to objects based on the rule: [none]
Application note:
The Personalization SFP applies in phase 6 & 7 of the life cycle
Copyright 2010 © 66 FQR 110 4773 Ed3
Signature Creation SFP
FDP_ACF.1.1/ Signature-creation SFP
The TSF shall enforce the [Signature-creation SFP] to objects based on [General attribute group] and
[Signature-creation attribute group].
FDP_ACF.1.2/ Signature-creation SFP
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed:
[In phase 7, the User with the security attribute "role" set to "Signatory" is allowed to create
electronic signatures for DTBS sent by an authorized SCA with SCD by the Signatory which
security attribute "SCD operational" is set to "yes"]
FDP ACF.1.3/ Signature-creation SFP
The TSF shall explicitly authorise access of subjects to objects based on the following additional rules:
[none]
FDP_ACF.1.4/ Signature-creation SFP
The TSF shall explicitly deny access of subjects to objects based on the rule:
(a) [In phase 6 and 7, User with the security attribute "role" set to "Signatory" is not allowed to
create electronic signatures for DTBS which is not sent by an authorized SCA with SCD by the
Signatory which security attribute "SCD operational" is set to "yes".]
(b) [In phase 6 and 7, User with the security attribute "role" set to "Signatory" is not allowed to
create electronic signatures for DTBS sent by an authorized SCA with SCD by the Signatory
which security attribute "SCD operational" is set to "no".]
(c) [In phase 6, User with the security attribute "role" set to "Signatory" is not allowed to create
electronic signatures for DTBS sent by an authorized SCA with SCD by the Signatory which
security attribute "SCD operational" is set to "yes".]
Application note:
The Signature creation SFP applies in phase 6 and 7 of the life cycle
IAS ECC Administration SFP
FDP_ACF.1.1/ IAS ECC Administration SFP
The TSF shall enforce the [IAS ECC Administration SFP] to objects based on [Administration group].
FDP_ACF.1.2/ IAS ECC Administration SFP
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed:
(a) [In phase 7, Subject with the security attribute "role" set to "TOE_Administrator" is
allowed to modify the TOE attributes]
(b) [In phase 6, Subject with the security attribute "role" set to “Personalizer” is allowed to
modify the TOE attributes]
FDP ACF.1.3/ IAS ECC Administration SFP
The TSF shall explicitly authorise access of subjects to objects based on the following additional rules:
[none]
Copyright 2010 © 67 FQR 110 4773 Ed3
FDP_ACF.1.4/ IAS ECC Administration SFP
The TSF shall explicitly deny access of subjects to objects based on the rule:
(a) [In phase 7, Subject without the security attribute "role" set to "TOE_Administrator" is
allowed to modify the TOE attributes]
(b) [In phase 6, Subject without the security attribute "role" set to “Personalizer” is allowed
to modify the TOE attributes]
Application note:
The IAS ECC Administration SFP applies in phase 6 & 7 of the life cycle
Key Management SFP
FDP_ACF.1.1/ Key Management SFP
The TSF shall enforce the [Key Management SFP] to objects based on [Key Management group].
FDP_ACF.1.2/ Key Management SFP
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed:
(a) [In phase 7, the subject with the security attribute "role" set to "Administrator",
"Signatory", “SCA”, CGA”, “IFD” or “SSCD type 1” and with the security attribute "Key import
Management" set to "authorised".]
(b) [In phase 6, the subject with the security attribute "role" set to “Personalizer” is allowed
to import a AUTH_KEYS, ESERVICES_KEYS, TOE_AUTH_PRIVATE_KEYS, and
TOE_AUTH_PUBLIC_KEYS.]
(c) [In phase 7, the subject with the security attribute "role" set to "Administrator",
"Signatory", “SCA”, CGA”, “IFD” or “SSCD type 1” and with the security attribute "Key generation
Management" set to "authorised".]
(d) [In phase 6, the subject with the security attribute "role" set to “Personalizer” is allowed
to generate a ESERVICES_KEYS (except Diffie Hellman Domain parameters),
TOE_AUTH_PRIVATE_KEYS/TOE_AUTH_PUBLIC_KEYS.]
(e) [In phase 7, the subject with the security attribute "role" set to "Administrator",
"Signatory", “SCA”, CGA”, “IFD” or “SSCD type 1” and with the security attribute "Key export
Management" set to "authorised".]
(f) [In phase 6, the subject with the security attribute "role" set to “Personalizer” is allowed
to export a public portion of an ESERVICES_KEYS (including Diffie Hellman Domain parameters),
and TOE_AUTH_PUBLIC_KEYS.]
Refinement note:
Depending on the use case considered, the list of subjects allowed to import, generate or export
the keys may be reduced to several of them (Some may be excluded)
The role “Personalizer” implies that the security attributes are set to “authorized”.
FDP ACF.1.3/ Key Management SFP
The TSF shall explicitly authorise access of subjects to objects based on the following additional rules:
[none]
FDP_ACF.1.4/ Key Management SFP
The TSF shall explicitly deny access of subjects to objects based on the rule: [none]
Application note:
Copyright 2010 © 68 FQR 110 4773 Ed3
The Key Management SFP applies in phase 6 & 7 of the life cycle
The Key Management SFP enables as well to erase the RSA keys (public and provate portion)
Protection against eavesdropping SFP
FDP_ACF.1.1/ Protection against eavesdropping SFP
The TSF shall enforce the [Protection against eavesdropping SFP] to objects based on [Protection
against eavesdropping group].
FDP_ACF.1.2/ Protection against eavesdropping SFP
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed:
[In phase 7, the user with the security attribute "role" set to "IFD" and with the security attribute "
data exchange in contactless allowed " set to "authorised" is allowed to import and export data]
FDP ACF.1.3/ Protection against eavesdropping SFP
The TSF shall explicitly authorise access of subjects to objects based on the following additional rules:
[none]
FDP_ACF.1.4/ Protection against eavesdropping SFP
The TSF shall explicitly deny access of subjects to objects based on the rule:
(a) [In phase 7, the user without the security attribute "role" set to "IFD" and with the
security attribute "data exchange in contactless" set to "authorised" is not allowed to import and
export data]
(b) [In phase 7, the user with the security attribute "role" set to "IFD" and without the
security attribute "data exchange in contactless" set to "not authorised" is not allowed to import
and export data]
Application note:
The Protection against eavesdropping SFP applies in phase 7 of the life cycle
FDP_ETC : Export to outside TSF control
SVD Transfer
FDP_ETC.1.1/ SVD transfer
The TSF shall enforce the [SVD transfer SFP] when exporting user data, controlled under the SFP(s),
outside of the TOE.
FDP_ETC.1.2/ SVD transfer
The TSF shall export the user data without the user data's associated security attributes.
Application note:
The Export of user data applies in phase 6 & 7 of the life cycle
Keys Transfer
Copyright 2010 © 69 FQR 110 4773 Ed3
FDP_ETC.1.1/ Keys transfer
The TSF shall enforce the [Key Management SFP] when exporting user data, controlled under the
SFP(s), outside of the TOE.
FDP_ETC.1.2/ Keys transfer
The TSF shall export the user data without the user data's associated security attributes.
Application note:
The Export of user data applies in phase 6 & 7 of the life cycle
Transfer protected against eavesdropping
FDP_ETC.1.1/ Transfer protected against eavesdropping
The TSF shall enforce the [Protection against eavesdropping SFP] when exporting user data,
controlled under the SFP(s), outside of the TOE.
FDP_ETC.1.2/ Transfer protected against eavesdropping
The TSF shall export the user data without the user data's associated security attributes.
Application note:
The Export of user data applies in phase 7 of the life cycle
FDP_ITC Import from outside TSF control
SCD Import
FDP_ITC.1.1/ SCD
The TSF shall enforce the [SCD Import SFP] when importing user data, controlled under the SFP, from
outside of the TOE.
FDP_ITC.1.2/ SCD
The TSF shall ignore any security attributes associated with the user data when imported from outside the
TOE.
FDP_ITC.1.3/ SCD
The TSF shall enforce the following rules when importing user data controlled under the SFP from outside
the TOE: [SCD shall be sent by an Authorised SSCD].
Application note:
A SSCD of Type 1 is authorized to send SCD to a SSCD of Type 2, if it is designated to generate
the SCD for this SSCD of Type 2 and to export the SCD for import into this SSCD of Type 2.
Authorized SSCD of Type 1 is able to establish a trusted channel to the SSCD of Type 2 for SCD
transfer as required by FTP_ITC.1.3/SCD export.
In phase 6, an authorized SSCD is the one that received from S.Personnalizer the correct
diversification data to correctly encrypt the SCD to transmit to the TOE.
DTBS import
Copyright 2010 © 70 FQR 110 4773 Ed3
FDP_ITC.1.1/ DTBS
The TSF shall enforce the [Signature-creation SFP] when importing user data, controlled under the SFP,
from outside of the TOE.
FDP_ITC.1.2/ DTBS
The TSF shall ignore any security attributes associated with the user data when imported from outside the
TOE.
FDP_ITC.1.3/ DTBS
The TSF shall enforce the following rules when importing user data controlled under the SFP from outside
the TOE: [DTBS-representation shall be sent by an Authorised SCA].
Application note:
A SCA is authorized to send the DTBS-representation if it is actually used by the Signatory to create
an electronic signature and able to establish a trusted channel to the SSCD as required by
FTP_ITC.1.3/SCA DTBS.
Keys import
FDP_ITC.1.1/ Keys
The TSF shall enforce the [Key Management SFP] when importing user data, controlled under the SFP,
from outside of the TOE.
FDP_ITC.1.2/ Keys
The TSF shall ignore any security attributes associated with the user data when imported from outside the
TOE.
FDP_ITC.1.3/ Keys
The TSF shall enforce the following rules when importing user data controlled under the SFP from outside
the TOE: [Keys belonging to AUTH_KEYS or ESERVICES_KEYS groups shall be sent by the
administrator, the Personalizer, the SCA, the CGA, the IFD or the SSCD type 1].
Application note:
These SFRs only applies for the import of user data envisioned by the Key Management SFP
Depending on the use case considered, a choice may be done between the administrator, the
Personalizer, the SCA, the CGA, the IFD or the SSCD type 1..
FDP_RIP Residual information protection
FDP_RIP.1.1
The TSF shall ensure that any previous information content of a resource is made unavailable upon the [de-
allocation of the resource from] the following objects: [SM_DATA, AUTH_CRYPTOGRAM,
AUTH_KEYS, ESERVICES_KEYS, EPHEMERAL_KEYS, TOE_AUTH_PUBLIC_KEYS,
TOE_AUTH_PRIVATE_KEYS, SCD, VAD, and RAD].
Copyright 2010 © 71 FQR 110 4773 Ed3
FDP_SDI Stored data integrity
Persistent data
The following data persistently stored by TOE have the user data attribute "integrity checked persistent
stored data"
• SCD
• RAD
• SVD
• AUTH_KEYS
• ESERVICES_KEYS
FDP_SDI.2.1/ Persistent
The TSF shall monitor user data stored in containers controlled by the TSF for [integrity error] on all
objects, based on the following attributes: [integrity checked persistent stored data].
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 Signatory about integrity error.]
DTBS-representation
The Protection Profiles [SSCD2] and [SSCD3] specify that the DTBS representation temporarily stored by
TOE have the user data attribute "integrity checked stored data".
FDP_SDI.2.1/ DTBS
The TSF shall monitor user data stored in containers controlled by the TSF for [integrity error] on all
objects, based on the following attributes: [integrity checked stored data].
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 Signatory about integrity error.]
FDP_UCT Inter-TSF user data confidentiality transfer protection
SCD Import
FDP_UCT.1.1/ Receiver
The TSF shall enforce the [SCD Import SFP] to be able to [receive] user data in a manner protected from
unauthorised disclosure.
Application note:
The TSF ensures protection of the SCD against unauthorized disclosure in phase 6 & 7 of the life
cycle
Protection against eavesdropping in contactless
Copyright 2010 © 72 FQR 110 4773 Ed3
FDP_UCT.1.1/ TOE Contactless
The TSF shall enforce the [Protection against eavesdropping SFP] to be able to [receive and transmit]
user data in a manner protected from unauthorised disclosure.
Application Note:
This SFRs only applies in phase 7, when the SSCD features are used in contactless.
FDP_UIT Inter-TSF user data integrity transfer protection
SVD transfer
FDP_UIT.1.1/ SVD transfer
The TSF shall enforce the [SVD transfer SFP] to be able to [transmit] user data in a manner protected
from [modification and insertion] errors.
Refinement
This SFR only applies in phase 7
FDP_UIT.1.2/ SVD transfer
The TSF shall be able to determine on receipt of user data, whether [modification and insertion] has
occurred.
DTBS transfer
FDP_UIT.1.1/ TOE DTBS
The TSF shall enforce the [Signature-creation SFP] to be able to [receive] user data in a manner
protected from [modification, deletion and insertion] errors.
FDP_UIT.1.2/ TOE DTBS
The TSF shall be able to determine on receipt of user data, whether [modification, deletion and
insertion] has occurred.
Protection against eavesdropping in contactless
FDP_UIT.1.1/ TOE Contactless
The TSF shall enforce the [Protection against eavesdropping SFP] to be able to [receive and transmit]
user data in a manner protected from [modification, deletion and insertion] errors.
FDP_UIT.1.2/ TOE Contactless
The TSF shall be able to determine on receipt of user data, whether [modification, deletion and
insertion] has occurred.
Application Note:
These SFRs only applies in phase 7, when the SSCD features are used in contactless
3.10.3. FIA: IDENTIFICATION AND AUTHENTICATION
FIA_AFL Authentication failure
FIA_AFL is specific to the RAD and the Authentication keys.
• RAD used by the Signatory
Copyright 2010 © 73 FQR 110 4773 Ed3
• RAD used by the Administrator.
• The Symmetric key(s) used by the Personalization Agent
• The Symmetric key(s) used by the TOE Administrator
• Symmetric external authentication keys used by the Administrator
• Symmetric device authentication keys used by the Administrator or a remote IT
• Assymmetric external authentication keys used by the Administrator
• Assymmetric device authentication keys used by the Administrator or a remote IT
FIA AFL.1.1/RAD
The TSF shall detect when [an administrative configurable positive integer within 1 and 15]
unsuccessful authentication attempts occur related to [consecutive failed authentication attempts].
FIA AFL.1.2/RAD
When the defined number of unsuccessful authentication attempts has been [met or surpassed], the TSF
shall [block RAD].
Application Note:
The Authentication Try Limit N, defined during personalisation, must verify 1 ≤ N ≤ 15.
FIA AFL.1.1/ Authentication keys
The TSF shall detect when [selection :[assignment: positive integer number], an administrator
configurable positive integer within [assignment: range of acceptable values]] unsuccessful
authentication attempts occur related to [consecutive failed authentication attempts].
FIA AFL.1.2/ Authentication keys
When the defined number of unsuccessful authentication attempts has been [met or surpassed], the TSF
shall [assignment : list of actions].
Refinements:
The Authentication or external entities (subjects or remote IT entities) may be performed with the
D.AUTH_KEYS or with D.EPHEMERAL_KEYS. Depending on the cases, several cases may
occur:
Type of TSF data Entity to be authenticated
Selection for FIA_AFL.1.1
/Authentication keys
List of action
D.AUTH_KEYS S.Personalizer Positive integer number ‘1’
Time of next
authentication
increases
D.AUTH_KEYS S.TOE_Admin Positive integer number ‘1’
Time of next
authentication
increases
D.AUTH_KEYS
S.Admin
(when using symmetric
role authentication)
Administrator
configurable positive
integer ‘N’
0 ≤ N ≤ 15
If N= ‘0’, no actions
are taken.
If N != ‘0’, the key is
blocked
D.AUTH_KEYS
S.Admin or
Remote IT entity
(when using symmetric
device authentication)
Administrator
configurable positive
integer ‘N’
0 ≤ N ≤ 15
If N= ‘0’, no actions
are taken.
If N != ‘0’, the key is
blocked
Copyright 2010 © 74 FQR 110 4773 Ed3
D.EPHEMERAL_KEYS
S.Admin
(when using assymmetric
role authentication)
Positive integer number ‘1’
The key is deallocated
with respect to
FDP_RIP.1.1
D.EPHEMERAL_KEYS
Administrator or
Remote IT entity
(when using assymmetric
device authentication)
Positive integer number ‘1’
The key is deallocated
with respect to
FDP_RIP.1.1
It is important to note that the subject S.Admin may be the SCA, CGA, SSCD or IFD if they act as
a subject.
FIA_ATD User attribute definition
FIA ATD.1.1 / S.Signatory
The TSF shall maintain the following list of security attributes belonging to individual users [RAD]
FIA ATD.1.1 / S.Admin
The TSF shall maintain the following list of security attributes belonging to individual users [RAD]
Application Note:
This is mandated if the User “Administrator” is authenticated by mean of a RAD.
FIA ATD.1.1 / S.Admin, S.TOE_Admin, S.Personalizer
The TSF shall maintain the following list of security attributes belonging to individual users [AUTH_KEYS
and EPHEMERAL_KEYS]
Application Note:
Each subjects is authenticated thanks to a dedicated authentication key and a dedicated
authentication scheme. The key to use is a TSF data that is either permanently stored in the TOE
(AUTH_KEYS), or an ephemeral key extracted from a certificate (EPHEMERAL_KEYS).
FIA_UAU User authentication
FIA UAU.1.1
The TSF shall allow
[Identification of the user by means of TSF required by FIA_UID.1]
[Establishing a trusted channel between the TOE and a SSCD of type 1 by means of TSF
required by FTP_ITC.1/SCD import]
[Establishing a trusted path between local user and the TOE by means of TSF required by
FTP_TRP.1/TOE to transmit the VAD if the TOE is used in contact in phase 7]
[Establishing a trusted channel between an IFD and the TOE by means of TSF required by
FTP_ITC.1/ TOE Contactless to transmit the VAD if the TOE is used in contactless in phase 7]
[Establishing a trusted channel between the SCA and the TOE by means of TSF required
by FTP_ITC.1/DTBS import in phase 7]
On behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2
Copyright 2010 © 75 FQR 110 4773 Ed3
The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated
actions on behalf of that user.
Application note:
"Local user" mentioned in component FIA_UAU.1.1 is the user using the trusted path provided
between the SCA in the TOE environment and the TOE as indicated by FTP_TRP.1/SCA and FTP
TRP.1/TOE.
This trusted path enables to authenticate the role Signatory and Administrator (if it is authenticated
with a RAD).
FIA_UID User Identification
FIA UID.1.1
The TSF shall allow
[Establishing a trusted channel between the TOE and a SSCD of type 1 by means of TSF
required by FTP_ITC.1/SCD import]
[Establishing a trusted path between local user and the TOE by means of TSF required by
FTP_TRP.1/TOE to transmit the VAD if the TOE is used in contact in phase 7]
[Establishing a trusted channel between an IFD and the TOE by means of TSF required by
FTP_ITC.1/ TOE Contactless to transmit the VAD if the TOE is used in contactless in phase 7]
[Establishing a trusted channel between the SCA and the TOE by means of TSF required
by FTP_ITC.1/DTBS import in phase 7]
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.
3.10.4. FMT: SECURITY MANAGEMENT
FMT_MOF Management of functions in TSF
FMT_MOF.1.1
The TSF shall restrict the ability to [enable] the functions [signature-creation function] to [Signatory].
FMT_MSA Management of security attributes
FMT_MSA.1.1/ Administrator - Initialisation
The TSF shall enforce the [Initialisation SFP] to restrict the ability to [modify] the security attributes
[SCD/SVD management] to [Administrator and Personalizer].
FMT_MSA.1.1/ Administrator - Import
The TSF shall enforce the [SCD Import SFP] to restrict the ability to [modify] the security attributes
[SCD/SVD management and secure SCD import allowed] to [Administrator and Personalizer].
Copyright 2010 © 76 FQR 110 4773 Ed3
FMT_MSA.1.1/ Signatory
The TSF shall enforce the [Signature-creation SFP] to restrict the ability to [modify] the security
attributes [SCD operational] to [Signatory].
FMT_MSA.1.1/ Management of TOE
The TSF shall enforce the [IAS ECC Administration SFP] to restrict the ability to [modify] the security
attributes [Medium, HashOffCard, SymAuthMechanism and AsymAuthMechanism] to
[TOE_Administrator or Personalizer].
FMT_MSA.1.1/ Key Management
The TSF shall enforce the [Key Management SFP] to restrict the ability to [modify] the security attributes
[Key import management, Key generation management and Key export Management] to [User,
SCA, CGA, SSCD, IFD].
FMT_MSA.1.1/ Protection against eavesdropping
The TSF shall enforce the [Protection against eavesdropping SFP] to restrict the ability to [modify] the
security attributes [data exchange in contactless] to [IFD].
FMT_MSA.2.1
The TSF shall ensure that only secure values are accepted for [SCD/SVD management, SCD
operational, Medium, HashOffCard, SymAuthMechanism, AsymAuthMechanism, Key import
management, Key generation management and Key export Management, data exchange in
contactless].
FMT_MSA.3.1
The TSF shall enforce the [Initialisation SFP, Signature-creation SFP, SCD Import SFP, IAS ECC
Administration SFP and Key Management SFP, Protection against eavesdropping SFP] to provide
[restrictive] default values for security attributes that are used to enforce the SFP.
Refinement:
The security attribute of the SCD "SCD operational" is set to "no" after generation or import of the
SCD.
FMT_MSA.3.2
The TSF shall allow the [assignment : the authorised identified role] to specify alternative initial values
to override the default values when an object or information is created.
Refinement:
The following refinement applies :
Security attributes Authorised identified role
SCD/SVD Management
Administrator
Personalizer
SCD Operational Administrator
Medium
HashOffCard
SymAuthMechanism
AsymAuthMechanism
Personalizer
TOE_Administrator
Copyright 2010 © 77 FQR 110 4773 Ed3
data exchange in contactless IFD
Key import Management
Key generation Management
Key export Management
User, SCA, CGA, SSCD, IFD
Secure SCD import Allowed SSCD
Sent by an authorized SCA SCA
Role
User
Personalizer
FMT_MTD Management of TSF data
Signatory
FMT_MTD.1.1/ Signatory
The TSF shall restrict the ability to [modify] the [RAD] to [Signatory].
Refinement:
This requirement applies only if the RAD is the one used for the Authentication of the Role
Signatory
Association between SCD and SCD_ID
FMT_MTD.1.1/ Association between SCD and SCD_ID
The TSF shall restrict the ability to [associate] the [SCD and a SCD_ID] to [Administrator and
Personalizer].
Application note:
At creation, the SCD is given a SCD identifier that will be permanently associated to it.
Protection against tracability
FMT_MTD.1.1/ Disabling identification data retrieval
The TSF shall restrict the ability to [to disable read access for users to] the [IDENTIFICATION_DATA] to
[Manufacturer].
Application note:
The requirement is only needed in case the TOE is used in contactless mode. It ensures it is not
possible to retrieve identification data such as CPLC data, TOE identifier, FCI of the Card
Manager,
Rely on the SFRs provided by [ST_CLIO/THALIE] :
• FMT_MOF.1/PP_TOE enable to disable identification data retrieval
• FDP_ACC.2/PP restricts the access to this feature to the Manufacturer
TOE Serial number
FMT_MTD.1.1/ TOE Serial number
The TSF shall restrict the ability to [set] the [TOE_SerialNumber] to [Personalizer in phase 6].
Application note:
Copyright 2010 © 78 FQR 110 4773 Ed3
The Personalizer only interacts with the TOE in phase 6
TOE State
FMT_MTD.1.1/ TOE State
The TSF shall restrict the ability to [modify] the [STATE] to [Personalizer in phase 6].
Application note:
The Personalizer shall set D.STATE to “PERSONALIZED” at the end of phase 6
to switch the life cycle to phase 7.
FMT_SMF Specification of Management Functions
FMT_SMF.1.1
The TSF shall be capable of performing the following management functions: [SCD/SVD Generation, SCD
import, RAD personalization, Signature creation, Management of the TOE, Key Management,
Protection against eavesdropping].
FMT_SMR Security management roles
FMT_SMR.1.1
The TSF shall maintain the roles [Administrator, TOE_Administrator, SCA, CGA, SSCD, IFD,
Personalizer and Signatory].
FMT SMR.1.2
The TSF shall be able to associate users with roles.
Application note:
The SCA, CGA, SSCD, and IFD may be seen as subjects. As such, the TOE
maintains their Role.
3.10.5. FPT: PROTECTION OF THE TSF
FPT_EMSEC TOE Emanation
FPT_EMSEC.1.1
The TOE shall not emit [Side channel emission] in excess of [limits specified by the state-of-the-art
attacks on smart card IC] enabling access to [ESERVICES_KEY, AUTH_KEY,RAD and SCD] and
[none].
FPT_EMSEC.1.2
The TSF shall ensure [all users] are unable to use the following interface [external contacts
emanations] to gain access to [ESERVICES_KEY, AUTH_KEY,RAD and SCD] and [none].
Copyright 2010 © 79 FQR 110 4773 Ed3
FPT_FLS Failure secure
FPT_FLS.1.1
The TSF shall preserve a secure state when the following types of failures occur: [
those associated to the potential security violations described in FAU_ARP.1 of the
underlying javacard open platform,
the applet deletion manager fails to delete a package/applet,
the object deletion functions fail to delete all the unreferenced objects owned by the applet
that requested the execution of the method,
1. Invalid reference exception; 2. Code or data integrity failure; 3. Power loss while
processing. 4. worm on or dead EEPROM, full security area, false CRC
For each problem the TOE sends a specific exception status or doesn't start,].
FPT_PHP TSF physical Protection
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.1
The TSF shall resist [changing operational conditions every times: the frequency of the external
clock, power supply, and temperature] to the [chip elements] by responding automatically such that
the SFRs are always enforced
FPT_TST TSF self test
FPT_TST.1.1
The TSF shall run a suite of self-tests [during initial start-up and periodically during normal operation]
to demonstrate the correct operation of [the TSF].
FPT_TST.1.2
The TSF shall provide authorised users with the capability to verify the integrity of [TSF data].
FPT_TST.1.3
The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable
code.
Application note:
Any loss of integrity will cause the TOE to be killed.
Copyright 2010 © 80 FQR 110 4773 Ed3
3.10.6. FTP: TRUSTED PATH/CHANNELS
FTP_ITC Inter-TSF trusted channel
SCD Import
FTP_ITC.1.1/ SCD import
The TSF shall provide a communication channel between itself and another trusted IT product that is
logically distinct from other communication channels and provides assured identification of its end points and
protection of the channel data from modification or disclosure.
FTP_ITC.1.2/ SCD import
The TSF shall permit [another trusted IT product] to initiate communication via the trusted channel.
FTP_ITC.1.3/ SCD import
The TSF shall initiate communication via the trusted channel for [SCD import]
Refinement:
This requirement applies in phase 6 & 7.
SVD Transfer
FTP_ITC.1.1/ SVD transfer
The TSF shall provide a communication channel between itself and another trusted IT product that is
logically distinct from other communication channels and provides assured identification of its end points and
protection of the channel data from modification or disclosure.
FTP_ITC.1.2/ SVD transfer
The TSF shall permit [another trusted IT product] to initiate communication via the trusted channel.
FTP_ITC.1.3/ SVD transfer
The TSF shall initiate communication via the trusted channel for [SVD transfer]
Refinement:
The mentioned remote trusted IT product is a CGA in phase 7
Application note:
FTP_ITC.1/SVD Transfer will be required only, if the TOE is to import the SVD from a SSCD
Type1 so it will be exported to the CGA for certification.
DTBS Import
FTP_ITC.1.1/ DTBS import
The TSF shall provide a communication channel between itself and another trusted IT product that is
logically distinct from other communication channels and provides assured identification of its end points and
protection of the channel data from modification or disclosure.
FTP_ITC.1.2/ DTBS import
Copyright 2010 © 81 FQR 110 4773 Ed3
The TSF shall permit [another trusted IT product] to initiate communication via the trusted channel.
FTP_ITC.1.3 DTBS import
The TSF shall initiate communication via the trusted channel for [signing DTBS-representation]
Refinement:
The mentioned remote trusted IT product is a SCA.
This requirement applies in phase 7 only.
Protection against tracability in contactless
FTP_ITC.1.1/ TOE Contactless
The TSF shall provide a communication channel between itself and another trusted IT product that is
logically distinct from other communication channels and provides assured identification of its end points and
protection of the channel data from modification or disclosure.
FTP_ITC.1.2/ TOE Contactless
The TSF shall permit [another trusted IT product] to initiate communication via the trusted channel.
FTP_ITC.1.3 TOE Contactless
The TSF shall initiate communication via the trusted channel for [performing any operation that may
disclose any information about the holder, such as identification or tracability]
Refinement:
The mentioned remote trusted IT product is an interface device (IFD)
FTP_TRP Trusted path
FTP_TRP.1.1/ TOE
The TSF shall provide a communication path between itself and [local] users that is logically distinct from
other communication paths and provides assured identification of its end points and protection of the
communicated data from [modification or disclosure].
FTP_TRP.1.2/ TOE
The TSF shall permit [local users] to initiate communication via the trusted path.
FTP_TRP.1.3/ TOE
The TSF shall require the use of the trusted path for [initial user authentication].
Application note:
The Trusted path is required to send the VAD to the TOE in order to identify & authenticate the
Signatory, and the Administrator (if it ias authenticated with a RAD),
During phase 7, if the TOE is used in contactless mode, in order to protect the VAD against
eavesdropping and prevent the tracability risks, the trusted path is removed and replaced by the
trusted channel defined by :
Copyright 2010 © 82 FQR 110 4773 Ed3
• FTP_ITC.1.1/ TOE Contactless (against tracability)
• FTP_ITC.1.2/ TOE Contactless (against tracability)
• FTP_ITC.1.3/ TOE Contactless (against tracability)
• FDP_UCT.1.1/ TOE Contactless (against disclosure)
• FDP_UIT.1.1/ TOE Contactless (against eavesdropping)
• FDP_UIT.1.2/ TOE Contactless (against eavesdropping)
4. TOE summary specification
4.1. Security function of the TOE
4.1.1. Security functions provided by the javacard open platform
All the security functions provided by the javacard open platform are described in
[ST_CLIO/THALIE]
They are listed in the following table.
Security function Description
SF_Firewall Firewall Security policy
SF_Card_Content_Management
Control of loading, deletion and installation of
applet and packages
SF_Card_Management_Environment
Initialization and management of internal data
structure of the Card Manager
SF_Signature Generation/Verification of signature
SF_Encryption_and_Decryption Encryption/Decryption of Data
SF_Message_Digest_Generation Message Digest computation
SF_Random_Number_Generation Random number generation
SF_Key_Destruction Destruction of keys
SF_data_integrity Integrity of keys, PIN, packages, …
SF_Clearing_of_Sensitive_Information Clearing of sensitive data when not used anymore
SF_Atomic_Transactions Execution of atomic operations
SF_Key_Generation Generation of Assymmetric keys
SF_Key_Distribution Distribution of keys
SF_Cardholder_Verification Authentication of the cardholder with PIN
SF_Hardware_Operating Hardware self tests at start up or before first use
SF_Memory_failure Management of non volatile memory
SF_Data_Coherency Transaction mechanism
SF_Exception Management of abnormal execution
SF_DAP_Verification DAP verification for applet loading
SF_TOKEN Validity of card content management
SF_Manufacturer_Authentication Authentication of the manufacturer agent
SF_Resident_Application_Dispatcher
Control of security level when communicating with
resident application
Copyright 2010 © 83 FQR 110 4773 Ed3
SF_Entity_Authentication/Secure_Channel GP Secure Channel management
SF_GP_Dispatcher
Control of security level when communicating with
the Card manager
SF_KEY_MANAGEMENT Management of the keys of the Card Manager
SF_Security_Functions_of_the IC Security function of the IC
SF_Unobservability Unobservability of secure element processing
SF_Prepersonalization Prepersonalization of the TOE
SF_Key_Access Secure Access to keys and PINs
SF_Key_Agreement Key agreement
4.1.2. Security functions added by the composite TOE
The TOE provides the following security functions on top of the one provided by the
underlying javacard open platform.
Security function Description
SF.PIN_MGT PIN Management
SF.SIG Signature Computation
SF.DEV_AUTH Device Authentication
SF.ADM_AUTH Administrator Authentication
SF.SM Secure messaging
SF.KEY_MGT Key Management
SF.CONF Configuration of TOE
SF.ESERVICE Execution of eServices
SF.EAVESDROPPING_PROTECTION
Protection of communication against
eavesdropping (when the TOE is used in
contactless)
SF.SAFESTATE_MGT Safe State Management
SF.PHYS Physical protection
SF.PIN_MGT
This security function is involved in the PIN (RAD) management. In particular, it
provides access control over the creation, update, reset and verification of the PIN,
depending on the subject and the life cycle state.
In phase 6, this security function only allows the RAD(s) to be created and its value to be
loaded in an encrypted way by the Personalizer Agent. It can not be checked.
In phase 7, this security function enables to create the RAD, to verify, unblock and
change the RAD according to the security policies set at RAD creation
Copyright 2010 © 84 FQR 110 4773 Ed3
This security function enables to authenticate the subject Signatory and Administrator
(if it is authenticated with a RAD). It manages as well an error counter for each RAD,
ensuring protection against brute force attacks.
This security function ensures the deallocation of the RAD when it is updated and of the
VAD when it is sent to the TOE for checking
This security function enables the RAD management either directly throught the IAS
ECC applet with APDU command, or through shared interfaces. The shared interfaces
enable, other applets loaded on the javacard open platform to use the services provided
by the security function.
However, in any case, whether shared interfaces or APDU commands are used, the
same security policy is applied to access RAD management features.
SF.SIG
This security function manages the signature computation.
In phase 6, it ensures the Personalizer Agent can not sign on behalf of the Signatory
In phase 7, it enforces the correct security policy for the DTBS import and for the
signature computation, depending on the subjects
It performs the signature computation and ensures the SCD and SVD correspond.
SF.DEV_AUTH
This security function manage the (mutual) device authentication between the TOE and
a remote IT. It is only active in phase 7.
It enables the TOE to establish a trusted channel with remote IT entities such as the SCA,
the CGA, the SSCD type 1 and the IFD. The device authentication may be either realized
with symmetric or asymmetric scheme.
This security function ensures the mutual authentication of both entities (TOE and
remote IT entity). Upon successful authentication, it computes a shared secret (called the
seed) used by SF.SM to generate the session key to ensure the protection in integrity and
Copyright 2010 © 85 FQR 110 4773 Ed3
confidentiality of the data exchanged. This seed is computed from random numbers
partly generated by the TOE, partly generated by the remote IT.
This security function manages as well an error counter for each key used for the
authentication of the remote IT entity.
This security function ensures the deallocation of
• the authentication cryptogram received once processed
• in case the asymmetric scheme is used, it ensures as well the deallocation of the
ephemeral public keys extracted form the certificates processed by the TOE after
use
SF.ADM_AUTH
This security function enables the TOE to authenticate external entities. It is active in
phase 6 and 7.
In phase 6, it enables the TOE to authenticate the Personalization Agent and in phase 7,
it enables to authenticate the TOE_Administrator, and the Administrator.
The authentication of the Administrator may be either realized with symmetric or
asymmetric scheme.
This security function manages as well an error counter for each key used for the
authentication of the external entity.
This security function ensures the deallocation of
• the authentication cryptogram received once processed
• in case the asymmetric scheme is used, it ensures as well the deallocation of the
ephemeral public keys extracted form the certificates processed by the TOE after
use
SF.SM
This security function applies only in phase 7. It ensures the protection of
communication between the TOE and Remote IT entities.
This security function requires the TOE and the entity between which a trusted channel
shall be established to be authenticated with SF.DEV_AUTH.
Copyright 2010 © 86 FQR 110 4773 Ed3
This security function ensures the following properties:
• The TOE can detect any modification or deletion when receiving data
• The incoming data are protected against disclosure
• The TOE can return data in a manner protected from modification and deletion
• The TOE can return data in a manner protected against disclosure
• Upon reception of the data, the recipient can check the data were issued by the
expected sender (authenticated by SF.DEV_AUTH).
The integrity and confidentiality of data exchanged are ensured by cryptographic means
: data are encrypted and their integrity is ensured by a MAC computed with session
keys.
This security function builds session keys from the seed computed by SF.DEV_AUTH.
These session keys are ephemeral and unique as the seed is computed from random
numbers generated by the TOE and the external entity. In order to ensure a protection
against replay attacks, the MAC is computed from an ICV which is generated randomly
by the TOE and by the external entity once the device authentication is successful.
When the secure messaging session is closed or when an error is detected by the TOE,
the session keys and the ICV are erased.
SF.KEY_MGT
This security function applies in phase 6 & 7. It provides the mean to
• Create any kind of keys and the DH parameters
• generate asymmetric key pairs (used for signature computation or TOE
authentication)
• update the keys (symmetric key used for authentication of external entity,
SCD/SVD, eServices keys, asymmetric keys for TOE’s authentication) and the DH
Domain parameters
• export the SVD and the TOE’s authentication public key
It provides access control over these operations and means to set at creation the relevant
security policy to apply for the key use.
In particular, in case of SCD/SVD key pair update (by import or generation), this
security function ensures the “SCD operational” state is reset.
When a key value is updated (by import or generation), the former key value is
destroyed.
Copyright 2010 © 87 FQR 110 4773 Ed3
SF.CONF
This security function applies in phase 6 & 7. It manages the initialization of TSF data
and administration features of the TOE.
It provides access control on the modification of the following TOE attributes:
• Communication medium : contact and/or contactless
• Type of cryptography to be used for the remote IT entities and remote subject
authentication (symmetric or asymmetric)
• Type of DTBS to be used : the DTBS representation fully computed outside the
TOE may be used.
Only the Personalization Agent can modify them in phase 6, and the
TOE_Administrator in phase 7.
It restricts the initialization of the following TSF data to the Personalization
Agent/Manufacturing Agent only:
• TOE serial number – shall be initialized in phase 6 by the Personalization Agent
• identification data of the TOE – Retrieval can be locked in phase 5 by the
Manufacturing or Personalization Agent
• TOE State – it shall be set at the end of phase 6 to PERSONNALIZED by the
Personalization Agent
SF.ESERVICE
This security function applies in phase 7. It enables to perform eservices such as
• C/S authentication
• Decryption key decipherment
• Certificate verification
SF.EAVESDROPPING_PROTECTION
This security function applies in phase 7. It enables to ensure protection of sensitive data
against eavesdropping when the TOE is used in contactless.
This security function requires P.SecurityPolicy_Contactless to be applied.
It enforces the keys, the PIN (RAD and VAD) as well as the identification data to be
transferred through a trusted channel established with an interface device.
Copyright 2010 © 88 FQR 110 4773 Ed3
SF.SAFESTATE_MGT
This security function applies in phase 6 & 7. It performs the following operations:
• Monitoring the integrity of the TOE and the TSF data by performing selftests
• Ensuring the TOE returns in a safe state when an unexpected event occurs (loss of
power, tearing,…) : all sensitive data are erased and the TOE returns in a
restrictive and secure state.
In case a major error is detected, the security function destroys the TOE.
SF.PHYS
This security function applies in phase 6 & 7. It ensures
• the TOE detects physical manipulation (I/O manipulation, EM perturbation,
temperature perturbation,…) and takes countermeasures.
• The TOE is protected against probing and that there is no information leakage
that my be used to reconstruct sensitive data
In case a major error is detected, the security function destroys the TOE.
4.2. Security assurance requirments
This chapter defines the list of the assurance measures required for the TOE security assurance requirements.
The EAL4+ is claimed.
4.2.1. Evaluation Assurance Level rationale
The underlying javacard open platform [CLIO/THALIE] has a certificate level at
Evaluation Assurance Level 4 (EAL4) augmented with ALC_DVS.2 and AVA_VAN.5.
This is conform with the evaluation level assurance claimed by this security target
which is EAL4 augmented with ALC_DVS.2 and AVA_VAN.5.
The following assurance packages are required
Measure Name
AM_ADV Development
AM_AGD Guidance
AM_ALC Life Cycle
AM_ASE Security target
AM_ATE Tests
AM_VAN Vulnerability
Copyright 2010 © 89 FQR 110 4773 Ed3
4.2.2. ADV : Development
The following components are included:
Component Level
ADV_ARC 1
ADV_FSP 4
ADV_IMP 1
ADV_INT N/A
ADV_SPM N/A
ADV_TDS 3
4.2.3. AGD : Guidance
The following components are included:
Component Level
AGD_OPE 1
AGD_PRE 1
4.2.4. ALC : Life Cycle
The following components are included:
Component Level
ALC_CMC 4
ALC_CMS 4
ALC_DEL 1
ALC_DVS 2 – enhanced component
ALC_FLR N/A
ALC_LCD 1
ALC_TAT 1
Note : ALC_DVS is enhanced
4.2.5. ASE : Security target
The following components are included:
Component Level
ASE_CCL 1
ASE_ECD 1
ASE_INT 1
ASE_OBJ 2
ASE_REQ 2
Copyright 2010 © 90 FQR 110 4773 Ed3
ASE_SPD 1
ASE_TSS 1
4.2.6. ATE : Tests
The following components are included:
Component Level
ATE_COV 2
ATE_DPT 2
ATE_FUN 1
ATE_IND 2
4.2.7. VAN : Vulnerability Analysis
The following component is included:
Component Level
VAN 5 –enhanced component
Note : VAN is enhanced
4.3. EAL augmentations rationale
4.3.1. AVA_VAN.5 Advanced methodical vulnerability analysis
Due to the definition of the TOE, it must be shown to be highly resistant to penetration
attacks. This assurance requirement is achieved by the AVA_VAN.5 component.
Independent vulnerability analysis is based on highly detailed technical information.
The attacker is assumed to be thoroughly familiar with the specific implementation of
the TOE. The attacker is presumed to have a high level of technical sophistication.
AVA_VAN.5 has dependencies:
• ADV_ARC.1
• ADV_FSP.2
• ADV_IMP.1
• ADV_TDS.3
• AGD_OPE.1
• AGD_PRE.1
All these dependencies are fulfilled.
Copyright 2010 © 91 FQR 110 4773 Ed3
4.3.2. ALC_DVS.2 Sufficiency of security measures
In order to protect the TOE on development Phase, the component ALC_DVS.2 was
added. This latter requires security documentation justifying that the security measures
provide the necessary level of protection to maintain the confidentiality and integrity of
the TOE.
5. Conformance Claims
5.1. Conformance Claim to CC
This Security Target claims conformance to CC version 3.1 with the following
documents:
• "Common Criteria for information Technology Security Evaluation, Part 1: Introduction and
general model", September 2006, Version 3.1 revision 1
• "Common Criteria for information Technology Security Evaluation, Part 2: Security Functional
requirements", September 2007, Version 3.1 revision 2
• "Common Criteria for information Technology Security Evaluation, Part 3: Security Assurance
requirements", September 2007, Version 3.1 revision 2
Conformance is claimed as follows:
• Part 1: conformant
• Part 2: extended with the FCS_RNG.1 and FPT_EMSEC.1. All the other Security
requirements have been drawn from the catalogue of requirements in Part 2
• Part 3: conformant EAL4 augmented with ALC_DVS.2 and AVA_VAN.5.
5.2. Protection Profile reference
This Security Target claims conformance with the following protection profiles
• Protection Profile «Secure Signature Creation Device Type 2, version 1.04»,
reference BSI-PP-0005-2002.
• Protection Profile «Secure Signature Creation Device Type 3, version 1.05»,
reference BSI-PP-0006-2002.
5.3. Conformance Claim rationale
The TOE described in this Security target is conformant with the TOE type described in
[SSCD2] and [SSCD3]. The security problem definition of this Security Target is
consistent with the one defined in [SSCD2] and [SSCD3] as it was extracted from them.
The TOE claims a demonstrable conformance.
Copyright 2010 © 92 FQR 110 4773 Ed3
However the security problem definition was extended to consider the following
behaviour of the TOE
• the various authentication features
• the management of keys
• the life cycle management which separates the phase 6 (under the personalization
Agent control) and the phase 7
5.3.1. Rationale for TOE objectives
All the TOE objectives described in [SSCD2] and [SSCD3] are included. The following
ones are added:
• OT.Authentication_Secure : The TOE enable secure authentication of itself and
external entities
• OT.Privacy_Contactless : When used in contactless, the TOE ensures privacy of
data
• OT.SCD/SVD_Management : The TOE does not consider only one couple
SCD/SVD but considers several that may be created, erased and loaded all along
the TOE life cycle
• OT.Key_Lifecycle_Security ; The Toe protects the authentication and eServices
keys all over its life cycle
• OT.Key_Secrecy : The TOE ensures the secrecy of the authentication and
eServices keys
• OT.TOE_AuthKey_Unique : When the TOE generates an asymmetric key pair
used to authenticate itself, it ensures it will be unique
• OT.LifeCycle_Management : The Life cycle of the TOE is splitted in two phases :
the first one in which the TOE is under the Personalization Agent control and
during which data are loaded in the TOE and during which the TOE can not sign,
and the second one in which the TOE can be used by the Signatory to sign
• OT.eServices : The TOE realize eServices
None of these new objectives interfere with the security problem definition stated by
[SSCD2] and [SSCD3].
5.3.2. Rationale for threats
All the threats present in [SSCD2] and [SSCD3] are included. The following ones are
added :
• T.TOE_ID_Contactless : Identification of the TOE when used in contactless
• T.Skimming_Contactless : Skimming of the TOE when used in contactless
Copyright 2010 © 93 FQR 110 4773 Ed3
• T.Eavesdropping_Contactless : Eavesdropping of the communication when used
in contactless
• T.Key_Divulg : Divulgation of an authentication of eService key
• T.Key Derive : Derivation of an authentication of eServices key
• T.TOE_PublicAuthKey_Forgery : Forgery of the authentication public key of the
TOE
• T.Authentication_Replay : replay of an authentication protocol
Moreover, T.Hack_Phys is extended to address all the threats over the keys stored in the
TOE (SCD, SVD, authentication keys and eServices keys)
None of these new threats interfere with the security problem definition stated by
[SSCD2] and [SSCD3].
5.3.3. Rationale for Assumptions
No assumptions were added
5.3.4. Rationale for Organisational Security Policies
All the OSPs present in [SSCD2] and [SSCD3] are included. The following ones are
added :
• P.EMSEC_Design : The development of the TOE was made in order to avoid any
exploitable information leakage
• P.SecurityPolicy_Contactless :If the TOE is to be used in contactless, a relevant
security policy shall be set to protect TOE against traceability and to protect it
from skimming.
• P.LinkSCD_QualifiedCertificate : there shall exist a link between the SCD used
to create the signature and the matching qualified certificate
• P.ControlOfAppletToBeLoaded_Contactless : the other applets that might be
present shall not enable to trace the TOE when used in contactless
• P.TOE_PublicAuthKey_Cert : the TOE contains certificate enabling to use the
authentication features of the TOE.
• P.TOE_Construction : the recommandations indicated in [AGD_PRE] shall be
applied to ensure the correct construction of the TOE. This OSP is just added for
conformance reasons and does not modify the SPD
None of these new OSPs interfere with the security problem definition stated by
[SSCD2] and [SSCD3].
Copyright 2010 © 94 FQR 110 4773 Ed3
5.3.5. Rationale for Environment objectives
All the Environment objectives present in [SSCD2] and [SSCD3] are included. The
following ones are added :
• OE.AuthKey_Transfer : the environment ensures the confidentiality and
integrity of the authentication keys when transferred in the TOE
• OE.AuthKey_Unique : the environment ensures the uniqueness of each TOE
authentication keys loaded in the TOE
• OE.TOE_PublicAuthKey_Transfer : the environment ensures the authenticity of
the authentication public keys when transferred from the TOE
• OE.SecurityPolicy_Contactless : The security policy applied by the environment
on sensitive data that may be accessed in contactless is correctly defined
• OE.LinkSCD_QualifiedCertificate : The environment ensures that when the
SCD is updated, the link with the qualified certificate is maintained
• OE.ControlOfAppletToBeLoaded_Contactless : When an applet is loaded on the
javacard open plateform, the applet shall ensure the privacy of the TOE (no
tracking)
• OE.TOE_Construction : the Personalization Agent shall be a trusted person and
be skilled enough to apply the recommandations indicated in [AGD_PRE]. This
OE is just added for conformance reasons and does not modify the SPD
None of these new environment objectives interfere with the security problem definition
stated by [SSCD2] and [SSCD3].
5.3.6. Rationale for Security requirments
Security requirement of the {SSCD2] and {SSCD3] are defined in this Security target.
However, as they are based on previous Common Criteria version (v2.1), some
requirements are adapted to CC v3.1 (mainly wording) as well as some dependencies
that were modified. In particular, FPT_AMT is replaced by FPT_TEE in CC v3.1.
In the case of the TOE, FPT_TEE is non applicable. With respect to the definition of this
SFR, it implies the TOE to perform test on external entities. However, as the TOE does
not rely on any external mechanisms to realize the security services and as all the
security features are present in the TOE scope, this SFR is non applicable and is
withdrawn from the current security target.
Moreover, due to compliance with the CC v3.1, FMT_SMF.1 is added in this current
security target
Copyright 2010 © 95 FQR 110 4773 Ed3
5.4. Security Objectives rationale
In the following chapter, all refinements to the OSP, Threats and Assumptions of the
[SSCD2] and [SSCD3] are indicated in blue italic letters.
Policies and Security Objective Sufficiency
P.CSP_QCert (CSP generates qualified certificates)
establishes the qualified certificate for the signatory and provides that the SVD matches
the SCD that is implemented in the SSCD under sole control of this signatory.
P.CSP_QCert is addressed by the TOE by OT.SCD_SVD_Corresp and
OE.SCD_SVD_Corresp concerning the correspondence between the SVD and the SCD,
in the TOE IT environment, by OE.CGA_QCert for generation of qualified certificates
by the CGA, respectively.
P.QSign (Qualified electronic signatures)
provides that the TOE and the SCA may be employed to sign data with qualified
electronic signatures, as defined by the Directive [1],article 5, paragraph 1. Directive [1],
recital (15) refers to SSCDs to ensure the functionality of advanced signatures. The
requirement of qualified electronic signatures being based on qualified certificates is
addressed by OE.CGA_QCert. OE.SCA_Data_Intend provides that the SCA presents
the DTBS to the signatory and sends the DTBS-representation to the TOE.
OT.Sig_Secure and OT.Sigy_SigF address the generation of advanced signatures by the
TOE.
P.Sigy_SSCD (TOE as secure signature-creation device)
establishes the TOE as secure signature-creation device of the signatory with practically
unique SCD. This is addressed by OT.Sigy_SigF ensuring that the SCD is under sole
control of the signatory and OE.SCD_Unique and OT.SCD_Unique ensuring the
cryptographic quality of the SCD/SVD pair for the qualified electronic signature.
OT.Init provides that generation of the SCD/SVD pair is restricted to authorised users
P.EMSEC_Design (TOE designed to reduce the E.M. emanations)
ensures that all the sensitive operations that may disclose information through
electromagnetic signal are protected. In particular it ensures the memory access, the
cryptographic computation, the software execution do not emit any usable data that
may be used to find any assets. It addresses OT.EMSEC_Design
P.SecurityPolicy_Contactless (Security policy definition)
Copyright 2010 © 96 FQR 110 4773 Ed3
ensures that the TOE identification data, the access to the RAD, the sending of the VAD
is protected against disclosure and eavesdropping. It requires these data to be
exchanged through a communication channel ensuring identification of both entity
(sender and the TOE) and ensuring protection against disclosure. It is addressed by
OE.SecurityPolicy_Contactless that guarantees the correct security policy is set to
objects/files and by OT.Privacy_Contactless that ensures the TOE does apply this
security policy.
P.LinkSCD_QualifiedCertificate (Link between a SCD and its qualified certificate)
ensures that the SCA can unambiguously find the qualified certificate matching a SCD
chosen to perform a SDO. It is addressed by OE.LinkSCD_QualifiedCertificate that
ensures a link between the SCD and a unique identifier within the TOE file structure
P.ControlOfAppletToBeLoaded_Contactless (Control of the other applet that may be
used on the javacard open platform)
ensures that there is no malicious applet loaded in the TOE that may be used to trace it
(by emitting a unique identifier for instance) in case it is used in contactless mode. This
is the responsibility of the SSCD Service provider to control the applet loaded in the
TOE. It is addressed by OE.ControlOfAppletToBeLoaded_Contactless .
P.TOE_PublicAuthKey_Cert (Certificate for asymmetric TOE authentication keys)
ensures that each private key(s) of the TOE for authentication matches the public key
stored within the relevant certificate issued by an entitled entity. The authentication
public key is exported thanks to OE.TOE_PublicAuthKey_Transfer.
P.TOE_Construction (TOE construction)
ensures that all the recommandations indicated in [AGD_PRE] are applied. It is
addressed by OE.TOE_Construction.
Threats and Security Objective Sufficiency
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.Key_Secrecy preserves the secrecy
of all the authentication and eServices keys stored in the TOE. Physical attacks through the
TOE interfaces or observation of TOE emanations are countered by OT.EMSEC_Design.
OT.Tamper_ID and OT.Tamper_Resistance counter the threat T.Hack_Phys by
detecting and by resisting tamper attacks.
T.SCD_Divulg (Storing and copying and releasing of the signature-creation data)
Copyright 2010 © 97 FQR 110 4773 Ed3
addresses the threat against the legal validity of electronic signature due to storage and
copying of SCD outside the TOE, as expressed in the Directive [1], recital (18). This
threat is countered by OT.SCD_Secrecy which assures the secrecy of the SCD used for
signature generation. OT.SCD_Transfer and OE.SCD_Transfer ensures the
confidentiality of the SCD transferred between SSCDs.
T.SCD_Derive (Derive the signature-creation data)
deals with attacks on the SCD via public known data produced by the TOE. This threat
is countered by OE.SCD_Unique (in case of SCD import) and OT.SCD_Unique (in case
of key generation) that provides cryptographic secure generation of the SCD/SVD-pair.
OT.Sig_Secure ensures cryptographic secure electronic signatures.
T.Sig_Forgery (Forgery of the electronic signature)
deals with non-detectable forgery of the electronic signature. This threat is in general
addressed by OT.Sig_Secure (Cryptographic security of the electronic signature),
OE.SCA_Data_Intend (SCA sends representation of data intended to be signed),
OE.CGA_QCert (Generation of qualified certificates), OT.SCD_SVD_Corresp and
OE.SCD_SVD_Corresp (Correspondence between SVD and SCD),
OT.SVD_Auth_TOE (TOE ensures authenticity of the SVD), OE.SVD_Auth_CGA
(CGA proves the authenticity of the SVD), OT.SCD_Secrecy and OT.SCD_Transfer
(Secrecy of the signature-creation data), OT.SCD_Transfer (Secure transfer of SCD
between SSCD), OT.EMSEC_Design (Provide physical emanations security),
OT.Tamper_ID (Tamper detection), OT.Tamper_Resistance (Tamper resistance) and
OT.Lifecycle_Security (Lifecycle security), as follows: OT.Sig_Secure ensures by means
of robust encryption techniques that the signed data and the electronic signature are
securely linked together. OE.SCA_Data_Intend provides that the methods used by the
SCA (and therefore by the verifier) for the generation of the DTBS-representation is
appropriate for the cryptographic methods employed to generate the electronic
signature. The combination of OE.CGA_QCert, OT.SCD_SVD_Corresp,
OT.SVD_Auth_TOE, and OE.SVD_Auth_CGA provides the integrity and authenticity
of the SVD that is used by the signature verification process. OT.Sig_Secure,
OT.SCD_Secrecy, OT.SCD_Transfer, OT.EMSEC_Design, OT.Tamper_ID,
OT.Tamper_Resistance, and OT.Lifecycle_Security ensure the confidentiality of the
SCD implemented in the signatory's SSCD and thus prevent forgery of the electronic
signature by means of knowledge of the SCD.
T.Sig_Repud (Repudiation of electronic signatures)
deals with the repudiation of signed data by the signatory, although the electronic
signature is successfully verified with the SVD contained in his un-revoked certificate.
This threat is in general addressed by OE.CGA_QCert (Generation of qualified
Copyright 2010 © 98 FQR 110 4773 Ed3
certificates), OT.SVD_Auth_TOE (TOE ensures authenticity of the SVD),
OE.SVD_Auth_CGA (CGA proves the authenticity of the SVD),
OT.SCD_SVD_Corresp and OE.SCD_SVD_Corresp (Correspondence between SVD
and SCD), OT.SCD_Unique and OE.SCD_Unique(Uniqueness of the signature-
creation data), OT.SCD_Transfer and OE.SCD_Transfer (Secure transfer of SCD
between SSCD), OT.SCD_Secrecy (Secrecy of the signature-creation data),
OT.EMSEC_Design (Provide physical emanations security), OT.Tamper_ID (Tamper
detection), OT.Tamper_Resistance (Tamper resistance), OT.Lifecycle_Security
(Lifecycle security), OT.Sigy_SigF (Signature generation function for the legitimate
signatory only), OT.Sig_Secure (Cryptographic security of the electronic signature),
OE.SCA_Data_Intend (SCA sends representation of data intended to be signed) and
OT.DTBS_Integrity_TOE (Verification of the DTBS-representation integrity).
OE.CGA_QCert ensures qualified certificates which allow to identify the signatory and
thus to extract the SVD of the signatory. OE.CGA_QCert, OT.SVD_Auth_TOE and
OE.SVD_Auth_CGA ensure the integrity of the SVD. OE.CGA_QCert and
OT.SCD_SVD_Corresp ensure that the SVD in the certificate correspond to the SCD
that is implemented by the SSCD of the signatory. OT.SCD_Unique provides that the
signatory’s SCD can practically occur just once. OT.Sig_Secure, OT.SCD_Transfer,
OT.SCD_Secrecy, OT.Tamper_ID, OT.Tamper_Resistance, OT.EMSEC_Design, and
OT.Lifecycle_Security ensure the confidentiality of the SCD implemented in the
signatory's SSCD. OT.Sigy_SigF provides that only the signatory may use the TOE for
signature generation. OT.Sig_Secure ensures by means of robust cryptographic
techniques that valid electronic signatures may only be generated by employing the
SCD corresponding to the SVD that is used for signature verification and only for the
signed data. OE.SCA_Data_Intend and OT.DTBS_Integrity_TOE ensure that the TOE
generates electronic signatures only for DTBS-representations which the signatory has
decided to sign as DTBS.
OT.LifeCycle_Management ensures that when the TOE is under the Personalizer control, it
can not be misused to sign on behalf of the legitimate Signatory.
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.SVD_Auth_TOE which ensures that
the TOE sends the SVD in a verifiable form to the CGA, as well as by
OE.SVD_Auth_CGA which provides verification of SVD authenticity by the CGA.
T.DTBS_Forgery (Forgery of the DTBS-representation)
addresses the threat arising from modifications of the DTBS-representation sent to the
TOE for signing which then does not correspond to the DTBS-representation
corresponding to the DTBS the signatory intends to sign. The TOE counters this threat
Copyright 2010 © 99 FQR 110 4773 Ed3
by the means of OT.DTBS_Integrity_TOE by verifying the integrity of the DTBS-
representation. The TOE IT environment addresses T.DTBS_Forgery by the means of
OE.SCA_Data_Indent.
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 Signed
Data Object by others than the signatory to create SDO for data the signatory has not
decided to sign, as required by the Directive [1],Annex III, paragraph 1, literal (c). This
threat is addressed by the OT.Sigy_SigF (Signature generation function for the
legitimate signatory only), OE.SCA_Data_Intend (Data intended to be signed),
OT.DTBS_Integrity_TOE (Verification of the DTBS-representation integrity), and
OE.HI_VAD (Protection of the VAD) as follows: OT.Sigy_SigF ensures that the TOE
provides the signature-generation function for the legitimate signatory only.
OE.SCA_Data_Intend ensures that the SCA sends the DTBS-representation only for
data the signatory intends to sign. The combination of OT.DTBS_Integrity_TOE and
OE.SCA_Data_Intend counters the misuse of the signature generation function by
means of manipulation of the channel between the SCA and the TOE. If the SCA
provides the human interface for the user authentication, OE.HI_VAD provides
confidentiality and integrity of the VAD as needed by the authentication method
employed.
OT.LifeCycle_Management ensures that when the TOE is under the Personalizer control, it
can not be misused to sign on behalf of the legitimate Signatory..
T.TOE_ID_Contactless (Identification of the TOE)
deals with the threats for the TOE to be traced when used in contactless. This threat is
addressed by OE.SecurityPolicy_Contactless that ensures that identification data stored
by TOE can not be disclosed to an unauthenticated entity, and OT.Privacy_Contactless
that ensures that this security policy is enforced : sensitive data (including the
identification data) managed by the TOE are protected against retrieval by an
unauthorized entity. OE.ControlOfAppletToBeLoaded_Contactless ensures that when
an applet is loaded in the javacard open platform, it does not endangers the privacy of
the TOE and of the holder.
T.Skimming_Contactless (skimming of the TOE)
deals with the threats of an attacker accessing the TOE by imitating an entitled device.
OT.Authentication_Secure ensures it is very difficult for the attacker to imitate an
entitled device as the cryptographic techniques are very resistant.
OE.SecurityPolicy_Contactless ensures a suitable security policy is applied, so that
authentication of the TOE and the external entity is applied prior to access data, and that
exchanges are protected in confidentiality (for the sole recipient) and proves the
Copyright 2010 © 100 FQR 110 4773 Ed3
authenticity of the sender. OT.Privacy_Contactless ensures this security policy is
enforced.
T.Eavesdropping_Contactless (eavesdropping of the communication)
deals with the threats of an attacker listening to communication between the TOE and a
device to get sensitive information. This is addressed by OT.Privacy_Contactless that
ensures sensitive data are exchanged through an encrypted channel with an
authenticated entity.
T.Key_Divulg (storing, copying and releasing a key)
addresses the threat against the (1) authentication key of the TOE, (2) the authentication
keys of entities and (3) the eServices keys stored in the TOE due to storage and copying
of key(s) outside the TOE. This threat is countered by OT.Key_Secrecy which assures
the secrecy of the keys stored and used by the TOE. OE.AuthKey_Transfer ensures the
confidentiality of the authentication keys transferred to the TOE.
OT.Key_Lifecycle_Security (Lifecycle security) ensures the secrecy of the keys stored in
the TOE during the whole life of the TOE.
T.Key_Derive (Derive a key)
deals with attacks on authentication and eServices keys via public known data produced
or received by the TOE (public key, authentication cryptogram,…). This threat is
countered by OE.AuthKey_Unique (in case of import) and OT.TOE_AuthKey_Unique
(in case of TOE’s authentication key generation) that provides cryptographic secure
generation of the keys. OT.Authentication_Secure ensures secure authentication
cryptograms.
T.TOE_PublicAuthKey_Forgery (Forgery of the public key of a TOE authentication
key)
deals with the forgery of the TOE’s public key used for authentication exported by the
TOE to an entitled entity for the generation of the certificate. This is addressed by
OE.TOE_PublicAuthKey_Transfer which ensures the authenticity of the TOE’s public
key for authentication.
T.Authentication_Replay (Replay of an authentication of an external entity)
deals with the threats an attacker retrieves an authentication cryptogram presented to
the TOE by an entity and present it again to the TOE is order to grant some rights in
order to gain access to some data on the TOE. This is addressed by
OT.Authentication_Secure that ensures the authentication cryptogram can not be
replayed as they rely on random data internally generated by the TOE;
Copyright 2010 © 101 FQR 110 4773 Ed3
Assumption and Security Objective Sufficiency
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_CGA (CGA proves the
authenticity of the SVD) which ensures the verification of the integrity of the received
SVD and the correspondence between the SVD and the SCD that is implemented by the
SSCD of the signatory.
A.SCA (Trustworthy signature-creation application)
establishes the trustworthiness of the SCA according to the generation of DTBS-
representation. This is addressed by OE.SCA_Data_Intend (Data intended to be signed)
which ensures that the SCA generates the DTBS-representation of the data that has 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.SCD_Generate (Trustworthy SCD/SVD generation)
establishes a trustworthy SCD/SVD pair. This that the SCD must be unique, objective
met by OE.SCD_Unique, that the SCD and the SVD must correspond, objective met by
OE.SCD_SVD_Corresp. The secrecy of the SCD must be maintained while it is
transferred to the TOE before being deleted, OE.SCD_Transfer.
6. Annex A : Extended Family
6.1. Definition of FPT_EMSEC
The sensitive family FPT_EMSEC (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 TOE 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, etc. This family describes the
functional requirements for the limitation of intelligible emanations which are not
directly addressed by any other component of CC part 2.
The family “TOE Emanation (FPT_EMSEC)” is specified as follows.
Copyright 2010 © 102 FQR 110 4773 Ed3
Family behavior
This family defines requirements to mitigate intelligible emanations.
Component leveling:
FPT_EMSEC TOE emanation 1
FPT_EMSEC.1 TOE emanation has two constituents:
FPT_EMSEC.1.1 Limit of Emissions requires to not emit intelligible emissions enabling
access to TSF data or user data.
FPT_EMSEC.1.2 Interface Emanation requires to not emit interface emanation enabling
access to TSF data or user data.
Management: FPT_EMSEC.1
There are no management activities foreseen.
Audit: FPT_EMSEC.1
There are no actions defined to be auditable.
FPT_EMSEC.1 TOE Emanation
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_EMSEC.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_EMSEC.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].
6.2. Definition of FCS_RNG
See [ST_CLIO/THALIE] for definition
Copyright 2010 © 103 FQR 110 4773 Ed3