Euterpe on Terpsichore IAS ECC v1.0.1 on ID-One Cosmo V7.0.1-n

Euterpe on Terpsichore IAS ECC v1.0.1 on ID-One Cosmo V7.0.1-n

Euterpe on Terpsichore

IAS ECC v1.0.1 on ID-One Cosmo V7.0.1-n

Public Security target

September 7 th

2010

Copyright 2010 © 1 FQR 110 5185 Ed2

INDEX

1.

INTRODUCTION ................................................................................................................................ 3

1.1.

S

ECURITY

T

ARGET

R

EFERENCE

...................................................................................................... 3

1.2.

R

EFERENCES

................................................................................................................................. 3

1.3.

A

BBREVIATIONS

.............................................................................................................................. 4

2.

TARGET OF EVALUATION DESCRIPTION..................................................................................... 6

2.1.

T

ARGET

O

F

E

VALUATION

O

VERVIEW

............................................................................................... 7

2.1.1.

TOE type ................................................................................................................................................ 7

2.1.2.

Logical scope........................................................................................................................................ 7

2.1.3.

Physical scope ...................................................................................................................................... 8

2.1.4.

Usage and major security features of the TOE....................................................................................... 9

2.2.

T

ARGET

O

F

E

VALUATION

R

EFERENCE

........................................................................................... 11

2.3.

D

ESCRIPTION OF THE EMBEDDED SOFTWARE

................................................................................. 12

2.3.1.

Description of data structure ................................................................................................................ 12

2.3.2.

Access Control Management................................................................................................................ 16

2.3.3.

Authentication of entities ..................................................................................................................... 16

2.3.4.

eServices............................................................................................................................................... 17

2.3.5.

Administration of the TOE................................................................................................................... 17

2.3.6.

Single Sign on feature (SSO) ............................................................................................................... 18

2.3.7.

Scope of evaluation .............................................................................................................................. 19

2.4.

I

NTENDED

U

SAGE

......................................................................................................................... 19

2.5.

L

IFE

C

YCLE

.................................................................................................................................. 20

2.5.1.

Description of the TOE Environment................................................................................................... 22

2.5.2.

Development environment ................................................................................................................... 22

2.5.3.

Production environment ....................................................................................................................... 23

Operational environment...................................................................................................................................... 25

2.5.4.

Coverage of the different Life cycle state by the assurance components AGD & ALC....................... 25

State of the TOE depending on the phase ............................................................................................................ 26

2.5.5.

Mapping with the life cycle and Subjects described in [SSCD2] and [SSCD3]................................... 26

3.

TARGET OF EVALUATION SECURITY ENVIRONMENT ............................................................. 28

3.1.

R

EMOTE

IT

ENTITY

....................................................................................................................... 29

3.2.

S

UBJECTS

.................................................................................................................................... 30

3.3.

U

SER DATA

.................................................................................................................................. 32

3.4.

TSF

DATA

.................................................................................................................................... 33

3.5.

A

SSUMPTION

................................................................................................................................ 35

3.5.1.

Standard Assumption ........................................................................................................................... 35

3.5.2.

Complementary Assumption ................................................................................................................ 35

3.6.

T

HREATS

...................................................................................................................................... 35

3.6.1.

Standard threats .................................................................................................................................... 35

3.6.2.

Complementary threats......................................................................................................................... 36

3.7.

O

RGANIZATIONAL SECURITY POLICIES

............................................................................................ 37

3.7.1.

Standard organizational security policies ............................................................................................. 37

3.7.2.

Complementary organizational security policies.................................................................................. 38

3.8.

S

ECURITY

O

BJECTIVES FOR THE

TOE ........................................................................................... 39

3.8.1.

Standard security objectives of the TOE .............................................................................................. 39

3.8.2.

Complementary security objectives of the TOE................................................................................... 40

3.9.

S

ECURITY OBJECTIVES FOR THE

E

NVIRONMENT

............................................................................. 42

3.9.1.

Standard security objectives of the Environment ................................................................................. 42

3.9.2.

Complementary security objectives of the Environment...................................................................... 43

3.10.

TOE S

ECURITY FUNCTIONAL REQUIREMENTS

................................................................................. 45

3.10.1.

FCS: CRYPTOGRAPHIC SUPPORT ................................................................................................. 45

3.10.2.

FDP : USER DATA PROTECTION.................................................................................................... 48

3.10.3.

FIA: IDENTIFICATION AND AUTHENTICATION........................................................................ 67

Copyright 2010 © 1 FQR 110 5185 Ed2

3.10.4.

FMT: SECURITY MANAGEMENT .................................................................................................. 69

3.10.5.

FPT: PROTECTION OF THE TSF...................................................................................................... 73

3.10.6.

FTP: TRUSTED PATH/CHANNELS ................................................................................................. 74

3.11.

S

ECURITY REQUIREMENTS FOR THE

IT

ENVIRONMENT

.................................................................... 76

3.11.1.

Signature key generation (SSCD Type1) ............................................................................................. 76

3.11.2.

Certification generation application (CGA) ......................................................................................... 79

3.11.3.

Signature creation application (SCA)................................................................................................... 82

3.11.4.

Interface Device (IFD) ......................................................................................................................... 84

3.12.

S

ECURITY REQUIREMENTS FOR THE

A

DMINISTRATOR

..................................................................... 84

3.13.

S

ECURITY REQUIREMENTS FOR THE

P

ERSONALIZER AND

TOE_A

DMINISTRATOR

............................. 85

3.14.

S

ECURITY REQUIREMENTS FOR THE NON

-IT

ENVIRONMENT

............................................................. 85

3.14.1.

Standard security requirements ............................................................................................................ 85

3.14.2.

Complementary security requirements ................................................................................................. 86

4.

TOE SUMMARY SPECIFICATION.................................................................................................. 87

4.1.

S

ECURITY FUNCTION OF THE

TOE................................................................................................. 87

4.1.1.

Security functions provided by the javacard open platform ................................................................. 87

4.1.2.

Security functions added by the composite TOE ................................................................................. 88

4.1.3.

Composition with the Security functions provided of the javacard Open platform ............................. 93

4.1.4.

Dependencies of the Security functions ............................................................................................... 94

4.2.

S

ECURITY ASSURANCE REQUIREMENTS

......................................................................................... 97

4.2.1.

Evaluation Assurance Level rationale .................................................................................................. 97

4.2.2.

ADV : Development............................................................................................................................. 97

4.2.3.

AGD : Guidance................................................................................................................................... 98

4.2.4.

ALC : Life Cycle.................................................................................................................................. 98

4.2.5.

ASE : Security target ............................................................................................................................ 98

4.2.6.

ATE : Tests........................................................................................................................................... 98

4.2.7.

VAN : Vulnerability Analysis .............................................................................................................. 99

4.3.

EAL

AUGMENTATIONS RATIONALE

................................................................................................. 99

4.3.1.

AVA_VAN.5 Advanced methodical vulnerability analysis................................................................. 99

4.3.2.

ALC_DVS.2 Sufficiency of security measures .................................................................................... 99

5.

CONFORMANCE CLAIMS .............................................................................................................. 99

5.1.

C

ONFORMANCE

C

LAIM TO

CC ..................................................................................................... 100

5.2.

P

ROTECTION

P

ROFILE REFERENCE

.............................................................................................. 100

5.3.

C

ONFORMANCE

C

LAIM RATIONALE

............................................................................................... 100

5.3.1.

Rationale for TOE objectives ............................................................................................................. 101

5.3.2.

