GCC C1
urity Target Lite
Version 2.5
R&DSTARCOS 3.5 ID
Sec
Author stut
Status Fina
Rating
l
Public
Edition 14.12.2010
Giesecke & Devrient GmbH
Prinzregentenstraße 159
Postfach 80 07 29
D-81607 München
is copyrighted. Any use not
ient GmbH. This
y reproduction, revision, translation, storage on microfilm as well as its import and
processing in electronic systems, in particular.
The information or material contained in this document is property of Giesecke & Devrient GmbH
and any recipient of this document shall not disclose or divulge, directly or indirectly, this
document or the information or material contained herein without the prior written consent of
Giesecke & Devrient GmbH.
All copyrights, trademarks, patents and other rights in connection herewith are expressly reserved
to the Giesecke & Devrient group of companies and no license is created hereby.
All brand or product names mentioned are trademarks or registered trademarks of their respective
holders.
© Copyright 2010
Giesecke & Devrient GmbH
Prinzregentenstraße 159
Postfach 80 07 29
D-81607 München
This document as well as the information or material contained
explicitly permitted by copyright law requires prior consent of Giesecke & Devr
applies to an
Contents
Security Target Lite STARCOS 3.5 ID GCC C1 Page 3 of 128
Version 2.5 14.12.2010
Contents
......................... 1
......................... 1
................ ....... 1
Contents .. 3
1 T ................ ....... 7
1.1 T ...................7
1. O ................................7
...8
................................8
1.2.3 TOE major security features for operational use.....................................................................9
......10
..............................11
2 ....................... 14
2. ..............................14
2. ..............................14
2. a ..............................14
2. ..................... ........15
3 Se ................ ..... 16
3. n ..............................16
. ..................... ........16
. .................... .......19
3. h ..............................24
. n..........................24
OE and a rightful
terminal ..............................................................................................................................24
3.2.3 T.ID_Card_Tracing Tracing ID_Card...................................................................................24
3.2.4 T.Counterfeit Counterfeiting ID_Card ...............................................................................24
3.2.5 T.Forgery Forgery of Data..................................................................................................25
3.2.6 T.Abuse-Func Abuse of Functionality.................................................................................25
3.2.7 T.Information_Leakage Information Leakage from ID_Card...............................................25
3.2.8 T.Phys-Tamper Physical Tampering....................................................................................25
3.2.9 T.Malfunction Malfunction due to Environmental Stress.....................................................26
3.3 Organisational Security Policies.....................................................................................................27
STARCOS 3.5 ID GCC C1 ........................................................................
Security Target Lite...............................................................................
Version 2.5............................................................................................. ..
.......................................................................................................................
S Introduction ......................................................................... .. ..
.
...
....
...
...
....
...
...
...
...
1 I troduction ......................................................................................................
...
...
...
ca
he
S Reference...................................................................................................................
2 T E Overview............................................................................................... ..
1.2.1 Sections Overview..............................................................................................................
1.2.2 TOE definition and operational usage.............................................. ..
1.2.4 TOE type .......................................................................................................................
1.2.5 Non-TOE hardware/software/firmware............................................. ..
Conformance Claim ................................................................ ..
1 CC Conformance Claim............................................................................... ..
2 PP Claim........................................................................................................ ..
3 P ckage Claim.............................................................................................. ..
4 Conformance Claim Rationale.................................................................... .. .
curity Problem Definition................................................... .. ..
3 1.1 Assets .............................................................................................. .. .
3 1.2 Subjects and external entities ........................................................... .. ...
2 T reats.......................................................................................................... ..
3 2.1 T.Skimming Skimming ID_Card / capturing card-terminal communi tio
3.2.2 T.Eavesdropping Eavesdropping on the communication between t T
Contents
Page 4 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
3.3.1 P.Pre-Operational Pre-operational handling of the ID_Card................ . ...
....
h)
....
...
....
....
....
....
....
....
....
....
....
....
...
...
....
....
....
...
....
.................... .... 27
27
28
3.3.4 P.Trustworthy_PKI Trustworthiness of PKI........................................................................... 29
29
........................... 31
4 ................ .. 32
4.1 cu 32
.................... .... 32
.................... .... 32
..................... .... 32
.................... .... 33
.................... .... 33
33
33
.................... .... 34
..................... .... 34
.................... .... 34
4.1.11 OT.Personalisation Personalisation of ID_Card .................................................................... 34
........................... 36
I. ID r ................ .. 36
4.2.1 OE.Legislative_Compliance ................................................................................................. 36
II. I r ................ .. 36
4.2.2 OE.Passive_Auth_Sign Authentication of ID_Card by Signature .......................................... 36
........................... 37
.................... .... 37
III. ID_Card Issuer and CVCA: Terminal’s PKI (receiving) branch ............................... 37
37
........................... 38
IV. a ................. ... 39
........................... 39
4.3 Security Objective Rationale ......................................................................................................... 41
5 Extended Components Definition..................................................................... 45
5.1 Definition of the Family FAU_SAS ................................................................................................ 45
5.2 Definition of the Family FCS_RND ................................................................................................ 45
5.2.1 FCS_RND Generation of random numbers.......................................................................... 46
5.3 Definition of the Family FIA_API................................................................................................... 46
3.3.2 P.ID_Card_PKI PKI for Chip and Passive Authentication (issuing branc ............................
3.3.3 P.Terminal_PKI PKI for Terminal Authentication (receiving branch).....................................
3.3.5 P.Terminal Abilities and trustworthiness of rightful terminals.............................................
3.4 Assumptions ................................................................................................... .
Security Objectives .................................................................... . ...
Se rity Objectives for the TOE.....................................................................................................
4.1.1 OT.Data_Integrity Integrity of Data ..................................................... . ...
4.1.2 OT.Data_Authenticity Authenticity of Data......................................... ...
.
..
4.1.3 OT.Data_Confidentiality Confidentiality of Data ................................. .
4.1.4 OT.ID_Card_Tracing Tracing ID_Card.................................................. . ...
4.1.5 OT.Chip_Auth_Proof Proof of ID_Card authenticity ............................ . ...
4.1.6 OT.Prot_Abuse-Func Protection against Abuse of Functionality........... ............................
4.1.7 OT.Prot_Inf_Leak Protection against Information Leakage ..................................................
4.1.8 OT.Prot_Phys-Tamper Protection against Physical Tampering.............. . ...
4.1.9 OT.Prot_Malfunction Protection against Malfunctions ........................ . ..
4.1.10 OT.Identification Identification of the TOE .......................................... . ...
4.2 Security Objectives for Operational Environment....................................... .
_Ca d Issuer as the general responsible..................................... . ...
D_Ca d Issuer and CSCA: ID_Card’s PKI (issuing) branch ............. . ...
4.2.3 OE.Chip_Auth_Key Chip Authentication Key...................................... .
4.2.4 OE.Personalisation Personalisation of ID_Card .................................... . ...
4.2.5 OE.Terminal_Authentication Authentication of rightful terminals .......................................
4.2.6 OE.Terminal Terminal operating ......................................................... .
ID_C rd holder Obligations .......................................................... . .
4.2.7 OE.ID_Card-Holder ID_Card holder Obligations .................................. .
Contents
Security Target Lite STARCOS 3.5 ID GCC C1 Page 5 of 128
Version 2.5 14.12.2010
5.3.1 FIA_API Authentication Proof of Identity .......................................... .. ...
...
...
...
....
...
...
...
...
...
...
...
.....
.....
.....
.....
.....
.....
.....
....
.....
.....
.....
.....
.....
.................... .......46
5. e ..................... ........47
..............................47
5.5 Definition of the Family FPT_EMSEC.............................................................................................48
..............................48
6 e ................ ..... 50
6. e .................... .......50
. .................... .......50
. .................... .......54
60
. ..................... ........69
.................... .......76
6.1.6 Class FAU Security Audit .....................................................................................................78
78
. .................... .......90
6.2 Se 94
6. e .................... .......94
. .................... .......94
. .................... .......99
100
6. .................... .....101
. .................... .....101
. .................... .....102
. .................... .....108
7 O ................ ... 109
7. ............................109
............................109
. ................. ......110
110
110
............................110
............................110
7.2 Assurance Measures......................................................................................................................111
7.3 Fulfilment of the SFRs...................................................................................................................111
7.3.1 Justifications for the correspondence between functional requirements and TOE mechanisms114
8 Glossary and Acronyms..................................................................................... 115
8.1 Glossary .........................................................................................................................................115
8.2 Acronyms.......................................................................................................................................124
4 D finition of the Family FMT_LIM.............................................................. .. .
5.4.1 FMT_LIM Limited capabilities and availability.................................... ..
5.5.1 FPT_EMSEC TOE emanation ............................................................ ..
S curity Requirements............................................................ .. ..
1 S curity Functional Requirements for the TOE ......................................... .. ...
6 1.1 Overview.......................................................................................... .. ...
6 1.2 Class FCS Cryptographic Support..................................................... .. ...
6.1.3 Class FIA Identification and Authentication .........................................................................
6 1.4 Class FDP User Data Protection ........................................................ .. .
6.1.5 Class FTP Trusted Path/Channels ...................................................... .. ...
6.1.7 Class FMT Security Management.........................................................................................
6 1.8 Class FPT Protection of the Security Functions .................................. .. ...
curity Assurance Requirements for the TOE .............................................................................
3 S curity Requirements Rationale.............................................................. .. ...
6 3.1 Security Functional Requirements Rationale.................................... .. ...
6 3.2 Rationale for SFR’s Dependencies................................................... .. ...
6.3.3 Security Assurance Requirements Rationale.......................................................................
4 Statement of Compatibility ...................................................................... .. ...
6 4.1 Classification of Platform TSFs........................................................ .. ...
6 4.2 Matching statement....................................................................... .. ...
6 4.3 Overall no contracdictions found.................................................... .. ...
T E summary specification ................................................... .. ..
1 TOE Security Functions .............................................................................. ..
7.1.1 SF_AccessControl........................................................................... ..
7 1.2 SF_AssetProtection............................................................................. .. .
7.1.3 SF_TSFProtection...............................................................................................................
7.1.4 SF_KeyManagement .........................................................................................................
7.1.5 SF_SignatureGeneration................................................................. ..
7.1.6 SF_TrustedCommunication............................................................. ..
Contents
Page 6 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
9 Bibliography ............................................................................ . ...
.....
.....
.....
................ 126
1 ......................... 126
2 ......................... 126
127
9.4 Other Sources ............................................................................................................................... 127
9. Common Criteria........................................................................................... .
9. Protection Profiles......................................................................................... .
9.3 Technical Guidelines and Directives............................................................................................
1 ST Introduction
Security Target Lite STARCOS 3.5 ID GCC C1 Page 7 of 128
Version 2.5 14.12.2010
1 ST Introduction
1.1
Lite STARCOS 3.5 ID GCC C1
_GCC_ASE
er
the following assurance components:
.
TOE: STARCOS 3.5 ID GCC C1
Preparative procedures STARCOS 3.5 ID GCC C1
l user guidance STARCOS 3.5 ID GCC C1
-2010) [21]. This TOE was
against Common Criteria Version 3.1
1.2
describe the Security Target for STARCOS 3.5 ID GCC
STARCOS 3.5 ID GCC C1 stands for the Target of
In the following chapters, STARCOS 3.5 ID GCC C1 Card stands for the product.
 ePA application
 and depends on the secure NXP chip being certified according to CC EAL5+
[21]
 and uses the following ECC brainpool curve: P256r1, see chapter 1.3.2 [12].
STARCOS 3.5 ID GCC C1 consists of the related software in combination with the
underlying hardware ('Composite Evaluation').
The assurance level for the TOE is CC EAL4 augmented.
ST Reference
Title: Security Target
Reference: GDM_STA35
Version 2.5 Status 14.12.2010
Origin: Giesecke & Devrient GmbH
Author: Dr. Ulrich Stutenbäum
CC Version: 3.1 (Revision 3)
Assurance Level: EAL4-augmented with
AVA_VAN.5, ATE_DPT.2 und ALC_DVS.2
TOE documentation:
Operationa
HW-Part of TOE: NXP P5CD128 (Certificate: BSI-DSZ-CC-0645
evaluated
TOE Overview
The aim of this document is to
ing chapters
C1. In the follow
Evaluation (TOE).
The related product is the STARCOS 3.5 ID GCC C1 Card.
STARCOS 3.5 ID GCC C1 Card contains the TOE consisting of the:
 STARCOS 3.5 operating system
1 ST Introduction
Page 8 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
1.2.1
Security Target.
This section also
threats that are to be addressed by either the technical
both the TOE and the operational
al to explicitly demonstrate that the
threats. Arguments
e requirements
n Criteria [1], Part 2 [2] and Part 3 [3], which must be satisfied
s rational. The section then explains how the set
security objective
quirements. Arguments are provided for the
the used references.
1.2.2
ofile is electronic
mmed according to
ing applications:
Passport1
containing the related user data2
(incl. biometric) as well as
n is intended to be
e travel document
d for authentication;
commercial
services, which require access to the user data stored in the context of this
application;
5
containing data needed for generating advanced or qualified
igital) signatures on behalf of the ID_Card holder as
well as for authentication; this application is intended to be used in the
context of official and commercial services, where an advanced or qualified
digital signature of the ID_Card holder is required. The eSign application is
optional: it means that it can optionally be activated on the ID_Card by a
Certification Service Provider (or on his behalf).
Sections Overview
Section 1 provides the introductory material for the
Section 2 provides the conformance claims for the Security Target.
Section 3 provides a discussion of the security problems for the TOE.
defines the set of
countermeasures implemented in the TOE hardware, the TOE software, or through the
environmental controls.
Section 4 defines the security objectives for
environment and the security objective ration
information technology security objectives satisfy the policies and
are provided for the cove ge of e policy and threat.
Section 5 contains the extended component definitions.
Section 6 contains the security functional requirements and assuranc
derived from the Commo
ra ach
and the security functional requirement
of requirements are complete relative to the objectives, and that each
is addressed by one or more component re
coverage of each objective.
Section 7 contains the TOE Summary Specification.
Section 8 provides information on used acronyms and glossary and
TOE definition and operational usage
The Target of Evaluation (TOE) addressed by the current protection pr
Identity Card (ID_Card) representing a contactless smart card progra
BSI TR-03110, version 2.01 [11]. This smart card provides the follow
 the e
data needed for authentication (incl. MRZ); this applicatio
used by authorities, amongst other as a machine readabl
(MRTD);
 the eID3
including the related user data4
and data neede
this application is intended to be used for accessing official and
 the eSign
