Sie sind auf Seite 1von 84

BS EN 419251-3:2013

BSI Standards Publication

Security requirements for


device for authentication
Part 3: Additional functionality
for security targets
BS EN 419251-3:2013 BRITISH STANDARD

National foreword
This British Standard is the UK implementation of EN 419251-3:2013.
The UK participation in its preparation was entrusted to
Technical Committee IST/17, Cards and personal identification.
A list of organizations represented on this committee can be
obtained on request to its secretary.
This publication does not purport to include all the necessary
provisions of a contract. Users are responsible for its correct
application.
© The British Standards Institution 2013.
Published by BSI Standards Limited 2013.
ISBN 978 0 580 74078 7
ICS 35.240.15
Compliance with a British Standard cannot confer immunity
from legal obligations.
This British Standard was published under the authority of the
Standards Policy and Strategy Committee on 30 April 2013.
Amendments issued since publication
Date Text affected
BS EN 419251-3:2013

EUROPEAN STANDARD EN 419251-3


NORME EUROPÉENNE
EUROPÄISCHE NORM March 2013

ICS 35.240.15

English Version

Security requirements for device for authentication - Part 3:


Additional functionality for security targets

Profils de protection pour dispositif d'authentification - Sicherheitsanforderungen für Geräte zur Authentisierung -
Partie 3: Fonctionnalités additionnelles Teil 3: Zusätzliche Funktionalitäten für Sicherheitsziele

This European Standard was approved by CEN on 7 December 2012.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European
Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national
standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member.

This European Standard exists in three official versions (English, French, German). A version in any other language made by translation
under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same
status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United
Kingdom.

EUROPEAN COMMITTEE FOR STANDARDIZATION


COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG

Management Centre: Avenue Marnix 17, B-1000 Brussels

© 2013 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 419251-3:2013: E
worldwide for CEN national Members.
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Contents Page

Foreword .......................................................................................................................................................5
1 Scope ................................................................................................................................................6
2 Normative references .......................................................................................................................6
3 Conformance ....................................................................................................................................6
3.1 CC Conformance Claim ...................................................................................................................6
3.2 PP Claim ...........................................................................................................................................6
3.3 Package Claim ..................................................................................................................................6
3.4 Conformance Rationale ...................................................................................................................6
3.5 Conformance Statement ..................................................................................................................7
4 Terms and definitions ......................................................................................................................7
5 Symbols and abbreviations .............................................................................................................9
6 Overview of the target of evaluation ............................................................................................... 9
6.1 TOE Type ..........................................................................................................................................9
6.2 TOE Usage ........................................................................................................................................9
6.3 Security Features of the TOE......................................................................................................... 10
6.4 Required non-TOE Hardware and Software .................................................................................. 10
6.5 Protection Profile Usage ................................................................................................................ 10
6.6 Groups ............................................................................................................................................ 10
6.6.1 General ........................................................................................................................................... 10
6.6.2 Main groups.................................................................................................................................... 10
6.6.3 Environment groups ...................................................................................................................... 11
6.7 Configurations................................................................................................................................ 13
6.7.1 General ........................................................................................................................................... 13
6.7.2 Rules ............................................................................................................................................... 13
6.7.3 Possible Configurations ................................................................................................................ 14
6.8 TOE Environment ........................................................................................................................... 15
6.8.1 Overall view .................................................................................................................................... 15
6.8.2 Personalisation application ........................................................................................................... 16
6.8.3 Administration application ............................................................................................................ 17
6.8.4 Authentication application............................................................................................................. 18
6.8.5 Verifier ............................................................................................................................................ 19
6.8.6 Key Generator ................................................................................................................................ 19
6.8.7 Certification Authority.................................................................................................................... 20
6.8.8 Examples of applications............................................................................................................... 20
6.9 Life Cycle ........................................................................................................................................ 22
6.9.1 Overview ......................................................................................................................................... 22
6.9.2 Pre-Personalisation phase............................................................................................................. 23
6.9.3 Personalisation phase ................................................................................................................... 23
6.9.4 Usage phase ................................................................................................................................... 24
7 Security problem definition ........................................................................................................... 26
7.1 Assets ............................................................................................................................................. 26
7.1.1 General ........................................................................................................................................... 26
7.1.2 Core group...................................................................................................................................... 26
7.1.3 KeyGen group ................................................................................................................................ 26
7.1.4 Admin group................................................................................................................................... 27
7.2 Users............................................................................................................................................... 27
7.2.1 Core group...................................................................................................................................... 27
7.2.2 KeyImp group ................................................................................................................................. 28

2
BS EN 419251-3:2013
EN 419251-3:2013 (E)

7.2.3 KeyGen group ................................................................................................................................28


7.2.4 Admin group ...................................................................................................................................28
7.3 Threats ............................................................................................................................................28
7.3.1 General ...........................................................................................................................................28
7.3.2 Core group ......................................................................................................................................29
7.3.3 KeyGen group ................................................................................................................................30
7.3.4 Admin group ...................................................................................................................................30
7.4 Organisational security policies ....................................................................................................30
7.4.1 Core group ......................................................................................................................................30
7.4.2 KeyGen group ................................................................................................................................31
7.4.3 Admin group ...................................................................................................................................31
7.5 Assumptions ..................................................................................................................................31
7.5.1 Core group ......................................................................................................................................31
7.5.2 KeyGen group ................................................................................................................................32
7.5.3 Admin group ...................................................................................................................................32
8 Security objectives .........................................................................................................................32
8.1 General − Transfer of sensitive data .............................................................................................32
8.2 Security objectives for the TOE .....................................................................................................33
8.2.1 Core group ......................................................................................................................................33
8.2.2 KeyImp group .................................................................................................................................34
8.2.3 KeyGen group ................................................................................................................................34
8.2.4 Admin group ...................................................................................................................................34
8.2.5 Untrusted PersoAppli .....................................................................................................................35
8.2.6 Untrusted AuthAppli ......................................................................................................................35
8.2.7 Untrusted Verifier ...........................................................................................................................35
8.2.8 Untrusted CA ..................................................................................................................................35
8.2.9 Untrusted AdminAppli....................................................................................................................35
8.3 Security objectives for the operational environment....................................................................36
8.3.1 Core group ......................................................................................................................................36
8.3.2 KeyImp group .................................................................................................................................36
8.3.3 Admin group ...................................................................................................................................37
8.3.4 Trusted PersoAppli ........................................................................................................................37
8.3.5 Trusted AuthAppli ..........................................................................................................................37
8.3.6 Trusted Verifier ...............................................................................................................................37
8.3.7 Trusted CA......................................................................................................................................37
8.3.8 Trusted AdminAppli .......................................................................................................................37
8.4 Rationale for Security objectives...................................................................................................38
9 Extended component definition – Definition of the Family FCS_RNG .........................................43
10 Security requirements ....................................................................................................................43
10.1 General ...........................................................................................................................................43
10.2 Introduction ....................................................................................................................................44
10.2.1 Subjects Objects and security attributes ......................................................................................44
10.2.2 Operations ......................................................................................................................................45
10.3 Security functional requirements ..................................................................................................46
10.3.1 General ...........................................................................................................................................46
10.3.2 Core group ......................................................................................................................................47
10.3.3 KeyImp group .................................................................................................................................55
10.3.4 KeyGen group ................................................................................................................................58
10.3.5 Admin group ...................................................................................................................................61
10.3.6 Untrusted PersoAppli .....................................................................................................................65
10.3.7 Untrusted AuthAppli ......................................................................................................................66
10.3.8 Untrusted Verifier ...........................................................................................................................66
10.3.9 Untrusted CA ..................................................................................................................................67
10.3.10 Untrusted AdminAppli....................................................................................................................68
10.4 Security assurance requirements..................................................................................................68
10.5 SFR / Security objectives ...............................................................................................................69
10.6 SFR Dependencies .........................................................................................................................74
10.7 Rationale for the Assurance Requirements ..................................................................................76

3
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Bibliography................................................................................................................................................ 78
Index............................................................................................................................................................ 79

Figures
Figure 1 — TOE Security Features ...............................................................................................................15
Figure 2 — Personalisation application environment .....................................................................................16
Figure 3 — Administration application environment .......................................................................................17
Figure 4 — Authentication application environment .......................................................................................18
Figure 5 — TOE Life Cycle ...........................................................................................................................22

Tables
Table 1 — Basic configurations.....................................................................................................................14
Table 2 — IdTrusted configurations ..............................................................................................................14
Table 3 — Protection of sensitive data ..........................................................................................................33
Table 4 — Security objectives vs problem definition rationale ........................................................................38
Table 5 — Security attributes ........................................................................................................................45
Table 6 — Core security attributes ................................................................................................................50
Table 7 — Core operations ...........................................................................................................................50
Table 8 — Core security attributes − Operation .............................................................................................51
Table 9 — Core security attributes - initial value ............................................................................................52
Table 10 — Core security attributes – Updates .............................................................................................53
Table 11 — TSF data – updates ...................................................................................................................53
Table 12 — KeyImp security attributes ..........................................................................................................55
Table 13 — KeyImp security attributes - operations.......................................................................................56
Table 14 — KeyImp security attributes – update authorised roles ..................................................................57
Table 15 — KeyImp security attributes – update values ................................................................................58
Table 16 — KeyGen operations ....................................................................................................................59
Table 17 — KeyGen security attributes .........................................................................................................59
Table 18 — KeyGen operation rules .............................................................................................................60
Table 19 — KeyGen security attributes – update authorised roles .................................................................60
Table 20 — KeyGen security attributes – initial values ..................................................................................61
Table 21 — KeyGen security attributes – update values................................................................................61
Table 22 — Admin security attributes – update authorised roles ....................................................................64
Table 23 — Admin security attributes – initial values .....................................................................................64
Table 24 — Admin security attributes – update values ..................................................................................64
Table 25 — Admin TSF data – operations .....................................................................................................65
Table 26 — SFR vs Security objectives retionale ..........................................................................................69
Table 27 — SFR dependencies ....................................................................................................................74

4
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Foreword
This document (EN 419251-3:2013) has been prepared by Technical Committee CEN/TC 224 “Personal
identification, electronic signature and cards and their related systems and operations”, the secretariat of
which is held by AFNOR.

This European Standard shall be given the status of a national standard, either by publication of an identical
text or by endorsement, at the latest by September 2013, and conflicting national standards shall be
withdrawn at the latest by September 2013.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights.

EN 419251 contains the following parts:

 EN 419251-1, Security requirements for device for authentication — Part 1: Protection profile for core
functionality;

 EN 419251-2, Security requirements for device for authentication — Part 2: Protection profile for
extension for trusted channel to certificate generation application;

 EN 419251-3, Security requirements for device for authentication — Part 3: Additional functionality for
security targets (the present document).

The present document was submitted to the Enquiry under the reference prEN 16248-3.

According to the CEN/CENELEC Internal Regulations, the national standards organisations of the following
countries are bound to implement this European Standard: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech
Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece,
Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal,
Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.

5
BS EN 419251-3:2013
EN 419251-3:2013 (E)

1 Scope
This European Standard contains packages that define security requirements for an authentication device.
This document is Part 3. Part 1 and Part 2 are Protections Profiles – PP– based on the packages defined in
this document. Packages contained in this document can be added in a Security Target –ST- claiming PP of
Part 1 or Part 2.

2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.

ISO/IEC 10181-2:1996, Information technology — Open Systems Interconnection — Security frameworks for
open systems: Authentication framework

ISO/IEC 15408-1:2009 1), Information technology — Security techniques — Evaluation criteria for IT security
— Part 1: Introduction and general model

ISO/IEC 15408-21), Information technology — Security techniques — Evaluation criteria for IT security —
Part 2: Security functional components

ISO/IEC 15408-31), Information technology — Security techniques — Evaluation criteria for IT security —
Part 3: Security assurance components

ISO/IEC 18045, Information technology — Security techniques — Methodology for IT security evaluation

3 Conformance

3.1 CC Conformance Claim

These packages are CC Part 2 extended and CC Part 3 conformant and written according to ISO/IEC 15408-
1, -2, -3 and ISO/IEC 18045.

3.2 PP Claim

These packages do not claim conformance to any other Protection Profile.

3.3 Package Claim

The evaluation assurance level for these packages is EAL4-augmented with the assurance components
AVA_VAN.5 and ALC_DVS.2.

3.4 Conformance Rationale

Since these packages do not claim conformance to any other protection profile, no rationale is necessary
here.

1) ISO/IEC 15408-1, -2 and -3 respectively correspond to Common Criteria for Information Technology Security Evaluation,
Parts 1, 2 and 3.

6
BS EN 419251-3:2013
EN 419251-3:2013 (E)

3.5 Conformance Statement

The conformance required by these packages is the demonstrable-PP conformance. This would facilitate
conformance claim to both the PP “Authentication device” and other PPs for Security Target (ST) authors.

4 Terms and definitions


For the purposes of this document, the following terms and definitions apply.

4.1
Administrator
person who is allowed administration operations on the authentication device

Note 1 to entry: See 7.2 for more details.

4.2
Authentication Protocol sensitive data
data used in the process of authentication of the TOE by the external entity

Note 1 to entry: These data are linked to the Authentication private key, e.g. Authentication Certificate or APuK.

Note 2 to entry: Authentication Protocol sensitive data may be empty if the environment is trusted, and the holder
public key known to the system.

4.3
Certificate
attestation, which links the APuK to a person and confirms the identity of that person (as defined in the
Directive [8], article 2, Clause 9)

4.4
Certificate Info
information associated with an Authentication key pair that consists either:

 a signer's public key certificate; or

 one or more hash values of a signer's public key certificate together the identifier of the hash function
used to compute these hash values, and some information which allows the signer to disambiguate
between several signers certificates

4.5
Configuration
set of groups

Note 1 to entry: Each configuration corresponds to one PP. It has its own rationale. See the rest of the document.

4.6
Group
set Assets, threats, objectives, and Requirements, addressing a specific function

Note 1 to entry: See the rest of the document.

4.7
Holder
legitimate holder of the authentication device

Note 1 to entry: See 7.2 for more details.

7
BS EN 419251-3:2013
EN 419251-3:2013 (E)

4.8
Issuer
user of the authentication device during personalisation

Note 1 to entry: See 7.2 for more details.

4.9
Protection Profile
PP
implementation-independent statement of security needs for a TOE

[SOURCE: ISO/IEC 15408-1:2009, Clause 4 "Terms and definitions", modified  in ISO/IEC 15408-1, the
protection profile refers to a TOE type instead of a TOE in this document]

4.10
PP collection
document defining groups and configurations

4.11
Reference Authentication Data
usually called RAD, data stored inside the TOE and used as a reference to which the VAD will be compared

Note 1 to entry: This RAD can be biometrics data, a PIN, or a symmetric key. It can also be a combination of these
factors. The RAD is not an Asset, it is TSF data.

4.12
Trusted channel
means by which a TSF and a remote trusted IT product can communicate with necessary confidence

[SOURCE: ISO/IEC 15408-1:2009, Clause 4 "Terms and definitions"]

4.13
Trusted Environment
environment that ensures the protection of sensitive data transfers between the TOE and a remote trusted IT
product (resp. a user)

Note 1 to entry: A trusted (or untrusted) environment relates to the whole communication channel between the TOE
and the remote trusted IT product (resp. the user).

4.14
Untrusted Environment
environment that does not ensure the protection of sensitive data transfers between the TOE and a remote
trusted IT product (resp. a user)

Note 1 to entry: This protection should be ensured by the TOE with a Trusted Channel (resp. a Trusted Path). An
untrusted (or trusted) environment relates to the whole communication channel between the TOE and the remote trusted
IT product (resp. the user).

4.15
User
current User of the TOE

Note 1 to entry: The User can be the Issuer, the Holder, the Administrator.

4.16
Verifier
entity which is or represents the entity requiring an authenticated identity

Note 1 to entry: A verifier includes the functions necessary for engaging in authentication exchanges.

8
BS EN 419251-3:2013
EN 419251-3:2013 (E)

[SOURCE: ISO/IEC 10181-2:1996, modified  the full sentence at the end of the definition in the ISO/IEC has
been turned into the present Note 1 to entry]

4.17
Verification Authentication Data
usually called VAD, data entered into the TOE and checked against the RAD as a means of authentication

Note 1 to entry: As the RAD, the VAD is not an Asset, it is TSF data.

5 Symbols and abbreviations

APSD Authentication Protocol Sensitive Data


APrK Authentication Private Key
APuK Authentication Public Key
CA Certificate Authority
CC Common Criteria
OBKG On-Board Key Generation
PIN Personal Identification Number
PC Personal Computer
PP Protection Profile
RAD Reference Authentication Data
SSCD Secure Signature Creation Device
ST Security Target
TOE Target of Evaluation
VAD Verification Authentication Data

6 Overview of the target of evaluation

6.1 TOE Type

The aimed objective is to define security requirements that an authentication device shall conform to in the
perspective of a security evaluation. The Target of Evaluation (TOE2)) considered in this PP corresponds to a
hardware device (such as, for example, a smart card or USB token) allowing its legitimate holder to
authenticate himself when accessing an on-line service or to guarantee the origin authentication of data sent
by the User to a distant agent3).

This PP has been constructed such as to make it possible for an ST writer to claim conformance to both this
PP and PP-SSCD [3], [4], [5], [6], [7] and easily merge these PPs into one ST.

6.2 TOE Usage

In order to connect to an on-line service with restricted access or send data whose origin should be
authenticated, the Holder shall use his personal authentication device. The service provided by the device
requires the prior input of authentication data by the Holder on a terminal device (as specified in 6.4). The
authentication service included in the TOE relies solely on public-key cryptography mechanisms to allow the
Holder to authenticate himself and access to the on-line service with restricted access or to enable the origin
authentication of data sent by the Holder.

Note that authentication devices implementing shared key (i.e. symmetric-key) mechanisms for authentication
purposes are therefore not considered in this PP.

2) In the document the terms authentication device, device and TOE are equivalent.
3) He is a physical person that receives some authenticated data from the users.