Rationale for threats ........................................................................................................................... 101

5.3.3.

Rationale for Assumptions ................................................................................................................. 102

5.3.4.

Rationale for Organisational Security Policies................................................................................... 102

5.3.5.

Rationale for Environment objectives ................................................................................................ 102

5.3.6.

Rationale for Security requirements ................................................................................................... 103

5.4.

S

ECURITY OBJECTIVES RATIONALE

.............................................................................................. 103

6.

ANNEX A : EXTENDED FAMILY .................................................................................................. 110

6.1.

D

EFINITION OF

FPT_EMSEC ..................................................................................................... 110

6.2.

D

EFINITION OF

FCS_RNG.......................................................................................................... 111

Copyright 2010 © 2 FQR 110 5185 Ed2

1.

Introduction

1.1.

Security Target Reference

The Security target is identified as follows:

Title:

EUTERPE on Terpsichore – IAS ECC v1.0.1 on ID-One Cosmo

V7.0.1-n - Public Security target

Reference: FQR 110 5185 edition 2

Editor:

CC version:

Oberthur Technologies

3.1 revision 2

EAL:

1.2.

References

EAL4 augmented with AVA_VAN.5 and ALC_DVS.2

[SSCD2]

[SSCD3]

[AGD_PRE]

[AGD_OPE]

[AGD_PRE_TERPSICHORE]

[AGD_OPE_ TERPSICHORE]

[PP9911]

[AIS31]

Secure Signature-Creation Device Type2, 1.04, EAL

4+

Secure Signature-Creation Device Type3, 1.05, EAL

4+

FQR 110 5171 Ed3 - AGD_PRE

FQR 110 5170 Ed2 - AGD_OPE

ID-One Cosmo V7.0.1 - Pre-Perso Guide

FQR 110 4910 Ed3

ID-One Cosmo V7.0.1 - Reference Guide

FQR 110 4911 Ed3

ID-One Cosmo V7.0.1 - Security recommendations

FQR 110 4912 Ed3

Smart Card Integrated Circuit With Embedded

Software Protection Profile, version 2.0, June 1999.

Certified under the reference PP/9911, DCSSI

Anwendungshinweise und Interpretationen zum

Schema, AIS31: Funktionalitätsklassen und

Evaluationsmethodologie für physikalische

Zufallszahlengeneratoren, Version 1, 25.09.2001,

Bundesamt für Sicherheit in der Informationstechnik

Copyright 2010 © 3 FQR 110 5185 Ed2

[FIPS180-2]

[CC31-1]

[CC31-2]

[CC31-3]

[PKCS#1]

[PKCS#3]

[IASECC]

[FQR 110 5169]

[ISO7816-4]

FIPS PUB 180-2, Secure Hash Standard", August

2002 , National Institute of Standards and Technology

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

PKCS#1 The public Key Cryptography standards,

RSA Data Security Inc. 1993

PKCS#3

IAS ECC v1.0.1

FQR 110 5169 ConfigurationList

Note :

The last edition of this document contains the whole set of applicable up to date documents for this CC evaluation project.

Identification Cards _ Integrated Circuits Card _ Part

4 : Organisation, security and commands for interchange : 2005

TERPSICHORE - ST ID-ONE COSMO V7.0.1-n -

P5CD041V1A, P5CC081V1A and P5CD081V1A

FQR 110 4933 Ed2

Card Specification - Version 2.1.1 - Mars, 2003

[ST_TERPSICHORE]

[GP]

1.3.

Abbreviations

ADF

AES

AID

AMB

Application Dedicated File

Advanced Encryption Standard

Application Identifier

Access Mode Byte

Copyright 2010 © 4 FQR 110 5185 Ed2

APDU received/Data sent by the chip)

API

CA

Application Protocol Data Unit (command

Application Programming Interfaces

Certification authority

CBC Cipher Block Chaining

CGA Certificate Generation Authority (Authority in charge of generating the qualified certificate(s) )

C/S

CSE

DAP

Data Authentication Pattern (enable to ensure integrity & authenticity of javacard package when loaded)

Device Authentication with Privacy Protection DAPP

DES

DF

DH

DTBS

DTBS Representation

EAL

EF

EEPROM

Memory

Data Encryption Standard

Dedicated File

Diffie Hellman

Data to be signed (Sent by the SCA)

Representation of the Data to be signed

Evaluation Assurance Level

Elementary File

Electrically Erasable Programmable Read Only

FID

GP

HI the user)

Client / Server

Current Security Environment

File identifier

Global Platform

Human Interface (used to enter the RAD and VAD by

IC

ICC

Integrated Chip

IFD

MAC

PIN

PKI

Integrated Chip card

Interface Device

Message Authentication code

Personal Identification Number

Public Key Infrastructure

Copyright 2010 © 5 FQR 110 5185 Ed2

RAD

RCA

Reference Authentication Data (PIN stored)

Root Certification Authority

ROM

RSA

Read Only Memory

Rivest Shamir Adleman

RSA CRT

Theorem

Rivest Shamir Adleman – Chinese Remainder

SCA a qualified signature to the chip)

Signature creation Application (Application requiring

SCB

SCD

SCP

SDO

Security Condition Byte

Signature Creation Data (Signature key)

Secure Channel Procotol

Security Data Object

SE

SHA

SSCD

SSE

SSESP

Policies

SSO

SVD key)

TOE

URL

USB

VAD the holder)

XML

Security Environment

Secure hashing Algorithm

Secure Signature Creation Device

Static Security Environment

Static Security Environment for Security

Single Sign On

Signature Verification Data (Signature Verification

Target of evaluation

Uniform Resource Locator

Universal Serial Bus

Verification Authentication Data (PIN submitted by eXtensible Markup Language

2.

Target Of Evaluation Description

Copyright 2010 © 6 FQR 110 5185 Ed2

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.

The javacard Applet provides to the outside the whole set of security services described herein. To do so, [Applet] relies on

[API] which provides a wide range of services enabling to manage the files and cryptographic objects

[Interface] which provides the mechanisms for data sharing with other applet

Javacard API provided by the underlying javacard open platform

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 fulfils the recommendations indicated in the guidance documentation of the javacard open platform ([AGD_PRE_TERPSICHORE] and [AGD_OPE_TERPSICHORE]) 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:

Copyright 2010 © 7 FQR 110 5185 Ed2

TOE

[Applet]

[API] [Interface]

Applet 1 Applet n

Javacard Open Platform

Limits of the TOE

2.1.3.

Physical scope

It is made of the javacard open platform [TERPSICHORE] with the card manager in state OP_READY, INITIALIZED or SECURED on which the javacard packages are masked in the .ROM code

Physical overview

Once constructed, the TOE is a bare microchip with its external interfaces for communication.

It may be used on several physical medium

Copyright 2010 © 8 FQR 110 5185 Ed2

• 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 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.

• 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:

Copyright 2010 © 9 FQR 110 5185 Ed2

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 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

……

Copyright 2010 © 10 FQR 110 5185 Ed2

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):

Guidance document for preparation

Guidance document for use

Guidance document for preparation of

TERPSICHORE

Guidance document for operational user of

TERPSICHORE

IAS ECC v1.0.1 on ID-One Cosmo V7.0.1-n Card

FQR 110 5171 Ed2 - AGD_PRE

FQR 110 5170 Ed1 - AGD_OPE

ID-One Cosmo V7.0.1 - Pre-Perso Guide

FQR 110 4910 Ed3

ID-One Cosmo V7.0.1 - Reference Guide

FQR 110 4911 Ed3

ID-One Cosmo V7.0.1 - Security recommendations

FQR 110 4912 Ed3

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

P08-018 - ID One IAS ECC\07169x - IAS ECC Java Applet light

Internal identification

Configuration management (PVCS) label

Name of [API]:

Internal identification

“V1.2”

IAS ECC Javacard API

P08-018 - ID One IAS ECC\07166x - IAS ECC Javacard API

Copyright 2010 © 11 FQR 110 5185 Ed2

Configuration management (PVCS) label

Name of [Interface]

“V1.1”

Internal identification

Configuration management (PVCS) label

Server Applet Manager javacard Interface

P08-018 - ID One IAS ECC\07076x - Server Applet Manager javacard

Interface

“V1.2”

Names of [JOP]:

ID-One Cosmo V7.0.1-n Standard Dual

ID-One Cosmo V7.0.1-n Standard

ID-One Cosmo V7.0.1-n Basic Dual

ANSSI-CC-2010-40

Certificate

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, which are secure container storing cryptographic data

(PINs, Keys,….)

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 © 12 FQR 110 5185 Ed2

Root File dedicated file Transparent file

Application dedicated file

Transparent file

Application dedicated file dedicated file

Transparent file

Example of FileSystem Structure

Copyright 2010 © 13 FQR 110 5185 Ed2

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 File Structure by use of file selection.

Each file 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].

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 © 14 FQR 110 5185 Ed2