electronic (concretely: d
1
as specified in [11], sec. 3.1.1; see also [8], [9].
2
according to [11], sec. 1.1 and 3.1.1; see also chap. 7 below for definitions
3
as specified in [11] sec. 3.1.2
4
as specified in [11], sec. 3.1.2
5
as specified in [[11] sec. 3.1.3
1 ST Introduction
Security Target Lite STARCOS 3.5 ID GCC C1 Page 9 of 128
Version 2.5 14.12.2010
For the ePassport application, the ID_Card holder can control access to his user data by
ata by
ard to authorities7
.
ID_Card holder can control access to the digital signature
e provider and inputting his
r represents a
cret PIN. In order to
t, the eID and the eSign applications shall organisationally get
eSign-PIN). It is
ll be generated by
art of the Identity Card,
able
lastic, optically readable cover of the Identity Card, where the
tying-up of the
achieved by physical and
t of scope of the current ST.
ware9
being active
, IC),
system)10
,
tenna) may have
us, be security
E.
1.2.3 TOE major security features for operational use
E security features are the most significant for its operational u
terminals can get access to the user data stored on the TO nd
of the ID_Card under control of the ID_Card holder,
integrity as well as securing confidentiality of user data12
in
ervice provider
on of digital signatures, if the eSign application is operational,
conscious presenting his ID_Card to authorities6
.
For the eID application, the ID_Card holder can control access to his user d
inputting his secret PIN (eID-PIN) or by conscious presenting his ID_C
For the eSign application, the
functionality by conscious presenting his ID_Card to a servic
secret PIN for this application: eSign-PIN8
.
Application Note 1: Using a secret PIN by the PIN’s owne
manifestation of his declaration of intent bound to this se
reflect this fac
different values of the respective secret PINs (eID-PIN and
especially important, if qualified electronic signatures sha
the eSign application.
The ID_Card is integrated into a plastic, optically readable p
which – as the final product – shall supersede the existing, merely optically read
Identity Cards. The p
electronic Identity Card is embedded in, is not part of the TOE. The
electronic Identity Card to the plastic Identity Card is
organisational security measures being ou
The TOE shall comprise at least
a) the circuitry of the contactless chip incl. all IC dedicated soft
in the operational phase of the TOE (the integrated circuit
b) the IC Embedded Software (operating
c) the ePassport, the eID and, optionally11
, the eSign applications and
d) the associated guidance documentation.
Application Note 2: Since contactless interface parts (e.g. an
impact on specific aspects of vulnerability assessment and, th
relevant, these parts are considered as part of the TO
The following TO se:
Only auth ticated
en E a
use security functionality
Verifying authenticity and
the communication channel between the TOE and the s
connected ,
Creati
13
6
CAN or MRZ user authentication, see [11], sec. 3.3
7
eID-PIN or CAN user authentication, see [11] sec. 3.3
8
CAN and eSign-PIN user authentication, see [11], sec. 3.3
9
usually preloaded (and often security certified) by the Chip Manufacturer
10
usually – together with IC – completely implementing executable functions
11
it means activated or not activated on the ID_Card
12
please note that user data might also be imported from outside of the TOE, e.g. data to be signed by the eSign application
13
a service provider can technically be represented by a local RF-terminal as the end point of secure
communication in the sense of this PP (local authentication) or by a remote terminal as the end point of secure communication in the
sense of this PP (online authentication)
1 ST Introduction
Page 10 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Averting of inconspicuous tracing of the ID_Card,
Self-protection of the TOE security functionality and the data stored inside.
1.2.4
and the eSign
.
anufacturing15
,
E is explicitly in
turing and the card
s operational phase
idered by the current ST. A security evaluation/certification being conform
the extent as
ce package chosen here for the TOE (see chap. 2.3 ‘Package
Claim’ below).
A more detailed view of the current TOE life cycle phases can be discussed as in [9a]
(see figure below)
TOE type
The TOE type is contactless smart card with the ePassport, the eID
applications named as a whole ‘electronic Identity Card (ID_Card)’
The typical life phases for the current TOE type are development14
, m
card issuing16
and, finally, operational use. Operational use of the TO
focus of the current ST. Some single properties of the manufac
issuing life phases being significant for the security of the TOE in it
are also cons
with the PP will have to involve all life phases into consideratio o
required by the assuran
n t
Figure 1 Life cycle phases of the TOE as from [9a]
In phase 1 the smart card embedded software is developed. In phase 2 the IC design
and IC dedicated software is developed. In phase 3 the IC is manufactured.
For this TOE the IC Packaging in phase 4 also consists of the transponder inlay
production and its attachement to the chip.
14
IC itself and IC embedded software
15
IC manufacturing and smart card manufacturing including installation of a native card operating system and transponder inlay
production and attachement
16
including installation of the smart card applications and their electronic personalisation (i.e. tying the application data up to the
ID_Card holder)
1 ST Introduction
Security Target Lite STARCOS 3.5 ID GCC C1 Page 11 of 128
Version 2.5 14.12.2010
In phase 5 the smart card product is integrated and tested and the inlays are transferred
in two steps, the
nd-user data, for
. The product is
the dedicated filesystem
phase (phase 7).
the preparative
ectives, assumptions from phases 1
to 5 and phase 6 before the personalization are referenced here. The phase 6 after the
life-cycle is considered in detail in the operational
.
1.2.5
nal world’ the TOE needs
munication according to [20].
guish between the
], sec. 3.2):
d by a governmental
nisation (i.e. an Official Domestic or Foreign Document Verifier),
a governmental
rganisation (Non-
rifier), and
ration of digital
henticate itself before access
nted. To authenticate a terminal
either as an inspection system or authentication terminal or signature terminal, General
ACE’ -> ‘terminal
on’ as depicted in Fig.
tion Procedure, sec. 3.4
to the personaliser.
The phase 6 described in [9a] as personalization can be separated
initialization of the embedded software and personalization of the e
short referred in the following as initialization and personalization
finished after initialization, after testing the OS and creation of
with security attributes. The TOE exists only in the operational usage
The correct delivery and the correct personalization are covered by
procedures document. Nevertheless all elements, obj
initialization and phase 7 of the card
user guidance. The delivery of the TOE is to the personalization body
Non-TOE hardware/software/firmware
In order to be powered up and to communicate with the ‘exter
terminal (card reader) supporting the contactless com
From the logical point of view, the TOE shall be able to distin
following terminal types, which, hence, shall be available (see [11
– Inspection system: an official terminal that is always operate
orga
– Authentication terminal: a terminal that may be operated by
organisation (Official Domestic Document Verifier) or by any other o
Official / Foreign Document Ve
– Signature terminal: a terminal used by ID_Card holder for gene
signature
The TOE shall require terminal of each type to aut
according to effective terminal authorisation is gra
s.
Authentication Procedure17
must be used.
The security policy of this ST covers only the sequence ‘P
authentication’ -> ‘passive authentication’ -> ‘chip authenticati
3.1, sec. 3.1.1 of [11], the branch rightmost (General Authentica
of [11]).
Please note that the current TOE does not support BAC.
Application Note 3: After Terminal Authenticatio . Pass
n ive Authentication and
d, the authenticated
l can request for a sector-specific chip-identifier (Restricted
Identification, see sec. 2.1.5, 3.2, 4.5 of [11]). Restricted Identification aims
providing a temporary ID_Card identifier being specific for a terminal sector
(pseudo-anonymisation) and supporting revocation features (sec. 3.2, 4.1.2 of
[11]). The security status of ID_Card is not affected by Restricted Identification.
Application Note 4: Concerning terminals for the eSign application, the
parallels with the terminals as defined in [7] are as follows: the Authentication
Terminal in the context of [11] (and of the current ST) is CGA18
in [7]; the
Chip Authentication have successfully b en performe
e
termina
17
i.e. PACE, terminal authentication, passive authentication and chip authentication according to [11]sec. 4.2, 4.3 and 4.4
18
Certification Generation Application
1 ST Introduction
Page 12 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Signature Terminal in the context of [11] represents a combination of SCA19
ined by the effective
resented by this terminal to
ucture – Country
k Certificates, Document Verifiers
erifiable format as
ich types of terminals shall be supported for
which single application of the TOE, see [11], sec. 3.1 – 3.4 (please note that the
effective ability of nds on its terminal authorisation level finally derived
chain as state
and HID20
in [7].
The authorisation level of an authenticated terminal shall be determ
terminal authorisation calculated from the certificate chain p
the TOE21
. All necessary certificates of the related public key infrastr
Verifying Certification Authority (CVCA) Lin
Certificates and Terminal Certificates – shall be available in a card v
specified in [11], Appendix C.1; see also [11], sec. 2.2.3.
The following table gives an overview wh
a terminal depe
from the presented certificate d above):
Inspection System
(official terminal)
Authentication
Terminal
(official or
commercial
terminal)
Signature
Terminal
ePassport reading
ps (incl.
User interaction:
CAN or MRZ f
text
rent termin
to E
- -
Operations:
all data grou
biometrical)
or
PACE
In this con
cur
, the
al is
equivalent
[6]
IS in
eID
Operations:
reading all dat
groups
User interactio
CAN for PACE
erations:
g a subset
roups;
l or a
data gr
ion:
eID-PIN or eID-PUK or
CAN25
for PACE
a
readin
n:
subse
User interact
Op
writin of data
g
g al
t of oups
-
eSign
eID-PIN or eID-PUK
-
Operations:
User interaction:
CAN22
for PACE
In the eSign context, the
Operations:
g digital
s
User interaction:
CAN for PACE, then
eSign-PIN for access
to the signature
activating eSign
application
generatin
signature
or
19
Signature Creation Application
20
Human Interface Device
21
It is based on Certificate Holder Authorization Template (CHAT), see [11], C.1.5. A CHAT is calculated as an AND-operation from the
certificate chain of the terminal and the ID_Card holder’s restricting input at the terminal. This final CHAT reflects the effective
authorisation level, see [11], C.4.2 and is then sent to the TOE by the command 'MSE:Set AT' within the Terminal Authentication (B.3
und B.11.1 of [11]).
22
if the terminal indicates such required authorisation with PACE (an official terminal), see C.4.2 in [11]
1 ST Introduction
Security Target Lite STARCOS 3.5 ID GCC C1 Page 13 of 128
Version 2.5 14.12.2010
Inspection System
(official terminal)
Authentication
Terminal
(official or
commercial
terminal)
Signature
Terminal
current termina
equivalent to C
nction
In the eSign
context, the current
al is
equivalent – as a
general term – to
SCA and HID in [7]
l is
GA in [7]
fu
termin
Table 1 ID_Card applications vs. terminal types
2 Conformance Claim
Page 14 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
2 Conformance Claim
.1 CC Conformance Claim
This protection profile claims conformance to
n, Part 1:
3.1, Revision 3,
Part 2: Security
Functional Components; CCMB-2009-07-002, Version 3.1, Revision 3, July 2009
[2]
riteria for Information Technology Security Evaluation, Part 3: Security
equirements; CCMB-2009-07-003, Version 3.1, Revision 3, July 2009
[3]
- Part 3 conformant.
2009, [4]
2.2
Profile –Electronic
-PP-0061 [7a].
The part of the security policy for the ePassport application of the TOE is contextually in
ion with the protection profile ‘Common Criteria Protection Profile
ble Travel Document with „ICAO Application", Extended Access
wever does not claim any
e current ST does
it cannot be ensured for the future, that the specifications
[10] and [11] remain compatible to each other. In addition to the security policy defined
in [6], the ePassport application of the TOE uses PACE as the mandatory
communication establishment protocol.
2.3 Package Claim
The current ST is conformant to the following security requirements package:
Assurance package EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5
as defined in the CC, part 3 [3].
2
Common Criteria for Information Technology Security Evaluatio
Introduction and General Model; CCMB-2009-07-001, Version
July 2009 [1]
Common Criteria for Information Technology Security Evaluation,
Common C
Assurance R
as follows
- Part 2 extended,
The
Common Methodology for Information Technology Security Evaluation, Evaluation
Methodology; CCMB-2009-07-004, Version 3.1, vision 3, July
Re
has to be taken into account.
PP Claim
This claims strict conformance to the Common Criteria Protection
(ID_Card PP), ver. 1.03, 15.12.2009, BSI-CC
ST
Identity Card
a tight connect
Machine Reada
Control, BSI-PP-0056, version 1.10, 25th March 2009’ [6], ho
formal conformance to it. The main reason for this decision is that th
not cover BAC. Besides is,
th
2 Conformance Claim
Security Target Lite STARCOS 3.5 ID GCC C1 Page 15 of 128
Version 2.5 14.12.2010
2.4 Conformance Claim Rationale
ommon Crite
3, 15.12.2009, BSI-CC-
tection Profiles for
ion, prEN 141 9-
claims strict
formance to the protection profile [7]. In the following chapters this claim and how
2.4.1
e and software
data (SCD). The SSCD
protects the SCD during its whole life cycle as to be used in a signature-creation process
its signatory’.
pe in the part being
ve.
2.4.1.2 SPD Statement
The security problem definition (SPD) of the current ST contains the security problem
organisational
ends several
2.4.1
ement for the TOE in the current ST includes all the security
onal items as stated
nment in the current
t of the PP [7] and
w.
2.4.1.4 Security Requirements Statement
The SFR statement for the TOE in the current ST includes all the SFRs for the TOE of the
PP [7] and comprehends several additional items as stated in chap. 6.1 below.
The SAR statement for the TOE in the current ST includes all the SARs for the TOE of
the PP [7] as stated in chap. 6.2 below. The current assurance package contains the
assurance components ALC_DVS.2 and ATE_DPT.2 being hierarchical to ALC_DVS.1
respectively ATE_DPT.1 as required by [7].
Th urrent ST claims strict conformance to the protection profile C ria
Protection Profile –Electronic Identity Card (ID_Card PP), ver. 1.0
PP-0061 [7a]. However, this PP claims strict conformance to ‘Pro
Secure Signature Creation Device – Part 2: Device with key generat 6
1:2009, ver. 1.03, 2009-12, BSI-CC-PP-0059, [7]. Therefore this ST also
e c
con
it is implemented in this ST is discuused in detail.
.1 TOE Type
The TOE type stated in [7], sec. 5.4.2 is ‘… a combination of hardwar
configured to securely create, use and manage signature-creation
solely by
This TOE type is obviously commensurate with the current TOE ty
provided by the eSign application, see sec. 1.2.1 and 1.2.3 abo
definition of the PP [7]. The current SPD includes the same threats,
security policies and assumptions as for the TOE in [7] and compreh
additional items as stated in chap. 3 below.
.3 Security Objectives Statement
The security objectives stat
objectives for the TOE of the PP [7] and comprehends several additi
in chap. 4.1 below.
The security objectives statement for the TOE’s operational enviro
S includes all security objectives for the operational environmen
comprehends several additional items as stated in chap. 4.2 belo
T
3 Security Problem Definition
Page 16 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
3 Security Problem Definition
oduction
3.1.1
The primary assets to be protected by are in scope of the TOE
lease refer to ry in chap. 8 for the term d
3.1 Intr
Assets
the TOE as long as they
are (p the glossa efinitions)
Object
No.
Asset Definition
Generic security property
to be
maintained by the current
security policy
ePassport, eID, eSign
1
user data sto
on
the TOE
pplications of the ID_Card
and
b
red
All data (being not
authentication
d ) stored in the context of
ata
the a
as defined in [11]
(i) being allowed to e read out
or written sol by
ely a
terminal (in the
11], sec. 3.2)
to be used
ticated
al (in the sense of [11],
tion
ng allowed to be used
solely by the authenticated
ID_Card holder (the private
signature key within the eSign
24
ta on
n
authenticated
sense of [
respectively
(ii) being allowe
solely by an authen
termin
d
sec. 3.2) (the private
Restricted Identifica
key23
) respectively
(iii) ei
b
application ).
This asset covers ‘User Da
the MRTD’s chip’ and ‘Logical
[6] as well as ‘SCD’ and
‘DTBS/R’ in [7].
Confidentiality25
Integrity Authenticity
MRTD sensitive User Data’ in
23
Since the Restricted Identification according to [11], sec. 4.5 represents just a functionality of the ID_Card, the key material needed for
this functionality and stored in the TOE is treated here as User Data in the sense of the CC.
24
SCD in [7]
25
Though not each data element stored on the TOE represents a secret, the specification [11] anyway requires securing their
confidentiality: only terminals authenticated according to [11]], sec. 4.4 can get access to the user data stored.
3 Security Problem Definition
Security Target Lite STARCOS 3.5 ID GCC C1 Page 17 of 128
Version 2.5 14.12.2010
Object
No.
Asset Definition
Generic security property
to be
maintained by the current
security policy
2 ta
rred
ween t
d th
service
provider
connected
ot
ferred in the
plications of
as defined in [11]
and an
rminal (in the
3.2).
e received and
ge <=> {receive,
DTBS’ in [7].
Confidentiality27
Integrity Authenticity
user da
transfe
he
e
All data (being n
authentication
data) being t s
context of the ap
e ID_Card
bet
TOE an
26
between the TOE
authenticated te
ran
th
sense of [11], c.
se
User data can b
sent (exchan
send}).
This asset covers ‘
3
data
ati
revious
D_Card
y inconspicuous (for
holder)
recognising the TOE knowing
PIN nor eID-PUK. TOE tracing
unavailability28
ID_Card tracing
Technical inform
the current and p
locations of the I
gathered b
the ID_Card
on about
neither CAN nor MRZ nor eID-
data can be provided /
gathered.
Table 2 Primary assets
All these primary assets represent Use the CC.
c to ed by the TOE in order to achieve a
ie assets are:
r Data in the sense of
The se
suffic
ondary assets also having
nt protection of the primary
be protect
Object
No.
Asset Definition Property to be maintained
by the current security
policy
ePassport, eID, eSign
4 Accessibility to
subjects
Property of the TOE to restrict Availability
the TOE access to TSF and TSF-data
functions and
data only for
stored in the TOE to authorised
subjects only.
authorised
26
for the ePassport application, the service provider is always an authority represented by a local RF-terminal
27
Though not each data element being transferred represents a secret, the specification [11] anyway requires securing their
confidentiality: the secure messaging in encrypt-then-authenticate mode is required for all messages according to [11] sec. 4.3.2, 4.4.2.
28
represents a prerequisite for anonymity of the ID_Card holder
3 Security Problem Definition
Page 18 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Object
No.
Asset Definition Property to be maintained
by the current security
policy
5 Genuinene
the TOE
to be
tic in order to provide
urity functionality in
rs
he MRTD’s
].
Availability
ss of Property of the TOE
authen
claimed sec
proper way.
a
This asset also cove
‘Authenticity of t
chip’ in [6
6
p
cryptographic material
in or
Confidentiality Integrity
TOE imman
secret
cryptogra
keys
ent
hic
used by the TOE
enforce its security
functionality29
.
Secret
der to
7 TOE imman
non-secret
cryptograp
material
raphic
n-
rd Security
Object containing digital
sed by the
ts security
.
vers ‘SVD’ in
Integrity Authenticity
ent Non-secret cryptog
(public) keys and other no
hic secret material (Ca
signature) u
order to enforce i
functionality
This asset also co
[7].
TOE in
8 Secret ID_C
holder
authentica
data
ID_Card
r
e
attemp
holder (–
30
stored in
ell as
gn-PUK, if
e ID_Card32
to it33
)
Confidentiality Integrity
ard Secret authentication
tion
information for the
holder being used fo
verification of th
authentication
authorised ID_Card
eID-PIN and eID-PUK
the ID_Card as w
– eSign-PIN (and eSi
any)31
(i) stored in th
and (ii) transferred
ts as
9
communication
establishment
icted-revealable39
authorisation information for a
human user being used for
orised user
;
MRZ for ePassport). These data
to it.
Confidentiality34
Integrity
ID_Card Restr
authorisation verification of the authorisation
data attempts as auth
(CAN for ePassport, eID, eSign
are stored in the TOE and are
not to convey
Table 3 Secondary assets
29
please note that the private signature key within the eSign application (SCD) belongs to the object No. 1 ‘user data stored’ above.
30
eID-PIN and eID-PUK are global secrets being valid for the entire ID_Card.
31
eSign-PIN (and eSign-PUK, if any) are local secrets being valid only within the eSign application.
32
is commensurate with RAD in [7]
33
is commensurate with VAD in [7]
34
The ID_Card holder may reveal, if necessary, his or her verification values of CAN and MRZ to an authorised person or device who
definitely act according to respective regulations and are trustworthy.
3 Security Problem Definition
Security Target Lite STARCOS 3.5 ID GCC C1 Page 19 of 128
Version 2.5 14.12.2010
ID_Card holder authentication and ID_Card communication estab
authorisation data are represented by two different entities: (i) ref
lishment
erence information
tion being provided as
ation attempt.
ith the terminal
the verification information in the ‘TOE <-> terminal’ channel, if it has
RZ, eID-PIN and eID-PUK are not
to convey to the TOE.
and TSF-data in the sense of the CC.
ts and ex tities
s security target considers the following subjects:
being persistently stored in the TOE and (ii) verification informa
input for the TOE by a human user as an authentication/authoris
The TOE secures the reference information as well as – together w
connected35
–
to be transferred to the TOE. Please note that CAN, M
The secondary assets represent TSF
3.1.2
Thi
Subjec ternal en
External
Entity
No.
Subject
No.
Role Definition
1 1 ID_Card h or whom the ID_Card Issuer has
Card36
.
surate with ‘MRTD
ory’ in [7].
rd holder can also
).
older A person f
personalised the ID_
This subject is commen
Holder’ in [6] and ‘Signat
Plea note that an ID_Ca
se
be an attacker (s. below
2 - ID_Card p enting the ID_Card to a
he identity of the
s commensurate with ‘Traveller’
in [7].
Card presenter can
ow).
resenter A person pres
terminal37
and claiming t
ID_Card holder.
This subject i
in [6] and ‘User’
Please note that an ID_
also be an attacker (s. bel
3 - Service Provider (SP) An official or commer
providing services which can be used b
ro
cial organisation
y the
vider uses rightful
terminals managed by a DV.
ID_Card holder. Service P
4 2 inal l system
.
default role for any
terminal being recognised by the TOE as
neither PCT nor EIS nor ATT nor SGT
(‘Terminal’ is used by the ID_Card presenter).
Term A terminal is any technica
communicating with the TOE through the
contactless interface
The role ‘Terminal’ is the
This subject is commensurate with ‘Terminal’
in [6].
5 3 PACE Terminal
(PCT)
A technical system verifying correspondence
between the password stored in the ID_Card
and the related value presented to the
terminal by the ID_Card presenter.
35
the input device of the terminal
36
i.e. this person is uniquely associated with a concrete electronic ID Card
37
in the sense of [11]
3 Security Problem Definition
Page 20 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
External
Entity
No.
Subject
No.
Role Definition
PCT implements the termin
PACE protocol and authenti
ID_Card using a sh d p
al’s part of the
cates itself to the
assword (CAN, eID-
e PCT is not allowed
ee sec. 4.2.2 in [11]).
2, table 1.2 and
are
PIN, eID-PUK or MRZ). Th
reading User Data (s
See also [11], chap. 3.3, 4.
G.2
6 4 Inspection s
(EIS)
ed by an
a governmental
fficial Domestic or
verifying the
D_Card holder (for
the real biometrical
senter with the
e ID_Card
PCT additionally
entication (incl.
the Terminal
d is authorised by
ugh the Document
iving State (by issuing
d a subset of the
Card.
he context of [11]
mmensurate with
ystem (EIS) as
and C.4.
ystem A technical system being us
authority38
and operated by
organisation (i.e. an O
Foreign Document Verifier) and
ID_Card presenter as the I
ePassport: by comparing
data of the ID_Card pre
stored biometrical data of th
holder).
An Inspection System is a
supporting the Chip Auth
passive authentication d
Authentication protocols an
the ID_Card Issuer thro
) an
Verifier of the rece
terminal certificates) to rea
data stored on the ID_
The Inspection System in t
(and of the current ST) is co
the Extended Inspection S
defined in [6].
See also [11], chap. 3.2
7 5
Authentication
Terminal (ATT)
eing operated and used
organisation
stic Document Verifier) or by
mmercial organisation and
enter as the
ret eID-PIN39
), (ii)
ta of the eID
d (iii) activating the eSign
application.
An Authentication Terminal is a PCT
the Chip
Authentication (incl. passive
authentication) and the Terminal
Authentication protocols and is authorised by
the ID_Card Issuer through the Document
Verifier of the receiving branch (by issuing
terminal certificates) to access a subset of the
data stored on the ID_Card.
A technical system b
either by a governmental
(Official Dome
any other, also co
(i) verifying the ID_Card pres
ID_Card holder (using sec
updating a subset of the da
application an
additionally supporting
38
concretely, by a control officer
39
secret eID-PUK can be used for unblocking the eID-PIN as well as the eSign-PIN and resetting the related retry counters.
3 Security Problem Definition
Security Target Lite STARCOS 3.5 ID GCC C1 Page 21 of 128
Version 2.5 14.12.2010
External
Entity
No.
Subject
No.
Role Definition
8 6 Signature
(SGT)
used for generation of
ature Terminal is a
ting the Chip
passive authentication)
uthentication protocols
e ID_Card Issuer
the Document Verifier of the
ing terminal
bset of the data
D_Card.
nd [11], chap. 3.2
Terminal A technical system
digital signatures. A Sign
PCT additionally suppor
Authentication (incl.
and the Terminal A
and is authorised by th
through
receiving b ch (by issu
ran
certificates) to access a su
stored on the I
See also par. 23 above a
and C.4.
9 7 Document
(DV)
g the policies of the
ercial organisation)
inals belonging together
y a State’s border
nt Verifier is therefore
at least the national
.2.2. There can be
DV: A domestic DV is
he policy of the domestic
ID_Card Issuer; a
the
(in this case there
reement40
between
a foreign CVCA
he ID_Card Issuer’s
ject is
ment Verifier’ in
Verifier An organisation enforcin
CVCA and of a Service Provider
(governmental or comm
and managing term
(e.g. terminals operated b
police), by – inter alia – issuing Terminal
Certificates. A Docume
a CertA, authorised by
CVCA to issue certificates for national
terminals, see [11], chap. 2
Domestic and Foreign
acting under t
CVCA being run by the
foreign DV is acting under a policy of
respective foreign CVCA
shall be an appropriate ag
the ID_Card Issuer und
ensuring enforcing t
privacy policy41
). This sub
commensurate with ‘Docu
[6].
10 8 Country V
Certificatio
Authority (CVCA)
forcing the privacy policy
with respect to
stored in the ID_Card
access to
these data). The CVCA represents the
PKI for the
rightful terminals (EIS, ATT, SGT) and creates
the Document Verifier Certificates within this
PKI. Updates of the public key of the CVCA
are distributed in form of CVCA Link-
Certificates, see [11], chap. 2.2.1. The
Country Signing Certification Authority
erifying
n
An organisation en
of the ID_Card Issuer
protection of user data
(at a trial of a terminal to get an
country specific root of the
40
the form of such an agreement may be of formal and informal nature; the term ‘agreement’ is used in the current ST in order to
reflect an appropriate relationship between the parties involved.
41
Existing of such an agreement may technically be reflected by means of issuing a CCVCA-F for the Public Key of the foreign CVCA
signed by the domestic CVCA.
3 Security Problem Definition
Page 22 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
External
Entity
No.
Subject
No.
Role Definition
(CSCA) issuing certifica
Signers (cf. [8]) and the do
be integrated into a single e
tes for Document
mestic CVCA may
ntity, e.g. a
ate with ‘Country
Authority’ in [6].
Country CertA. However, even in this case,
separate key pairs must be used for different
roles, see [11], sec. 2.2.1.
This subject is commensur
Verifying Certification
11 - Document S
(DS)
the policy of the
Security Object
rd for passive
Signer is
l CSCA issuing the
(CDS), see [11],
e is usually
ion Agent.
igner An organisation enforcing
CSCA and signing the rd
stored on the ID_Ca
authentication. A Doc
Ca
ument
authorised by the nationa
Document Signer Certificate
chap. 1.1 and [8]. This rol
delegated to a Personalisat
12 - Country Sig
Certification
Authority (C
the policy of the
to confirming
SF data stored in the
ents the country
he ID_Cards and
r Certificates
es the self-
ictly secure diplomatic
Country Signing
ing certificates for
]) and the domestic
ed into a single entity,
ever, even in this
must be used for
. 2.2.1.
ning
SCA)
An organisation enforcing
ID_Card Issuer with respect
correctness of user and T
ID_Card. The CSCA repres
specific root of the PKI for t
creates the Document Signe
within this PKI. The CSCA also issu
signed CSCA Certificate (CCSCA) having to
be di uted by str
strib
means, see. [8], 5.1.1. The
Certification Authority issu
Document Signers (cf. [8
CVCA may be integrat
e.g. a Country CertA. How
case, separate key pairs
different roles, see [11], sec
13 - Certification
Provider (CS
certificates and
es related to electronic
d
’ Certification
d
certificates. A CSP is the Certification Service
Provider in the sense of [7].
Service
P)
An organisation issuing
providing other servic
signatures. There can be ‘common’ an
‘qualified’ CSP: A ‘qualified
Service Provider can also issue qualifie
14 9 Personalisation
Agent
An organisation acting on behalf of the
ID_Card Issuer to personalise the ID_Card for
the ID_Card holder by some or all of the
following activities: (i) establishing the
identity of the ID_Card holder for the
biographic data in the ID_Card42
, (ii) enrolling
the biometric reference data of the ID_Card
holder43
, (iii) writing a subset of these data
42
relevant for the ePassport, the eID and the eSign applications
43
relevant for the ePassport application
3 Security Problem Definition
Security Target Lite STARCOS 3.5 ID GCC C1 Page 23 of 128
Version 2.5 14.12.2010
External
Entity
No.
Subject
No.
Role Definition
on the physical Identifica
personalisat ) and storin
ID_Car
tion Card (optical
g them in the
ersonalisation) for the
d in [11], (iv) writing
e initial TSF data, (vi)
curity Object defined in
Please note that the
t’ may be
veral institutions
operational policy of the
d Issuer. Generating signature key
of the tasks of this
surate with
in [6] and
ion
d (electronic p
ID_Card holder as define
the document details
data, (v) writing th
signing the Card Se
[11] (in the role of DS).
role ‘Personalisation Agen
distributed among se
according to the
ID_ ar
C
pair(s) is not in the scope
role. This subject is commen
‘Personalisation agent’
‘Administrator’ in [7].
15 10 Manufactu anufacturer
it and the ID_Card
anufacturer completing the IC to the
nufacturer is the default
the TOE during the manufacturing life
es
n the IC Manufacturer
er using this role
urate with
rer Generic term for the IC M
producing integrated circu
M
ID_Card. The Ma
use of
r
phase44
. The TOE itself do
not distinguish betwee
and ID_Card Manufactur
Manufacturer.
This subject is commens
‘Manufacturer’ in [6].
16 - Attacker on or a process acting
dermine the
urity policy defined by the current ST,
especially to change properties of the assets
attacker is
assumed to possess an at most high attack
potential.
Please note that the attacker might ‘capture’
any subject role recognised by the TOE.
with ‘Attacker’
A threat agent (a pers
on his behalf) trying to un
ec
s
having to be maintained. The
This subject is commensurate
in [6] and in [7].
Table 4 Subjects and external entities45
Since the TOE does not support BAC, a Basic Inspection System (BIS) cannot be
recognised by the TOE.
44
cf. also par. 14 in sec. 1.2.3 above
45
This table defines external entities and subjects in the sense of [1]. Subjects can be recognised by the TOE independent of their nature
(human or technical user). As result of an appropriate identification and authentication process, the TOE creates – for each of the
respective external entity – an ‘image’ inside and ‘works’ then with this TOE internal image (also called subject in [1]). From this point of
view, the TOE itself does not differ between ‘subjects’ and ‘external entities’. There is no dedicated subject with the role ‘attacker’ within
the current security policy, whereby an attacker might ‘capture’ any subject role recognised by the TOE.
3 Security Problem Definition
Page 24 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
3.2 Threats
endently or in
rotected
e derived from the ICAO-
3.2.1 erminal
ion system, an authentication or a signature terminal
nsferred between the TOE
ace of the TOE. The
f the shared password
ign.
printed or stuck on the
Z effectively
ard-Holder.
3.2.2 vesdropping Eavesdropping on the communication
l terminal
_Card and a rightful
e TOE and the service
n(s): ePassport, eID,
3.2.3 T.ID_Card_Tracing Tracing ID_Card
. to trace the movement of the
r listening to a
ker cannot read
MRZ, eID-PIN,
application(s): ePassport, eID, eSign.
3.2.4 T.Counterfeit Counterfeiting ID_Card
An attacker produces an unauthorised copy or reproduction of a genuine ID_Card
to be used as part of a counterfeit Identification Card: he or she may generate a
new data set or extract completely or partially the data from a genuine ID_Card and
copy them on another functionally appropriate chip to imitate this genuine ID_Card.
This violates the authenticity of the ID_Card being used either for authentication of
an ID_Card presenter as the ID_Card holder or for authentication of the ID_Card as
a genuine secure signature creation device.
This item concerns the following application(s): ePassport, eID, eSign.
This section describes the threats to be averted by the TOE indep
collaboration with its IT environment. These threats result from the assets p
by the TOE and the ethod of TOE’s use in the operational environment.
m
The following threats are defined in the current ST (they ar
BAC PP [5] and ICAO-EAC PP [6]):
T.Skimming Skimming ID_Card / capturing card-t
communication
An attacker imitates an inspect
in order to get access to the user data stored on or tra
and the service provider connected via the contactless interf
attacker cannot read and does not know the correct value o
(CAN, MRZ, eID-PIN, eID-PUK) in advance.
This item concerns the following application(s): ePassport, eID, eS
Application Note 5: MRZ is printed and CAN is
Identification Card. Please note that neither CAN nor MR
represent secrets, but are restricted-revealable, cf. OE.ID_C
T.Ea
between the TOE and a rightfu
An attacker is listening to the communication between the ID
terminal in order to gain the user data transferred between th
provider connected. This item concerns the following applicatio
eSign.
An attacker tries to gather TOE tracing data (i.e
ID_Card) unambiguously identifying it remotely by establishing o
communication via the contactless interface of the TOE. The attac
and does not know the correct values of shared passwords (CAN,
eID-PUK) in advance.
This item concerns the following
3 Security Problem Definition
Security Target Lite STARCOS 3.5 ID GCC C1 Page 25 of 128
Version 2.5 14.12.2010
3.2.
tored on the ID_Card
nnected in order to
s of changed
r biometric data or
e Service Provider (represented
authentic one.
rns the following application(s): ePassport, eID, eSign.
d, but not being sent to the
3.2. nality
e used in TOE
e User Data stored in
a stored in the TOE or (iii) to
r modify) soft-coded security functionality of the
TOE. This threat addresses the misuse of the functions for the initialisation and
_Card holder.
ncerns the following application(s): ePassport, eID, eSign.
3.2. mation Leakage from
ing its usage in order
tion leakage may be
, eID, eSign.
tions, variations in
, or by changes in
leakage may be interpreted as a covert
sely related to measurement of
either from measurements of
ents (by contact to
an then be related
e Differential
tromagnetic Analysis (DEMA) and Differential Power Analysis (DPA).
rce information leakage by
fault injection (e.g. Differential Fault Analysis).
3.2.8 T.Phys-Tamper Physical Tampering
An attacker may perform physical probing of the ID_Card in order (i) to disclose the
TSF-data, or (ii) to disclose/reconstruct the TOE’s Embedded Software. An attacker
may physically modify the ID_Card in order to alter (i) its security functionality
(hardware and software part, as well), (ii) the User Data or the TSF-data stored on
the ID_Card.
This item concerns the following application(s): ePassport, eID, eSign.
5 T.Forgery Forgery of Data
An attacker fraudulently alters the User Data or/and TSF-data s
or/and exchanged between the TOE and the Service Provider co
outsmart the authenticated terminal (EIS, ATT or SGT) by mean
ID_Card holder’s related reference data (like biographic o
SCD/SVD). The attacker does it in such a way that th
by the terminal connected) perceives these modified data as
This item conce
This threat partially covers T.SVD_Forgery (only store
CGA SVD) from Table 5.
6 T.Abuse-Func Abuse of Functio
An attacker may use functions of the TOE which shall not b
operational phase in order (i) to manipulate or to disclosure th
the TOE, (ii) to manipulate or to disclose the TSF-dat
manipulate (bypass, deactivate o
personalisation in the operational phase after delivery to the ID
This item co
This threat covers T.SigF_Misuse from Table 5.
7 T.Information_Leakage Infor
ID_Card
An attacker may exploit information leaking from the TOE dur
to disclose confidential User Data or/and TSF-data. The informa
inherent in the normal operation or caused by the attacker.
This item concerns the following application(s): ePassport
Application Note 6: Leakage may occur through emana
power consumption, I/O characteristics, clock frequency
processing time requirements. This
channel transmission, but is more clo
operating parameters which may be derived
the contactless interface (emanation) or direct measurem
the chip still available even for a contactless chip) and c
to the specific operation being performed. Examples ar
Elec
Moreover the attacker may try actively to enfo
3 Security Problem Definition
Page 26 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
This threat covers T.Hack_Phys from Table 5.
Application Note 7: Physical tampering may be focused d
disclosure or manipulation of the user data (e.g. the biom
data for the inspection system) or the TSF data (e.g. auth
the ID_Card) or indirectly by preparation of the TOE to
methods by modification of security features (e.g. to enabl
leakage through power analysis). Physical tampering req
interaction with the ID_Card’s internals. Techniques com
IC failure analysis and IC reverse engineering efforts may be used. Before
that, hardware security mechanisms and layout characteristics need t
identified. Determination o
irectly on the
etric reference
entication key of
following attack
e information
uires a direct
monly employed in
o be
f software design including treatment of the
he modification
anges of circuitry or
3.2.9 ntal Stress
and Embedded
ate or modify
es or functionality of the TOE’ hardware or to (ii) circumvent,
mbedded Software. This may
perating conditions,
g administrative
rmation about the
functional operation.
lication(s): ePassport, eID, eSign.
Application Note 8: A malfunction of the TOE may also be caused using a
direct interaction with
being a manipulation (refer to the threat T.Phys-Tamper) assuming a
detailed knowledge about TOE’s i
The cu n eats of the SSCD PP [7]. These items are
applicable, if the eSign a
user data and the TSF data may also be a pre-requisite. T
may result in the deactivation of a security function. Ch
data can be permanent or temporary.
T.Malfunction Malfunction due to Environme
An attacker may cause a malfunction the ID_Card’s hardware
Software by applying environmental stress in order to (i) deactiv
security featur
deactivate or modify security functions of the TOE’s E
be achieved e.g. by operating the ID_Card outside the normal o
exploiting errors in the ID_Card’ Embedded Software or misusin
functions. To exploit these vulnerabilities an attacker needs info
This item concerns the following app
elements on the chip surface. This is considered as
nternals.
rrent ST also i cludes all thr
pplication is operational.
Threat
identifier
Comments
T.SCD_
concerns the following
application(s):
Divulge
– eSign
T.SCD_Derive
cerns the following
application(s):
– eSign
con
T.Hack_Phys is
covered by
T.Phys-Tamper
concerns the following
application(s):
– ePassport
– eID
– eSign
T.SVD_Forgery
is covered by
concerns the following
application(s):
3 Security Problem Definition
Security Target Lite STARCOS 3.5 ID GCC C1 Page 27 of 128
Version 2.5 14.12.2010
Threat
identifier
Comments
T.Forgery – eSign
T.SigF
is cove
concerns the following
application(s):
ort
– eSign
_Misuse
red by
T.Abuse-Func – ePassp
– eID
T.DTBS_Forgery concern
application(s):
s the following
– eSign
T.Sig_Forgery concerns the following
n(s):
applicatio
– eSign
Table 5 Threats taken over from [7]
3.3 Organisational Security Policies
he TOE and/or its environment shall comply with the following Organisational
ctices, or guidelines
3.3.1 g of the
ves using the
ss of the user data (amongst
r) and of the TSF-data
technical components (IC)
which enable traceability of the ID_Cards in their manufacturing
in the operational phase,
cf. sec. 1.2.3 above.
Agent to
rs, the ID_Card Issuer
n accordance
with the ID_Card Issuer’s policy.
ication(s): ePassport, eID, eSign.
3.3.2 P.ID_Card_PKI PKI for Chip and Passive Authentication
(issuing branch)47
Application Note 9: The description below states responsibilities of the involved
parties and represents the logical, but not the physical structure of the PKI.
Physical distribution ways shall be implemented by the involved parties in such a
T
Security Policies (OSP) as security rules, procedures, pra
imposed by an organisation upon its operation.
P.Pre-Operational Pre-operational handlin
ID_Card
1. The ID_Card Issuer issues the ID_Cards and appro
terminals complying with all applicable laws and regulations.
2. The ID_Card Issuer guarantees correctne
other of those, concerning the ID_Card holde
permanently stored in the TOE46
.
3. The ID_Card Issuer uses only such TOE’s
and issuing life phases, i.e. before they are
4. If the ID_Card Issuer authorises a Personalisation
personalise the ID_Cards for ID_Card holde
has to ensure that the Personalisation Agent acts i
This item concerns the following appl
46
cf. Table 2 and Table 3 above
47
Passive authentication is considered to be part of the chip authentication protocol within this ST.
3 Security Problem Definition
Page 28 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
way that all certificates belonging to the PKI are securely distributed / made
ices.
rastructure for the
creation and
s a Country Signing
er shall make the
Document Signer Certificates
(who shall finally
e CSCA key pair.
et and issue a self-
A Certificate (CCSCA) having to be made available to
8], 5.1.1. The CSCA
for the Document
le to the ID_Card
ment Signer Key Pair,
e Document Signer Public Key to the CSCA for
er Private Key secret, (iv)
securely use the Document Signer Private Key for signing the Card
ip Authentication
Key Pairs {SKPICC, PKPICC} used for the chip authentication as
eSign.
3.3.3 ntication (receiving
sibilities of the involved
ure of the PKI.
ed parties in such a
ates belonging to the PKI are securely distributed / made
ices.
y infrastructure for the
entication. For this
e ID_Card Issuer shall run a domestic Country Verifying
ay use already
ll make the CVCA
finally distribute it
2. A CVCA shall securely generate, store and use the CVCA key pair. A
CVCA shall keep the CVCA Private Key secret and issue a self-
available to their final destination, e.g. by using directory serv
1. The ID_Card Issuer shall establish a public key inf
passive authentication, i.e. for digital signature
verification for the ID_Card. For this aim he run
Certification Authority (CSCA). The ID_Card Issu
CSCA Certificate (CCSCA) and the
(CDS) available to the CVCAs under agreement48
distribute them to their rightful terminals).
2. The CSCA shall securely generate tore and use th
The CSCA shall keep the CSCA Private Key secr
signed CSC
, s
the ID_Card Issuer by strictly secure means, see [
shall create the Document Signer Certificates
Signer Public Keys (CDS) and make them availab
Issuer, see [8], 5.1.1.
3. A Document Signer shall (i) generate the Docu
(ii nd over th
) ha
certification, (iii) keep the Document Sign
Security Objects of ID_Cards and (v) manage Ch
defined in [11], sec. 4.3.49
This item concerns the following application(s): ePassport, eID,
P.Terminal_PKI PKI for Terminal Authe
branch)
Application Note 10: The description below states respon
parties and represents the logical, but not the physical struct
Physical distribution ways shall be implemented by the involv
way that all certific
available to their final destination, e.g. by using directory serv
1. The ID_Card Issuer shall establish a public ke
card verifiable certificates used for terminal auth
aim, th
Certification Authority (domestic CVCA) and m
existing foreign CVCAs50
. The ID_Card Issuer sha
Link Certificate available to the CSCA (who shall
to its ID_Cards).
48
the form of such an agreement may be of formal and informal nature; the term ‘agreement’ is used in the current ST in order to
reflect an appropriate relationship between the parties involved.
49
A Document Signer shall also manage Restricted Identification Key Pairs {SKID, PKID} [11], sec. 2.3 and 4.5. The private Restricted
Identification Key SKID shall be stored in the TOE, whereby the public Restricted Identification Key PKID – in a database of the DS. See
also Application Note 3 and Table 2, object #1.
50
In this case there shall be an appropriate agreement between the ID_Card Issuer und a foreign CVCA ensuring enforcing the ID_Card
Issuer’s privacy policy. Existence of such an agreement may technically be reflected by means of issuing a CCVCA-F for the Public Key of
the foreign CVCA signed by the domestic CVCA.
3 Security Problem Definition
Security Target Lite STARCOS 3.5 ID GCC C1 Page 29 of 128
Version 2.5 14.12.2010
signed CVCA Certificate (CCVCA) having
the ID_Card Issuer by strictly secure means as w
respective Document Verifiers. A CVCA shall
to be made available to
ell as to the
create the Document
CDV) and
ent Verifiers51
.
ment Verifier Key
lic Key to the CVCA
erifier Private Key secret
ivate Key for signing
e Terminal Certificates (CT) of the terminals being managed by
and CCVCA
ho puts them in his
thentication Key
inal Authentication
keep the
cret, (iv) securely
ate Keys for the terminal
in [11], sec. 4.4 and (v) install CT, CDV
plication(s): ePassport, eID, eSign.
3.3.4
usively to the rightfu
sign exclusively correct
e ID_Cards.
es exclusively to the
sure that they issue their
certificates exclusively to the rightful equipment (terminals)53
.
es exclusively for the
_Card holder)54
.
eID, eSign.
3.3.5 P.Terminal Abilities and trustworthiness of rightful
ation terminal and
signature terminal, cf. Table 1 above) shall be used by Service
Providers and by ID_Card holders as defined in [11], sec. 3.2
2. They shall implement the terminal parts of the PACE protocol [11],
sec. 4.2, of the Terminal Authentication protocol [11], sec. 4.4, of
the Passive Authentication [11], sec. 3.4 and of the Chip
Verifier Certificates for Document Verifier Public Keys (
distribute them back to the respective Docum
3. A Document Verifier shall (i) generate the Docu
Pair, (ii) hand over the Document Verifier Pub
for certification, (iii) keep the Document V
and (iv) securely use the Document Verifier Pr
th
him. The Document Verifier shall make CT, CDV
available to the respective Service Provider (w
terminals)52
.
4. A Service Provider shall (i) generate the Terminal Au
Pairs {SKPCD, PKPCD}, (ii) hand over the Term
Public Keys (PKPCD) to the DV for certification, (iii)
Terminal Authentication Private Keys (SKPCD) se
use the Terminal Authentication Priv
authentication as defined
and CCVCA in the rightful terminals operated by him.
5. This item concerns the following ap
P.Trustworthy_PKI Trustworthiness of PKI
1. The CSCA shall ensure that it issues its certificates excl
organisations (DS) and DSs shall ensure that they
Card Security Objects having to be stored on th
2. CVCAs shall ensure that they issue their certificat
rightful organisations (DV) and DVs shall en
3. CSPs shall ensure that they issue their certificat
rightful data (public signature of the ID
key
por
This item concerns the following application(s): ePass t,
terminals
1. Rightful terminals (inspection system, authentic
.
51
A CVCA shall also manage a Revocation Sector Key Pair {SKRevocation, PKRevocation} [11], sec. 2.3 and 4.5. For Restricted
Identification please see Application Note 3 and Table 2, object #1.
52
A DV shall also manage Sector’s Static Key Pairs {SKSectorNN, PKSectorNN} [11], sec. 2.3 and 4.5. For Restricted Identification please
see Application Note 3 and Table 2, object #1.
53
This rule is relevant for T.Skimming
54
This property is affine to P.CSP_QCert from [7].
3 Security Problem Definition
Page 30 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Authentication protocol [11], sec. 4.355
and
A rightful terminal shall use randomly and
selected nonces, if required by
use them in this order56
.
(almost) uniformly
the protocols (for generating
eded for the
ey pair {SKPCD,
D issued by the
d CCVCA; the terminal certificate
access to the data stored
m the terminal
nd CDS) in order
entication (determination of
enticity of PKPICC, [11], sec. 4.3.1.2).
n-PIN, DTBS) to the
cessfully
erminal
thentication .
ust ensure confidentiality
it (e.g. confidentiality of
KI certificates and DTBS, etc.), where it is
necessary for a secure operation of the TOE according to the
current ST.
This erns the following application(s): ePassport, eID, eSign.
Th a of the SSCD PP [7]. These items are
applicable, if the eSign application is operational.
ephemeral keys for Diffie-Hellmann).
3. Rightful terminals shall store the related credentials ne
terminal authentication (terminal authentication k
PKPCD} and the terminal certificate (CT) over PKPC
DV related as w s CDV an
ell a
includes an authorisation mask (CHAT) for
on the ID_Card) in order to enable and to perfor
authentication as defined in [11], sec. 4.4.
4. They shall also store the Country Signing Public Key and the
Document Signer Public Key (in form of CCSCA a
to enable and to perform Passive Auth
the auth
5. A rightful terminal must not send assets (e.g. eSig
TOE within the PACE session, but first having suc
performed the Chip Authentication after the T
Au 57
6. A rightful terminal and its environment m
and integrity of respective data handled by
PINs/PUKs, integrity of P
item conc
e current ST lso includes all OSPs
OSP
identifier
Comments
P.CSP_QCert concerns the following
application(s):
Sign
– e
P.QSign application(s):
concerns the following
– eSign
P.Sigy_SSCD
concerns the following
application(s):
– eSign
P.Sig_Non-
Repud
concerns the following
application(s):
– eSign
55
The Passive Authentication is considered to be part of the Chip Authentication (CA) Protocol within this ST.
56
This order is only commensurate with the branch rightmost in Fig. 3.1, sec. 3.1.1 of [11]. Other branches of this figure are not covered
by the security policy of the current ST.
57
This rule is relevant for T.Skimming
3 Security Problem Definition
Security Target Lite STARCOS 3.5 ID GCC C1 Page 31 of 128
Version 2.5 14.12.2010
Table 6 OSPs taken over from [7]
3.
nment in which the
The current ST includes all assumptions of the SSCD PP [7] (please regard Table
1 e item able, if the eSig application is operational.
4 Assumptions
The assumptions describe the security as ects of the enviro
TOE will be used or is intended to be used.
p
above). Thes s are applic
Assumption
identifier
Comments
A.CGA
concerns not
nly qualified, but also
non-qualified certificates,
cf.
the following
This item
o
concerns
application(s):
– eSign
A.SCA
concerns the following
application(s):
– eSign
Table 7 Assumptions taken over from [7]
The current ST does not include any additional assumptions.
4 Security Objectives
Page 32 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
4 Security Objectives
4.1 Secu
objectives address the protection provided by the
ent.
4.1.1 OT.Data_Integrity Integrity of Data
ata58
stored on it
ion (physical
tion and unauthorised modifying).
he TSF-data59
during their
Service Provider connected (and
SGT) after the Terminal- and the Chip
eSign.
4.1.2 OT.D
F-data60
stored on
e fication of their authenticity at the terminal-side61
.
TSF-data62
during
Service Provider connected (and
er the Terminal- and the Chip
tion at the terminal-
n by the TOE itself
TOE) .
item concerns the following application(s): ePassport, eID, eSign.
.Data_Confidentiality Confidentiality of Data
nfidentiality of the User Data and the TSF-data64
b
EIS, ATT, SGT)
resented by the
rity Objectives for the TOE
The following TOE security
TOE independent of TOE environm
The TOE must ensure integrity of the User Data and the TSF-d
by protecting these data against unauthorised modificat
manipula
The TOE must ensure integrity of the User Data and t
exchange between the TOE and the
represented by either EIS or ATT or
Authentication.
This item concerns the following application(s): ePassport, eID,
ata_Authenticity Authenticity of Data
The TOE must ensure authenticity of the User Data and the TS
it by enabling v ri
The TOE must ensure authenticity of the User Data and the
their exchange between the TOE and the
represented be either EIS or ATT or SGT) aft
Authentication. It shall happen by enabling such a verifica
side (at receiving by the terminal) and by an active verificatio
(at receiving by the 63
This
4.1.3 OT
The TOE must ensure co y
granting read access only to authorised rightful terminals (
according to the effective terminal authorisation level (CHAT) p
terminal connected65
.
58
where appropriate, see Table 3 above
59
where appropriate, see Table 3 above
60
where appropriate, see Table 3 above
61
verification of SOC
62
where appropriate, see Table 3 above
63
secure messaging after the chip authentication, see also [11], sec. 4.4.2
64
where appropriate, see Table 3 above
65
The authorisation of the terminal connected (CHAT) is drawn from the terminal certificate chain used for the successful terminal
authentication as defined in [11], sec. 4.4 and shall be a non-strict subset of the authorisation defined in the Terminal Certificate (CT),
the Document Verifier Certificate (CDV) and the CCVCA in the certificate chain up to the Country Verifying Certification Authority of the
ID_Card Issuer (receiving PKI branch of the ID_Card Issuer). The effective terminal authorisation can additionally be restricted by the
ID_Card holder by a respective input at the terminal.
4 Security Objectives
Security Target Lite STARCOS 3.5 ID GCC C1 Page 33 of 128
Version 2.5 14.12.2010
The TOE must ensure confidentiality of the User Data a
their exchange between the TOE and the Service Provi
represent
nd the TSF-data68
during
der connected (and
ed be either EIS or ATT or SGT) after the Terminal- and the Chip
owing application(s): ePassport, eID, eSign.
4.1.4 OT.
means of unambiguous
entifying the ID_Card remotely through establishing or listening to a
TOE without knowledge of
the correct values of shared passwords (CAN, MRZ, eID-PIN, eID-PUK) in
, eID, eSign.
4.1.5 OT. _Proof Proof of ID_Card authenticity
henticity of the
ssuing PKI branch of
ntication as defined
, eID, eSign.
es the ID_Card’s chip
knowledge, i.e. a
Chip Authentication Private Key as TSF-data. The terminal shall have the
t of the ID_Card’s
on Public Key
y (SKPICC). This
ublic Key stored
e Card Security
) signed by the Document Signer.
ay not be used in TOE
er (i) to manipulate or to disclose the
e the TSF-data stored
dify) soft-coded security
eID, eSign.
4.1.7 OT.Prot_Inf_Leak Protection against Information Leakage
The TOE must provide protection against disclosure of confidential User Data
or/and TSF-data stored and/or processed by the ID_Card
 by measurement and analysis of the shape and amplitude of signals
or the time between events found by measuring signals on the
electromagnetic field, power consumption, clock, or I/O lines,
 by forcing a malfunction of the TOE and/or
 by a physical manipulation of the TOE.
Authentication.
This item concerns the foll
ID_Card_Tracing Tracing ID_Card
The TOE must prevent gathering TOE tracing data by
id
communication via the contactless interface of the
advance.
This item concerns the following application(s): ePassport
Chip_Auth
The TOE must enable the terminal connected to verify the aut
ID_Card as a whole device as issued by the ID_Card Issuer (i
the ID_Card Issuer) by means of the Passive and Chip Authe
in [11], sec. 4.3.
This item concerns the following application(s): ePassport
Application Note 11: The OT.Chip_Auth_Proof impli
to have a unique secret to prove its authenticity by
reference data to verify the authentication attemp
chip, i.e. a certificate for the respective Chip Authenticati
(PKPICC) fitting to the Chip Authentication Private Ke
certificate is provided by (i) the Chip Authentication P
on the TOE and (ii) the hash value of this PKPICC in th
Object (SOC
4.1.6 OT.Prot_Abuse-Func Protection against Abuse of Functionality
The TOE must prevent that functions of the TOE, which m
operational phase, can be abused in ord
User Data stored in the TOE, (ii) to manipulate or to disclos
in the TOE, (iii) to manipulate (bypass, deactivate or mo
functionality of the TOE.
This item concerns the following application(s): ePassport,
4 Security Objectives
Page 34 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
This item concerns the following application(s): ePassport, eID, eSign.
4.1.8 OT.P ampering
grity of the User
y means of
representing a direct physical
g bonded (using
or
pes of physical
s used in solid-state
hysics research and IC failure analysis),
ctionality, as well as
olled manipulation of memory contents (User Data, TSF-data)
with a prior
e design and its properties and
D, eSign.
4.1.9 OT.P nctions
event its operation
secure operation
ors in the TOE.
The environmental conditions may include external energy (esp.
y contacts), clock frequency or
eSign.
TOE security objectives address the aspects of identified threats to
e TOE
Personalisation
rovide a unique
card issuing life
This item concerns the following application(s): ePassport, eID, eSign.
lisation of ID_Card
The TOE must ensure that the user data (amongst other those concerning the
ID_Card holder67
) and the TSF-data permanently stored in the TOE can be
written by authorised Personalisation Agents only. The Card Security Object can
be updated by authorised Personalisation Agents (in the role of DS), if the
related data have been modified. The optional eSign application can additionally
rot_Phys-Tamper Protection against Physical T
The TOE must provide protection of confidentiality and inte
Data, the TSFdata and the ID_Card’s Embedded Software b
 measuring through galvanic contacts
probing on the chip’s surface except on pads bein
standard tools for measuring voltage and current)
 measuring not using galvanic contacts, but other ty
interaction between electrical charges (using tool
p
 manipulation of the hardware and its security fun
contr
 reverse-engineering to understand th
functionality.
This item concerns the following application(s): ePassport, eI
rot_Malfunction Protection against Malfu
The TOE must ensure its correct operation. The TOE must pr
outside the normal operating conditions where reliability and
have not been proven or tested. This is to prevent functional err
electromagnetic) fields, voltage (on an
temperature.
This item concerns the following application(s): ePassport, eID,
The following
be countered involving TOE’s environment.
4.1.10 OT.Identification Identification of th
The TOE must provide means to store Initialisation66
and Pre-
Data in its non-volatile memory. The Initialisation Data must p
identification of the IC during the manufacturing and the
phases of the ID_Card.
4.1.11 OT.Personalisation Persona
66
amongst other, IC Identification data
67
biographical and biometrical data as well as the SCD, if the eSign is operational.
4 Security Objectives
Security Target Lite STARCOS 3.5 ID GCC C1 Page 35 of 128
Version 2.5 14.12.2010
be activated on the TOE on behalf of the CSP issuing this eSign application, if
eID, eSign.
The current ST also includes all security objectives for the TOE of the SSCD PP
[7]. These items are applicable, if the eSign application is operational.
the ID_Card holder had applied for this.
This item concerns the following application(s): ePassport,
Objective identifier Comments
OT.Lifecycle_Se s the following
application(s):
– eSign
curity concern
OT.SCD/SVD_G concerns the following
application(s):
en
– eSign
OT.SCD_Uniqu concerns the following
application(s):
e
– eSign
OT.SCD_SVD_C concerns the following
tion(s):
– eSign
orresp
applica
OT.SCD_Secrec
– eSign
y concerns the following
application(s):
OT.Sig_Secure
application(s):
– eSign
concerns the following
OT.Sigy_SigF concerns the following
application(s):
– eSign
OT.DTBS_Integ concerns the following
rity_ TOE
application(s):
– eSign
OT.EMSEC_Design concerns the following
application(s):
– eSign
OT.Tamper_ID concerns the following
application(s):
– eSign
OT.Tamper_Resistance concerns the following
application(s):
– eSign
4 Security Objectives
Page 36 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Table 8 TOE objectives taken over from [7]
bjectives for Operational
I. ID_Card Issuer as the general responsible
The ID_Card Issuer as the general responsible for the global security policy
he following security objectives for the TOE
4.2.1
e using the terminals
eID.
ssuing) branch
following security
Note 9 above):
4.2.2 Card by
infrastructure as
ehalf and according to the policy of the ID_Card
air, (ii) ensure the
ertificates in a
of the CSCA
S) available to the
mestic) CVCA as well
he foreign CVCAs under agreement68
. Hereby authenticity and integrity
erate
Pair, (ii) ensure the secrecy of
Public Key
of genuine ID_Cards
l environment only. The digital signature in the Card
Security Object relates to all security information objects according to [11],
The CSCA must issue its certificates exclusively to the rightful organisations (DS)
and DSs must sign exclusively correct Card Security Objects having to be stored
on ID_Cards.
This item concerns the following application(s): ePassport, eID.
This item also covers OE.CGA_SSCD and partially OE.SVD_Auth from Table 9
below for the eSign application.
4.2 Security O
Environment
related will implement t
environment:
OE.Legislative_Compliance
The ID_Card Issuer must issue the ID_Cards and approv
complying with all applicable laws and regulations.
This item concerns the following application(s): ePassport,
II. ID_Card Issuer and CSCA: ID_Card’s PKI (i
The ID_Card Issuer and the related CSCA will implement the
objectives for the TOE environment (see also the Application
OE.Passive_Auth_Sign Authentication of ID_
Signature
The ID_Card Issuer has to establish the necessary public key
follows: the CSCA acting on b
Issuer must (i) generate a cryptographically secure CSCA Key P
secrecy of the CSCA Private Key and sign Document Signer C
secure operational environment, and (iii) make the Certificate
Public Key (CCSCA) and the Document Signer Certificates (CD
ID_Card Issuer, who makes them available to his ow o
as to t
n (d
of these certificates are being maintained.
A Document Signer acting in accordance with the CSCA policy must (i) gen
a cryptographically secure Document Signing Key
the Document Signer Private Key, (iii) hand over the Document Signer
to the CSCA for certification, (iv) sign Card Security Objects
in a secure operationa
Appendix A.
68
CVCAs represent the roots of the receiving branch, see below.
4 Security Objectives
Security Target Lite STARCOS 3.5 ID GCC C1 Page 37 of 128
Version 2.5 14.12.2010
4.2 ey
licy has to (i)
C, PKPICC} used for
ign and store the Chip
n Public Key Info (Appendix
erify the authenticity of the
f the Chip
bject.
Key Pairs {SKID,
ted Identification Key SKID is to
ion Key PKID – in a
See also Application Note 3 and Table 2, object #1.
(s): ePassport, eID.
_Auth from Table 9
4.2
gents acting on his
t identity of the ID_Card holder and create the
he biometric reference data of the
on
personalisation) for the ID_Card holder as defined in [11], (iv) write the
n the Card Security
eID.
also partially covers OE.CGA_QCert from Table 9 below for the eSign
application.
ard Issuer and CVCA: Terminal’s PKI (receiving) branch
s the foreign
plement the
also the Application
uthentication Authentication of rightful
The ID_Card Issuer has to establish the necessary public key infrastructure as
follows: the domestic CVCA acting on behalf and according to the policy of the
ID_Card Issuer as well as each foreign CVCA acting under agreement with the
ID_Card Issuer and according to its policy must (i) generate a cryptographically
secure CVCA Key Pair, (ii) ensure the secrecy of the CVCA Private Key and sign
Document Verifier Certificates in a secure operational environment, (iii) make
.3 OE.Chip_Auth_Key Chip Authentication K
A Document Signer acti in accordance with the CSCA po
generate the ID_Card’s Chip Authentication Key Pair {SKPIC
as defined in [11], sec. 4.3, (ii) s
Authentication Public Key in the Chip Authenticatio
A of [11]) and (iii) support Service Providers to v
ng
the chip authentication
A
ID_Card’s chips used for genuine ID_Cards by certification o
uthentication Public Key by means of the Card Security O
A Document Signer has also to manage Restricted Identification
PKID [11], sec. 2.3 and 4.5: the private Restric
store in the TOE, whereby the public Restricted Identificat
database of the DS.
This item concerns the following application
This item also covers OE.CGA_SSCD and partially OE.SVD
below for the eSign application.
.4 OE.Personalisation Personalisation of ID_Card
The ID_Card Issuer must ensure that the Personalisation A
behalf (i) establish the correc
biographical data for the ID_Card69
, (ii) enrol t
70
ID_Card holder , (iii) write a subset of these data on the physical Identificati
Card (optical personalisation) and store them in the ID_Card (electronic
document details data, (v) write the initial TSF data, (vi) sig
Object defined in [8] (in the role of a DS).
This item concerns the following application(s): ePassport,
This item
III. ID_C
The ID_Card Issuer and the related domestic CVCA as well a
CVCAs under agreement (with the ID_Card Issuer)71
will im
following security objectives for the TOE environment (see
Note 10 above):
4.2.5 OE.Terminal_A
terminals
69
relevant for the ePassport, the eID and the eSign applications
70
relevant for the ePassport application
71
the form of such an agreement may be of formal and informal nature; the term ‘agreement’ is used in the current ST in order to
reflect an appropriate relationship between the parties involved.
4 Security Objectives
Page 38 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
the Certificate of the CVCA Public Key (CCVCA) available to t
(who make it available to his own CSCA72
as well as to
Verifiers, (iv) distribute Document Verifier Certificates (CDV
respective Document Verifiers. H by authenticity an
he ID_Card Issuer
the respective Document
) back to the
d integrity of these
a Revocation
d 4.573
.
CVCA policy must
y Pair, (ii) ensure
over the Document
, (iv) sign the Terminal
n a secure operational
e to relevant for
d the eSign applications relevant for the ePassport
nd informal
n order to reflect an
A represents the root
ed Identification please see Application Note 3 and Table 2, object
certified. This
level of pertained
has also to
11], sec. 2.3 and
I (and, hence, acting in accordance
thentication Key
l Authentication Private
Terminal Authentication Public Keys {PKPCD} to the DV
uthentication Private Keys for
(v) install CT, CDV
CVCA in the rightful terminals operated by him.
cates exclusively to the rightful organisations (DV)
htful equipment
ncerns the following application(s): ePassport, eID.
low for the eSign
application.
rminal operating
ting in the current PKI (and, hence, acting in
ance with the policy of the related DV) must operate their terminals as
follows:
1. They use their terminals (inspection systems, authentication or
signature terminals, cf. Table 1 above) as defined in [11], sec. 3.2.
ere
certificates are being maintained. A CVCA has also to manage
Sector Key Pair {SKRevocation, PKRevocation} [11], sec. 2.3 an
A Document Verifier acting in accordance with the respective
(i) generate a cryptographically secure Document Verifying Ke
the secrecy of the Document Verifying Private Key, (iii) hand
Verifier Public Key to the respective CVCA for certification
Certificates (CT) of the terminals being managed by him i
environment only, and (v) make CT, CDV and CCVCA availabl
the ePassport, the eID an
application the form of such an agreement may be of formal a
nature; the term ‘agreement’ is used in the current ST i
appropriate relationship between the parties involved. CSC
of the issuing branch, see above.
For Restrict
#1 the respective Service Providers operating the terminals
certificate chain contains, amongst other, the authorisation
terminals for differentiated data access on the ID_Card. A DV
manage Sector’s Static Key Pairs {SKSectorNN, PKSectorNN} [
4.574
.
A Service Provider participating in this PK
with the policy the related DV) must (i) generate Terminal Au
Pairs {SKPCD, PKPCD}, (ii) ensure the secrecy of Termina
Keys, (iii) hand over the
for certification, (iv) securely use the Terminal A
the terminal authentication as defined in [11], sec. 4.4 and
and C
CVCAs must issue their certifi
and DVs must issue their certificates exclusively to the rig
(terminals)75
.
This item co
This item also partially covers OE.SVD_Auth from Table 9 be
4.2.6 OE.Terminal Te
The Service Providers participa
accord
72
CSCA represents the root of the issuing branch, see above.
73
For Restricted Identification please see Application Note 3 and Table 2, object #1
74
For Restricted Identification please see Application Note 3 and Table 2, object #1.
75
This rule is relevant for T.Skimming
4 Security Objectives
Security Target Lite STARCOS 3.5 ID GCC C1 Page 39 of 128
Version 2.5 14.12.2010
2. Their terminals implement the termin arts of th
[11], sec. 4.2, o e Terminal Authentication
of the Passi Authentication [11], sec. 3.4 (by v
signature of the Card Security Object) and of
Authentication protocol [11], sec. 4.376
and use
A rightfu
al p
f th
ve
nal
fin
e PACE protocol
protocol [11], sec. 4.4,
erification of the
the Chip
them in this order77
.
l terminal uses randomly and (almost) uniformly selected
ting ephemeral keys
entials needed for the
ation key pair {SKPCD,
er PKPCD issued by the
erminal certificate
ss to the data
to perform the
c. 4.4.
ing Public Key and the
CCSCA and CDS) in order
of the ID_Card
).
gn-PIN, DTBS) to the
successfully
the Terminal
78
ust ensure confidentiality and
onfidentiality of
PINs/PUKs, integrity of PKI certificates and DTBS, etc.), where it is
necessary for a secure operation of the TOE according to the
current ST.
eID.
D, OE.HID_TC_VAD,
ble 9 below for the
IV. ID_Card holder Obligations
r Obligations
er has to keep his or her verification values of eID-PIN and eID-
ecret. The ID_Card Holder may reveal, if necessary, his or her verification
values of CAN and MRZ to an authorised person or device who definitely act
according to respective regulations and are trustworthy.
This item concerns the following application(s): ePassport, eID.
nonces, if required by the protocols (for genera
for Diffie-Hellmann).
3. Their terminals securely store the related cred
terminal authentication (terminal authentic
PKPCD} and the termi certificate (CT) ov
DV related as well as CDV and CCVCA; the t
includes the authorisation mask (CHAT) for acce
stored on the ID_Card) in order to enable and
terminal authentication as de ed in [11], se
4. Their terminals securely store the Country Sign
Document Signer Public Key (in form of
to enable and to perform Passive Authentication
(determination of the authenticity of PKPICC, [11], sec. 4.3.1.2
5. Their terminals must not send assets (e.g. eSi
TOE within the PACE session, but first having
performed the Chip Authentication after
Authentication .
6. Their terminals and its environment m
integrity of respective data handled by it (e.g. c
This item concerns the following application(s): ePassport,
This item also partially covers OE.CGA_TC_SV
OE.SCA_TC_DTBS, OE.SVD_Auth, OE.DTBS_Intend from Ta
eSign application.
4.2.7 OE.ID_Card-Holder ID_Card holde
The ID_Card Hold
PUK s
76
The Passive Authentication is considered to be part of the Chip Authentication (CA) Protocol within this PP
77
This order is only commensurate with the branch rightmost in Fig. 3.1, sec. 3.1.1 of [11]. Other branches of
this figure are not covered by the security policy of the current ST.
78
This rule is relevant for T.Skimming
4 Security Objectives
Page 40 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
This item also partially covers OE.Signatory from Table 9 below for the eSign
s environment of
the SSCD PP [7] (please regard Table 1 above). These items are applicable, if the
eSign application is operational.
application.
The current ST also includes all security objectives for the TOE’
Objective
identifier
Comments
OE.SVD_Au lowing
th concerns the fol
application(s):
– eSign
OE.CGA_Q enforces the property #3 (CSP
.Trustworthy_PKI
cerns the following
application(s):
Cert
duties) of P
con
– eSign
OE.DTBS_In concerns the following
application(s):
tend
– eSign
OE.Signatory concerns the following
application(s):
– eSign
OE.SSCD_P
vice
ing
tal objective shall
) the CSP checks by means of the
evice
ed by the applicant for the
icate examples
SSCD and is able to prove this
identity;
(ii) CGA detects alteration of the
SVD imported from the TOE and
verifies the
correspondence between the SCD
in the SSCD of the
signatory and the SVD in the
(qualified) certificate.
rov_Ser concerns the follow
application(s):
– eSign
This environmen
be achieved in such a
way that
(i
CGA, whether the d
present
(qualified) certif
holds unique identification as
4 Security Objectives
Security Target Lite STARCOS 3.5 ID GCC C1 Page 41 of 128
Version 2.5 14.12.2010
Objective
identifier
Comments
OE.HID_V concerns the following
application(s):
al objective shall
ed in such a
ides the human
r
d HID
fidentiality of the VAD
as needed by the authentication
ployed including export to the
TOE by means of a trusted
AD
– eSign
This environment
be achiev
way that HID prov
interface for use
authentication an
ensures con
method
em
channel.
OE.DTBS_ s the following
ental objective shall
ch a
the TOE for the
protection of the
integrity of the DTBS to ensure
DTBSrepresentation
e altered undetected in
Protect concern
application(s):
– eSign
This environm
be achieved in su
way that SCA provides a trusted
channel to
that the
cannot b
transit
between the SCA and theTOE.
T
4.3 Security Objective Rationale
The following table provides an overview for security objectives coverage (TOE
and its environment) also giving an evidence for sufficiency and necessity of the
objectives defined. It shows that all threats and OSPs are addressed by the
security objectives. It also shows that all assumptions are addressed by the
security objectives for the TOE environment.
able 9 TOE’s environment objectives taken over from [7]
4 Security Objectives
Page 42 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
tion
OT.Data_Integrity
nticity
nfidentiality
Tracing
th_Proof
use-Func
ys-Tamper
OE.Personalisation
n
ey
OE.Terminal_Authentication
OE.Terminal
OE.ID_Card-Holder
OE.Legislative_Compliance
OE.CGA_QCert
([7])
79
OT.Identifica
OT.Personalisation
OT.Data_Authe
OT.Data_Co
OT.ID_Card_
OT.Chip_Au
OT.Prot_Ab
OT.Prot_Inf_Leak
OT.Prot_Ph
OT.Prot_Malfuntion
OE.Passive_Auth_Sig
OE.Chip_Auth_K
T.Skimming x x x x x x
T.Eavesdropping x
T.ID_Card_Tracing x x
T.Forgery x x x
x x x x
T.Counterfeit x
x x
T.Abuse-Func x
T.Information_Le x
akage
T.Phys-Tamper x
T.Malfunction x
P.Pre-Operational x x x
x
P.Terminal x
P.ID_Card_PK x x
I
P.Terminal_P x
KI
P.Trustworth
I x x
y_PK
x
Table 10 Security Objective Rationale
A detailed justification required for suitability of the security o
with the security problem definition is given below.
bjectives to coup
The threat T.Skimming addresses accessing the User Data (stored on the TOE or
en the TOE and the Service Provider) using the TOE’s
contactless interface. This threat is countered by the security objectives
OT.Data_Integrity, OT.Data_Authenticity and OT.Data_Confidentiality through
the Terminal- and the Chip Authentication. The objective
OE.Terminal_Authentication sets a prerequisite up for an effective terminal
authentication (its property ‘CVCAs must issue their certificates exclusively to
the rightful organisations (DV) and DV must issue their certificates exclusively to
the rightful equipment (terminals)’). The objective OE.Terminal sets a
prerequisite up that no assets will be transferred between the TOE and the
transferred betwe
79
This item is applicable, if the eSign application is operational.
4 Security Objectives
Security Target Lite STARCOS 3.5 ID GCC C1 Page 43 of 128
Version 2.5 14.12.2010
Service Provider before the Chip Authentication has succe
accomplished (in its property ‘Their (Service Provider’s – rem
terminals must not send assets (e.g. eSign-PIN, DTBS) to th
PACE session, but first having successfully performed the chi
The objective OE.ID_Card-Holder ensure
ssfully been
ark of the author)
e TOE within the
p authentication’).
s that a PACE session can only be
orised person or
pping addresses listening to the communication between
a transferred there.
_Confidentiality
racing data identifying it
via the contactless
e TOE, whereby the attacker does not a priori know the correct
rectly countered by
tracing data) and
the correct values of
n of
xchanged between
ersonalisation
to the trustworthy
protect the integrity
Data or/and TSF-data as
aimed by the security objectives OT.Data_Integrity and OT.Data_Authenticity,
.Prot_Abuse-Func
F-data stored on the
cording to OE.Terminal and
rity Object as aimed
egrity and
of the data received from the TOE.
ed copy or
countered by the chip
chip authentication
aimed by
Provider’s terminals
the authenticity of the
misusing TOE’s functionality to
as well as to disable or
jective
OT.Prot_Abuse-Func ensures that the usage of functions having not to be used
in the operational phase is effectively prevented.
The threats T.Information_Leakage, T.Phys-Tamper and T.Malfunction are
typical for integrated circuits like smart cards under direct attack with high
attack potential. The protection of the TOE against these threats is obviously
addressed by the directly related security objectives OT.Prot_Inf_Leak,
OT.Prot_Phys-Tamper and OT.Prot_Malfunction, respectively.
The OSP P.Pre-Operational is enforced by the following security objectives:
OT.Identification is affine to the OSP’s property ‘traceability before the
established either by the ID_Card holder itself or by an auth
device, and, hence, cannot be captured by an attacker.
The threat T.Eavesdro
the TOE and a rightful terminal in order to gain the User Dat
This threat is countered by the security objective OT.Data
through the Chip Authentication.
The threat T.ID_Card_Tracing addresses gathering TOE t
remotely by establishing or listening to a communication
interface of th
values of CAN, MRZ, eID-PIN and eID-PUK). This threat is di
security objectives OT.ID_Card_Tracing (no gathering TOE
OE.ID_Card-Holder (the attacker does not a priori know
the shared passwords).
The threat T.Forgery addresses the fraudulent, complete or partial alteratio
the User Data or/and TSF-data stored on the TOE or/and e
the TOE and the Service Provider. The security objective OT.P
requires the TOE to limit the write access for the ID_Card
Personalisation Agent (cf. OE.Personalisation). The TOE will
and authenticity of the stored and exchanged User
respectively. The objectives OT.Prot_Phys-Tamper and OT
contribute to protecting integrity of the User Data or/and TS
TOE. A Service Provider operating his terminals ac
performing the Passive Authentication using the Card Secu
by OE.Passive_Auth_Sign will be able to effectively verify int
authenticity
The threat T.Counterfeit addresses the attack of unauthoris
reproduction of the genuine ID_Card. This attack is
authenticity proof as aimed by OT.Chip_Auth_Proof using a
key pair to be generated within the issuing PKI branch as
OE.Chip_Auth_Key. According to OE.Terminal the Service
has to perform the Chip Authentication Protocol to verify
ID_Card.
The threat T.Abuse-Func addresses attacks of
manipulate or to disclosure the stored User- or TSF-data
to bypass the soft-coded security functionality. The security ob
4 Security Objectives
Page 44 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
operational phase’; OT.Personalisation and OE.Personalisation together enf
the OSP’s properties ‘correctness of the User- and the TSF-dat
‘authorisation of Personalisation Agents’; OE
orce
a stored’ and
.Legislative_Compliance is affine to
OE.Terminal, whereby
licable.
Security Object) and
ID_Card’s Chip Authentication Key Pairs).
eiving PKI branch as
rminal_Authentication.
_Sign (for CSCA,
KI branch), by OE.Terminal_Authentication (for CVCA, receiving PKI
branch) and by OE.CGA_QCert (see [7]).
The rationale related to the security objectives taken over from [7] are exactly
the same as given for the respective items of the security policy definitions in
sec. 8.4 of [7].
the OSP’s property ‘compliance with laws and regulations’.
The OSP P.Terminal is obviously enforced by the objective
the one-toone mapping between the related properties is app
The OSP P.ID_Card_PKI is enforced by establishing the issuing PKI branch as
aimed by the objectives OE.Passive_Auth_Sign (for the Card
OE.Chip_Auth_Key (for managing the
The OSP P.Terminal_PKI is enforced by establishing the rec
aimed by the objective OE.Te
The OSP P.Trustworthy_PKI is enforced by OE.Passive_Auth
issuing P
5 Extended Components Definition
Security Target Lite STARCOS 3.5 ID GCC C1 Page 45 of 128
Version 2.5 14.12.2010
5Extended Components
Definition
defined as extensions to CC part 2. All
rom [6].
5.
E, the family FAU_SAS
ecurity audit) is defined here. This family describes the
data. It has a more general
se it does not necessarily require the data to be
ive specific details of the
the audit records.
The family ‘Audit data storage (FAU_SAS)’ is specified as follows:
FAU_SAS Audit data storageFamily behaviour
ctional requirements for the storage of audit data.
This protection profile uses components
these extended components are drawn f
1 Definition of the Family FAU_SAS
To describe the security functional requirements of the TO
of the class FAU (S
functional requirements for the storage of audit
approach than FAU_GEN, becau
generated by the TOE itself and because it does not g
content of
This family defines fun
Component levelling
FAU_SAS.1 Requires the TOE to provide the possibility to store audit data.
ment activities foreseen.
Hierarchical to: No other components
sers] with the
capability
to store [assignment: list of audit information] in the audit records.
5.2 Definition of the Family FCS_RND
To describe the IT security functional requirements of the TOE, the family
FCS_RND of the class FCS (Cryptographic support) is defined here. This family
describes the functional requirements for random number generation used for
cryptographic purposes. The component FCS_RND.1 is not limited to generation
Management: FAU_SAS.1
There are no manage
Audit: FAU_SAS.1
There are no actions defined to be auditable.
5.1.1.1 FAU_SAS.1 Audit storage
Dependencies: No dependencies
FAU_SAS.1.1 The TSF shall provide [assignment: authorised u
5 Extended Components Definition
Page 46 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
of cryptographic keys unlike the component FCS_CKM.1. The similar
.
ers (FCS_RND)’ is specified as follows:
5.2.1
fines quality requirements for the generation of random numbers
intended to be used for cryptographic purposes.
component FIA_SOS.2 is intended for non-cryptographic use
The family ‘Generation of random numb
FCS_RND Generation of random numbers
Family behaviour
This family de
Component levelling:
FCS_RND.1 Generation of random numbers requires that random numbers
ined quality metric.
seen.
5.2.1.1 FCS_RND.1 Quality metric for random numbers
random numbers
5.3
OE, the family
entication) is defined here. This
roof of the claimed identity for
ernal entity, where the other families of
IA address the verification of the identity of an external entity.
n verification of
e functionality of
ove its own identity. The following paragraph defines the family
FIA_API in the style of the Common Criteria part 2 (cf. [3], chapter ‘Extended
components definition (APE_ECD)’) from a TOE point of view.
5.3.1 FIA_API Authentication Proof of Identity
Family behaviour
This family defines functions provided by the TOE to prove its identity and to be
verified by an external entity in the TOE IT environment.
Component levelling:
meet a def
Management: FCS_RND.1
There are no management activities fore
Audit: FCS_RND.1
There are no actions defined to be auditable.
Hierarchical to: No other components
Dependencies: No dependencies
FCS_RND.1.1 The TSF shall provide a mechanism to generate
that meet [assignment: a defined quality metric].
Definition of the Family FIA_API
To describe the IT security functional requirements of the T
FIA_API of the class FIA (Identification and auth
family describes the functional requirements for p
the authentication verification by an ext
the class F
Other families of the class FIA describe only the authenticatio
user’s identity performed by the TOE and do not describe th
the TOE to pr
5 Extended Components Definition
Security Target Lite STARCOS 3.5 ID GCC C1 Page 47 of 128
Version 2.5 14.12.2010
FIA_API.1 Authentication Proof of Identity.
he following actions could be considered for the management functions in
anagement of authentication information used to prove the claimed
ed to be auditable.
5.3.1.1
FIA_API.1.1 The TSF shall provide a [assignment: authentication mechanism] to
le].
5.
r the test features
of the TOE. The new functional requirements were defined in the class FMT
ent of functions of the TSF. The
the technical mechanism used in the TOE show that no other class
the specific issues of preventing abuse of functions by
heir availability.
as follows:
5.4 mited capabilities and availability
Family behaviour
This family defines requirements that limit the capabilities and availability of
access to
ires the functions
emselves to be designed in a specific manner.
Management: FIA_API.1
T
FMT: M
identity.
Audit: FIA_API.1
There are no actions defin
FIA_API.1 Authentication Proof of Identity
Hierarchical to: No other components
Dependencies: No dependencies
prove the identity of the [assignment: authorised user or ro
4 Definition of the Family FMT_LIM
The family FMT_LIM describes the functional requirements fo
because this class addresses the managem
examples of
is appropriate to address
limiting the capabilities of the functions and by limiting t
The family ‘Limited capabilities and availability (FMT_LIM)’ is specified
.1 FMT_LIM Li
functions in a combined manner. Note, that FDP_ACF restricts
functions whereas the Limited capability of this family requ
th
Component levelling:
FMT_LIM.1 Limited capabilities requires that the TSF is built to provide only the
capabilities (perform action, gather information) necessary for its genuine
purpose.
FMT_LIM.2 Limited availability requires that the TSF restrict the use of functions
(refer to Limited capabilities (FMT_LIM.1)). This can be achieved, for instance, by
removing or by disabling functions in a specific phase of the TOE’s life-cycle.
Management: FMT_LIM.1, FMT_LIM.2
5 Extended Components Definition
Page 48 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
There are no management activities foreseen.
ined to be auditable.
5.4.1.1
a manner that limits their capabilities
ith ‘Limited availability (FMT_LIM.2)’ the following policy
ited capability and availability policy].
5.4.1
t limits their availability
)’ the following
ilability policy].
ts FMT_LIM.1 and
_LIM.2 assume existence of two types of mechanisms (limited
ities and limited availability) which together shall provide
This also allows that
n its user
policy is
or conversely
moved or
e related policy.
5.5
lass FPT (Protection of the TSF)
is defined here to describe the IT security functional requirements of the TOE.
tacks against secret data stored in and used by the TOE
tack is based on external observable physical phenomena of the
TOE. Examples of such attacks are evaluation of TOE’s electromagnetic
radiation, simple power analysis (SPA), differential power analysis (DPA), timing
attacks, etc. This family describes the functional requirements for the limitation
of intelligible emanations being not directly addressed by any other component
of CC part 2 [2].
The family ‘TOE Emanation (FPT_EMSEC)’ is specified as follows:
5.5.1 FPT_EMSEC TOE emanation
Family behaviour
Audit: FMT_LIM.1, FMT_LIM.2
There are no actions def
FMT_LIM.1 Limited capabilities
Hierarchical to: No other components
Dependencies: FMT_LIM.2 Limited availability
FMT_LIM.1.1 The TSF shall be designed in
so that in conjunction w
is enforced [assignment: Lim
.2 FMT_LIM.2 Limited availability
Hierarchical to: No other components
Dependencies: FMT_LIM.1 Limited capabilities
FMT_LIM.2.1 The TSF shall be designed in a manner tha
so that in conjunction with ‘Limited capabilities (FMT_LIM.1
policy is enforced [assignment: Limited capability and ava
Application Note 12: The functional requiremen
FMT
capabil
protection in order to enforce the related policy.
(i) the TSF is provided without restrictions in the product i
environment, but its capabilities are so limited that the
enforced
(ii) the TSF is designed with high functionality, but is re
disabled in the product in its user environment.
The combination of both the requirements shall enforce th
Definition of the Family FPT_EMSEC
The family FPT_EMSEC (TOE Emanation) of the c
The TOE shall prevent at
where the at
5 Extended Components Definition
Security Target Lite STARCOS 3.5 ID GCC C1 Page 49 of 128
Version 2.5 14.12.2010
This family defines requirements to mitigate intelligible emanations.
Component levelling:
FPT_EMSEC.1 TOE emanation has two constituents:
elligible emissions
or user data.
ation requires to not emit interface emanation
ser data.
There are no management activities foreseen.
defined to be auditable.
5.5.
emissions] in
excess of [assignment: specified limits] enabling access to [assignment: list of
types of TSF data] and [assignment: list of types of user data].
FPT_EMSEC.1.2 The TSF shall ensure [assignment: type of users] are unable to
use the following interface [assignment: type of connection] to gain access to
[assignment: list of types of TSF data] and [assignment: list of types of user
data].
FPT_EMSEC.1.1 Limit of Emissions requires to not emit int
enabling access to TSF data
FPT_EMSEC.1.2 Interface Eman
enabling access to TSF data or u
Management: FPT_EMSEC.1
Audit: FPT_EMSEC.1
There are no actions
1.1 FPT_EMSEC.1 TOE Emanation
Hierarchical to: No other components
Dependencies: No dependencies
FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of
6 Security Requirements
Page 50 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
6 Security Requirements
hat shall be
TOE security requirements shall define
OE needs to satisfy
e CC allows several operations to be performed on security requirements (on
iteration are
e operations is used in
ment, and, thus,
rements are
ns provided by the
y the PP author are
This part of the PP defines the detailed security requirements t
satisfied by the TOE. The statement of
the functional and assurance security requirements that the T
in order to meet th security objectives for the TOE.
Th
e
the component level); refinement, selection, assignment and
defined in sec. 8.1 of Part 1 [1] of the CC. Each of thes
this PP.
The refinement operation is used to add detail to a require
further restricts a requirement. Refinements of security requi
denoted in such a way that added words are in bold text.
The selection operation is used to select one or more optio
CC in stating a requirement. Selections having been made b
denoted as underlined text. Selections filled in by the ST auth
double underlined text
or are denoted as
and a foot note where the selection
are listed.
choices from the PP
ue to an unspecified
nts having been made
The assignment operation is used to assign a specific val
parameter, such as the length of a password. Assignme
by the PP author are denoted by showing as underlined text.
in by the ST author are denoted as double underlined text
Assignments filled
. In
assignment made by the PP authors defines a selection to be
some cases the
performed by the
ST author. Thus this text is underlined and italicised like this.
repeated with varying
enoted by showing a slash “/”, and the iteration
etter readability, the
onents (being not
The iteration operation is used when a component is
operations. Iteration is d
indicator after the component identifier. For the sake of a b
iteration operation may also be applied to some single comp
repeated) in order to indicate belonging of such SFRs to same functional cluster.
ch a case, the iteration operation is applied to only one single component.
SSCD PP [7] and
hese SFRs by
6.1 Security Functional Requirements for the TOE
6.1.1 Overview
In order to give an overview of the security functional requirements in the
context of the security services offered by the TOE, the author of the PP defined
the security functional groups and allocated the functional requirements
described in the following sections to them:
In su
In order to distinguish between the SFRs taken over from the
other SFRs having the same denotation, the author iterated t
‘/SSCD’ or ‘/XXX_SSCD’.
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 51 of 128
Version 2.5 14.12.2010
Security Functional Groups
Security Functional Requirements
concerned
Access control to the User Dat
in the TOE
DP_ACF.1/TRM}
minal
, SGT)
ignature-creation_SFP_SSCD,
reation_SFP_SSCD}
a stored FIA_UAU.1/Rightful_Terminal: Ter
– {FDP_ACC.1/TRM, F
Supported by:
Authentication (EIS, ATT
– {FDP_ACC.1/S
FDP_ACF.1/Signature-c
Secure data exchange between
ID_Card and the Service Provid
connected
/CA: trusted channel
d by:
encryption/decryption
AC
ification
Identification/Authentication
minal: Terminal
T)
the
er
– FCS_COP.1/CMAC: M
generation/ver
– FTP_ITC.1
Supporte
– FCS_COP.1/AES:
– FIA_API.1/CA: Chip
– FIA_UAU.1/Rightful_Ter
Authentication (EIS, ATT, SG
Identification and authentic
users and components
– FIA_UID.1/PACE: PACE Identification
htful_Terminal: Terminal
(EIS, ATT, SGT)
Authentication
(PCT)
_Terminal: Terminal
T, SGT)
thentication
of authentication
authentication
nisms
ication of
_Suspending
ocking: reaction to
l authentication attempts for
using
E: reaction to unsuccessful
empts for establishing
PACE
munication using non-blocking
authentication
and authorisation data
– FIA_UID.1/SSCD: Identification of ID_Card
holder as Signatory (eSign-PIN)
– FIA_UIA.1/SSCD: Authentication of
ID_Card
holder as Signatory (eSign-PIN)
– FIA_AFL.1/SSCD: Blocking of the
Signatory’s
RAD (eSign-PIN)
ation of
– FIA_AFL.1/eID-PIN
– FIA_AFL.1/eID-PIN_Bl
(PCT)
– FIA_UID.1/Rig
Identification
– FIA_UAU.1/PACE: PACE
– FIA_UAU.1/Rightful
Authentication (EIS, AT
– FIA_API.1/CA: Chip
Identification/Au
– FIA_UAU.4: single-use
data
– FIA_UAU.5: multiple
mecha
– FIA_UAU.6: Re-authent
Terminal
unsuccessfu
establishing PACE communication
blocking
authentication data
– FIA_AFL.1/PAC
authentication att
com
6 Security Requirements
Page 52 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Security Functional Groups
Security Functional Requirements
concerned
Supported by:
– FCS_CKM.1/DH_PACE: PACE
inal
TT, SGT)
S_CKM.1/DH_CA: Chip Authentication
-Hellmann key
PACE and Chip
estruction
piration)
random numbers generation
ting tracing while
ng Chip Authentication
tion.
authentication
(PCT)
– FCS_COP.1/SIG_VER: Term
Authentication (EIS
– FC
, A
– FCS_CKM.2/DH: Diffie
distribution within
authentication
– FCS_CKM.4: session keys d
(authentication ex
– FCS_COP.1/SHA: Keys derivation
– FCS_RND.1:
– FTP_ITC.1/PACE: preven
establishi
– FMT_SMR.1: security roles defini
Audit
e
d by:
MT_MTD.1/INI_ENA: Writing Initialisation
-personalisation
– FMT_MTD.1/INI_DIS: Disabling access to
lisation Data in
– FAU_SAS.1 : Audit storag
te
Suppor
– F
and Pre
Initialisation and Pre-persona
the operational phase
Generation of the Signature Key Pair for
y:
CKM.4/SSCD
–
.1/SCD/SVD_Generation_SFP_SSCD,
CD/SVD_Generation_SFP_SSCD}
/SVD_Transfer_SFP_SSCD,
FDP_ACF.1/SVD_Transfer_SFP_SSCD}
the eSign application
– FCS_CKM.1/SSCD
Supported b
– FCS_
{FDP_ACC
FDP_ACF.1/S
– {FDP_ACC.1
Creation of Digital Signatures by the – FCS_COP.1/SSCD
eSign application
Management of and access to T
TSF-data
class FMT.
d by:
tire class FIA: user
SF and Supporte
- The entire
– the en
identification/authentication
Accuracy of the TOE security
functionality/ Self-protection
– The entire class FPT
– FDP_RIP.1: enforced memory/storage
cleaning
– FDP_SDI.2/Persistent_SSCD
– FDP_SDI.2/DTBS_SSCD
Supported by:
– the entire class FMT.
Table 11 Security functional groups vs. SFRs
The following table provides an overview of the keys and certificates used for
enforcing the security policy defined in the current ST:
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 53 of 128
Version 2.5 14.12.2010
Name Data
Receiving PKI branch
Country Verifying
Auth
V
e Country Verifying Certification Authority (CVCA) holds a
Document Verifier
Th
Certification ority private key (SKCVCA) used for signing the
Private Key (SKC CA) Certificates.
Country Verifying
Certification Auth
Public Key (PKCV
to verify the
cument Verifier Certificates.
The TOE stores the Country Veri
ority
CA)
fying Certification Authority
Public Key (PKCVCA) as part of the TSF-data
Do
Country Verifying
Certification Auth
Certificate (CCVC
y Certificate may be
and
Verifying Certification Authority Public
ata, (ii) the coded
ing Certification
and the Certificate
ority
a self-signed certificate or a link certificate (cf. [11]
Glossary). It
contains (i) the Country
A)
access control rights of the Country Verify
The Country Verifying Certification Authorit
Key (PKCVCA) as authentication reference d
Authority, (iii) the Certificate Effective Date
Expiration Date as security attributes.
Document Verifie
Certificate (CDV)
The Document Verifier Certificate CDV is issued by the Country
r
Verifying Certification Authority. It contains (i) the Document
n reference data (ii)
identification as domestic or foreign Document Verifier, the
e Certificate
piration Date as security
ttributes.
Verifier Public Key (PKDV) as authenticatio
an
coded
access control rights of the Document Verifier, th
Effective Date and the Certificate Ex
a
Terminal Certificate (CT)
(CT) is issued by the Document
D) as authentication
The Terminal Certificate
Verifier.
It contains (i) the Terminal Public Key (PKPC
reference data, (ii) the coded access control rights of the
and the
terminal
(EIS, ATT, SGT), the Certificate Effective Date
Certificate
Expiration Date as security attributes.
Issuing PKI branch
Country Signing
Certification Auth
Key Pair and Cert
e ID_Card Issuer
rtificate (CDS) with
rivate Key (SKCSCA)
ing terminal with the
ority
ificate
signs the Document Signer Public Key Ce
the
Country Signing Certification Authority P
and the signature will be verified by receiv
Country Signing Certification Authority of th
Country Signing Certification Authority Pu
The C
blic Key (PKCSCA).
SCA also issues the self-signed CSCA Certificate (CCSCA)
having to be distributed by strictly secure diplomatic means,
see. [8], 5.1.1.
Document Signer Key
Pairs and Certificates
The Document Signer Certificate CDS is issued by the Country
Signing Certification Authority. It contains the Document
Signer Public Key (PKDS) as authentication reference data. The
Document Signer acting under the policy of the CSCA signs the
Card Security Object (SOC) of the ID_Card with the Document
Signer Private Key (SKDS) and the signature will be verified by a
terminal as the Passive Authentication with the Document Signer
Public Key
6 Security Requirements
Page 54 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Name Data
(PKDS).
Chip Authenticatio
Public Key (PKPICC
nd used by the
the Chip Authentication. Its authenticity is verified
uthentication
n
PKPICC is stored in an EF on the ID_Card a
terminal for
) by the terminal in the context of the Passive A
(verification of SOC).
Chip Authenticatio
Private Key (SKPICC)
KPICC} is used for
(DH) according to
ffie-Hellman (ECDH; ECKA key
ag rithm) according to TR-03111 (ver. 1.11, BSI,
ed by the TOE to
n
The Chip Authentication Key Pair {SKPICC, P
Key Agreement Protocol: Diffie-Hellman
PKCS#3 or Elliptic Curve Di
reement algo
2009), cf. [11], table. A.2. SKPICC is us
authenticate itself as authentic ID_Card.
Session keys
PACE Session
(PAC
Key
E-KMAC,
Enc)
authentication
C-mode) agreed
t of the PACE
.3, F.2.2, A.2.3.2.
s
(CMAC-mode) and for message encryption (CB
PACE-K
Secure messaging AES keys for message
between the TOE and terminal (PCT) as resul
a
Protocol, see [11], sec. A
Chip Authenticatio
Session Keys (CA-
KMAC,
entication
BC-mode) agreed
T) as result of the
, F.2.2, A.2.3.2.
n Secure messaging AES keys for message auth
(CMAC-mode) and for message encryption (C
between the TOE and a terminal (EIS, ATT, SG
Chip Authentication Protocol, see [11], sec. A.4
CA-KEnc)
Restricted Identification keys
Restricted
Identification Key
{SKID, PKID}
related private key
specific chip-identifier Sector ID I (pseudo-anonymisation), see
presents user data
rity policy, cf. Table
used for a
quest and should not be stored in the TOE, see
Identification
Pair
[11], sec. 4.1.2, 4.1.3.1, 4.5.1. This key re
(Table 2, object no. 1) within the current secu
2, object #1. The belonging public key PKID is
revocation re
Static Diffie-Hellman key pair, whereby the
SKID is stored in the TOE and used for generation of the sector-
[11], sec. 4.1.2, 4.1.3.1, 4.5.3. For Restricted
please also refer to the Application Note 3.
Signature keys
Signature Creation Key
Pair {
Signature Verification Dat
SCD, SVD}
ation Data (SCD) is represented by a private
cryptographic key being used by the ID_Card holder (signatory)
This key represents user data
(Table 2, object no. 1).
a (SVD) is represented by a public
eing used for
the purpose of verifying an electronic signature.
key pair shall fulfil the relevant requirements
stated in [5].
Signature Cre
to create an electronic signature.
cryptographic key corresponding with SCD and b
Properties of this
Table 12 Keys and Certificates
6.1.2 Class FCS Cryptographic Support
6.1.2.1 Cryptographic key generation (FCS_CKM.1)
6.1.2.1.1 FCS_CKM.1/DH_PACE Cryptographic key generation – Diffie-Hellman for PACE
session keys
Hierarchical to: No other components.
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 55 of 128
Version 2.5 14.12.2010
Dependencies:
[FCS_CKM.2 Cryptographic key distribution or FCS_C
operation]: fulfilled by FCS_CKM.2/DH. FCS_CKM
OP.1 Cryptographic
.4 Cryptographic key
filled by FCS_CKM.4
6.1.2
ate with a specified
[13]
destruction: ful
.1.1.1 FCS_CKM.1.1/ DH_PACE
The TSF shall gener cryptographic keys in ance
accord
cryptographic key generation algorithm ECDH compliant to 80
and specified
cryptographic key sizes 256 bit
81,82
that meet the following: [11], Appendix
A.383
.
This item concerns the following application(s): ePasspor ,
Application Note 13: The TOE generates a shared secret
terminal during the PA protocol, see [1 sec.
protocol may be based on the Diffie-Hellman- Proto
PKCS#3 (i.e. modulo arithmetic based cryptographic
or on the ECDH compliant
t eID, eSign.
value with the
4.2 and A.3. This
col compliant to
algorithm, cf. [17])
to TR-03111 [13] (i.e. the elliptic curve
d [13] for
he AES session keys
CE-KMAC,
o [11], F.2.2 and A.2.3.2 for the TSF required by
OP.1/AES and FCS_COP.1/CMAC.
6.1.2 Diffie-Hellman for Chip
ys
o: No other components.
.1 Cryptographic
.4 Cryptographic key
6.1.2
a specified
3]
CE 1],
te c
cryptographic algorithm ECKA, cf. [11], Appendix A.3 an
details). The shared secret value is used to derive t
for message encryption and message authentication (PA
PACEKEnc) according t
FCS_C
.1.2 FCS_CKM.1/DH_CA Cryptographic key generation –
Authentication session ke
Hierarchical t
Dependencies:
[FCS_CKM.2 Cryptographic key distributi or FCS_COP
on
operation]: fulfilled by FCS_CKM.2/DH. FCS_CKM
destruction: fulfilled by FCS_CKM.4
.1.2.1 FCS_CKM.1.1/DH_CA
The TSF shall genera ryptographic keys in accordance with
cryptographic key generation algorithm ECDH compliant to [1 84
and specified
cryptographic key sizes 256 bit
85,86
that meet the following: [11], Annex A.487
.
ncerns the following application(s): ePassport, eID, eSign.
Application Note 14: The TOE generates a shared secret value with the
terminal during the CA Protocol, see [11], sec. 4.3 and A.4. This protocol
n-Protocol compliant to PKCS#3 (i.e.
modulo arithmetic based cryptographic algorithm, cf. [17]) or on the
ECDH compliant to TR-03111 [13] (i.e. an elliptic curve cryptography
algorithm, cf. [11], Appendix A.4 and [13] for details). The shared secret
This item co
may be based on the Diffie-Hellma
80
[assignment: cryptographic key generation algorithm]
81
[assignment: cryptographic key sizes]
82
For length of p
83
[assignment: list of standards]
84
[assignment: cryptographic key generation algorithm]
85
[assignment: cryptographic key sizes]
86
For length of p
87
[assignment: list of standards]
6 Security Requirements
Page 56 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
value is used to derive the AES session keys f messa
message authentication (CA-KMAC, CA-KEn
and A.2.3.2 for the TSF
or ge encryption and
c) according to the [11], F.2.2
required by FCS_COP.1/AES and
6.1.2.1.3 distribution – Diffie-Hellman
or FCS_CKM.1]: fulfilled by
1/DH_PACE, FCS_CKM.1/DH_CA
6.1.2.1.3.1 1/DH
ccordance with a s
in the list belo
FCS_COP.1/CMAC.
FCS_CKM.2/DH Cryptographic key
Hierarchical to: No other components.
Dependencies:
[FDP_ITC.1 or FDP_ITC.2
FCS_CKM.
FCS_CKM.4: fulfilled by FCS_CKM.4
FCS_CKM.2.
pe
The TSF shall distribute cryptographic keys in a
w
cified
cryptographic key distribution method as specified 88
that meets
and A.3;
the following:
a) PACE: as specified in [11], sec. 4.2
rsion 2) and A.489
.
b) CA: as specified in [11], sec. 4.3 (ve
n(s): ePassport, eID, eSign.
6.1.2.1.4
other components.
Dependencies: [FDP_I
6.1.2.1
specified
lue with zero
This item concerns the following applicatio
FCS_CKM.4 Cryptographic key destruction – Session keys
Hierarchical to: No
TC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]: fulfilled by
FCS_CKM.1/DH_PACE, FCS_CKM.1/DH_CA
.4.1 FCS_CKM.4.1/Session Keys
The TSF shall destroy cryptographic keys in accordance with a
cryptographic key destruction method overwriting the key va
values90
that meets the following: none91
.
This item concerns the following application(s): ePassport, eID, eSign.
Application Note 15: The TOE shall destroy the PACE session keys (i) after
detection of an error in a received command by verification of the MAC, and
ccessful run of the Chip Authentication Protocol. The TOE shall
CA session keys after detection of an error in a received command
by verification of the MAC. The TOE shall clear the memory area of any session
keys before starting the communication with the terminal in a new after-reset-
session as required by FDP_RIP.1.
(ii) after su
destroy the
88
[assignment: cryptographic key distribution method]
89
[assignment: list of standards]
90
[assignment: cryptographic key destruction method]
91
[assignment: list of standards]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 57 of 128
Version 2.5 14.12.2010
6.1.2.2 Cryptographic operation (FCS_COP.1)
6.1.2 tion – Hash for key derivation
ut security attributes, or
tion]: not fulfilled, but justified
ther a respective
Cryptographic key destruction: not fulfilled, but justified
ce, a respective key
6.1.2
.2.1 FCS_COP.1/SHA Cryptographic opera
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data witho
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key genera
A hash function does not use any cryptographic key; hence, nei
key import nor key generation can be expected here.
FCS_CKM.4
A hash function does not use any cryptographic key; hen
destruction cannot be expected here.
.2.1.1 FCS_COP.1.1/SHA
The TSF shall perform hashing92
in accordance with a specifie
algorithm SHA-1 and SHA-25693
d cryptographic
and cryp raphic key
tog sizes none94
that meet
the following: FIPS 180-2 [19]95
.
This item concerns the following application(s): ePassport, eID, eSign.
eral public key for DH
d ([11], table A.2).
ables A.12 and A.13).
ng
92-bit and 256-bit AES
6.1.2 erification
attributes, or
S_CKM.1
Cryptographic key generation]: not fulfilled, but justified
root key PKCVCA used for verifying CDV is stored in the TOE during its
rsonalisation (in the card issuing life phase)98
. Since importing the respective
certificates (CT, CDV) does not require any special security measures except hose
current ST does n t
ent like FDP_ITC.2 for the import function.
FCS_CKM.4 Cryptographic key destruction: not fulfilled, but justified
Cryptographic keys used for the purpose of the current SFR (PKPCD, PKDV, PKCVCA)
Application Note 16: For compressing (hashing) an ephem
(PACE96
and CA97
), the hash function SHA-1 shall be use
The TOE shall implement hash functions either SHA-1 or SHA-224 or SHA-256
for the Terminal Authentication Protocol (cf. [11], t
Within the normative Appendix A of [11], section A.2.3 ‘Key Derivation
Function’, [11] states that the hash function SHA-1 shall be used for derivi
128-bit AES keys, whereas SHA-256 – for deriving 1
keys.
.2.2 FCS_COP.1/SIG_VER Cryptographic operation – Signature v
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security
FDP_ITC.2 Import of user data with security attributes, or FC
The
pe
t
required by the current SFR (cf. FMT_MTD.3 belo o
w), the
contain any dedicated requirem
92
[assignment: list of cryptographic operations]
93
[assignment: cryptographic algorithm]
94
[assignment: cryptographic key sizes]
95
[assignment: list of standards]
96
IDPICC ≡ Comp(ephem-PKPICC-PACE) in [11], sec. 4.4; the public key compression function is defined in table A.2 of [11].
97
Comp(ephem-PKPCD-TA) in [11], sec. 4.3.1.2; the public key compression function is defined in table A.2 of [11].
98
as already mentioned, operational use of the TOE is explicitly in focus of the current ST
6 Security Requirements
Page 58 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
are public keys; they do not represent any secret and, hence, needn’t to be
6.1.2.
destroyed.
2.2.1 FCS_COP.1.1/ SIG_VER
The TSF shall perform digital signature veri tion
fica 99
in accordance with a
256 100
specified cryptographic algorithm ECDSA with SHA- and cryptographic
key sizes 256 bit
101,102
that meet the following: TR-03111[13]
103
.
ing application(s): ePassport, eID, eSign.
6.1.2. ryption AES
urity attributes, or
mport of user data with security attributes, or FCS_CKM.1
tion: fulfilled by
6.1.2.2.3.1 FCS_COP.1.1/AES
ryption
This item concerns the follow
2.3 FCS_COP.1/AES Cryptographic operation – Encryption / Dec
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without sec
FDP_ITC.2 I
Cryptographic key generation]: fulfilled by FCS_CKM.1/DH_PACE,
FCS_CKM.1/DH_CA FCS_CKM.4 Cryptographic key destruc
FCS_CKM.4.
The TSF shall perform secure messaging – encryption and dec 104
in
CBC mode
accordance with a specified cryptographic algorithm AES in 105
and
cryptographic key sizes 128 bit106
that meet the following: FIPS 197 [16] and [11]
Appendix F.2.2107
.
This item concerns the following application(s): ePassport, eID,
Application Note 17: This SFR requires the TOE to implemen
primitive AES for secure messaging with encryption
eSign.
t the cryptographic
of transmitted data. The
n the TOE and the terminal as part of
ng to the FCS_CKM.1/DH_PACE (PACE-KEnc) or
A.2.3.1 the (two-
e messaging. Due to the
y more (cf. [12], sec.
riple-DES in any mode is no longer applicable within this PP.
6.1.2.2.4 FCS_COP.1/CMAC Cryptographic operation – CMAC
rchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
with security attributes, or FCS_CKM.1
tographic key generation]: fulfilled by FCS_CKM.1/DH_PACE,
_CKM.1/DH_CA FCS_CKM.4 Cryptographic key destruction: fulfilled by
FCS_CKM.4.
related session keys are agreed betwee
either the PACE protocol accordi
the Chip Authentication Protocol according to the FCS_CKM.1/DH_CA (CA-
KEnc). Note that in accordance with [11] Appendix F.2.1 and
key) Triple-DES could be used in CBC mode for secur
fact that the (two-key) Triple-DES is not recommended an
1.3), T
Hiera
FDP_ITC.2 Import of user data
Cryp
FCS
99
[assignment: list of cryptographic operations]
100
[assignment: cryptographic algorithm]
101
[assignment: cryptographic key sizes]
102
For length of p
103
[assignment: list of standards]
104
[assignment: list of cryptographic operations]
105
[assignment: cryptographic algorithm]
106
[assignment: cryptographic key sizes]
107
[assignment: list of standards]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 59 of 128
Version 2.5 14.12.2010
6.1.2
ation code
.2.4.1 FCS_COP.1.1/CMAC
The TSF shall perform secure messaging – message authentic 108
in
accordance with a specified crypto phic orithm CMAC
gra alg 109
cryptographi
and
c key sizes 128 bit that meet the following: ‘The CMAC Mode for
110
Authentication, NIST Special Publication 800-38B’ [18] and [11] Appendix
F.2.2111
.
This item concerns the following application(s): ePassport, eID,
Application Note 18: This SFR requires the TOE to im
cryptographic primitive for secure messaging with me
authentication code over transmitted data. The relat
agreed between the TOE and the terminal as part of
protocol according to the FCS_CKM.1/DH_PACE (PACE
Authentication Protocol according to the FCS_CKM.1/
Note that in accordance with [11]
eSign.
plement the
ssage
ed session keys are
either the PACE
-KMAC) or the Chip
DH_CA (CA-KMAC).
Appendix F.2.1 and A.2.3.1 the (two-
in Retail mode for secure messaging. Due
in any mode is no longer applicable within
Random Number Generation (FCS_RND.1)
6.1.2
components.
6.1.2
m numbers that meet K4
key) Triple-DES could be used
to the fact that the (two-key) Triple-DES is not recommended any more
(cf. [12], sec. 1.3), Triple-DES
this PP.
6.1.2.3
.3.1 FCS_RND.1 Quality metric for random numbers
Hierarchical to: No other
Dependencies: No dependencies.
.3.1.1 FCS_RND.1.1
The TSF shall provide a mechanism t generate rando
o
(high) according to AIS20 [12a]112
.
This item concerns the following application(s): ePassport, eID, eSign.
Application Note 19: This SFR requires the TOE to generate random
numbers (random nonce) used for the authentication protocols (PACE,
CA and TA) as required by FIA_UAU.4.
The current ST also includes all SFRs of the SSCD PP [7]. These items are
applicable, if the eSign application is operational. For the functional class FCS,
there are the following components:
108
[assignment: list of cryptographic operations]
109
[assignment: cryptographic algorithm]
110
[assignment: cryptographic key sizes]
111
[assignment: list of standards]
112
[assignment: a defined quality metric]
6 Security Requirements
Page 60 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
SFR identifier Comments
FCS_CKM.1/SS pplication(s): –
eSign
CD concerns the following a
FCS_CKM.4/SS ng application(s): –
It is the same SFR as in 6.1.2.1.4.1
CD concerns the followi
eSign
FCS_COP.1/SSCD concerns the following application –
(s):
his chapter are from the SSCD PP [7].
6.1.2.
s: [FCS_CKM.2 Cryptographic key distribution, or
/SVD pair in accordance with a specified
113
eSign
The following SFRs in t
3.2 FCS_CKM.1/SSCD Cryptographic key generation
Hierarchical to: No other components.
Dependencie
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
6.1.2.3.2.1 FCS_CKM.1.1/SSCD
The TSF shall generate an SCD
cryptographic key generation algorithm G&D_ECDSAKeyGen and specified
cryptographic key sizes 256 bit114
that meet the following: [15]115
.
6.1.2.3.3 ion
attributes, or
r
FCS_CKM.1 Cryptographic key generation]
ction
6.1.2.
igital signature-generation
FCS_COP.1 Cryptographic operat
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security
FDP_ITC.2 Import of user data with security attributes, o
FCS_CKM.4 Cryptographic key destru
3.3.1 FCS_COP.1.1/SSCD
The TSF shall perform d 116
in accordance with a
specified cryptographic algorithm EC-DSA117
and cryptographic key sizes 256
bit118
that meet the following: [15]119
.
FIA Identification and Authentication
sake of better readability, Table 13 provides an overview of the
entication mechanisms used:
6.1.3 Class
For the
auth
113
[assignment: cryptographic key generation algorithm]
114
[assignment: cryptographic key sizes]
115
[assignment: list of standards]
116
[assignment: list of cryptographic operations]
117
[assignment: cryptographic key algorithm]
118
[assignment: cryptographic key sizes]
119
[assignment: list of standards]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 61 of 128
Version 2.5 14.12.2010
Name SFR for the TOE Comments
PACE pro
.1/eID-PIN_Suspending
FIA_AFL.1/eID-PIN_Bloc
as required by FCS_CKM.1/DH_PACE
tocol FIA_UAU.1/PACE
FIA_UAU.5
FIA_AFL
king
FIA_AFL.1/PACE
Terminal
uthentic AU.1/Rightful_Terminal
UAU.5
as required by FCS_COP.1/SIG_VER
A
Protocol
ation U
FIA_
FIA_
Chip
Authentica
/CA, required by FCS_CKM.1/DH_CA
tion FIA_UAU.5,
Protocol F
FIA_API.1
IA_UAU.6
as
eSign-PIN FIA_UAU.1/SSCD inherited from [7]
Table 13 Overview of authentication SFRs
6.1.3 ending eID-
by
PACE
6.1.3
.1.1 FIA_AFL.1/eID-PIN_Suspending Authentication failure handling – Susp
PIN
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication: fulfilled
FIA_UAU.1/
.1.1.1 FIA_AFL.1.1/eID-PIN_Suspending
The TSF shall detect when 2120
unsuccessful au tication atte
then mpts occur related to
ared password for
consecutive failed authentication attempts using eID-PIN as the sh
PACE121
.
6.1.3 ending
tication attempts has been met
.1.1.2 FIA_AFL.1.2/eID-PIN_Susp
When the defined number of unsuccessful authen 122
,
eference value of eID-PIN according to [11], sec. 3.3.2
the TSF shall suspend the r 123
.
he following application(s): eID, eSign.
6.1.3 a Blocking eID-PIN
Hierarchical to: No other components.
by
FIA_UAU.1/PACE
.2.1 FIA_AFL.1.1/eID-PIN_Blocking
This item concer t
ns
.1.2 FIA_AFL.1/eID-PIN_Blocking Authentication failure h ndling –
Dependencies: FIA_UAU.1 Timing of authentication: fulfilled
6.1.3.1
The TSF shall detect when 1124
unsuccessful authentication attempts occur
nsecutive failed authentication attempts using suspended125
eID-PIN
related to co
as the shared password for PACE126
.
120
[selection:[assignment: positive integer number], an administrator configurable positive integer within [assignment: range of
acceptable values]]
121
[assignment: list of authentication events]
122
[selection: met ,surpassed]
123
[assignment: list of actions]
124
[selection:[assignment: positive integer number], an administrator configurable positive integer within [assignment: range of
acceptable values]]
125
as required by FIA_AFL.1/eID-PIN_Suspending
126
[assignment: list of authentication events]
6 Security Requirements
Page 62 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
6.1.3.
empts has been
met
1.2.2 FIA_AFL.1.2/eID-PIN_Blocking
When the defined number of unsuccessful authentic n att
atio
127
, the TSF shall block the reference value of eID-PIN according to [11], sec.
3.3.2128
.
This item concerns the following application(s): e
6.1.3.2 FIA_AFL.1/PACE Authenticat
ID, eSign.
ion failure handling – PACE
-blocking authentication / authorisation
to: No other components.
led by
FIA_AFL.1.1/PACE
authentication using non
data
Hierarchical
Dependencies: FIA_UAU.1 Timing of authentication: fulfil
FIA_UAU.1/PACE
6.1.3.2.1.1
The TSF shall detect when 1129
unsuccessful authentication
related to authentication attempts using CAN, MRZ, eID-PUK
attempts occurs
as shared
passwords for PACE130
.
6.1.3.2.1.2
mpts has been
FIA_AFL.1.2/PACE
When the defined number of unsuccessful authentication atte
met131
, the TSF shall return an error code132,133
and reset all PACE dedicated
internal variables.
This item concerns the following application(s): ePassport, eID, eSign.
ation data (CAN, MRZ and
ocol do not possess
TOE shall not allow a quick monitoring of its
the first step of
high, so that the
he security policy of
One of some opportunities for performing this operation might be
‘consecutively increase the reaction time of the TOE to the next authentication
Application Note 20: Please note that since guessing CAN, MRZ and eID-
PUK requires an attack potential beyond high according to the current
ST, monitoring the static PKPICC and SOC in the context of the chip
E), so that it is not
Since all non-blocking authorisation and authentic
eID-PUK) being used as a shared secret within the PACE prot
a sufficient entropy134
, the
behaviour (e.g. due to a long reaction time) in order to make
the skimming attack135
requiring an attack potential beyond
threat T.ID_Card_Tracing can be averted in the frame of t
the current ST.
attempt using CAN, MRZ, eID-PUK’.
authentication will also fail (due to FTP_ITC.1/PAC
127
[selection: met ,surpassed]
128
[assignment: list of actions]
129
[selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of
acceptable values]]
130
[assignment: list of authentication events]
131
[selection: met ,surpassed]
132
[list of actions]
133
The complete PACE process will take a very long time so that a quick monitoring of its behaviour is implicutely not possible.
134
≥ 100 bits; a theoretical maximum of entropy which can be delivered by a character string is N*ld(C), whereby N is the length of the
string, C – the number of different characters which can be used within the string.
135
guessing CAN or MRZ or eID-PUK, see T.Skimming above
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 63 of 128
Version 2.5 14.12.2010
essential, whether PKPICC and SOC ‘ID_Card-generation / batch’ or
e.
6.1.3 on Proof of Identity
components.
endencies: No dependencies.
6.1.3
ng to [11], sec.
‘ID_Card-individual’ data ar
.2.2 FIA_API.1/CA Authenticati
Hierarchical to: No other
Dep
.2.2.1 FIA_API.1.1
The TSF shall provide the Chip Authentication Protocol accordi
4.3, Version 2136
to prove the identity of the TOE137
.
This item concerns the following application(s): ePassport,
Application Note 21: The Chip Authentication sh
rightful terminal immediately after the successful
Authentication (as required FIA_UAU.1/Rightful_Term
amongst other, Comp(ephem-PKPCD-TA)
eID, eSign.
all be triggered by a
Terminal
inal) using,
138
from the accomplished TA.
verifying the
Card using ephem-
king evident possessing
The Passive Authentication making evident authenticity of the PKPICC
A shall be
the successful
ion139
and is
The terminal verifies genuineness of the ID_Card by
authentication token TPICC calculated by the ID_
PKPCD-TA and CA-KMAC, (and, hence, finally ma
the Chip Authentication Key (SKPICC)).
by verifying the Card Security Object (SOC) up to CSC
triggered by the rightful terminal immediately after
Terminal Authentication before the Chip Authenticat
considered to be part of the CA protocol within this ST (see also
of any TOE’s
enabling an external entity (the terminal
the TOE’s identity. If the Chip Authentication was
rmed, Secure Messaging is restarted using the derived
keys (CA-KMAC, CA-KEnc), cf. FTP_ITC.1/CA. Otherwise, Secure
using the previously established session keys
, PACE-K ), cf. FTP_ITC.1/PACE.
6.1. n
Hierarchical to: No other components.
ndencies: No dependencies.
TSF shall allow
1. establishing a communication channel,
P.Terminal).
Please note that this SFR does not require authentication
user, but providing evidence
connected) to prove
successfully perfo
session
Messaging is continued
(PACE-KMAC Enc
3.3 FIA_UID.1/PACE Timing of i tificatio
den
Depe
6.1.3.3.1.1 FIA_UID.1.1/PACE
The
2. carrying out the PACE Protocol according to [11], sec. 4.2140
on behalf of the user to be performed before the user is identified.
136
[assignment: authentication mechanism]
137
[assignment: authorised user or role]
138
Comp() is public key compression function. It is defined in [11], table A.2 as SHA-1 (for Diffie-Hellmann)
139
cf. [11], sec. 3.4
140
[assignment: list of TSF-mediated actions]
6 Security Requirements
Page 64 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
6.1.3.
successfully identified before allowing any
eSign.
performed PACE
-PUK were used
note that neither
CAN nor MRZ effectively represent secrets, but are restricted-revealable;
CE, it is either the ID_Card
orised other person or device.
FIA_UID.1/Rightful_Terminal Timing of identification
to: No other components.
.
6.1.3.4
SF shall allow
3.1.2 FIA_UID.1.2/PACE
The TSF shall require each user to be
other TSF-mediated actions on behalf of that user.
This item concerns the following application(s): ePassport, eID,
Application Note 22: User identified after a successfully
protocol is a PACE terminal (PCT). In case eID-PIN or eID
for PACE, it is the ID_Card holder using PCT. Please
i.e. in case CAN or MRZ were used for PA
holder itself or an auth
6.1.3.4
Hierarchical
Dependencies: No dependencies
.1.1 FIA_UID.1.1/Terminal Timing
The T
1. establishing a communication channel,
2. carrying out the PACE protocol according to [11], sec. 4.2,
rding to [11] sec. 4.4,
3. carrying out the Terminal Authentication Protocol acco
Version 2141
on behalf of the user to be performed before the user is identified.
6.1.3.4.1.2 FIA_UID.1.2/Terminal Timing
successfully identified before allowing any
n behalf of that user.
eSign.
n Note 23: The User identified after a successfully performed
ol is a rightful terminal, i.e. either EIS or ATT or SGT.
6.1.3.5
Dependencies: FIA_UID.1 Timing of identification: fulfilled by FIA_UID.1/PACE
6.1.3.5.1.1 FIA_UAU.1.1/PACE
SF shall allow
establishing a communication channel,
The TSF shall require each user to be
other TSF-mediated actions o
This item concerns the following application(s): ePassport, eID,
Applicatio
TA protoc
FIA_UAU.1/PACE Timing of authentication
Hierarchical to: No other components.
The T
1.
2. carrying out the PACE Protocol according to [11], sec. 4.2142,143
on behalf of the user to be performed before the user is authenticated.
141
[assignment: list of TSF-mediated actions]
142
ID_Card identifies itself within the PACE protocol by selection of the authentication key ephem-PKPICC-PACE
143
[assignment: list of TSF-mediated actions]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 65 of 128
Version 2.5 14.12.2010
6.1.3
ccessfully authenticated before allowing
ser.
, eID, eSign.
successfully
n case eID-PIN or
using PCT. Please
t secrets, but are
sed for PACE, it is
orised other person or device.
saging is started using
s (PACE-KMAC, PACE-KEnc), cf. FTP_ITC.1/PACE.
6.1. ful_Terminal Timing of authentication
components.
cies: FIA_UID.1 Timing of identification: fulfilled by
all allow
1. establishing a communication channel,
.5.1.2 FIA_UAU.1.2/PACE
The TSF shall require each user to be su
any other TSF-mediated actions on behalf of that u
This item concerns the following application(s): ePassport
Application Note 24: The user authenticated after a
performed PACE protocol is a PACE terminal (PCT). I
eID-PUK were used for PACE, it is the ID_Card holder
note that neither CAN nor MRZ effectively represen
restricted-revealable; i.e. in case CAN or MRZ were u
either the ID_Card holder itself or an auth
If PACE was successfully performed, secure mes
the derived session key
3.6 FIA_UAU.1/Right
Hierarchical to: No other
Dependen
FIA_UID.1/Rightful_Terminal
6.1.3.6.1.1 FIA_UAU.1.1/Terminal Timing
The TSF sh
. 4.2,
2. carrying out the PACE protocol according to [11], sec
ntication Protocol according to [11], sec.
3. carrying out the Terminal Authe
4.4, Version 2144145
on behalf of the user to be performed before the user is aut
.6.1.2 FIA_UAU.1.2/Terminal Timing
The TSF shall require each user to be successfully authentica
any other TSF-mediated actions on behalf of that user.
henticated.
6.1.3
ted before´allowing
t, eID, eSign.
user authenticated after a successfully performed
Provider represented by a rightful terminal, i.e.
SGT. The authenticated terminal will immediately
perform the Chip Authentication (Version 2) as required by FIA_API.1/CA
using, amongst other, Comp(ephem-PKPCD-TA) from the accomplished TA.
Please note that the Passive Authentication is considered to be part of
6.1.3.7 FIA_UAU.4/Single-use authentication of the Terminals by the TOE
Hierarchical to: No other components.
Dependencies: No dependencies.
This item concerns the following application(s): ePasspor
Application Note 25: The
TA protocol is a Service
either EIS or ATT or
the CA protocol within this ST.
144
ID_Card identifies itself within the TA protocol by using the identifier IDPICC ≡ Comp(ephem-PKPICC-PACE).
145
[assignment: list of TSF-mediated actions]
6 Security Requirements
Page 66 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
6.1.3.7
a related to
.1.1 FIA_UAU.4.1
The TSF shall prevent re entication dat
use of auth
1. PACE Protocol according to [11], sec. 4.2,
2. Terminal Authentication Protocol according to [11], sec. 4.4, Version
2.146
This item concerns the following application(s): ePassport eID,
Application Note 26: For the PACE protocol, the TOE
nonce s of 128 bits leng being (almost) un
,
th
eSign.
randomly selects a
iformly distributed (the
n function based on AES; see [11],
TOE randomly selects a
ngth, see [11], sec. B.3 and B.11.6.
entication mechanisms
6.1.3.8.1.1
he TSF shall provide the General Authentication Procedure as the sequence
current ST supports the key derivatio
sec. A.3.3 and A.2.3). For the TA protocol, the
nonce rPICC of 64 bits le
6.1.3.8 FIA_UAU.5/Multiple auth
Hierarchical to: No other components.
Dependencies: No depe ncies.
nde
FIA_UAU.5.1//Multiple authentication
T
1. PACE Protocol according to [11], sec. 4.2,
2. Terminal Authentication Protocol according to [11], sec. 4.4, Version 2,
Protocol according to [11], sec. 4.3, Version 2°147
,
3. Chip Authentication
and
4. Secure messaging in encrypt-then-authenticate mode according to [11],
Appendix F148
to support user authentication.
FIA_UAU.5.2/Multiple authentication
6.1.3.8.1.2
ding to the following
The TSF shall authenticate any user’s claimed identity accor
rules:
1. The TOE accepts the authentication attempt by means of the Terminal
Authentication Protocol, only if (i) the terminal presents its static public
key149
being successfully verifiable up to CVCA and (ii) the terminal uses
the PICC identifier calculated during
150
and the secure messaging
established by the current PACE authentication.
Having successfully run the Chip Authentication Protocol the TOE
2.
ith correct message authentication
accepts only received commands w
code sent by means of secure messaging with the key agreed with the
terminal by means of the Chip Authentication Protocol151
This item concerns the following application(s): ePassport, eID, eSign.
146
[assignment: identified authentication mechanism(s)]
147
the Passive Authentication is considered to be part of the Chip Authentication (CA) Protocol within this PP.
148
[assignment: list of multiple authentication mechanisms]
149
PKPCD
150
IDPICC ≡ Comp(ephem-PKPICC-PACE)
151
[assignment: rules describing how the multiple authentication mechanisms provide authentication]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 67 of 128
Version 2.5 14.12.2010
Application Note 27: Please note that Chip Authen
not authenticate any TOE’s user, but provides evid
tication Protocol does
ence enabling an
to prove the TOE’s identity.
6.1.3.9 of Terminal by the TOE
Hierarchical to: No other components.
6.1.3
nditions each command sent
external entity (the terminal connected)
FIA_UAU.6 /Re-authenticating
Dependencies: No dependencies.
.9.1.1 FIA_UAU.6.1/Re-authenticating
The TSF shall re-authenticate the user under the co
to the TOE after successful run of the Chip Authentication Protocol shall be
verifi eing sent by the rightful terminal.
ed as b 152
This item concerns the following application(s): ePassport, e
Application Note 28: The PACE and the Chip Authen
specified in [11] start secure messaging used for all
exchanged after successful PACE authentication and
each command by secure messaging in encrypt-then
based on CMAC, whether it was sent by th
terminal (see FCS_COP.1/CMAC for further details).
execute any command with inco
ID, eSign.
tication protocols
commands
CA. The TOE checks
-authenticate mode
e successfully authenticated
The TOE does not
rrect message authentication code.
connected, if a secure
mmands received
Terminal
Authentication, the current secure messaging session is bounded on
se items are
unctional class FIA,
there are the following components, whereby the component
is explicitly re-defined (supplemented) in the current ST:
6.1.3.10 of authentication
y FIA_UID.1/SSCD,
6.1
The TSF shall allow
rding to FPT_TST.1,
Therefore the TOE re-authentica s the terminal
messaging error occurred, and accepts only those co
from the initially authenticated terminal. For the
te
Comp(ephem-PKPCD-TA).
The current ST also includes all SFRs of the SSCD PP [7]. The
applicable, if the eSign application is operational. For the f
FIA_UAU.1/SSCD
FIA_UAU.1/SSCD Timing
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification: fulfilled b
cf. [7]
.3.10.1.1 FIA_UAU.1.1/SSCD Timing
1. self test acco
ation of the user by means of TSF required by
2. identific
FIA_UID.1/SSCD in [7],
3. establishing a trusted channel between CGA and the TOE by means
of TSF required by FTP_ITC.1/CA153
,
4. establishing a trusted channel between HID and the TOE by means of
TSF required by FTP_ITC.1/CA154
,
152
[assignment: list of conditions under which re-authentication is required]
153
the authenticated terminal is ATT, cf. FIA_UAU.1/Rightful_Terminal
6 Security Requirements
Page 68 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
5. none155
on behalf of the user to be performed before the user is authenticated.
6.1.3.
essfully authenticated before allowing any
F-m tions on behalf of that user.
This item concerns the following application(s): eSign.
10.1.2 FIA_UAU.1.2/SSCD Timing
The TSF shall require each user to be succ
other TS ediated ac
SFR identifier Comments
FIA_UID.1/SSCD
rns dedicated
authentication data for the eSign application
like eSign-PIN and eSign-PUK, if any.
ation(s):
This requirement conce
concerns the following applic
– eSign
FIA_AFL.1/SSCD like eSign-PIN and eSign-PUK, if an
This requirement concerns dedicated
authentication data for the eSign application
concerns the following application(s):
y.
– eSign
The following SFRs in this chapter are from the SSCD PP [7].
6 entification
cal to: No other components.
6.1.3.10.2.1
.1,
.1.3.10.2FIA_UID.1/SSCD/Timing of id
Hierarchi
Dependencies: No dependencies.
FIA_UID.1.1/SSCD/Timing
The TSF shall allow
1. Self test according to FPT_TST
None
2. 156
on behalf of the user to be performed before the user is identified.
F shall require each user to be successfully identified before allowing any
on behalf of that user.
6.1.3.10.3FIA_AFL.1/SSCD Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
6.1.3.10.2.2 FIA_UID.1.2/SSCD/Timing
The TS
other TSF-mediated actions
154
the authenticated terminal is SGT, cf. FIA_UAU.1/Rightful_Terminal; the trusted channel by FTP_ITC.1/CA implements a trusted path
between HID and the TOE.
155
[assignment: list of TSF mediated actions]
156
[assignment: list of additional TSF-mediated actions]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 69 of 128
Version 2.5 14.12.2010
6.1.3.10.3.1 FIA_AFL.1.1/SSCD Authentication failure
The TSF shall detect when 3157
unsuc es
c sful authentication attempts occur
hentication attempts
related to consecutive failed aut 158
.
6.1.3
When the defined number of unsuccessful authentication attempts has been
.10.3.2 FIA_AFL.1.2/SSCD Authentication failure
met159
, the TSF shall block RAD160
.
6.1 Protection
6.1.4.1.1
Hierarchical to: No other components.
ss control: fulfilled by
6.1.4.1.1.1 FDP_ACC.1.1
erminal Access Control SFP
.4 Class FDP User Data
FDP_ACC.1/TRM Subset access control – Terminal Access
Dependencies: FDP_ACF.1 Security attribute based acce
FDP_ACF.1/TRM
The TSF shall enforce the T 161
on terminals gaining
write, read, modification and usage access to the User Data stored in the ID_Card162
.
sport, eID, eSign.
6.1.4 Terminal Access
Dependencies: FDP_ACC.1 Subset access control: fulfilled by FDP_ACC.1/TRM
stified
e access control TSF according to FDP_ACF.1/TRM uses security attributes
ng been defined during the personalisation and fixed over the whole life
the TOE. No management of these security attributes (i.e. SFR
FMT_MSA.3) is necessary here.
6.1.4.1
TSF shall enforce the Terminal Access Control SFP
This item concerns the following application(s): ePas
.1.2 FDP_ACF.1/TRM Security attribute based access control –
Hierarchical to: No other components.
FMT_MSA.3 Static attribute initialisation: not fulfilled, but ju
Th
havi
time of
FMT_MSA.1 and
.2.1 FDP_ACF.1.1/TRM
The 163
to objects based on the
following:
1. Subjects:
a. Terminal,
b. PACE Terminal (PCT),
c. Rightful Terminal (EIS, ATT, SGT);
2. Objects:
User Data stored in the TOE;
157
[selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment: range of
acceptable values]]
158
[assignment: list of authentication events]
159
[selection: met ,surpassed]
160
[assignment: list of actions]
161
[assignment: access control SFP]
162
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
163
[assignment: access control SFP]
6 Security Requirements
Page 70 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
3. Security attributes:
a. Authentication status of terminals,
risation Level,
b. Terminal Autho
c. CA authentication status,
d. Authentication status of the ID_Card holder as Signatory (if the eSign is
operational) 164
.
FDP_ACF.1.2/TRM
6.1.4.1.2.2
era
controlled objects is allowed:
m (EIS) is allowed
The TSF shall enforce the following rules to determine if an op tion among
controlled subjects and
1. a successfully authenticated Extended Inspection Syste
to read User Data according to [11], sec. C.4.1.1 after a successful CA as
required by FIA_API.1/CA.
2. a successfully authenticated Authentication Terminal (ATT) is allowed to
read, modify and write User Data as well as to generate signature key
pair(s) within the eSign application (SCD/SVD 5
) according to [11], sec.
16
C.4.1.2 after a successful CA as required by FIA_API.1 .
/CA
3. a successfully authenticated Signature Terminal (SGT) is allowed to use
the private signature key within the eSign application (SCD, if the eSign
is operational) for generating digital signatures according to [11], sec.
C.4.1.3 after a successful CA as required by FIA_API.1/CA and a
successful authentication of the ID_Card holder as Signatory as required
by FIA_UAU.1/SSCD.166
6.1.4.
ased on the
1.2.3 FDP_ACF.1.3/TRM
The TSF shall explicitly authorise access of subjects to objects b
following additional rules: none167
.
6.1.4.1.2.4
sed on the following
as a rightful
FDP_ACF.1.4/TRM
The TSF shall explicitly deny access of subjects to objects ba
additional rules:
1. Any terminal (including PCT) being not authenticated
terminal (i.e. as either EIS or ATT or SGT) is not allowed to read, to write,
to modify, to use any User Data stored on the ID_Card.
ographic keys’
2. Nobody is allowed to read ‘TOE immanent secret crypt
stored on the ID_Card.
on data’
3. Nobody is allowed to read ‘secret ID_Card holder authenticati
stored on the ID_Card.
4. Nobody is allowed to read the private Restricted Identification (SKID) key
stored on the ID_Card.
164
[assignment: list of subjects and objects controlled under the indicated SFP, and. for each, the SFP-relevan security attributes, or
named groups of SFP-relevant security attributes]
165
as required by FCS_CKM.1/SSCD
166
[assignment: rules governing access among controlled subjects and controlled objects using controlle operations on controlled
objects]
167
[assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 71 of 128
Version 2.5 14.12.2010
5. Nobody is allowed to read the private signature key(s) within the eSign
application (SCD; if the eSign is operational)168
.
, eID, eSign.
Service Provider)
ertificate of the
the
Certification
e Terminal
tion Level is the
the certificates of
Document Verifier
te chain. It is
on Template (CHAT),
ration from the
hain of the terminal and the ID_Card holder’s restricting
effective
n sent to the TOE by the
tication (B.3 und
thentication
atory for all the
ions residing on the TOE, see [11], sec. 3.4; cf. also table E.1.
only ‘EAC version
a (DG1 – DG16) of
ject (SOC) does not
ard Security Object
PCT, see [11], A.1.2 and table A.1 for
ctional requirement also
tion using the ATT with
isation Level, see [11], sec. C.4.1.2, and
an application by the ID_Card
/SVD_Generation_SFP_SSCD Subset access control
ents.
Dependencies: FDP_ACF.1 Security attribute based access control
6.1.4.1.3.1 FDP_ACC.1.1/
This item concerns the following application(s): ePassport
Application Note 29: The relative certificate holder (
authorisation is encoded in the Card Verifiable C
terminals being operated by the Service Provider. The TOE verifies
certificate chain established by the Country Verifying
Authority, the Document Verifier Certificate and th
Certificate (cf. FMT_MTD.3). The Terminal Authorisa
intersection of the Certificate Holder Authorisation in
the Country Verifying Certification Authority, the
Certificate and the Terminal Certificate in a valid certifica
technically based on Certificate Holder Authorizati
see [11], C.1.5. A CHAT is calculated as an AND-ope
certificate c
input at the terminal. This final CHAT reflects the
authorisation level, see [11], C.4.2 and is the
command 'MSE:Set AT' within the Terminal Authen
B.11.1 of [11]).
Application Note 30: Please note that the General Au
Procedure as required by FIA_UAU.5 is mand
applicat
Concerning table 1.2 of [11], the current ST supports
2’, whereby EAC shall be mandatory for all user dat
the ePassport. Please note that the Card Security Ob
belong to the user data, but to the TSF-data. The C
can be read out by the
EF.CardSecurity.
Application Note 31: Please note that this fun
covers the ability to activate the eSign applica
an appropriate Terminal Author
acting on behalf of the CSP and upon
holder.
6.1.4.1.3 FDP_ACC.1/SCD
Hierarchical to: No other compon
SCD/SVD_Generation_SFP_SSCD 169
ation_SFP170
The TSF shall enforce the SCD/SVD_Gener on
1. subjects: S.User,
2. objects: SCD, SVD,
3. operations: generation of SCD/SVD pair171
.
168
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
169
from PP [7]
170
[assignment: access control SFP]
171
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
6 Security Requirements
Page 72 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
6.1.4.1.4 FDP_ACF.1/SCD/SVD_Generation_SFP_SSCD Security attribute based
ts.
Subset access control
on
6.1.4.
access control
Hierarchical to: No other componen
Dependencies: FDP_ACC.1
FMT_MSA.3 Static attribute initialisati
1.4.1 FDP_ACF.1.1/ SCD/SVD_Generation_SFP_SSCD 149
The TSF shall enforce the SCD/SVD_Generation_SFP172
to objects based on the
ed with the security attribute “SCD / SVD
following: the user S.User is associat
Management “173
.
1.5 FDP_ACF.1.2/
6.1.4. SCD/SVD_Generation_SFP_SSCD 149
The TSF shall enforce the following rules to determine if an operation among
with the security
controlled subjects and controlled objects is allowed: S.User
attribute “SCD / SVD Management” set to “authorised” is allowed to generate
SCD/SVD pair174
.
6.1.4.1.5.1 FDP_ACF.1.3/ SCD/SVD_Generation_SFP_SSCD 149
bjects based on the
The TSF shall explicitly authorise access of subjects to o
following additional rules: none175
.
6.1.4.1.5.2 FDP_ACF.1.4/ SCD/SVD_Generation_SFP_SSCD 149
sed on the rule:
ute “SCD / SVD management” set to “not
The TSF shall explicitly deny access of subjects to objects ba
S.User with the security attrib
te SCD/SVD pair
authorised” is not allowed to genera 176
.
_Transfer_SFP_SSCD Subset access control
to: No other components.
access control
6.1.4. SFP_SSCD
_SFP
6.1.4.1.6 FDP_ACC.1/SVD
Hierarchical
Dependencies: FDP_ACF.1 Security attribute based
1.6.1 FDP_ACC.1.1/ SVD_Transfer_
The TSF shall enforce the SVD_Transfer 177
on
1 subjects: S.User,
2 objects: SVD
3 operations: export178
.
6.1.4.1.7 FDP_ACF.1/SVD_Transfer_SFP_SSCD Security attribute based access control
s.
ss control
FMT_MSA.3 Static attribute initialisation
Hierarchical to: No other component
Dependencies: FDP_ACC.1 Subset acce
172
[assignment: access control SFP]
173
[assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or
named groups of SFP-relevant security attributes]
174
[assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled
objects]
175
[assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
176
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
177
[assignment: access control SFP]
178
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 73 of 128
Version 2.5 14.12.2010
6.1.4
TSF shall enforce the SVD_Transfer_SFP
.1.7.1 FDP_ACF.1.1/SVD_Transfer_SFP_SSCD
The 179
to objects based on the
1 the S.User is associated with the security attribute Role
following:
,
2 the SVD 180
.
6.1.4
s to determine if an operation among
trolled objects is allowed: R.Admin is allowed to
.1.7.2 FDP_ACF.1.2/SVD_Transfer_SFP_SSCD
The TSF shall enforce the following rule
controlled subjects and con
export SVD181
.
6.1.4.1.7.3 FDP_ACF.1.3/ SVD_Transfer_SFP_SSCD
jects based on the
llowing additional rules: none
The TSF shall explicitly authorise access of subjects to ob
fo 182
.
_SSCD
sh cess of subjects to objects based on the rule:
6.1.4.1.7.4 FDP_ACF.1.4/SVD_Transfer_SFP
The TSF all explicitly deny ac
none183
SFP_SSCD
o ts.
P_ACF.1 Security attribute based access control
6.1.4.1.8.1 FDP_ACC.1.1/
.
6.1.4.1.8 FDP_ACC.1/Signature_Creation_
Hierarchical to: No other comp nen
Dependencies: FD
Signature-creation_SFP_SSCD
The TSF shall enforce the Signature-creation_SFP184
on
1. subjects: S.User,
2. objects: DTBS/R, SCD,
3. operations: signature-creation.185
179
[assignment: access control SFP]
180
[assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or
named groups of SFP-relevant security attributes]
181
[assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled
objects]].
182
[assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
183
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
184
[assignment: access control SFP]
185
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
6 Security Requirements
Page 74 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
6.1.4.1.9 FDP_ACF.1/ Signature_Creation_SFP_SSCD
.
1 Subset access control
6.1.4.1.9 ACF.1.1/
Hierarchical to: No other components
Dependencies: FDP_ACC.
FMT_MSA.3 Static attribute initialisation
.1 FDP_ Signature-creation_SFP
shall enforce the Signature-creation_SFP
The TSF 186
to objects based on the
is associated with the security attribute "Role"
following:
1. the user S.User
and
2. the SCD with the security attribute "SCD Operational"187
.
6.1.4.1.9.2 FDP_ACF.1.2/ Signature-creation_SFP
The TSF shall enforce the following rules to determine if an operation among
te digital signatures for DTBS/R with SCD which
controlled subjects and controlled objects is allowed:
R.Sigy is allowed to crea
security attribute “SCD operational” is set to “yes”188
.
6.1.4.1.9.3 FDP_ACF.1.3/ Signature-creation_SFP
The TSF shall explicitly authorise access of subjects to obje
following additional rules: none189
cts based on the
.
6.1.4.1.9.4 FDP_ACF.1.4/ Signature-creation_SFP
The TSF shall explicitly deny access of subjects to objects based on the
rules:
r is not allowed to create digital signatures for DTBS/R with SCD which
following additional
S.Use
security attribute “SCD operational” is set to “no”190
.
.2 FDP
6.1.4 _RIP.1 Subset residual information protection
r r hical to: No other components.
Dependencies: No dependencies.
resource is
f the resource from191
Hie a c
6.1.4.2.1.1 FDP_RIP.1/eID
The TSF shall ensure that any previous information content of a
made unavailable upon the deallocation o the following
1. the Chip Authentication Private Key (SKPICC),
objects:
186
[assignment: access control SFP]
187
[assignmemt: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or
named groups of SFP-relevant security attributes:]
188
[assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled
objects:]
189
[assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects:]
190
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects:]
191
[selection: allocation of the resource to, deallocation of the resource from]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 75 of 128
Version 2.5 14.12.2010
2. the secret ID_Card holder authentication data eID-PIN, eID-PUK,
eSign-PIN (RAD; if the eSign is operational),
, PACE-KEnc), (CA-KMAC, CA-KEnc),
3. the session keys (PACE-KMAC
ID,
4. the private Restricted Identification key SK
the private signature key of the ID_Card holder (SCD; if the
5.
eSign is operational),
6. None192
.
This item concerns the following application(s): ePassport, eID, eSign.
The current ST also includes all SFRs of the SSCD PP [7]. These items are
applicable, if the e tion is operational. For the functional class
Sign applica
FDP, there are the following components:
SFR identifier Comments
FDP_ACC.1/SCD/SVD_Generation_SFP_SSCD concerns the following application(s):
– eSign
FDP_ACF.1/SCD/SVD_Generatio llowing application(s):
– eSign
n_SFP_SSCD concerns the fo
FDP_ACC.1/SVD_Transfer_SFP_ llowing application(s):
– eSign
SSCD concerns the fo
FDP_ACF.1/SVD_Transfer_SFP_ concerns the following application(s):
– eSign
SSCD
FDP_ACC.1/Signature-creation_S following application(s):
FP_SSCD concerns the
– eSign
FDP_ACF.1/Signature-creation_SFP_SSCD concerns the following application(s):
– eSign
FDP_RIP.1_SSCD This item is covered by FDP_RIP.1
ing application(s):
– eSign
6.1.4.2
concerns the f w
ollo
It is the same SFR as in:
FDP_SDI.2/Persistent_SSCD concerns the following application(s):
– eSign
FDP_SDI.2/DTBS_SSCD concerns the following application(s):
– eSign
The following SFRs in this chapter are from the SSCD PP [7].
6.1.4.2.2 FDP_SDI.2/Persistent_SSCD Stored data integrity monitoring and
action
Hierarchical to: FDP_SDI.1 Stored data integrity monitoring.
Dependencies:No dependencies.
192
[assignment: list of (further) objects]
6 Security Requirements
Page 76 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
6.1.4
trolled by the TSF for
.2.2.1 FDP_SDI.2.1/ Persistent_SSCD
The TSF shall monitor user data stored in containers con
integrity error193
on all objects, based on the following attributes: integrity
checked stored data194
.
6
rror, the TSF shall
.1.4.2.2.2 FDP_SDI.2.2/ Persistent_SSCD
Upon detection of a data integrity e
1. prohibit the use of the altered data
2. inform the S.Sigy about integrity error195
.
6.1.4 Stored data integrity monitoring and
action
onitoring.
BS_SSCD
TSF
.2.3 FDP_SDI.2/DTBS_SSCD
Hierarchical to: FDP_SDI.1 Stored data integrity m
Dependencies:No dependencies.
6.1.4.2.3.1 FDP_SDI.2.1/DT
The TSF shall monitor user data stored in containers controlled by the
for integrity error196
on all objects, based on the following attributes:
integrity checked stored DTBS197
.
6.1.4.2.3.2 FDP_SDI.2.2/DTBS_SSCD
Upon detection of a data integrity error, the TSF shall
1. prohibit the use of the altered data
ut integrity error198
.
2. inform the S.Sigy abo
F data like RAD shall be
veness of the user authentication. This
aspect of the security architecture (cf.
6.1.
6.1.5 CE
Hierarchical to: No other components.
Dependencies: No dependencies.
.1 FTP_ITC.1.1/PACE Inter-TSF trusted channel after PACE
The TSF shall provide a communication channel between itself and PACE
terminal (PCT) after PACE 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.
Application Note 32: The integrity of TS
protected to ensure the effecti
protection is a specific
ADV_ARC.1).
5 Class FTP Trusted Path/Channels
.1 FTP_ITC.1/PACE Inter-TSF trusted channel after PA
6.1.5.1.1
193
[assignment: integrity errors]
194
[assignment: user data attributes]
195
[assignment: action to be taken]
196
[assignment: integrity errors]
197
[assignment: user data attributes]
198
[assignment: action to be taken]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 77 of 128
Version 2.5 14.12.2010
6.1. E
TSF shall permit the PCT199
5.1.1.2 FTP_ITC.1.2/PACE Inter-TSF trusted channel after PAC
The to initiate communication via the trusted
6.1.
ed channel for any data
channel.
5.1.1.3 FTP_ITC.1.3/PACE Inter-TSF trusted channel after PACE
The TSF shall enforce communication via the trust
exchange between the TOE and the PCT after PACE.200
ort, eID, eSign.
shed after
.1/PACE). If the
sing the derived session keys (PACE-KMAC, PACE-KEnc): this
lishing
being used for the
and
The PACE secure messaging session is immediately superseded by a
successful Chip Authentication as
/CA. The establishing phase of the PACE trusted
enable tracing due to the requirements
cking.
6.1
No dependencies.
annel after CA
n rightful
terminal (EIS, ATT, SGT) after Chip Authentication that is logically
channels and provides assured
annel data from
6.1.
The TSF shall permit the rightful terminal (EIS, ATT, SGT)
This item concerns the following application(s): ePassp
Application Note 33: The trusted channel is establi
successful performing the PACE protocol (FIA_UAU
PACE was successfully performed, secure messaging is immediately
started u
secure messaging enforces preventing tracing while estab
Chip Authentication; the cryptographic primitives
secure messaging are as required by FCS_COP.1/AES
FCS_COP.1/CMAC.
CA secure messaging session after
required by FTP_ITC.1
channel does not
FIA_AFL.1/PACE and FIA_AFL.1/eID-PIN_Blo
.5.2 FTP_ITC.1/CA Inter-TSF trusted channel after CA
Hierarchical to: No other components.
Dependencies:
6.1.5.2.1.1 FTP_ITC.1.1/CA Inter-TSF trusted ch
The TSF shall provide a communication cha nel between itself and
distinct from other communication
identification of its end points and protection of the ch
modification or disclosure.
5.2.1.2 FTP_ITC.1.2/CA Inter-TSF trusted channel after CA
201
to initiate
communication via the trusted channel.
ITC.1.3/CA Inter-TSF trusted channel after CA
SF shall enforce communication via the trusted channel for any data
6.1.5.2.1.3 FTP_
The T
exchange between the TOE and the Service Provider represented by the
rightful terminal after Chip Authentication.202
This item concerns the following application(s): ePassport, eID, eSign.
199
[selection: the TSF, another trusted IT product]
200
[assignment: list of functions for which a trusted channel is required]
201
[selection: the TSF, another trusted IT product]
202
[assignment: list of functions for which a trusted channel is required]
6 Security Requirements
Page 78 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
6.1.6 Class FAU Security Audit
6.1.6
components.
es: No dependencies.
6.1.6
.1 FAU_SAS.1 Audit storage
Hierarchical to: No other
Dependenci
.1.1.1 FAU_SAS.1.1
The TSF shall provide the Manufacturer203
with the capability to store the
Initialisation and Pre-Personalisation Data204
in the audit
This item concerns the following application(s): ePassport,
Application Note 34: The Manufacturer role is the de
identity assumed by the TOE in the life phase ‘manu
IC manufacturer and the ID_Card manufacturer i
role write the Initialisation
records.
eID, eSign.
fault user
facturing’. The
n the Manufacturer
and/or Pre-personalisation Data as TSF-
dit records are usually write-only-once data
TD.1/INI_ENA, FMT_MTD.1/INI_DIS). Please
which cannot be
ctly used by the TOE.
6.1. nagement
d FMT_SMR.1 provide basic requirements on the
6.1.7 SMF.1/Specification of Management Functions
to: No other components.
: No dependencies.
Management Functions
rming the following management
data into the TOE. The au
of the ID_Card (see FMT_M
note that there could also be such audit records
read out, but dire
7 Class FMT Security Ma
The SFR FMT_SMF.1 an
management of the TSF data.
.1 FMT_
Hierarchical
Dependencies
6.1.7.1.1.1 FMT_SMF.1.1/Specification of
The TSF shall be capable of perfo
functions:
1. Initialisation,
2. Personalisation,
3. Configuration,
4. Resume and unblock the eID-PIN205
,
5. Activate and deactivate the eID-PIN.206
e following application(s): ePassport, eID, eSign.
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification: fulfilled by
FIA_UID.1/PACE,
FIA_UID.1/Rightful_Terminal (see also the Application Note 35 below).
This item concerns th
203
[assignment: authorised users]
204
[assignment: list of audit information]
205
unblocking eSign-PIN is managed by FMT_SMF.1/SSCD
206
[assignment: list of management functions to be provided by the TSF]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 79 of 128
Version 2.5 14.12.2010
6.1 cification of Management Functions
ll maintain the roles
rer,
.7.1.1.2 FMT_SMR.1.1/Spe
The TSF sha
1. Manufactu
2. Personalisation Agent,
3. Country Verifying Certification Authority,
t Verifier,
4. Documen
5. Terminal,
6. PACE Terminal (PCT),
ed) Inspection System (EIS),
7. (Extend
),
8. Authentication Terminal (ATT
),
9. Signature Terminal (SGT
10. ID_Card holder.207
6.1.7
ort, eID, eSign.
er please refer to
the default role for any terminal
gnised by the TOE as neither PCT nor EIS nor ATT nor SGT (‘Terminal’
S, ATT208
and SGT are
cf. [11], C.4
erminal). The TOE recognises the ID_Card holder by using
PACE) as well as – in the context
R FMT_LIM.1 and FMT_LIM.2 address the management of the TSF and
er the life cycle phases.
6.1.7.2
6.1.7.2.1.1 FMT_LIM.1.1
pabilities so that in
enforced:
Deploying test features after TOE delivery do not allow
1. User Data to be manipulated and disclosed
.1.1.3 FMT_SMR.1.2/Specification of Management Functions
The TSF shall be able to associate users with roles.
This item concerns the following application( Passp
Application Note 35: For explanation on the role Manufactur
the Application Note 34. The role Terminal is
being reco
s): e
is used by the ID_Card presenter). The roles CVCA, DV, EI
recognised by analysing the current Terminal Certificate CT,
(FIA_UAU.1/Rightful_T
PCT upon input eID-PIN or eID-PUK (FIA_UAU.1/
of the eSign application – by using SGT upon input eSign-PIN
(FIA_UAU.1/SSCD).
The SF
TSF data to prevent misuse of test features of the TOE ov
FMT_LIM.1/Limited capabilities
Hierarchical to: No other components.
Dependencies: FMT_LIM.2 Limited availability: fulfilled by FMT_LIM.2
The TSF shall be designed in a manner that limits their ca
conjunction with ‘Limited availability (FMT_LIM.2)’ the following policy is
,
2. TSF data to be manipulated or disclosed,
207
[assignment: the authorised identified roles]
208
ATT plays a special role ‘CGA’ for the eSign application, if bits 7 (install qualified certificate) or/and (install certificate) are set to 1
within the effective terminal authorisation level, cf. [11], sec. C.4.1.2; an AT with such an terminal authorisation level is authorised by the
related CSP to act as CGA on its behalf.
6 Security Requirements
Page 80 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
3. embedded software to be reconstructed and
4. substantial information about construction of TSF to be gathered
which may enable other attacks.209
This item concerns the following application(s): ePassport, eID, eSign.
6.1.7.3
ical to: No other components.
FMT_LIM.1
6.1.7. T_LIM.2.1
eir availability so that in
(FMT_LIM.1)’ the following policy is
ry do not allow
FMT_LIM.2/Limited availability
Hierarch
Dependencies: FMT_LIM.1 Limited capabilities: fulfilled by
3.1.1 FM
The TSF shall be designed in a manner that limits th
conjunction with ‘Limited capabilities
enforced:
Deploying test features after TOE delive
1. User Data to be manipulated and disclosed,
2. TSF data to be manipulated or disclosed,
3. embedded software to be reconstructed and
4. substantial information about construction of TSF to be gathered which
may enable other attacks.210
eSign.
6.1.7.4 of TSF data – Writing Initialisation and
er components.
ulfilled by
nt of TSF data – Writing Initialisation and
shall restrict the ability to write
This item concerns the following application(s): ePassport, eID,
FMT_MTD.1/INI_ENA Management
Pre-personalisation Data
Hierarchical to: No oth
Dependencies: FMT_SMF.1 Specification of management functions: f
FMT_SMF.1
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1
6.1.7.5 FMT_MTD.1.1/INI_ENA Manageme
Pre-personalisation Data
The TSF 211
the Initialisation Data and Pre-personalisation
Data212
to the Manufacturer213
.
e following application(s): ePassport, eID, eSign.
D.1/INI_DIS Management of TSF data – Reading and Using
and Pre-personalisation Data
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by
FMT_SMF.1
This item concerns th
6.1.7.6 FMT_MT
Initialisation
209
[assignment: Limited capability and availability policy]
210
[assignment: Limited capability and availability policy]
211
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
212
[assignment: list of TSF data]
213
[assignment: the authorised identified roles]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 81 of 128
Version 2.5 14.12.2010
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1
6.1.7.
214
6.1.1 FMT_MTD.1.1/INI_DIS
The TSF shall restrict the ability to read out and to use the Initialisation Data215
to the
Personalisation Agent216
.
This item concerns the following application(s): ePassport, eID, eSi
Application Note 36: The TOE may restrict the ability to write the Initi
Data and the Pre-personalisation Data by (i) allowing writing
once and (ii) blocking the role Manufacturer at the end of t
phase. The Manufacturer may write the Initialisation Data (as
FAU_SAS.1) including, but being not limited to a unique ide
being used to trace the IC in th
gn.
alisation
these data only
he manufacturing
required by
ntification of the IC
e life phases ‘manufacturing’ and ‘issuing’, but
being not needed and may be misused in the ‘operational use’. Therefore, read
he ‘operational use’
n Agent, when he switches the TOE from the life phase
e ‘operational use’.
6.1.7 TD.1/CVCA_INI Management of TSF data – Initialisation of CVCA
F.1 Specification of management functions: fulfilled by
6.1.7.7.1.1 ment of TSF data – Initialisation of CVCA
d Current Date
e TSF shall restrict the ability to write
and use access the Initialisation Data shall be blocked in t
by the Personalisatio
‘issuing’ to the life phas
.7 FMT_M
Certificate and Current Date
Hierarchical to: No other components.
Dependencies: FMT_SM
FMT_SMF.1
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1
FMT_MTD.1.1 CVCA_INI Manage
Certificate an
Th 217
the
ty Public Key (PKCVCA),
1. initial Country Verifying Certification Authori
rity Certificate
2. metadata of the initial Country Verifying Certification Autho
(CCVCA) as required in [11], sec. A.6.2.3,
3. initial Current Date,
4. none218
to Personalisation Agent219
.
This item concerns the following application(s): ePassport, eID, eSign.
Verifying Certification Authority Public
cturer in the manufacturing phase or by the
g phase (cf. [11], sec. 2.2.5). The initial
Country Verifying Certification Authority Public Keys (and their updates later
on) are used to verify the Country Verifying Certification Authority Link-
Certificates. The metadata of the initial Country Verifying Certification
Authority Certificate and the initial Current Date are needed for verification of
Application Note 37: The initial Country
Key may be written by the Manufa
Personalisation Agent in the issuin
214
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
215
[assignment: list of TSF data]
216
[assignment: the authorised identified roles]
217
selection: change_default, query, modify, delete, clear, [assignment: other operations]]
218
[assignement. List of TSF data]
219
[assignment: the authorised identified roles]
6 Security Requirements
Page 82 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
the certificates and the calculation of the Terminal Aut is
note that only a subset of the metadata must be
hor ation Level. Please
stored in the TOE, see [11],
onal.
6.1.7.8 TSF data – Country Verifying
hical to: No other components.
functions: fulfilled by
roles: fulfilled by FMT_SMR.1
6.1.7.9 data – Country Verifying
The TSF sh
sec. A.6.2.3; storing of further certificate’s content is opti
FMT_MTD.1/CVCA_UPD Management of
Certification Authority
Hierarc
Dependencies: FMT_SMF.1 Specification of management
FMT_SMF.1
FMT_SMR.1 Security
FMT_MTD.1.1/CVCA_UPD Management of TSF
Certification Authority
all restrict the ability to update220
the
Authority Public Key (PKCVCA),
1. Country Verifying Certification
Authority Certificate (CCVCA) as
2. metadata of the Country Verifying Certification
required in [11], sec. A.6.2.3,
3. none221
.
to Country Verifying Certification Authority222
.
This item concerns the following application(s): ePassport,
Application Note 38: The Country Verifying Certification
eID, eSign.
Authority updates its
istributes the public key and the related metadata be
he TOE updates its
al trust-point, if a valid CVCA Link-Certificates (cf. FMT_MTD.3) is
sec. 2.2.3 and 2.2.5).
TE Management of TSF data – Current date
.
_SMF.1 Specification of management functions: fulfilled by
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1
l restrict the ability to modify223
asymmetric key pair and d
means of the CVCA Link-Certificates (cf. [11], sec. 2.2). T
intern
provided by the terminal (cf. [11],
6.1.7.10 FMT_MTD.1/DA
Hierarchical to: No other components
Dependencies: FMT
FMT_SMF.1
6.1.7.10.1.1 FMT_MTD.1.1/DATE
The TSF shal the Current Date224
to
Country Verifying Certification Authority,
1.
2. Document Verifier,
3. Rightful Terminal (EIS, ATT or SGT) possessing an Accurate Terminal
Certificate225
.
220
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
221
[assignment: list of TSF data]
222
[assignment: the authorised identified roles]
223
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
224
[assignment: list of TSF data]
225
[assignment: the authorised identified roles]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 83 of 128
Version 2.5 14.12.2010
This item concerns the following application(s): ePassport, eID, eSig
Application Note 39: The authorised roles are identified in th
[11], sec. 2.2.5 and C.4) and authorised by validation of the
to CVCA (cf. FMT_MTD.3). The authorised role of the termina
Certificate Ho
n.
eir certificates (cf.
certificate chain up
l is part of the
lder Authorization in the card verifiable certificate provided by
A.6.2.3, B.11.1, C.1.3,
6.1.7 rsonalisation Agent
other components.
on of management functions: fulfilled by
urity roles: fulfilled by FMT_SMR.1
6.1.7.11.1.1
the terminal within the Terminal Authentication (cf. [11],
C.1.5, D.2 for details).
.11 FMT_MTD.1/PA_UPD Management of TSF data – Pe
Hierarchical to: No
Dependencies: FMT_SMF.1 Specificati
FMT_SMF.1
FMT_SMR.1 Sec
FMT_MTD.1.1 PA_UPD
The TSF shall restrict the ability to write226
the Card Security Object (SOC)227
to the
Personalisation Agent.228
D, eSign.
6.1.7 MTD.1/SK_PICC Management of TSF data – Chip Authentication
other components.
by
6.1.7.1
This item concerns the following application(s): ePassport, eI
.12 FMT_
Private Key
Hierarchical to: No
Dependencies: FMT_SMF.1 Specification of management functions: fulfilled
FMT_SMF.1
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1
2.1.1 FMT_MTD.1.1/SK_PICC
The TSF shall restrict the ability to create, load229
the Chip Authentication Private Key
(SKPICC)230
to Personalisation Agent231
.
This item concerns the following application(s): ePassport, eID, eSign.
C is refined by (i)
ns and (ii) defining a selection for the operations
‘create’ and ‘load’ to be performed by the ST writer. The verb ‘load’ means
y is generated securely outside the
and written into the TOE memory. The verb ‘create’ means here that the
tication Private Key is generated by the TOE itself. In the latter
on of the
FCS_CKM.1 as SFR for this key generation.
6.1.7.13 FMT_MTD.1/KEY_READ Management of TSF data – Private Key Read
Hierarchical to: No other components.
Application Note 40: The component FMT_MTD.1/SK_PIC
selecting other operatio
here that the Chip Authentication Private Ke
TOE
Chip Authen
case the ST writer might include an appropriate instantiati
component
226
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
227
[assignment: list of TSF data]
228
[assignment: the authorised identified roles]
229
selection: change_default, query, modify, delete, clear, [assignment: other operations]]
230
[assignment: list of TSF data]
231
[assignment: the authorised identified roles]
6 Security Requirements
Page 84 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Dependencies: FMT_SMF.1 Specification of management functions: fulfilled by
T_SMR.1
6.1.7.13
FMT_SMF.1
FMT_SMR.1 Security roles: fulfilled by FM
.1.1 FMT_MTD.1.1/KEY_READ /Multiple authentication
The TSF shall restrict the ability to read232
the Chip Authentication Private Key (SKPICC)233
to none.234
This item concerns the following application(s): ePassport, eID, eSign.
6.1.7.1 ta – Resuming eID-
unctions: fulfilled by
6.1.7.14 y Read
4 FMT_MTD.1/eID-PIN_Resume Management of TSF da
PIN
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management f
FMT_SMF.1
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1
.1.1 FMT_MTD.1.1/KEY_READ Management of TSF data – Private Ke
The TSF shall restrict the ability to resume235
the suspended eID-PIN236
to the ID_Card
holder.237
This item concerns the following application(s): eID.
o-step one, subsequently using
E with eID-PIN. It must be implemented according to [11],
r the status as required by FIA_AFL.1/eID-PIN_Suspending.
.1/PACE using the eID-PIN
shared password.
_SMF.1 Specification of management functions: fulfilled by
FMT_SMF.1
T_SMR.1
ment of TSF data –
cking/Changing eID-PIN
and change
Application Note 41: The resuming procedure is a tw
PACE with CAN and PAC
sec. 3.5.1 and is relevant fo
The ID_Card holder is authenticated as required by FIA_UAU
as the
6.1.7.15 FMT_MTD.1/eID-PIN_Unblock Management of TSF data –
Unblocking/Changing eID-PIN
Hierarchical to: No other components.
Dependencies: FMT
FMT_SMR.1 Security roles: fulfilled by FM
6.1.7.15.1.1 FMT_MTD.1.1/eID-PIN_Unblock Manage
Unblo
The TSF shall restrict the ability to unblock 238
the blocked eID-PIN239
to
1. the ID_Card holder,
232
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
233
[assignment: list of TSF data]
234
[assignment: the authorised identified roles]
235
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
236
[assignment: list of TSF data]
237
[assignment: the authorised identified roles]
238
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
239
[assignment: list of TSF data]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 85 of 128
Version 2.5 14.12.2010
2. the Authentication Terminal (ATT) with the Terminal Authorisation Level for eID-
PIN management.240
This item concerns the following application(s): eID.
Application Note 42: The unblocking procedure must be implement
[11], sec. 3.5.1, 3.5.2 and is relevant for the status as required by F
PIN_Blocking. It can be triggered by either (i) the ID_Card holder b
required by FIA_UAU.1/PACE using th
ed according to
IA_AFL.1/eID-
eing authenticated as
e eID-PUK as the shared password or (ii) the ATT
Authorisation Level being sufficient
(FDP_ACF.1/TRM).
6.1.7.16
gement functions: fulfilled by
6.1.7. gement of TSF data
Activating/Deactivating eID-PIN
e ability to activate and deactivate
(FIA_UAU.1/Rightful_Terminal) proved a Terminal
for eID-PIN management
FMT_MTD.1/eID-PIN_Activate Management of TSF data
Activating/Deactivating eID-PIN
Hierarchical to: No other component
Dependencies: FMT_SMF.1 Specification of mana
FMT_SMF.1
FMT_SMR.1 Security roles: fulfilled by FMT_SMR.1
16.1.1 FMT_MTD.1.1/eID-PIN_Activate Mana
The TSF shall restrict th 241
the eID-PIN242
to the
TT) with the Terminal Authorisation Level for eID-PIN
Authentication Terminal (A
management.243
This item concerns the following application(s): eID, eSign.
SF data
ependencies: FMT_MTD.1 Management of TSF data: fulfilled by
UPD,
6.1.7.17.1.1 F data
in are accepted for
Access Control
6.1.7.17 FMT_MTD.3/Secure T
Hierarchical to: No other components.
D
FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_
FMT_MTD.1/DATE
FMT_MTD.3.1 Secure TS
The TSF shall ensure that only secure values of the certificate cha
TSF data of the Terminal Authentication Protocol and the Terminal
SFP.244
alid if and only if
e digital signature of the Terminal Certificate (CT) has been
verified as correct using the public key of the Document Verifier
Certificate and the expiration date of the CT is not before the
Current Date of the TOE,
2. the digital signature of the Document Verifier Certificate (CDV) has
been verified as correct using the public key in the Certificate of the
Refinement: The certificate chain is v
1. th
240
assignment: the authorised identified roles]
241
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
242
[assignment: list of TSF data]
243
[assignment: the authorised identified roles]
244
[assignment: list of TSF data]
6 Security Requirements
Page 86 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Country Verifying Certification Authority (CCVCA) and the expiration
of the TOE,
fying
d as correct using
ntry Verifying Certification Authority
CVCA is not
The static terminal public key (PK ) contained in the C in a valid certificate
ta of a rightful
Holder Authorisations contained in the
value for Terminal
e Provider
This item concerns the following application(s): ePassport, eID, eSign.
The current ST also includes all SFRs of the SSCD PP [7]. These items are applicable, if
the eSign application is operational. For the functional class FMT, there are the
following components:
date of the CDV is not before the Current Date
3. the digital signature of the Certificate of the Country Veri
Certification Authority (CCVCA) has been verifie
the public key of the Cou
known to the TOE and the expiration date of the C
before the Current Date of the TOE.
PCD T
chain is a secure value for the authentication reference da
terminal.
The intersection of the Certificate
certificates of a valid certificate chain is a secure
Authorisation Level245
of a success lly authenticated Servic
(represented by a rightful terminal).
fu
245
this certificate-calculated Terminal Authorisation Level can additionally be restricted by ID_Card holder at the terminal, s. [11], sec.
C.4.2. It is based on Certificate Holder Authorization Template (CHAT), see [11], C.1.5. A CHAT is calculated as an AND-operation from
the certificate chain of the terminal and the ID_Card holder’s restricting input at the terminal. This final CHAT reflects the effective
authorisation level, see [11], C.4.2 and is then sent to the TOE by the command 'MSE:Set AT' within the Terminal Authentication (B.3
und B.11.1 of [11]).
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 87 of 128
Version 2.5 14.12.2010
SFR identifier Comments
FMT_SMR.1/SSCD concerns the following application(s):
– eSign
FMT_SMF.1/SSCD concerns the following application(s):
– eSign
FMT_MOF.1/SSCD concerns the following application(s):
– eSign
FMT_MSA.1/Admin_SSCD concerns the following application(s):
– eSign
FMT_MSA.1/Signatory_SSCD concerns the following application(s):
– eSign
FMT_MSA.2/SSCD concerns the following application(s):
– eSign
FMT_MSA.3/SSCD concerns the following application(s):
– eSign
FMT_MSA.4/SSCD concerns the following application(s):
– eSign
FMT_MTD.1/Admin_SSCD owing application(s):
concerns the foll
– eSign
FMT_MTD.1/Signatory_SSCD
eSign-PIN can be unblocked using
lobal eID-PUK and may
cked using an
eSign-specific eSign-PUK, if any.
concerns the following application(s):
– eSign
the card-g
also be unblo
apter are from the SSCD PP [7].
6.1.7.
s.
Timing of identification.
1.1/SSCD Security roles
The TSF shall maintain the roles R.Admin and R.Sigy
The following SFRs in this ch
17.2 FMT_SMR.1/SSCD Security roles
Hierarchical to: No other component
Dependencies: FIA_UID.1
6.1.7.17.2.1 FMT_SMR.
246
.
6.1.7.17.2.2 FMT_SMR.1.2/SSCD Security roles
The TSF shall be able to associate users with roles.
6.1.7.17.3 FMT_SMF.1/SSCD Security management functions
Hierarchical to: No other components.
246
[assignment: the authorised identified roles]
6 Security Requirements
Page 88 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Dependencies: No dependencies.
6.1.7.1
rming the following security management functions:
7.3.1 FMT_SMF.1.1/SSCD Security roles
The TSF shall be capable of perfo
1. Creation and modification of RAD,
2. Enabling the signature-creation function,
3. Modification of the security attribute SCD/SVD management, SCD operational,
bute SCD Identifier,
4. Change the default value of the security attri
5. none247
.
6.1.7.1 rity functions behaviour
F.1 Specification of Management Functions.
6.1.7.1 ement of security functions behaviour
7.4FMT_MOF.1/SSCD Management of secu
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SM
7.4.1 FMT_MOF.1.1/SSCD Manag
The TSF shall restrict the ability to enable248
the signature-creation function249
to
R.Sigy250
.
7.5 FMT_MSA.1/Admin_SSCD Managemen
6.1.7.1 t of security attributes
ther components.
FDP_IFC.1 Subset information flow control]
nagement Functions
6.1.7.1
tion_SFP
Hierarchical to: No o
Dependencies: [FDP_ACC.1 Subset access control, or
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Ma
7.5.1 FMT_MSA.1.1/Admin_SSCD
The TSF shall enforce the SCD/SVD_Genera 251
to restrict the ability to modify252
the security attributes SCD / SVD management253
to R.Admin254
.
6.1.7.1 es
nts.
ccess control, or
control]
_SMR.1 Security roles
ement Functions
1/ Signatory_SSCD
The TSF shall enforce the Signature-creation_SFP
7.6 FMT_MSA.1/Signatory_SSCD Management of security attribut
Hierarchical to: No other compone
Dependencies: [FDP_ACC.1 Subset a
FDP_IFC.1 Subset information flow
FMT
FMT_SMF.1 Specification of Manag
6.1.7.17.7FMT_MSA.1.
255
to restrict the ability to modify256
the
security attributes SCD operational257
to R.Sigy258
.
247
[assignment: list of other security management functions to be provided by the TSF]
248
[selection: determine the behaviour of, disable, enable, modify the behaviour of]
249
[assignment: list of functions]
250
[assignment: the authorised identified roles]
251
[assignment: access control SFP(s), information flow control SFP(s)]
252
[selection: change_default, query, modify, delete, [assignment: other operations]]
253
[assignment: list of security attributes]
254
[assignment: the authorised identified roles]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 89 of 128
Version 2.5 14.12.2010
6.1.7. curity attributes
bset access control, or
attributes
6.1.7.17.8.1 D Secure security attributes
e values are accepted for SCD / SVD Management
17.81 FMT_MSA.2/SSCD Secure se
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Su
FDP_IFC.1 Subset information flow control]
FMT_MSA.1 Management of security
FMT_SMR.1 Security roles
FMT_MSA.2.1/SSC
The TSF shall ensure that only secur
and SCD operational259
.
6.1.7. 7 atic attribute initialisation
Security roles
initialisation
_SFP and Signature-
1 .9FMT_MSA.3/SSCD St
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1
6.1.7.17.9.1 FMT_MSA.3.1/SSCD Static attribute
The TSF shall enforce the SCD/SVD_Generation_SFP, SVD_Transfer
creation_SFP260
to provide restrictive261
default values for security attributes that are
6.1.7. itialisation
used to enforce the SFP.
17.9.2 FMT_MSA.3.2/SSCD Static attribute in
The TSF shall allow the R.Admin262
to specify alternative initial values to override the
6.1.7. ance
C.1 Subset access control, or
6.1.7.17.10.1 FMT_MSA.4.1/SSCD Security attribute value inheritance
ing rules to set the value of security attributes:
.Admin successfully generates an SCD/SVD pair without S.Sigy being
default values when an object or information is created.
17.10 FMT_MSA.4/SSCD Security attribute value inherit
Hierarchical to: No other components.
Dependencies: [FDP_AC
FDP_IFC.1 Subset information flow control]
The TSF shall use the follow
1. If S
authenticated the security attribute “SCD operational of the SCD” shall be set
to “no” as a single operation.
s an SCD/SVD pair the security attribute “SCD
2. If S.Sigy successfully generate
operational of the SCD” shall be set to “yes” as a single operation. 263
255
[assignment: access control SFP(s), information flow control SFP(s)]
256
[selection: change_default, query, modify, delete, [assignment: other operations]]
257
[assignment: list of security attributes]
258
[assignment: the authorised identified roles]
259
[selection: list of security attributes]
260
[assignment: access control SFP, information flow control SFP]
261
[selection, choose one of: restrictive, permissive, [assignment: other property]]
262
[assignment: the authorised identified roles]
263
[assignment: rules for setting the values of security attributes]
6 Security Requirements
Page 90 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
6.1.7.1 Management of TSF data
ents.
s
ation of Management Functions
to create
7.11 FMT_MTD.1/Admin_SSCD
Hierarchical to: No other compon
Dependencies: FMT_SMR.1 Security role
FMT_SMF.1 Specific
6.1.7.17.11.1 FMT_MTD.1.1/Admin_SSCD
The TSF shall restrict the ability 264
the RAD265
to R.Admin266
.
6.1.7.1 nagement of TSF data
MR.1
FMT_SMF.1 Specification of Management Functions
7.12 FMT_MTD.1/Signatory_SSCD Ma
Hierarchical to: No other components.
Dependencies: FMT_S Security roles
6.1.7.17.12.1 FMT_MTD.1.1/Signatory_SSCD
The TSF shall restrict the ability to modify267
the RAD268
to S.Sigy269
.
Class FPT Protection of the Security Functions
The TOE shall prevent inherent and forced illicit information leakage
and TSF-data. The security functional requirement FPT_EMSEC.1 add
leakage. With respect to the forced leakage they have to be consider
with the security functional requ
6.1.8
for the User Data
resses the inherent
ed in combination
irements ‘Failure with preservation of secure state
ing (FPT_TST.1)’ on the one hand and ‘Resistance to physical
The SFRs ‘Limited capabilities (FMT_LIM.1)’, ‘Limited
physical attack (FPT_PHP.3)’ together with
e described within the SAR ‘Security architecture description’
) prevent bypassing, deactivation and manipulation of the security features
6.1.8.1
endencies.
t emit information about IC power consumption and command
(FPT_FLS.1)’ and ‘TSF test
attack (FPT_PHP.3)’ on the other.
availability (FMT_LIM.2)’ and ‘Resistance to
the design measures to b
(ADV_ARC.1
or misuse of the TOE security functionality.
FPT_EMSEC.1 TOE Emanation
Hierarchical to: No other components.
Dependencies: No dep
6.1.8.1.1.1 FPT_EMSEC.1.1
The TOE shall no
execution time270
in excess of non useful information271
enabling access to
Authentication Private Key (SKPICC),
1. the Chip
the eID-PIN, eID-PUK, eSign-PIN (RAD; if the eSign is operational),
2.
3. None272
264
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
265
[assignment: list of TSF data]
266
[assignment: the authorised identified roles]
267
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
268
[assignment: list of TSF data]
269
[assignment: the authorised identified roles]
270
[assignment: types of emissions]
271
[assignment: specified limits]
272
[list of types of (further) TSF data]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 91 of 128
Version 2.5 14.12.2010
and
4. the private Restricted Identification key SKID,
5. the private signature key of the ID_Card holder (SCD; if the eSign is
operational),
None
6. 273
6.1.8.1.1.2 FPT_EMSEC.1.2
The TSF shall ensure any users274
are unable to use the following interface ID_Card’s
contactless interface and circuit contacts275
to gain access to
hentication Private Key (SKPICC),
1. the Chip Aut
-PUK, eSign-PIN (RAD; if the eSign is operational),
2. the eID-PIN, eID
3. None276
and
the privat
he eSign is
e Restricted Identification key SKID,
4. the private signature key of the ID_Card holder (SCD; if t
operational),
5. None277
.
This item concerns the following application(s): ePassport, eID, e
Application Note 43: The TOE shall prevent attacks against the listed
data where the attack is based on external observable phys
the TOE. Such attacks may be observable at the interface
be originated from internal operation of the TOE o
attacker that varies the physical environment under which
Sign.
secret
ical phenomena of
s of the TOE or may
r may be caused by an
the TOE operates.
y the technology
. The ID_Card’s chip has to provide a
smart card contactless interface, but may have also (not used by the terminal,
ntacts according to ISO/IEC 7816-2 as
rable phenomena include, but are not limited to
er consumption, the timing of signals and the
ata transmissions.
otection against forced
ation.
re with preservation of secure state
ical to: No other components.
o dependencies.
6.1.8.2.1 FPT_FLS.1.1 /Failure with preservation of secure state
The TSF shall preserve a secure state when the following types of failures occur:
1. Exposure to operating conditions causing a TOE malfunction,
The set of measurable physical phenomena is influenced b
employed to implement the smart card
but maybe by an attacker) sensitive co
well. Examples of measu
variations in the pow
electromagnetic radiation due to internal operations or d
The following security functional requirements address the pr
illicit information leakage including physical manipul
6.1.8.2 FPT_FLS.1/Failu
Hierarch
Dependencies: N
273
[assignment: list of types of (further) user data
274
[assignment: type of users]
275
[assignment: type of connection]
276
L[ist of types of (further) TSF data]
277
[[assignment: list of types of (further) user data]
6 Security Requirements
Page 92 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
2. Failure detected by TSF according to FPT_TST.1,
3. None278
.
This item concerns the following application(s): ePassport, eID, eSign.
6.1.8.2.2
: No other components.
6.1.8.2 .1.1/Testing
un a suite of self tests during initial start-up, periodically during normal
FPT_TST.1 TSF/Testing
Hierarchical to
Dependencies: No dependencies.
.2.1 FPT_TST
The TSF shall r
operation, at the condition279
Reset of the TOE280
to demonstrate th
of the T
e correct operation
SF281
.
sting
integrity of the
6.1.8.2.2.2 FPT_TST.1.2Te
The TSF shall provide authorised users with the capability to verify the
TSF data282
.
6.1.8.2
integrity of stored
.2.3 FPT_TST.1.3/Testing
The TSF shall provide authorised users with the capability to verify the
TSF executable code.
This item concerns the following application(s): ePassport, eID, eSign
Application Note 44: If the ID_Card’s chip uses state of the art smar
will run some self tests at the request of an authorised user and some self tests
.
t card technology, it
automatically. E.g. a self test for the verification of the integrity of stored TSF executable
executed during initial start-up by the ‘authorised
phase ‘Manufacturing’. Other self tests may automatically
to preserve the secure state according to FPT_FLS.1 in the
phase ‘operational use’, e.g. to check a calculation with a private key by the reverse
ng public key as a countermeasure against Differential
6.1.8.3
Dependencies: No dependencies.
st physical manipulation and physical probing283
code required by FPT_TST.1.3 may be
user’ Manufacturer in the life
run to detect failures and
calculation with the correspondi
Failure Analysis.
FPT_PHP.3/Resistance to physical attack
Hierarchical to: No other components.
6.1.8.3.1.1 FPT_PHP.3.1/Resistance to physical attack
The TSF shall resi to the TSF284
by
such that the SFRs are always enforced.
erns the following application(s): ePassport, eID, eSign.
Application Note 45: The TOE will implement appropriate measures to
continuously counter physical manipulation and physical probing. Due to the
responding automatically
This item conc
278
[assignment: list of types of (further) failures in the TSF]
279
[selection: during initial start-up, periodically during normal operation, at the request of the authorised user, at the conditions]
280
[assignment: conditions under which self test should occur]
281
[selection: [assignment: parts of TSF], the TSF]
282
[selection: [assignment: parts of TSF], TSF data]
283
[assignment: physical tampering scenarios]
284
[assignment: list of TSF devices/elements]
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 93 of 128
Version 2.5 14.12.2010
nature of these attacks (especially manipulation) the TOE ca
detect attacks on all of its elements. Therefore, permanent p
these attacks is required ensuring that the TSP could not be violated
n by no means
rotection against
at any
time. Hence, ‘automatic response’ means here (i) assuming that there might be
at any time.
rrent ST also includes all SFRs of the SSCD PP [7]. These items are applicable, if
plication is operational. For the functional class FPT, there are the following
an attack at any time and (ii) countermeasures are provided
The cu
the eSign ap
components:
SFR identifier Comments
FPT_EMSEC.1/SSC by
e.
g application(s):
– eSign
in: 6.1.8.1.1.2
D This SFR is covered
SFR FPT_EMSEC.1 abov
concerns the followin
It is the same SFR as
FPT_FLS.1/SSCD PT_FLS.1 above.
llowing application(s):
n
: 6.1.8.2.1
This SFR is covered by F
concerns the fo
– eSig
It is the same SFR as in
FPT_PHP.1/SSCD llowing application(s):
concerns the fo
– eSign
FPT_PHP.3/SSCD This SFR is commensurate with
wing application(s): –
It is the same SFR as in: 6.1.8.3
FPT_PHP.3 above.
concerns the follo
eSign
FPT_TST.1/SSCD This SFR eq
is uivalent to FPT_TST.1
concerns the following application(s):
– eSign
It is the same SFR as in: 6.1.8.2.2
above.
The following SFRs in this chapter are from the SSCD PP [7].
SCD Passive detection of physical attack
Dependencies: No dependencies.
6.1.8.3.2.1 FPT_PHP.1.1/SSCD
The TSF shall provide unambiguous detection of physical tampering that might
compromise the TSF.
6.1.8.3.2.2 FPT_PHP.1.2/SSCD
The TSF shall provide the capability to determine whether physical tampering with the
TSF’s devices or TSF’s elements has occurred.
6.1.8.3.2 FPT_PHP.1/S
Hierarchical to: No other components.
6 Security Requirements
Page 94 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
6.2 Security Assurance Requirements for the TOE
operating en efined assurance package EAL4
augmented by the following compo
es),
- ATE_DPT.2 (Testing: security enforcing modules) and
odical vulnerability analysis).
6.3
6.3.1 Security Functional Requirements Rationale
The following l ro e n er w r u f ct al requirements coverage
also giving an id ce r fi n an necessity
The assurance requirements for the evaluation of the TOE, its development and
vironment are to choose as the pred
nents:
- ALC_DVS.2 (Sufficiency of security measur
- AVA_VAN.5 (Advanced meth
Security Requirements Rationale
tab e p vid s a ov vie fo sec rity un
of the SFRs chosen.
ion
ev en fo suf cie cy d
OT.Identification
OT.Personalisation
OT.Data_Integrity
OT.Data_Authenticity
OT.Data_Confidentiality
OT.ID_Card_Tracing
OT.Chip_Auth_Proof
OT.Prot_Abuse-Func
OT.Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.Prot_Malfuntion
OT.SCD/SVD_Gen
[7]200
OT.Sigy_SigF
[7]
285
FCS_CKM.1/DH_P E x
AC x x
FCS_CKM.1/DH_CA x x x
FCS_CKM.2/DH x x
x x
FCS_CKM.4 x x x
FCS_COP.1/SHA x x
x x
FCS_COP.1/SIG_V x
ER x x
FCS_COP.1/AES x
FCS_COP.1/CMAC x x
x
FCS_RND.1 x x x x
FIA_AFL.1/eID-PIN Su
_
spending
x x x x
FIA_AFL.1/eID-PIN_Bl
ocking
x x x
x x
FIA_AFL.1/PACE x
FIA_API.1/CA x x x x
FIA_UID.1/PACE x x x
FIA_UID.1/Rightful_Ter
minal
x x x x
FIA_UAU.1/PACE x x x
FIA_UAU.1/Rightful_Te
rminal
x x x x
FIA_UAU.1/SSCD x x
285
this item is applicable, if the eSign application is operational.
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 95 of 128
Version 2.5 14.12.2010
OT.Identification
OT.Personalisation
OT.Data_Integrity
OT.Data_Authenticity
OT.Data_Confidentiality
OT.ID_Card_Tracing
OT.Chip_Auth_Proof
OT.Prot_Abuse-Func
OT.Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.Prot_Malfuntion
OT.SCD/SVD_Gen
[7]200
OT.Sigy_SigF
[7]
285
FIA_UAU.4 x x
x
FIA_UAU.5 x x
x
FIA_UAU.6 x x
x
FDP_ACC.1/TRM x x
x
FDP_ACF.1/TRM x x
x
FDP_RIP.1 x x x
x x
FTP_ITC.1/PACE x
FTP_ITC.1/CA x x x
x
FAU_SAS.1 x x
FMT_SMF.1 x x x x
x
FMT_SMR.1 x x x x
x
FMT_LIM.1 x
FMT_LIM.2 x
FMT_MTD.1/INI_ENA x x
FMT_MTD.1/INI_D x
IS x
FMT_MTD.1/CVCA IN
_
I
x x
x
FMT_MTD.1/CVCA U
_
PD
x x
x
FMT_MTD.1/DATE x x
x
FMT_MTD.1/PA_UPD x x x
x x
FMT_MTD.1/SK_P C x x x
IC x
FMT_MTD.1/KEY_RE
AD
x x x
x
FMT_MTD.1/eID-PIN_
Resume
x x x
x
FMT_MTD.1/eID-PIN_
Unblock
x x x x
FMT_MTD.1/eID-PIN_
Activate
x x x x
FMT_MTD.3 x x x
FPT_EMSEC.1 x
FPT_FLS.1 x x
FPT_TST.1 x x
FPT_PHP.3 x x x
Table 14 Coverage of Security Objectives for the TOE by SFR
A detailed justification required for suitability of the security functional requirements to
achieve the security objectives is given below.
The security objective OT.Identification addresses the storage of Initialisation and Pre-
Personalisation Data in its non-volatile memory, whereby they also include the IC
Identification Data uniquely identifying the TOE’s chip.
6 Security Requirements
Page 96 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
This will be ensured by TSF according to SFR FAU_SAS.1.
The SFR FMT_MTD.1/INI_ENA allows only the Manufacturer to write I
Prepersonalisation Data (including the Personalisation Agent key). Th
nitialisation and
e SFR
ble access to Initialisation
related.
ling/activating of the
requiring, amongst
l. This authorisation level
red by the SFR
e only an ATT can
necessary authorisation level, using and management of eID-PIN
TD.1/eID-
PIN_Activate) also support
quires erasing the temporal values of eID-
T_MTD.1/INI_DIS
o the Pre-
e related property of OT.Personalisation (updating SOC).
s related.
that the TOE always ensures integrity of
tication, of
ing). Physical
the first line, by
on level is achieved by the
by FCS_COP.1/SIG_VER). The TA protocol
ACE) being, in
as the shared
ement of eID-PIN (FIA_AFL.1/eID-PIN_Suspending,
FIA_AFL.1/eID-PIN_Blocking,
T_MTD.1/eID-
this objective. FDP_RIP.1 requires erasing the
temporal values of eID-PIN, eID-PUK. FIA_UAU.4, FIA_UAU.5 and FCS_CKM.4 represent
some required specific properties of the protocols used.
To allow a verification of the certificate chain as required in FMT_MTD.3, the CVCA’s
public key and certificate as well as the current date are written or update by authorised
identified role as required by FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD and
FMT_MTD.1/DATE.
FMT_MTD.1/INI_DIS requires the Personalisation Agent to disa
and Pre-personalisation Data in e life phase ‘operational use’.
th
The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles
The security objective OT.Personalisation aims that only Personalisation Agent can
write the User- and the TSF-data into the TOE (it also includes instal
eSign application).
This property is covered by FDP_ACC.1/TRM and FDP_ACF.1/TRM
other, an appropriate authorisation level of a rightful termina
can be achieved by the terminal identification/authentication as requi
FIA_UID.1/Rightful_Terminal, FIA_UAU.1/Rightful_Terminal286
. Sinc
reach the
(FIA_AFL.1/eID-PIN_Suspending, FIA_AFL.1/eID-PIN_Blocking, FMT_M
PIN_Resume, FMT_MTD.1/eID-PIN_Unblock, FMT_MTD.1/eID-
achievement of this objective. FDP_RIP.1 re
PIN, eID-PUK.
The justification for the SFRs FAU_SAS.1, FMT_MTD.1/INI_ENA and FM
arises from the justification for OT.Identification above with respect t
personalisation Data.
FMT_MTD.1/PA_UPD covers th
The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and role
The security objective OT.Data_Integrity aims
the User- and TSF-data stored and, after the Terminal- and the Chip Authen
these data exchanged (physical manipulation and unathorised modify
manipulation is addressed by FPT_PHP.3.
Unathorised modifying of the stored data is addressed, in
FDP_ACC.1/TRM and FDP_ACF.1/TRM. A concrete authorisati
terminal identification/authentication as required by the SFRs
FIA_UID.1/Rightful_Terminal,
FIA_UAU.1/Rightful_Terminal (is supported
uses the result of the PACE authentication (FIA_UID.1/PACE, FIA_UAU.1/P
turn, supported by FCS_CKM.1/DH_PACE. Since PACE can use eID-PIN
secret, using and manag
FMT_MTD.1/eID-PIN_Resume, FMT_MTD.1/eID-PIN_Unblock, FM
PIN_Activate) also support achievement of
286
which, in turn, are supported by the related FCS-components. The author dispensed here with listing of these supporting FCS-
components for the sake of clearness. See the next item OT.Data_Integrity for further detail.
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 97 of 128
Version 2.5 14.12.2010
Unathorised modifying of the exchanged data is addressed, in t
FTP_ITC.1/CA using FCS_COP.1/CMAC. A prerequisite for establishin
channel is a successful Chip Authentication FIA_API.1/CA using FCS_CKM.1/DH_CA an
FCS_CKM.2/DH and possessing the special properties FIA_UAU.5, F
provides an evidence of possessing the Chip Authentication Private
FMT_MTD.1/SK_PICC governs creating/loading SKPIC
he first line, by
g this trusted
d
IA_UAU.6. The CA
Key (SKPICC).
C, FMT_MTD.1/KEY_READ requires
onfidential. FDP_RIP.1
or KMAC).
ther, signature over the
Passive Authentication is allowed to be modified by the
worthily.
eral support for
d roles related.
henticity of the User-
abling its
.
.1/CMAC. A
tication
ecial
p
PICC governs creating/loadin SKPICC,
readable for a user, so that its
values of SKPICC and session
the
y.
y
authentication
ment of eID-PIN
T_MTD.1/eID-
block, FMT_MTD.1/eID-PIN_Activate) also support
emporal values of eID-
FIA_UAU.4, FIA_UAU.5 and FCS_CKM.4 represent some required specific properties of
the protocols used.
To allow a verification of the certificate chain as required in FMT_MTD.3, the CVCA’s
public key and certificate as well as the current date are written or update by authorised
identified role as required by FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD and
FMT_MTD.1/DATE.
The SFRs FCS_COP.1/SHA and FCS_COP.1/RND represent the general support for
cryptographic operations needed.
The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles related.
to make this key unreadable for a user, so that its value remains c
requires erasing the values of SKPICC and session keys (here: f
FMT_MTD.1/PA_UPD requires that SOC containing, amongst o
PKPICC and used for the
Personalisation Agent only and, hence, is to consider as trust
The SFRs FCS_COP.1/SHA and FCS_COP.1/RND represent the gen
cryptographic operations needed.
The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions an
The security objective OT.Data_Authenticity aims ensuring aut
and TSFdata (after the Terminal- and the Chip Authentication) by en
verification at the terminalside and by an active verification by the TOE itself
This objective is mainly achieved by FTP_ITC.1/CA using FCS_COP
prerequisite for establishing this trusted channel is a successful Chip Authen
FIA_API.1/CA using FCS_CKM.1/DH_CA and FCS_CKM.2/DH and possessing the sp
properties FIA_UAU.5, FIA_UAU.6. The CA provides an evidence of possessing the Chi
Authentication Private Key (SKPICC). FMT_MTD.1/SK_
FMT_MTD.1/KEY_READ requires to make this key un
value remains confidential. FDP_RIP.1 requires erasing the
keys (here: for KMAC).
FMT_MTD.1/PA_UPD requires that SOC containing, amongst other, signature over the
PKPICC and used for the Passive Authentication is allowed to be modified by
Personalisation Agent only and, hence, is to consider as trustworthil
A prerequisite for successful CA is an accomplished TA as required by
FIA_UID.1/Rightful_Terminal, FIA_UAU.1/Rightful_Terminal (is supported b
FCS_COP.1/SIG_VER). The TA protocol uses the result of the PACE
(FIA_UID.1/PACE, FIA_UAU.1/PACE) being, in turn, supported by FCS_CKM.1/DH_PACE.
Since PACE can use eID-PIN as the shared secret, using and manage
(FIA_AFL.1/eID-PIN_Suspending, FIA_AFL.1/eID-PIN_Blocking, FM
PIN_Resume, FMT_MTD.1/eID-PIN_Un
achievement of this objective. FDP_RIP.1 requires erasing the t
PIN, eID-PUK.
6 Security Requirements
Page 98 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
The security objective OT.Data_Confidentiality aims that the TOE always ensures
TSF-data stored and, after the Terminal- and the Chip
.1/TRM and
erminal
l_Terminal,
e TA protocol
A_UAU.1/PACE) being, in
N as the shared
/eID-PIN_Suspending,
.1/eID-
FMT_MTD.1/eID-PIN_Activate) also support achievement of this objective.
.
specific properties of
used.
the CVCA’s
y authorised
CA_UPD and
/CA using
lishing this trusted channel is a successful Chip
KM.2/DH and
CA provides an evidence
). FMT_MTD.1/SK_PICC
s to make this key
that its value remains confidential. FDP_RIP.1 requires erasing
gnature over the
dified by the
.
FCS_COP.1/SHA and FCS_COP.1/RND represent the general support for
eeded.
ated.
thering TOE
unambiguous identifying the ID_Card remotely through
face of the TOE
s (CAN, MRZ, eID-
(i) while establishing PACE communication with CAN, MRZ or eID-PUK (non-blocking
authentication / authorisation data) – by FIA_AFL.1/PACE;
(ii) while establishing PACE communication using eID-PIN (blocking authentication data)
– by FIA_AFL.1/eID-PIN_Blocking;
(iii) for listening to PACE communication and for establishing CA communication (is of
importance for the current ST, if SOC and PKPICC are card-individual) – FTP_ITC.1/PACE;
(iv) for listening to CA communication (readable and writable user data: document
details data, biographic data, biometric reference data; eSign-PIN) – FTP_ITC.1/CA.
confidentiality of the User- and
Authentication, of these data exchanged.
This objective for the data stored is mainly achieved by FDP_ACC
FDP_ACF.1/TRM. A concrete authorisation level is achieved by the t
identification/authentication as required by the SFRs FIA_UID.1/Rightfu
FIA_UAU.1/Rightful_Terminal (is supported by FCS_COP.1/SIG_VER). Th
uses the result of the PACE authentication (FIA_UID.1/PACE, FI
turn, supported by FCS_CKM.1/DH_PACE. Since PACE can use eID-PI
secret, using and management of eID-PIN (FIA_AFL.1
FIA_AFL.1/eID-PIN_Blocking, FMT_MTD.1/eID-PIN_Resume, FMT_MTD
PIN_Unblock,
FDP_RIP.1 requires erasing the temporal values of eID-PIN, eID-PUK
FIA_UAU.4, FIA_UAU.5 and FCS_CKM.4 represent some required
the protocols
To allow a verification of the certificate chain as required in FMT_MTD.3,
public key and certificate as well as the current date are written or update b
identified role as required by FMT_MTD.1/CVCA_INI, FMT_MTD.1/CV
FMT_MTD.1/DATE.
This objective for the data exchanged is mainly achieved by FTP_ITC.1
FCS_COP.1/AES. A prerequisite for estab
Authentication FIA_API.1/CA using FCS_CKM.1/DH_CA and FCS_C
possessing the special properties FIA_UAU.5, FIA_UAU.6. The
of possessing the Chip Authentication Private Key (SKPICC
governs creating/loading SKPICC, FMT_MTD.1/KEY_READ require
unreadable for a user, so
the values of SKPICC and session keys (here: for KEnc).
FMT_MTD.1/PA_UPD requires that SOC containing, amongst other, si
PKPICC and used for the Passive Authentication is allowed to be mo
Personalisation Agent only and, hence, is to consider as trustworthily
The SFRs
cryptographic operations n
The SFRs FMT_SMF.1 and FMT_SMR.1 support the functions and roles rel
The security objective OT.ID_Card_Tracing aims that the TOE prevents ga
tracing data by means of
establishing or listening to a communication via the contactless inter
without a priori knowledge of the correct values of shared password
PIN, eID-PUK).
This objective is achieved as follows:
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 99 of 128
Version 2.5 14.12.2010
The security objective OT.Chip_Auth_Proof aims enabling verification of the
KM.1/DH_CA. The CA
Key (SKPICC).
TD.1/KEY_READ requires
ains confidential. FDP_RIP.1
AC).
e SFRs
signature over the
the
s functions being
pulating and disclosing the
ting misuse of test and
E’s operational life phase.
tection against disclosure of
by the TOE.
This objectiv
nd amplitude of
signals or the time between events found by measuring signals on the
ck, or I/O lines,
E, and
.
e confidentiality
e stored in the
t operation of the
erating conditions.
_TST.1 requiring self tests to demonstrate the correct
of authorised users to verify the integrity of the TSF-data
uiring entering a
rating conditions possibly
causing a malfunction.
The rationale related to the security functional requirements taken over from [7] (incl.
OT.SCD/SVD_Gen, OT.Sigy_SigF and FIA_UAU.1/SSCD) are exactly the same as given for
the respective items of the security policy definitions in sec. 11.1 of [7].
6.3.2 Rationale for SFR’s Dependencies
The dependency analysis for the security functional requirements shows that the basis
for mutual support and internal consistency between all defined functional
authenticity of the TOE as a whole device.
This objective is mainly achieved by FIA_API.1/CA using FCS_C
provides an evidence of possessing the Chip Authentication Private
FMT_MTD.1/SK_PICC governs creating/loading SKPICC, FMT_M
to make this key unreadable for a user, so that its value rem
requires erasing the values of SKPICC and session keys (here: for CM
The authentication token TPICC is calculated using FCS_COP.1/CMAC. Th
FCS_COP.1/SHA and FCS_COP.1/RND represent the general support for cryptographic
operations needed.
FMT_MTD.1/PA_UPD requires that SOC containing, amongst other,
PKPICC and used for the Passive Authentication is allowed to be modified by
Personalisation Agent only and, hence, is to consider as trustworthily.
The security objective OT.Prot_Abuse_Func aims preventing TOE’
not intended to be used in the operational phase from mani
User- and TSFdata.
This objective is achieved by FMT_LIM.1 and FMT_LIM.2 preven
other functionality of the TOE having not to be used in the TO
The security objective OT.Prot_Inf_Leak aims pro
confidential User- or/and TSF-data stored on / processed
e is achieved
by FPT_EMSEC.1 for measurement and analysis of the shape a
electromagnetic field, power consumption, clo
by FPT_FLS.1 and FPT_TST.1 for forcing a malfunction of the TO
by FPT_PHP.3 for a physical manipulation of the TOE
The security objective OT.Prot_Phys-Tamper aims protection of th
and integrity of the User- and TSF-data as well as embedded softwar
TOE.
This objective is completely covered by FPT_PHP.3 in an obvious way.
The security objective OT.Prot_Malfunction aims ensuring a correc
TOE by preventing its operation outside the norma p
l o
This objective is covered by FPT
operation of the TOE and tests
and the embedded software (TSF code) as well as by FPT_FLS.1 req
secure state of the TOE in case of detected failure or ope
6 Security Requirements
Page 100 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
requirements is satisfied. All dependencies between the chosen functional components
lained.
ion of each SFR in
ment is justified.
endencies related to the security functional requirements
given for the respective items of the security
6.3.3
assurance
assurance from
nt practices which,
ills, and other
ghest level, at which it is likely to retrofit to an existing product
mstances where
red security
ty specific
nce of the security
secure handling of
ance than the pre-
-enforcing modules.
surance than the pre-
defined EAL4 package, namely requiring a vulnerability analysis to assess the resistance
to pe s performed by an attacker possessing a high attack potential (see
also T ‘Attacker’). This decision represents a part of the conscious security
e current ST.
requirements being part of EAL4 fulfils all dependencies a priori.
Th io ises the following assurance components:
– ALC
ATE
AV
For these additio nce components, dencies are met or exceeded in
the EAL4 assuran e:
are analysed, and non-dissolved dependencies are appropriately exp
The dependency analysis has directly been made within the descript
sec. 6.1 above. All dependencies being expected by CC part 2 and by extended
components definition in chap. 5 are either fulfilled or their non-fulfil
The rationale for SFR’s p
de
taken over from [7] are exactly the same as
policy definitions in sec. 11.2 of [7].
Security Assurance Requirements Rationale
The current assurance package was chosen based on the pre-defined
package EAL4. This package permits a developer to gain maximum
positive security engineering based on good commercial developme
though rigorous, do not require substantial specialist knowledge, sk
resources. EAL4 is the hi
line in an economically feasible way. EAL4 is applicable in those circu
developers or users require a moderate to high level of independently assu
in conventional commodity TOEs and are prepared to incur additional securi
engineering costs.
The selection of the component ALC_DVS.2 provides a higher assura
of the ID_Card’s development and manufacturing, especially for the
sensitive material.
The selection of the component ATE_DPT.2 provides a higher assur
defined EAL4 package due to requiring the functional testing of SFR
The selection of the component AVA_VAN.5 provides a higher as
netration attack
able 4, entry
policy for the ID_Card required by the ID_Card Issuer and reflected by th
The set of assurance
e augmentat n of EAL4 chosen compr
_DVS.2,
– _DPT.2 and
– A_VAN.5.
nal assura all depen
ce packag
Component Dependencies required by
CC Part 3 or ASE_ECD
Dependency fulfilled by
TOE security assurance requirements (only additional to EAL4)
ALC_DVS.2 no dependencies -
ADV_ARC.1 ADV_ARC.1
ADV_TDS.3 ADV_TDS.3
ATE_DPT.2
ATE_FUN.1 ATE_FUN.1
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 101 of 128
Version 2.5 14.12.2010
Component Dependencies required by
CC Part 3 or ASE_ECD
Dependency fulfilled by
ADV_ARC.1 ADV_ARC.1
ADV_FSP.4 ADV_FSP.4
ADV_TDS.3 ADV_TDS.3
ADV_IMP.1 ADV_IMP.1
AGD_OPE.1 AGD_OPE.1
AGD_PRE.1 AGD_PRE.1
AVA_V
T.2
AN.5
ATE_DPT.1 ATE_DP
Table 15 SAR Dependencies
6.3.4 Security Requirements – Internal Consistency
The following part of the security requirements rationale shows that the set of security
nts (SFRs) and the
consistent whole.
eir mutual supportiveness
endencies’ for the security
shows that the basis for internal consistency between all defined
hosen functional
ly explained.
.1 are also treated in a
nsistent way: the SFRs impacting them do not require any contradictory property and
consistent assurance
nce requirements are
nconsistency
appears.
nd assurance requirements could only arise, if there are
functional-assurance dependencies being not met: an opportunity shown not to arise in
ssurance
.3 ‘Security Assurance
urance components are adequate for the functionality
inconsistencies between the goals of these two groups of security
requirements.
6.4 Statement of Compatibility
This is a statement of compatibility between this Composite Security Target (Composite-
ST) and the Platform Security Target (Platform-ST) of the Chip P5CD128V0A [21]. This
statement is compliant to the requirements of [4a].
6.4.1 Classification of Platform TSFs
A classification of TSFs of the Platform-ST has been made. Each TSF has been classified
as ‘relevant’ or ‘not relevant’ for the Composite-ST.
requirements for the TOE consisting of the security functional requireme
security assurance requirements (SARs) together forms an internally
The analysis of the TOE´s security requirements with regard to th
and internal consistency demonstrates:
The dependency analysis in section 6.3.2 ‘Rationale for SFR’s Dep
functional requirements
functional requirements is satisfied. All dependencies between the c
components are analysed and non-satisfied dependencies are appropriate
All subjects and objects addressed by more than one SFR in sec. 6
co
behaviour of these ‘shared’ items.
The assurance package EAL4 is a pre-defined set of internally
requirements. The dependency analysis for the sensitive assurance components in section
6.3.3 ‘Security Assurance Requirements Rationale’ shows that the assura
internally consistent as all (additional) dependencies are satisfied and no i
Inconsistency between functional a
sections 6.3.2 ‘Rationale for SFR’s Dependencies’ and 6.3.3 ‘Security A
Requirements Rationale’. Furthermore, as also discussed in section 6.3
Requirements Rationale’, the chose ss
n a
of the TOE. So, there are no
6 Security Requirements
Page 102 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
TOE Security Functionality
Relevant
Not
relevant
SS.RNG: Random Number Generator x
SS.HW_DES: Triple-DES Co-processor x
SS.HW_AES: AES coprocessor x
SF.OPC: Control of Operating Condition x
s
SF.PHY: Protection against Physical Manipulation x
SF.LOG: Logical Protection x
SF.COMP: Protection of Mode Control x
SF.MEM_ACC: Memory Access Control x
SF.SFR_ACC: Special Function Register Access
Control
x
Table 16: Classification of Platform-TSFs
g protection against SPA/DPA and timing attacks.
the TOE does not use the DES
Co-processor.
d SF.SFR_ACC are not relevant for the Composite-ST because the
combination of SF.SFR_ACC and SF.COMP ensures that the other CPU modes are not
or specific purposes
ST.
6.4.2
the IC:
 True Random Number Generator (TRNG) with P2 SOF-high classification
according to AIS 31 [12b],
 Cryptographic support based on asymmetric and symmetric key algorithms (EC-
DSA, AES) with 256 bit asymmetric key length and 168 bit symmetric
cryptographic key length.
The rationale of the Platform-ST has been used to identify the relevant SFRs, TOE
objectives, threats and OSPs. As SF.PHY is mapped to all SFRs except FPT_SEP.1[CONF]
all SFRs, objectives for the TOEs, but also all objectives for the TOE-environment, all
threats and OSPs of the Platform-ST have been used for the following analysis.
SF.LOG is relevant by providin
SS.HW_DES is not relevant for the Composite-ST because
SF.MEM_ACC an
available for the Smartcard Embedded Software, but reserved f
fulfilled by the IC Dedicated Software.
All other listed TSFs of the Platform-ST are relevant for the Composite-
Matching statement
The TOE relies on fulfillment of the following implicit assumptions on
 Certified NXP Microcontroller P5CD128V0A,
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 103 of 128
Version 2.5 14.12.2010
6.4.2.1 TOE Security Environment
6.4.2.
efore not
atform-ST deals with
and decryption and
Tamper of the
threats of this Composite-ST are directly related to IC functionality:
er
Malfunction
ation_Leakage
 ery
e mapped to the following Platform-ST threats:
-Inherent
s_Probing
T.Malfunction
 T.Phys_Manipulation
 .Leak-Forced
 T.Abuse-Func
 T.RND
The following table shows the ap g t th ts
1.1 Threats and OSPs
(see chapters 3.2 and 3.3)
None of the OSPs of the Composite-ST are applicable to the IC and ther
mapable for the Platform-ST.
The organizational security policy P.Add-Components of the Pl
additional specific security components like the AES encryption
could therefore be mapped to OT.Prot_Inf_Leak and OT.Prot_Phys-
Composite-ST.
The following
 T.Phys_Tamp
 T.
 T.Abuse-Func
 T.Inform
T.Forg
These threats will b
 T.Leak
 T.Phy

T
m pin of he rea .
Platform-ST
T.Leak-Inherent
T.Phys_Prob
g
in
T.Phys_Manipulation
T.Malfunc
tion
T.Leak-Forced
T.Abuse-Func
T.RND
T.Phys_Tamper X X X X X X
T.Malfunction X
T.Abuse-Func
X
T.Information_Leakage
X X X X X X
Composite-ST
T.Forgery
X X
Table 17: Mapping of threats
6 Security Requirements
Page 104 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
alfunction, T.Phys-
aces like emanations,
ulnerabilities.
g, T.Malfunction,
sical TOE interfaces like
and tampering could be used to exploit
to disclose
.Phys_Manipulation and T.Malfunction because if an attacker
ently alters the User Data or/and TSF-data stored on the ID_Card or/and
een the TOE and the Service Provider then the listed threats of the
6.4.2.1.2
(see
The s from this ST (A.CGA, A.SCA) make no assumption on the Platform,
t ir ent of the TOE.
The on
T. Phys_Tamper matches to T.Leak-Inherent, T.Phys_Probing, T.M
Manipulation, T.Leak-Forced and T.RND as physical TOE interf
probing, environmental stress and tampering are used to exploit v
T.Information_Leakage matches to T.Leak-Inherent, T.Phys_Probin
T.Phys-Manipulation, T.Leak-Forced and T.Abuse-Func as phy
emanations, probing, environmental stress
exploit information leaking from the TOE during its usage in order
confidential User Data or/and TSF-data.
T.Forgery matches to T
fraudul
exchanged betw
Platform-ST could be relevant.
Assumptions
chapter 3.4
assumption
)
bu to the env onm
assumpti s from the Platform-ST are as follows:
Assumption Classification
of
assumptions
Mapping to Security Objectives of this Composite-ST
A.Process-Card [9] not relevant n/a
A.Plat-Appl [9] not relevant n/a
A.Resp-Appl [9] levan a_Authenticity,
Confidentiality, OT.Prot_Abuse-Func Protection,
nalisation,
T.SCD_Secrecy,
_Secure, OT.Sigy_SigF, OT.DTBS_Integrity_ TOE.
the above listed Security Objectives of this Composite
D, SVD, DTBS
and RAD.
re t OT.Data_Integrity Integrity of Data, OT.Dat
OT.Data_
OT.Prot_Phys-Tamper Protection, OT.Perso
OT.SCD/SVD_Gen, OT.SCD_SVD_Corresp, O
T.Sig
All of
TOE aim to protect the user data, especially SC
A.Check-Init relevant OT.Lifecycle_Security tests the integrity of the TSF and the TSF
data in the EEPROM.
A.Key-F ndent functions are
implemented in a way that they are not susceptible to leakage
attacks.
unction relevant OT.EMSEC_Design requires that Key-depe
Table 18: Mapping of assumptions
between security environments of this Composite-ST and the
latform-ST [9].
6.4.2.2 Security objctives
This Composite-ST has security objectives which are related to the Platform-ST.
These are:
 OT.SCD_Secrecy
 OT.SCD_Unique
 OT.Tamper_ID
 OT.Tamper_Resistance
There is no conflict
P
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 105 of 128
Version 2.5 14.12.2010
 OT.Prot_Abuse-Func
Leak
Phys-Tamper
OT.Prot_Malfunction
ng Platform-objectives could be mapped to Composite-objectives:
_AES
 O.Phys-Probing
function
pulation
e-Func
 O.Leak-Inherent
 O.Identification
 O.Malfunction
These could be mapped to the Composite-objec s s the following table.
 OT.Prot_Inf_
 OT.Prot_
 OT.Identification

The followi
 O.RND
 O.HW
 O.Mal
 O.Phys-Mani
 O.Abus
 O.Leak-Forced
tive as een in
Platform-ST
O.RND
O.Phys-Probing
O.Malfunction
O.Phys-Manipulation
O.Abuse-Func
O.HW_AES
O.Leak-Forced
O.Leak-Inherent
O.Identification
O.Malfunction
OT.SCD_Secrecy X
OT.SCD_Unique X
OT.Tamper_ID X X X
OT.Tamper_Resistance X X X X
OT.Prot_Abuse-Func X
OT.Prot_Inf_Leak X X
OT.Prot_Phys-Tamper X X X X
OT.Identification X
Composite-ST
OT.Prot_Malfunction X
Table 19: Mapping of objectives
OT.SCD_Secrecy and OT.SCD_Unique require sufficient quality of random numbers for
the generation of SCD/SVD, which matches to O.RND.
OT.Tamper_ID, OT.Tamper_Resistance and OT.Prot_Phys-Tamper require detection of
and resistance to physical tampering which matches to O.Phys-Probing, O.Phys-
Manipulation O.Malfunction and O.HW_AES.
6 Security Requirements
Page 106 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
The following Platform-objectives are not relevant for the Composite-TOE:
ARE firewall.
se are based memory
 O.SFR_ACCESS because the Composite-TOE does not use special function
r 4.2 and [6]) are not linked to
he platform and are therefore not applicable to this mapping. These objectives are:
by Signature
ip Authentication Key
ard
 _Authentication Authentication of rightful terminals
minal Terminal operating
rd-Holder ID_Card holder Obligations
uth
_QCert
.DTBS_Intend
 OE.CGA_TC_SVD
lict between security objectives of this Composite-ST and the
latform-ST [9].
6.4.2.3 requirements
6.4.2.3.1 curity Functional Requirements
site-ST has the following platform related SFRs:
 FCS_CKM.1
 FCS_COP.1/AES
 FPT_PHP.1
 FPT_PHP.3
 FCS_RND.1
 FPT_EMSEC.1
 FPT_FLS.1
 O.HW_DES3 because the Composite-TOE does not use T-DES functionality.
 O.MF_FW because the Composite-TOE does not use the MIF
 O.MEM_ACCESS because the Composite-TOE does not u
access control.
register access control.
All Security Objectives for the Environment (see chapte
t
 OE.Legislative_Compliance
 OE.Passive_Auth_Sign Authentication of ID_Card
 OE.Chip_Auth_Key Ch
 OE.Personalisation Personalisation of ID_C
OE.Terminal
 OE.Ter
 OE.ID_Ca
 OE.SVD_A
 OE.CGA
 OE.HID_VAD
 OE
 OE.DTBS_Protect
 OE.CGA_SSCD
There is no conf
P
Security
Se
This Compo
6 Security Requirements
Security Target Lite STARCOS 3.5 ID GCC C1 Page 107 of 128
Version 2.5 14.12.2010
 FMT_LIM.1/2
g Platform-SFRs could be mapped to Composite-SFRs:
T.2
.1
P.3
COP.1[AES]
 FAU_SAS.1.
mapped as n t fo w t le
 FAU_SAS.1.
The followin
 FCS_RND.1
 FRU_FL
 FPT_FLS
 FPT_PH
 FCS_
 FMT_LIM.1/2
They will be see in he llo ing ab .
Platform-ST
FCS_RND.1
FCS_COP.1[AES]
FRU_FLT.2
FPT_FLS.1
FPT_PHP.3
FMT_LIM.1/2
FAU_SAS.1
FCS_CKM 1 X
.
FCS_COP /A X
.1 ES
FPT_PHP.1 X X X
FPT_PHP.3 X X X
FCS_RND.1 X
FPT_EMSEC.1 X
FPT_FLS.1 X
FMT_LIM.1/2 X
Composite-ST
FAU_SAS.1 X
Table 20: Mapping of SFRs
FCS_CKM.1 requires sufficient quality of random numbers for the generation of
d by the TOE.
f the composite ST matches the robustness requirements of
FMT_LIM.1/2 of the composite TOE matches to the equivalent SFR of the platform TOE.
FAU_SAS.1 of the composite TOE matches to the equivalent SFR of the platform TOE.
The following Platform-SFRs could not be be mapped to Composite-SFRs:
 FCS_COP.1[DES] because no DES is used for the composite TOE.
 FDP_ACC.1[MEM] because the composite TOE is always in system mode and
therefore no MMU is necessary.
 FDP_ACC.1[SFR] because the composite TOE does not use the platform TOE
special function registers.
SCD/SVD, which matches to FCS_RND.1.
FCS_COP.1 matches to FCS_COP.1[AES] when the AES coprocessor is use
FPT_PHP.1 and FPT_PHP.3 o
FRU_FLT.2, FPT_FLS.1 and FPT_PHP.3 of the platform ST.
6 Security Requirements
Page 108 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
 FDP_ACF.1[MEM] because the composite TOE is always in system mode and
FDP_ACF.1[SFR] because the composite TOE does not use the platform TOE
system mode and
ecessary.
system mode and
U is necessary.
 platform TOE
the CPU mode.
TOE delivery.
policy of the
impact the composite TOE.
 FPT_ITT.1 because it deals with the basic internal data protection of the platform
does not by itself impact the composite TOE.
the platform TOE
pact the composite TOE.
6.4.2.3
EAL 4 according to Common Criteria V3.1R3 augmented by
1 R3 augmented by:
g the component
de architectural information on the security
functionality of the TOE. his additional architectural information has no direct impact
ted parts of the
to the Platform-ST assurance requirements. But also the
augmented parts of the Composite-ST match to the Platform-ST except ATE_DPT.2.
However, this additional augmentation of the composite TOE has no direct link to the
platform TOE and is therefore without conflict.
6.4.3 Overall no contracdictions found
Overall there is no conflict between security requirements of this Composite-ST and
the Platform-ST.
therefore no MMU is necessary.

special function registers.
 FMT_MSA.3[MEM] because the composite TOE is always in
therefore no MMU is n
 FMT_MSA.1[MEM] because the composite TOE is always in
therefore no MM
FMT_MSA.1[SFR] because the composite TOE does not use the
special function registers.
 FMT_SMF.1 because ther TOE does not change
 FAU_SAS.1 because it deals with test process before platform
 FDP_ITT.1 because it deals with the internal data processing
platform TOE that does not by itself
TOE that
 FDP_IFC.1 because it deals with the data processing policy of
that does not by itself im
.2 Assurance requirements
The Composite-ST requires
ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5
The Platform-ST requires EAL 5 according to Common Criteria V3.
ALC_DVS.2 and AVA_VAN.5. The Security Target is augmented usin
ASE_TSS.2, which is chosen to inclu
T
on the composite TOE.
As EAL 5 covers all assurance requirements of EAL 4 all non augmen
Composite-ST will match
7 TOE summary specification
Security Target Lite STARCOS 3.5 ID GCC C1 Page 109 of 128
Version 2.5 14.12.2010
7 TOE summary specification
This chapter gives the overview description of the different TOE Security Functions
rity Functions
7.1.1
others the maintenance
different users (Administrator, Signatory). After activation or reset no user is
asymmetric dev
nature PIN. After 10
PIN is permanently
cording to [11], sec. 4.2
, Version 2 is prevented.
dure as the sequence
], sec. 4.4, Version 2,
Version 2°287
, and
n-authenticate mode according to [11],
at only the Administrator can generate the
way for
dministrator can store the certificate or
trol mechanisms
e PIN or generate
curity relevant actions
ser authentication.
e-Personalisation
Data in audit records through the Manufacturer.
er in Phase 6. If Test Features are
performed by the TOE then no User Data can be disclosed or manipulated, no TSF data
can be disclosed or manipulated, no software can be reconstructed and no substantial
information about construction of TSF can be gathered which may enable other attacks.
Only secure values of the certificate chain are accepted for TSF data of the Terminal
Authentication Protocol and the Access Control.
All security attributes under access control are modified in a secure way so that no
unauthorised modifications are possible.
composing the TSF.
7.1 TOE Secu
SF_AccessControl
The TOE provides access control mechanisms that allow among
of
authenticated. The Administrator can authenticate himself using ice
authentication. The Signatory can au nticate himself using the sig
the
roc
unsuccessful consecutive authentication attempts the signature
blocked.
The reuse of authentication data related to PACE Protocol ac
and Terminal Authentication Protocol according to [11], sec. 4.4
To support user authentication General Authentication P e
certificate
 PACE Protocol according to [11], sec. 4.2,
 Terminal Authentication Protocol according to [11
 Chip Authentication Protocol according to [11], sec. 4.3,
 Secure messaging in encrypt-the
Appendix is implemented.
The access control mechanisms ensure th
signature key pair or export the public signature key in an authentic
certification. In addition, only the A
information for the public signature key on the TOE. The access con
also ensure that only the Signatory can set and change the signatur
electronic signatures using the private signature key.
The access control mechanisms allow the execution of certain se
(e.g. self-tests) without successful u
The access control mechanisms allow the storage of Initialisation and Pr
Test Features of the TOE are not available for the us
287
the Passive Authentication is considered to be part of the Chip Authentication (CA) Protocol within this PP.
7 TOE summary specification
Page 110 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
7.1.2
n the
are overwritten.
a integrity checking.
s residing on the TOE
ded to be signed.
information about IC power consumptions and command execution
formation can be derived from this data.
7.1.3
erating voltage, clock
etic radiation. The TOE is resistant to physical
sensors, that it is
and the TOE is not
the hardware
g.
rates the correct operation of the TSF by among others verifying the
njections. In the
jections during the
e.
7.1.4
4 (high) according
ic random number generator is provided by
rresponding EC-DSA keypairs with ke
s the TOE uses random numbers generated by its K4 (high)
mber generator.
PROM with zero
The TOE supports the distribution of cryptographic keys in accordance with PACE: as
as specified in [11].
7.1.5
ld F(p) and with
supports calculations
ulations the TOE
supports generation of EC-DSA signatures according to EN14890 [15a].
7.1.6 SF_TrustedCommunication
The TOE supports the establishment of a trusted channel/path based on mutual
authentication with negotiation of symmetric cryptographic keys used for the protection
of the communication data with respect to confidentiality and integrity. The mutual
authentication is based on a challenge response protocol using the AES algorithm in
CBC mode with key sizes of 128 bits. This algorithm is also used for encryption and
integrity protection of the communication data. Via this trusted channel/path the
SF_AssetProtection
When the private signature key or the signature PIN are no longer needed i
internal memory of the TOE for calculations these parts of the memory
The TOE supports the calculation of block check values for dat
These block check values are stored with persistently stored asset
as well as temporarily stored hash values for data that is inten
The TOE hides
time, to ensure that no confidential in
SF_TSFProtection
The TOE detects physical tampering of the TSF with sensors for op
frequency, temperature and electromagn
tampering of the TSF. If the TOE detects with the above mentioned
not supplied within the specified limits, a security reset is initiated
operable until the supply is back in the specified limits. The design of
protects it against analysing and physical tamperin
The TOE demonst
integrity of the TSF and TSF data and verifying the absence of fault i
case of inconsistencies in the calculation of the signature and fault in
operation of the TSF the TOE preserves a secure stat
SF_KeyManagement
The TOE contains a deterministic random number generator rated K
to AIS20 [12]. The seed for the determinist
the P2 (high) true random number generator of the underlying IC.
The TOE supports onboard generation of co y
length 256 bit. For thi
deterministic random nu
The TOE supports overwriting the cryptographic keys stored in the EE
values prior to conclusion of the Personalisation Phase.
specified in [11] and CA:
SF_SignatureGeneration
The TOE supports calculations with elliptic curves defined over a fie
lengths of the parameters p and q of 256 bit. In addition, the TOE
of hash values according to SHA-2 (256 bit). Based on these calc
7 TOE summary specification
Security Target Lite STARCOS 3.5 ID GCC C1 Page 111 of 128
Version 2.5 14.12.2010
Administrator can authentically export the public signature key for certification and
import the certificate or certificate information for the public signature key.
7.2
uirements listed in
The following table lists the Assurance measures and references the corresponding
uments describing the measures
Assurance Measures
This chapter describes the Assurance Measures fulfilling the req
chapter 6.3.
doc .
Assurance
Measures
Description
AM_ADV e documentation for
r TOE design, in the
n.
The representing of the TSF is described in th
functional specification, in the documentation fo
security architecture description and in the documentation for
implementation representatio
AM_AGD the operational user
gu documentation for preparative
The guidance documentation is described in
idance documentation and in the
procedures.
AM_ALC ts development and
cycle documentation including
n management, delivery procedures, development
security as well as development tools.
The life cycle support of the TOE during i
ed in the life
maintenance is describ
configuratio
AM_ATE The testing of the TOE is described in the test documentation..
AM_AVA The vulnerability assessment for the TOE is described in the
vulnerability analysis documentation.
Table 21 References of Assurance measures
7.3 Fulfilment of the SFRs
The following table shows the mapping of the SFRs to security functions of the TOE.
7 TOE summary specification
Page 112 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
SF_AccessControl
SF_AssetProtection
SF_TSFProtection
SF_KeyManagement
SF_SignatureGeneration
SF_TrustedCommunication
FCS_CKM.1/DH_PACE X
FCS_CKM.1/DH_CA X
FCS_CKM.2/DH X
FCS_CKM.4 X
FCS_COP.1/SHA X
FCS_COP.1/SIG_VER X
FCS_COP.1/AES X
FCS_COP.1/CMAC X
FCS_RND.1 X
FCS_CKM.1/SSCD X
FCS_CKM.4/SSCD X
FCS_COP.1/SSCD X
FIA_AFL.1/eID-PIN_Su
spending
X
FIA_AFL.1/eID-
X
PIN_Blocking
FIA_AFL.1/PACE X
FIA_API.1/CA X
FIA_UID.1/PACE X
FIA_UID.1/Rightful_Term
X
i
nal
FIA_UAU.1/PACE X
FIA_UAU.1/Rightful_Termi
X
nal
FIA_UAU.1/SSCD X
FIA_UAU.4 X
FIA_UAU.5 X
FIA_UAU.6 X
FIA_UID.1/SSCD X
FIA_AFL.1/SSCD X
FDP_ACC.1/TRM X
FDP_ACF.1/TRM X
FDP_RIP.1 X
FDP_ACC.1/SCD/SVD_Ge X
7 TOE summary specification
Security Target Lite STARCOS 3.5 ID GCC C1 Page 113 of 128
Version 2.5 14.12.2010
SF_AccessControl
SF_AssetProtection
SF_TSFProtection
SF_KeyManagement
SF_SignatureGeneration
SF_TrustedCommunication
neration_SFP_SSCD
FDP_ACF.1/SCD/SV
eration
D_ n
_SFP_SSCD
Ge
X
FDP_ACC.1/SVD_Tran r
sfe
_SFP_SSCD
X
FDP_ACF.1/SVD_Tran r_
sfe
SFP_SSCD
X
FDP_ACC.1/Signature
CD
-
creation_SFP_SS
X
FDP_ACF.1/Signature-
SFP_SSCD
creation_
X
FDP_RIP.1_SSCD X
FDP_SDI.2/Persistent_SSC
X
D
FDP_SDI.2/DTBS_SSCD X
FTP_ITC.1/PACE X
FTP_ITC.1/CA X
FAU_SAS.1 X
FMT_SMF.1 X
FMT_SMR.1 X
FMT_LIM.1 X
FMT_LIM.2 X
FMT_MTD.1/INI_ENA X
FMT_MTD.1/INI_DIS X
FMT_MTD.1/CVCA_IN I X
FMT_MTD.1/CVCA_U PD X
FMT_MTD.1/DATE X
FMT_MTD.1/PA_UPD X
FMT_MTD.1/SK_PICC X
FMT_MTD.1/KEY_RE AD X
FMT_MTD.1/eID-PIN_
Resume
X
FMT_MTD.1/eID-PIN_
Unblock
X
FMT_MTD.1/eID-PIN_ X
7 TOE summary specification
Page 114 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
SF_AccessControl
SF_AssetProtection
SF_TSFProtection
SF_KeyManagement
SF_SignatureGeneration
SF_TrustedCommunication
Activate
FMT_MTD.3 X
FMT_SMR.1/SSCD X
FMT_SMF.1/SSCD X
FMT_MOF.1/SSCD X
FMT_MSA.1/Admin_SSCD X
FMT_MSA.1/Signatory_
X
SS
CD
FMT_MSA.2/SSCD X
FMT_MSA.3/SSCD X
FMT_MSA.4/SSCD X
FMT_MTD.1/Admin_SSCD X
FMT_MTD.1/Signatory_
X
SS
CD
FPT_EMSEC.1 X
FPT_FLS.1 X
FPT_TST.1 X
FPT_PHP.3 X
FPT_EMSEC.1/SSCD X
FPT_FLS.1/SSCD X
FPT_PHP.1/SSCD X
FPT_PHP.3/SSCD X
FPT_TST.1/SSCD X
Table 22 Mapping of SFRs to mechanisms of TOE
7.3.1 Justifications for the correspondence between functional
requirements and TOE mechanisms
Each TOE security functional requirement is implemented by at least one TOE
mechanism. In section 7.1 the implementing of the TOE security functional requirement
is described in form of the TOE mechanism.
8 Glossary and Acronyms
Security Target Lite STARCOS 3.5 ID GCC C1 Page 115 of 128
Version 2.5 14.12.2010
8 Glossary and Acronyms
.1 Gloss
8 ary
Term Definition
Accurate Termin
Certificate
ocument Verifier is
l Certificates with
c. 2.2.5.
al
A Terminal Certificate is accurate, if the issuing D
trusted by the ID_Card’s chip to produce Termina
the correct certificate effective date, see [11], se
Agreement t ST in order to reflect an appropriate
as a legal notion.
This term is used in the curren
relationship between the parties involved, but not
Application Note
ining sensitive supporting
Optional informative part of the PP conta
information that is considered relevant or useful for the
construction, evaluation or use of the TOE.
Audit records
the ID_Card’s chip to
on Data.
Write-only-once non-volatile memory area of
store the Initialisation Data and Pre-personalisati
Authentication
inal (
term ATT)
by a
ental organisation (Official Domestic Document Verifier) or
d (i) verifying the
ard holder (using the secret eID-
plication and (iii)
above and [11],
equivalent to CGA
A technical system being operated and used either
governm
by any other, also commercial organisation an
ID_Card presenter as the ID_C
PIN288
), (ii) updating a subset of data of the eID ap
activating the eSign application. See also par. 23
chap. 3.2 and C.4. For the eSign application, it is
as defined in [7].
Authenticity
data elements
Ability to confirm that the ID_Card itself and the
stored in were issued by the ID_Card Issuer
Basic Control anism defined in [8] by which means the MRTD’s chip
mmunication by
Access Keys (see
and access condition
to LDS.
Access
Security mech
proves and the inspection system protects their co
means of secure messaging with Document Basic
there) based on MRZ information as key seed
to data stored on MRTD’s chip according
Basic Inspection
System (BIS)
289
and operated by a
governmental organisation (i.e. an Official Domestic or Foreign
Document Verifier) and verifying correspondence between the
BIS implements the terminal’s part of the Basic Access Control
protocol and authenticates itself to the ID_Card using the Document
Basic Access Keys drawn form printed MRZ data for reading the less-
sensitive data (ID_Card document details data and biographical
data) stored on the ID_Card (ePassport application only).
See also Application Note 4, [11], chap. G.1 and H; also [8].
A technical system being used by an authority
stored and printed MRZ.
288
the secret eID-PUK can be used for unblocking the eID-PIN and resetting the retry counter related
289
concretely, by a control officer
8 Glossary and Acronyms
Page 116 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Term Definition
Biographical data
as text in
the visual and machine readable zones of and electronically stored in
e data.
The personalised details of the ID_Card holder appearing
(biodata)
the ID_Card. The biographical data are less-sensitiv
Biometric referen
data metric reference
ce Data stored for biometric authentication of the ID_Card holder in
the ID_Card as (i) digital portrait and (ii) optional bio
data.
Card Access
Number (CAN)
he document. The
ay be static (printed on
el on the
by the electronic
LED or similar
A short password that is printed or displayed on t
CAN is a non-blocking password. The CAN m
the Identi tion Card
fica ), semi-static (e.g. printed on a lab
Identification Card) or dynamic (randomly chosen
ID_Card and displayed by it using e.g. ePaper, O
technologies), see [11], sec. 3.3
Card Security
Object (SOC)
y the Document
ardSecurity, see [11],
lues of different
all also carry the
An RFC3369 CMS Signe ata Str
d D ucture signed b
Signer (DS). It is stored in the ID_Card (EF.C
table A.1 and sec. A.1.2) and carries the hash va
Data Groups as defined in [11], Appendix A. It sh
Document Signer Certificate (CDS), [11], A.1.2.
Certificate chain
west level),
ification Authority
f a lower lever is
ublic key in the
ry Verifying
ith the private key
ey it contains (self-signed certificate).
Hierarchical sequence of Terminal Certificate (lo
Document
Verifier Certificate and Country Verifying Cert
Certificates (highest level), where the certificate o
signed with the private key corresponding to the p
certificate of the next higher level. The C nt
ou
Certification Authority Certificate is signed w
corresponding to the pub k
lic
Certification Serv
Provider (CSP)
mmon’ CSP, who
also
ense of [7].
ice
related to electronic signatures. There can be ‘co
cannot issue qualified
An organisation issuing certificates or providing other services
certificates and ‘qualified’ CSP, who can
issue qualified certificates.
A CSP is the Certification Service Provider in the s
Counterfeit
An unauthorised copy or reproduction of a ge
docume
nuine security
nt made by whatever means. [8]
Country Signing
CertA Certificate
(CCSCA)
hority Public Key
ssued by Country Signing Certification Authority and
Certificate of the Country Signing Certification t
(KPuCSCA) i
Au
stored in the rightful terminals.
Country Signing
Certification
Authority (CSCA)
d Issuer with
of user and TSF data stored in the
ic root of the PKI
r Certificates
The CSCA also issues the self-signed CSCA Certificate (CCSCA)
having to be distributed by strictly secure diplomatic means, see. [8],
5.1.1.
The CSCA issuing certificates for Document Signers (cf. [8]) and the
domestic CVCA may be integrated into a single entity, e.g. a
Country CertA. However, even in this case, separate key pairs must
be used for different roles, see [11], sec. 2.2.1
An organisation enforcing the policy of the ID_Car
respect to confirming correctness
ID_Card. The CSCA represents the country specif
for the ID_Cards and creates the Document Signe
within this PKI.
Country Verifying
Certification
Authority (CVCA)
An organisation enforcing the privacy policy of the ID_Card Issuer
with respect to protection of user data stored in the ID_Card (at a
trial of a terminal to get an access to these data). The CVCA
8 Glossary and Acronyms
Security Target Lite STARCOS 3.5 ID GCC C1 Page 117 of 128
Version 2.5 14.12.2010
Term Definition
represents the country specific root of the PK
terminals (EIS, ATT, SGT) and creates the Documen
Cert
I for the rightful
t Verifier
ificates within this PKI. The updates of the public key of the
ficates, see [11],
d the
ntity, e.g. a
te key pairs must
, see [11], sec. 2.2.1
CVCA are distributed in form of CVCA ink-Certi
chap. 2.2.1.
The CSCA issuing tificates for Document Signers (cf. [8]) an
L
cer
diff
domestic CVCA may be integrated into a single e
Country CertA. However, even in this case, separa
be used for erent roles
Current date contained in a valid CVCA
minal Certificate
The most recent certificat ffective date
e e
Link Certificate, a DV Certificate or an Accurate Ter
known to the TOE, see [11], sec. 2.2.5.
CV Certificate appendix C.
Card Verifiable Certificate according to [11],
CVCA link
Certificate
Certificate of the new public key of the Country V
Certification Authority signed with the old publ
Verifying Certification Authority where the certif
for the new key is
erifying
ic key of the Country
icate effective date
before the certificate expiration date of the
key.
certificate for the old
Digital Signatur pean parliament
of the council of 13 December 1999 on “a Community
signature qualifies as
atory can maintain under his sole
manner that any
e according to the Directive 1999/93/ec of the Euro
and
framework for electronic signatures” a digital
an electronic signature, if it is:
-uniquely linked to the signatory;
-capable of identifying the signatory;
-created using means that the sign
control, and
-linked to the data to which it relates in such a
subsequent change of the data is detectable.
Document Deta
Data
ID_Card
cument type, issuing state,
ent number, date of issue, date of expiry, issuing authority.
.
ils Data printed on and electronically stored in the
representing the document details like do
docum
The document details data are less-sensitive data
Document Secu ed by the Document
ta Groups. It is
_Card. It may carry the
rity A RFC3369 CMS Signed Data Structure, s
Object (SOD)
ign
Signer (DS). Carries the hash values of the LDS Da
stored in the ePassport application of the ID
Document Signer Certificate (CDS); see [8].
Document Sign
(DS)
and signing the
for passive
al CSCA issuing the
ap. 1.1 and [8].
This role is usually delegated to the Personalisation Agent.
er
An organisation enforcing the policy of the CSCA
ID_Card Security Object stored on the ID_Card
authenticat .
ion
A Document Signer is authorised by the nation
Document Signer Certificate (CDS), see [11], ch
Document Verifier
(DV)
An organisation (certification authority) enforcing the policies of the
CVCA and of a service provider (governmental or commercial
organisation) and managing the terminals belonging together (e.g.
terminals operated by a State’s border police) by – inter alia – issuing
Terminal Certificates. A Document Verifier is therefore a CertA,
authorised by at least the national CVCA to issue certificates for
national terminals, see [11], chap. 2.2.2.
There can be Domestic and Foreign DV: A domestic DV is acting
under the policy of the domestic CVCA being run by the ID_Card
8 Glossary and Acronyms
Page 118 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Term Definition
Issuer; a foreign DV is acting under a policy of the re
CVCA (in this case there shall be an appropriate agreement between
spective foreign
enforcing the
the ID_Card Issuer und a foreign CVCA ensuring
ID_Card Issuer’s privacy policy290
)
Eavesdropper
en the ID_Card
_Card.
A threat agent reading the communication betwe
and the Service Provider to gain the data on the ID
eID application
table, related user data
or authentication; this application is intended
ervices, which
context of this
A part of the TOE containing the non-execu
and the ta needed f
da
to be used for accessing official and commercial s
require access to the user data stored in the
application. See [11], sec. 3.1.2.
Enrolment
son and the
ference
].
The process of collecting biometric samples from a per
subsequent preparation and storage of biometric re
templates representing that person's identity; see [8
ePassport
application
, related user data
authentication (incl.
ed by authorities, amongst
D). See [11], sec.
A part of the TOE containing the non-executable
(incl. biometric) as well as the data needed for
MRZ); this application is intended to be us
other as a machine readable travel document (MRT
3.1.1.
eSign application
ata needed for
tely: digital)
as for
used in the context
vanced or qualified
an optionally be
ice Provider (or on
ective authorisation
See [11], sec. 3.1.3.
his application is intended to be
of official and commercial services, where an ad
digital signature of the ID_Card holder is required.
The eSign application is optional: it means that it c
activated291
on the ID_Card by a Certification Serv
his behalf) using the ATT with an appropriate eff
level.
A part of the TOE containing the non-executable d
generating advanced or qualified electronic (concre
signatures on behalf of the ID_Card holder as well
authentication; t
Extended Access
l
anism identified in [8] by which means the MRTD’s
ion systems
ric reference data, (ii) controls
a and (iii) protects
metric reference
stem by secure
Contro
Security mech
chip (i) verifies the authentication of the inspect
authorised to read the optional bio et
m
the access to the optional biometric reference dat
the confidentiality and integrity of the optional bio
data during their transmission to the inspection sy
messaging.
Extended Inspecti
System (EIS)
on
See Inspection system
Forgery
Fraudulent alteration of any part of the genuine document, e.g.
changes to the biographical data or portrait; see [8].
General
Authentication
Procedure
A specific order of authentication steps between an ID_Card and a
terminal as required by [11], sec. 3.4, namely (i) PACE, (ii) Terminal
Authentication (version 2), (iii) Passive Authentication and (iv) Chip
Authentication (version 2).
Global
Interoperability
The capability of inspection systems (either manual or automated) in
different States throughout the world to exchange data, to process
290
Existing of such an agreement may be technically reflected by means of issuing a CCVCA-F for the Public Key of the foreign CVCA
signed by the domestic CVCA.
291
‚activated’ means (i) generate and store in the eSign application one or more signature key pairs and (ii) optionally store there the
related certificates
8 Glossary and Acronyms
Security Target Lite STARCOS 3.5 ID GCC C1 Page 119 of 128
Version 2.5 14.12.2010
Term Definition
data received from systems in other States, and to utilise that
inspection operations in their respective States. Gl
int op
data in
obal
erability is a major objective of the standardised specifications
e readable data in all
er
for placement of both eye-readable and machin
MRTDs; see [8].
IC Dedicated
rdware by the IC
al functionality of
, for implementing
ivery procedures between different players. The usage of parts of
certain life phases.
Software
Software developed and injected into the chip ha
manufacturer. Such software might support speci
the IC hardware and be used, amongst other
del
the IC Dedicated Software might be restricted to
IC Emb
Softwar
edded
e
igned by the IC
ed Software is designed in the design life phase and
phase of the TOE.
Software embedded in an IC and not being
developer.
The IC Embedd
des
embedded into the IC in the manufacturing life
ID_Card
(electronic)
The contactless smart card integrated into the plastic, optical
lications: ePassport,
readable cover and providing the following app
eID and eSign (optionally)
ID_Card holder
om
.
The rightful/legitimated holder of the electronic ID Card for wh
the issuing authority personalised the ID Card
ID_Card Issuer
uthorit
ntity Card to the
(issuing a y)
Organisation authorised to issue an electronic Ide
ID_Card holder
ID_Card presen
ng the ID_Card to a terminal and claiming the
ter
identity of the ID_Card holder.
A person presenti
Identity Card
(physical and
in form of a
by the Identity Card
he Identity Card
electronic)
An optically and electronically readable document
paper/plastic cover and an integrated smart card. The Identity Card
is used in order to verify that identity claimed
presenter is commensurate with the identity of t
holder stored on/in the card.
Impostor
A person who applies for and obtains a documen
false name and identity, or a person who alters h
appearance to represent himself or herself as an
purpose of using that person’
t by assuming a
is or her physical
other person for the
].
s document; see [8
Improperly
documented pe
(a) an expired
ment or an invalid visa; (b) a counterfeit, forged or
’s travel document
quired; see [8].
rson altered travel document or visa; (c) someone else
or visa; or (d) no travel document or visa, if re
A person who travels, or attempts to travel w
travel cu
ith:
do
Initialisation Dat
r and injected into the
manufacturer. These
r instance, used for traceability and for IC identification
as IC_Card material (IC identification data).
a
Any data defined by the ID_Card manufacture
non-volatile memory by the Integrated Circuits
data are, fo
Inspection
The act of an authority examining an ID_Card presented to it by an
ID_Card presenter and verifying its authenticity as the ID_Card
holder. See also [8].
Inspection system
(EIS)
A technical system being used by an authority292
and operated by a
governmental organisation (i.e. an Official Domestic or Foreign
Document Verifier) and verifying the ID_Card presenter as the
ID_Card holder (for ePassport: by comparing the real biometrical
data of the ID_Card presenter with the stored biometrical data of
the ID_Card holder).
292
concretely, by a control officer
8 Glossary and Acronyms
Page 120 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Term Definition
The specification [11], sec. 3.2 (and C.4) knows o
inspection system, namely according to the resu f
authentication in the context of the Genera
Procedure. It means that Inspection System in t
nly one type of the
the terminal
l Authentication
he context of [11]
e Extended
e also par. 23 above.
lt o
the
(and of the current ST) is commensurate with th
Inspection System (EIS) as defined in [11]293
. Se
Integrated circuit ocessing and/or
ed circuit.
Electronic component(s) designed to perform pr
(IC) memory functions. The ID_Card’s chip is an integrat
Integrity
Ability to confirm the ID_Card and its data ele e
m
ro
nts stored upon
that created by the ID_Card Issuer.
have not been altered f m
Issuing
Organisation
ocument (e.g. the
Laissez-passer); see [8].
Organisation authorised to issue an official travel d
United Nations Organisation, issuer of the
Issuing State The country issuing the MRTD; see [8].
Logical Data
Structure (LDS)
red in the optional
pansion
The collection of groupings of Data Elements sto
capacity expansion technology [8]. The capacity ex
technology used is the MRTD’s chip.
Machine readable
travel document
, visa, official
ory visual (eye
and a separate mandatory data summary, intended
capable of being
ent issued by a State or Organisation which is used by
the holder for international travel (e.g. passport
document of identity) and which contains mandat
readable) ta
(MRTD)
Official docum
da
for global use, reflecting essential data elements
machine read; see [8].
Machine readable
zone (MRZ)
MRTD or MRP
back of the MRTD,
hine reading using
ved from the machine
containing mandatory and optional data for mac
OCR methods; see [8].
The MRZ-Password is a secret key that is deri
Fixed dimensional area located on the front of the
Data Page or, in the case of the TD1 he
, t
readable zone and may be used for both PACE and BAC.
Machine-verifiabl
eature
e (e.g. an iris pattern,
ent in a
e [8].
e
A unique physical personal identification featur
fingerprint or facial characteristics) stored on a travel docum
form that can be read and verified by machine; se
biometrics f
Malicious
equipment
ts
iable up to the
root CertA (CVCA for a terminal and CSCA for an
A technical device not possessing a valid, certified key pair for i
authentication; validity of its certificate is not verif
respective
ID_Card).
Manufacturer
he IC Manufacturer producing the integrated
d Manufacturer completing the IC to the
ID_Card. The Manufacturer is the default user of the TOE during the
manufacturing life phase294
. The TOE itself does not distinguish
between the IC Manufacturer and ID_Card M nufacturer using this
role Manufacturer.
The generic term for t
ar
circuit and the ID_C
a
Metadata of a CV
Certificate
Data within the certificate body (excepting Public Key) as described
in [11], sec. C.1.3.
The metadata of a CV certificate comprise the following elements:
-Certificate Profile Identifier,
-Certificate Authority Reference,
-Certificate Holder Reference,
293
please note that an Extended Inspection System also covers the General Inspection Systems (GIS) in the sense of [6]
294
cf. also par. 14 in sec. 1.2.3 above
8 Glossary and Acronyms
Security Target Lite STARCOS 3.5 ID GCC C1 Page 121 of 128
Version 2.5 14.12.2010
Term Definition
-Certificate Holder Authorisation Template,
Date,
-Certificate Effective
-Certificate Expiration Date,
-Certificate Extensions (optional).
PACE Terminal
(PCT)
tween the stored
terminal.
protocol and
ared password (CAN,
er Data
, table 1.2 and G.2.
A technical system verifying correspondence be
password and the related value presented to the
PCT im ments the terminal’s part of the PACE
ple
authenticates itself to the ID_Card using a sh
MRZ, eID-PIN, eID-PUK). The PCT is not allowed reading Us
(see sec. 4.2.2 in [11]). See [11], chap. 3.3, 4.2
Passive
tication
ct and (ii) comparing
hash values
ct. See [11], sec.
authen
Security mechanism implementing (i) verification of the digital
signature of the Card (Document) S rity Obje
the hash values of the read data fields with the
contained in the Card (Document) Security Obje
1.1.
ecu
Password
on
ent
(PACE)
d in [11], sec. 4.2.
icated Diffie-Hellman key
d-based
d and
rification, whether
are the same value of a password).
es a secure
enticity of data
nel are maintained.
Authenticated
Connecti
Establishm
A communication establishment protocol define
The PACE Protocol is a password authent
agreement protocol providing implicit passwor
authentication of the communication partners (e.g. smart car
the terminal connected): i.e. PACE provides a ve
the communication partners sh
Based on this authentication, PACE also provid
communication, whereby confidentiality and auth
transferred within this communication chan
Personal
Identification
Number (PIN)
ID_Card holder.
A short secret password being only known to the
PIN is a blocking password, see [11], sec. 3.3.
Personalisation
The process by which the individual-related data
biometric data, signature key pair(s) for the eSig
ID_Card holder are stored in and unambiguou
associated with the ID_Card.
(biographic and
n application) of the
sly, inseparably
Personalisation
Agent
Issuer to
_Card holder by some or all of the
for the biographic
ii) enrolling the biometric reference data of
ese data on the
onalisation) and storing
them in the ID_Card (electronic personalisation) for the ID_Card
holder as defined in [11], (iv) writing the document details data, (v)
nitial TSF data, (vi) signing the Card
Security Object defined in [8] (in the role of DS).
A Personalisation Agent acts, amongst other, as the Document
Signer (item (vi) of his tasks). Generating signature key pair(s) is not
in the scope of the tasks of this role.
the ID_Card holder296
, (iii) writing a subset of th
physical Identification Card (optical pers
An organ ion acting on behalf of the ID_Card
isat
personalise th D_Card for the ID
e I
following activities:
(i) establishing the identity of the ID_Card holder
data in the ID_Card295
, (
writing the i
PIN Unblock Key
(PUK)
A long secret password being only known to the ID_Card holder.
The PUK is a non-blocking password, see [11], sec. 3.3.
295
relevant for the ePassport, the eID and the eSign applications
296
relevant for the ePassport application
8 Glossary and Acronyms
Page 122 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
Term Definition
Pre-personalisatio
mory of the TOE by
nalised ID_Card
he life cycle phases
n and/or to secure shipment within or between t
manufacturing and card issuing.
Data
Any data that is injected into the non-volatile me
the Manufacturer for traceability of the non-perso
Pre-personalised
ip asymmetric Authentication Key Pair of the chip.
ID_Card’s ch
ID_Card’s chip equipped with a unique identifier and a unique
Receiving State
g for entry; see
The Country to which the ID_Card holder is applyin
[8].
Reference data
verifier to check
this identity in an
Data enrolled for a known identity and used by the
the verification data provided by an entity to prove
authentication attempt.
Remote terminal
ng the
e between them (Internet, a local RF-terminal)
ntication when a
d remote
data of the eID
A remote device directly communicating with the TOE and usi
technic frastructur
al in
merely as a message carrier. Only after Chip Authe
secure end-to-end connection between the TOE an
terminal is established, the TOE grants access to the
application, see [11], sec. 3.4.1.
Restricted
ation aims providing a temporary ID_Card
pseudo-anonymisation)
, 4.5 of [11]). The
Identification
Restricted Identific
identifier being specific for a terminal sector (
and supporting revocation features (sec. 2.3, 4.1.2
security status of ID_Card is not affected by Restricted Identification.
RF-terminal
A device being able to establish communica
according to ISO/IEC 14443
tion with an RF-chip
Rightful equipment verifiable up to the respective root CertA. A righ
(rightful terminal
rightful ID_Card)
air for its
validity of the related certificate is
tful terminal can be
al is CVCA and for
or either EIS or ATT or SGT.
A technical device possessing a valid, certified key p
authentication, whereb the
y
A terminal as well as an ID_Card can represent the rightful
equipment, whereby the root CertA for a termin
an ID_Card – CSCA.
Secondary image
ed elsewhere in the
[8].
A repeat i ge of the holder’s portrait reproduc
document by whatever means; e
ma
se
Secure messaging
combined mode
on
in Secure messaging using encryption and message authenticati
code according to ISO/IEC 7816-4
Service Provider
ing services which can
ses the rightful
An official or commercial organisation provid
be used by the ID_Card holder. Service Provider u
terminals managed by a DV.
Signature
al
ration of digital signatures. See also
uivalent – as a
termin
(SGT)
A technical system used for gene
par. 23 above and [11], chap. 3.2 and C.4. It is eq
general term – to SCA and HID as defined in [8].
Skimming
Imitation of a rightful terminal to read the ID_Card or parts of it via
the contactless communication channel of the TOE without
knowledge of the printed MRZ, CAN, eID-PIN or eID-PUK data.
Terminal
A technical system communicating with the TOE through the
contactless interface.
The role ‘Terminal’ is the default role for any terminal being
recognised by the TOE as neither PCT nor EIS nor ATT nor SGT
(‘Terminal’ is used by the ID_Card presenter).
Terminal
Authorisation Level
Intersection of the Certificate Holder Authorisations defined by the
Terminal Certificate, the Document Verifier Certificate and Country
8 Glossary and Acronyms
Security Target Lite STARCOS 3.5 ID GCC C1 Page 123 of 128
Version 2.5 14.12.2010
Term Definition
Verifying Certification Authority which shall be all valid for the
terminal by ID_Card
Current Date. It can additionally be restricted at
holder using CHAT.
TOE tracing dat rmation about the current and previous locations of
_Card holder)
a Technical info
the ID_Card gathered by inconspicuous (for the ID
recognising the ID_Card
Travel documen issued by a State or
which may be used by the rightful holder for
t A passport or other official document of identity
Organisa n
tio
international travel; see [8].
TSF data affect the operation of
Data created by and for the TOE that might
the TOE (CC part 1 [1]).
Unpersonalised
ID_Card
ised ID_Card
ID_Card’s chip.
ID_Card material prepared to produce a personal
taining an initialised and pre-personalised
con
User Data in the context of the
1] and (i) being allowed
nticated terminal (in the
ed to be used
f [11], sec. 3.2)
Restricted
c. 4.5 represents just a
ded for this
d here as ‘user data’)
ly by the authenticated
hin the eSign
signature key of the
data’).
er data: Data created
e user that does not affect the operation of the TSF
(CC part 1 [1]). Information stored in TOE resources that can be
operated upon by users in accordance with the SFRs and upon
which the TSF places no special meaning (CC part 2 [2]).
All data (being not authentication a) stored
applications of the ID_Card as defined in [1
to be read out or written solely by an authe
sense of [11], sec. 3.2) respectively (ii) being allow
solely by an authenticated terminal (in the sense o
(the private Restricted Identification key; since the
Identification according to [11], se
dat
functionality of the ID_Card, the key material nee
functionality and stored in the TOE is considere
respectively (iii) being allowed to be used sole
ID_Card holder (the private signatur key wit
e
application; from this point of view, the private
ID_Card holder is also considered as ‘user
CC give the following generic definitions for us
by and for th
Verification data Data provided by an entity in an authentication attempt to prove
their identity to the verifier. The verifier checks whether the
verification data match the reference data known for the claimed
identity.
8 Glossary and Acronyms
Page 124 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
8.2 Acronyms
Acronym Term
ATT Terminal as defined in [11], sec. 3.2
Authentication
BAC Control
Basic Access
BIS on System
Basic Inspecti
CA Chip Authentication
CAN Card Access Number
CC Common Criteria
CertA Certification Authority (the author dispensed with the usual
abbreviation ‘CA’ in order to avoid a collision with ‘Chip
Authentication’)
CGA Certificate generation application, please refer to [7]. In the current
esented by ATT for the eSign application.
context, it is repr
CHAT Certificate Holder Authorization Template
DTBS d, please refer to [7]
Data to be signe
DTBS/R er to [7]
Data to be signed or its unique representation, please ref
EAC cess Control
Extended Ac
EIS Extended Inspection System (equivalent to the Inspection Systems as
in [11], sec. 3.2)
defined
GAP ion Procedure (see [11], sec. 3.4)
General Authenticat
HID evice, please refer to [7]. It is equivalent to SGT in
Human Interface D
the current context.
MRZ Machine readable zone
n.a. Not applicable
OSP onal security policy
Organisati
PACE thenticated Connection Establishment
Password Au
PCD Coupling Device
Proximity
PCT PACE-authenticated terminal
PICC Proximity Integrated Circuit Chip
PIN Personal Identification Number
PP Protection Profile
PUK PIN Unblock Key
RAD ease refer to [7]
Reference Authentication Data, pl
RF Radio Frequency
SAR Security assurance requirements
SCA Signature creation application, please refer to [7]. It is equivalent to
SGT in the current context.
SCD Signature Creation Data, please refer to [7]; the term ‘private signature
key within the eSign application’ is synonym within the current ST.
SFR Security functional requirement
SGT Signature Terminal as defined in [11], sec. 3.2
SVD Signature Verification Data, please refer to [7]
8 Glossary and Acronyms
Security Target Lite STARCOS 3.5 ID GCC C1 Page 125 of 128
Version 2.5 14.12.2010
Acronym Term
TA uthentication
Terminal A
TOE tion
Target of Evalua
TSF TOE security functionality
TSP TOE Security Policy (defined by the current document)
VAD Verification Authentication Data, please refer to [7]
9 Bibliography
Page 126 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5
9 Bibliography
9.1 C m
[1 valuation, Part 1:
n 3.1, Revision 3,
2009
o mon Criteria
] Common Criteria for Information Technology Security E
Introduction and General Model; CCMB-2009-07-001, Versio
July
[2 ion, Part 2:
] Common Criteria for Information Technology Security Evaluat
Security Functional Components; CCMB-2009-07-002, Version 3.1, Revision 3,
July 2009
[3 luation, Part 3:
rements; CCMB-2009-07-003, Version 3.1, Revision 3,
] Common Criteria for Information Technology Security Eva
Security Assurance Requi
July 2009
[4 ethodology for Information Technology Security Evaluation,
Evaluation Methodology; CCMB-2009-07-004, Version 3.1, Revision 3, July
2009
] Common M
[4a] Supporting Document, Mandatory Technical Document, Composite product
evaluation for Smart Cards and similar devices, September 2007, Version 1.0,
CCDB-007-09-001.
9.2 Prot
[5 ocument with
AO Application", Basic Access Control, BSI-PP-0055, version 1.10, 25th
ection Profiles
] Common Criteria Protection Profile Machine Readable Travel D
„IC
March 2009
[6 avel Document with
, version 1.10, 25th
] Common Criteria Protection Profile Machine Readable Tr
„ICAO Application", Extended Access Control, BSI-PP-0056
March 2009
[7 P SSCD type 3
009-12, BSI-CC-
] Protection Profile – Secure Signature Creation Device – Core P
(key generation on card), prEN 14169-1:2009, version 1.01, 2
PP-0059
[7 rsion 1.03,
15.12.2009, BSI-CC-PP-0061
a] Protection Profile –Electronic Identity Card (ID_Card PP), ve
[8] ICAO Doc 9303-1, Specifications for electronically enabled passports with
biometric identification capabilities. In Machine Readable Travel Documents –
Part 1: Machine Readable Passport, volume 2, ICAO, 6th edition, 2006
[9] ICAO Doc 9303-3, Specifications for electronically enabled official travel
documents with biometric identification capabilities. In Machine Readable Travel
Documents – Part 3: Machine Readable Official Travel Documents, volume 2,
ICAO, 3rd edition, 2008.
[9a] Protection Profile –Security IC Platform, version 1.0, 15.06.2007, BSI-CC-PP-
0035
9 Bibliography
Security Target Lite STARCOS 3.5 ID GCC C1 Page 127 of 128
Version 2.5 14.12.2010
9.3 Technical Guidelines and Directives
isms for Machine
(EAC), TR-03110, version
ormationstechnik (BSI)
[10] Technical Guideline TR-03110 Advanced Security Mechan
Readable Travel Documents – Extended Access Control
1.11, 21.02.2008, Bundesamt für Sicherheit in der Inf
[11] Technical Guideline TR-03110 Advanced Security Mechan
Readable Travel Documents – Extended Access Control (EAC),
isms for Machine
Password
ted Identification
Sicherheit in der
chnik (BSI)
Authenticated Connection Establishment (PACE) and Restric
(RI), TR-03110, Version 2.04, ##.##.2010, Bundesamt für
Informationste
[12] Technische Richtlinie TR-03116-2, eCard-Projekte der Bundesregierung, Teil 2 –
Sicherheit in der
Hoheitliche Ausweisdokumente, Stand 2010, Bundesamt für
Informationstechnik (BSI)
[12a] Anwendungshinweise und Interpretationen zum Schema
Bundesamt für Sicherheit in der Informationstechnik, Ver
(AIS), AIS 20;
sion 1.0, 2.12.1999
[12b] Anwendungshinweise und Interpretationen zum Schema (AIS), AIS 31;
1, 25.09.2001
Bundesamt für Sicherheit in der Informationstechnik, Version
[13] Technical Guideline TR-03111 Elliptic Curve Crypto
1.11, 17.04.2009, Bundesamt für Sic
graphy, TR-03111, version
herheit in der Informationstechnik (BSI)
[14] DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE
of 13 December 1999 on a Community framework
Common Criteria Protection Profile Version 1.01, 1st Octo
Ele
COUNCIL
for electronic signatures
ber 2009
ctronic Identity Card (ID_Card PP) Bundesamt für Sicherheit in der
Informationstechnik page 107 of 107 Cryptography
[15] Übersicht über geeignete Algorithmen: Bekanntmach
Signatur nach dem Signaturgesetz und der Signaturverord
Bundesnetzagentur für Elektrizität, Gas, Te
ung zur Elektronischen
nung,
lekommunikation, Post und
9 im Bundesanzeiger Nr.
Eisenbahn, 17.11.2008, Veröffentlicht am 27.01.200
13, S. 346
[15a] EUROPEAN STANDARD, EN 14890-1:2008, Application Interface for smart cards
services
used as secure signature creation devices – Part 1: Basic
[16] Federal Information Processing Standards Publication 197, A
ENCRYPTION STANDARD (AES), U.S. D
DVANCED
EPARTMENT OF COMMERCE/National
Institute of Standards and Technology, November 26, 2001
[17] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA Laboratories
Technical Note, Version 1.4, Revised November 1, 1993
[18] Recommendation for Block Cipher Modes of Operation: The CMAC Mode for
National Institute of
Authentication, NIST Special Publication 800-38B,
Standards and Technology, May 2005
[19] Secure hash standard (and Change Notice to include SHA-224), FIPS PUB 180-2,
National Institute of Standards and Technology, 2002
9.4 Other Sources
[20] ISO 14443, Identification cards – Contactless integrated circuit(s) cards –
Proximity cards, 2000
[21] Security Target Lite, NXP Secure SmartCard Controllers
P5Cx128V0A/P5Cx145V0A, MSA, Rev1.4, 07.01.2010
9 Bibliography
Page 128 of 128 Security Target Lite STARCOS 3.5 ID GCC C1
14.12.2010 Version 2.5