9
BS EN 419251-3:2013
EN 419251-3:2013 (E)

6.3 Security Features of the TOE

The primary functionality of the TOE is to enable the Holder to authenticate himself in order to access an on-
line service or guarantee the origin authentication of data sent by the Holder to a distant agent.

To implement such services, a chain of trust shall be created between the TOE and the on-line restricted-
access service or the agent in charge of authenticating the origin of data sent by the Holder. This trust chain is
created in two phases:

 Authentication of the Holder by the TOE;

 Authentication of the TOE by the verifier on behalf of the Holder.

6.4 Required non-TOE Hardware and Software

The authentication device requires the services provided by a terminal device to enable the Holder to input his
authentication data. Typically, this terminal device (e.g., a PINPad terminal) ensures the protection of
authentication data input in confidentiality and integrity and its secure transfer to the TOE. The general
features of this terminal along with the method employed to enable the input of authentication data are
considered out of the TOE scope.

It should be however noted that the level of security of the whole operational system including the TOE
depends on the security level of the TOE operational environment. In particular, an authenticated terminal
device for the input and transfer of the Holder authentication data could be required in usage environments
considered as untrusted.

6.5 Protection Profile Usage

The requirements present in this PP define the minimum security rules an ST of an authentication device shall
conform to but are in no way exhaustive. It remains indeed possible to add functionalities or also refer to
another PP. However, any modifications to this PP are restricted by the rules defined by the conformance as
set forth in Clause 3.

In other respects, this PP aims at ensuring compatibility with PP-SSCD [3], [4], [5], [6], [7], in order to define
complementary security requirements for products offering both authentication and signature services.

6.6 Groups

6.6.1 General

A group is a set of Assets, Threats, Objectives, and Requirements, addressing a specific function, e.g.
KeyGen addresses key generation on TOE.

6.6.2 Main groups

6.6.2.1 General

This PP has the following main groups: Core, KeyImp, KeyGen, and Admin.

6.6.2.2 Core group

Core group applies to all Configurations. It contains the basic security features for all Authentication devices.

10
BS EN 419251-3:2013
EN 419251-3:2013 (E)

6.6.2.3 KeyImp group

KeyImp group contains the security features directly linked to the import of the Authentication Private Key into
the card.

6.6.2.4 KeyGen group

KeyGen group contains the security features directly linked to the On Board Key Generation (OBKG) of the
Authentication Private Key.

6.6.2.5 Admin group

Admin group contains the security features directly linked to the following Administration functions, which take
place during the Usage phase:

 Import and export of the public key and certificate by administrator.

 Storage and export of log data by administrator.

 Reset of Holder authentication failures counter by administrator.

6.6.3 Environment groups

6.6.3.1 General

This PP has additional groups in order to deal with Trusted and Untrusted environments. The TOE exports
and imports sensitive data to and from the following environments:

 Personalisation application

 Authentication application

 Verifier

 CA (KeyGen group)

 Administration application (Admin group)

For each environment, two groups are defined, a Trusted one and an Untrusted one. Each configuration
selects one group in each pair. A configuration cannot include both groups of the same pair but it can include
none if the TOE does not import or export sensitive data from the corresponding environment.

6.6.3.2 Trusted PersoAppli

Trusted PersoAppli group contains the security features directly linked to the transfer of sensitive data
between the Personalisation application and the TOE, when these transfers take place in a protected
environment, i.e. when potential attacks are countered by the environment.

However even in a trusted environment the Authentication private key shall be imported within a trusted
channel.

6.6.3.3 Trusted AuthAppli

Trusted AuthAppli group contains the security features directly linked to the transfer of sensitive data between
the Authentication application and the TOE, when these transfers take place in a protected environment, i.e.
when potential attacks are countered by the environment.

11
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Under some conditions, which are not specified in this document, a PC in an office or at home can be
considered a trusted environment.

6.6.3.4 Trusted Verifier

Trusted Verifier group contains the security features directly linked to the transfer of sensitive data between
the Verifier and the TOE, when these transfers take place in a protected environment, i.e. when potential
attacks are countered by the environment.

This group is also required when a trusted channel, eg using SSL, is established from the Authentication
application to the Verifier but not from the TOE to the Verifier.

6.6.3.5 Trusted CA

Trusted CA group contains the security features directly linked to the transfer of sensitive data between the
TOE and the CA, when these transfers take place in a protected environment, i.e. when potential attacks are
countered by the environment.

This group only applies when KeyGen group belongs to the configuration.

6.6.3.6 Trusted AdminAppli

Trusted AdminAppli group contains the security features directly linked to the transfer of sensitive data
between the Administration application and the TOE, when these transfers take place in a protected
environment, i.e. when potential attacks are countered by the environment.

This group only applies when admin group belongs to the configuration.

6.6.3.7 Untrusted PersoAppli

Untrusted PersoAppli group contains the security features directly linked to the transfer of sensitive data
between the Personalisation application and the TOE, when these transfers do not take place in a protected
environment.

This means that the TOE has to establish a trusted channel with the Personalisation application.

6.6.3.8 Untrusted AuthAppli

Untrusted AuthApp group contains the security features directly linked to the transfer of sensitive data
between the Authentication application and the TOE, when these transfers do not take place in a protected
environment.

This means that the TOE has to establish a trusted channel with the Authentication application.

6.6.3.9 Untrusted Verifier

Untrusted Verifier group contains the security features directly linked to the transfer of sensitive data between
the Verifier and the TOE for the authentication of TOE, when these transfers do not take place in a protected
environment.

This means that the TOE has to use a secure protocol for the authentication of TOE by the Verifier.

6.6.3.10 Untrusted CA

Untrusted CA group contains the security features directly linked to the export of the Authentication public key
to the CA, when thes export does not take place in a protected environment.

12
BS EN 419251-3:2013
EN 419251-3:2013 (E)

This means that the TOE has to establish a trusted channel with the CA.

This group only applies when KeyGen group belong to the configuration.

6.6.3.11 Untrusted AdminAppli

Untrusted AdminApp group contains the security features directly linked to the transfer of sensitive data
between the Administration application and the TOE, when these transfers do not take place in a protected
environment.

This means that the TOE has to establish a trusted channel with the Administration application.

This group only applies when admin group belong to the configuration.

6.7 Configurations

6.7.1 General

A Configuration is a set of groups. Each configuration corresponds to one PP and has to be certified
separately. It has its own rationale.

6.7.2 Rules

Due to the nature of groups, the following rules apply:

 Core

Core group is mandatory.

 KeyImp/KeyGen

A Configuration shall include at least KeyImp group or KeyGen group. It can also include both groups.

 Admin

Admin group is optional.

 Trusted PersoAppli / Untrusted PersoAppli

A Configuration shall include either Trusted PersoAppli group or Untrusted PersoAppli.group. It cannot include
both.

 Trusted AuthAppli / Untrusted AuthAppli

A Configuration shall include either Trusted AuthAppli group or Untrusted AuthAppli.group. It cannot include
both.

 Trusted Verifier / Untrusted Verifier

A Configuration shall include either Trusted Verifier group or Untrusted Verifier.group. It cannot include both.

 Trusted CA / Untrusted CA

These groups are related to KeyGen group

A Configuration including KeyGen group shall include either Trusted CA group or Untrusted CA.group. It
cannot include both.

13
BS EN 419251-3:2013
EN 419251-3:2013 (E)

 Trusted AdminAppli / Untrusted AdminAppli

These groups are related to Admin group.

A Configuration including Admin group shall include either Trusted AdminAppli group or Untrusted
AdminAppli.group. It cannot include both.

6.7.3 Possible Configurations

6.7.3.1 General

With the restrictions described previously, the only possible configurations are the following:

6.7.3.2 Basic configurations

Table 1 — Basic configurations


Basic configurations BC1 BC2 BC3 BC4 BC5 BC6
Core 1 1 1 1 1 1
KeyImp 1 0 1 1 0 1
KeyGen 0 1 1 0 1 1
Admin 0 0 0 1 1 1

Basic configurations are identified from BC1 to BC6.

6.7.3.3 Transfer configurations

They are related to the transfers of sensitive data:

Table 2 — IdTrusted configurations


Transfers
Trusted PersoApp 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
Trusted AutApp 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1
Trusted Verifier 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1 0 0 0 0 1 1 1 1
Trusted CA 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1
Trusted AdminApp 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
IdTrusted can have all values from 0 to 1F
As there are 5 independent possibilities,
IdTrusted has 25 = 32 possibilities
A configuration is identified by its Basic configuration and its Transfer configuration: (IdBasic, IdTrusted)
Not all combinations of these two arrays are allowed. The only restrictions are:
(Trusted CA group or Untrusted CA) group is included only when KeyGen group is included.
(Trusted AdminApp group or Untrusted AdminApp) group is included only when Admin group is included.

Therefore there are 6 * 32 *[1/2 * (1+ 2/3)] * [1/2 * (1+1/2)] = 120 possible configurations.
The rationale will address all these configurations.
The ST writer shall specify the configuration of the TOE.

14
BS EN 419251-3:2013
EN 419251-3:2013 (E)

6.8 TOE Environment

6.8.1 Overall view

Figure 1 — TOE Security Features

Figure 1 shows all the security features of the TOE, in the Personnalisation, Usage and Administration
environments.

The legend explains how different colors identity the security features of the different groups: Core, KeyImp,
KeyGen, and Admin. Further details on groups can be found in the rest of the document.

15
BS EN 419251-3:2013
EN 419251-3:2013 (E)

6.8.2 Personalisation application

6.8.2.1 General

Figure 2 — Personalisation application environment

6.8.2.2 Functionalities

The Personalisation application interfaces the TOE at the Personalisation facility. These operations take place
beforethe issuance of the TOE.

After the issuance of the TOE, when the TOE is in Usage phase, an Administrator can perform Administration
operations, using an Administration application, see 6.8.3.

This application initialises all data specific to the end user. These data can include:

 APrK

 User RAD

 Administrator RAD

If the TOE generates the APrK, the application retrieves the APuK and sends it to the CA that will generate
the certificate.

If the TOE imports the APrK, the application retrieves the APuK and sends it to the TOE. The application also
ensures that the APuK is securely - protected in integrity - sent from the key pair generator to the CA that
generates the certificate.

16
BS EN 419251-3:2013
EN 419251-3:2013 (E)

6.8.2.3 Communication

Depending on the group selected in the configuration - Untrusted PersoAppli group or Trusted PersoAppli
group - Transfer of sensitive data has or does not have to be protected by the environment or by a trusted
channel.

However, as APrK is of special special sensitivity, a "Trusted channel" is always required to load it.

6.8.3 Administration application

6.8.3.1 General

Figure 3 — Administration application environment

6.8.3.2 Functionalities

The Administration application interfaces the TOE at the Administration facility. The connection to the facility
can be online.

This application performs the administration operations of the TOE. These operations are:

 Retrieving authentication logs;

 Reset User RAD Retry counter.

Before performing these operations, the administrator shall authenticate himself to the TOE, using the
administrator RAD.

17
BS EN 419251-3:2013
EN 419251-3:2013 (E)

6.8.3.3 Communication

Depending on the group selected in the configuration - Untrusted AdminAppli group or Trusted AdminAppli
group - Transfer of sensitive data has or does not have to be protected by the environment or by a trusted
channel.

6.8.4 Authentication application

6.8.4.1 General

Figure 4 — Authentication application environment

6.8.4.2 Functionalities

The Authentication application interfaces the TOE when the holder needs to be authenticated by the Verifier. It
can run on several devices:

 a PC at home to access online services (e-administration, e-commerce…);

 a specific device to identify and authenticate a card holder (police control…).

The TOE may contain several Authentication keys. It may also contain Signature keys. Therefore the
Authentication application shall ensure a clear and secure human interface to prevent any confusion, when
selecting the Verifier and the authentication key.

The VAD can also be entered via a separate Human Interface.

6.8.4.3 Communication

Depending on the group selected in the configuration - Untrusted AuthAppli group or Trusted AuthAppli group
- Transfer of sensitive data has or does not have to be protected by the environment or by a trusted channel.

18
BS EN 419251-3:2013
EN 419251-3:2013 (E)

The TOE and the Authentication application exchange the following sensitive data:

 Import of Holder VAD for authentication;

 Import of Holder RAD for update;

 Request for authentication from a specific Verifier.

6.8.5 Verifier

6.8.5.1 Functionalities

The Verifier wants to authenticate the card holder.

The holder activates an “authentication application” on the PC.

The “authentication application” selects an online server (e-administration, e-commerce…), that request
authentication and the authentication key.

According to the verifier selected by the holder, the “authentication application” shall allow the authentication
protocol to be initiated with the selected Authentication key and the corresponding Authentication Protocol
sensitive data.

If several different authentication keys are simultaneously present on the card, the holder has to select one
according to the Verifier he intends to be authenticated by. The IT environment, mainly the Authentication
application helps the holder to securely select the correct authentication key. It is up to the IT environment to
indicate the link between the selected authentication key and the Certificate of the corresponding key. For this
purpose, and to allow mobility, it may be useful to store the Certificate or Certificate Info on the card by this is
not mandatory.

6.8.5.2 Communication

Communication between the TOE and the verifier is the authentication protocol.

This PP does not cover the data exchanges that may take place after this authentication.

This authentication may take place in an untrusted environment. Therefore the TOE has to counter the threats
identified in ISO/IEC 10181-2 as relay and replay attacks, via the authentication protocol.

The communication protocol can also counter threats due to a faulty CA, delivering certificates without
verifying the correct origin of the public key by a “Proof of Possession”. In this case an authentication protocol
using a signed certificate delivered by the TOE can still ensure a correct authentication.

6.8.6 Key Generator

6.8.6.1 Functionalities

The Key Generator generates a public key pair. The private key is securely transmitted to the TOE.

The environment shall make sure that the public key is securely transmitted to the CA for the generation of the
certificate.

6.8.6.2 Communication

Communication between the Key generator and the TOE shall be secured.

19
BS EN 419251-3:2013
EN 419251-3:2013 (E)

During the personalisation phase, which takes place in a trusted environment, this communication can be split
in two phases:

 Transfer from the Key Generator to the Personalisation application, then

 Transfer from the Personalisation application to the TOE.

The transfer from the Personalisation application to the TOE shall be protected by the TOE.

6.8.7 Certification Authority

6.8.7.1 Functionalities

The certification authority generates a Certificate, based on the public key it receives. If the Key pair is
generated on TOE, then the public key shall be sent from the TOE.

The ST writer shall specify the Identification data and how these are securely transferred to the CA and
associated to the correct public key.

If the key is generated off TOE, then the Environment shall ensure that the public key is securely transferred
to the CA.

The public key shall be transferred with the correct identity data to make sure that no false certificate can be
produced. The CA shall prevent the generation of certificates with wrong identity. A possible mean is the
“Proof Of Possession” mechanism.

The certificate may then be sent to the card. It can prevent some attacks on authentication protocols.

6.8.7.2 Communication

Communication between the TOE and the CA is used to transfer the public key.

This authentication can take place in a trusted or untrusted environment.

Communication may transit through a CGA.

If group Trusted CA is included in the configuration, then the whole environment between the TOE and CA,
through the CGA has to be Trusted.

The Trusted Channel shall be established between the TOE and the CA.

6.8.8 Examples of applications

6.8.8.1 General

This TOE environment generally described in this chapter covers very different environments.

6.8.8.2 Simple Access Control

The simplest could be an access control application inside a company, where the PKI would managed inside
the company and the IT environment would be secure, i.e. protected against external attacks.

In this simple Application the communication between TOE and Verifier is protected by the IT environment.

The PKI is managed internally. It generates and manages certificates and it regularly updates the list of valid
certificates used by the Verifier.

20
BS EN 419251-3:2013
EN 419251-3:2013 (E)

The Issuer and the Administration belong to the company and use the Secure internal IT.

In such a simple application, the TOE only needs his Authentication Private Key. The authentication protocol
with the verifier may be very simple. The verifier generates a random message, sends to the TOE that signs it
and returns it to the Verifier.

All communications are protected, on the secure IT network.

6.8.8.3 E-government

E-government application allowing a holder on a PC at home to access personal data ex: remaining points on
the holder driving license.

The e-government may get the certificate from the PKI. But it may also rely on the authentication protocol to
securely provide the public key, for example within a signed certificate.

Communication between Authentication application and the TOE may be regarded as secure for:

 Holder authentication;

 Acceptance of authentication of the TOE with the Authentication key pair.

6.8.8.4 Multiple application TOE

E-administration for tax payment requiring signature + e-commerce only requiring authentication

The e-administration and the e-commerce center may get the certificate from the PKI. But they may also rely
on the authentication protocol to securely provide the public key, for example within a signed certificate.

Communication between Authentication application and the TOE may be regarded as secure for:

 Holder authentication.

 Selection of online server

 Selection of a specific Authentication key pair

 Acceptance of authentication of the TOE.

21
BS EN 419251-3:2013
EN 419251-3:2013 (E)

6.9 Life Cycle

6.9.1 Overview

Figure 5 — TOE Life Cycle

This figure represents two views of the life-cycle:

a) An “end-user” view made of 4 phases, focusing on the following main logical phases:

1) Development phase: IC design, and embedded software development;

2) Manufacturing phase: from IC manufacturing to card or token manufacturing, including patch loading,
application creation and pre-personalisation;

3) Personalisation phase: loading of all data related to the TOE holder;

4) Operational use phase: TOE used by its legitimate holder to authenticate himself to a Verifier.

22
BS EN 419251-3:2013
EN 419251-3:2013 (E)

b) A business view made of 7 steps, focusing more on the different trades and actors involved in smartcard
business. For example, the company in charge of IC manufacturing may be different from the one in
charge of IC packaging, as well as from the one in charge of packaging, initialisation, pre-personalisation,
not considering all other actors involved in this phase: antenna supplier, booklet supplier. The definition of
the content of each step and the associated supply chain vary from one provider to another and the
picture is just indicative.