• 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

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:

Copyright 2010 © 15 FQR 110 5185 Ed2

Access conditions

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 features 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].

Prior 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 © 16 FQR 110 5185 Ed2

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 holds.

2.3.4. eServices

The IAS ECC application offers as well eServices features:

C/S authentication: this feature enables to authenticate the TOE on behalf of the cardholder’s PC to a remote web server.

Digital signature: this feature enables 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 © 17 FQR 110 5185 Ed2

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 through 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 DTBSrepresentation 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) will 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

PIN. The access conditions on the PINs that are accessed by these entry points are still enforced.

Copyright 2010 © 18 FQR 110 5185 Ed2

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, even though 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.

• eServices features are added, enabling the cardholder to perform C/S authentication, Encryption key decipherment….

Copyright 2010 © 19 FQR 110 5185 Ed2

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 © 20 FQR 110 5185 Ed2

c

p ha s e 1 p h as e 2 p h as e 3 p h as e 4 p h as e 5

I C pho tom a sk fa b rica tio n

IC m anu fac turi ng

S o ftw are dev e lo p m ent

ID O ne IA S E C C

S o ftw a re d eve lop m en t

ID O ne C osm o v7 .0.1 X X X

IC dat aba se c ons truct io n

IC te stin g

I C M a n u fa ct u r er

N X P

C ard pr inti ng

T estin g m icr om o dul e

E m be d din g

p h as e 6

P re -p ers o na lisa tion

T e s ting

p h as e 7

T e stin g

P er son a lisa tion

S m a rtc a rd pr o duc t

E n d-u s age

S m a rtc ard

E n d o f l ife

A pp lic a tion

E n d-u s ag e

A pp lic a tion

E nd o f l ife

Figure 1 : life cycle state of the composite TOE

Copyright 2010 © 21 FQR 110 5185 Ed2

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 packages (applet and interface)

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

At the end of this phase: the javacard packages together with the javacard open platform are transferred to the chip manufacturer in order to be masked on silicium. The integrity (and confidentiality) of the data transfer between the premises of OBERTHUR TECHNOLOGIES and the chip manufacturer is covered by the certificate of [TERPSICHORE]

At the end of this phase 1, the javacard packages are protected in integrity.

Copyright 2010 © 22 FQR 110 5185 Ed2

Hardware development (Phase 2)

In this phase, the javacard open platform (JOP) is being built.

The javacard packages are 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 packages and javacard open platform is covered by the evaluation of the development premises of the silicium manufacturer (see [TERPSICHORE])

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 application is instantiated

Javacard open platform manufacturing (phase 3)

In this phase, the javacard open platform (JOP) is self protected. The javacard packages are self protected as they are present in the ROM code of the javacard open platform (JOP)

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 javacard packages are self protected: their integrity and confidentiality is ensured as they are present in the ROM code of the javacard open platform

Copyright 2010 © 23 FQR 110 5185 Ed2

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

Javacard open platform (JOP) pre-personnnalization (phase 5)

The Javacard open platform (JOP) is under the control of the Manufacturing Agent. This subject shall be authenticated prior to any action on the javacard open platform.

In any case, at the end of this phase, the composite TOE is produced and self protected.

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)

Copyright 2010 © 24 FQR 110 5185 Ed2

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

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

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.4. 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

Phase 1

Phase 2

Phase 3

Phase 4

Phase 5

Environment

Development

Development

Development

Covered by

ALC [TERPSICHORE]

ALC [EUTERPE]

ALC [TERPSICHORE]

ALC [TERPSICHORE]

Javacard open platform is self protected

Javacard packages are self protected

Production of TOE AGD_PRE [TERPSICHORE]

Production of TOE

AGD_PRE [TERPSICHORE],

AGD_OPE [TERPSICHORE],

Copyright 2010 © 25 FQR 110 5185 Ed2

Phase 6

Phase 7

TOE is self protected

Operational

AGD_OPE [TERPSICHORE]

AGD_PRE [EUTERPE]

TOE is constructed

Operational

AGD_OPE [TERPSICHORE]

AGD_OPE [EUTERPE]

State of the TOE depending on the phase

This chapter describes when the TOE is self protected

Life cycle phase

State of the javacard packages 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

Phase 2

Phase 3

Phase 4

Phase 5

Phase 6 constructed but not self protected constructed but not self protected constructed and self protected

N/A

Application is instantiated

Self protected

Self protected

In construction

In construction constructed and self protected

Self protected

Self protected

Self protected

In construction

In construction

In construction and self protected

In construction and self protected

In construction and self protected

Constructed and self protected

Phase 7 Self protected Self protected

Constructed and self protected

2.5.5. 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

Phase 1

Phase 2

Life cycle phase with respect to [SSCD2] and [SSCD3]

Design

Fabrication

Phase 3

Phase 4

Fabrication

Javacard open platform is self protected

Javacard packages are self protected

N/A

Copyright 2010 © 26 FQR 110 5185 Ed2

Phase 5

Phase 6

Phase 7

Loading of application data

TOE is self protected

Personalization

TOE is constructed

Usage

Destruction

For each of these phases, the following subjects may interact with the TOE

Life cycle phase of the TOE

Phase 1

Phase 2

Phase 3

Subject interacting with the TOE

OBERTHUR TECHNOLOGIES

OBERTHUR TECHNOLOGIES

OBERTHUR TECHNOLOGIES

Javacard open platform is self protected

Javacard packages are self protected

Phase 4

Phase 5

Manufacturing Agent

Offcard

Manufacturing Agent

Offcard

Phase 6

Phase 7

TOE is self protected

Personalization Agent

Offcard

TOE is constructed

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.

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.

Copyright 2010 © 27 FQR 110 5185 Ed2

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

3.

Target Of Evaluation Security Environment

Copyright 2010 © 28 FQR 110 5185 Ed2

3.1.

Remote IT entity

The following remote IT entity may interact with the TOE

Remote IT

SCA

CGA

SSCD type 1

IFD

HI

Description

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

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

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

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 communicate in a secure manner.

This remote IT is present in phase 7 of the life cycle of the TOE