Referring to the life-cycle, the evaluated product is the product that comes out of the IC manufacturing, test
and possible pre-personalisation operations (step 3).

At this step, the product shall already be self-protected before delivery to step 4 and all steps after. This
means that if a patch is to be loaded on the product to fix a security flaw, this operation has to be performed
during the IC manufacturing step, i.e. in an environment that is under control of the evaluation and assessed
through assurance class of Common Criteria related to the development environment (ALC).

The following options are also important to keep in mind:

 Creation of the application:

 Applet instantiation for a JavaCard;

 Loading of the pre-personalisation data in the chip.

These operations may or may not be performed within the IC manufacturer secure premises covered by the
evaluation scope, depending on the business organisation for the TOE production. They may even be
performed during the personalisation phase (step 6) under the control of the issuing state.

However, if they are not performed within the IC manufacturer secure premises, the procedures to perform
these operations have to be well defined, and successfully evaluated through assurance tasks of Common
Criteria related to guidance analysis (class AGD).

More generally, all steps that come after step 3 are to be covered by guidance (secure delivery, secure
handling, etc.).

The ST writer can choose to include step 4 and also step 5 inside the perimeter of the evaluation. In this case
the premises where these operations take place will be covered by ALC, not AGD and sensitive operations
such as the loading of patches invoving Security Functions can be done in the included steps.

6.9.2 Pre-Personalisation phase

Pre-Personalisation is the final phase under the control of the Smart card manufacturer.

 Application initialisation

During Pre-personalisation, the Smartcard manufacturer initialises the application.

 Import of Issuer RAD

The manufacturer imports the Issuer RAD that will be used in the next phase to authenticate the Issuer.

6.9.3 Personalisation phase

6.9.3.1 General

The Personalisation phase is under the control of the Issuer.

23
BS EN 419251-3:2013
EN 419251-3:2013 (E)

6.9.3.2 Personalisation application

 Issuer authentication
The Issuer authenticates himself to the TOE using a RAD.

 Import of Holder RAD


This function is mandatory in Personalisation.
This function initialises the RAD.
When biometrics is used, this operation requires the holder.

 Import of Authentication Protocol sensitive data


This function is optional as these data may be empty.
It is only necessary if APrK / APuK key pair is generated on TOE during Personalisation. In this case the TOE
shall import the APSD, if not null, after the CA has generated the certificate.

 Import of Authentication private key.


This function is not necessarily used in Personalisation.
APrK can also be generated by the TOE during Personalisation.
The TOE can also be issued without APrK.

 Authentication key pair generation


This function is not necessarily used in Personalisation.
APrK can also be imported during Personalisation.
The TOE can also be issued without APrK.

 Export of Authentication Public key


This function is not necessarily used in Personalisation.
It is only necessary if APrK / APuK key pair is generated on TOE during Personalisation. In this case the TOE
shall export APuK to the CA, which will generate the certificate.

 Import of Administrator RAD


This function is mandatory in Personalisation as the Admin group is part of the configuration.

6.9.4 Usage phase

6.9.4.1 Authentication application

The Authentication application interfaces the TOE to the holder.

During the usage phase, the Holder can perform the following operation on the authentication device:

 Holder Authentication to the TOE


The Holder authenticates himself to the TOE using a RAD.
When the TOE is used both for Authentication and Signature and when the RAD is a PIN, the TOE shall
provide at least one PIN for Signature and one PIN for Authentication.

 Generation of an authentication key pair


This function is not necessarily used in Usage phase.
APrK can also be imported in Usage phase.
The TOE can also be issued with APrK.

24
BS EN 419251-3:2013
EN 419251-3:2013 (E)

 Import of the private key


This function is not necessarily used in Usage phase.
APrK can also be imported in Personalisation phase.
The TOE can also be issued with APrK.

 Export of the public key


This function is not necessarily used in Usage phase.
It is only necessary if APrK / APuK key pair is generated on TOE during Usage phase. In this case the TOE
shall export APuK to the CA, which will generate the certificate.

 Import for update of holder RAD


This function allows the holder to update his RAD. This operation is required when the Holder receives its
TOE, except when RAD is biometrics. It gives the holder, exclusive control of the authentication function of the
TOE.

 Allow Authentication by Verifier


This function enables the Holder to accept or deny the authentication by the Verifier.

6.9.4.2 Administration application

The Administration application interfaces the TOE to the Administrator.

During the usage phase, the Administrator can perform the following operation on the authentication device:

 Administrator Authentication to the TOE,


The Administrator authenticates himself to the TOE using a RAD.

 Import for update of Administrator RAD.


This function allows the Administrator to update his RAD.

 Retrieve authentication log


This function allows the Administrator to retrieve the authentication log.

 Reset holder RAD Retry counter


This function allows the Administrator to reset the Holder RAD counter. This enables the holder to
authenticate himself to the TOE, after the TOE has been blocked by an erroneous or malicious action. The
Holder shall still know his RAD.

6.9.4.3 Verifier

Authentication by Verifier
This function allows the Verifier to authenticate the TOE and therefore its holder.
Other functions following the Authentication, such as exchange of data with the Verifier, are out of the scope
of this PP.

25
BS EN 419251-3:2013
EN 419251-3:2013 (E)

7 Security problem definition

7.1 Assets

7.1.1 General

The description of each asset provides the type of protection required for each asset ("Protection" part).

RAD, VAD, Authentication Protocol sensitive data are not Assets, they are TSF data.

7.1.2 Core group

7.1.2.1 Assets protected by the TOE

D.AUTHENTICATION
This asset represents the authentication function itself and all the benefits that can result from the
authentication. These benefits can be:
 Communication data between the authentication device and an access-restricted on-line service
 Data or goods located in an access-restricted area
 Rights provided in country by an ID card

7.1.2.2 Sensitive assets of the TOE

D. AUTHENTICATION_PRIVATE_KEY
This asset corresponds to the private key generated outside of the TOE and imported in the TOE or generated
inside the TOE. The private key is associated with a public key and a public-key certificate. In addition, the
private key shall remain consistent with its corresponding public key.
Protection: integrity and confidentiality.
Application notes:
This asset is used by the authentication service running on the TOE.
The TOE can contain several Authentication Keys, dedicated to different distant entities. In case of multiple
Authentication Keys, the holder can be authenticated by the same RAD or by different RAD.

D.IDENTIFICATION_DATA
These data correspond to Holder identification data. These are the data to be authenticated.
These data can be present on the TOE. They are included in the certificate.
Protection: integrity and confidentiality.

7.1.3 KeyGen group

D. AUTHENTICATION_PUBLIC_KEY
This asset is the public key generated inside the TOE as part of the key pair generation. The public key shall
remain consistent with its corresponding private key until it is securely delivered to the CGA.
Protection: integrity.
Application note:
This asset may be part of the Authentication Protocol sensitive data.

26
BS EN 419251-3:2013
EN 419251-3:2013 (E)

7.1.4 Admin group

D.LOG
This asset corresponds to data generated by the TOE to enable the audit of authentication failures.
Protection: integrity.
The above cryptographic keys and certificate are to be used for the authentication of the device by a verifier.
When a device implements other cryptographic operations (signature, ciphering…), then different keys should
be used for each operation.

7.2 Users

7.2.1 Core group

a) Issuer

During the personalisation phase of the device, the Issuer can perform the following operations:

1) Authenticate himself with his own VAD,

2) Import the holder RAD into the TOE,

3) Import the Authentication Protocol sensitive data into the TOE.

4) Import the Authentication private key into the TOE.

5) Request an Authentication key pair generation inside the TOE

6) Export the Authentication public key from the TOE.

7) Import the Administrator RAD into the TOE.

The Issuer is the only person who can perform the above administration commands during the personalisation
phase. During the usage phase, the issuer cannot perform import operations anymore.

b) Holder

Holder of the authentication device (legitimate holder). The Holder accesses by means of his authentication
device an access-restricted on-line service that requires an authentication, or sends data whose origin shall
be authenticated by an agent. The Holder knows the authentication data allowing him to access the
authentication service in the device and unlock the associated private key (these actions can only be
performed during the usage phase).

During the usage phase, the Holder can perform the following operation on the authentication device:

1) Authenticate himself with his own VAD.

2) Import the Authentication Protocol sensitive data into the TOE.

3) Import his own RAD.

4) Allow the TOE to authenticate itself to the external verifier.

The Holder cannot perform these functions during the personalisation phase.

The Holder can be a single person or a group of people. This shall be specified in the ST.

27
BS EN 419251-3:2013
EN 419251-3:2013 (E)

c) Verifier

The user “Verifier” represents either a distant device or a distant agent.

During the usage phase, the Verifier can perform the following operations:

1) Authenticate the TOE, using the authentication protocol based on APrK.

2) Perform other operations such as opening a trusted channel and transmitting and receiving data.
These other operations are not in the scope of this PP.

7.2.2 KeyImp group

Issuer
During the personalisation phase of the device, the Issuer can also perform the following operations:

 Import the Authentication private key into the TOE.

7.2.3 KeyGen group

Issuer
During the personalisation phase of the device, the Issuer can also perform the following operations:

 Request an Authentication key pair generation inside the TOE

 Export the Authentication public key from the TOE.

7.2.4 Admin group

Administrator
During the usage phase, the Administrator can perform the following operations:

 Authenticate himself with his own VAD,

 Import the Authentication Protocol sensitive data into the TOE,

 Export of log data,

 Reset Holder authentication failures counter.

During the personalisation phase the Administrator cannot perform any operation.

The Administrator is responsible for the analysis of device audit records concerning authentication failures.

7.3 Threats

7.3.1 General

Threats present in this section only target the TOE security and do not concern the services provided by the
TOE since such services are considered in the security problem definition as organisational security policies
environment elements. The considered threat agents are the following:

28
BS EN 419251-3:2013
EN 419251-3:2013 (E)

 Attackers trying to illegitimately authenticate to the on-line service and therefore have access to data or
services they are not entitled.

Issuers are not considered as attackers (assumption A.ISSUER).

7.3.2 Core group

T.MASQUERADE_USER
An attacker illegitimately retrieves, modifies or deletes data that enable the Holder or the Issuer to
authenticate himself to the TOE (i.e. RAD).
For example, an attacker may import RAD with known corresponding VAD in order to be able to use the
authentication device to authenticate to an on-line service or to a distant agent.
These data can be modified when they are stored in the TOE or during their transfer to the TOE.
Threatened assets: D.AUTHENTICATION.

T.PRIV_KEY_DISCLOSURE
An attacker discloses the value of the private key in order, for instance, to illegitimately authenticate
subsequently as the device holder to an on-line service or a distant agent.
The private key can be disclosed when it is stored in the TOE or during its transfer from the Key Generator to
the TOE.
Threatened assets: D.AUTHENTICATION_PRIVATE_KEY.

T.PRIVATE_KEY_MODIF
An attacker modifies the value of the private key when it is stored in the TOE or during its transfer to and from
the TOE.
Threatened assets: D.AUTHENTICATION_PRIVATE_KEY, D.AUTHENTICATION_PUBLIC_KEY.

T.COMM_EAVESDROP
An attacker passively eavesdrops on a legitimate communication between the authentication device and a
terminal to obtain information that could be used to derive the value of sensitive information stored in the
device. Such eavesdropping is conducted without the knowledge of the device holder.
Threatened assets: D.AUTHENTICATION_PRIVATE_KEY.

T.USER_TRACKING
An attacker illegitimately manages to track or identify the device holder, without the knowledge of the latter.
This threat has been identified for contactless cards.
Threatened assets: D.IDENTIFICATION_DATA.

T.MASQUERADE_TOE
An attacker illegitimately retrieves, modifies or deletes data that enable the TOE to authenticate itself to the
verifier (Authentication Protocol sensitive data).
ISO/IEC 10181-2 is the result of a study on Authentication in Open Systems. It identifies and describes the
following threats:
 Replay attacks on the same verifier, see ISO/IEC 10181-2:1996, 5.8.1.1
 Replay attacks on a different verifier, see ISO/IEC 10181-2:1996, 5.8.1.2

29
BS EN 419251-3:2013
EN 419251-3:2013 (E)

 Relay attacks initiated by an intruder, see ISO/IEC 10181-2:1996, 5.8.2.1


 Relay attacks in which an intruder responds, see ISO/IEC 10181-2:1996, 5.8.2.2
Threatened assets: D.AUTHENTICATION.

7.3.3 KeyGen group

T.PUBLIC_KEY_MODIF
An attacker modifies the value of the public key generated on card before it is used to generate the certificate,
ie, before it transferred to the CA or during this transfer.
Threatened assets: D.PUBLIC_KEY

7.3.4 Admin group

T.MASQUERADE_ADMIN
An attacker illegitimately retrieves, modifies or deletes data stored in the TOE that enable the Administrator to
authenticate himself to the TOE (i.e., the Administrator RAD).
Threatened assets: D.LOG.

7.4 Organisational security policies

7.4.1 Core group

7.4.1.1 Provided services

OSP.AUTHENTICATION_PROTOCOL
The TOE shall implement a public-key cryptography protocol by making use of the private key.
The authentication protocol may optionally use other data, the “Authentication Protocol sensitive data” stored
on TOE, such as the public key and the certificate. This protocol shall enable the authentication device to be
authenticated by the verifier.

OSP.PKI
The TOE shall be used in an environment providing a PKI that generates a certificate for the Authentication
Private Key. The PKI also manages the validity of Certificates, their end of validity, their possible revocation, in
such a way that the Verifier can rely on the Certificate provided by the PKI.

7.4.1.2 Other services

OSP.PERSO_CORE
During the personalisation phase, the issuer shall be allowed to:
 Generate on card or Import the Authentication key pair,
 Import the Authentication Protocol sensitive data,
 Import the Holder RAD.

OSP.CRYPTO
The cryptographic mechanisms of the TOE shall conform to the rules and recommendations defined by the
relevant Certification Body.

30
BS EN 419251-3:2013
EN 419251-3:2013 (E)

7.4.2 KeyGen group

OSP.CONSISTENCY
The TOE shall ensure the following consistency rule: the public key and the private key generated on TOE
form a key pair for the implemented asymmetric cryptographic algorithm. This rule shall be enforced until the
public key is exported to the CA for the certificate generation.

7.4.3 Admin group

OSP.PERSO_ADMIN
The issuer shall be allowed to import the Admin RAD during the personalisation phase.

OSP.ADMIN
The administrator shall be allowed to:
 Reset the Holder RAD and its ratification counter,
 Retrieve a log of unsuccessful holder authentication.

7.5 Assumptions

7.5.1 Core group

A.ISSUER
It is assumed that the Issuer is non hostile and competent. He possesses the resources required for his tasks
and is trained to conduct activities he is responsible for.
It is assumed that the Issuer RAD has been securely imported previously, in the pre-personalisation phase.

A.HOLDER
It is assumed that the Holder of the device (i.e., the legitimate device holder) does not disclose his
authentication data allowing him to authenticate to the device.

A.CERTIF_VERIF
It is assumed that the Verifier verifies the validity of the Holder certificate before considering the Holder as
authenticated and granting to the service. The certificate verification includes in particular the verification that
the current date belongs to the validity period of the certificate and the verification that the certificate has not
been revoked.

A.CERTIF_AUTH
It is assumed that the Certification Authority issuing the certificate for the authentication service implements
practices that conform to an approved certification policy.

A.COPY
It is assumed that the confidential assets of the TOE cannot be compromised by copies of such assets that
may exist outside the TOE.

31
BS EN 419251-3:2013
EN 419251-3:2013 (E)

A.CRYPTO
The cryptographic keys generated outside the TOE and imported in the TOE are supposed to be generated in
conformance to the rules and recommendations defined by the relevant Certification Body.

7.5.2 KeyGen group

A.KEY_PAIR_GENERATION
When the Authentication key pair is generated outside the TOE, it is assumed that this generation is
performed by an authorised person in a way that preserves the confidentiality of the private key.

7.5.3 Admin group

A.ADMIN
It is assumed that the administrator of the device is non hostile and competent. He possesses the resources
required for his tasks, is trained to conduct activities he is responsible for, and follows administration guides
and procedures.
It is also assumed that the administrator does not disclose his authentication data allowing to authenticate
himself to the device.

8 Security objectives

8.1 General − Transfer of sensitive data

Untrusted groups deal with communication in an untrusted environment between the TOE and IT devices
outside the TOE.

Each untrusted group of 8.2 Security objectives for the TOE has a corresponding trusted group in 8.3 Security
objectives for the operational environment. A configuration shall include either the trusted or the untrusted
corresponding group, but never both groups.

In a trusted group the threats related to communication are covered by an Objective on the environment.

In an untrusted group the threats related to communication are covered by an Objective on the TOE.

The following sensitive data have to be protected against disclosure and/or modification when they are
imported and/or exported to and from the TOE. They can be protected either by the TOE or by the
environment.

32
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Table 3 — Protection of sensitive data


Data IT device transfer Protection Protected by
type
Authentication Private key KeyGenIT Import I,C TOE
Authentication Public key CA Export I TOE / environment
Authentication Protocol PersoAppli Import I TOE / environment
Sensitive Data AuthAppli Import I TOE / environment
AdminAppli Import I TOE / environment
Issuer VAD PersoAppli Import I,C TOE / environment
Holder RAD HI Import I,C TOE / environment
AuthAppli Import I,C TOE / environment
PersoAppli Import I,C TOE / environment
Holder VAD HI Import I,C TOE / environment
AuthAppli Import I,C TOE / environment
Admin RAD HI Import I,C TOE / environment
AdminAppli Import I,C TOE / environment
PersoAppli Import I,C TOE / environment
Admin VAD HI Import I,C TOE / environment
AdminAppli Import I,C TOE / environment

Application note:
Export of authentication public key is only used in KeyGen group
Import of Admin RAD and Admin VAD are used in Admin group
Secure Import of Authentication Protocol data is not a security feature. If these data are wrong, authentication
will not be possible, but there is no security breach.
Import of authentication private key is only used KeyImp group