Human interface used by local users to enter

RAD or VAD.

The data entered are transmitted to the TOE via a trusted path

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

Copyright 2010 © 29 FQR 110 5185 Ed2

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

S.User

S.Admin

S.Signatory

S.TOE_Admin

S.Personalizer

Description

End User of the TOE that can be identified as

S.Admin or S.Signatory

It is named User

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

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

User who is in charge to perform the configuration management of the TOE

It is named TOE_Administrator

User who operates in Phase 6 of the life cycle.

It is in charge to perform the TOE initialization

Copyright 2010 © 30 FQR 110 5185 Ed2

S.DAP_Admin

S.Manufacturer

S.SCA

S.CGA

S.SSCD

S.Offcard

Copyright 2010 ©

S.IFD and TOE personalization

It is named Personalizer

User who operates as soon as the DAP feature is activated on the javacard open platform: in phase 6 (optionally) & 7 of the life cycle. It holds the DAP signature key and is in charge of controling the applet to be loaded on the javacard open platform.

It is named DAP_Admin

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

[TERPSICHORE]

It is named Manufacturer

It is the SCA seen as a subject interacting with the TOE.

As such, depending on the use case, it might belong to the category S.Admin.

It is named SCA

It is the CGA seen as a subject interacting with the TOE.

As such, depending on the use case, it might belong to the category S.Admin.

It is named CGA

It is the SSCD seen as a subject interacting with the TOE.

As such, depending on the use case, it might belong to the category S.Admin.

It is named SSCD

It is the IFD seen as a subject interacting with the TOE.

As such, depending on the use case, it might belong to the category S.Admin.

It is named IFD

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

31 FQR 110 5185 Ed2

has a high attack potential and knows no secret

3.3.

User data

The following user data are managed by the TOE

User Data

D.DTBS

D.VAD

D.AUTH_CRYPTOGRAM

D.SIGNATURE

D.DTBS

D.RAD

D.SCD

D.SVD

D.TOE_SerialNumber

D.AUTH_KEYS

Description

DTBS and DTBS representation ; set of data or its representation which is intended to be signed

VAD : PIN code data entered by the End User (S.Signatory or S.Admin) to authenticate itself or to perform a signature operation

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

Electronic signature (Unforgeabilty of electronic signatures must be assured)

DTBS and DTBS representation stored within the TOE; set of data or its representation which is intended to be signed

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

SCD : private key used to perform an electronic signature operation There might be several SCD within the TOE

SVD :public key linked to the SCD and used to perform an electronic signature verification There might be several SVD within the TOE

Serial number of the TOE. This data is required to perform device and external authentication. It is an

IDENTIFICATION_DATA

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

Copyright 2010 © 32 FQR 110 5185 Ed2

D.ESERVICES_KEYS

D.TOE_AUTH_PUBLIC_KEYS

D.TOE_AUTH_PRIVATE_KEYS

D.IDENTIFICATION_DATA

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

These keys are secret data shared by the TOE and the other entity (symmetric 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

Group of public key matching the private authentication key of the TOE

Group of authentication private key(s) of the TOE.

The authentication mechanism involved are

C/S authentication

DAPP Internal authentication

Data or group of data stored in the TOE, which 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

D.APPLI

D.SCD_ID

Description

The quality of the signature creation application (IAS

ECC) must be maintained so that it can participate to the legal validity of electronic signature

Identifier of the SCD. In order to identify the matching certificate, each SCD shall be associated with an

Copyright 2010 © 33 FQR 110 5185 Ed2

D.EPHEMERAL_KEYS

D.STATE

D.Medium

D.HashOffCard

D.SymAuthMechanisms

D.AsymAuthMechanisms

D.SM_DATA identifier

The ephemeral key extracted from a certificate (CVC). It may be used to

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

Life Cycle state of the TOE. Its value is either

“SELECTABLE” (in phase 6) or “PERSONALIZED”. (in phase 7)

Attribute of the TOE indicating which communication medium can be used (contact and/or contactless)

Attribute of the TOE indicating if qualified signature can be performed on a hash computed off card

Attribute of the TOE indicating if authentication mechanisms based on symmetric scheme can be used

Attribute of the TOE indicating if authentication mechanisms based on asymmetric scheme can be used

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 © 34 FQR 110 5185 Ed2

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 DTBSrepresentation 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.

Copyright 2010 © 35 FQR 110 5185 Ed2

T.SCD_Derive Derive the signature-creation data

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 DTBSrepresentation 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.

Copyright 2010 © 36 FQR 110 5185 Ed2

T.Skimming_Contactless Skimming of the TOE in contactless

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 device

Eavesdropping of the communication between TOE and

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

Copyright 2010 © 37 FQR 110 5185 Ed2

ensures that the use of the TOE is evident with signatures through the certificate or other publicly available information.

P.QSign Qualified electronic signatures

The signatory uses a signature-creation system to sign data with 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 loaded on the javacard open platform

Control of the other applet that may be

Copyright 2010 © 38 FQR 110 5185 Ed2

When the TOE is configured to be used in contactless mode, the Manufacturing Agent

(for phase 5), the Personalization Agent (for phase 6), and the DAP_Administrator (for phase 6 & 7) shall ensure that any applet that is loaded on the javacard open platform does not enable to track/identify the TOE.

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 recommendations 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 reimport 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.

Copyright 2010 © 39 FQR 110 5185 Ed2

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.

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

Copyright 2010 © 40 FQR 110 5185 Ed2

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

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 (identification data,..). It enforces the data 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, reimport 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.

Copyright 2010 © 41 FQR 110 5185 Ed2

OT.LifeCycle_Management Management of the life cycle

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.

Copyright 2010 © 42 FQR 110 5185 Ed2

OE.SCD_Unique Uniqueness of the signature-creation data

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

Copyright 2010 © 43 FQR 110 5185 Ed2

successfully authenticated entity. Moreover, they shall only be transferred in a manner 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 © 44 FQR 110 5185 Ed2

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 recommendations indicated in [AGD_PRE]. These recommendations 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 © 45 FQR 110 5185 Ed2

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 © 46 FQR 110 5185 Ed2

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 © 47 FQR 110 5185 Ed2

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]

Application Note

:

The type of algorithm used by the TOE depends on the configuration set during the platform personalisation (For more details see

[AGD_PRE_TERPSICHORE]. 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]

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_PRE_TERPSICHORE]). 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].

3.10.2. FDP : USER DATA PROTECTION

FDP_ACC Access Control Policy

FDP_ACC.1.1/SVD transfer SFP

Copyright 2010 © 48 FQR 110 5185 Ed2

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].

Application note:

It is very important to stress the following point. When used in contactless, the TOE will have to apply this policy to receive the VAD, RAD, DTBS, AUTH_KEYS, ESERVICES KEYS,

TOE_AUTH_PRIVATE_KEYS and TOE_AUTH_PUBLIC_KEYS and return the signature, the

SVD, the eServices keys (except the Diffie Hellman Domain parameters), the

TOE_AUTH_PUBLIC_KEYS, the identification data. It does not conflict with the existing security

Copyright 2010 © 49 FQR 110 5185 Ed2

policies set for SCD import, signature creation, SVD export…it only enhances the security policies. In such case, the IFD will be considered as a unique entity acting as a SCA, CGA and

SSCD. However, the IFD may afterwards dispatch the data to the true SCA, CGA and SSCD, provided it does ensures a trusted channel between the IFD and the SCA, CGA and SSCD.

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

S.Admin

Remark

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

User,

Personalizer