8.2 Security objectives for the TOE

8.2.1 Core group

8.2.1.1 Provided service

OT.DEVICE_AUTHENTICATION
The authentication of the device (on behalf of the Holder) by the access-restricted on-line service or by the
distant agent authenticating data sent by the Holder shall be ensured by the TOE. This authentication shall
implement a public-key cryptographic protocol by making use of the private key stored in the TOE (and
optionally of the corresponding certificate).
The TOE shall enable the import of the Authentication Protocol sensitive data, if it is not yet inside the TOE.

8.2.1.2 Authentication to the TOE

OT.AUTH_USER
The TOE shall provide mechanisms to authenticate the Holder and the Issuer.
Holder authentication shall use a RAD / VAD mechanism. The number of failed Holder authentication attempts
shall be limited.
Before the user authenticates himself to the TOE, the TOE shall not deliver data that could enable the holder
identification.

33
BS EN 419251-3:2013
EN 419251-3:2013 (E)

8.2.1.3 TOE management

OT.PROTECTIONS
The TOE shall be able to protect any sensitive data, Assets and TSF data, against unauthorised disclosure
and/or modification. This protection applies when the data are on the TOE.

OT.HOLDER_RAD
The TOE shall be able to import the Holder RAD and to replace it. Such import shall be allowed only in the
following cases:
 in the personalisation phase, when the Issuer is authenticated,
 in the usage phase, when the Holder is authenticated.

8.2.2 KeyImp group

OT.AUTHENTICATION_PRIVATE_KEY_IMPORT
The TOE shall be able to import the authentication private key.
The import of the private key is only allowed:
 in the personalisation phase, when the Issuer is authenticated,
 in the usage phase, when the Holder is authenticated.
The import of the private key shall be protected against disclosure and modification.
When a new key is imported, the previous key shall be deleted.

8.2.3 KeyGen group

OT.AUTHENTICATION_KEYS_GENERATION
The TOE shall be able:
 to generate a key pair,
 to export the public key to the CA.
The key pair shall be consistent.
The generation operation of the private key is only allowed:
 in the personalisation phase, when the Issuer is authenticated,
 in the usage phase, when the Holder is authenticated.

8.2.4 Admin group

OT.AUTH_ADMIN
The TOE shall provide mechanisms to authenticate the Administrator by means of the VAD and RAD
associated with the Administrator. The TOE therefore ensures that only authorised personnel can perform
administration operations.

OT.ADMIN_RAD
The TOE shall be able to import the Administrator RAD and to replace it. Such import shall be allowed only
when:
 in the personalisation phase, when the Issuer is authenticated,
 in the usage phase, when the Administrator is authenticated.

34
BS EN 419251-3:2013
EN 419251-3:2013 (E)

OT.LOG
The TOE shall maintain a log with the number of authentication failures. This log will be exported from the
TOE only when the Administrator is authenticated.

OT.RESET_HOLDER_RAD_COUNTER
The TOE shall be able to reset the Holder retry counter. Such operation shall be allowed only when the
Administrator is authenticated.

8.2.5 Untrusted PersoAppli

OT.UNTRUSTED_PERSONALIZATION_APPLI
The TOE shall protect the following data transfers:
 Authentication with Issuer_VAD – protected in integrity and confidentiality
 Import of Holder_RAD – protected in integrity and confidentiality
 Import of Admin_RAD – protected in integrity and confidentiality
 Import of Authentication Protocol data – protected in integrity

8.2.6 Untrusted AuthAppli

The TOE shall protect the following data transfers:


 Authentication with Holder_VAD – protected in integrity and confidentiality
 Import of Holder_RAD – protected in integrity and confidentiality
 Import of Authentication Protocol data – protected in integrity

8.2.7 Untrusted Verifier

OT.UNTRUSTED_VERIFIER
The TOE shall protect the following data transfers:
 Import of random message to be signed – protected in integrity
 Export of Signed message – protected in integrity

8.2.8 Untrusted CA

OT.UNTRUSTED_CA
The TOE shall protect the following data transfers:
 Export of the public key to the CA for the generation of the certificate – protected in integrity

Application note: This Objective is included only if group KeyGen is in the configuration

8.2.9 Untrusted AdminAppli

OT.UNTRUSTED_ADMINISTRATION_APPLI
The TOE shall protect the following data transfers:
 Authentication with Admin_VAD – protected in integrity and confidentiality
 Export of LOG – protected in integrity and confidentiality
 Import of Authentication Protocol sensitive data – protected in integrity

35
BS EN 419251-3:2013
EN 419251-3:2013 (E)

8.3 Security objectives for the operational environment

8.3.1 Core group

OE.ISSUER
The Issuer shall possess the resources required for his tasks and is trained to conduct activities he is
responsible for.

OE.HOLDER
The Holder of the device (i.e., the legitimate device holder) shall not disclose his authentication data allowing
to authenticate himself to the device.

OE.CERTIF_VERIF
The access-restricted “verifier” shall verify the validity of the Holder certificate before considering the Holder
as authenticated and granting to the service. The certificate verification shall include in particular:
 the verification that the current date belongs to the validity period of the certificate,
 the verification that the certificate has not been revoked.

OE.CERTIF_AUTH
The Certification Authority issuing the certificate for the authentication service shall implement practices that
conform to an approved certification policy, in particular concerning:
 the verification of the certificate subject identity,
 the verification of possession of the corresponding private key by the subject,
 the certificate generation,
 the certificate issuance.

OE.COPY
The confidential sensitive data, Assets and TSF data, of the TOE shall not be compromised by copies of such
data that may exist outside the TOE.

OE.CRYPTO
The cryptographic mechanisms used outside the TOE, to protect sentitive assets of the TOE shall conform to
the rules and recommendations defined by the relevant Certification Body. These mechanisms include the
generation of the Authentication Key Pair and the generation of the Authentication Certificate.

8.3.2 KeyImp group

OE.KEY_PAIR_GENERATION
If the key pair is not generated by the TOE, the device generating the key pair used by the authentication
service shall ensure the integrity and the confidentiality of APrK and the integrity of the APuK until it is
transferred to the CA, protected in integrity.

36
BS EN 419251-3:2013
EN 419251-3:2013 (E)

8.3.3 Admin group

OE.ADMIN
Administrators shall be trained to conduct activities they are responsible for and shall follow the administration
guides and procedures. In particular, they shall not disclose their authentication data.

8.3.4 Trusted PersoAppli

OE.TRUSTED_PERSONALIZATION_APPLI
The TOE relies on its environment to protect the following data transfers:
 Authentication with Issuer_VAD – protected in integrity and confidentiality
 Import of Holder_RAD – protected in integrity and confidentiality
 Import of Admin_RAD – protected in integrity and confidentiality
 Import of APSD – protected in integrity

8.3.5 Trusted AuthAppli

OE.TRUSTED_AUTHENTICATION_APPLI
The TOE relies on its environment to protect the following data transfers:
 Authentication with Holder_VAD – protected in integrity and confidentiality
 Import of Holder_RAD – protected in integrity and confidentiality
 Import of Authentication Protocol sensitive data – protected in integrity

8.3.6 Trusted Verifier

OE.TRUSTED_VERIFIER
The TOE relies on its environment to protect the following data transfers:
 Import of random message to be signed – protected in integrity
 Export of Signed message – protected in integrity
 The environment shall also protect the authentication mechanism against Replay and Relay attacks as
defined in ISO/IEC 10181-2:1996, 5.8.1 and 5.8.2.

8.3.7 Trusted CA

OE.TRUSTED_CA
The TOE relies on its environment to protect the following data transfers:
 Export of the public key to the CA for the generation of the certificate – protected in integrity

Application note: This Objective is included only if group KeyGen is in the configuration

8.3.8 Trusted AdminAppli

OE.TRUSTED_ADMINISTRATION_APPLI
The TOE shall protect the following data transfers:
 Authentication with Admin_VAD – protected in integrity and confidentiality
 Export of LOG – protected in integrity and confidentiality
 Import of Authentication Protocol data – protected in integrity

37
BS EN 419251-3:2013
EN 419251-3:2013 (E)

8.4 Rationale for Security objectives

Color code:
This rationaIe uses colors to indidicate the groups to which the threats, policies, assumptions, objectives and
requirements come from.
Core group: Yellow; KeyImp group: Green; KeyGen group: Blue; Admin group: Violet;
All Trusted/Untrusted groups: Orange

Table 4 — Security objectives vs problem definition rationale

O.TRUSTED/IUTRUSTED_PERSONALIZATION_APPLI
O.TRUSTED/IUTRUSTED_AUTHENTICATION_APPLI
Objectives

O.TRUSTED/IUTRUSTED_ADMINISTRATION_APPLI
OT.AUTHENTUCATION_PRIVATE_KEY_IMPORT
vs

OT.AUTHENTICATION_KEYS_GENERATION

OT..RESET_HODER_RAD_COUNTER
Threats

O.TRUSTED/IUTRUSTED_VERIFIER
OSP
OT.DEVICE_AUTHENTICATION

Assumptions

OE.KEY_PAIR_GENERATION

O.TRUSTED/IUTRUSTED_CA
OT.PROTECTIONS

OE.CERTIF_VERIF
OE.CERTIF_AUTH
OT.HOLDER_RAD

OT.AUTH_ADMIN
OT.AUTH_USER

OT.ADMIN_RAD

OE.CRYPTO
OE.HOLDER
OE.ISSUER

OE.ADMIN
OE.COPY
OT.LOG

T.MASQUERADE_USER X X X X X X X
T.PRIV_KEY_DISCLOSURE X X X X X X
T.PRIVATE_KEY_MODIF X X X X X X
T.COMM_EAVESDROP X X X X X
T.USER_TRACKING X X X
T.MASQUERADE_TOE X X X X X X
T.PUBLIC_KEY_MODIF X X X
T.MASQUERADE_ADMIN X X X X X
OSP.AUTHENTICATION_PROTOCOL X X
OSP.PKI X X X
OSP.PERSO_CORE X X X X X
OSP.CRYPTO X X X
OSP.CONSISTENCY X X X
OSP.PERSO_ADMIN X X X
OSP.ADMIN X X
A.ISSUER X
A.HOLDER X
A.CERTIF_VERIF X
A.CERTIF_AUTH X X
A.COPY X
A.CRYPTO X
A.KEY_PAIR_GENERATION X X
A.ADMIN X

T.MASQUERADE_USER addresses the threat of retrieving or modifying the holder RAD in order to
illegimately access to the TOE. This threat is countered by:
OT.AUTH_USER that ensures that the user, (Issuer or Holder) will be authenticated to the TOE before
sensitive operations can be performed on the TOE,

38
BS EN 419251-3:2013
EN 419251-3:2013 (E)

OT.PROTECTIONS that ensures the integrity and confidentiality of Issuer and holder RAD inside the TOE,
OT.HOLDER_RAD that ensures the import and update of the holder RAD,
OE.HOLDER that ensures the Holder will maintain the confidentiality of his RAD outside the TOE,
OE.COPY that ensures the confidentiality of Issuer and holder RAD outside he TOE,
O.TRUSTED/UNTRUSTED_PERSONALIZATION_APPLI that ensures the integrity and confidentiality of the
Issuer and holder RAD when they are transferred from the personalisation application to the TOE, and
O.TRUSTED/UNTRUSTED_AUTHENTICATION_APPLI that ensures the integrity and confidentiality of the
holder RAD when it is transferred from the authentication application to the TOE.

T.PRIV_KEY_DISCLOSURE addresses the threat of retrieving the Authentication Private Key in order to
illegimately authenticate to the Verifier. This threat is countered by:
OT.AUTH_USER that ensures that the user, (Issuer or Holder) will be authenticated to the TOE before he can
import APrK into the TOE,
OT.PROTECTIONS that ensures the confidentiality of Authentication Private Key inside the TOE,
OT.AUTHENTICATION_PRIVATE_KEY_IMPORT, that ensures the integrity and the confidentiality of the
Authentication Private Key, when it is transferred to the TOE. It also ensures that only the authorised user can
import the Authentication Private Key.
OT.AUTHENTICATION_KEYS_GENERATION, that ensures that only the authorised user can generate the
Authentication Private Key.
OE.ISSUER, that ensures the Issuer will not cause the Authentication Private Key disclosure, and
OE.COPY that ensures the confidentiality of the Authentication Private Key outside he TOE.

T.PRIVATE_KEY_MODIF addresses the threat of modifying the Authentication Private Key in order to
illegimately use it and deceive the Verifier. This threat is countered by:
OT.AUTH_USER that ensures that the user, (Issuer or Holder) will be authenticated to the TOE before he can
import APrK into the TOE,
OT.PROTECTIONS that ensures the integrity of the Authentication Private Key inside the TOE,
OT.AUTHENTICATION_PRIVATE_KEY_IMPORT, that ensures the integrity and the confidentiality of the
Authentication Private Key, when it is transferred to the TOE. It also ensures that only the authorised user can
import the Authentication Private Key,
OT.AUTHENTICATION_KEYS_GENERATION that ensures that only the authorised user can generate the
Authentication Private Key,
O.TRUSTED/UNTRUSTED_PERSONALIZATION_APPLI that ensures the integrity and confidentiality of the
Authentication Private Key when it is transferred from the personalisation application to the TOE, and
O.TRUSTED/UNTRUSTED_ADMINISTRATION_APPLI that ensures the integrity and confidentiality of the
Authentication Private Key when it is transferred from the administration application to the TOE.

T.COMM_EAVESDROP addresses the threat of retrieving the sensitive data by eavesdropping the
communication of the TOE.This threat is countered by:
OT.AUTHENTICATION_PRIVATE_KEY_IMPORT that ensures the integrity and the confidentiality of the
Authentication Private Key, when it is transferred to the TOE. It also ensures that only the authorised user can
import the Authentication Private Key.
O.TRUSTED/UNTRUSTED_PERSONALIZATION_APPLI that ensures the integrity and/or confidentiality of
sensitive data – Issuer RAD, Holder RAD, Authentication Protocol sensitive data, Authentication Public key,
Admin RAD - when they are transferred between the TOE and the personalisation application,

39
BS EN 419251-3:2013
EN 419251-3:2013 (E)

O.TRUSTED/UNTRUSTED_AUTHENTICATION_APPLI that ensures the integrity and/or confidentiality of


sensitive data – Holder RAD, Authentication Protocol sensitive data, Authentication Public key - when they are
transferred between the TOE and the authentication application,
O.TRUSTED/UNTRUSTED_VERIFIER that ensures the integrity and/or confidentiality of sensitive data –
Authentication Protocol sensitive data - when they are transferred between the TOE and the Verifier, and
O.TRUSTED/UNTRUSTED_ADMINISTRATION_APPLI that ensures the integrity and/or confidentiality of
sensitive data – Audit data, Admin RAD - when they are transferred between the TOE and the personalisation
application.

T.USER_TRACKING addresses the threat of identifying and tacking the Holder. This threat is countered by:
OT.AUTH_USER that ensures that the user, (Issuer or Holder) will be authenticated to the TOE before
sensitive operations can be performed on the TOE,
O.TRUSTED/UNTRUSTED_AUTHENTICATION_APPLI that ensures the integrity and/or confidentiality of
sensitive data – Holder RAD, Authentication Protocol sensitive data, Authentication Public key - when they are
transferred between the TOE and the authentication application, and
O.TRUSTED/UNTRUSTED_VERIFIER that ensures the integrity and/or confidentiality of sensitive data –
Authentication Protocol sensitive data - when they are transferred between the TOE and the Verifier.

T.MASQUERADE_TOE addresses the threat of replay and relay attacks on the Authentication protocol. This
threat is countered by:
OT.DEVICE_AUTHENTICATION that ensures that authentication of the TOE using a public-key cryptographic
protocol with the private key stored in the TOE,
OT.PROTECTIONS that ensures the integrity and/or confidentiality of sensitive data – Holder RAD,
Authentication Protocol sensitive data - inside the TOE,
OT.AUTHENTICATION_PRIVATE_KEY_IMPORT that imports the Authentication Private Key,
OT.AUTHENTICATION_KEYS_GENERATION that generates the authentication key pair,
OE.KEY_PAIR_GENERATION that generates the authentication key pair, and
O.TRUSTED/UNTRUSTED_VERIFIER that ensures the integrity and/or confidentiality of sensitive data –
Authentication Protocol sensitive data - when they are transferred between the TOE and the Verifier.

T.PUBLIC_KEY_MODIF addresses the threat of modifying the Authentication Public Key before it is used to
generate the certificate. This threat is countered by:
OT.AUTH_USER that ensures that the user, (Issuer or Holder) will be authenticated to the TOE before he can
export the Authentication Public key outside the TOE,
OT.PROTECTIONS that ensures the integrity of the Authentication Public Key while it is inside the TOE,
O.TRUSTED/UNTRUSTED_CA that ensures the the integrity of the Authentication Public key when it is
exported to the CA.

T.MASQUERADE_ADMIN addresses the threat of retrieving or modifying the Admin RAD in order to
illegimately access to the TOE. This threat is countered by:
OT.PROTECTIONS that ensures the integrity and confidentiality of the Admin RAD inside the TOE,
OT.AUTH_ADMIN that ensures that the Administrator will be authenticated to the TOE before he can perform
sensitive operations on the TOE,
OE.COPY that ensures the confidentiality of the Admin RAD outside the TOE,
O.TRUSTED/UNTRUSTED_ADMINISTRATION_APPLI that ensures the integrity and confidentiality of the
Admin RAD when it is transferred from the administration application to the TOE.

40
BS EN 419251-3:2013
EN 419251-3:2013 (E)

OSP.AUTHENTICATION_PROTOCOL addresses the authentication protocol. This OSP is covered by:


OT.DEVICE_AUTHENTICATION that ensures the authentication of the TOE using a public-key protocol, and
O.TRUSTED/UNTRUSTED_VERIFIER that ensures the integrity of the Authentication Protocol sensitive data
when it is transferred from the TOE to the Verifier.

OSP.PKI addresses the PKI.This OSP is covered by:


OT.AUTHENTICATION_KEYS_GENERATION which ensures the correct generation of Authentication Key
pairs on card,
OE.KEY_PAIR_GENERATION, which ensures the correct generation of Authentication Key pairs off card, and
O.TRUSTED/UNTRUSTED_CA, which ensures the integrity of Authentication Public key when it is transferred
to the CA.

OSP.PERSO_CORE addresses Issuer activities during the Personnalisation. This OSP is covered by:
OT.HOLDER_RAD that ensures the import and update of the HOLDER_RAD
OT.AUTHENTICATION_PRIVATE_KEY_IMPORT that allows the Issuer to import APrK in Personnalisation,
OT.AUTHENTICATION_KEYS_GENERATION that ensures the TOE allows the Issuer to generate APrK /
APuK on card in Personnalisation,
OE.KEY_PAIR_GENERATION that provides the authentication key pair generated off card, and
OT.ADMIN_RAD that ensures the import and update of the ADMIN_RAD.

OSP.CRYPTO addresses the cryptographic rules to be applied. This OSP is covered by:
OT.AUTHENTICATION_PRIVATE_KEY_IMPORT that securely imports APrK,
OT.AUTHENTICATION_KEYS_GENERATION which ensures the correct generation of Authentication Key
pairs on card, and
OE.CRYPTO, which requires cryptographic mechanisms of the TOE to conform to the rules and
recommendations defined by the relevant Certification Body.

OSP.CONSISTENCY addresses the consistency of the key pair APrK / APuK. This OSP is covered by the
objectives:
OT.PROTECTIONS that ensures the integrity of of the Authentication public key inside the TOE,
OT.AUTHENTICATION_KEYS_GENERATION that generates the cryptographic key pair used in the
authentication of the TOE, and
O.TRUSTED/UNTRUSTED_CA that ensures the integrity of APuK when it is exported from the TOE to the CA.

OSP.PERSO_ADMIN addresses the activities linked to the Administrator, in Personnalisation. This OSP is
covered by the objectives:
OT.ADMIN_RAD that ensures the import and update of the Administrator RAD.

OSP.ADMIN addresses the activities linked to the Administrator, in Usage phase. This OSP is covered by the
objectives:
OT.LOG that stores a log of unsuccessful holder authentication,
OT.RESET_HODER_RAD_COUNTER that unblocks the RAD holder,

41
BS EN 419251-3:2013
EN 419251-3:2013 (E)

A.ISSUER assumes qualifications of the Issuer. This assumption is directly covered by


OE.ISSUER that ensures that the Issuer is trained to conduct his activities.

A.HOLDER assumes qualifications of the Holder. This assumption is automatically covered by the objective
on the environment
OE.HOLDER that ensures that the Issuer is aware he shall not disclose his own RAD.

A.CERTIF_VERIF assumes the Verifier checks the certificate.This assumption is automatically covered by the
objective on the environment:
OE.CERTIF_VERIF that ensures the Verifier shall check the validity of the Holder certificate.

A.CERTIF_AUTH assumes qualifications of the Certification Authority. This assumption is covered by the
objectives on the environment:
OE.CERTIF_AUTH that ensures the CA shall implement practices that conform to an approved certification
policy, and
OE.CRYPTO, which defines the cryptographic rules to be applied by the CA.

A.COPY assumes confidential assets are not disclosed outside the TOE. This assumption is covered by the
objective on the environment:
OE.COPY that prevents the sensitive date to be compromised by copies of such data that may exist outside
the TOE.

A.CRYPTO assumes that the rules and recommendations defined by the relevant Certification Body are
applied for the generation of authentication keys outside the TOE. This assumption is automatically covered
by the objective on the environment
OE.CRYPTO, which ensures that the generation of the Authentication Key Pair and the generation of the
Authentication Certificate shall conform to the rules and recommendations defined by the relevant Certification
Body.

A.KEY_PAIR_GENERATION assumes the correct generation of keys outside the TOE. This assumption is
automatically covered by the objective on the environment
OE.KEY_PAIR_GENERATION, which ensures the integrity and the confidentiality of APrK and the integrity of
the APuK and
OE.CRYPTO, which ensures that the generation of the Authentication Key Pair shall conform to the rules and
recommendations defined by the relevant Certification Body.

A.ADMIN assumes qualifications of the Administrator. This assumption is automatically covered by the
objective on the environment
OE.ADMIN that ensures that the Issuer is trained to conduct his activities.

42
BS EN 419251-3:2013
EN 419251-3:2013 (E)

9 Extended component definition – Definition of the Family FCS_RNG

To define the IT security functional requirements of the TOE an additional family (FCS_RNG) of the Class
FCS (cryptographic support) is defined here. This family describes the functional requirements for random
number generation used for cryptographic purposes.

FCS_RNG Generation of random numbers


Family behaviour
This family defines quality requirements for the generation of random numbers which are intended to be use
for cryptographic purposes.
Component leveling:

FCS_RNG Generation of random numbers 1

FCS_RNG.1 Generation of random numbers requires that random numbers meet a defined
quality metric.
Management: FCS_RNG.1
There are no management activities foreseen.
Audit: FCS_RNG.1
There are no actions defined to be auditable.
FCS_RNG.1 Random number generation
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic,
hybrid] random number generator that implements: [assignment: list of security
capabilities].
FCS_RNG.1.2 The TSF shall provide random numbers that meet [assignment: a defined
quality metric].
Application note 1: A physical random number generator (RNG) produces the random number by a
noise source based on physical random processes. A non-physical true RNG
uses a noise source based on non-physical random processes like human
interaction (key strokes, mouse movement). A deterministic RNG uses a
random seed to produce a pseudorandom output. A hybrid RNG combines the
principles of physical and deterministic RNGs.

10 Security requirements

10.1 General

This section describes the operations and requirements that a TOE shall fulfill in order to be compliant to this
PP.

The device shall implement all the following requirements/operations:

43
BS EN 419251-3:2013
EN 419251-3:2013 (E)

 Device authentication by the verifier (on behalf of the Holder);

 Issuer authentication;

 Holder authentication with limited authentication attempts;

 Import of the authentication protocol sensitive data;

 Import of the Holder RAD;

 Export of the authentication protocol sensitive data.

Moreover, the device shall implement either the following set of requirements:

 Import of the authentication private key;

or the following requirement:

 Generation of authentication key pair.

 Export of the authentication public key;

NOTE The device could implement both sets of requirements (key pair generation and key pair import).

As explained in the introduction of Clause 8 "Security objectives", transfers security can be enforced by the
TOE or by the environment.
This section also contains SFR for the untrusted environments, when transfer security is enforced by the TOE.

10.2 Introduction

10.2.1 Subjects Objects and security attributes

S.command_manager
It manages commands sent to the TOE and corresponding responses from the TOE, including import/export
of sensitive assets.
S.communication_manager
IT manages the communication with the on-line service or with the distant agent in order to perform the
service provided by the TOE.
O.Authentication_Private_Key
This object is the authentication key used to authenticate the card to a Verifier. This object is not necessarily
unique.
O.Holder_RAD
This object is the Holder RAD. If it is a PIN, it has to be modified by the holder to ensure that only he can
authenticate to the TOE.

44
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Table 5 — Security attributes


Subject Security attribute Possible Values Initial Value
S.command_manager AT.Phase Personalisation, Usage Personalisation
S.command_manager AT.Authenticated_user Issuer, Holder, Administrator, None
None
S.communication_manager AT.Authenticated_device Verifier, None None
O.Authentication_Private_Key AT.Operational Yes, No Yes, No
O.Authentication_Private_Key AT.Consistency_pub_key Yes, No No
O.Authentication_Private_Key AT.Identifier Arbitrary value Null
O.Holder_RAD AT.Holder_only Yes, No No
O.Holder_RAD AT.RAD_value Arbitrary value Null
O.Holder_RAD AT.RAD_retry_counter 0 to 0
HOLDER_MAX_RETRY_CO
UNTER
O.Holder_RAD AT.RAD_reset_counter 0 to 0
RAD_MAX_RESET_COUNT
ER

10.2.2 Operations

10.2.2.1 Core group

 Calculate: This operation corresponds to the internal use of the authentication private key.

 Issuer Authentication.

 Holder authentication with limited authentication attempts.

 Import of the Authentication Protocol sensitive data: This writing operation includes the deletion of the
previous Authentication Protocol sensitive data (if any).

 Import of the Holder RAD: This writing operation includes the deletion of the previous Holder RAD (if any).

10.2.2.2 KeyImp group

Import of the authentication private key: This writing operation includes the deletion of the previous
authentication private key (if any) and the deletion of the previous Authentication Protocol sensitive data (if
any).

10.2.2.3 KeyGen group

 Generation of authentication key pair: This creation operation generates an authentication private key and
an authentication public key. This operation includes the deletion of the previous authentication private
and Authentication Protocol sensitive data (if any).

 Export of the authentication public key: This reading operation allows exporting the authentication public
key outside the device.

10.2.2.4 Admin group

 Administrator authentication with limited authentication attempts;

 Reset Holder authentication failures counter;

45
BS EN 419251-3:2013
EN 419251-3:2013 (E)

 Export of Holder authentication logs: The log contains the number of Holder authentication failure
attempts;

 Import of the Administrator RAD: This writing operation includes the deletion of the previous Administrator
RAD (if any).

10.2.2.5 Untrusted PersoAppli

 Authentication with Issuer_VAD – protected in integrity and confidentiality

 Import of Holder_RAD – protected in integrity and confidentiality

 Import of Admin_RAD – protected in integrity and confidentiality

 Import of Authentication Protocol data – protected in integrity

10.2.2.6 Untrusted AuthAppli

 Authentication with Holder_VAD – protected in integrity and confidentiality

 Import of Holder_RAD – protected in integrity and confidentiality

 Import of Authentication Protocol data – protected in integrity

10.2.2.7 Untrusted Verifier

 Import of random message to be signed – protected in integrity

 Export of Signed message – protected in integrity

10.2.2.8 Untrusted CA

Secure Export of the public key to the CA for the generation of the certificate – protected in integrity.

10.2.2.9 Untrusted AdminAppli

 Authentication with Admin_VAD – protected in integrity and confidentiality

 Export of LOG – protected in integrity and confidentiality

 Import of Authentication Protocol sensitive data – protected in integrity

10.3 Security functional requirements

10.3.1 General

Global refinement for crypto operations:

The cryptographic algorithms, modes of operations and protocols including random generation shall be
compliant with the rules and recommendations defined in OSP.CRYPTO.

46
BS EN 419251-3:2013
EN 419251-3:2013 (E)

10.3.2 Core group

10.3.2.1 Device authentication by the verifier

FCS_COP.1/Signature Cryptographic operation


Hierarchical to: No other component
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes

FCS_COP.1/ The TSF shall perform [assignment: list of cryptographic operations] in


Signature accordance with a specified cryptographic algorithm [assignment:
cryptographic algorithm] and cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [assignment: list of
standards].

FCS_CKM.4/Priv_key Cryptographic key destruction


Hierarchical to: No other component
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FMT_MSA.2 Secure security attributes
FCS_CKM.4.1/ The TSF shall destroy cryptographic keys in accordance with a specified
Priv_key cryptographic key destruction method [assignment: cryptographic key destruction
method] that meets the following: [assignment: list of standards].

Application note:
The private key has to be overwritten when a new private key is regenerated or re-imported, for the same
authentication usage

FIA_ATD.1 User attribute definition


Hierarchical to: No other component
Dependencies: No dependencies

FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to
individual users: [see Table 5 — Security attributes, other security attributes].

FIA_USB.1/Device User-subject binding


Hierarchical to: No other component
Dependencies: FIA_ATD.1 User attribute definition

47
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FIA_USB.1.1/ The TSF shall associate the following user security attributes with subjects acting
Device on the behalf of that user: AT.Authenticated_device.

FIA_USB.1.2/ The TSF shall enforce the following rules on the initial association of user
Device security attributes with subjects acting on the behalf of users:
Before a user binds to S.Communication_manager the TSF shall authenticate to
that user.
FIA_USB.1.3/ The TSF shall enforce the following rules governing changes to the user security
Device attributes associated with subjects acting on the behalf of users:
If the device is successfully authenticated by the verifier then the value of the
security attribute Authenticated_ device of S.communication_manager shall be
set at "verifier".

Application note:
The authentication mechanism implemented by the TOE shall be based on a public key cryptographic
algorithm that allows the verifier to prevent replay of authentication data.

10.3.2.2 User authentication

FIA_UAU.1 Timing of authentication


Hierarchical to: No other component
Dependencies: FIA_UID.1 Timing of identification

FIA_UAU.1.1 The TSF shall allow [assignment: list of TSF mediated actions] 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:
When refining this SFR, the ST writer shall pay attention to prevent any disclosure of data that can enable the
tracking of the holder, without his consent.

FIA_USB.1/User User-subject binding


Hierarchical to: No other component
Dependencies: FIA_ATD.1 User attribute definition

48
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FIA_USB.1.1/User The TSF shall associate the following user security attributes with
subjects acting on the behalf of that user: AT.Phase.

FIA_USB.1.2/User The TSF shall enforce the following rules on the initial association of
user security attributes with subjects acting on the behalf of users:

• Before a user binds to S.Communication_manager the TSF shall


authenticate to that user.

FIA_USB.1.3/User The TSF shall enforce the following rules governing changes to the user
security attributes associated with subjects acting on the behalf of
users:

• If the user provides the VAD corresponding to the Issuer RAD and if
Phase[S.command_manager]=Personalization, then the value of the
security attribute Authenticated_ user of S.command_manager shall
be set at "Issuer".

• If the user provides the VAD corresponding to the Holder RAD and
if Phase[S.command_manager]=Usage, then the value of the
security attribute Authenticated_ user of S.command_manager shall
be set at "Holder".
Application note:
If the configuration includes the admin group, this SFR shall be replaced by FIA_USB.1/Admin. See 10.3.5
"Admin group".

FIA_AFL.1/Holder Authentication failure handling


Hierarchical to: No other component
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1/ The TSF shall detect when [HOLDER_RAD_MAX_RETRY] unsuccessful
Holder authentication attempts occur related to the same user (Holder).

FIA_AFL.1.2/ When the defined number of unsuccessful authentication attempts has


Holder been [met, surpassed], the TSF shall prevent any subsequent Holder
authentication attempt.

Application notes:
The ST writer shall define the integer HOLDER_RAD_MAX_RETRY.
“unsuccessful authentication attempts” here shall be regarded as “consecutive unsuccessful authentication
attempts”.
When the RAD is blocked, the only way to unblock it is to reset the counter. This operation can only be
performed by the administrator.

10.3.2.3 Access control

FDP_ACC.1/Core Subset access control


Hierarchical to: No other component
Dependencies: FDP_ACF.1 Security attribute based access control

49
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FDP_ACC.1.1/ Core The TSF shall enforce the Core access control SFP on [assignment: list
of subjects, objects, and operations among subjects and objects
covered by the SFP].

Subject Object Operation


S.command_manager Authentication private key Calculate

FDP_ACF.1/Core Security attribute based access control


Hierarchical to: No other component
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization

FDP_ACF.1.1/ Core The TSF shall enforce the Core access control SFP to objects based on
the following:
Table 6 — Core security attributes
Subject/Object Security attribute
S.command_manager AT.Phase
S.command_manager AT.Authenticated_user
O.Authentication_Private_Key AT.Operational
O.Holder_RAD AT.Holder_Only

FDP_ACF.1.2/ Core The TSF shall enforce the following rules to


determine if an operation among controlled
subjects and controlled objects is allowed:

The following operation is allowed when the rule is met:

Table 7 — Core operations


Operation Rule
Calculate Phase[S.command_manager]=Usage AND
Authenticated_user[S.command_manager]=Holder AND
Operational[O.Authentication private key]=Yes AND
Holder_Only[O.Holder_RAD] =Yes

FDP_ACF.1.3/ Core The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: None

FDP_ACF.1.4/ Core The TSF shall explicitly deny access of subjects to objects based on the
following rules:

The following operations are never allowed:


 Export (read) of the authentication private key
 Modification (other than the import operations) of the authentication private key and the Authentication
Protocol sensitive data.

FDP_RIP.1 Subset residual information protection


Hierarchical to: No other component
Dependencies: No dependencies

50
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FDP_RIP.1.1 The TSF shall ensure that any previous information content of a
resource is made unavailable upon the deallocation of the resource
from the following objects: Authentication private key.

FDP_SDI.2 Stored data integrity monitoring and action


The following data persistently stored by the TOE have the user data attribute “stored sensitive data”:
 Authentication private key
 Authentication public key if stored in the TOE
 Authentication Protocol sensitive data

Hierarchical to: FDP_SDI.1 Stored data integrity monitoring


Dependencies: No dependencies

FDP_SDI.2.1 The TSF shall monitor user data stored within the TSC for integrity
errors on all objects, based on the following attributes: “stored
sensitive data”.
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall:
prohibit the use of the altered data
inform the user about the error

FMT_MSA.1/Core Management of security attributes


Hierarchical to: No other component
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions

FMT_MSA.1.1/Core The TSF shall enforce the Core access control SFP, [assignment: other
access control SFP, other information flow control SFP] to restrict the
ability to [selection: change_default, query, modify, delete, [assignment:
other operations]] the security attributes [assignment: list of security
attributes] to [assignment: the authorised identified roles].
Table 8 — Core security attributes − Operation
Authorised role Operation Attribute At value
Issuer Set value of AT.Phase [S.command_manager] Usage
Issuer Change default value of AT.Identifier [Authentication_Private_Key] Arbitrary value
Holder Set value of AT.Holder_Only [Holder_RAD] Yes
Holder Set value of AT.Authenticated_device Verifier
[S.communication_manager]
Issuer, Holder Modify value of AT.Authenticated_user Not Applicable
[S.command_manager]

FMT_MSA.2 Secure security attributes


Hierarchical to: No other component
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]