Role

S.Signatory

S.Personalizer

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

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

Copyright 2010 © 50 FQR 110 5185 Ed2

the life cycle

Administration group

TOE Attributes

Medium

HashOffCard

SymAuthMechanisms

Meaning

Communication medium allowed

Qualified signature computed over hash computed off card

Authentication mechanisms based on symmetric scheme allowed

Status

Contact

Contactless

Authorized

Not authorized

Authorized

Not authorized

Remark

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

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

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

Copyright 2010 © 51 FQR 110 5185 Ed2

AsymAuthMechanisms

Authentication mechanisms based on asymmetric scheme allowed

Authorized

Not authorized

S.TOE_Admin

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 and in phase 7 by

S.TOE_Admin

Copyright 2010 © 52 FQR 110 5185 Ed2

Initialisation attribute group

Subject Security Attribute

User, Personalizer

SCD/SVD

Management

Status

Authorized

Not authorized

Remark

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

(type 2)

import

The access condition is granted to a User if the following conditions are fulfilled:

The User successfully is 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 © 53 FQR 110 5185 Ed2

User Data

SCD

Security Attribute

Secure SCD Import Allowed

Status

No

Yes

Remark

The TOE controls the access on every object it possesses, 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 © 54 FQR 110 5185 Ed2

Signature-creation attribute group

User Data Security Attribute

SCD

DTBS

SCD operational

Sent by an authorized

SCA

Status

No

Yes

No

Yes

Remark

The attribute SCD operational is granted by the submission of the RAD by the User S.Signatory

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

User

SCA

CGA

SSCD type 1

IFD

Personalizer

Key

Management import

Authorized

Not authorized

Remark

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 © 55 FQR 110 5185 Ed2

Key generation

Management

Key export

Management

Copyright 2010 ©

Authorized

Not authorized

Authorized

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

Diffie Hellmann

(including

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

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

Diffie Hellmann parameters,

(including

Domain 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

56 FQR 110 5185 Ed2

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

Protection against eavesdropping group

User Security Attribute

IFD

Data exchange in contactless

Status

Not authorized authorized

Remark

The TOE controls the access on every object it possesses, in particular the

DTBS, VAD, SIGNATURE, RAD,

SVD,

ESERVICES_KEYS,

AUTH_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 authenticated is successfully

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

F D P_ ACF . 1. 1 / SVD transfer SF P

The TSF shall enforce the [ SVD transfer SF P] to objects based on [G e n e r a l at tr ib ut e ]

F D P_ ACF . 1. 2 / SVD transfer SF P

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”

F D P_ ACF . 1. 3 / SVD transfer SF P

Copyright 2010 © 57 FQR 110 5185 Ed2

The TSF shall explicitly authorise access of subjects to objects based on the following additional rules:

[none]

F D P_ ACF . 1. 4 / SVD transfer SF P

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

Initialisation SFP

F D P_ ACF . 1. 1 / Initialisation SF P

The TSF shall enforce the [Initialisation SFP] to objects based on [General attribute] and [Initialisation

attribute group].

F D P_ ACF . 1. 2 / Initialisation SF P

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”

F D P_ ACF . 1. 3 / Initialisation SF P

The TSF shall explicitly authorise access of subjects to objects based on the following additional rules:

[none]

F D P_ ACF . 1. 4 / Initialisation SF P

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

Copyright 2010 © 58 FQR 110 5185 Ed2

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”

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)

Copyright 2010 © 59 FQR 110 5185 Ed2

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

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

Copyright 2010 © 60 FQR 110 5185 Ed2

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]

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”.

Copyright 2010 © 61 FQR 110 5185 Ed2

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:

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 private 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.

Copyright 2010 © 62 FQR 110 5185 Ed2

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

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].

Copyright 2010 © 63 FQR 110 5185 Ed2

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

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...

Copyright 2010 © 64 FQR 110 5185 Ed2

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].

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

Copyright 2010 © 65 FQR 110 5185 Ed2

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

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.

Copyright 2010 © 66 FQR 110 5185 Ed2

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

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

Asymmetric external authentication keys used by the Administrator

Asymmetric 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

D.AUTH_KEYS

S.Personalizer

S.TOE_Admin

Positive integer number ‘1’

Positive integer number ‘1’

Time of next authentication increases

Time of next authentication increases

Copyright 2010 © 67 FQR 110 5185 Ed2

D.AUTH_KEYS

D.AUTH_KEYS

D.EPHEMERAL_KEYS

S.Admin

(when using symmetric role authentication)

S.Admin or

Remote IT entity

(when using symmetric device authentication)

S.Admin

(when using asymmetric role authentication)

Administrator configurable positive integer ‘N’

0

N

15

Administrator configurable positive integer ‘N’

0

N

15

Positive integer number ‘1’

If N= ‘0’, no actions are taken.

If N != ‘0’, the key is blocked

If N= ‘0’, no actions are taken.

If N != ‘0’, the key is blocked

The key is deallocated with respect to

FDP_RIP.1.1

Administrator or

The key is deallocated

D.EPHEMERAL_KEYS

Remote IT entity

Positive integer number ‘1’ with respect to

(when using asymmetric device authentication)

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 subject 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]

Copyright 2010 © 68 FQR 110 5185 Ed2

[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

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].

Copyright 2010 © 69 FQR 110 5185 Ed2

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].

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

Copyright 2010 © 70 FQR 110 5185 Ed2

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

SCD/SVD Management

Authorized identified role

Administrator

Personalizer

Administrator SCD Operational

Medium

HashOffCard Personalizer

TOE_Administrator SymAuthMechanism

AsymAuthMechanism data exchange in contactless IFD

Key import Management

Key generation Management

Key export Management

Secure SCD import Allowed

Sent by an authorized SCA

Role

User, SCA, CGA, SSCD, IFD

SSCD

SCA

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 traceability

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:

Copyright 2010 © 71 FQR 110 5185 Ed2

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_TERPSICHORE] :

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:

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.

Copyright 2010 © 72 FQR 110 5185 Ed2

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].

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].

Copyright 2010 © 73 FQR 110 5185 Ed2

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.

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

Copyright 2010 © 74 FQR 110 5185 Ed2

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

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 traceability 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 traceability]

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

Copyright 2010 © 75 FQR 110 5185 Ed2

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 was 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 traceability risks, the trusted path is removed and replaced by the trusted channel defined by:

FTP_ITC.1.1/ TOE Contactless (against traceability)

FTP_ITC.1.2/ TOE Contactless (against traceability)

FTP_ITC.1.3/ TOE Contactless (against traceability)

FDP_UCT.1.1/ TOE Contactless (against disclosure)

FDP_UIT.1.1/ TOE Contactless (against eavesdropping)

FDP_UIT.1.2/ TOE Contactless (against eavesdropping)

3.11.

Security requirements for the IT environment

This section describes the IT security requirements that are to be met by the IT environment of the TOE.

The IT environment of the TOE is composed of the Certification Generation Application (CGA) and the

Signature Creation Application (SCA).

These requirements are as stated in [SSCD2] & [SSCD3].

3.11.1. Signature key generation (SSCD Type1)

Cryptographic key generation (FCS_CKM.1)

FCS CKM.1.1

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]

Cryptographic key destruction (FCS_CKM.4)

FCS_CKM.4.1 / Type1

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: [assignment:

list of standards].

Copyright 2010 © 76 FQR 110 5185 Ed2

Application notes:

The cryptographic key SCD will be destroyed automatically after export.