51
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FMT_MSA.1 Management of security attributes


FMT_SMR.1 Security roles

FMT_MSA.2.1 The TSF shall ensure that only secure values are accepted for
[see Table 5 — Security attributes, other security attributes].

FMT_MSA.3/Core Static attribute initialization


Hierarchical to: No other component
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles

FMT_MSA.3.1/Core The TSF shall enforce Core access control SFP, [assignment: other
access control SFP, other information flow control SFP] to provide
restrictive default values for security attributes that are used to enforce
the SFP.
Table 9 — Core security attributes - initial value
Security attribute Initial value
AT.Phase [S.command_manager] Pre-personalisation
AT.Authenticated_ user [S.command_manager] None
AT.Authenticated_device [S.communication_manager] None
AT.Holder_Only [Holder_RAD] No
AT.Operational [Authentication_Private_Key] No
AT.Consistency_Pub_Key [Authentication_Private_Key] No
AT.RAD_retry _counter [Holder_RAD] 0

FMT_MSA.3.2/Core The TSF shall allow the None to specify alternative initial values to
override the default values when an object or information is created.

FMT_MSA.4/Core Security attributes value inheritance


Hierarchical to: No other component
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles

FMT_MSA.4.1/Core The TSF shall use the following rules to set the value of security
attributes [assignment: rules for setting the value of security attributes].

52
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Table 10 — Core security attributes – Updates


Condition Modification
Set value of at
Authenticated Issuer AND Issuer command to Usage AT.Phase Usage
phase [S.command_manager]
Authenticated Issuer AND Issuer command to Usage AT.Holder_Only [Holder_RAD] No
phase AND RAD is PIN or symmetric key
Authenticated Issuer AND Issuer command to Usage AT.Holder_Only [Holder_RAD] Yes
phase AND RAD is biometrics
Reset of the device or end of session. AT.Authenticated_user None
[S.command_manager]
Reset of the device or end of session. AT.Authenticated_device None
Authenticated Holder AND change PIN AT.Holder_Only [Holder_RAD] Yes
Issuer Authentication AND Phase personalisation AT.Authenticated_user Issuer
[S.command_manager]
Holder Authentication AND Phase usage AT.Authenticated_ user Holder
[S.command_manager]
Import Authentication Protocol sensitive data for the AT.Operational Yes
current Authentication Private Key [Authentication_Private_Key]
Failed Holder Authentication AT.RAD_retry_counter current
[Holder_RAD] RAD_retry_Counter +1
Successful Holder Authentication AT.RAD_retry _counter 0
[Holder_RAD]
Authenticated Holder AND Successful Authentication AT.Authenticated_device Verifier
by Verifier [S.communication_manager]

Application note:
When RAD_retry _counter [Holder_RAD] reaches HOLDER_RAD_MAX_RETRY, All subsequent
authentication are blocked until the counter is reset by the Administrator

FMT_MTD.1/Core Management of TSF data


Hierarchical to: No other component
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of management functions
FMT_MTD.1.1/Core The TSF shall restrict the ability to [selection: change_default, query,
modify, delete, clear, [assignment: other operations]] the [assignment:
list of TSF data] to [assignment: the authorised identified roles].
Table 11 — TSF data – updates
Operation TSF data role
modify Holder_RAD holder
modify Authentication Protocol sensitive Holder,
data administrator

FMT_SMR.1/Core Security roles


Hierarchical to: No other component
Dependencies: FIA_UID.1 Timing of Authentication

53
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FMT_SMR.1.1/Core The TSF shall maintain the roles Issuer, Holder.


FMT_SMR.1.2/Core The TSF shall be able to associate users with roles.

FMT_SMF.1/Core Specification of management functions


Hierarchical to: No other component
Dependencies: No dependencies

FMT_SMF.1.1/Core The TSF shall be capable of performing the following management


functions:
Creation and modification of RAD,
Import of Authentication Protocol sensitive data
[assignment: list of other management functions to be provided by the
TSF].

10.3.2.4 Protection of the TSF

FPT_FLS.1 Failure with preservation of secure state


Hierarchical to: No other component
Dependencies: No dependencies

FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures
occur: [assignment: list of types of failures in the TSF].

FPT_PHP.1 Passive detection of physical attack


Hierarchical to: No other component
Dependencies: No dependencies

FPT_PHP.1.1 The TSF shall provide unambiguous detection of physical tampering that
might compromise the TSF.

FPT_PHP.1.2 The TSF shall provide the capability to determine whether physical
tampering with the TSF's devices or TSF's elements has occurred.

FPT_PHP.3 Resistance to physical attack


Hierarchical to: No other component
Dependencies: No dependencies

FPT_PHP.3.1 The TSF shall resist [assignment: physical tampering scenarios] to the
[assignment: list of TSF devices/elements] by responding automatically
such that the TSP is not violated.

Application note:
Physical tampering includes know attacks such as SPA, DPA, SEMA, DEMA, DFA

FPT_TST.1 TSF testing


Hierarchical to: No other component

54
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Dependencies: No dependencies

FPT_TST.1.1 The TSF shall run a suite of self tests [selection: during initial start-up,
periodically during normal operation, at the request of the authorised user,
at the conditions [assignment: conditions under which self test should
occur]] to demonstrate the correct operation of the TSF. operation of
[selection: [assignment: parts of TSF], the TSF].

FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the
integrity of [selection: [assignment: parts of TSF], TSF data].

FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the
integrity of stored TSF executable code.
10.3.3 KeyImp group

This section contains the SFR that are specific to the import of the Authentication Private Key

FDP_ACC.1/KeyImp Subset access control


Hierarchical to: No other component
Dependencies: FDP_ACF.1 Security attribute based access control

FDP_ACC.1.1/ The TSF shall enforce the KeyImp access control SFP on [assignment: list
KeyImp of subjects, objects, and operations among subjects and objects covered
by the SFP].

Subject Object Operation


Holder/Issuer Authentication Private Key Import of the authentication private key

FDP_ACF.1/KeyImp Security attribute based access control


Hierarchical to: No other component
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization

FDP_ACF.1.1/ The TSF shall enforce the KeyImp access control SFP to objects based on
KeyImp the following:
Table 12 — KeyImp security attributes
Subject/Object Security attribute
S.command_manager AT.Phase
S.command_manager AT.Authenticated_user

FDP_ACF.1.2/ The TSF shall enforce the following rules to determine if an operation among
KeyImp controlled subjects and controlled objects is allowed:

The following operation is allowed only when the rule is met:

55
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Table 13 — KeyImp security attributes - operations


Operation Rule
Import of the authentication private {AT.Phase[S.command_manager]=Usage AND
key AT.Authenticated_user[S.command_manager]=Holder} OR
{AT.Phase[S.command_manager]=Personalization AND
AT.Authenticated_user[S.command_manager]=Issuer}

FDP_ACF.1.3/ The TSF shall explicitly authorise access of subjects to objects based
KeyImp on the following additional rules: None.

FDP_ACF.1.4/ The TSF shall explicitly deny access of subjects to objects based on the
KeyImp following additional rules: None.

FDP_ITC.2/Priv_key Import of user data with security attributes


Hierarchical to: No other component
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]

FDP_ITC.2.1/Priv_key The TSF shall enforce the KeyImp access control SFP when
importing user data, controlled under the SFP, from outside of the
TOE

FDP_ITC.2.2/Priv_key The TSF shall use the security attributes associated with the
imported user

FDP_ITC.2.3/Priv_key The TSF shall ensure that the protocol used provides for the
unambiguous association between the security attributes and the
user data received.

FDP_ITC.2.4/Priv_key The TSF shall ensure that interpretation of the security attributes of
the imported user data is as intended by the source of the user data.

FDP_ITC.2.5/Priv_key The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TOE: [assignment:
additional importation control rules].

FDP_UCT.1/Priv_key Basic Data exchange confidentiality


Hierarchical to: No other component
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]

56
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FDP_UCT.1.1/Priv_key The TSF shall enforce the KeyImp access control SFP to be able
to receive user data in a manner protected from unauthorised
disclosure.

The user considered here is the Authentication Private key.

FDP_UIT.1/Priv_key Data exchange integrity

Hierarchical to: No other component


Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]

FDP_UIT.1.1/Priv_key The TSF shall enforce the KeyImp access control SFP to be able
to receive user data in a manner protected from modification,
deletion, insertion, replay errors.
FDP_UIT.1.2/Priv_key The TSF shall be able to determine on receipt of user data,
whether modification, deletion, insertion, replay errors has
occurred.

FMT_MSA.1/KeyImp Management of security attributes


Hierarchical to: No other component
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions

FMT_MSA.1.1/ The TSF shall enforce the KeyImp access control SFP, [assignment:
KeyImp other access control SFP, other information flow control SFP] to restrict
the ability to [selection: change_default, query, modify, delete,
[assignment: other operations]] the security attributes [assignment: list
of security attributes] to [assignment: the authorised identified roles].
Table 14 — KeyImp security attributes – update authorised roles
Authorised role Operation Attribute At value
Issuer, Holder Set value of AT.Operational[Authentication_Private_Key] Yes, No
Issuer, Holder Set value of AT.Consistency_pub_key[Authentication_Private_Key] Yes, No

FMT_MSA.4/KeyImp Security attributes value inheritance


Hierarchical to: No other component
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles

57
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FMT_MSA.4.1 The TSF shall use the following rules to set the value of security
/KeyImp attributes [assignment: rules for setting the value of security
attributes].
Table 15 — KeyImp security attributes – update values
Condition Modification
Set value of at
Import Authentication private key AT.Operational[Authentication_Private_Key] No
Import Authentication Protocol sensitive AT.Operational[Authentication_Private_Key] Yes
data
Import Authentication private key AT.Consistency_pub_key[Authentication_Private_Key] No

FTP_ITC.1/Priv_Key Inter-TSF trusted channel


Hierarchical to: No other component
Dependencies: No dependencies

FTP_ITC1.1/ The TSF shall provide a communication channel between itself and another
Priv_Key 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_ITC1.2/ The TSF shall permit another trusted IT product to initiate communication
Priv_Key via the trusted channel.

FTP_ITC1.3/ The TSF shall initiate communication via the trusted channel for:
Priv_Key • Import of Priv_Key

Application note:
1. The Remote Trusted IT product is Key pair generator

10.3.4 KeyGen group

FCS_CKM.1/Key_pair Cryptographic key generation


Hierarchical to: No other component
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes

FCS_CKM.1.1/ The TSF shall generate cryptographic keys in accordance with a specified
Key_pair cryptographic key generation algorithm [assignment: cryptographic key
generation algorithm] and specified cryptographic key sizes [assignment:
cryptographic key sizes] that meet the following: [assignment: list of
standards].

Application note:
This SFR shall be refined in a way compliant with OSP.CRYPTO.

58
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FCS_RNG.1/KeyGen TSF Generation of random numbers


Hierarchical to: No other component
Dependencies: No dependencies

FCS_RNG.1.1/ The TSF shall provide a [selection: physical, non-physical true,


KeyGen deterministic, hybrid] random number generator that implements:
[assignment: list of security capabilities].

FCS_RNG.1.2/ The TSF shall be able to enforce the use of TSF generated secrets for
KeyGen [assignment: list of TSF functions].

Application note:
The random generation shall be compliant with OSP_CRYPTO.

FDP_ACC.1/KeyGen Subset access control


Hierarchical to: No other component
Dependencies: FDP_ACF.1 Security attribute based access control

FDP_ACC.1.1/ The TSF shall enforce the KeyGen access control SFP on [assignment: list
KeyGen of subjects, objects, and operations among subjects and objects covered
by the SFP].
Table 16 — KeyGen operations
Subject Object Operation
S.command_manager authentication key pair Generation of authentication key pair
S.command_manager Authentication public key Export of the authentication public key

FDP_ACF.1/KeyGen Security attribute based access control


Hierarchical to: No other component
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization

FDP_ACF.1.1/ The TSF shall enforce the KeyGen access control SFP to objects based on
KeyGen the following:
Table 17 — KeyGen security attributes
Subject/Object Security attribute
S.command_manager AT.Phase
S.command_manager AT.Authenticated_user
S.command_manager AT.Consistency_pub_key

FDP_ACF.1.2/ The TSF shall enforce the following rules to determine if an operation among
KeyGen controlled subjects and controlled objects is allowed:

The following operations are allowed only when the rules are met:

59
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Table 18 — KeyGen operation rules


Operation Rule
{Phase[S.command_manager]=Usage AND Authenticated_user
Generation of [S.command_manager]=Holder} OR
authentication key pair {Phase[S.command_manager]=Personalization AND Authenticated_user
[S.command_manager]=Issuer}
{{Phase[S.command_manager]=Usage AND Authenticated_user
[S.command_manager]=Holder} OR
Export of authentication
{Phase[S.command_manager]=Personalization AND Authenticated_user
Public key
[S.command_manager]=Issuer}} AND
Consistency_pub_key[S.command_manager] = Yes

FDP_ACF.1.3/ The TSF shall explicitly authorise access of subjects to objects based
KeyGen on the following additional rules: None.

FDP_ACF.1.4/ The TSF shall explicitly deny access of subjects to objects based on the
KeyGen following additional rules: None.

FMT_MSA.1/KeyGen Management of security attributes


Hierarchical to: No other component
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions

FMT_MSA.1.1/KeyGe The TSF shall enforce the KeyGen access control SFP, [assignment:
n other access control SFP, other information flow control SFP] to
restrict the ability to [selection: change_default, query, modify, delete,
[assignment: other operations]] the security attributes [assignment:
list of security attributes] to [assignment: the authorised identified
roles].
Table 19 — KeyGen security attributes – update authorised roles
Authorised role Operation Attribute At value

Issuer, Holder Set value of AT.Consistency_Pub_Key [Authentication_Private_Key] Yes, No


Issuer, Holder Set value of AT.Operational[Authentication_Private_Key] Yes, No

FMT_MSA.3/KeyGen Static attribute initialization


Hierarchical to: No other component
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles

FMT_MSA.3.1 The TSF shall enforce KeyGen access control SFP, [assignment: other
/KeyGen access control SFP, other information flow control SFP] to provide
restrictive default values for security attributes that are used to
enforce the SFP.

60
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Table 20 — KeyGen security attributes – initial values


Security attribute Initial value
AT.Consistency_pub_key No
AT.Operational No

FMT_MSA.3.2 The TSF shall allow the None to specify alternative initial values to
/KeyGen override the default values when an object or information is created.

FMT_MSA.4/KeyGen Security attributes value inheritance


Hierarchical to: No other component
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles

FMT_MSA.4.1 The TSF shall use the following rules to set the value of security
/KeyGen attributes [assignment: rules for setting the value of security
attributes].
Table 21 — KeyGen security attributes – update values
Condition Modification
Set value of at
Generate Authentication Key pair Consistency_Pub_Key[Authentication_Private_Key] Yes
Delete Authentication Key pair Operational[Authentication_Private_Key] No
Import Authentication Protocol sensitive Operational[Authentication_Private_Key] Yes
data

10.3.5 Admin group

FAU_GEN.1 Audit data generation


Hierarchical to: No other component
Dependencies: FPT_STM.1 Reliable time stamps

FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable
events: Holder authentication failures.
FAU_GEN.1.2 The TSF shall record within each audit record at least the following
information: none

Application note:
The generic SFR FAU_GEN.1 requires other data that are unavailable in a Smartcard. This SFR has therefore
been simplified and adapted to Smartcards.

FDP_ACC.1/ Admin Subset access control


Hierarchical to: No other component
Dependencies: FDP_ACF.1 Security attribute based access control

61
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FDP_ACC.1.1/ The TSF shall enforce the Admin access control SFP on [assignment: list
Admin of subjects, objects, and operations among subjects and objects covered
by the SFP].

Subject Object Operation


Administrator Holder authentication failures log Export of Holder authentication failures log

FDP_ACF.1/ Admin Security attribute based access control


Hierarchical to: No other component
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization

FDP_ACF.1.1/ The TSF shall enforce the Admin access control SFP to objects based on
Admin the following:

Subject/Object Security attribute


S.command_manager AT.Phase
S.command_manager AT.Authenticated_user

FDP_ACF.1.2/ The TSF shall enforce the following rules to determine if an operation among
Admin controlled subjects and controlled objects is allowed:

The following operation is allowed when the rule is met:


Operation Rule
Export of Holder authentication AT.Phase[S.command_manager]=Usage AND
failures log AT.Authenticated_user[S.command_manager]=Administrator
Reset Holder authentication failures AT.Phase[S.command_manager]=Usage AND
counter a AT.Authenticated_user[S.command_manager]=Administrator
a
This operation allows the Adminstrator to retrieve the Holder RAD by exhaustive search. The ST
author should consider the replacement of this rule with a more restrictive rule requiring both the
authentication of the Administrator and the authentication of the Holder. In this case, a new value shall be
added to the security attribute AT.authenticated_user of S.Command_manager:
Holder_and_Administrator.

FDP_ACF.1.3/ The TSF shall explicitly authorise access of subjects to objects based
Admin on the following additional rules: None.

FDP_ACF.1.4/ The TSF shall explicitly deny access of subjects to objects based on the
Admin following additional rules: None.

FIA_AFL.1/Admin Authentication failure handling


Hierarchical to: No other component
Dependencies: FIA_UAU.1 Timing of authentication

62
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FIA_AFL.1.1/ The TSF shall detect when [ADMIN_RAD_MAX_RETRY] unsuccessful


Admin authentication attempts occur related to the same user (Holder).

FIA_AFL.1.2/ When the defined number of unsuccessful authentication attempts has


Admin been [met, surpassed], the TSF shall prevent any subsequent Holder
authentication attempt.

Application notes:
The ST writer shall define the value the integer ADMIN_RAD_MAX_RETRY.
“unsuccessful authentication attempts” here shall be regarded as “consecutive unsuccessful authentication
attempts”.
When the Admin_RAD is blocked, there in no way to unblock it.

FIA_USB.1/Admin User-subject binding


As this PP includes the Admin group, this SFR replaces FIA_USB.1/User.
Hierarchical to: No other component
Dependencies: FIA_ATD.1 User attribute definition

FIA_USB.1.1/ The TSF shall associate the following user security attributes with subjects
Admin acting on the behalf of that user: AT.Phase.

FIA_USB.1.2/ The TSF shall enforce the following rules on the initial association of user
Admin security attributes with subjects acting on the behalf of users:
• Before a user binds to S.Communication_manager the TSF shall
authenticate to that user.
FIA_USB.1.3/ The TSF shall enforce the following rules governing changes to the user
Admin security attributes associated with subjects acting on the behalf of users:
• If the user provides the VAD corresponding to the Issuer RAD and if
Phase[S.command_manager]=Personalization, then the value of the
security attribute Authenticated_ user of S.command_manager shall be
set at "Issuer".
• If the user provides the VAD corresponding to the Holder RAD and if
Phase[S.command_manager]=Usage, then the value of the security
attribute Authenticated_ user of S.command_manager shall be set at
"Holder".
• If the user provides the VAD corresponding to the Administrator RAD,
then the value of the security attribute Authenticated_ user of
S.command_manager shall be set at “Administrator”.

FMT_MSA.1/Admin Management of security attributes


Hierarchical to: No other component
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions

63
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FMT_MSA.1.1/Admin The TSF shall enforce the Admin access control SFP, [assignment:
other access control SFP, other information flow control SFP] to
restrict the ability to [selection: change_default, query, modify, delete,
[assignment: other operations]] the security attributes [assignment:
list of security attributes] to [assignment: the authorised identified
roles].
Table 22 — Admin security attributes – update authorised roles
Authorised role Operation Attribute At value

Administrator Set value of AT.RAD_value [Holder_RAD] Default value


Administrator Set value of AT.RAD_retry_counter [Holder_RAD] 0
Administrator Set value of AT.RAD_reset_counter [Holder_RAD] AT.RAD_reset_counter +1

FMT_MSA.3/Admin Static attribute initialization


Hierarchical to: No other component
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles

FMT_MSA.3.1/Admin The TSF shall enforce KeyGen access control SFP, [assignment: other
access control SFP, other information flow control SFP] to provide
restrictive default values for security attributes that are used to
enforce the SFP.
Table 23 — Admin security attributes – initial values
Security attribute Initial value
RAD_reset_counter [Holder_RAD] 0
RAD_retry_counter [Admin_RAD] 0

FMT_MSA.3.2/Admin The TSF shall allow the None to specify alternative initial values to
override the default values when an object or information is created.

FMT_MSA.4/Admin Security attributes value inheritance


Hierarchical to: No other component
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles

FMT_MSA.4.1/Admin The TSF shall use the following rules to set the value of security
attributes [assignment: rules for setting the value of security
attributes].
Table 24 — Admin security attributes – update values
Condition Modification
Set value of at
Reset Holder RAD retry counter AT.RAD_retry _counter [Holder_RAD] 0
Administrator Authentication AND Phase AT.Authenticated_ user [S.command_manager] Administrator
usage
Failed Administrator Authentication AT.RAD_retry _counter [Admin_RAD] N+1
Successful Administrator Authentication AT.RAD_retry _counter [Admin_RAD] 0

64
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Application note:
When RAD_retry _counter [Administrator_RAD] reaches ADMIN_MAX_RETRY, All subsequent authentication
are blocked

FMT_MTD.1/Admin Management of TSF data


Hierarchical to: No other component
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of management functions

FMT_MTD.1.1/ The TSF shall restrict the ability to [selection: change_default, query,
Admin modify, delete, clear, reset [assignment: other operations]] the
[assignment: list of TSF data] to [assignment: the authorised identified
roles].
Table 25 — Admin TSF data – operations
Operation TSF data role
modify Admin_RAD Administrator
reset Holder_RAD Administrator
modify Authentication Protocol sensitive data Holder, Administrator

FMT_SMR.1/Admin Security roles


Hierarchical to: No other component
Dependencies: FIA_UID.1 Timing of Authentication

FMT_SMR.1.2/ Admin The TSF shall maintain the roles Administrator.

FMT_SMR.1.2/ Admin The TSF shall be able to associate users with roles.

FMT_SMF.1/Admin Specification of management functions


Hierarchical to: No other component
Dependencies: No dependencies

FMT_SMF.1.1/ The TSF shall be capable of performing the following management


Admin functions:
• Creation and modification of Admin RAD,
• Reset of Holder RAD retry counter
• [assignment: list of other management functions to be provided by
the TSF].
10.3.6 Untrusted PersoAppli

FTP_ITC.1/PersoAppli Inter-TSF trusted channel


Hierarchical to: No other component
Dependencies: No dependencies

65
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FTP_ITC.1.1/ The TSF shall provide a communication channel between itself and
PersoAppli 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_ITC1.2/ The TSF shall permit another trusted IT product to initiate communication
PersoAppli via the trusted channel.

FTP_ITC1.3/ The TSF shall initiate communication via the trusted channel for:
PersoAppli • Authentication with Issuer_VAD
• Import of Holder_RAD
• Import of Admin_RAD
• Import of Authentication Protocol data

Application notes:
1. Import of Admin_RAD is done only in configurations containing the Admin group
2. Import of Authentication Protocol data could be done outside a trusted channel because there is no
security risk at stake. But if the imported data are corrupted, the TOE will not work.
10.3.7 Untrusted AuthAppli

FTP_ITC.1/AuthAppli Inter-TSF trusted channel


Hierarchical to: No other component
Dependencies: No dependencies

FTP_ITC.1.1/ The TSF shall provide a communication channel between itself and
AuthAppli 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_ITC1.2/ The TSF shall permit another trusted IT product to initiate communication
AuthAppli via the trusted channel.

FTP_ITC1.3/ The TSF shall initiate communication via the trusted channel for:
AuthAppli • Authentication with Holder_VAD
• Import of Holder_RAD
• Import of Authentication Protocol data

10.3.8 Untrusted Verifier

FTP_ITC.1/ Verifier Inter-TSF trusted channel


Hierarchical to: No other component
Dependencies: No dependencies

66
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FTP_ITC.1.1/ The TSF shall provide a communication channel between itself and
Verifier 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_ITC1.2/ The TSF shall permit another trusted IT product to initiate communication
Verifier via the trusted channel.

FTP_ITC1.3/ The TSF shall initiate communication via the trusted channel for:
Verifier • Import of random message to be signed
• Export of Signed message

Application note:
1. This SFR requires a Trusted channel to protect the Authentication operation itself.
2. The Authentication operation may part of the Trusted channel establishment.
3. The Remote Trusted IT product is the verifier

10.3.9 Untrusted CA

FDP_UIT.1/Pub_key Data export integrity


Hierarchical to: No other component
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]

FDP_UIT.1.1/Pub_key The TSF shall enforce the KeyGen access control SFP to be able to
transmit user data in a manner protected from modification, deletion,
insertion, replay errors.
FDP_UIT.1.2/Pub_key The TSF shall be able to determine on receipt of user data, whether
modification, deletion, insertion, replay errors has occurred.

FTP_ITC.1/CA Inter-TSF trusted channel


Hierarchical to: No other component
Dependencies: No dependencies

FTP_ITC.1.1/ CA 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_ITC1.2/ CA The TSF shall permit another trusted IT product to initiate communication
via the trusted channel.

FTP_ITC1.3/ CA The TSF shall initiate communication via the trusted channel for:
• Export of Public key

67
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Application note:
1. This SFR shall be included only if the KeyGen group is in the configuration.
2. The Remote Trusted IT product is CA
3. The Trusted Channel shall include a “Proof of Possession”

10.3.10 Untrusted AdminAppli

FDP_UIT.1/LOG Data exchange integrity


Hierarchical to: No other component
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]

FDP_UIT.1.1/LOG The TSF shall enforce the Admin access control SFP to be able to
transmit user data in a manner protected from modification, deletion,
insertion, replay errors.
FDP_UIT.1.2/LOG The TSF shall be able to determine on receipt of user data, whether
modification, deletion, insertion, replay errors has occurred.

Application note: The user data considered here is the log of Holder authentication failures.

FTP_ITC.1/AdminAppli Inter-TSF trusted channel


Hierarchical to: No other component
Dependencies: No dependencies

FTP_ITC.1.1/ The TSF shall provide a communication channel between itself and
AdminAppli 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_ITC1.2/ The TSF shall permit another trusted IT product to initiate communication
AdminAppli via the trusted channel.

FTP_ITC1.3/ The TSF shall initiate communication via the trusted channel for:
AdminAppli • Authentication with Admin_VAD
• Export of LOG
• Import of Authentication Protocol sensitive data
10.4 Security assurance requirements

The assurance requirements associated with the EAL selected for this PP are not described below (as they
are described in ISO/IEC 15408-3).

The security assurance requirement level is EAL4. The EAL is augmented with ALC_DVS.2 and AVA_VAN.5.

68
BS EN 419251-3:2013
EN 419251-3:2013 (E)

10.5 SFR / Security objectives

Color code:

This rationaIe uses colors to indidicate the groups to which the threats, policies, assumptions, objectives and
requirements come from.

Core group: Yellow; KeyImp group: Green; KeyGen group: Blue; Admin group: Violet;
All Trusted/Untrusted groups: Orange

Table 26 — SFR vs Security objectives retionale

OT. AUTHENTICATION_PRIVATE_KEY_IMPORT
Objectives

OT.UNTRUSTED_PERSONALIZATION_APPLI
OT.AUTHENTICATION_KEYS_GENERATION

OT.UNTRUSTED_AUTHENTICATION_APPLI

OT.UNTRUSTED_ADMINISTRATION_APPLI
OT.RESET_HODER_RAD_COUNTER
OT.DEVICE_AUTHENTICATION

vs

OT.UNTRUSTED_VERIFIER
OT.UNTRUSTED_CA
OT.PROTECTIONS
OT.HOLDER_RAD

OT.AUTH_ADMIN
OT.AUTH_USER

OT.ADMIN_RAD

SFR
OT.LOG

FCS_COP.1/Signature X
FCS_CKM.4/Priv_key X X
FIA_ATD.1 X X
FIA_UAU.1 X X
FIA_USB.1/Device X
FIA_AFL.1/Holder X
FDP_ACC.1/Core X X X
FDP_ACF.1/Core X X X
FDP_RIP.1 X
FDP_SDI.2 X
FMT_MSA.1/Core X X X X
FMT_MSA.2 X X X X X X X
FMT_MSA.3/Core X X X X X
FMT_MSA.4/Core X X X X
FMT_MTD.1/Core X X
FMT_SMR.1/Core X X X X
FMT_SMF.1/Core X
FPT_FLS.1 X
FPT_PHP.1 X
FPT_PHP.3 X
FPT_TST.1 X
FDP_ACC.1/KeyImp X

69
BS EN 419251-3:2013
EN 419251-3:2013 (E)

OT. AUTHENTICATION_PRIVATE_KEY_IMPORT
Objectives

OT.UNTRUSTED_PERSONALIZATION_APPLI
OT.AUTHENTICATION_KEYS_GENERATION

OT.UNTRUSTED_AUTHENTICATION_APPLI

OT.UNTRUSTED_ADMINISTRATION_APPLI
OT.RESET_HODER_RAD_COUNTER
OT.DEVICE_AUTHENTICATION
vs

OT.UNTRUSTED_VERIFIER
OT.UNTRUSTED_CA
OT.PROTECTIONS
OT.HOLDER_RAD

OT.AUTH_ADMIN
OT.AUTH_USER

OT.ADMIN_RAD
SFR

OT.LOG
FDP_ACF.1/KeyImp X
FDP_ITC.1/Priv_key X
FDP_UCT.1/Priv_key X
FDP_UIT.1/Priv_key X
FMT_MSA.1/KeyImp X
FMT_MSA.4/KeyImp X
FTP_ITC/ Priv_key X
FCS_CKM.1/Key_pair X
FCS_RNG.1 X
FDP_ACC.1/KeyGen X
FDP_ACF.1/KeyGen X
FMT_MSA.1/KeyGen X
FMT_MSA.3/KeyGen X
FMT_MSA.4/KeyGen X
FAU_GEN.1 X
FDP_ACC.1/Admin X X X X
FDP_ACF.1/Admin X X X X
FIA_AFL.1/Admin X
FIA_USB.1/Admin X X
FMT_MSA.1 Admin X
FMT_MSA.3 Admin X
FMT_MSA.4 Admin X
FMT_MTD.1 Admin X
FMT_SMR.1/Admin X
FMT_SMF.1/Admin X X
FTP_ITC.1/PersoAppli X
FTP_ITC.1/AuthAppli X
FTP_ITC.1/Verifier X
FDP_UIT.1/Pub_key X X
FTP_ITC1/CA X X
FDP_UIT.1/LOG X X
FTP_ITC1/AdminAppli X X X

70
BS EN 419251-3:2013
EN 419251-3:2013 (E)

OT.DEVICE_AUTHENTICATION This objective ensures the authentication mechanism itself. It is is covered


by:
FCS_COP.1/Signature, which signs a message, received from the Verifier, using APrK, and by this means,
authenticates the card to the Verifier,
FIA_USB.1/Device that sets the AT.Authenticated_device security attribute to Verifier,
FMT_MSA.1/Core that allows only the Holder to set the AT.Authenticated_device security attribute to Verifier,
FMT_MSA.2 that ensures that only secure values are accepted for AT.Authenticated_device,
FMT_MSA.3/Core that ensures that the default values for Authenticated_ device is "None",
FMT_MSA.4/Core, which sets the rules for modifying the "Authenticated_device" security attribute, and
FMT_MTD.1/Core, which allows the Holder and the Administrator to modify APSD.

OT.AUTH_USER This objective ensures the authentication of the holder or the issuer to the TOE. It is
covered by:
FIA_ATD.1, which allows the creation of an authentication chain,
FIA_UAU.1, which ensures the authentication of the User,
FIA_AFL.1/Holder, which limis the number of authentication attemps,
FDP_ACC.1/Core and
FDP_ACF.1/Core, which only allows the access to the RAD to the subject that performs the authentication of
the User to the TOE and prevents access to sensitive data by unauthorised users,
FMT_MSA.1/Core that allows only the Issuer or the Holder to modify the AT.Authenticated_user,
FMT_MSA.2 that ensures that only secure values are accepted for AT.Authenticated_user,
FMT_MSA.3/Core that ensures that the default values for AT.Authenticated_user is "None",
FMT_MSA.4/Core, which control the "AT.Authenticated_user" security attribute,
FMT_SMR.1/Core, which maintains the roles Issuer and Holder,
FPT_FLS.1, which deals with the protection of User authentication to the TOE, and
FIA_USB.1/Admin, which binds the authenticated user to the Holder or the Admin role.

OT.PROTECTIONS This objective protects sensitive data on TOE against unauthorised modification and
disclosure. It is covered by:
FDP_ACC.1/Core and
FDP_ACF.1/Core, which prevents access to sensitive data by unauthorised users,
FDP_RIP.1, which participate to the confidentiality of sensitive stored data,
FDP_SDI.1, which ensures the integrity of sensitive stored data,
FMT_MSA.1/Core, that restricts the modification of security attributes to authorised roles,
FMT_MSA.2 that ensures that only secure values are accepted for security attributes,
FMT_MSA.3/Core that ensures that default values for security attributes are used,
FMT_MSA.4/Core, which controls the setting of the security attributes,
FPT_PHP.1, which detects attacks against the TOE,
FPT_PHP.3, which protects the TOE against attacks, and
FPT_TST.1, which tests the physical integrity of the TOE.

71
BS EN 419251-3:2013
EN 419251-3:2013 (E)

OT.HOLDER_RAD controls the import of the Holder RAD. It is covered by:


FDP_ACC.1/Core and
FDP_ACF.1/Core, which define the access control rules to import, modify, and replace the Holder RAD,
FMT_MSA.1/Core that restricts the modification of the "AT.Holder_only" and "AT.Authenticated_user" security
attributes to the Holder,
FMT_MSA.2 that ensures that only secure values are accepted for security attributes,
FMT_MSA.3/Core that provides "No" and "None" as default values for the "Holder_only" and
"Authenticated_user" security attributes,
FMT_MSA.4/Core, which controls the setting of the "AT.Holder_only" and "AT.Authenticated_user" security
attributes,
FMT_MTD.1/Core, which allows the import of the Holder RAD.
FMT_SMR.1/Core, which maintains the roles Issuer and Holder, and
FMT_SMF.1/Core, which allows the import of the Holder RAD.

OT.AUTHENTICATION_PRIVATE_KEY_IMPORT controls the import of APrK. This objective is covered by:


FCS_CKM.4/Priv_key, which controls the deletetion of APrK,
FMT_SMR.1/Core, which maintains the roles Issuer and Holder,
FDP_ACC.1/KeyImp and
FDP_ACF.1/KeyImp, which define the access control rules to import APrK,
FMT_MSA.1/KeyImp that restricts the modification of the "AT.Operational" and "AT.Consistency_pub_key"
security attributes to the Holder or the Issuer,
FMT_MSA.2 that ensures that only secure values are accepted for the "AT.Operational" and
"AT.Consistency_pub_key" security attributes,
FMT_MSA.3/Core, that provides "No" default value for the "AT.Operational" and
"AT.Consistency_pub_key"security attributes,
FMT_MSA.4/KeyImp, which control the "AT.operational" security attribute of APrK,
FDP_ITC/ Priv_key, which protects the integrity of APrK when it imported into the TOE,
FDP_UCT.1/Priv_key, which protects the confidentiality of APrK when it imported into the TOE,
FDP_UIT.1/Priv_key, which protects the integrity of APrK when it imported into the TOE, and
FTP_ITC/ Priv_key, which protect the integrity and the confidentiality of APrK when it imported into the TOE.

OT.AUTHENTICATION_KEYS_GENERATION controls the on TOE generation of APrK/APuK. This objective