FCS_CKM.4.1 / DES Session 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: [assignment:

list of standards].

Cryptographic operation (FCS_COP.1)

FCS_COP.1.1/ CORRESP

The TSF shall perform [SCD/SVD correspondence verification] in accordance with a specified cryptographic algorithm [assignment: cryptographic algorithm] and cryptographic key sizes [1024 bits,

1536 bits or 2048 bits] that meet the following: [assignment: list of standards].

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].

FCS_COP.1.1/ Certificate computation

Copyright 2010 © 77 FQR 110 5185 Ed2

The TSF shall perform [Certificate computation] 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 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

Triple DES list of standards

SCP1 and SCP02 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_PRE_TERPSICHORE]). The algorithm selection is performed by the subject R.Prepersonalizer and is covered by FMT_MTD.1/JCRE

Random Number Generation (FCS_RNG)

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 [assignment: list of standards].

Subset access control (FDP_ACC.1)

FDP_ACC.1.1/ SCD Export SFP

The TSF shall enforce the [SCD Export SFP] on [export of SCD by Administrator].

Copyright 2010 © 78 FQR 110 5185 Ed2

Basic data exchange confidentiality (FDP_UCT.1)

FDP_UCT.1.1/ Sender

The TSF shall enforce the [SCD Export SFP] to be able to [transmit] user data in a manner protected from unauthorised disclosure.

Inter-TSF trusted channel (FTP_ITC.1)

FTP_ITC.1.1/ SCD Export

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 Export

The TSF shall permit [the TSF] to initiate communication via the trusted channel.

FTP_ITC.1.3/ SCD Export

The TSF shall initiate communication via the trusted channel for [SCD export]

Refinement:

The mentioned remote trusted IT product is a SSCD Type2

Application note:

If the TOE exports the SVD to a SSCD Type2 and the SSCD Type 2 holds the SVD then the trusted channel between the TOE and the SSCD type 2 will be required.

3.11.2. Certification generation application (CGA)

Cryptographic key generation (FCS_CKM.1)

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]

Cryptographic key distribution (FCS_CKM.2)

FCS_CKM.2.1/ CGA

The TSF shall distribute cryptographic keys in accordance with a specified cryptographic key distribution method [qualified certificates] that meets the following: [assignment: list of standards].

Cryptographic key access (FCS_CKM.3)

FCS_CKM.3.1/ CGA

Copyright 2010 © 79 FQR 110 5185 Ed2

The TSF shall perform [import the SVD] in accordance with a specified cryptographic key access method

[import through a secure channel] that meets the following: [IASECC].

Cryptographic key destruction (FCS_CKM.4)

FCS_CKM.4.1 / DES Session 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: [assignment:

list of standards].

Cryptographic operation (FCS_COP.1)

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].

FCS_COP.1.1/ Certificate computation

The TSF shall perform [Certificate computation] 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

Copyright 2010 © 80 FQR 110 5185 Ed2

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].

Random Number Generation (FCS_RNG)

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 [assignment: list of standards].

Data exchange integrity (FDP_UIT.1)

FDP_UIT.1.1/ SVD Import

The TSF shall enforce the [SVD import SFP] to be able to [receive] user data in a manner protected from

[modification and insertion] errors.

FDP_UIT.1.2/ SVD Import

The TSF shall be able to determine on receipt of user data, whether [modification and insertion] has occurred.

Inter-TSF trusted channel (FTP_ITC.1)

FTP_ITC.1.1/ SVD 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/ SVD Import

The TSF shall permit [the TSF] to initiate communication via the trusted channel.

FTP_ITC.1.3/ SVD Import

The TSF shall initiate communication via the trusted channel for [SVD import]

Copyright 2010 © 81 FQR 110 5185 Ed2

3.11.3. Signature creation application (SCA)

Cryptographic key generation (FCS_CKM.1)

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]

Cryptographic key destruction (FCS_CKM.4)

FCS_CKM.4.1 / DES Session 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: [assignment:

list of standards].

Cryptographic operation (FCS_COP.1)

FCS_COP.1.1/ SCA Hash

The TSF shall perform [hashing the DTBS] in accordance with a specified cryptographic algorithm [SHA-

1 and SHA-256] and cryptographic key sizes [none] that meet the following: [FIPS 140-2].

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/ Certificate computation

Copyright 2010 © 82 FQR 110 5185 Ed2

The TSF shall perform [Certificate computation] 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].

Random Number Generation (FCS_RNG)

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 [assignment: list of standards].

Data exchange integrity (FDP_UIT.1)

FDP_UIT.1.1/ SCA DTBS

The TSF shall enforce the [Signature-creation SFP] to be able to [transmit] user data in a manner protected from [modification, deletion and insertion] errors.

FDP_UIT.1.2/ SCA DTBS

The TSF shall be able to determine on receipt of user data, whether [modification, deletion and

insertion] has occurred.

Inter-TSF trusted channel (FTP_ITC.1)

FTP_ITC.1.1/ SCA DTBS

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/ SCA DTBS

The TSF shall permit [the TSF] to initiate communication via the trusted channel.

FTP_ITC.1.3/ SCA DTBS

Copyright 2010 © 83 FQR 110 5185 Ed2

The TSF shall initiate communication via the trusted channel for [signing DTBS-representation by means

of the SSCD]

Trusted path (FTP_TRP.1)

The trusted path between the TOE and the SCA will be required only if the human interface for user authentication is not provided by the TOE itself but by the SCA.

FTP_TRP.1.1/ SCA

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/ SCA

The TSF shall permit [the TSF or local users] to initiate communication via the trusted path.

FTP_TRP.1.3/ SCA

The TSF shall require the use of the trusted path for [initial user authentication].

3.11.4. Interface Device (IFD)

Cryptographic key generation (FCS_CKM.1)

FCS CKM.1.1 / Authentication keys

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]

3.12.

Security requirements for the Administrator

This section describes the Administrator security requirements that are to be met when they use cryptographic mean to authenticate themselves.

Cryptographic operation (FCS_COP.1)

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].

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/ Certificate computation

Copyright 2010 © 84 FQR 110 5185 Ed2

The TSF shall perform [Certificate computation] 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].

3.13.

Security requirements for the Personalizer and TOE_Administrator

This section describes the Personalizer and TOE_Administrator security requirements that are to be met as they use cryptographic mean to authenticate themselves.

Cryptographic operation (FCS_COP.1)

FCS_COP.1.1/ GP Authentication

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

Triple DES list of standards

SCP1 and SCP02 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_PRE_TERPSICHORE]. The algorithm selection is performed by the subject R.Prepersonalizer and is covered by FMT_MTD.1/JCRE

3.14.

Security requirements for the non-IT environment

3.14.1. Standard security requirements

R.Administrator_Guide Application of Administrator Guidance

The implementation of the requirements of the Directive, ANNEX II "Requirements for certification service-providers issuing qualified certificates", literal (e), stipulates employees of the CSP or other relevant entities to follow the administrator guidance provided for the TOE. Appropriate supervision of the CSP or other relevant entities shall ensure the ongoing compliance.

R.Sigy_Guide Application of User Guidance

Copyright 2010 © 85 FQR 110 5185 Ed2

The SCP implementation of the requirements of the Directive, ANNEX II "Requirements for certification service-providers issuing qualified certificates", literal (k), stipulates the signatory to follow the user guidance provided for the TOE.

R.Sigy_Name

Signatory's name in the Qualified Certificate

The CSP shall verify the identity of the person to which a qualified certificate is issued according to the Directive [1], ANNEX II "Requirements for certification-serviceproviders issuing qualified certificates", literal (d). The CSP shall verify that this person holds the SSCD, which implements the SCD corresponding to the SVD to be included

3.14.2. Complementary security requirements

R.Keys_Protection transfer

Protection of the authentication keys and TOE’s public authentication keys during

The environment shall ensure the protection of authentication keys when transferred to the TOE in order to protect it from disclosure and ensure they are not modified nor altered. The TOE’s public authentication key shall be protected against modification when exported from the TOE to the outside when an authentication certificate request is made.

R.Contactless_Personalization Specific rules when used in contactless

When the TOE is used in contactless, the entity in charge of issuing the TOE (the Personalizer) shall ensure the security policy applied to protect the identification data (stored in the TOE) is restrictive. The

TOE shall either refuse the access, or mandate the authentication of the outside. When exchanged, the data shall be protected in confidentiality and authenticate the sender.

Furthermore, if another applet is loaded on the javacard open platform, the entity in charge of issuing the

TOE shall make sure the applet does not endanger the privacy of the TOE by enabling it to be tracked. It shall either control the applet behaviour, either ban it.

This requirement applies to

The manufacturer, if the applet is loaded in phase 5

The personaliser, if the applet is loaded in phase 6 while DAP is not activated

The DAP_Admin, if the applet is loaded while DAP control is activated

R.LinkBetweenSCDandCertificate Link between the SCD(s) stored in the TOE and qualified certificates

The environment shall ensure at any time a valid link between the SCD(s) stored in the

TOE and the matching (qualified) certificates. Each time the SCD is modified (by import or generation), an unambiguous link between the SCD(s) and the matching (qualified) certificate(s) shall be maintained. 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.

R.TOE_Construction Construction of the TOE

The Construction of the TOE shall be done by the Personalization Agent who acts in phase 6 of the TOE life Cycle. The Personalization Agent shall be a trusted person and shall apply the recommendations indicated in [AGD_PRE].

Copyright 2010 © 86 FQR 110 5185 Ed2

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_TERPSICHORE]

They are listed in the following table.

Security function

SF_Firewall

Description

Firewall Security policy

SF_Card_Content_Management

SF_Card_Management_Environment

Control of loading, deletion and installation of applet and packages

Initialization and management of internal data structure of the Card Manager

Generation/Verification of signature

SF_Signature

SF_Encryption_and_Decryption

Encryption/Decryption of Data

SF_Message_Digest_Generation

SF_Random_Number_Generation

Message Digest computation

Random number generation

SF_Key_Destruction

SF_Atomic_Transactions

Destruction of keys

SF_data_integrity

Integrity of keys, PIN, packages, …

SF_Clearing_of_Sensitive_Information

Clearing of sensitive data when not used anymore

Execution of atomic operations

SF_Key_Generation

Generation of Asymmetric keys

SF_Key_Distribution

SF_Cardholder_Verification

Distribution of keys

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

SF_Entity_Authentication/Secure_Channel

Control of security level when communicating with resident application

GP Secure Channel management

SF_GP_Dispatcher

SF_KEY_MANAGEMENT

Control of security level when communicating with the Card manager

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

Copyright 2010 © 87 FQR 110 5185 Ed2

SF_Prepersonalization

SF_Key_Access

SF_Key_Agreement

Prepersonalization of the TOE

Secure Access to keys and PINs

4.1.2. Security functions added by the composite TOE

Key agreement

The TOE provides the following security functions on top of the one provided by the underlying javacard open platform.

Security function

SF.PIN_MGT

SF.SIG

SF.DEV_AUTH

SF.ADM_AUTH

SF.SM

SF.KEY_MGT

SF.CONF

SF.ESERVICE

Description

PIN Management

Signature Computation

Device Authentication

Administrator Authentication

Secure messaging

Key Management

Configuration of TOE

Execution of eServices

SF.EAVESDROPPING_PROTECTION

SF.SAFESTATE_MGT

SF.PHYS

Protection of communication against eavesdropping (when the TOE is used in contactless)

Safe State Management

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

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.

Copyright 2010 © 88 FQR 110 5185 Ed2

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 through 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 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.

Copyright 2010 © 89 FQR 110 5185 Ed2

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.

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

Copyright 2010 © 90 FQR 110 5185 Ed2

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.

SF.CONF

This security function applies in phase 6 & 7. It manages the initialization of TSF data and administration features of the TOE.

Copyright 2010 © 91 FQR 110 5185 Ed2

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.

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

Copyright 2010 © 92 FQR 110 5185 Ed2

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.1.3. Composition with the Security functions provided of the javacard Open platform

The .following table shows how the security functions of the Composite TOE are supported by the security functions of the underlying javacard open platform:

Security function

SF.PIN_MGT

SF.SIG

SF.DEV_AUTH

SF.ADM_AUTH

Depends on

SF_Cardholder_Verification

SF_Clearing_of_Sensitive_Information

SF_Key_Access

SF_Clearing_of_Sensitive_Information

SF_Message_Digest_Generation

SF_Encryption_and_Decryption

SF_Key_Access

SF_Clearing_of_Sensitive_Information

SF_Key_Destruction

SF_Random_Number_Generation

SF_Message_Digest_Generation

SF_Encryption_and_Decryption

SF_Signature

SF_Key_Access

SF_KEY_MANAGEMENT

SF_Entity_Authentication/Secure_Channel

SF_Clearing_of_Sensitive_Information

SF_Key_Destruction

SF_Random_Number_Generation

SF_Message_Digest_Generation

SF_Encryption_and_Decryption

SF_Signature

Copyright 2010 © 93 FQR 110 5185 Ed2

SF.SM

SF.KEY_MGT

SF.CONF

SF.ESERVICE

SF.EAVESDROPPING_PROTECTION

SF.SAFESTATE_MGT

SF.PHYS

SF_Key_Access

SF_Clearing_of_Sensitive_Information

SF_Key_Destruction

SF_Random_Number_Generation

SF_Encryption_and_Decryption

SF_Signature

SF_Key_Access

SF_Key_Generation

SF_Clearing_of_Sensitive_Information

SF_Key_Destruction

N/A

SF_Key_Access

SF_Message_Digest_Generation

SF_Encryption_and_Decryption

SF_Signature

SF_Prepersonalization

SF_Resident_Application_Dispatcher

SF_Manufacturer_Authentication

SF_Exception

SF_Data_Coherency

SF_Memory_failure

SF_Hardware_Operating

SF_Atomic_Transactions

SF_data_integrity

SF_Random_Number_Generation

SF_Signature

SF_Unobservability

SF_Security_Functions_of_the IC

4.1.4. Dependencies of the Security functions

This section shows that the security functions are complete and internally consistent by showing that they are mutually supportive and provide an ‘integrated effective whole’ also with the javacard open platform, on which it is built

Number

1

2

Security function

SF.PIN_MGT

SF.SIG

Supported by

SF_Cardholder_Verification

SF_Clearing_of_Sensitive_Information

SF.PHYS

SF.SAFESTATE_MGT

SF.EAVESDROPPING_PROTECTION

SF_Key_Access

SF_Clearing_of_Sensitive_Information

SF_Message_Digest_Generation

SF_Encryption_and_Decryption

SF.PHYS

SF.SAFESTATE_MGT

SF.EAVESDROPPING_PROTECTION

SF.CONF

SF.KEY_MGT

Number

#25

#21

#11

#10

#9

#40

#21

#17

#16

#11

#10

#9

#7

#6