is covered by:
FCS_CKM.4/Priv_key, which controls the deletetion of APrK,
FMT_SMR.1/Core, which maintains the roles Issuer and Holder,
FCS_CKM.1/Key_Pair, which generates the authentication key pair,
FCS_RNG.1/KeyGen, which generates randoms according to [CRYPTO],
FDP_ACC.1/KeyGen and
FDP_ACF.1/KeyGen, which define the access control rules to generate APrK/APuK,
FMT_MSA.1/KeyGen that restricts the modification of the "AT.Consistency_Pub_Key" and "AT.Operational"
security attributes to the Holder or the Issuer,

72
BS EN 419251-3:2013
EN 419251-3:2013 (E)

FMT_MSA.2 that ensures that only secure values are accepted for the "AT.Consistency_Pub_Key" and
"AT.Operational"security attributes,
FMT_MSA.3/KeyGen that provides "No" default value for the "AT.Consistency_pub_key" security attribute,
FMT_MSA.4/KeyGen, which control the"operational" security attribute of APrK,
FDP_UIT.1/Pub_key and
FTP_ITC.1/CA, which protect the integrity of the Public key when it is exported to the CA.

OT.AUTH_ADMIN ensures the authentication of the administrator to the TOE.This objective is covered by
FIA_ATD.1, which allows the creation of an authentication chain.
FIA_UAU.1, which ensures the authentication of the User,
FDP_ACC.1/Admin and
FDP_ACF.1/Admin, which define the access control rules to import the Administrator RAD,
FIA_AFL.1/Admin, which limis the number of authentication attemps
FIA_USB.1/Admin, which binds the authenticated user to the Holder or the Admin role,
FMT_SMR.1/Admin, which ensures the role Admin

OT.ADMIN_RAD controls the import of the Administrator RAD. It is covered by:


FDP_ACC.1/Admin and
FDP_ACF.1/Admin, which define the access control rules to reset the Holder RAD retry counter,
FMT_MTD.1/Admin, and
FMT_SMF.1/Admin which allow the Admin to update its RAD,
FTP_ITC.1/AdminAppli, which protects the integrity and the confidentiality of the Administrator RAD during its
import.

OT.LOG This objective controls the generation and export of a log file. It is covered by:
FAU_GEN.1, which generates a log
FDP_ACC.1/Admin and
FDP_ACF.1/Admin, which define the access control rules to reset the Holder RAD retry counter,
FDP_UIT.1/Log and
FTP_ITC.1/AdminAppli, which protects the integrity of the log during its export.

OT.RESET_HOLDER_RAD_COUNTER controls the reset of the Holder RAD retry counter. It is covered by:
FDP_ACC.1/Admin and
FDP_ACF.1/Admin, which define the access control rules to reset the Holder RAD retry counter,
FMT_MSA.1/Admin, which restricts to the Administrator, the ability to set the RAD value of the Holder to its
default value, to reset the retry counter of the Holder RAD, and to increment the reset counter of the Holder
RAD.
FMT_MSA.2 that ensures that only secure values are accepted for security attributes,
FMT_MSA.3/Admin, that provides "0", as default value for the "AT.RAD_reset_counter[Holder_RAD]" security
attribute
FMT_MSA.4/Admin which control the security attributes linked to the Administrator.

73
BS EN 419251-3:2013
EN 419251-3:2013 (E)

OT.UNTRUSTED_PERSONALIZATION_APPLI controls the transfer of sensitive data with the


Personalisation Application. This objective is covered by:
FTP_ITC.1/PersoAppli deals with the confidentiality and integrity of transferred data between the TOE and the
Personalisation application.

OT.UNTRUSTED_AUTHENTICATION_APPLI controls the transfer of sensitive data with the Authentication


Application.This objective is covered by:
FTP_ITC.1/AuthAppli deals with the confidentiality and integrity of transferred data between the TOE and the
Authentication application.

OT.UNTRUSTED_VERIFIER controls the transfer of sensitive data with the Verifier.This objective is covered
by:
FTP_ITC.1/Verifier deals with the confidentiality and integrity of transferred data between the TOE and the
Verifier for the purpose of authentifying the TOE.

OT.UNTRUSTED_CA controls the transfer of sensitive data with the CA. This objective is covered by:
FDP_UIT.1/Pub_key, and
FTP_ITC.1/CA, which protects the integrity of APuK when it is exported to the CA.

OT.UNTRUSTED_ADMINISTRATION_APPLI controls the transfer of sensitive data with the Administration


Application. This objective is covered by
FDP_UIT.1/Log, which protects the integrity of the export of LOG and
FTP_ITC.1/AdminAppli, which protects: the integrity of the export of LOG; the integrity of the import
Authentication Protocol sensitive data; the confidentiality and integrity of the import of the Admin VAD.

10.6 SFR Dependencies

Table 27 — SFR dependencies


SFR Dependencies Satisfied dependencies
FCS_COP.1/Signature [FDP_ITC.1, or FDP_ITC.2, or FDP_ITC.1/Priv_key
FCS_CKM.1], FCS_CKM.1/Key_Pair
FCS_CKM.4, FCS_CKM.4/Priv_key
FMT_MSA.2 FMT_MSA.2
FCS_CKM.4/Priv_key [FDP_ITC.1, or FDP_ITC.2, or FDP_ITC.1/Priv_key
FCS_CKM.1/Key_Pair
FCS_CKM.1],
FMT_MSA.2
FMT_MSA.2
FIA_ATD.1 None
FIA_USB.1/Device FIA_ATD.1 FIA_ATD.1
FIA_UAU.1 FIA_UID.1
FIA_USB.1/User FIA_ATD.1 FIA_ATD.1
FIA_AFL.1/Holder FIA_UAU.1 FIA_UAU.1
FDP_ACC.1/Core FDP_ACF.1 FDP_ACF.1/Core
FDP_ACF.1/Core FDP_ACC.1, FDP_ACC.1/Core
FMT_MSA.3 FMT_MSA.3/Core
FDP_RIP.1 None

74
BS EN 419251-3:2013
EN 419251-3:2013 (E)

SFR Dependencies Satisfied dependencies


FDP_SDI.2 None
FMT_MSA.1/Core [FDP_ACC.1, or FDP_IFC.1l] FDP_ACC.1/Core
FMT_SMR.1, FMT_SMR.1/Core
FMT_SMF.1 FMT_SMF.1/Core
FMT_MSA.2 [FDP_ACC.1, or FDP_IFC.1] FDP_ACC.1/Core
FMT_MSA.1, FMT_MSA.1/Core
FMT_SMR.1 FMT_SMR.1/Core
FMT_MSA.3/Core FMT_MSA.1, FMT_MSA.1/Core
FMT_SMR.1 FMT_SMR.1/Core
FMT_MSA.4/Core [FDP_ACC.1, or FDP_IFC.1l] FDP_ACC.1/Core
FMT_MTD.1/Core FMT_SMR.1, FMT_SMR.1/Core
FMT_SMF.1 FMT_SMF.1/Core
FMT_SMR.1/Core FIA_UID.1
FMT_SMF.1/Core None
FPT_FLS.1 None
FPT_PHP.1 None
FPT_PHP.3 None
FPT_TST.1 FPT_AMT.1
FDP_ACC.1/KeyImp FDP_ACF.1 FDP_ACF.1/KeyImp
FDP_ACF.1/KeyImp FDP_ACC.1, FDP_ACC.1/KeyImp
FMT_MSA.3 FMT_MSA.3/Core
FDP_ITC.1/Priv_key [FDP_ACC.1, or FDP_IFC.1], FDP_ACC.1/KeyImp
FMT_MSA.3 FMT_MSA.3/Core
FDP_UCT.1/Priv_key [FDP_ACC.1, or FDP_IFC.1], FDP_ACC.1/KeyImp
[FTP_ITC.1, or FTP_TRP.1] FTP_ITC/ Priv_key
FDP_UIT.1/Priv_key [FDP_ACC.1, or FDP_IFC.1], FDP_ACC.1/KeyImp
[FTP_ITC.1, or FTP_TRP.1] FTP_ITC/ Priv_key
FMT_MSA.1/KeyImp [FDP_ACC.1, or FDP_IFC.1l] FDP_ACC.1/KeyImp
FMT_SMR.1, FMT_SMR.1/Core
FMT_SMF.1 FMT_SMF.1/Core
FMT_MSA.4/KeyImp [FDP_ACC.1, or FDP_IFC.1l FDP_ACC.1/KeyImp
FTP_ITC/ Priv_key None
FCS_CKM.1/Key_pair [FCS_CKM.2, or FCS_COP.1], FCS_COP.1/Signature
FCS_CKM.4, FCS_CKM.4/Priv_key
FMT_MSA.2 FMT_MSA.2
FCS_RNG.1/KeyGen None
FDP_ACC.1/KeyGen FDP_ACF.1 FDP_ACF.1/KeyGen
FDP_ACF.1/KeyGen FDP_ACC.1, FMT_MSA.3 FDP_ACC.1/KeyGen
FMT_MSA.3/KeyGen
FMT_MSA.1/KeyGen [FDP_ACC.1, or FDP_IFC.1l] FDP_ACF.1/KeyGen
FMT_SMR.1, FMT_SMR.1/Core
FMT_SMF.1 FMT_SMF.1/Core
FMT_MSA.3/KeyGen FMT_MSA.1, FMT_MSA.1/KeyGen
FMT_SMR.1 FMT_SMR.1/Core
FMT_MSA.4/KeyGen [FDP_ACC.1, or FDP_IFC.1l] FDP_ACF.1/KeyGen
FAU_GEN.1 FPT_STM.1
FDP_ACC.1/Admin FDP_ACF.1 FDP_ACF.1/Admin
FDP_ACF.1/Admin FDP_ACC.1, FDP_ACC.1/Admin

75
BS EN 419251-3:2013
EN 419251-3:2013 (E)

SFR Dependencies Satisfied dependencies


FMT_MSA.3 FMT_MSA.3/Admin
FIA_AFL.1/Admin FIA_UAU.1 FIA_UAU.1
FIA_USB.1/Admin FIA_ATD.1 FIA_ATD.1
FMT_MSA.1/Admin [FDP_ACC.1, or FDP_IFC.1l] FDP_ACC.1/Admin
FMT_SMR.1, FMT_SMR.1/Admin
FMT_SMF.1 FMT_SMF.1/Admin
FMT_MSA.3/Admin FMT_MSA.1, FDP_ACF.1/Admin
FMT_SMR.1 FMT_SMR.1/Admin
FMT_MSA.4/ Admin [FDP_ACC.1, or FDP_IFC.1l] FDP_ACC.1/Admin
FMT_MTD.1/Admin FMT_SMR.1, FMT_SMR.1/Admin
FMT_SMF.1 FMT_SMF.1/Admin
FMT_SMR.1/Admin FIA_UID.1
FMT_SMF.1/Admin None
FTP_ITC.1/PersoAppli None
FTP_ITC.1/AuthAppli None
FTP_ITC.1/Verifier None
FDP_UIT.1/Pub_key [FDP_ACC.1, or FDP_IFC.1], FDP_ACC.1/KeyGen
[FTP_ITC.1, or FTP_TRP.1] FTP_ITC.1/CA
FTP_ITC.1/CA None
FDP_UIT.1/LOG [FDP_ACC.1, or FDP_IFC.1], FDP_ACC.1/Admin
[FTP_ITC.1, or FTP_TRP.1] FTP_ITC.1/AdminAppli
FTP_ITC.1/AdminAppli None

The dependency FIA_UID.1 of FMT_SMR.1 is not supported; Identification is not required for the TOE.
The dependency FPT_STM.1 of FAU_GEN.1 is not supported. The TOE does not have the time feature.
The dependency FPT_AMT.1 of FPT_TST.1 is not supported. The TOE does not have an underlying abstract
machine.

10.7 Rationale for the Assurance Requirements

EAL.4 methodically designed, tested, and reviewed


EAL4 is required for this type of TOE and product since it is intended to defend against sophisticated attacks.
This evaluation assurance level allows a developer to gain maximum assurance from positive security
engineering based on good practices. EAL4 represents the highest practical level of assurance expected for a
commercial grade product. In order to provide a meaningful level of assurance that the TOE and its
embedding product provide an adequate level of defense against such attacks, the evaluators should have
access to the low level design and source code. The lowest for which such access is required is EAL4.
AVA_VAN.5 Advanced methodical vulnerability analysis
Due to the definition of the TOE and of the embedding the product, the product shall resist to high attack
potential. This is due to the fact that the product (Smart Card or similar device) can be placed in a hostile
environment, such as electronic laboratories. This robusteness level is achieved by the assurance
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 with ADV_ARC.1,
ADV_FSP.1, ADV_TDS.3, ADV_IMP.1, AGD_PRE.1, AGD_OPE.1. All these dependencies are satisfied by
EAL4.
ALC_DVS.2 Sufficiency of security measures
Development security is concerned with physical, procedural, personnel and other technical measures that
may be used in the development environment to protect the TOE and the embedding product. This assurance
component is a higher hierarchical component to EAL4 (only ALC_DVS.1 is found in EAL4). Due to the nature

76
BS EN 419251-3:2013
EN 419251-3:2013 (E)

of the TOE and embedding product, there is a need to justify the sufficiency of these procedures to protect
their confidentiality and integrity. ALC_DVS.2 has no dependencies.

77
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Bibliography

[1] EN 419251-1:2013, Security requirements for device for authentication — Part 1: Protection profile for
core functionality

[2] EN 419251-2:2013, Security requirements for device for authentication — Part 2: Protection profile for
extension for trusted channel to certificate generation application

[3] prEN 14169-2:2010, Protection Profile for Secure signature creation device — Part 2: Device with key
generation

[4] prEN 14169-3:2010, Protection profiles for secure signature creation device — Part 3: Device with key
import

[5] prEN 14169-4:2010, Protection profiles for secure signature creation device — Part 4: Extension for
device with key generation and trusted communication with certificate generation application

[6] prEN 14169-5:2010, Protection profiles for secure signature creation device — Part 5: Device with key
generation and trusted communication with signature-creation application

[7] prEN 14169-6:2010, Protection profiles for secure signature creation device — Part 6: Device with key
import and trusted communication with signature-creation application

[8] DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of


13 December 1999 on a Community framework for electronic signatures

78
BS EN 419251-3:2013
EN 419251-3:2013 (E)

Index

—A— —P—

Administrator, 7 PP collection, 8
Authentication Protocol sensitive data, 7 Protection Profile, 8

—C— —R—

Certificate, 7 Reference Authentication Data, 8


Certificate Info, 7
Configuration, 7
—T—

—G— Trusted channel, 8


Trusted Environment, 8
Group, 7

—U—
—H—
Untrusted Environment, 8
Holder, 7 User, 8

—I— —V—

Issuer, 8 Verification Authentication Data, 9


Verifier, 8

79
This page deliberately left blank
This page deliberately left blank
NO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAW

British Standards Institution (BSI)


BSI is the national body responsible for preparing British Standards and other
standards-related publications, information and services.
BSI is incorporated by Royal Charter. British Standards and other standardization
products are published by BSI Standards Limited.

About us Revisions
We bring together business, industry, government, consumers, innovators Our British Standards and other publications are updated by amendment or revision.
and others to shape their combined experience and expertise into standards We continually improve the quality of our products and services to benefit your
-based solutions. business. If you find an inaccuracy or ambiguity within a British Standard or other
The knowledge embodied in our standards has been carefully assembled in BSI publication please inform the Knowledge Centre.
a dependable format and refined through our open consultation process.
Organizations of all sizes and across all sectors choose standards to help Copyright
them achieve their goals. All the data, software and documentation set out in all British Standards and
other BSI publications are the property of and copyrighted by BSI, or some person
Information on standards or entity that owns copyright in the information used (such as the international
We can provide you with the knowledge that your organization needs standardization bodies) and has formally licensed such information to BSI for
to succeed. Find out more about British Standards by visiting our website at commercial publication and use. Except as permitted under the Copyright, Designs
bsigroup.com/standards or contacting our Customer Services team or and Patents Act 1988 no extract may be reproduced, stored in a retrieval system
Knowledge Centre. or transmitted in any form or by any means – electronic, photocopying, recording
or otherwise – without prior written permission from BSI. Details and advice can
Buying standards be obtained from the Copyright & Licensing Department.
You can buy and download PDF versions of BSI publications, including British
and adopted European and international standards, through our website at Useful Contacts:
bsigroup.com/shop, where hard copies can also be purchased. Customer Services
If you need international and foreign standards from other Standards Development Tel: +44 845 086 9001
Organizations, hard copies can be ordered from our Customer Services team. Email (orders): orders@bsigroup.com
Email (enquiries): cservices@bsigroup.com
Subscriptions
Subscriptions
Our range of subscription services are designed to make using standards
Tel: +44 845 086 9001
easier for you. For further information on our subscription products go to
Email: subscriptions@bsigroup.com
bsigroup.com/subscriptions.
With British Standards Online (BSOL) you’ll have instant access to over 55,000 Knowledge Centre
British and adopted European and international standards from your desktop. Tel: +44 20 8996 7004
It’s available 24/7 and is refreshed daily so you’ll always be up to date. Email: knowledgecentre@bsigroup.com
You can keep in touch with standards developments and receive substantial
Copyright & Licensing
discounts on the purchase price of standards, both in single copy and subscription
format, by becoming a BSI Subscribing Member. Tel: +44 20 8996 7070
Email: copyright@bsigroup.com
PLUS is an updating service exclusive to BSI Subscribing Members. You will
automatically receive the latest hard copy of your standards when they’re
revised or replaced.
To find out more about becoming a BSI Subscribing Member and the benefits
of membership, please visit bsigroup.com/shop.
With a Multi-User Network Licence (MUNL) you are able to host standards
publications on your intranet. Licences can cover as few or as many users as you
wish. With updates supplied as soon as they’re available, you can be sure your
documentation is current. For further information, email bsmusales@bsigroup.com.

BSI Group Headquarters


389 Chiswick High Road London W4 4AL UK