Copyright 2010 © 94 FQR 110 5185 Ed2

8

9

3

4

5

6

7

SF.DEV_AUTH

SF.ADM_AUTH

SF.SM

SF.KEY_MGT

SF.CONF

SF.ESERVICE

SF.EAVESDROPPING_PROT

SF.SM

SF_Key_Access

SF_Clearing_of_Sensitive_Information

SF_Key_Destruction

SF_Random_Number_Generation

SF_Message_Digest_Generation

SF_Encryption_and_Decryption

SF_Signature

SF.SAFESTATE_MGT

SF.PHYS

SF.CONF

SF.KEY_MGT

SF_Key_Access

SF_KEY_MANAGEMENT

SF_Entity_Authentication/Secure_Channel

SF_Clearing_of_Sensitive_Information

SF_Key_Destruction

SF_Random_Number_Generation

SF_Message_Digest_Generation

SF_Encryption_and_Decryption

SF_Signature

SF.PHYS

SF.SAFESTATE_MGT

SF.CONF

SF.KEY_MGT

SF_Key_Access

SF_Clearing_of_Sensitive_Information

SF_Key_Destruction

SF_Random_Number_Generation

SF_Encryption_and_Decryption

SF_Signature

SF.PHYS

SF.SAFESTATE_MGT

SF.DEV_AUTH

SF_Key_Access

SF_Key_Generation

SF_Clearing_of_Sensitive_Information

SF_Key_Destruction

SF.PHYS

SF.SAFESTATE_MGT

SF.EAVESDROPPING_PROTECTION

SF.SM

SF.PHYS

SF.SAFESTATE_MGT

SF_Key_Access

SF_Message_Digest_Generation

SF_Encryption_and_Decryption

SF_Signature

SF.PHYS

SF.SAFESTATE_MGT

SF.EAVESDROPPING_PROTECTION

SF_Prepersonalization

#11

#10

#7

#6

#40

#21

#19

#18

#16

#15

#11

#10

#3

#40

#23

#21

#19

#11

#10

#9

#5

#11

#10

#40

#17

#16

#15

#11

#10

#9

#39

#5

#40

#21

#19

#18

#17

#16

#15

#11

#10

#7

#6

#40

#36

#34

#21

#19

#18

#17

#16

#15

Copyright 2010 © 95 FQR 110 5185 Ed2

10

11

12

13

14

15

16

17

22

23

24

25

26

27

28

29

30

31

32

18

19

20

21

33

34

35

36

ECTION

SF.SAFESTATE_MGT

SF.PHYS

SF_Firewall

SF_Card_Content_Manageme nt

SF_Card_Management_Enviro nment

SF_Signature

SF_Encryption_and_Decryptio n

SF_Message_Digest_Generati on

SF_Random_Number_Generat ion

SF_Key_Destruction

SF_data_integrity

SF_Clearing_of_Sensitive_Info rmation

SF_Atomic_Transactions

SF_Key_Generation

SF_Key_Distribution

SF_Cardholder_Verification

SF_Hardware_Operating

SF_Memory_failure

SF_Data_Coherency

SF_Exception

SF_DAP_Verification

SF_TOKEN

SF_Manufacturer_Authenticati on

SF_Resident_Application_Disp atcher

SF_Entity_Authentication/Secu re_Channel

SF_GP_Dispatcher

SF_KEY_MANAGEMENT

SF_Resident_Application_Dispatcher

SF_Manufacturer_Authentication

SF.PHYS

SF.SAFESTATE_MGT

SF.CONF

SF.SM

SF_Exception

SF_Data_Coherency

SF_Memory_failure

SF_Hardware_Operating

SF_Atomic_Transactions

SF_data_integrity

SF_Random_Number_Generation

SF_Signature

SF.PHYS

SF_Unobservability

SF_Security_Functions_of_the IC

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

Copyright 2010 © 96 FQR 110 5185 Ed2

#29

#28

#27

#26

#22

#20

#18

#15

#11

#33

#32

#11

#10

#7

#5

#38

#37

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

N/A

37

38

39

40

41

4.2.

SF_Security_Functions_of_the

IC

SF_Unobservability

SF_Prepersonalization

SF_Key_Access

SF_Key_Agreement

Security assurance requirements

N/A

N/A

N/A

N/A

N/A

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 [TERPSICHORE] has a certificate level at

Evaluation Assurance Level 4 (EAL4) augmented with ALC_DVS.2 and AVA_VAN.5.

This is conform to 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

AM_ADV

AM_AGD

AM_ALC

AM_ASE

AM_ATE

AM_VAN

4.2.2. ADV : Development

Name

Development

Guidance

Life Cycle

Security target

Tests

Vulnerability

The following components are included:

Component

ADV_ARC

ADV_FSP

ADV_IMP

ADV_INT

ADV_SPM

ADV_TDS

Level

1

4

1

N/A

N/A

3

N/A

N/A

N/A

N/A

N/A

Copyright 2010 © 97 FQR 110 5185 Ed2

4.2.3. AGD : Guidance

The following components are included:

Component

AGD_OPE

AGD_PRE

4.2.4. ALC : Life Cycle

The following components are included:

Component

ALC_CMC

ALC_CMS

ALC_DEL

ALC_DVS

ALC_FLR

ALC_LCD

ALC_TAT

Note : ALC_DVS is enhanced

4.2.5. ASE : Security target

The following components are included:

Component

ASE_CCL

ASE_ECD

ASE_INT

ASE_OBJ

ASE_REQ

ASE_SPD

ASE_TSS

4.2.6. ATE : Tests

The following components are included:

Component

ATE_COV

ATE_DPT

ATE_FUN

Copyright 2010 © 98

Level

1

1

Level

4

4

1

2 – enhanced component

N/A

1

1

Level

2

1

1

1

1

1

2

Level

2

2

1

FQR 110 5185 Ed2

ATE_IND

4.2.7. VAN : Vulnerability Analysis

2

The following component is included:

Component

VAN

Note : VAN is enhanced

4.3.

EAL augmentations rationale

Level

5 –enhanced component

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.

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

Copyright 2010 © 99 FQR 110 5185 Ed2

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

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

Copyright 2010 © 100 FQR 110 5185 Ed2

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

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

Copyright 2010 © 101 FQR 110 5185 Ed2

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 recommendations 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].

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

Copyright 2010 © 102 FQR 110 5185 Ed2

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 platform, 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 recommendations 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 requirements

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

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.

Copyright 2010 © 103 FQR 110 5185 Ed2

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) 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)

Copyright 2010 © 104 FQR 110 5185 Ed2

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 recommendations 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) 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

Copyright 2010 © 105 FQR 110 5185 Ed2

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 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 signaturecreation 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

Copyright 2010 © 106 FQR 110 5185 Ed2

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 by the means of OT.DTBS_Integrity_TOE by verifying the integrity of the DTBSrepresentation. 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

Copyright 2010 © 107 FQR 110 5185 Ed2

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 endanger 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 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.

Copyright 2010 © 108 FQR 110 5185 Ed2

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;

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

Copyright 2010 © 109 FQR 110 5185 Ed2

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 DTBSrepresentation. 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.

Family behaviour

This family defines requirements to mitigate intelligible emanations.

Component levelling:

FPT_EMSEC TOE emanation

1

Copyright 2010 © 110 FQR 110 5185 Ed2

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.

6.2.

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].

Definition of FCS_RNG

See [ST_TERPSICHORE] for definition

Copyright 2010 ©

111

FQR 110 5185 Ed2

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement

Table of contents