Author: Giesecke & Devrient GmbH
Document status: Final
Giesecke & Devrient GmbH
Prinzregentenstr. 159
Postfach 80 07 29
81607 München
Security Target Lite
STARCOS 3.6 COSGKV C1
Page 2 of 134 Security Target Lite STARCOS 3.6 COSGKV C1, Version 1.0.1/10.12.15
© Copyright 2015
Giesecke & Devrient GmbH
Prinzregentenstraße 159
Postfach 80 07 29
D-81607 München
This document as well as the information or material contained is copyrighted. Any use not
explicitly permitted by copyright law requires prior consent of Giesecke & Devrient GmbH. This
applies to any 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.
Security Target Lite STARCOS 3.6 COSGKV C1, Version 1.0.1/10.12.15 Page 3 of 134
Contents
1 ST Introduction 6
1.1 ST reference 6
1.2 TOE Overview 6
1.2.1 TOE description 7
1.2.2 TOE life cycle 8
1.2.3 TOE definition and operational usage 9
1.2.4 TOE major security features for operational use 10
1.2.5 TOE type 10
1.2.6 Non-TOE hardware/software/firmware 11
2 Conformance Claims 13
2.1 CC Conformance Claim 13
2.2 PP Claim 13
2.3 Package Claim 13
2.4 Conformance Claim Rationale 13
2.5 Conformance statement 15
3 Security Problem Definition 16
3.1 Assets and External Entities 16
3.2 Threats 17
3.3 Organisational Security Policies 19
3.4 Assumptions 20
4 Security Objectives 22
4.1 Security Objectives for the TOE 22
4.2 Security Objectives for Operational Environment 24
4.3 Security Objective Rationale 25
5 Extended Components Definition 30
5.1 Definition of the Family FCS_RNG Generation of Random Numbers 30
5.2 Definition of the Family FIA_API 31
5.3 Definition of the Family FPT_EMS TOE Emanation 31
5.4 Definition of the Family FPT_ITE TSF image export 32
6 Security Requirements 34
6.1 Security Functional Requirements for the TOE 34
6.1.1 Overview 34
6.1.2 Users, subjects and objects 36
6.1.3 Security Functional Requirements for the TOE taken over from BSI-PP-0035-2007 50
6.1.4 General Protection of User data and TSF data 52
Page 4 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
6.1.5 Authentication 56
6.1.6 Access Control 64
6.1.7 Cryptographic Functions 87
6.1.8 Protection of communication 97
6.2 Security Assurance Requirements for the TOE 98
6.2.1 Refinements of the TOE Assurance Requirements 99
6.2.2 Refinements to ADV_ARC.1 Security architecture description 100
6.2.3 Refinements to ADV_FSP.4 Complete functional specification 101
6.2.4 Refinement to ADV_IMP.1 101
6.2.5 Refinements to AGD_OPE.1 Operational user guidance 101
6.2.6 Refinements to ATE_FUN.1 Functional tests 102
6.2.7 Refinements to ATE_IND.2 Independent testing – sample 102
6.3 Security Requirements Rationale 102
6.3.1 Security Functional Requirements Rationale 102
6.3.2 Rationale for SFR’s Dependencies 109
6.3.3 Security Assurance Requirements Rationale 114
7 Statement of Compatibility 116
7.1 Classification of the Platform TSFs 116
7.2 Matching statement 116
7.2.1 TOE Security Environment 117
7.2.2 Security objectives 118
7.2.3 Security requirements 119
7.3 Analysis 121
8 TOE summary specification 122
8.1 TOE Security Functions 122
8.1.1 SF_AccessControl 122
8.1.2 SF_Authentication 123
8.1.3 SF_AssetProtection 124
8.1.4 SF_TSFProtection 124
8.1.5 SF_KeyManagement 124
8.1.6 SF_CryptographicFunctions 125
8.2 Assurance Measure 125
8.3 Fulfilment of the SFRs 126
8.3.1 Correspondence of SRF and TOE mechanisms 128
9 Glossary and Acronyms 129
10 Bibliography 131
Security Target Lite STARCOS 3.6 COSGKV C1 Page 5 of 134
List of Tables
Table 1: Mapping between options and packages. ................................................................................11
Table 2: Data objects to be protected by the TOE as primary assets.....................................................16
Table 3: External entities.......................................................................................................................17
Table 4: Overview of threats defined in BSI-CC-PP-0035 [11] and taken over into this ST................17
Table 5: Overview of OSP defined in BSI-CC-PP-0035-2007 [11] and taken over into this ST..........19
Table 6: Overview of assumptions defined in BSI-CC-PP-0035-2007 [11] and implemented by the
TOE.................................................................................................................................................21
Table 7: Overview of Security Objectives for the TOE defined in BSI-CC-PP-0035 [11] and taken
over into this ST..............................................................................................................................22
Table 8: Overview of Security Objectives for the Operational Environment defined in BSI-CC-PP-
0035-2007 [11] and taken over into this ST....................................................................................24
Table 9: Security Objective Rationale related to the IC platform..........................................................26
Table 10: Security Objective Rationale for the COS part of the TOE...................................................28
Table 11: Security functional groups vs. SFRs related to the IC platform ............................................35
Table 12: Security functional groups vs. SFRs......................................................................................35
Table 13: TSF Data defined for the IC part...........................................................................................35
Table 14: Authentication reference data of the human user and security attributes..............................38
Table 15: Authentication reference data of the devices and security attributes.....................................39
Table 16: Authentication verification data of the TSF and security attributes ......................................40
Table 17: Security attributes of a subject...............................................................................................42
Table 18: Subjects, objects, operations and security attributes. The references refer to [21]................45
Table 19: Mapping between commands described in COS specification [21] and the SFR .................49
Table 20: Mapping between SFR names in this ST and the SFR names in the BSI-CC-PP-0035-2007
[11]..................................................................................................................................................50
Table 21: Assurance components ..........................................................................................................99
Table 22: Refined TOE assurance requirements .................................................................................100
Table 23: Coverage of Security Objectives for the TOE IC part by SFR............................................103
Table 24: Mapping between security objectives for the TOE and SFR...............................................105
Table 25: Dependencies of the SFR ....................................................................................................114
Table 26: SAR Dependencies..............................................................................................................115
Table 27 Classification of Platform-TSFs ...........................................................................................116
Table 28 Mapping of threats................................................................................................................118
Table 29 Mapping of assumptions.......................................................................................................118
Table 30 Mapping of objectives ..........................................................................................................119
Table 31 References of Assurance measures.......................................................................................126
Table 32 Mapping of SFRs to mechanisms of TOE............................................................................128
1 ST Introduction
Security Target Lite STARCOS 3.6 COSGKV C1 Page 6 of 134
1 ST Introduction
1.1 ST reference
Title: Security Target Lite ‘STARCOS 3.6 COSGKV C1’
Origin: Giesecke & Devrient GmbH
Editor(s): Giesecke & Devrient GmbH
CC Version: 3.1 (Revision 4)
Assurance Level: The assurance level for this Security Target is EAL4 augmented with
ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5 (refer to section 6.3.3 for
more detail)
General Status: Final
Version Number: Version 1.0.1/10.12.15
Keywords: Gesundheitskarte, card operating system
PP: This ST is based on BSI-CC-PP-0082-V2 version 1.9
TOE: STARCOS 3.6 COSGKV C1
TOE documentation:
Guidance Documentation STARCOS 3.6 COS – Main Document, v1.7
Guidance Documentation for the Initialisation Phase STARCOS 3.6 COS,
v2.11
Guidance Documentation for the Personalisation Phase STARCOS 3.6
COS, v2.0
Guidance Documentation for the Usage Phase STARCOS 3.6 COS, v2.5
STARCOS 3.6 Functional Specification - Part 1: Interface Specification,
v1.19
Guidance Documentation for the Wrapper STARCOS 3.6 COS C1/2,
v1.4
Starcos 3.6 Internal Design Specification, Version 1.3
HW-Part of TOE: IFX M7892 B11. This TOE was evaluated against Common Criteria
Version 3.1.
1.2 TOE Overview
The aim of this document is to describe the Security Target for STARCOS 3.6 COSGKV C1. In the
following chapters STARCOS 3.6 COSGKV C1 stands for the Target of Evaluation (TOE).
STARCOS 3.6 COSGKV C1 is a smart card and is intended to be used as a card operating system
platform in accordance with the [21], so the TOE provides a platform for applications in combination
with the underlying hardware (the TOE evalution is carried out as a ‘Composite Evaluation’). The
Security Target “STARCOS 3.6 COSGKV C1” is strictly conformant to the Protection Profile BSI-
CC-PP-0082-V2.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 7 of 134
STARCOS 3.6 COSGKV C1 comprises:
• the STARCOS 3.6 Health operating system,
• the hardware platform IFX M7892 B11 (certificate BSI-DSZ-CC-0782-V2-2015) with the following configurations:
o Flash: 404 kByte
o RAM: 8 kByte
o Sym.CoPr for DES/AES (SCP): Accessible
o Asym.CoPr for RSA/ECC (Crypto2304T): Accessible
o Interfaces: ISO/IEC 7816
1.2.1 TOE description
The TOE comprises:
 IC embedded software, the card operating system (COS)
 The associated guidance document
 The underlying IC
 The wrapper tool
The TOE does not include object systems (i.e. applications eGK, HPC, SMC)
The TOE provides the following features:
 ISO 7816 commands and file system
 Secure Messaging
 Cryptographic algortithms and protocols
 Contactbased communication
The TOE implements all COS [21] commands from the mandatory package with the base functionality
with the mandatory options, parameters and variants as well as following optional commands:
 CREATE
 PSO HASH
The command CREATE can be used to create a DF or an EF in the object system. The commands
CREATE and PSO HASH are part of the TSF. The TOE implements additional commands beyond
COS [21] for the TOE’s initialization, personalization and usage phase. The commands are described
with options and parameters in the STARCOS 3.6 Functional Specification - Part 1: Interface
Specification and in the Guidance Documentations. All commands belong to the TSF.
The TOE implements following crypto algorithms:
 Random generators: DRG.4 (HW random generator for seeding: PTG.2)
 Hash: SHA-1, SHA-224, SHA-384, SHA-256, SHA-512
 AES: 128 bit, 192 bit, 256 bit (with CBC mode)
1 ST Introduction
Page 8 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
 3TDES: 192 bit (with CBC mode)
 CMAC-AES: 128 bit, 192 bit, 256 bit
 RSA: 2048 bit, 3072 bit
 ECDSA-256 with curve brainpoolP256r1
 ECDSA-256 with curve ansix9p256r1
 ECDSA-384 with curve brainpoolP384r1
 ECDSA-384 with curve ansix9p384r1
 ECDSA-512 with curve brainpoolP512r1
The TOE implements following protocols:
 Signature calculation and verification according to RSA, ISO9796-2, DS1
 Signature calculation according to RSA, SSA, PKCS1-V1.5
 Signature calculation according to RSA, SSA, PSS
 Signature calculation according to RSA, ISO9796-2, DS2
 Signature calculation and verification according to ECDSA
The TOE implements following packages:
None.
1.2.2 TOE life cycle
The TOE life cycle is part of the product life cycle which goes from product development to its usage
by the final user. In detail TOE life cycle consist of development phase, initialisation phase,
personalisation phase and usage phase. The development phase and initialisation phase is part of the
evaluation. The personalisation phase and usage phase is not part of the evaluation.
Development phase
The TOE is developed in this phase.
This includes the COS design, implementation, testing and documentation. The development occurs in
a controlled environment that avoids disclosure of source code, data and any critical documentation
and that guarantees the integrity of these elements. The software development environment is included
in the evaluation of the TOE.
Initialisation phase
The initialisation phase covers the loading of the TOE's COS implementation and the loading of the
object system.
The COS is integrated in a flash image which is loaded via the IC's flash loader by G&D. Hereby, it is
possible to load in addition the object system. In this case the object system is part of the flash image.
After flashing the TOE the flash loader is permanently blocked. This is the point when the TOE is
delivered either for further initialization or for personalization. The environment for preparing flash
images, initialization tables, generating cryptographic keys and conducting the flashing of the TOE is
included in the evaluation of the TOE. An object system may also be loaded after flashing the COS by
loading an initialisation table which is generated by G&D. This can be done if the object system was
not loaded during the COS loading or if the object system was deleted after loading. This means, that
the object system is not always part of the delivered product. But a delivered product may additionally
Security Target Lite STARCOS 3.6 COSGKV C1 Page 9 of 134
include the object system beside the TOE. The loading of the object system via intialisation table can
be conducted either by G&D or a 3rd
party initialiser. G&D is able to include patches for the COS in
the initialization table. Only authentic initialization tables can be loaded on the TOE.
The TOE developer (G&D) provides the TOE to the personaliser either as completed card
(contactbased only) or as module. The physical scope of the TOE is only the module. This means that
the card body is not in the scope of the TOE even though this component is part of the product if
completed cards are delivered. The TOE is already initialized with an object system before providing
the product to the personaliser.
Personalisation phase
The card is personalised in this phase.
A personaliser or the TOE developer himself personalizes the initialized cards.
The product shall be tested again and all critical material including personalization data, test suites and
documentation shall be protected from disclosure and modification.
The writing of personalization data require a prior authentication with keys dedicated for these
operations. These keys are provided by G&D. A verification of the COS consistency can be performed
by the FINGERPRINT command.
Usage phase
The card is used in this phase.
Depending on the defined access rules set in the object system that is initially installed and initialised
on top of the TOE parts of the object system can also be loaded in this phase by authorized enitities.
This can be achieved with the command LOAD APPLICATION which requires an authentication. A
verification of the COS consistency after object system loading can be performed by the
FINGERPRINT command.
The command LOAD APPLICATION is implemented according to the G2 COS-specification in its
base variant.
By the command LOAD APPLICATION new applications (folders with sub-structures as further
folders, data files, key and PIN objects) can be installed. Is it not possible to install key and PIN
objects for their own (i.e. without installing a new folder where these new objects are settled).
1.2.3 TOE definition and operational usage
1 The Target of Evaluation (TOE) STARCOS 3.6 COSGKV C1 addressed by the current security
target is a smart card platform implementing the Card Operating System (COS) according
[21]without any object system. The TOE comprises
i) the Security platform IC, i.e. the circuitry of the chip incl. the configuration data and
initialisation data related to the security functionality of the chip and IC Dedicated Software1
with the configuration data and initialisation data related to IC Dedicated Software (the
integrated circuit, IC),
ii) the IC Embedded Software (operating system)2,
1 usually preloaded (and often security certified) by the Chip Manufacturer
2 usually – together with IC – completely implementing executable functions
1 ST Introduction
Page 10 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
iii) the associated guidance documentation including the wrapper for interpretation of exported
TSF data.
2 The TOE includes all excutable code running on the Security platform IC, i. e. IC Dedicated
Support Software and the Card Operating System.
3 The TOE does not support contactless communication.
4 The TOE does not include the object system, i. e. the application specific structures like the
Master File (MF), the Applications, the Application Dedicated Files (ADF), the Dedicated Files
(DF3), Elementary Files (EF) and internal security objects4 including TSF data. The TOE and the
application specific object system build an initialized smart card product like an electronic Health
Card.
5 The Guidance Documentations describe further developer specific commands and functionality
for the TOE's initialisation, personalisation and usage phase implemented in the TOE.
1.2.4 TOE major security features for operational use
6 The TOE STARCOS 3.6 COSGKV C1 as a smart card provides the following main security
functionality:
– authentication of human user and external devices,
– storage of and access control on user data,
– key management and cryptographic functions,
– management of TSF data including life cycle support,
– export of non-confidential TSF data of the object systems if implemented.
1.2.5 TOE type
7 The TOE type is smart card without the application named as a whole ‘Card Operating System
Card’.
8 The export of non-confidential TSF data of the object systems supports verification of correct
implementation of the object system of the smart card during manufacturing and test. The
exported TSF data include all security attributes of the object system as a whole and of all objects
but excludes any confidential authentication data. The wrapper provides communication
interfaces between the COS and the verification tool (cf. [27]). The verification tool sends
commands for the COS through the wrapper. The COS exports the TSF data in a vendor specific
format but the wrapper encodes the data into the standardized format for the export to the
verification tool. The verification tool compares the response of the smart card with the object
system definition. Details of the interface are described in the BSI Technical Guidance TR-03143
„eHealth G2-COS Konsistenz-Prüftool“.
3 The abbreviation DF is commonly used for dedicated files, application and application dedicated files, which
are folders with different methods of identification, cf. [21], sec. 8.1.1 and 8.3.1.
4 containing passwords, private keys etc.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 11 of 134
9 The typical life cycle phases for the current TOE type are IC and Smartcard embedded software
development, manufacturing5, smartcard product finishing6, smartcard personalisation and,
finally, smartcard end-usage as defined in [10]. The TOE will be delivered with completely
installed COS. After completion the bootloader is deactived. This means the COS cannot be
deleted or modified after these processes.
10 Operational use of the TOE is explicitly in the focus of current ST. Some single properties of the
manufacturing and the card issuing life cycle phases being significant for the security of the TOE
in its operational phase are also considered by the current ST. A security evaluation / certification
for this ST will have to involve all life cycle phases into consideration to the extent as required by
the assurance package chosen here for the TOE (see chap. 2.3 ‘Package Claim’ below).
1.2.6 Non-TOE hardware/software/firmware
11 In order to be powered up and to communicate with the ‘external world’ the TOE needs a
terminal (card reader) with contact.
12 The specification [21] defines the options “crypto box”, “contactless”, “PACE for Proximity
Coupling Device”, “logical channel”, and “USB” which the TOE may implement. The PP BSI-
CC-PP-0082-V2 [50] takes account of these options with the following packages:
Option in
[21]
Package Remark
Option_Kr
yptobox
crypto box Defines additional cryptographic mechanisms.
Option_kon
taktlose_Sc
hnittstelle
contactless Defines additional SFR for contactless interfaces of
the smartcard, i.e. PICC part of PACE.
Option_PA
CE_PCD
PACE for Proximity
Coupling Device
Defines additional SFR for support of contactless
interfaces of the terminals, i.e. PCD part of PACE.
Option_log
ische_Kanä
le
logical channel Defines additional SFR for the support of logical
channels.
Option_US
B_Schnittst
elle
- Defines additional communication support on the
lower layers. This option does not contain any
security related details and is therefore only listed
for the sake of completeness.
Table 1: Mapping between options and packages.
13 The Common Criteria for IT Security Evaluation, Version 3.1, Revision 4, defines a package as a
set of SFR or SAR. This approach does not necessarily fit for description of extended TSF due to
extended functionality of the TOE by means of packages. Therefore it was decided to provide an
extension of the Security Problem Definition, the Security Objectives, and the Security
Requirements as well as for the corresponding rationales for each defined package.
14 The ST integrates no packages.
5 IC manufacturing, packaging and testing
6 including installation of the object system
1 ST Introduction
Page 12 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
15 Application note 1 (ST writer): This ST describes in the chapter Conformance Claim, section
Package claim which package was chosen and in section Conformance Rationale how these
package are integrated in the ST.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 13 of 134
2 Conformance Claims
2.1 CC Conformance Claim
16 This security target claims conformance to
Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
General Model; CCMB-2012-09-001, Version 3.1, Revision 4, September 2012 [1]
Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional
Components; CCMB-2012-09-002, Version 3.1, Revision 4, September 2012 [2]
Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Requirements; CCMB-2012-09-003, Version 3.1, Revision 4, September 2012 [3]
as follows
- Part 2 extended,
- Part 3 conformant.
17 The
Common Methodology for Information Technology Security Evaluation, Evaluation
Methodology; CCMB-2012-09-004, Version 3.1, Revision 4, September 2012, [4]
has to be taken into account.
2.2 PP Claim
18 This ST claims strict conformance to protection profile BSI-CC-PP-0082-V2 [50] which claims
strict conformance to protection profile to BSI-CC-PP-0035-2007 [11]. Therefore this ST claims
also strict conformance to protection profile to BSI-CC-PP-0035-2007 [11].
2.3 Package Claim
19 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]. This ST implements none of the optional packages.
2.4 Conformance Claim Rationale
20 This ST claims strict conformance to the BSI-CC-PP-0082-V2 [50] and BSI-CC-PP-0035-2007
[11].
21 This security target is conformant to the claimed BSI-CC-PP-0082-V2 [50]. All Threats,
Assumptions, OSP and security objectives from the mandatory part of the PP (covering the G2-
COS specification's package with the base functionality) for TOE and OE are directly overtaken
from BSI-CC-PP-0082-V2. The same applies for the SFRs. This ST does not include additional
augmentations and refinements. The TOE type is a Card Operating System (COS) according to
[21] which is consistent with the TOE type of the claimed PP.
2 Conformance Claims
Page 14 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
22 From the Security Problem Definition (see section 3: “Security Problem Definition” [50] or [11])
of BSI-CC-PP-0082-V2 and BSI-CC-PP-0035-2007 the threats (see section 3.2 “Threats” [50] or
[11]) and the Organisational Security Policies (see section 3.3 “Organisational Security Policies”
[50] or [11]) are taken over into this Security Target. Namely the following threats are taken over:
T.Leak-Inherent, T.Phys-Probing, T.Malfunction, T.Phys-Manipulation, T.Leak-Forced,
T.Abuse-Func, T.RND. The OSP P.Process-TOE is also taken over from BSI-CC-PP-0082-V2
and BSI-CC-PP-0035-2007. See section 3.2 and 3.3 for more details.
23 The assumptions A.Process-Sec-IC, A.Plat-Appl and A.Resp-Appl defined in the BSI-CC-PP-
0035-2007 [11] address the operational environment of the Security IC, i.e. the COS part of the
current TOE and the operational environment of the current TOE. The aspects of these
assumptions are relevant for the COS part of the current TOE, address the development process
of the COS and are evaluated according to composite evaluation approach [8]. Therefore these
assumptions are now refined in order to address the assumptions about the operational
environment of the current TOE (cf. chapter 3.4 for details).
24 The Security Objectives for the Security IC as defined in the BSI-CC-PP-0035-2007 O.Leak-
Inherent, O.Phy-Probing, O.Malfunction, O.Phys-Manipulation, O.Leak-Forced, O.Abuse-Func,
O.Identification, O.RND are included as security objectives for the current TOE. Security
Objectives for the Environment OE.Resp-Appl defined in the BSI-CC-PP-0035 is split into the
security objective O_Resp_Appl for the COS part of the TOE and OE.Resp-ObjS for the object
system in the operational environment of the TOE. The security objective for the environment
OE.Plat-Appl defined in the BSI-CC-PP-0035-2007 is ensured by the COS part of the TOE and
verified in the composite evaluation process. It results in a similar security objective for the object
system in the operational environment of the TOE OE.Plat-COS. OE.Process-Sec-IC defined in
the BSI-CC-PP-0035-2007 is completely ensured by the assurance class ALC of the TOE up to
Phase 5 and addressed by OE.Process-Card. See chapter 4 for more details.
25 All Security Functional Requirements with existing refinements are taken over from the BSI-CC-
PP-0035-2007 into the BSI-CC-PP-0082-V2 and this ST by iterations indicated by “/SICP”.
Namely this are the following SFR: FRU_FLT.2/SICP, FPT_FLS.1/SICP, FMT_LIM.1/SICP,
FMT_LIM.2/SICP, FAU_SAS.1/SICP, FPT_PHP.3/SICP, FDP_ITT.1/SICP, FPT_ITT.1/SICP,
FDP_IFC.1/SICP, FCS_RNG.1/SCIP. See section 6.1 for more details.
26 The assurance package claim EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and
AVA_VAN.5. For rationale of the augmantations see section 6.3.3.
27 The refinements of the Security Assurance Requirements made in BSI-CC-PP-0082-V2 and BSI-
CC-PP-0035-2007 are taken over in this Security Target and must be applied to the IC Embedded
Software (operating system) resp. Security platform IC.
28 As all important parts of the BSI-CC-PP-0082-V2 and BSI-CC-PP-0035-2007 are referred in a
way that these are part of this Security Target the rationales still hold. Please refer sections 4.3
and 6.3 for further details.
29 This ST integrates none of the optional packages. Therefore the corresponding Security Problem
Definition, Security Objectives, Security Functional Requirements defined in BSI-CC-PP-0082-
V2 are not taken over in this Security Target.
30 Therefore the strict conformance with the BSI-CC-PP-0082-V2 [50] and BSI-CC-PP-0035-
2007 [11] is fulfilled by this Security Target.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 15 of 134
2.5 Conformance statement
31 This ST claims conformance to PP BSI-CC-PP-0082-V2 and BSI-CC-PP-0035-2007 [11].
3 Security Problem Definition
Page 16 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
3 Security Problem Definition
3.1 Assets and External Entities
32 As defined in section 1.2.3 the TOE is a smart card platform implementing the Card Operating
System (COS) according [21]without any object system. In sense of the BSI-CC-PP-0082-V2
[50] and BSI-CC-PP-0035-2007 [11] the COS is User Data and Security IC Embedded Software.
33 In section 3.1 “Description of Assets” in the BSI-CC-PP-0035-2007 a high level description (in
sense of this ST) of the assets (related to standard functionality) is given. Please refer there for a
long description. Namely these assets are
 the User Data,
 the Security IC Embedded Software, stored and in operation,
 the security services provided by the TOE for the Security IC Embedded Software, and
 the random numbers produced by the IC platform.
34 In section 3.1 “Assets and External Entities” in the BSI-CC-PP-0082-V2 these assets and the
protection requirements of these assets are refined because
 the User Data defined in the BSI-CC-PP-0035-2007 are User data or TSF Data in the context of
the BSI-CC-PP-0082-V2,
 Security IC Embedded Software is part of the current TOE,
 the security services provided by the TOE for the Security IC Embedded Software are part of
the current TSF and
 the random numbers produced by the IC platform are internally used by the TSF.
35 The primary assets are User Data to be protected by the COS as long as they are in scope of the
TOE and the security services provided by the TOE.
Asset Definition
User data in EF Data for the user stored in elementary files of the file hierarchy.
Secret keys Symmetric cryptographic key generated as result of mutual authentication
and used for encryption and decryption of user data.
Private keys Confidential asymmetric cryptographic key of the user used for
decryption and computation of digital signature.
Public keys Integrity protected public asymmetric cryptographic key of the user used
for encryption and verification of digital signatures and permanently
stored on the TOE or provided to the TOE as parameter of the command.
Table 2: Data objects to be protected by the TOE as primary assets
36 Note: elementary files (EF) may be stored in the MF, any DF, or Application and Application
Dedicated File. The place of an EF in the file hierarchy defines features of the User Data stored in
the EF. User data does not affect the operation of the TSF (cf. CC part 1, para. 100).
Cryptographic keys used by the TSF to verify authentication attempts of external entities (i.e.
authentication reference data) including the verification of Card Verifiable Certificates (CVC) or
Security Target Lite STARCOS 3.6 COSGKV C1 Page 17 of 134
authenticate itself to external entities by generation of authentication verification data in a
cryptographic protocol are TSF data (cf. Tables 13, 14 and 17)
37 This protection profile considers the following external entities:
External entity Definition
World Unauthenticated user
Human User A person authenticated by password or PUC7.
Device An external device authenticated by cryptographic operation
Table 3: External entities8
3.2 Threats
38 This section describes the threats to be averted by the TOE independently or in collaboration with
its IT environment. These threats result from the assets protected by the TOE and the method of
TOE’s use in the operational environment.
39 The following threats are defined in the BSI-CC-PP-0035-2007 [11] and referenced in BSI-CC-
PP-0082-V2 [50]: T.Leak-Inherent, T.Phys-Probing, T.Malfunction, T.Phys-Manipulation,
T.Leak-Forced, T.Abuse-Func, T.RND. All threats are part of this Security Target and taken over
into this ST. Please refer BSI-CC-PP-0035-2007 for further descriptions and the details. Table 4
lists all threats taken over with the corresponding reference.
Threat name Reference to
paragraph in [11]
Short description
T.Leak-Inherent 78 Inherent Information Leakage
T.Phys-Probing 79 Physical Probing
T.Malfunction 80 Malfunction due to Environmental Stress
T.Phys-Manipulation 81 Physical Manipulation
T.Leak-Forced 82 Forced Information Leakage
T.Abuse-Func 83 Abuse of Functionality
T.RND 84 Deficiency of Random Numbers
Table 4: Overview of threats defined in BSI-CC-PP-0035 [11] and taken over into this ST.
40 The TOE shall avert the threat “Forge of User or TSF data (T.Forge_Internal_Data)” as specified
below.
T.Forge_Internal_Data Forge of User or TSF data
7 The user World corresponds to the access condition ALWAYS in [21]. An authenticated Human User or
Device is allowed to use the right assigned for World.
8 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
perceives only ‘subjects’ and, for them, 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 18 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
An attacker with high attack potential tries to forge internal
user data or TSF data.
This threat comprises several attack scenarios of smart card
forgery. The attacker may try to alter the user data e.g. to add
user data in elementary files. The attacker may misuse the TSF
management function to change the user authentication data to
a known value.
41 The TOE shall avert the threat “Compromise of confidential User or TSF data
(T.Compromise_Internal_Data)” as specified below.
T.Compromise_Internal_D
ata
Compromise of confidential User or TSF data
An attacker with high attack potential tries to compromise
confidential user data or TSF data through the communication
interface of the TOE.
This threat comprises several attack scenarios e.g. guessing of
the user authentication data (password) or reconstruction the
private decipher key using the response code for chosen cipher
texts (like Bleichenbacher attack for the SSL protocol
implementation), e.g. to add keys for decipherment. The
attacker may misuse the TSF management function to change
the user authentication data to a known value.
42 The TOE shall avert the threat “Misuse of TOE functions (T.Misuse)” as specified below.
T.Misuse Misuse of TOE functions
An attacker with high attack potential tries to use the TOE
functions to gain access to the access control protected assets
without knowledge of user authentication data or any implicit
authorization.
This threat comprises several attack scenarios e.g. the attacker
may try circumvent the user authentication to use signing
functionality without authorization. The attacker may try to
alter the TSF data e.g. to extend the user rights after successful
authentication.
43 The TOE shall avert the threat “Malicious Application (T.Malicious_Application)” as specified
below.
T.Malicious_Application Malicious Application
An attacker with high attack potential tries to use the TOE
functions to install an additional malicious application in order
to compromise or alter User Data or TSF data.
44 The TOE shall avert the threat “Cryptographic attack against the implementation (T.Crypto)” as
specified below.
T.Crypto Cryptographic attack against the implementation
An attacker with high attack potential tries to launch a
Security Target Lite STARCOS 3.6 COSGKV C1 Page 19 of 134
cryptographic attack against the implementation of the
cryptographic algorithms or tries to guess keys using a brute-
force attack on the function inputs.
This threat comprises several attack scenarios e.g. an attacker
may try to foresee the output of a random number generator in
order to get a session key. An attacker may try to use leakage
during cryptographic operation in order to use SPA, DPA, DFA
or EMA techniques in order to compromise the keys or to get
knowledge of other sensitive TSF or User data. Furthermore an
attacker could try guessing the key by using a brute-force
attack.
45 The TOE shall avert the threat “Interception of Communication (T.Intercept)” as specified below.
T.Intercept Interception of Communication
An attacker with high attack potential tries to intercept the
communication between the TOE and an external entity, to
forge, to delete or to add other data to the transmitted sensitive
data.
This threat comprises several attack scenarios. An attacker may
try to read or forge data during transmission in order to add
data to a record or to gain access to authentication data.
46 The TOE shall avert the threat “Wrong Access Rights for User Data or TSF Data (T.Wrong)” as
specified below.
T.WrongRights Wrong Access Rights for User Data or TSF Data
An attacker with high attack potential executes undocumented
or inappropriate access rights defined in object system and
compromises or manipulate sensitive User data or TSF data.
3.3 Organisational Security Policies
47 The TOE and/or its environment shall comply with the following Organisational Security Policies
(OSP) as security rules, procedures, practices, or guidelines imposed by an organisation upon its
operation.
48 The following OSP is defined in the BSI-CC-PP-0035-2007 [11] and referenced in BSI-CC-PP-
0082-V2 [50]. That OSP is part of this Security Target and is taken over into this ST for the
current TOE. Note the current ST includes the embedded software which is not a part of TOE
defined in the BSI-CC-PP-0035-2007 [11]. Please refer BSI-CC-PP-0035-2007 for further
descriptions and the details. Table 5 lists all OSP taken over with the corresponding reference.
OSP name Short description Reference to paragraph in [11]
P.Process-TOE Protection during TOE
Development and Production
86
Table 5: Overview of OSP defined in BSI-CC-PP-0035-2007 [11] and taken over into this
ST.
3 Security Problem Definition
Page 20 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
3.4 Assumptions
49 The assumptions describe the security aspects of the environment in which the TOE will be used
or is intended to be used.
50 The assumptions A.Process-Sec-IC, A.Plat-Appl and A.Resp-Appl defined in the BSI-CC-PP-
0035-2007 [11] and referenced in the BSI-CC-PP-0082-V2 [50] address the operational
environment of the Security IC, i.e. the COS part of the current TOE and the operational
environment of the current TOE. The aspects of these assumptions are relevant for the COS part
of the current TOE, address the development process of the COS and are evaluated according to
composite evaluation approach [8]. Therefore these assumptions are refined in BSI-CC-PP-0082-
V2 [50] in order to address the assumptions about the operational environment of the TOE in
BSI-CC-PP-0082-V2. The Table 6 lists and maps these security objectives for the operational
environment with the corresponding reference.
Assumptions
defined in
[11]
Reference to
paragraph in
[11]
Refined assumptions for the
operational environment of the
current TOE
Rationale of the
changes
A.Process-
Sec-IC
91 A.Process-Sec-SC While the TOE of
BSI-CC-PP-0035-
2007 is delivered
after Phase 3 IC
manufactioring and
Testing or Phase or
Phase 4 IC Packaging
the current TOE is
delivered after Phase
5 Composite Product
Integration before
Phase 6
Personalisation. The
protection during
Phase 4 may and
during Phase 5 shall
be addressed by
security of the
development
environment of the
current TOE. Only
protection during
Personalisation is in
responsibility of the
operational
environment.
A.Plat-Appl 93 removed Usage of Hardware
Platform as TOE of
BSI-CC-PP-0035-
2007 as addressed by
A.Plat-Appl is
covered by ADV
class related to COS
as part of the current
Security Target Lite STARCOS 3.6 COSGKV C1 Page 21 of 134
Assumptions
defined in
[11]
Reference to
paragraph in
[11]
Refined assumptions for the
operational environment of the
current TOE
Rationale of the
changes
TOE.
A.Resp-Appl 95 A.Resp-ObjS The user data of the
TOE of BSI-CC-PP-
0035-2007 are the
Security IC
Embedded Software,
i.e. the COS part of
the TOE, the TSF
data of the current
TOE and the user
data of the COS. The
object system
contains the TSF data
and defines the
security attributes of
the user data of the
current TOE.
Table 6: Overview of assumptions defined in BSI-CC-PP-0035-2007 [11] and implemented
by the TOE.
51 The developer of applications for COS must ensure the appropriate “A.Process-Sec-SC
(Protection during Personalisation)” after delivery of the TOE.
A.Process-Sec-SC Protection during Personalisation
It is assumed that security procedures are used after delivery
of the TOE by the TOE Manufacturer up to delivery to the
end-consumer to maintain confidentiality and integrity of the
TOE and of its manufacturing and test data (to prevent any
possible copy, modification, retention, theft or unauthorised
use).
52 The developer of applications for COS must ensure the appropriate “Usage of COS (A.Plat-
COS)” while developing the application.
A.Plat-COS Usage of COS
An object system designed for the TOE meets the following
documents: (i) TOE guidance documents (refer to the
Common Criteria assurance class AGD) such as the user
guidance, and the application notes, and (ii) findings of the
TOE evaluation reports relevant for the COS as documented
in the certification report.
53 The developer of applications for COS must ensure the appropriate “Treatment of User Data by
the Object System (A.Resp-ObjS)” while developing the application.
A.Resp-ObjS Treatment of User Data by the Object System
All User Data and TSF Data are treated by the object system
as defined for its specific application context.
4 Security Objectives
Page 22 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
4 Security Objectives
54 This chapter describes the security objectives for the TOE and the security objectives for the TOE
environment.
4.1 Security Objectives for the TOE
55 The following TOE security objectives address the protection provided by the TOE.
56 The following Security Objectives for the TOE are defined in the BSI-CC-PP-0035-2007 [11] and
referenced in BSI-CC-PP-0082-V2 [50]. The Security Objectives for the TOE are part of the BSI-
CC-PP-0082-V2 and are taken over into this ST. Please refer BSI-CC-PP-0035-2007 for further
descriptions and the details. Table 6 lists all Security Objectives taken over with the
corresponding reference.
Security Objectives
name
Short description Reference to
paragraph in [11]
O.Leak-Inherent Protection against Inherent Information Leakage 100
O.Phy-Probing Protection against Physical Probing 101
O.Malfunction Protection against Malfunctions 102
O.Phys-Manipulation Protection against Physical Manipulation 103
O.Leak-Forced Protection against Forced Information Leakage 104
O.Abuse-Func Protection against Abuse of Functionality 105
O.Identification TOE Identification 106
O.RND Random Numbers 107
Table 7: Overview of Security Objectives for the TOE defined in BSI-CC-PP-0035 [11] and taken
over into this ST.
57 Additionally the following Security Objectives for the TOE are defined:
58 The TOE shall provide “Integrity of internal data (O.Integrity)” as specified below.
O.Integrity Integrity of internal data
The TOE must ensure the integrity of the User Data, the
security services and the TSF data under the TSF scope of
control.
59 The TOE shall provide “Confidentiality of internal data (O.Confidentiality)” as specified below.
O.Confidentiality Confidentiality of internal data
The TOE must ensure the confidentiality of private keys and
other confidential User Data and confidential TSF data
especially the authentication data, under the TSF scope of
control against attacks with high attack potential.
60 The TOE shall provide a “Treatment of User and TSF Data (O.Resp-COS)” as specified below.
O.Resp-COS Treatment of User and TSF Data
Security Target Lite STARCOS 3.6 COSGKV C1 Page 23 of 134
The User Data and TSF data (especially cryptographic keys)
are treated by the COS as defined by the TSF data of the object
system.
61 The TOE shall provide “Support of TSF data export (O.TSFDataExport)” as specified below.
O.TSFDataExport Support of TSF data export
The TOE must provide correct export of TSF data of the object
system excluding confidential TSF data for external review.
62 The TOE shall provide “Authentication of external entities (O.Authentication)” as specified
below.
O.Authentication Authentication of external entities
The TOE supports the authentication of human users and
external devices. The TOE is able to authenticate itself to
external entities.
63 The TOE shall provide “Access Control for Objects (O.AccessControl)” as specified below.
O.AccessControl Access Control for Objects
The TOE must enforce that only authenticated entities with
sufficient access control rights can access restricted objects and
services. The access control policy of the TOE must bind the
access control right of an object to authenticated entities. The
TOE must provide management functionality for access control
rights of objects.
64 The TOE shall provide “Generation and import of keys (O.KeyManagement)” as specified below.
O.KeyManagement Generation and import of keys
The TOE must enforce the secure generation, import,
distribution, access control and destruction of cryptographic
keys. The TOE must support the public key import from and
export to a public key infrastructure.
65 The TOE shall provide “Cryptographic functions (O.Crypto)” as specified below.
O.Crypto Cryptographic functions
The TOE must provide cryptographic services by
implementation of secure cryptographic algorithms for hashing,
key generation, data confidentiality by symmetric and
asymmetric encryption and decryption, data integrity protection
by symmetric MAC and asymmetric signature algorithms, and
cryptographic protocols for symmetric and asymmetric entity
authentication.
66 The TOE shall provide a “Secure messaging (O.SecureMessaging)” as specified below.
O.SecureMessaging Secure messaging
4 Security Objectives
Page 24 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
The TOE supports secure messaging for protection of the
confidentiality and the integrity of the commands received from
successful authenticated device and sending responses to this
device on demand of the external application. The TOE enforces
the use of secure messaging for receiving commands if defined
by access condition of an object.
4.2 Security Objectives for Operational Environment
67 This section describes the security objectives for the operational environment enforced by the
Security IC Embedded Software.
68 The following security objectives for the operational environment of the security IC are defined
in the BSI-CC-PP-0035-2007 [11]. The operational environment of the Security IC as TOE in the
BSI-CC-PP-0035-2007 comprises the COS part of the TOE in the BSI-CC-PP-0035-2007 and the
operational environment of the TOE in the BSI-CC-PP-0035-2007. Therefore these security
objectives of the operational environment are split and refined in the BSI-CC-PP-0082-V2. The
aspects relevant for the COS part of the TOE in the BSI-CC-PP-0082-V2 shall be fulfilled in the
development process of the COS and evaluated according to composite evaluation approach [8].
The remaining aspects of the security objectives for the operational environment defined in the
BSI-CC-PP-0035-2007 are addressed in the BSI-CC-PP-0082-V2 in new security objectives for
the operational environment of the BSI-CC-PP-0082-V2. The Table 7 lists and maps these
security objectives for the operational environment with the corresponding reference.
Security Objectives
for the operational
environment
defined in [11]
Reference to
paragraph
in [11]
Refined security
objectives for the
operational
environment of the
current TOE
Rationale of the changes
OE.Plat-Appl 109 removed OE.Plat-Appl requires the
Security IC Embedded Software
to meet the guidance documents
of the Security IC. The Security
IC Embedded Software is part of
the current TOE. This
requirement shall be fulfilled in
the development process of the
TOE.
OE.Resp-Appl 110 OE.Resp-ObjS OE.Resp-Appl requires the
Security IC Embedded Software
to treat the user data as required
by the security needs of the
specific application context. This
objective shall be ensured by the
TOE and the object system.
OE.Process-Sec-IC 111 OE.Process-Card The policy defined for the
Security platform IC is extended
to the current TOE.
Table 8: Overview of Security Objectives for the Operational Environment defined in BSI-
CC-PP-0035-2007 [11] and taken over into this ST.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 25 of 134
69 The Security IC Embedded Software shall provide “Usage of COS (OE.Plat-COS)” as specified
below
OE.Plat-COS Usage of COS
To ensure that the TOE is used in a secure manner the object
system shall be designed such that the requirements from the
following documents are met: (i) user guidance of the COS, (ii)
application notes for the COS (iii) other guidance documents,
and (iv) findings of the TOE evaluation reports relevant for
applications developed for COS as referenced in the
certification report.
70 The Security IC Embedded Software shall provide “Treatment of User Data (OE.Resp-ObjS)” as
specified below
OE.Resp-ObjS Treatment of User Data
All User Data and TSF Data of the object system are defined as
required by the security needs of the specific application
context.
71 The operational environment of the TOE shall provide “Protection of Card during Personalisation
(OE.Process-Card)” as specified below
OE.Process-Card Protection of Card during Personalisation
Security procedures shall be used after delivery of the TOE
during Phase 6 Smartcard personalisation up to the delivery of
the smartcard to the end-user to maintain confidentiality and
integrity of the TOE and to prevent any theft, unauthorised
personalization or unauthorised use.
4.3 Security Objective Rationale
72 Table 1 in BSI-CC-PP-0035-2007 [11] Section 4.4 “Security Objectives Rationale” give an
overview, how the assumptions, threats, and organisational security policies taken over are
addressed by the objectives. Please refer that table and the text following after that table justifying
this in detail for the further details.
73 The following tables provide an overview for the coverage of the defined security problem by the
security objectives for the TOE and its environment. The tables are addressing the security
problem definition as given in the BSI-CC-PP-0035-2007 and the additional threats,
organisational policies and assumptions defined in the BSI-CC-PP-0082-V2 [50]. It shows that all
threats and OSPs are addressed by the security objectives for the TOE and for the TOE
environment. It also shows that all assumptions are addressed by the security objectives for the
TOE environment.
4 Security Objectives
Page 26 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
SAR
ALC
for
IC
part
of
the
TOE)
OE.Process-Sec-Card
(SAR
ADV
class
for
COS
part
of
the
TOE)
(SAR
for
COS
part
of
the
TOE)
OE.Resp-ObjS
O.Identification
O.Leak-Inherent
O.Phys-Probing
O.Malfunction
O.Phys-Manipulation
O.Leak-Forced
O.Abuse-Func
O.RND
A.Process-Sec-IC (X) (X)
A.Process-Sec-SC X
A.Plat-Appl (X)
A.Resp-Appl (X)
A.Resp-ObjS X
P.Process-TOE X
T.Leak-Inherent X
T.Phys-Probing X
T.Malfunction X
T.Phys-Manipulation X
T.Leak-Forced X
T.Abuse-Func X
T.RND X
Table 9: Security Objective Rationale related to the IC platform
74 The assumption A.Process-Sec-IC assumes OE.Process-Sec-IC requires that security procedures
are used after delivery of the TOE by the TOE Manufacturer up to delivery to the end-consumer
to maintain confidentiality and integrity of the TOE and of its manufacturing and test data (to
prevent any possible copy, modification, retention, theft or unauthorised use). Development and
production of the Security IC is part of development and production of the TOE because it
includes the Security IT. The A.Process-Sec-SC assumes and OE.Process-Sec-Card requires
security procedures during Phase 6 Smartcard personalisation up to the delivery of the smartcard
to the end-user. More precisely, the smartcard life cycle according to [10] (cf. also to BSI-CC-PP-
0035-2007) are covered as follows.
 IC development (Phase 2) and IC manufacturing and testing (Phase3) are covered as
development and manufacturing of the security IC and therefore of the TOE as well.
 IC packaging and testing (Phase 3) may be part of the development and manufacturing
environment or the operational environment of the security IC. Even if it is part of the
operational environment of the Security IC addressed by OE. Process-Sec-IC it will be part
of the development and manufacturing environment of the current TOE and covered by the
SAR ALC_DVS.2.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 27 of 134
 IC packaging and testing (Phase 4) and Smartcard Packaging and finishing process (Phase 5)
are addressed by OE. Process-Sec-IC but they are covered by development and
manufacturing environment of the current TOE and covered by the SAR ALC_DVS.2.
 Smartcard personalisation (Phase 6) up to the delivery of the smartcard to the end-user is is
addressed by A.Process-Sec-IC and A.Process-Sec-SC and covered by OE.Process-Sec-
Card.
75 The assumption A.Plat-Appl assumes that the Security IC Embedded Software is designed so that
the requirements from the following documents are met: (i) TOE guidance documents (refer to
the Common Criteria assurance class AGD) such as the hardware data sheet, and the hardware
application notes, and (ii) findings of the TOE evaluation reports relevant for the Security IC
Embedded Software as documented in the certification report. This is met by the SAR of ADV
class and the requirements for composite evaluation [8].
76 The assumption A.Resp-Appl assumes that security relevant user data (especially cryptographic
keys) are treated by the Security IC Embedded Software as defined for its specific application
context. This assumption is split into requirements for the COS part of the TSF to provide
appropriate security functionality for the specific application context as defined by SFR of the
current PP and the assumption that AResp-ObjS that assumes all User Data and TSF Data of the
TOE are treated in the object system as defiend for its spefified application context. The security
objective for the operational environment OE.Resp-Obj requires the object system to be defined
as required by the security needs of the specified application context.
77 The OSP P.Process-TOE and the threats T.Leak-Inherent, T.Phys-Probing, T.Malfunction,
T.Phys-Manipulation, T.Leak-Forced, T.Abuse-Func and T.RND are covered by the security
objectives as described in BSI-CC-PP-0035-2007. As stated in section 2.4, this ST claims
conformance to BSI-PP-0035-2007 [11]. The objectives, assumptions, policies and threats as used
in Table 9 are defined and handled in [11]. Hence, the rationale for these items and their
correlation with Table 9 is given in [11] and not repeated here.
78 The current ST defines new threats and assumptions for the TOE extended to the the Security
platform IC as TOE defined in BSI-PP-0035-2007 and extends the policy P.Process-TOE to the
current TOE.
4 Security Objectives
Page 28 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
O.Integrity
O.Confidentiality
O.Resp-COS
O.TSFDataExport
O.Authentication
O.AccessControl
O.KeyManagement
O.Crypto
O.SecureMessaging
OE.Plat-COS
OE.Resp-ObjS
OE.Process-Card
T.Forge_Internal_Data X X
T.Compromise_Internal_Data X X X
T.Malicious_Application X X X
T.Misuse X X
T.Crypto X
T.Intercept X
T.Wrong X
A.Plat-COS X
A.Resp-ObjS X
P.Process-TOE X
Table 10: Security Objective Rationale for the COS part of the TOE
79 A detailed justification required for suitability of the security objectives to coup with the security
problem definition is given below.
80 The thread T.Forge_Internal_Data addresses the falsification of internal user data or TSF data
by an attacker. This is prevented by O.Integrity that ensures the integrity of user data, the security
services and the TSF data. Also, O.Resp-COS addresses this thread because the user data and
TSF data are treated by the TOE as defined by the TSF data of the object system.
81 The thread T.Compromise_Internal_Data addresses the disclosure of confidential user data or
TSF data by an attacker. The objective O.Resp-COS requires that the user data and TSF data are
treated by the TOE as defined by the TSF data of the object system. Hence, the confidential data
are handled correctly by the TSF. The security objective O.Confidentiality ensures the
confidentiality of private keys and other confidential TSF data. O.KeyManagement requires that
the used keys to protect the confidentiality are generated, imported, distributed, managed and
destroyed in a secure way.
82 The thread T.Malicious_Application addresses the modification of user data or TSF data by the
installation and execution of a malicious code by an attacker. The security objective
O.TSFDataExport requires the correct export of TSF data in order to prevent the export of code
fragments that could be used for analysing and modification of TOE code. O.Authentication
enforces user authentication in order to control the access protected functions that could be
(mis)used to install and execute malicious code. Also, O.AccessControl requires the TSF to
enforce an access control policy for the access to restricted objects in order to prevent
unauthorised installation of malicious code.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 29 of 134
83 The thread T.Misuse addresses the usage of access control protected assets by an attacker without
knowledge of user authentication data or by any implicit authorization. This is prevented by the
security objective O.AccessControl that requires the TSF to enforce an access control policy for
the access to restricted objects. Also the security objective O.Authentication requires user
authentication for the use of protected functions.
84 The thread T.Crypto addresses a cryptographic attack to the implementation of cryptographic
algorithms or the guessing of keys using brute force attacks. This thread is directly covered by the
security objective O.Crypto which requires a secure implementation of cryptographic algorithms.
85 The thread T.Intercept addresses the interception of the communication between the TOE and an
external entity by an attacker. The attacker tries to delete, add or forge transmitted data. This
thread is directly addressed by the security objective O.SecureMessaging which requires the TOE
to establish a trusted channel that protects the confidentiality and integrity of the transmitted data
between the TOE and an external entity.
86 The thread T.WrongRights addresses the compromising or manipulation of sensitive user data or
TSF data by using undocumented or inappropriate access rights defined in the object system. This
thread is addressed by the security objective O.Resp-COS which requires the TOE to treat the
user data and TSF data as defined by the TSF data of the object system. Hence the correct access
rights are always used and prevent misuse by undocumented or inappropriate access rights to that
data.
87 The assumption A.Plat-COS assumes that the object system of the TOE is designed according to
dedicated guidance documents and according to relevant findings of the TOE evaluation reports.
This assumption is directly addressed by the security objective for the operational environment
OE.Plat-COS.
88 The assumption A.Resp-ObjS assumes that all user data and TSF data are treated by the object
system as defined for its specific application context. This assumption is directly addressed by the
security objective for the operational environment OE.Resp-ObjS.
89 The OSP P.Process-TOE addresses the protection during TOE development and production as
defined in BSI-CC-PP-0035-2007 [11]. This is supported by the security objective for the
operational environment OE.Process-Card that addresses the TOE after the delivery for phase 5
up to 7: It requires that end consumers maintain the confidentiality and integrity of the TOE and
its manufacturing and test data.
5 Extended Components Definition
Page 30 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
5 Extended Components Definition
90 This security target uses components defined as extensions to Common Criteria part 2 [3]. The
following extensions are taken from BSI-CC-PP-0082-V2 [50] and BSI-CC-PP-0035-2007 [11]
chapter 5 “Extended Components Definition” and are part of this security target:
- Definition of the Family FMT_LIM, and
- Definition of the Family FAU_SAS.
The Definition of the Family FCS_RNG already defined in BSI-CC-PP-0035-2007 is updated in
BSI-CC-PP-0082-V2 according to [6] and [7] by refinement of selection “hybrid” to “hybrid
physical” and “hybrid deterministic”. The families FIA_API, FPT_EMS and FPT_ITE are
defined in the document on hand.
5.1 Definition of the Family FCS_RNG Generation of Random Numbers
91 This section describes the functional requirements for the generation of random numbers, which
may be used as secrets for cryptographic purposes or authentication. The IT security functional
requirements for a TOE are defined in an additional family (FCS_RNG) of the Class FCS
(Cryptographic support).
Family Behaviour
92 This family defines quality requirements for the generation of random numbers that are intended
to be used for cryptographic purposes.
Component levelling:
FCS_RNG: Generation of random numbers 1
FCS_RNG: Generation of random numbers 1
93 FCS_RNG.1 Generation of random numbers requires that the random number generator
implements defined security capabilities and that the random numbers meet a defined quality
metric.
Management: There are no management activities foreseen.
Audit: There are no actions defined to be auditable
FCS_RNG.1 Random number generation
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true,
deterministic, hybrid physical, hybrid deterministic] random number
generator that implements: [assignment: list of security capabilities].
FCS_RNG.1.2 The TSF shall provide random numbers that meet [assignment: a defined
quality metric].
94 Application note 2: This definition of FCS_RNG family is identical to the definition given in
BSI-CC-PP-0035-2007 but introduce additional RNG class “hybridphysical” RNG and “hybrid
deterministic” RNG according to [7].
Security Target Lite STARCOS 3.6 COSGKV C1 Page 31 of 134
5.2 Definition of the Family FIA_API
95 To describe the IT security functional requirements of the TOE a sensitive family (FIA_API) of
the Class FIA (Identification and authentication) is defined here. This family describes the
functional requirements for the proof of the claimed identity for the authentication verification by
an external entity where the other families of the class FIA address the verification of the identity
of an external entity.
96 Application note 3: The other families of the Class FIA describe only the authentication
verification of users’ identity performed by the TOE and do not describe the functionality of the
user to prove their identity. The following paragraph defines the family FIA_API in the style of
the Common Criteria part 2 (cf. [3], chapter “Explicitly stated IT security requirements
(APE_ECD)”) from a TOE point of view.
97 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:
FIA_API.1 Authentication Proof of Identity, provides prove of the identity of the TOE to an
external entity.
Management: The following actions could be considered for the management
functions in FMT: Management of authentication information used to
prove the claimed identity.
Audit: There are no actions defined to be auditable
FIA_API.1 Authentication Proof of Identity
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_API.1.1 The TSF shall provide a [assignment: authentication mechanism] to
prove the identity of the [assignment:object, authorized user or role] to
an external entity.
5.3 Definition of the Family FPT_EMS TOE Emanation
98 The family FPT_EMS (TOE Emanation) of the class FPT (Protection of the TSF) is defined here
to describe the IT security functional requirements of the TOE. The TOE shall prevent attacks
against secret data stored in and used by the TOE where the attack is based on external observable
physical phenomena of the TOE. Examples of such attacks are evaluation of TOE’s
electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA),
timing attacks, etc. This family describes the functional requirements for the limitation of
intelligible emanations being not directly addressed by any other component of CC part 2 [2].
5 Extended Components Definition
Page 32 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
Family Behaviour
99 This family defines requirements to mitigate intelligible emanations.
Component levelling:
100 FPT_EMS.1 Emanation of TSF and User data, defines limits of TOE emanation related to TSF
and User data.
Management: There are no management activities foreseen.
Audit: There are no actions defined to be auditable
FPT_EMS.1.1 Limit of Emissions requires to not emit intelligible emissions
enabling access to TSF data or user data
FPT_EMS.1.2 Interface Emanation requires to not emit interface emanation
enabling access to TSF data or user data
FPT_EMS.1 Emanation of TSF and User data
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_EMS.1.1 The TOE shall not emit [assignment: types of emissions] in excess
of [assignment: specified limits] enabling access to [assignment: list
of types of TSF data]
And
[assignment: list of types of user data].
FPT_EMS.1.2 The TSF shall ensure [assignment: type of users] are unable to use
the following interface [assignment: type of connection] to gain
access to
[assignment: list of types of TSF data]
and
[assignment: list of types of user data].
5.4 Definition of the Family FPT_ITE TSF image export
Family Behaviour
101 The family FPT_ITE (TSF image export) of the class FPT (Protection of the TSF) is defined here
to describe the IT security functional requirements of the TOE. This family defines rules for
export of TSF implementation fingerprints and of TSF data in order to allow verification of the
correct implementationof the IC Dedicated Software and the COS of the TOE and the TSF data of
the smartcard. The export of a fingerprint of the TSF implementation, e.g. a keyed hash value
over all implemented executable code, provides the ability to compare the implemented
executable code with the known intended executable code. The export of all non-confidential TSF
data, e.g. data security attributes of subjects and objects and public authentication verification
data like public keys, provides the ability to verify their correctness e.g. against an object system
specification. The exported data must be correct, but do not need protection of confidentiality or
Security Target Lite STARCOS 3.6 COSGKV C1 Page 33 of 134
integrity if the export is performed in a protected environment. This family describes the
functional requirements for unprotected export of TSF data and export of TOE implementation
fingerprints not being addressed by any other component of CC part 2 [2].
Component levelling:
102 FPT_ITE.1 Export of TOE implementation fingerprint, provides the ability to export the TOE
implementation fingerprint without protection of confidentiality or integrity.
103 FPT_ITE.2 Export of TSF data, provides the ability to export the TSF data without protection of
confidentiality or integrity.
Management
FPT_ITE.1, FPT_ITE.2:
There are no management activities foreseen.
Audit FPT_ITE.1,
FPT_ITE.2:
There are no actions defined to be auditable
FPT_ITE.1 Export of TOE implementation fingerprint
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_ITE.1.1 The TOE shall export fingerprint of TOE implementation given
the following conditions [assignment: conditions for export].
FPT_ITE.1.2 The TSF shall use [assignment: list of generation rules to be
applied by TSF] for the exported data.
FPT_ITE.2 Export of TSF data
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_ITE.2.1 The TOE shall export [assignment: list of types of TSF data]
given the following conditions [assignment: conditions for
export].
FPT_ITE.2.2 The TSF shall use [assignment: list of encoding rules to be
applied by TSF] for the exported data.
6 Security Requirements
Page 34 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
6 Security Requirements
104 This part of the ST defines the detailed security requirements that shall be satisfied by the TOE.
The statement of TOE security requirements shall define the functional and assurance security
requirements that the TOE needs to satisfy in order to meet the security objectives for the TOE.
105 The CC allows several operations to be performed on security requirements (on the component
level); refinement, selection, assignment and iteration are defined in sec. 8.1 of Part 1 [1] of the
CC. Each of these operations is used in this ST.
106 The refinement operation is used to add detail to a requirement, and, thus, further restricts a
requirement. Refinements of security requirements are denoted in such a way that added words
are in bold text and removed words are crossed out. In some cases an interpretation refinement is
given. In such a case an extra paragraph starting with “Refinement” is given.
107 The selection operation is used to select one or more options provided by the CC in stating a
requirement. Selections made by the PP author are denoted as underlined text. Selections made by
the ST author are italicised.9
108 The assignment operation is used to assign a specific value to an unspecified parameter, such as
the length of a password. Assignments having been made by the PP author are denoted by
showing as underlined text. Assignments made by the ST author are italicised. In some cases the
assignment made by the PP authors defines a selection which was performed by the ST author.
This text is underlined and italicised like this.
109 The iteration operation is used when a component is repeated with varying operations. Iteration
is denoted by showing a slash “/”, and the iteration indicator after the component identifier.
For the sake of a better readability, the iteration operation may also be applied to some single
components (being not repeated) in order to indicate belonging of such SFRs to same functional
cluster. In such a case, the iteration operation is applied to only one single component.
110 Some SFRs (including the potential exiting refinement) were taken over from the BSI-CC-PP-
0035-2007. A list of all SFRs taken from BSI-CC-PP-0035-2007 [11] can be found in section 2.4,
additionally the SFRs taken over are labelled with a footnote.
6.1 Security Functional Requirements for the TOE
111 In order to define the Security Functional Requirements Part 2 of the Common Criteria [2] was
used. However, some Security Functional Requirements have been refined. The refinements are
described below the associated SFR.
6.1.1 Overview
112 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:
9 Note the parameter defined in the COS specification are printed in italic as well but without indication of
selection or assignment.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 35 of 134
Security Functional Groups Security Functional Requirements concerned
Protection against Malfunction FRU_FLT.2/SICP, FPT_FLS.1/SICP
Protection against Abuse of Functionality FMT_LIM.1/SICP, FMT_LIM.2/SICP,
FAU_SAS.1/SICP
Protection against Physical Manipulation
and Probing
FPT_PHP.3/SICP
Protection against Leakage FDP_ITT.1/SICP, FPT_ITT.1/SICP,
FDP_IFC.1/SICP
Generation of Random Numbers FCS_RNG.1/SICP
Table 11: Security functional groups vs. SFRs related to the IC platform
Security
Functional
Groups
Security Functional Requirements concerned
General
Protection of
User data and
TSF data
(section 6.1.4)
FDP_RIP.1, FDP_SDI.2, FPT_FLS.1, FPT_EMS.1, FPT_TDC.1, FPT_ITE.1,
FPT_ITE.2, FPT_TST.1
Authentication
(section 6.1.5)
FIA_AFL.1/PIN, FIA_AFL.1/PUC, FIA_ATD.1, FIA_SOS.1, FIA_UAU.1,
FIA_UAU.4, FIA_UAU.5, FIA_UAU.6, FIA_API.1, FMT_SMR.1,
FIA_USB.1,
Access Control
(section 6.1.6)
FDP_ACC.1/EF, FDP_ACF.1/EF, FDP_ACC.1/ MF_DF, FDP_ACF.1/
MF_DF, FMT_MSA.3, FMT_SMF.1, FMT_MSA.1/Life, FMT_MSA.1/SEF,
FMT_MTD.1/PIN, FMT_MSA.1/PIN, FMT_MTD.1/Auth,
FMT_MSA.1/Auth, FMT_MTD.1/NE, FDP_ACC.1/SEF, FDP_ACC.1/TEF,
ACC.1/KEY,
FDP_ACF.1/SEF, FDP_ACF.1/TEF, ACF.1/KEY
Cryptographic
Functions
(section 6.1.7)
FCS_RNG.1, FCS_COP.1/SHA, FCS_COP.1/ COS.3TDES, FCS_COP.1/
COS.RMAC, FCS_CKM.1/ 3TDES_SM, FCS_COP.1/
COS.AES,FCS_CKM.1/ AES.SM, FCS_CKM.1/RSA, FCS_CKM.1/ELC,
FCS_COP.1/ COS.CMAC, FCS_COP.1/ COS.RSA.S, FCS_COP.1/
COS.RSA.V, FCS_COP.1/ COS.ECDSA.S, FCS_COP.1/ COS.RSA,
FCS_COP.1/ COS.ELC, FCS_CKM.4, FCS_COP.1/COS.ECDSA.V,
FCS_COP.1.1/CB_HASH
Protection of
communication
(section 6.1.8)
FTP_ITC.1/TC
Table 12: Security functional groups vs. SFRs
113 The following TSF Data are defined for the IC part of the TOE.
TSF Data Definition
TOE pre-
personalisation data
Any data supplied by the Card Manufacturer that is injected into the non-
volatile memory by the Integrated Circuits manufacturer.
TOE initialisation
data
Initialisation Data defined by the TOE Manufacturer to identify the TOE
and to keep track of the Security IC’s production and further life-cycle
phases are considered as belonging to the TSF data.
Table 13: TSF Data defined for the IC part
6 Security Requirements
Page 36 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
6.1.2 Users, subjects and objects
114 The security attributes of human users are stored in password objects (cf. [21] for details). The
human user selects the password object by pwIdentifier and therefore the role gained by the
subject acting for this human user after successful authentication. The role is a set of access rights
defined by the access control rules of the objects containing this pwIdentifier. The secret is used
to verify the authentication attempt of the human user providing the authentication verification
data. The security attributes transportStatus, lifeCycleStatus and flagEnabled stored in the
password object define the status of the role associated with the password. E.g. if the
transportStatus is equal to Leer-PIN or Transport-PIN the user is enforced to define his or her
own password and making this password and this role effective (by changing the transportStatus
to regularPassword). The multi-reference password shares the secret with the password identified
by pwReference. It allows enforcing re-authentication for access and limitation of authentication
status to specific objects and makes password management easier by using the same secret for
different roles. The security attributes interfaceDependentAccessRules, startRetryCounter,
retryCounter, minimumLength and maximumLength are defined for the secret. The PUC defined
for the secret is intended for password management and the authorization gained by successful
authentication is limited to the command RESET RETRY COUNTER for reset of the retryCounter
and setting a new secret.
115 The following table provides an overview of the authentication reference data and security
attributes of human users and the security attributes of the authentication reference data as TSF
data.
User type Authentication reference data and
security attributes
Comments
Human user Password
Authentication reference data
secret
Security attributes of the user role
pwIdentifier
transportStatus
lifeCycleStatus
flagEnabled
startSsecList
Security attributes of the secret
interfaceDependentAccessRules
startRetryCounterf
retryCounter
minimumLength
maximumLength
The following command is used by the
TOE to authenticate the human user
and to reset the security attribute
retryCounter by PIN: VERIFY.
The following command is used by the
TOE to manage the authentication
reference data secret and the security
attribute retryCounter with
authentication of the human user by
PIN: CHANGE REFERENCE DATA
(P1=’00’),
The following commands are used by
the TOE to manage the authentication
reference data secret without
authentication of the human user
CHANGE REFERENCE DATA
(P1=’01’) and RESET RETRY
COUNTER (P1=’02’).
The following command is used by the
TOE to manage the security attribute
retryCounter of the authentication
reference data PIN without
authentication of the human user:
RESET RETRY COUNTER
(P1=’03’).
The commandGET PIN STATUS is
Security Target Lite STARCOS 3.6 COSGKV C1 Page 37 of 134
User type Authentication reference data and
security attributes
Comments
used to query the security attribute
retryCounter of the authentication
reference data PIN with password
object specific access control rules.
The following commands are used by
the TOE to manage the security
attribute flagEnabled of the
authentication reference data with
human user authentication by PIN:
ENABLE VERIFICATION
REQUIREMENT, DISABLE
VERIFICATION REQUIREMENT
(P1=’00’).
The following commands are used by
the TOE to manage the security
attribute flagEnabled of the
authentication reference data without
human user authentication: ENABLE
VERIFICATION REQUIREMENT
(P1=’01’), DISABLE VERIFICATION
REQUIREMENT (P1=’01’).
The commands ACTIVATE,
DEACTIVATE and TERMINATE are used
to manage the security attribute
lifeCycleStatus of the authentication
reference data password with password
object specific access control rules.
The command DELETE is used to
delete the authentication reference data
password with password object specific
access control rules.
Human user Multi-Reference password
Authentication reference data
Secret is shared with the password
identified by pwReference.
Security attributes of the user role
pwIdentifier,
lifeCycleStatus,
transportStatus
flagEnabled
startSsecList.
Security attributes of the secret
The security attributes
interfaceDependentAccessRules,
minimumLength, maximumLength,
startRetryCounter and
retryCounter are shared with
The commands used by the TOE to
authenticate the human user and to
manage the authentication reference
Multi-Reference password data are the
same as for password.
6 Security Requirements
Page 38 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
User type Authentication reference data and
security attributes
Comments
password identified by
pwReference.
Human user Personal unblock code (PUC)
Authentication reference data
PUK
Security attributes
pwIdentifier of the password10,
pukUsage
The following command is used by the
TOE to manage the authentication
reference data secret and the security
attribute retryCounter of the
authentication reference data PIN with
authentication of the human user by
PUC: RESET RETRY COUNTER
(P1=’00’).
The following command is used by the
TOE to manage the security attribute
retryCounter of the authentication
reference data PIN with authentication
of the human user by PUC: RESET
RETRY COUNTER (P1=’01’).
Table 14: Authentication reference data of the human user and security attributes
116 The security attributes of devices depend on the authentication mechanism and the authentication
reference data. A device may be associated with a symmetric cryptographic authentication key
with a specific keyIdentifier and therefore the role gained by the subject acting for this device
after successful authentication. The role is defined by the access control rules of the objects
containing this keyIdentifier. A device may be also associated with a certificate containing the
public key as authentication reference data and the card holder authorization (CHA) in case of
RSA-based CVC or the card holder authorization template (CHAT) in case of ELC based CVC.
The authentication protocol comprise the verification of the certificate by means of the root public
key and command PSO VERIFY CERTIFICATE and the by means of the public key contained in the
successful verified certificate and the command EXTERNAL AUTHENTICATE. The subject acting
for this device get the role of the CHA which is referenced in the access control rules of the
objects. The security attribute lifeCycleStatus is defined for persistently stored keys only.
User type Authentication reference data and
security attributes
Comments
Device Symmetric authentication key
Authentication reference data
macKey11
Security attributes of the
Authentication reference data
keyIdentifier
interfaceDependentAccessRules
lifeCycleStatus
algorithmIdentifier
The following commands are used by
the TOE to authenticate a device
EXTERNAL AUTHENTICATE, MUTUAL
AUTHENTICATE and GENERAL
AUTHENTICATE,
The following commands are used by
the TOE to manage the authentication
reference data ACTIVATE, DEACTIVATE,
DELETE and TERMINATE.
10 The PUC is part of the password object as authentication reference data for the RESET RETRY COUNTER
command for this password.
11 The symmetric authentication object contains encryption key encKey and a message authentication key
macKey.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 39 of 134
User type Authentication reference data and
security attributes
Comments
numberScenario
Device Asymmetric authentication key
Authentication reference data
Root Public Key
Certificate containing the public
key of the device12
persistentCache,
applicationPublicKeyList13
Security attributes of the user
Certificate Holder Reference
(CHR)
lifeCycleStatus,
interfaceDependentAccessRules,
Certificate Holder Authorization
(CHA) for RSA keys or Certificate
Holder Authorization Template
(CHAT) for elliptic curve keys
Security attributes in the certificate
Certificate Profile Identifier (CPI)
Certification Authority Reference
(CAR)
Object Identifier (OID)
The following command is used by the
TOE to authenticate a device EXTERNAL
AUTHENTICATE with algID equal to
rsaRoleCheck or elcRoleCheck
The following commands are used by the
TOE to manage the authentication
reference data PSO VERIFY
CERTIFICATE,ACTIVATE,
DEACTIVATE, DELETE and
TERMINATE.
Device Secure messaging channel key
Authentication reference data
MAC session key SK4SM
Security attributes of SK4SM
flagSessionEnabled equal SK4SM,
Kmac and SSCmac,
negotiationKeyInformation.
The TOE authenticates the sender of a
received command using secure
messaging
Table 15: Authentication reference data of the devices and security attributes
117 The following table defines the authentication verification data used by the TSF itself for
authentication by external entities (cf. FIA_API.1).
Subject type Authentication verification data and
security attributes
Comments
TSF Private authentication key The following commands are used by
the TOE to authenticate themselves to an
12 The certificate of the device may be only end of a certificate chain going up to the root public key.
13 The command PSO VERIFY CERTIFICATEPSO VERIFY CERTIFICATE may store the successful verified
public key temporarily in the volatileCacheor persistenly in theappliationPublicKeyList or the
persistentCache. Public keys in the applicationPublicKeyListmay be used like root public keys. The
wrapper specification [27] and COS specification [21] define the attribute persistentPublicKeyList as
superset of all persistently stored public key in the applicationPublicKeyList and the persitentCache.
6 Security Requirements
Page 40 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
Subject type Authentication verification data and
security attributes
Comments
Authentication verification data
privateKey
Security attributes
keyIdentifier
setAlgorithmIdentifier with
algorithmIdentifier
lifeCycleStatus
external device: INTERNAL
AUTHENTICATE, MUTUAL
AUTHENTICATE
TSF Secure messaging channel key
Authentication verification data
MAC session key SK4SM
Security attributes
flagSessionEnabled, macKey and
SSCmac, encKey and SSCenc,
flagCmdEnc and flagRspEnc
Responses using secure messaging. The
session keys are linked to the folder of
the keys used to them.
Table 16: Authentication verification data of the TSF and security attributes
118 The COS specification associates a subject with a logical channel and its channelContext
(cf. [21], chapter 12). The TOE supports one subject respective logical channel. The
channelContext comprises security attributes of the subject summarized in the following table.
Security attribute Elements Comments
interface The TOE does not support contactless
communication the TOE and behaves as
interfaceDependentAccess
Rules is permanently set to “kontaktbehaftet”.
currentFolder Identifier of the (unique) current folder
seIdentifier Security environment selected by means of
command MANAGE SECURITY ENVIRONMENT14.
If no security environment is explicitly selected
the default security environment #1 is assumed.
keyReferenceList The list contains elements which may be empty
or may contain one pair (keyReference,
algorithmIdentifier).
externalAuthenticate keyReference and algorithmIdentifier of the key
selected by means of the command MANAGE
SECURITY ENVIRONMENT to be used for device
authentication by means of commands
EXTERNAL AUTHENTICATE and MUTUAL
AUTHENTICATE
internalAuthenticate keyReference and algorithmIdentifier of the key
selected by means of the command MANAGE
SECURITY ENVIRONMENT to be used for
14 Note the COS specification [21] describes this security attribute in the informative chapter 8.8. The object
system specification of the eHCP uses this security attribute for access control rules of batch signature
creation.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 41 of 134
Security attribute Elements Comments
authentication of the TSF itself by means of
commands INTERNAL AUTHENTICATE
verifyCertificate keyReference of the key selected by means of the
command MANAGE SECURITY ENVIRONMENT to
be used for PSO VERIFY CERTIFICATE
signatureCreation keyReference and algorithmIdentifier of the key
selected by means of the command MANAGE
SECURITY ENVIRONMENT to be used for PSO
COMPUTE DIGITAL SIGNATURE
dataDecipher keyReference and algorithmIdentifier of the key
selected by means of the command MANAGE
SECURITY ENVIRONMENT to be used for PSO
DECIPHER or PSO TRANSCIPHER
dataEncipher keyReference and algorithmIdentifier of the key
selected by means of the command MANAGE
SECURITY ENVIRONMENT to be used for PSO
ENCIPHER.
macCalculation keyReference and algorithmIdentifier of the key
selected by means of the command MANAGE
SECURITY ENVIRONMENT to be used for PSO
COMPUTE CRYPTOGRAPHIC CHECKSUM and PSO
VERIFY CRYPTOGRAPHIC CHECKSUM
SessionkeyContext This list contains security attributes associated
with secure messaging and trusted channels.
flagSessionEnabled Value noSK indicates no session key established.
Value SK4SM indicates session keys established
for receiving commands and sending responses.
Value SK4TC indicates session keys established
for PSO COMPUTE CRYPTOGRAPHIC CHECKSUM,
PSO VERIFY CRYPTOGRAPHIC CHECKSUM and
PSO ENCIPHER, PSO DECIPHER.
encKey and SSCenc Key for encryption and decryption and its
sequence counter
macKey and SSCmac Key for MAC calculation and verification and its
sequence counter
flagCmdEnc and
flagRspEnc
Flags indicating encryption of data in commands
respective responses
negotiationKeyInform
ation
keyIdentifier of the key used to generate the
session keys and if asymmetric key was used the
accessRight associated with this key. The
keyIdentifier may reference to the authentication
reference data used for PACE.
accessRulesSession-
keys
Access control rules associated with trusted
channel support.
globalPasswordList (pwReference,
securityStatusEvaluati
onCounter)
List of 0, 1, 2, 3 or 4 elements containing results
of successful human user authentication with
password in MF: pwReference and
6 Security Requirements
Page 42 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
Security attribute Elements Comments
securityStatusEvaluationCounter
dfSpecificPasswordLi
st
(pwReference,
securityStatusEvaluati
onCounter)
List of 0, 1, 2, 3 or 4 elements containing results
of successful human user authentication with
password for each DF: pwReference and
securityStatusEvaluationCounter
globalSecurityList CHA or keyIdentifier List of 0, 1, 2 or 3 elements containing results of
successful device authentication with
authentication reference data in MF: CHA as
reference to the role gained by authentication
based on certificate or keyIdentifier as reference
to the used symmetric authentication key or
keyIdentifier generated by successful
authentication with PACE protocol.
dfSpecificSecurityList CHA or keyIdentifier List of 0, 1, 2 or 3 elements containing results of
successful device authentication with
authentication reference data for each DF: CHA
CHA as reference to the role gained by
authentication based on certificate or
keyIdentifier as reference to symmetric
authentication key or keyIdentifier generated by
successful authentication with PACE protocol15.
bitSecurityList List of CHAT gained by successful
authentication with CVC based on ECC. The
effective access rights are the intersection of
access rights defined in CVC of the CVC chain
up to the root.
Current file Identifier of the (unique) current file from
currentFolder.children
securityStatusEvaluat
ionCounter
startSsec Must contain all values of startSsec and may be
empty
Table 17: Security attributes of a subject
119 The following tables provide an overview of the objects, operations and security attributes
defined in the current ST (including the packages). All references in the table refer to the
technical specification of the card operating system [21]. The security attribute lifeCycleStatus is
defined for persistently stored keys only.
Object type Security attributes Operations
Object system applicationPublicKeyList,
persistentCache,
pointInTime
PSO VERIFY
CERTIFICATE
Folder (8.3.1) accessRules:
lifeCycleStatus
shareable16
SELECT
ACTIVATE
DEACTIVATE
15 The keyIdentifier generated by successful authentication with PACE protocol is named
“Kartenverbindungsobjekt” in the COS specification [21].
16 Available with package logical channel
Security Target Lite STARCOS 3.6 COSGKV C1 Page 43 of 134
Object type Security attributes Operations
interfaceDependentAccessRules
children
DELETE
FINGERPRINT
GET RANDOM17
LOAD APPLICATION
TERMINATE DF
Dedicated File (8.3.1.2) Additionally to Folder:
fileIdentifier
Identical to Folder
Application (8.3.1.1) Additionally to Folder:
applicationIdentifier
Identical to Folder
Application Dedicated File
(8.3.1.3)
Additionally to Folder:
fileIdentifier
applicationIdentifier
children
Identical to Folder
Elementary File (8.3.2) fileIdentifier
list of shortFileIdentifier
lifeCycleStatus
shareable18
accessRules:
interfaceDependentAccessRules
flagTransactionMode
flagChecksum
SELECT
ACTIVATE
DEACTIVATE
DELETE
TERMINATE
Transparent EF (8.3.2.1) Additionally to Elementary File:
numberOfOctet
positionLogicalEndOfFile
body
Additionally to
Elementary File:
ERASE BINARY
READ BINARY
UPDATE BINARY
WRITE BINARY
Structured EF (8.3.2.2) Additionally to Elementary File:
recordList
maximumNumberOfRecords
maximumRecordLength
flagRecordLifeCycleStatus
Additionally to
Elementary File:
ACTIVATE RECORD
APPEND RECORD
DELETE RECORD
DEACTIVATE RECORD
ERASE RECORD
READ RECORD
SEARCH RECORD
SET LOGICAL EOF
UPDATE RECORD
Regular Password (8.4)
(PIN)
lifeCycleStatus
pwdIdentifier
accessRules:
interfaceDependentAccessRules
secret: PIN
minimumLength
ACTIVATE
DEACTIVATE
DELETE
TERMINATE
CHANGE REFERENCE
DATA
17 Only available with package crypto box
18 Available with package logical channel
6 Security Requirements
Page 44 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
Object type Security attributes Operations
maximumLength
startRetryCounter
retryCounter
transportStatus
flagEnabled
startSsecList
PUC
pukUsage
channel specific:
securityStatusEvaluationCounter
DISABLE VERIFICATION
REQUIREMENT
ENABLE VERIFICATION
REQUIREMENT
GET PIN STATUS
RESET RETRY COUNTER
VERIFY
Multi-reference Password (8.5)
(MR-PIN)
lifeCycleStatus
pwdIdentifier
accessRules:
interfaceDependentAccessRules
startSsecList
flagEnabled
passwordReference
Attributed used together with
referred password (PIN):
secret: PIN
minimumLength
maximumLength
startRetryCounter
retryCounter
transportStatus
PUC
pukUsage
channel specific:
securityStatusEvaluationCounter
Identical to Regular
Password
PUC type pin
pukUsage
RESET RETRY COUNTER
Symmetric Key (8.6.1) lifeCycleStatus
keyIdentifier
accessRules:
interfaceDependentAccessRules
encKey
macKey
numberScenario
algorithmIdentifier
accessRulesSessionkeys:
interfaceDependentAccessRules
ACTIVATE
DEACTIVATE
DELETE
TERMINATE
EXTERNAL
AUTHENTICATE
GENERAL
AUTHENTICATE
INTERNAL
AUTHENTICATE
MUTUAL
AUTHENTICATE
Private Asymmetric Key (8.6.4) lifeCycleStatus
keyIdentifier
accessRules:
interfaceDependentAccessRules
privateKey
listAlgorithmIdentifier
ACTIVATE
DEACTIVATE
DELETE
TERMINATE
GENERATE
ASYMMETRIC KEY PAIR
Security Target Lite STARCOS 3.6 COSGKV C1 Page 45 of 134
Object type Security attributes Operations
accessRulesSessionkeys:
interfaceDependentAccessRules
algorithmIdentifier
keyAvailable
or key import
EXTERNAL
AUTHENTICATE
GENERAL
AUTHENTICATE
INTERNAL
AUTHENTICATE
PSO COMPUTE DIGITAL
SIGNATURE
PSO DECIPHER
PSO TRANSCIPHER
Public Asymmetric Key (8.6.4) lifeCycleStatus
keyIdentifier
oid
accessRules:
interfaceDependentAccessRules
ACTIVATE
DEACTIVATE
DELETE
TERMINATE
Public Asymmetric Key for
signature verification
(8.6.4.2)
Additionally to Public
Asymmetric Key:
publicRsaKey: oid or
publicElcKey: oid
CHAT
expirationDate: date
Additionally to Public
Asymmetric Key:
PSO VERIFY
CERTIFICATE,
PSO VERIFY DIGITAL
SIGNATURE
Public Asymmetric Key for
Authentication (8.6.4.3)
publicRsaKey: oid or
publicElcKey: oid
CHA
CHAT
expirationDate: date
Additionally to Public
Asymmetric Key:
EXTERNAL
AUTHENTICATE
GENERAL
AUTHENTICATE
INTERNAL
AUTHENTICATE
Public Asymmetric Key for
Encryption (8.6.4.4)
Additionally to Public
Asymmetric Key:
publicRsaKey: oid
publicElcKey: oid
Additionally to Public
Asymmetric Key:
PSO ENCIPHER
Card verifiable certificate
(CVC) (7.1.1)
Certificate Profile Identifier (CPI)
Certification Authority Reference
(CAR) Certificate Holder
Reference (CHR) Certificate
Holder Autorisation (CHA)
Object Identifier (OID) signature
Table 18: Subjects, objects, operations and security attributes. The references refer to
[21].
120 The TOE must support Access control lists for
 lifeCycleStatus values “Operation state(activated)”, “Operation state(deactivated)” and
“Termination state”,
 security environments with value seIdentifier selected for the folder
 interfaceDependentAccessRules for contact based communication
and support Access control lists for
6 Security Requirements
Page 46 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
 interfaceDependentAccessRules not for contactless communication.
121 If the user communicates with the TOE through the contact based interface the security attribute
“interface” of the subject is set to the value “kontaktbehaftet” and the
interfaceDependentAccessRules for contact based communication shall apply. As the TOE does
not support the contactless communication it behaves in respect to access control like a TOE
defining all interfaceDependentAccessRules “kontaktlos” set to NEVER in the object system.
122 The user may set the seIdentifier value of the security environments for the folder by means of the
command MANAGE SECURITY ENVIRONMENT. This may be seen as selection of a specific set of
access control rules for the folder and the objects in this folder.19
123 The TOE access control rule contains
 command defined by CLA, 0 or 1 parameter P1, and 0 or 1 parameter P2,
 values of the lifeCycleStatus and interfaceDependentAccessRules indicating the set of access
control rules to be applied,
 access control condition defined as Boolean expression with Boolean operators AND and
OR of Boolean elements of the following types ALWAYS, NEVER, PWD(pwIdentifier),
AUT(keyReference), AUT(CHA), AUT(CHAT) and secure messaging conditions (cf. [21],
chapter 10.2 for details).
Note AUT(CHAT) is true if the access right bit necessary for the object and the command is 1 in
the effective access rights calculated as bitwise-AND of all CHAT in the CVC chain verified
successfully by PSO VERIFY DIGITAL SIGNATURE command executions.
124 The Boolean element ALWAYS provides the Boolean value TRUE. The Boolean element
NEVER providesthe Boolean value FALSE. The other Boolean elements providethe Boolean
value TRUE if the value in the access control list match its corresponding security attribute of the
subject and provides the Boolean value FALSE is they do not match.
125 The following table gives an overview of the commands the COS has to implement and the
related SFR. Please note that the commands printed in italic are described in the packages. Some
commands may be or may be not implemented by the COS as defined in [21] and thereforefore
are not addressed by SFR in this ST.
Operation SFR Chapter
ACTIVATE FMT_SMF.1, FMT_MSA.1/Life 14.2.1
ACTIVATE RECORD FMT_SMF.1, FMT_MSA.1/SEF 14.4.1
APPEND RECORD FDP_ACC.1/SEF, FDP_ACF.1/SEF 14.4.2
CHANGE REFERENCE DATA FIA_UAU.5, FIA_USB.1, FMT_SMF.1,
FMT_MTD.1/PIN, FMT_MSA.1/PIN,
FIA_AFL.1/PIN
14.6.1
CREATE FDP_ACC.1/EF, FMT_SMF.1 14.2.2
DEACTIVATE FMT_SMF.1, FMT_MSA.1/PIN 14.2.3
19 This approach is used e.g. for signature creation with eHPC: the signatory selects security environment #1 for
single signature, and security environment #2 for batch signature creation requirering additional
authentication of the signature creation application.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 47 of 134
Operation SFR Chapter
DEACTIVATE RECORD FMT_SMF.1, FMT_MSA.1/SEF 14.4.3
DELETE FIA_USB.1, FDP_ACC.1/ MF_DF, FDP_ACF.1/
MF_DF, FDP_ACC.1/EF, FDP_ACF.1/EF,
FDP_ACC.1/KEY, FDP_ACF.1/KEY,
FMT_MSA.3, FMT_SMF.1, FMT_MSA.1/Life,
FCS_CKM.4
14.2.4
DELETE RECORD FDP_ACC.1/SEF, FDP_ACF.1/SEF,
FMT_MSA.1/SEF
14.4.4
DISABLE VERIFICATION
REQUIREMENT
FMT_SMF.1, FMT_MSA.1/PIN,
FIA_AFL.1/PIN.FIA_USB.1
14.6.2
ENABLE VERIFICATION
REQUIREMENT
FMT_SMF.1, FMT_MSA.1/PIN, FIA,
FIA_AFL.1/PIN.FIA_USB.1
14.6.3
ENVELOPE This command is not implemented by the TOE and
therefore not addressed in the SFRs of this ST.
14.9.1
ERASE BINARY FDP_ACC.1/TEF, FDP_ACF.1/TEF 14.3.1
ERASE RECORD FDP_ACC.1/SEF, FDP_ACF.1/SEF,
FMT_MSA.1/SEF
14.4.5
EXTERNAL AUTHENTICATE FIA_UAU.4, FIA_UAU.5, FIA_USB.1,
FCS_RNG.1, FCS_CKM.1/ AES.SM,
FCS_COP.1/ COS.RSA.V, FCS_COP.1/
COS.ECDSA.V,
14.7.1
FINGERPRINT FPT_ITE.1 FDP_ACF.1/MF_DF 14.9.2
GENERAL AUTHENTICATE FIA_UAU.4, FIA_UAU.5, FIA_UAU.6,
FIA_API.1, FIA_USB.1, FCS_RNG.1,
FCS_COP.1/ COS.AES, FCS_CKM.1/ AES.SM,
14.7.2
GENERATE ASYMMETRIC KEY PAIR FDP_ACC.1/KEY, FDP_ACF.1/KEY,
FMT_MSA.3, FMT_SMF.1, FCS_CKM.1/RSA,
FCS_CKM.1/ELC
14.9.3
GET CHALLENGE FCS_RNG.1 14.9.4
GET DATA This command is not implemented by the TOE and
therefore not addressed in the SFRs of this ST.
14.5.1
GET PIN STATUS FMT_SMF.1, FMT_MSA.1/PIN 14.6.4
GET RANDOM FCS_RNG.1,
14.9. 5
GET RESPONSE This command is not implemented by the TOE and
therefore not addressed in the SFRs of this ST.
14.9.6
GET SECURITY STATUS KEY FMT_SMF.1, FMT_MSA.1/Auth 14.7.3
INTERNAL AUTHENTICATE FIA_API.1, FCS_CKM.1/ AES.SM, FCS_COP.1/
COS.RSA.S, FCS_COP.1/ COS.ECDSA.S, 14.7.4
LOAD APPLICATION FDP_ACC.1/ MF_DF, FDP_ACF.1/ MF_DF,
FMT_SMF.1, FMT_MSA.1/Life
14.2.5
LIST PUBLIC KEY FPT_ITE.2, FDP_ACC.1/MF_DF, 14.9.7
6 Security Requirements
Page 48 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
Operation SFR Chapter
FDP_ACF.1/MF_DF
MANAGE CHANNEL FIA_UID.1, FIA_UAU.1, FMT_MSA.3 14.9.8
MANAGE SECURITY ENVIRONMENT FIA_USB.1, FDP_ACC.1/KEY,
FDP_ACF.1/KEY, FMT_MSA.3
14.9.9
MUTUAL AUTHENTICATE FIA_UAU.4, FIA_UAU.5, FIA_UAU.6,
FIA_API.1, FIA_USB.1, FCS_RNG.1,
FCS_CKM.1/ AES.SM,
14.7.1
PSO COMPUTE CRYPTOGRAPHIC
CHECKSUM
FIA_API.1, FDP_ACC.1/KEY, FDP_ACF.1/KEY,
,
14.8.1
PSO COMPUTE DIGITAL
SIGNATURE, WITHOUT
"RECOVERY"
FDP_ACC.1/KEY, FDP_ACF.1/KEY,
FMT_MSA.3, FCS_COP.1/ COS.RSA.S,
FCS_COP.1/ COS.ECDSA.S
14.8.2.1
PSO COMPUTE DIGITAL
SIGNATURE, WITH "RECOVERY"
FDP_ACC.1/KEY, FDP_ACF.1/KEY,
FMT_MSA.3, FCS_COP.1/ COS.ECDSA.S
14.8.2.2
PSO DECIPHER FIA_USB.1 ,FDP_ACC.1/KEY,
FDP_ACF.1/KEY, FMT_MSA.3, FCS_COP.1/
COS.RSA, FCS_COP.1/ COS.ELC,
14.8.3
PSO ENCIPHER FIA_API.1, FDP_ACC.1/KEY, FDP_ACF.1/KEY,
FMT_MSA.3, FCS_COP.1/ COS.RSA,
FCS_COP.1/ COS.ELC,
14.8.4
PSO HASH, [ISO/IEC 7816–8] SFR FCS_COP.1/CB_HASH -
PSO TRANSCIPHER USING RSA FDP_ACC.1/KEY, FDP_ACF.1/KEY,
FMT_MSA.3, FCS_COP.1/ COS.RSA,
FCS_COP.1/ COS.ELC
14.8.6.1
PSO TRANSCIPHER USING ELC FDP_ACC.1/KEY, FDP_ACF.1/KEY,
FMT_MSA.3, FCS_COP.1/ COS.RSA,
FCS_COP.1/ COS.ELC
14.8.6.3
PSO VERIFY CERTIFICATE FMT_SMF.1, FMT_MTD.1/Auth, FCS_COP.1/
COS.RSA.V, FCS_COP.1/
COS.ECDSA.V, FDP_ACC.1/KEY,
FDP_ACF.1/KEY
14.8.7
PSO VERIFY CRYPTOGRAPHIC
CHECKSUM
FIA_USB.1, FDP_ACC.1/KEY, FDP_ACF.1/KEY14.8.8
PSO VERIFY DIGITAL SIGNATURE FDP_ACC.1/KEY, FDP_ACF.1/KEY,
FMT_MSA.3, FCS_COP.1/
COS.ECDSA.V
14.8.9
PUT DATA This command is not implemented by the TOE and
therefore not addressed in the SFRs of this ST.
14.5.2
READ BINARY FDP_ACC.1/TEF, FDP_ACF.1/TEF 14.3.2
READ RECORD FDP_ACC.1/SEF, FDP_ACF.1/SEF 14.4.6
RESET RETRY COUNTER FIA_AFL.1/PUC, FIA_UAU.5, FMT_SMF.1, 14.6.5
Security Target Lite STARCOS 3.6 COSGKV C1 Page 49 of 134
Operation SFR Chapter
FMT_MTD.1/PIN, FMT_MSA.1/PIN
SEARCH BINARY This command is not implemented by the TOE and
therefore not addressed in the SFRs of this ST.
14.3.3
SEARCH RECORD FDP_ACC.1/SEF, FDP_ACF.1/SEF 14.4.7
SELECT FIA_USB.1, FDP_ACC.1/ MF_DF, FDP_ACF.1/
MF_DF, FDP_ACC.1/EF, FDP_ACF.1/EF
14.2.6
SET LOGICAL EOF FDP_ACC.1/TEF, FDP_ACF.1/TEF,
FDP_ACF.1/TEF
14.3.4
TERMINATE FMT_SMF.1, FMT_MSA.1/Life 14.2.9
TERMINATE CARD USAGE FMT_SMF.1, FMT_MSA.1/Life 14.2.7
TERMINATE DF FMT_SMF.1, FMT_MSA.1/Life 14.2.8
UPDATE BINARY FDP_ACC.1/TEF, FDP_ACF.1/TEF 14.3.5
UPDATE RECORD FDP_ACC.1/SEF, FDP_ACF.1/SEF 14.4.8
VERIFY FIA_AFL.1/PIN, FIA_UAU.5, FIA_USB.1,
FMT_SMF.1, FMT_MSA.1/PIN
14.6.6
WRITE BINARY FDP_ACC.1/TEF, FDP_ACF.1/TEF 14.3.6
WRITE RECORD This command is not implemented by the TOE and
therefore not addressed in the SFRs of this ST.
14.4.9
Table 19: Mapping between commands described in COS specification [21] and the SFR
In the following table the additional commands of STARCOS 3.6 COS C1 are mapped to the
following SFRs. Commands according the COS specification [21] which are used for the initialization
and personalization are already mapped in Table 19.
Operation SFR
INITALIZATION PHASE:
COMMANDS ACCORDING GUIDANCE DOCUMENTATION FOR THE
INITIALISATION PHASE STARCOS 3.6 COS C1
PERSONALISATION PHASE:
Commands according Guidance Documentation for the
Personalisation Phase STARCOS 3.6 COS C1
FMT_SMR.1.1
INITALIZATION PHASE:
Commands according Guidance Documentation for the Initialisation
Phase STARCOS 3.6 COS C1
PERSONALISATION PHASE:
Commands according Guidance Documentation for the
Personalisation Phase STARCOS 3.6 COS C1
FMT_SMF.1.1
Commands according Guidance Documentation for the
Personalisation Phase STARCOS 3.6 COS C1
FCS_CKM.1/RSA
FCS_CKM.1/ELC
Commands according Guidance Documentation for the Initialisation
Phase STARCOS 3.6 COS C1
FAU_SAS.1/SICP
Table 19a: Mapping between initialisation and personalisation commands and the SFR
6 Security Requirements
Page 50 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
6.1.3 Security Functional Requirements for the TOE taken over from BSI-PP-0035-
2007
126 All SFRs from section 6.1 ”Security Functional Requirements for the TOE” of the BSI-PP-0035-
2007 are part of the BSI-CC-PP-0082-V2. On all SFR of the BSI-PP-0035-2007 an iteration
operation is performed in BSI-CC-PP-0082-V2. For the iteration operation the suffix “/SICP” is
added to the SFR name from BSI-CC-PP-0035-2007.
127 The complete list of the SFRs taken over from BSI-PP-0035-2007 by BSI-CC-PP-0082-V2
follows. For further descriptions, details, and interpretations refer section 6.1 in BSI-PP-0035-
2007 [11].
- FRU_FLT.2/SICP: Limited fault tolerance.
- FPT_FLS.1/SICP: Failure with preservation of secure state.
- FMT_LIM.1/SICP: Limited capabilities.
- FMT_LIM.2/SICP: Limited capabilities
- FAU_SAS.1/SICP: Audit storage
- FPT_PHP.3/SICP: Resistance to physical attack.
- FDP_ITT.1/SICP: Basic internal transfer protection.
- FPT_ITT.1/SICP: Basic internal TSF data transfer protection.
- FDP_IFC.1/SICP: Subset information flow control.
- FCS_RNG.1/SICP: Random number generation
128 Table 20 maps the SFR name in BSI-CC-PP-0082-V2 to the SFR name in BSI-CC-PP-0035-
2007 [11]. This approach allows an easy and unambiguous identification which SFR was taken
over from the BSI-CC-PP-0035-2007 into the Protection Profile BSI-CC-PP-0082-V2 and which
SFR is defined newly in BSI-CC-PP-0082-V2.
SFR name SFR name in [11] Reference to paragraph in [11]
FRU_FLT.2/SICP FRU_FLT.2 140
FPT_FLS.1/SICP FPT_FLS.1 141
FMT_LIM.1/SICP FMT_LIM.1 150
FMT_LIM.2/SICP FMT_LIM.2 151
FAU_SAS.1/SICP FAU_SAS.1 152
FPT_PHP.3/SICP FPT_PHP.3 156
FDP_ITT.1/SICP FDP_ITT.1 159
FPT_ITT.1/SICP FPT_ITT.1 160
FDP_IFC.1/SICP FDP_IFC.1 161
FCS_RNG.1/SICP FCS_RNG.1 164
Table 20: Mapping between SFR names in this ST and the SFR names in the BSI-CC-PP-0035-
2007 [11]
129 In some cases security functional components have been added or refined by BSI-CC-PP-0082-
V2. Please refer section for details. The refinements of the security functional are only being
applied for the SFR for the TOE taken over from BSI-CC-PP-0035-2007 [11] (see Table 20).
The TOE shall meet the requirement “Quality metric for random numbers (FCS_RNG.1/SICP)” as
specified below (Common Criteria Part 2 extended).
Security Target Lite STARCOS 3.6 COSGKV C1 Page 51 of 134
FCS_RNG.1/SICP Random number generation
Hierarchical to: No other components.
FCS_RNG.1.1 The TSF shall provide a physical random number generator that implements
total failure test of the random source,
(PTG.2.1) A total failure test detects a total failure of entropy source
immediately when the RNG has started. When a total failure is detected, no
random numbers will be output.
(PTG.2.2) If a total failure of the entropy source occurs while the RNG is
being operated, the RNG prevents the output of any internal random number
that depends on some raw random numbers that have been generated after the
total failure of the entropy source.
(PTG.2.3) The online test shall detect non-tolerable statistical defects of the
raw random number sequence (i) immediately when the RNG has started, and
(ii) while the RNG is being operated. The TSF must not output any random
numbers before the power-up online test has finished successfully or when a
defect has been detected.
(PTG.2.4) The online test procedure shall be effective to detect non-tolerable
weaknesses of the random numbers soon.
(PTG.2.5) The online test procedure checks the quality of the raw random
number sequence. It is triggered at regular intervals or continuously. The
online test is suitable for detecting non-tolerable statistical defects of the
statistical properties of the raw random numbers within an acceptable period
of time20.
FCS_RNG.1.2 The TSF shall provide random numbers that meet
(PTG.2.6) Test procedure A does not distinguish the internal random numbers
from output sequences of an ideal RNG.
(PTG.2.7) The average Shannon entropy per internal random bit exceeds
0.99721.
Dependencies: No dependencies.
130 The TOE shall meet the requirement “Storage Audit Data (FAU_SAS.1)” as specified below.
FAU_SAS.1/SICP Requires the TOE to provide the possibility to store audit data.
Management: FAU_SAS.1
There are no management activities foreseen.
Audit: FAU_SAS.1
There are no actions defined to be auditable.
FAU_SAS.1/SICP Audit storage
Hierarchical to: No other components.
FAU_SAS.1.1/SICP TSF shall provide the test process before TOE Delivery22 with the
20 [assignment: list of additional security capabilities]
21 [selection: independent bits with Shannon entropy of 7.976 bits per octet, Min-entropy of 7.95 bit
per octet, [assignment: other comparable quality metric]
6 Security Requirements
Page 52 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
capability to store the Initialisation Data and/or Pre-personalisation Data
and/or supplements of the Security IC Embedded Software23 in the
flash memory24.
Dependencies: No dependencies.
6.1.4 General Protection of User data and TSF data
131 The TOE shall meet the requirement “Subset residual information protection (FDP_RIP.1)” as
specified below.
FDP_RIP.1 Subset residual information protection
Hierarchical to: No other components.
Dependencies: No dependencies.
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource
is made unavailable upon the deallocation of the resource from25 the
following objects: password objects, secret cryptographic keys, private
cryptographic keys, session keys, none26 27.
132 The TOE shall meet the requirement “Stored data integrity monitoring and action (FDP_SDI.2)”
as specified below.
FDP_SDI.2 Stored data integrity monitoring and action
Hierarchical to: FDP_SDI.1 Stored data integrity monitoring
Dependencies: No dependencies.
FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF for
tampering28 on all objects, based on the following attributes:
(1) key objects,
(2) PIN objects,
(3) affectedObject.flagTransactionMode=TRUE,
(4) none29 30.
133 FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall prevent the usage of this
key or PIN object31.
22 [assignment: list of subjects]
23 [assignment: list of audit information]
24 [assignment: type of persistent memory]
25 [selection: allocation of the resource to, deallocation of the resource from]
26 [assignment: other data objects]
27 [assignment: list of objects].
28 [assignment: integrity errors]
29 [assignment: other user data attributes]
30 [assignment: user data attributes]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 53 of 134
134 The TOE shall meet the requirement “Failure with preservation of secure state (FPT_FLS.1)” as
specified below.
FPT_FLS.1 Failure with preservation of secure state
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of
failures occur:
(1) exposure to operating conditions where therefore a malfunction
could occur
(2) failure detected by TSF according to FPT_TST.132.
135 The TOE shall meet the requirement “FPT_EMS.1 (FPT_EMS.1)” as specified below (CC part 2
extended).
FPT_EMS.1 Emanation of TSF and User data
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_EMS.1.1 The TOE shall not emit information about IC power consumption and
command execution time33 in excess of non useful information34
enabling access to the following TSF data
(1)Regular password,
(2)Multi-Reference password,
(3)PUC,
(4)Session keys,
(5)Symmetric authentication keys,
(6)Private authentication keys,
(7)none35 36
and the following user data
(8)Private asymmetric keys,
(9)Symmetric keys,
(10) none37 38.
FPT_EMS.1.2 The TSF shall ensure any user39 are unable to use the following interface
circuit interfaces40 to gain access to the following TSF data
31 [assignment: action to be taken]
32 [assignment: list of types of failures in the TSF]
33 [assignment: types of emissions]
34 [assignment: specified limits]
35 [assignment: list of additional types of TSF data]
36 [assignment: list of types of TSF data]
37 [assignment: list of additional types of user data]
38 [assignment: list of types of user data]
6 Security Requirements
Page 54 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
(1) Regular password
(2) Multi-Reference password
(3) PUC
(4) Session keys
(5) Symmetric authentication keys
(6) Private authentication keys
(7) none41 42
and the following user data
(8) Private asymmetric keys
(9) Symmetric keys
(10) none43 44
136 The TOE shall meet the requirement “Inter-TSF basic TSF data consistency (FPT_TDC.1)” as
specified below.
FPT_TDC.1 Inter-TSF basic TSF data consistency
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret Card
Verifiable Certificate (CVC)45 when shared between the TSF and
another trusted IT product.
FPT_TDC.1.2 The TSF shall use [21], chapter 7 “CV-Certificate” and [21], appendix H
“CV-Certificate for ELC-keys”46 when interpreting the TSF data from
another trusted IT product.
137 The TOE shall meet the requirement “Export of TOE implementation fingerprint (FPT_ITE.1)”
as specified below.
FPT_ITE.1 Export of TOE implementation fingerprint
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_ITE.1.1 The TOE shall export fingerprint of TOE implementation given the
following conditions execution of the command FINGERPRINT [21]
chapter 14.0.247.
39 [assignment: type of users]
40 [assignment: type of connection]
41 [assignment: list of additional types of TSF data]
42 [assignment: list of types of TSF data]
43 [assignment: list of additional types of user data]
44 [assignment: list of types of user data]
45 [assignment: list of TSF data types]
46 [assignment: list of interpretation rules to be applied by the TSF]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 55 of 134
FPT_ITE.1.2 The TSF shall use SHA-256 based fingerprint of the TOE
implementation48 for the exported data.
138 Application note 4: The command FINGERPRINT calculates a hash value or CMAC based
fingerprint over the complete executable code actually implemented in the TOE. The TOE
implementation includes IC Dedicated Support Software, the Card Operating System and
application specific code loaded on the smartcard by command LOAD CODE or any other
means. The hash function respective the CMAC based calculation uses the prefix send in the
command FINGERPRINT for “fresh” fingerprints over all executable code, i.e. no precomputed
values over fixed parts of the code only.
139 The TOE shall meet the requirement “Export of TSF data (FPT_ITE.2)” as specified below.
FPT_ITE.2 Export of TSF data
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_ITE.2.1 The TOE shall export
(1) all public authentication reference data,
(2) all security attributes of the object system and for all objects of
the object system for all commands,
(3) none49
given the following conditions
(1) no export of secret data,
(2) no export of private keys,
(3) no export of secure messaging keys,
(4) no export of passwords and PUC50
.
FPT_ITE.2.2 The TSF shall use structure and content of CV certificate according to
[21] and access condition encoding schemes according to [29]51 52 for
the exported data.
140 Application note 5: The public TSF data addressed as TSF data in bullet (1) in the element
FPT_ITE.2.1 covers at least all root public key and other public keys used as authentication
reference data persistent stored in the object system (cf. persitentPublicKeyList in [21] and [27],
applicationPublicKeyList and persistentCache in [21]). The bullet (2) in the element
FPT_ITE.2.1 covers all security attributes of all objects system (cf. [21], (N019.900), [27],
objectLocator ‘E0’) and of all objects of object types listed in Table 18 and all TOE specific
security attributes and parameters (except secrets). The COS specification [21] identifies
optional functionality of the TOE may support. The ST lists all security attributes and the TSF
shall export all security attributes implemented in addition to the Table 18 and due to these
options allowed according to the COS specification. Note the listOfApplication as security
47 [assignment: conditions for export]
48 [assignment: list of generation rules to be applied by TSF]
49 [assignment: list of types of TSF data]
50 [assignment: conditions for export]
51 [assignment: list of encoding rules to be applied by TSF]
52 [assignment: list of encoding rules to be applied by TSF]
6 Security Requirements
Page 56 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
attribute of the object system contains at least one applicationIdentifier of each Application or
Application Dedicated File (cf. [27]). The exported data shall be encoded by wrapper to allow
interpretation of the TSF data. The encoding rules shall meet the requirements of the Technical
Guidance TR-03143 describing the verification tool used for examination of the object system
against the specification of the object system.
141 The TOE shall meet the requirement “TSF testing (FPT_TST.1)” as specified below.
FPT_TST.1 TSF testing
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_TST.1.1 The TSF shall run a suite of self tests during initial start-up53 to
demonstrate the correct operation of the TSF54.
FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the
integrity of TSF data55.
FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the
integrity of TSF56.
6.1.5 Authentication
The TOE shall meet the requirement “Verification of secrets (FIA_SOS.1)” as specified below.
FIA_SOS.1 Verification of secrets
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_SOS.1.1 The TSF shall provide a
mechanism to verify that secrets
provided by the user for
password objects meet the quality
metric: length not lower than
minimumLength and not greater
than maximumLength57.
142 The TOE shall meet the requirement “Authentication failure handling (FIA_AFL.1/PIN)” as
specified below.
FIA_AFL.1/PIN Authentication failure handling
53 [selection: during initial start-up, periodically during normal operation, at the request of the authorised user,
at the conditions [assignment: conditions under which self test should occur]]
54 [selection: [assignment: parts of TSF], the TSF]
55 [selection: [assignment: parts of TSF data], TSF data]
56 [selection: [assignment: parts of TSF], TSF]
57 [assignment: a defined quality metric]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 57 of 134
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication.
FIA_AFL.1.1/PIN The TSF shall detect when an administrator configurable positive integer
within 1 to 1558 unsuccessful authentication attempts occur related to
consecutive failed human user authentication for the PIN via VERIFY ,
ENABLE VERIFICATION REQUIREMENT, DISABLE
VERIFICATION, REQUIREMENT or CHANGE REFERENCE DATA
command.59.
FIA_AFL.1.2/PIN When the defined number of unsuccessful authentication attempts has
been met60, the TSF shall block the password for authentication until
successful unblock using command RESET RETRY COUNTER
(1) P1=’00’ or P1=’01’ with presenting unblocking code PUC of this
password object,
(2) P1=’02’ or P1=’03’ without presenting unblocking code PUC of this
password object61.
143 Application note 6: The component FIA_AFL.1/PIN addresses the human user authentication by
means of a password. The configurable positive integer of unsuccessful authentication attempts is
defined in the password objects of the object system. "Consecutive failed authentication attemps"
are counted separately for each PIN and interrupted by successful authentication attempt for this
PIN, i.e. the PIN object has a retryCounter wich is initially set to startRetryCounter, decremented
by each failed authentication attempt and reset to startRetryCounter by successful authentication
with the PIN or be successful execution of the command RESET RETRY COUNTER. The
command RESET RETRY COUNTER (CLA,INS,P1)=(00,2C,02) and
(CLA,INS,P1)=(00,2C,03) unblock the PIN without presenting unblocking code PUC of this
password object. In order to prevent bypass of the human user authentication defined by the PIN
or PUC the object system shall define access control to this command as required by the security
needs of the specific application context, cf. OE.Resp-ObjS.
144 The TOE shall meet the requirement “Authentication failure handling (FIA_AFL.1/PUC)” as
specified below.
FIA_AFL.1/PUC Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication.
FIA_AFL.1.1/PUC The TSF shall detect when an administrator configurable positive integer
within 1 to 1562 unsuccessful63 authentication attempts occur related to
58 [assignment: positive integer number], an administrator configurable positive integer within [assignment:
range of acceptable values]]
59 [assignment: list of authentication events]
60 [selection: met, surpassed]
61 [assignment: list of actions]
62 [assignment: positive integer number], an administrator configurable positive integer within [assignment:
range of acceptable values]]
63 Refinement: not only unsuccessful but all attempts shall be counted here – obviously this refinement is valid,
because the original requirement is still fulfilled.
6 Security Requirements
Page 58 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
usage of a password unblocking code using the RESET RETRY COUNTER
command.64.
FIA_AFL.1.2/PUC When the defined number of unsuccessful65 authentication attempts has
been met66, the TSF shall block the password unblocking code6768.
145 Application note 7: The component FIA_AFL.1/PUC addresses the human user authentication by
means of a PUC. The configurable positive integer of usage of password unblocking code is
defined in the password objects of the object system.
146 Application note 8: The command RESET RETRY COUNTER can be used to change a password or
reset a retry counter. In certain cases, for example for digital signature applications, the usage of
the command RESET RETRY COUNTER must be restricted to the ability to reset a retry counter
only.
147 The TOE shall meet the requirement “User attribute definition (FIA_ATD.1)” as specified below.
FIA_ATD.1 User attribute definition
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes
belonging to individual users:
(1) for Human User: authentication state gained
a. with password: pwIdentifier in globalPasswordList and
pwIdentifier in dfSpecificPasswordList,
b. with Multi-Reference password: pwIdentifier in
globalPasswordList and pwIdentifier in
dfSpecificPasswordList,
(2) for Device: authentication state gained
a. by CVC with CHA in globalSecurityList if CVC is stored
in MF and dfSpecificSecurityList if CVC is stored in a DF,
b. by CVC with CHAT in bitSecurityList,
c. with symmetric authentication key: keyIdentity of the key,
d. with secure messaging keys: keyIdentity of the key used
for establishing the session key69.
148 The TOE shall meet the requirement “Timing of authentication (FIA_UAU.1)” as specified
below.
FIA_UAU.1 Timing of authentication
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification.
64 [assignment: list of authentication events]
65 Refinement: not only unsuccessful but all attempts shall be counted here – obviously this refinement is valid,
because the original requirement is still fulfilled.
66 [selection: met, surpassed]
67 [assignment: list of actions, which at least includes: block the password unblocking code]
68 [assignment: list of actions]
69 [assignment: list of security attributes]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 59 of 134
FIA_UAU.1.1 The TSF shall allow
(1) reading the ATR,
(2) GET CHALLENGE, MANAGE CHANNEL, MANAGE SECURITY
ENVIRONMENT, SELECT70
(3) commands with access control rule ALWAYS for the current
life cycle status and depending on the interface,
(4) none71 72
on behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before
allowing any other TSF-mediated actions on behalf of that user.
149 The TOE shall meet the requirement “Single-use authentication mechanisms (FIA_UAU.4)” as
specified below.
FIA_UAU.4 Single-use authentication mechanisms
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to
(1) external device authentication by means of executing the
command EXTERNAL AUTHENTICATE with symmetric or
asymmetric key,
(2) external device authentication by means of executing the
command MUTUAL AUTHENTICATE with symmetric or
asymmetric key,
(3) external device authentication by means of executing the
command GENERAL AUTHENTICATE with symmetric or
asymmetric key.
(4) none73 74.
150 The TOE shall meet the requirement “Multiple authentication mechanisms (FIA_UAU.5)” as
specified below.
FIA_UAU.5 Multiple authentication mechanisms
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.5.1 The TSF shall provide
(1) the execution of the VERIFY command,
(2) the execution of the CHANGE REFERENCE DATA command,
(3) the execution of the RESET RETRY COUNTER command,
(4) the execution of the EXTERNAL AUTHENTICATE command,
(5) the execution of the MUTUAL AUTHENTICATE command,
70 [selection: GET CHALLENGE, MANAGE CHANNEL, MANAGE SECURITY ENVIRONMENT,
SELECT]
71 [assignment: list of additional TSF mediated actions]
72 [assignment: list of TSF mediated actions]
73 [assignment: additional identified authentication mechanism(s)]
74 [assignment: identified authentication mechanism(s)]
6 Security Requirements
Page 60 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
(6) the execution of the GENERAL AUTHENTICATE command,
(7) a secure messaging channel,
(8) a trusted channel75
to support user authentication.
FIA_UAU.5.2 THE TSF shall authenticate any user's claimed identity according to the
following rules:
(1) password based authentication shall be used for authenticating
a human user by means of commands VERIFY, CHANGE
REFERENCE DATA and RESET RETRY COUNTER,
(2) key based authentication mechanisms shall be used for
authenticating of devices by means of commands EXTERNAL
AUTHENTICATE, MUTUAL AUTHENTICATE and GENERAL
AUTHENTICATE,
(3) none76.
151 The TOE shall meet the requirement “Re-authenticating (FIA_UAU.6)” as specified below:.
FIA_UAU.6 Re-authenticating
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.6.1 The TSF shall re-authenticate the user sender of a message77 under the
conditions
(1) each command sent to the TOE after establishing the secure
messaging by successful authentication after execution of the
INTERNAL AUTHENTICATE and EXTERNAL AUTHENTICATE, or
MUTUAL AUTHENTICATE or GENERAL AUTHENTICATE
commands shall be verified as being sent by the authenticated
device78
.
152 Application note 9: The entities establishing a secure messaging channel respective a trusted
channel authenticate each other and agree symmetric session keys. The sender of a command
authenticates its message by MAC calculation for the command (cf. PSO COMPUTE
CRYPTOGRAPHIC CHECKSUM using SK4TC, cf. Package Crypto box) and the receiver of the
commands verifies the authentication by MAC verification of commands (using SK4SM). The
receiver of the commands authenticates its message by MAC calculation (using SK4SM) and the
sender of a command verifies the authentication by MAC verification of responses (cf. PSO
VERIFY CRYPTOGRAPHIC CHECKSUM using SK4TC). If secure messaging is used with encryption
the re-authentication includes the encrypted padding in the plaintext as authentication attempt of
the message sender (cf. PSO ENCIPHER for commands) and the receiver (cf. secure messaging for
responses) and verification of the correct padding as authentication verification by the message
receiver (cf. secure messaging for received commands and PSO DECIPHER for received
responses). The specification [21] states in section 13.1.2 item (N031.600): This re-authentication
is controlled by the external entity (e.g. the connector in the eHealth environment). If no Secure
75 [assignment: list of multiple authentication mechanisms]
76 [assignment: rules describing how the multiple authentication mechanisms provide authentication]
77 Refinement identifying the concrete user
78 [assignment: list of conditions under which re-authentication is required]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 61 of 134
Messaging is indicated in the CLA byte (see [ISO7816-4] Clause 5.1.1) and
SessionkeyContext.flagSessionEnabled has the value SK4SM, then the security status of the key
that was involved in the negotiation of the session keys MUST be deleted by means of
clearSessionKeys(...).” Furthermore item (N031.700) states that the security status of the key that
was involved in the negotiation of the session keys MUST be deleted by means of
clearSessionKeys(...) if the check of the command CMAC (cf. FCS_COP.1/COS.CMAC) or
Retail MAC (cf. FCS_COP.1/COS.RMAC) fails. The TOE does not execute any command with
incorrect message authentication code. The TOE checks each command by secure messaging in
encrypt-then-authenticate mode based on a MAC, whether it was sent by the successfully
authenticated communication partner. The TOE does not execute any command with incorrect
MAC. Therefore, the TOE re-authenticates the communication partner connected, if a secure
messaging error occurred, and accepts only those commands received from the initially
communication partner.
153 The TOE shall meet the requirement “Timing of identification (FIA_UID.1)” as specified below.
FIA_UID.1 Timing of identification
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UID.1.1 The TSF shall allow
(1) reading the ATR
(2) GET CHALLENGE, MANAGE CHANNEL, MANAGE SECURITY
ENVIRONMENT, SELECT79
(3) commands with access control rule ALWAYS for the current
life cycle status and depending on the interface,
(4) none 80
on behalf of the user to be performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
154 The TOE shall meet the requirement “Authentication Proof of Identity (FIA_API.1)” as specified
below (Common Criteria Part 2 extended (see section 5.1)).
FIA_API.1 Authentication Proof of Identity
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_API.1.1 The TSF shall provide
(1) INTERNAL AUTHENTICATE,
(2) MUTUAL AUTHENTICATE,
(3) GENERAL AUTHENTICATE,
to prove the identity of the TSF itself81 to an external entity.
155 The TOE shall meet the requirement “Security roles (FMT_SMR.1)” as specified below:
FMT_SMR.1 Security roles
79 [selection: GET CHALLENGE, MANAGE CHANNEL, MANAGE SECURITY ENVIRONMENT, SELECT]
80 [assignment: list of TSF mediated actions]
81 [assignment: authorized user or rule].
6 Security Requirements
Page 62 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1 The TSF shall maintain the roles
(1) World as unauthenticated user without authentication reference
data,
(2) Human User authenticated by password in the role defined for
this password,
(3) Human User authenticated by PUC as holder of the
corresponding password,
(4) Device authenticated by means of symmetric key in the role
defined for this key,
(5) Device authenticated by means of asymmetric key in the role
defined by the Certificate Holder Authorisation in the CVC,
(6) Personalisation Agent
(7) Initialisation Agent82.
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
156 Application note 10: The protection profile BSI-CC-PP-0035-2007 does not explicitly define role
because roles are linked to life cycle of the chip not addressed by SFR. Therefore the current ST
defines the role “World” relevant for all parts of the TOE (e.g. physical protection) and roles for
COS related SFR. The ST may add developer specific roles, e. g. for TSF data export according
to FPT_ITE.1/EXP.
157 Application note 11: Human users authenticate themselves by identifying the password or Multi-
reference password and providing authentication verification data to be matched to the secret of
the password object or PUC depending on the command used. The role gained by authorization
with a password is defined in the security attributes of the objects and related to identified
commands. The authorization status is valid for the same level and in the level below in the file
hierarchy as the password object is stored. The role gained by authentication with a symmetric
key is defined in the security attributes of the objects and related to identified commands. The
assignment may assign additional role like the role defined for authentication by means of PACE
protocol or “none”.
158 The TOE shall meet the requirement “User-subject binding (FIA_USB.1)” as specified below.
FIA_USB.1 User-subject binding
Hierarchical to: No other components.
Dependencies: FIA_ATD.1 User attribute definition
FIA_USB.1.1 The TSF shall associate the following user security attributes with
subjects acting on the behalf of that user:
(1) for Human User authenticated with password: pwIdentifier and
Authentication Context globalPasswordList and
dfSpecificPasswordList.
(2) for Human User authenticated with PUC: pwIdentifier of
corresponding password,
(3) for Device the Role authenticated by RSA based CVC : the
82 [assignment: the authorised identified roles].
Security Target Lite STARCOS 3.6 COSGKV C1 Page 63 of 134
Certificate Holder Authorisation (CHA) in the CVC
(4) for Device the Role authenticated by ECC based CVC: the
Certificate Holder Authorisation Template (CHAT),
(5) for Device the Role authenticated by symmetric key:
keyIdentifier and Authentication Context.83
FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of
user security attributes with subjects acting on the behalf of users:
(1) If the logical channel is reset by command Manage Channel
(INS,P1,P2)=(‘70’,’40’,’00’) the initial authentication state is
set to “not authenticated” (i.e. globalPasswordList,
dfSpecificPasswordList, globalSecurityList,
dfSpecificSecurityList and keyReferenceList are empty,
SessionkeyContext.flagSessionEnabled=noSK).
(2) If the command SELECT is executed and the newFile is a folder
the initial authentication state of the selected folder inherit the
authentication state of the folder above up the root.84
FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user
security attributes associated with subjects acting on the behalf of users:
(1) The authentication state is changed to “authenticated Human
User” for the specific context when the Human User has
successfully authenticated via one of the following procedures:
a) VERIFY command using the context specific password
or the context specific Multi-Reference password,
b) If the security attribute flagEnabled of password object
is set to False the authentication state for this specific
password is changed to “authenticated Human User”.
c) If the security attribute flagEnabled of Multi-Reference
password object is set to False the authentication state
for this specific Multi-Reference password is changed
to “authenticated Human User”.
(2) The authentication state is changed to “authenticated Device”
for the specific authentication context when a Device has
successfully authenticated via one of the following procedures:
a) EXTERNAL AUTHENTICATE with symmetric or public
keys,
b) MUTUAL AUTHENTICATE with symmetric or public
keys,
c) GENERAL AUTHENTICATE with mutual ELC
authentication and
d) GENERAL AUTHENTICATE for asynchronous secure
messaging
(3) The effective access rights gained by ECC based CVC: the
CHAT are the intersection of the access rights encoded in the
CHAT of the CVC chain used as authentication reference data
of the Device.
(4) All authentication contexts are lost and the authentication state
is set to “not authenticated” for all contexts if the TOE is reset.
83 [assignment: list of user security attributes]
84 [assignment: rules for the initial association of attributes]
6 Security Requirements
Page 64 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
(5) If a DELETE command is executed for a password object or
symmetric authentication key the entity is authenticated for the
authentication state has to be set to “not authenticated”. If a
DELETE command is executed for a folder (a) authentication
states gained by password objects in the deleted folder shall be
set to “notauthenticated” and (b) all entires in keyReferenceList
and allPublicKeyList related to the deleted folder shall be
removed.
(6) If an authentication attempt using one of the following
commands failed the authentication state for the specific context
has to be set to “not authenticated”: EXTERNAL AUTHENTICATE,
MUTUAL AUTHENTICATE, MANAGE SECURITY ENVIRONMENT
(variant with restore).
(7) If a context change by using the SELECT command is performed
the authentication state for all objects of the old authentication
context not belonging to the new context of the performed
SELECT command have to be set to “not authenticated”.
(8) If failure of secure messaging (not indicated in CLA-byte, or
erroneous MAC, or erroneous cryptogram) is detected the
authentication status of the device in the current context set to
“not authenticated” (i.e. the element in globalSecurityList
respective in dfSpecificSecurityList and the used SK4SM are
deleted).
(9) none85
159 Application note 12: Note the security attributes of the user are defined by the authentication
reference data. The user may chose security attributes of the subjects interface in the power on
session and seIdentifier by execution of command MANAGE SECURITY ENVIRONMENT for the
current directory. The initial authentication state is set when the command SELECT is executed
and the newFile is a folder (cf. [21], clause (N076.100) and (N048.200)).
6.1.6 Access Control
160 Application note 13: This section defines SFR for access control on User data in the object
system. The SFR FDP_ACF.1/ MF_DF, FDP_ACF.1/EF, FDP_ACF.1/TEF, FDP_ACF.1/SEF
and FDP_ACF.1/KEY describe the security attributes of the subject gaining access to these
objects. The COS specification [21] describes the attributes of logical channels (i.e. subjects in
CC terminology) which is valid for the core of COS including all packages. The
globalSecurityList and dfSpecificSecurityList contain all keyIdentifier used for successful device
authentications, i.e. the list may be empty, may contain a CHA, a key identifier of a symmetric
authentication key.
161 The TOE shall meet the requirement “Subset access control (FDP_ACC.1/ MF_DF)” as specified
below.
FDP_ACC.1/
MF_DF
Subset access control
85 [assignment: rules for the changing of attributes]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 65 of 134
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control.
FDP_ACC.1.1/
MF_DF
The TSF shall enforce the access control MF_DF SFP86 on
(1) the subjects logical channel bind to users
a. World,
b. Human User,
c. Device,
d. Human User and Device,
none87,
(2) the objects
a. all executable code implemented by the TOE,
b. MF,
c. Application,
d. Dedicated file,
e. Application dedicated file,
f. persistent stored public keys,
g. none88,
(3) the operation by command following
a. command SELECT,
b. create objects with command LOAD APPLICATION with and
without command chaining,
c. delete objects with command DELETE,
d. read fingerprint with command FINGERPRINT,
e. COMMAND LIST PUBLIC KEY,
f. none89.90
162 Application note 14: Note the commands ACTIVATE, DEACTIVATE and, TERMINATE DF for
current file applicable to MF, DF, Application and Application dedicated file manage the security
life cycle attributes. Therefore access control to theses commands are described by
FMT_MSA.1/Life. The object “all executable code implemented by the TOE” includes IC
Dedicated Support Software, the Card Operating System and application specific code loaded on
the smartcard by command LOAD CODE or any other means.
163 The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1/
MF_DF)” as specified below.
FDP_ACF.1/
MF_DF
Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1/
MF_DF
The TSF shall enforce the access control MF_DF SFP91 to objects based
on the following
86 [assignment: access control SFP]
87 [assignment: list of further subjects]
88 [assignment: list of further objects]
89 [assignment: all other operations applicable to MF and DF]
90 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
6 Security Requirements
Page 66 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
(1) the subject logical channel with security attributes
a. interface,
b. globalPasswordList,
c. globalSecurityList,
d. dfSpecificPasswordList,
e. dfSpecificSecurityList,
f. bitSecurityList,
g. SessionkeyContext,
h. none92
(2) the objects
a. all executable code implemented by the TOE,
b. MF with security attributes lifeCycleStatus, seIdentifier and
interfaceDependentAccessRules,
c. DF with security attributes lifeCycleStatus, seIdentifier and
interfaceDependentAccessRules,
d. Application with security attributes lifeCycleStatus,
seIdentifier and interfaceDependentAccessRules,
e. Application dedicated file with security attributes
lifeCycleStatus, seIdentifier and
interfaceDependentAccessRules,
f. persistent stored public keys,
g. none93 94
FDP_ACF.1.2/
MF_DF
The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
(1) SELECT is ALWAYS allowed 95.
(2) GET CHALLENGE is ALWAYS allowed96.
(3) A subject is allowed to create new objects (user data or TSF
data) in the current folder MF if the security attributes interface,
globalPasswordList, globalSecurityList and SessionkeyContext
of the subject meet the access rules for the command LOAD
APPLICATION of the MF dependent on lifeCycleStatus,
seIdentifier and interfaceDependentAccessRules.
(4) A subject is allowed to create new objects (user data or TSF
data) in the current folder Application, Dedicated file or
Application Dedicated file if the security attributes interface,
globalPasswordList, globalSecurityList,
dfSpecificPasswordList, dfSpecificSecurityList and
SessionkeyContext of the subject meet the access rules for the
command LOAD APPLICATION of this object dependent on
lifeCycleStatus, seIdentifier and
interfaceDependentAccessRules.
(5) A subject is allowed to DELETE objects in the current folder MF
91 [assignment: access control SFP]
92 [assignment: further subjects listed in FDP_ACC.1.1/MF_DF with their security attributes]
93 [assignment: list of further objects listed in FDP_ACC.1.1/MF_DF with their security attributes]
94 [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]
95 [selection:ALWAYS allowed, [assignment: supported access control rules]]
96 [selection:ALWAYS allowed, [assignment: supported access control rules]]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 67 of 134
if the security attributes interface, globalPasswordList,
globalSecurityList and SessionkeyContext of the subject meet
the access rules for the command DELETE of the MF dependent
on lifeCycleStatus, seIdentifier and
interfaceDependentAccessRules.
(6) A subject is allowed to DELETE objects in the current
Application, Dedicated file or Application, Dedicated file if the
security attributes interface, globalPasswordList,
globalSecurityList, SpecificPasswordList, dfSpecificSecurityList
and SessionkeyContext of the subject meet the access rules for
the command DELETE of this object dependent on
lifeCycleStatus, seIdentifier and
interfaceDependentAccessRules.
(7) A subject is allowed to read fingerprint according to FPT_ITE.1
if it is allowed to execute the command FINGERPRINT inthe
current folder 97.
(8) All subjects are allowed to execute command LIST PUBLIC
KEY to export all persistent stored public keys.
(9) none98
FDP_ACF.1.3/
MF_DF
The TSF shall explicitly authorise access of subjects to objects based on
the following additional rules: none99
FDP_ACF.1.4/
MF_DF
The TSF shall explicitly deny access of subjects to objects based on the
following additional rules: none100.
164 The TOE shall meet the requirement “Subset access control (FDP_ACC.1/EF)” as specified
below.
FDP_ACC.1/EF Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control.
FDP_ACC.1.1/EF The TSF shall enforce the access control EF SFP101 on
(1) the subjects logical channel bind to users
a. World,
b. Human User,
c. Device,
d. Human User and Device,
e. none102
(2) the objects
a. EF
b. Transparent EF
c. Structured EF
97 [assignment: list of security attributes of subjects]
98 [assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
99 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
100 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
101 [assignment: access control SFP]
102 [assignment: list of further subjects]
6 Security Requirements
Page 68 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
d. none103
(3) the operation by command following
a. SELECT
b. DELETE of the current file
c. CREATE104 105.
165 Application note 15: Note the commands ACTIVATE, DEACTIVATE and, TERMINATE DF
for current file applicable to EF, Transparent EF and Structured EF manage the security life cycle
attributes. Therefore access control to theses commands are described by FMT_MSA.1/Life. The
commands CREATE, GET DATA, GET RESPONSE and PUT DATA are optional. If implemented by
the TOE these commands shall be added to the corresponding FDP_ACC.1 and FDP_ACF.1
SFR. The commands specific for transparent files are described in FDP_ACC.1/TEF and
FDP_ACF.1/TEF SFR. The commands specific for structured files are described in
FDP_ACC.1/SEF and FDP_ACF.1/SEF SFR.
166 The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1/EF)”
as specified below.
FDP_ACF.1/EF Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1/EF The TSF shall enforce the access rule EF SFP106 to objects based on the
following
(1) the subject logical channel with security attributes
a. interface,
b. globalPasswordList,
c. globalSecurityList,
d. dfSpecificPasswordList,
e. dfSpecificSecurityList
f. bitSecurityList,
g. SessionkeyContext,
h. none107
(2) the objects
a. EF with security attributes seIdentifier of the current folder,
lifeCycleStatus and interfaceDependentAccessRules of the
EF, and none108,
b. none109 110
FDP_ACF.1.2/EF The TSF shall enforce the following rules to determine if an operation
103 [assignment: list of further objects]
104 [assignment: further operations]
105 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
106 [assignment: access control SFP]
107 [assignment: further subjects listed in FDP_ACC.1.1/EF]
108 [selection: transaction protection Mode, checksum]
109 [assignment: list of further objects listed in FDP_ACC.1.1/EF with their security attributes]
110 [assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 69 of 134
among controlled subjects and controlled objects is allowed:
(1) SELECT isALWAYS allowed.111
(2) A subject is allowed to DELETE the current EF if the security
attributes interface, globalPasswordList, globalSecurityList,
dfSpecificPasswordList and SessionkeyContext of the subject
meet the access rules for the command DELETE of this object
dependent on lifeCycleStatus, interfaceDependentAccessRules
and seIdentifier of the current folder.
(3) none112 113
FDP_ACF.1.3/EF The TSF shall explicitly authorise access of subjects to objects based on
the following additional rules: none114.
FDP_ACF.1.4/EF The TSF shall explicitly deny access of subjects to objects based on the
following additional rules: none115
167 Application note 16: The EF stands here for transparent EF and structured EF, which access
control is further refined by FDP_ACF.1/TEF and FDP_ACF.1/SEF. The selection of
“transaction protection Mode” and “checksum” may be empty because they are optional in the
COS specification [21].
168 The TOE shall meet the requirement “Subset access control (FDP_ACC.1/TEF)” as specified
below.
FDP_ACC.1/TEF Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control.
FDP_ACC.1.1/TEF The TSF shall enforce the access rule TEF SFP116 on
(1) the subjects logical channel bind to users
a. World,
b. Human User
c. Device
d. Human User and Device,
e. none117
(2) the objects
a. Transparent EF,
b. none118
(3) the operation by the following command
a. ERASE BINARY
b. READ BINARY
c. SET LOGICAL EOF,
111 [selection:ALWAYS allowed, [assignment: supported access control rules]].
112 [assignment: further list of subjects, objects, and operations among subjects and objects covered by the SFP]
113 [assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
114 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
115 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
116 [assignment: access control SFP]
117 [assignment: further subjects]
118 [assignment: list of further objects]
6 Security Requirements
Page 70 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
d. UPDATE BINARY
e. WRITE BINARY
f. none119 120.
169 The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1/TEF)”
as specified below.
FDP_ACF.1/TEF Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1/TEF The TSF shall enforce the access rule TEF SFP121 to objects based on
the following
(1) the subjects logical channel with security attributes
a. interface,
b. globalPasswordList,
c. globalSecurityList,
d. dfSpecificPasswordList,dfSpecificSecurityList,
e. bitSecurityList,
f. SessionkeyContext,
a. none122
(2) the objects
a. with security attributes seIdentifier of the current folder,
lifeCycleStatus and interfaceDependentAccessRules of the
current Transparent EF, and none123,
b. none124 125
FDP_ACF.1.2/TEF The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
(1) The subject is allowed to execute the command listed in
FDP_ACC.1.1/TEF for the current Transparent EF if the
security attributes interface, globalPasswordList,
globalSecurityList, dfSpecificPasswordList,
dfSpecificSecurityList and SessionkeyContext of the subject
meet the access rules of this object for this command dependent
on seIdentifier of the current folder, lifeCycleStatus and
interfaceDependentAccessRules of the current Transparent EF.
(2) none126 127
.
FDP_ACF.1.3/TEF The TSF shall explicitly authorise access of subjects to objects based on
119 [assignment: further operation]
120 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
121 [assignment: access control SFP]
122 [assignment: further subjects listed in FDP_ACC.1.1/TEF]
123 [selection: transaction protection Mode, checksum]
124 [assignment: list of further objects listed in FDP_ACC.1.1/TEF]
125 [assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
126 [assignment: further list of subjects, objects, and operations among subjects and objects covered by the SFP]
127 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 71 of 134
the following additional rules: none128.
FDP_ACF.1.4/TEF The TSF shall explicitly deny access of subjects to objects based on the
following additional rules: Rules defined in FDP_ACF.1.4/EF apply ,
and none129 130.
170 The TOE shall meet the requirement “Subset access control (FDP_ACC.1/SEF)” as specified
below.
FDP_ACC.1/SEF Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control.
FDP_ACC.1.1/
SEF
The TSF shall enforce the access rule SEF SFP131 on
(1) the subjects logical channel bind to users
a. World,
b. Human User
c. Device
d. Human User and Device,
e. none132
(2) the objects
a. record in Structured EF
b. none133
(3) the operation by command following
a. Append Record
b. Erase Record
c. Delete Record
d. Read Record
e. Search Record
f. Update Record
g. none134 135.
171 The command WRITE RECORD is optional. If implemented by the TOE this command shall be
added to the corresponding FDP_ACC.1/SEF and FDP_ACF.1/SEF SFR.
172 The TOE shall meet the requirement “Security attribute based access control (FDP_ACF.1/SEF)”
as specified below.
FDP_ACF.1/SEF Security attribute based access control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
128 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
129 [assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects]
130 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
131 [assignment: access control SFP]
132 [assignment: further subjects]
133 [assignment: list of further objects]
134 [assignment: further operation]
135 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
6 Security Requirements
Page 72 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
FDP_ACF.1.1/SEF The TSF shall enforce the access rule SEF SFP136 to objects based on
the following
(1) the subjects logical channel with security attributes
a. interface,
b. globalPasswordList,
c. globalSecurityList,
d. dfSpecificPasswordList,
e. dfSpecificSecurityList,
f. bitSecurityList,
g. SessionkeyContext,
h. none137
(2) the objects
a. with security attributes seIdentifier of the current folder,
lifeCycleStatus and interfaceDependentAccessRules of the
current Structured EF, and lifeCycleStatus of the record,
b. none138 139
FDP_ACF.1.2/SEF The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
(1) The subject is allowed to execute the command listed in
FDP_ACC.1.1/SEF for the record of the current Structered EF if
the security attributes interface, globalPasswordList,
globalSecurityList, dfSpecificPasswordList,
dfSpecificSecurityList and SessionkeyContext of the subject
meet the access rules of this object for this command dependent
on seIdentifier of the current folder, lifeCycleStatus and
interfaceDependentAccessRules of the current Structered EF,
and lifeCycleStatus of the record.
(2) none140
.
FDP_ACF.1.3/SEF The TSF shall explicitly authorise access of subjects to objects based on
the following additional rules: none.141.
FDP_ACF.1.4/SEF The TSF shall explicitly deny access of subjects to objects based on the
following additional rules: Rules defined in FDP_ACF.1.4/EF apply ,
and none142
.
173 Application note 17: Keys can be TSF or user data. As SFR FDP_ACC.1/KEY and
FDP_ACF.1/KEY address protection of user data the keys defined in these SFR as objects are
user keys only. Keys used for authentication are TSF data and are therefore not in the scope of
these two SFR. Please note that the PSO ENCIPHER, PSO DECIPHER, PSO COMPUTE
CRYPTOGRAPHIC CHECKSUM, and PSO VERIFY CRYPTOGRAPHIC CHECKSUM are used with the
136 [assignment: access control SFP]
137 [assignment: further subjects listed in FDP_ACC.1.1/SEF]
138 [assignment: list of further objects listed in FDP_ACC.1.1/SEF
139 [assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
140 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
141 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
142 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 73 of 134
SK4TC for trusted channel. If these commands are used in the context trusted channel the key
used is TSF data and not user data. Therefore the SFR FDP_ACC.1/KEY and FDP_ACF.1/KEY
are not applicable on the commands used for trusted channel.
174 The TOE shall meet the requirement “Subset access control (FDP_ACC.1/KEY)” as specified
below.
FDP_ACC.1/KEY Subset access control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control.
FDP_ACC.1.1/KEY The TSF shall enforce the SFP access control key SFP143 on
(1) the subjects logical channel bind to users
a. World,
b. Human User
c. Device
d. Human User and Device,
e. none144
(2) the objects
a. symmetric key used for user data,
b. private asymmetric key used for user data,
c. public asymmetric key for signature verification used for
user data,
d. public asymmetric key for encryption used for user data,
e. ephemeral keys used during Diffie-Hellmann key
exchange,
f. none145
(3) the operation by command following
a. DELETE for private, public and symmetric key objects,
b. MANAGE SECURITY ENVIRONMENT,
c. GENERATE ASYMMETRIC KEY PAIR,
d. PSO COMPUTE DIGITAL SIGNATURE,
e. PSO VERIFY DIGITAL SIGNATURE,
f. PSO VERIFY CERTIFICATE,
g. PSO COMPUTE CRYPTOGRAPHIC CHECKSUM,
h. PSO VERIFY CRYPTOGRAPHIC CHECKSUM,
i. PSO ENCIPHER,
j. PSO DECIPHER,
k. PSO TRANSCIPHER,
l. none146 147.
175 The TOE shall meet the requirement “Security attribute based access control
(FDP_ACF.1/KEY)” as specified below.
FDP_ACF.1/KEY Security attribute based access control
Hierarchical to: No other components.
143 [assignment: access control SFP]
144 [assignment: further subjects]
145 [assignment: list of further objects]
146 [assignment: further operation]
147 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
6 Security Requirements
Page 74 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1/KEY The TSF shall enforce the access control key SFP148 to objects based on
the following
(1) the subjects logical channel with security attributes
a. interface,
b. globalPasswordList,
c. globalSecurityList,
d. dfSpecificPaswordList,
e. dfSpecificSecurityList,
f. bitSecurityList,
g. SessionkeyContext,
h. none149
(2) the objects
a. symmetric key used for user data with security attributes
seIdentifier of the current folder, lifeCycleStatus and
interfaceDependentAccessRules, the key type (encryption
key or mac key), interfaceDependentAccessRules for
session keys
b. private asymmetric key used for user data with security
attributes seIdentifier of the current folder, lifeCycleStatus,
keyAvailable and interfaceDependentAccessRules,
c. public asymmetric key for signature verification used for
user data with security attributes seIdentifier of the current
folder, lifeCycleStatus and interfaceDependentAccessRules,
d. public asymmetric key for encryption used for user data
with security attributes seIdentifier of the current folder,
lifeCycleStatus and interfaceDependentAccessRules,
e. CVC with security attributes certificate content and
signature,
f. ephemeral keys used during Diffie-Hellmann key exchange
g. none
150 151
FDP_ACF.1.2/KEY The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
(1) MANAGE SECURITY ENVIRONMENT is ALWAYS allowed152in
cases defined in FDP_ACF.1.4/KEY.
(2) A subject is allowed to DELETE an object listed in
FDP_ACF.1.1/KEY if the security attributes interface,
globalPasswordList, globalSecurityList, ,
dfSpecificPasswordList, dfSpecificSecurityListand
SessionkeyContext of the subject meet the access rules for the
command DELETE of this object dependent on seIdentifier of the
current folder, lifeCycleStatus and
interfaceDependentAccessRules,
148 [assignment: access control SFP]
149 [assignment: further subjects listed in FDP_ACC.1.1/KEY]
150 [assignment: list of further objects listed in FDP_ACC.1.1/KEY]
151 [assignment: rules governing access among controlled subjects and controlled objects using controlled
operations on controlled objects]
152 [selection:ALWAYS allowed, [assignment: supported access control rules]]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 75 of 134
(3) A subject is allowed to generate a new asymmetric key pair or
change the content of existing objects if the security attributes
interface, globalPasswordList, globalSecurityList,
dfSpecificPasswordList, dfSpecificSecurityListand
SessionkeyContext of the subject meet the access rules for the
command GENERATE ASYMMETRIC KEY PAIR of this object
dependent on seIdentifier of the current folder, lifeCycleStatus,
key type and interfaceDependentAccessRules. In case P1=’80’
or P1 = ‘84’ the security attribute keyAvaliable must be set to
FALSE.
(4) A subject is allowed to import a public key as part of a CVC by
means of the command PSO VERIFY CERTIFICATE if
a) the security attributes interface,
globalPasswordList, globalSecurityList,
dfSpecificPassworldList,
dfSpecificSecurityListand SessionkeyContext
of the subject meet the access rules for the
command PSO VERIFY CERTIFICATE of
the signature public key to be used for
verification of the signature of the CVC
dependent on seIdentifier of the current
folder, lifeCycleStatus, key type and
interfaceDependentAccessRules,
b) the CVC has valid certificate content and
signature, where the expiration date is
checked against poinmtInTime.
(5) A subject is allowed to compute digital signatures using the
private asymmetric key for user data if the security attributes
interface, globalPasswordList, globalSecurityList,
dfSpecificPasswordList, dfSpecificSecurityList and
SessionkeyContext of the subject meet the access rules for the
command PSO COMPUTE DIGITAL SIGNATURE of this object
dependent on seIdentifier of the current folder, lifeCycleStatus,
the key type and interfaceDependentAccessRules.
(6) Any subject is allowed to verify digital signatures using the
public asymmetric key for user data using the command PSO
VERIFY DIGITAL SIGNATURE
(7) Any subject is allowed to compute a cryptographic checksum
with a symmetric key used for user data if the security attributes
interface, globalPasswordList, globalSecurityList,
dfSpecificPasswordList, dfSpecificSecurityListand
SessionkeyContext of the subject meet the access rules for using
the command PSO COMPUTE CRYPTOGRAPHIC CHECKSUM of
this object dependent on seIdentifier of the current folder,
lifeCycleStatus, the key type and
interfaceDependentAccessRules.
(8) A subject is allowed to verify a cryptographic checksum with a
symmetric key used for user data if the security attributes
interface, globalPasswordList, globalSecurityList,
SpecificPasswordList, dfSpecificSecurityListand
SessionkeyContext of the subject meet the access rules for the
command PSO VERIFY CRYPTOGRAPHIC CHECKSUM of this
object dependent on seIdentifier of the current folder,
6 Security Requirements
Page 76 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
lifeCycleStatus, the key type and
interfaceDependentAccessRules.
(9) A subject is allowed to decrypt and to encrypt user data using
the asymmetric key if the security attributes interface,
dfSpecificPasswordList, globalSecurityList,
dfSpecificSecurityList and SessionkeyContext of the subject
meet the access rules for the command PSO ENCIPHER of this
object dependent on seIdentifier of the current folder,
lifeCycleStatus, the key type and
interfaceDependentAccessRules.
(10) A subject is allowed decrypt user data using the
asymmetric key if the security attributes interface,
dfSpecificPasswordList, globalPasswordList,
globalSecurityList, dfSpecificSecurityListand SessionkeyContext
of the subject meet the access rules for the command PSO
DECIPHER of this object dependent on seIdentifier of the current
folder, lifeCycleStatus, the key type and
interfaceDependentAccessRules.
(11) A subject is allowed decrypt and to encrypt user data
using the asymmetric keys if the security attributes interface,
dfSpecificPasswordList, globalPasswordList,
globalSecurityList, dfSpecificSecurityListand SessionkeyContext
of the subject meet the access rules for the command PSO
TRANSCIPHER of both keys dependent on seIdentifier of the
current folder, lifeCycleStatus, the key type and
interfaceDependentAccessRules.
(12) none153.
FDP_ACF.1.3/KEY The TSF shall explicitly authorise access of subjects to objects based on
the following additional rules: none.154.
FDP_ACF.1.4/KEY The TSF shall explicitly deny access of subjects to objects based on the
following additional rules
(1) If the security attribute keyAvailable=TRUE the TSF shall prevent
generation of a private key by means of the command GENERATE
ASYMMETRIC KEY PAIR with P1=’80’ or P1=’84.
(2) none155156.
176 The TOE shall meet the requirement “Specification of Management Functions (FMT_SMF.1)” as
specified below.
FMT_SMF.1 Specification of Management Functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions:
(1) Initialization,
153 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
154 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
155 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
156 [assignment: rules, based on security attributes, that explicitly deny access subjects to objects]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 77 of 134
(2) Personalization,
(3) Life Cycle Management by means of commands GENERATE
ASYMMETRIC KEY PAIR, DELETE, LOAD APPLICATION,
TERMINATE, TERMINATE DF, TERMINATE CARD USAGE,
CREATE157
(4) Management of access control security attributes by means of
commands ACTIVATE, DEACTIVATE, ACTIVATE RECORD,
DEACTIVATE RECORD, ENABLE VERIFICATION REQUIREMENT,
DISABLE VERIFICATION REQUIREMENT, LOAD APPLICATION,
(5) Management of password objects attributes by means of commands
CHANGE REFERENCE DATA, RESET RETRY COUNTER, GET PIN
STATUS, VERIFY, LOAD APPLICATION
(6) Management of device authentication reference data by means of
commands PSO VERIFY CERTIFICATE, GET SECURITY STATUS KEY,
LOAD APPLICATION.
(7) None158
177 Application note 18: The protection profile BSI-CC-PP-0035-2007 [11] describes initialisation
and personalisation as management functions. This ST assigns the COS commands dedicated for
these management functions.
178 Application note 19: LOAD APPLICATION creates new objects together with their TSF data (cf.
FMT_MSA.1/Life). In case of folders this includes authentication reference data as passwords
and public keys. CREATE is an optional command which is implemented in the TOE. This ST lists
it to the commands for the Life Cycle Management listed in FMT_SMF.1 and FMT_MSA.1/Life
if implemented.
179 The TOE shall meet the requirement “Management of security attributes (FMT_MSA.1/Life)” as
specified below.
FMT_MSA.1/Life Management of security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1/Life The TSF shall enforce the access control MF_DF SFP, access control
EF_SFP, access rule TEF_SFP, access rule SEF_SFP and access
control key SFP159 to restrict the ability to
(1) create160 all security attributes of the new object 161 to subjects
allowed execution of command CREATE and LOAD
APPLICATION for the MF, DF, Application or Application
dedicated file where the new object is created162,
157 [assignment: list of further management functions to be provided by the TSF]
158 [assignment: list of management functions to be provided by the TSF]
159 [assignment: access control SFP(s), information flow control SFP(s)]
160 [selection: change_default, query, modify, delete, [assignment: other operations]]
161 [assignment: list of security attributes]
162 [assignment: the authorised identified roles]
6 Security Requirements
Page 78 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
(2) change163 security attributes of the object MF, DF,
Application, Application dedicated file, EF, TEF and
SEF164 by means of command LOAD APPLICATION
to none165
(3) change166 the security attributes lifeCycleStatus to
„Operational state (active)“167 to subjects allowed execution
of command ACTIVATE for the selected object168,
(4) change169 the security attributes lifeCycleStatus to
„Operational state (deactivated)“170 to subjects allowed
execution of command DEACTIVATE for the selected
object171,
(5) change172 the security attributes lifeCycleStatus to
„Termination state”173 to subjects allowed execution of
command TERMINATE for the selected EF, the key object
or the password object174,
(6) change175 the security attributes lifeCycleStatus to
„Termination state”176 to subjects allowed execution of
command TERMINATE DF for the selected DF, Application
or Application File177,
(7) change178the security attributes lifeCycleStatus to
„Termination state”179 to subjects allowed execution of
command TERMINATE CARD USAGE180,
(8) query the security attributes lifeCycleStatus to by means of
command SELECT to ALWAYS allowed181
163 [selection: change_default, query, modify, delete, [assignment: other operations]]
164 [assignment: list of security attributes]
165 [selection: none, subjects allowed execution of command LOAD APPLICATION for theMF, DF,
Application, Application dedicated file where the object is updated]
166 [selection: change_default, query, modify, delete, [assignment: other operations]]
167 [assignment: list of security attributes]
168 [assignment: the authorised identified roles]
169 [selection: change_default, query, modify, delete, [assignment: other operations]]
170 [assignment: list of security attributes]
171 [assignment: the authorised identified roles]
172 [selection: change_default, query, modify, delete, [assignment: other operations]]
173 [assignment: list of security attributes]
174 [assignment: the authorised identified roles]
175 [selection: change_default, query, modify, delete, [assignment: other operations]]
176 [assignment: list of security attributes]
177 [assignment: the authorised identified roles]
178 [selection: change_default, query, modify, delete, [assignment: other operations]]
179 [assignment: list of security attributes]
180 [assignment: the authorised identified roles]
181 [selection:ALWAYS allowed, [assignment: supported access control rules]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 79 of 134
(9) delete182 all security attributes of the selected object183 to
subjects allowed execution of command DELETE for the
selected object184 to none185.
The subject logical channel is allowed to execute a command if the
security attributes interface, globalPasswordList, globalSecurityList,
dfSpecificPasswordList, dfSpecificSecurityList, bitSecurityList
SessionkeyContext of the subject meet the security attributes
lifeCycleStatus, seIdentifier and interfaceDependentAccessRules of
the affected object.
180 Application note 20: The refinements repeat the structure of the element in order to avoid iteration
of the same SFR.
181 The TOE shall meet the requirement “Management of security attributes
(FMT_MSA.1/SEFSEF)” as specified below.
FMT_MSA.1/SEF Management of security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1/SEF The TSF shall enforce the access control SEF SFP186 to restrict the
ability to
(1) change187 the security attributes lifeCycleStatus of the selected
record to „Operational state (active)“188 to subjects allowed to execute
the command ACTIVATE RECORD189
(2) change190 the security attributes lifeCycleStatus of the selected
record to „Operational state (deactived)“191 to subjects allowed to
execute the command DEACTIVATE RECORD192,
(3) delete193 all security attributes of the selected record194 to subjects
allowed to execute the command DELETE RECORD195,
182 [selection: change_default, query, modify, delete, [assignment: other operations]]
183 [assignment: list of security attributes]
184 [assignment: the authorised identified roles]
185 [assignment: list of further security attributes with the authorised identified roles]
186 [assignment: access control SFP(s), information flow control SFP(s)]
187 [selection: change_default, query, modify, delete, [assignment: other operations]]
188 [assignment: list of security attributes]
189 [assignment: the authorised identified roles]
190 [selection: change_default, query, modify, delete, [assignment: other operations]]
191 [assignment: list of security attributes]
192 [assignment: the authorised identified roles]
197 [assignment: access control SFP, information flow control SFP]
197 [assignment: access control SFP, information flow control SFP]
6 Security Requirements
Page 80 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
(4) none196
The subject logical channel is allowed to execute a command if the
security attributes interface, globalPasswordList, globalSecurityList,
dfSpecificPasswordList, dfSpecificSecurityList, bitSecurityList
SessionkeyContext of the subject meet the security attributes
lifeCycleStatus, seIdentifier and interfaceDependentAccessRules of
the affected object.
182 Application note 21: The access rights can be described in FMT_MSA.1/SEF in more detail. The
“authorised identified roles” could therefore be interpreted in a wider scope including the context
where the command is allowed to be executed. The refinements repeat the structure of the
element in order to avoid iteration of the same SFR.
183 The TOE shall meet the requirement “Static attribute initialisation (FMT_MSA.3)” as specified
below.
FMT_MSA.3 Static attribute initialisation
Hierarchical to: No other components.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
FMT_MSA.3.1 The TSF shall enforce the access control MF_DF_SFP, access control
EF_SFP, access rule TEF_SFP, access rule SEF_SFP and access control
key SFP197 to provide restrictive198 default values for security attributes
that are used to enforce the SFP. After reset the security attributes of
the subject are set as follows
(1) currentFolder is root,
(2) keyReferenceList, globalSecurityList, globalPasswordList,
dfSpecificSecurityList, dfSpecificPasswordList bitSecurityList
are empty,
(3) SessionkeyContext.flagSessionEnabled is set to noSK,
(4) seIdentifier is #1,
(5) currentFile is undefined.
FMT_MSA.3.2 The TSF shall allow the subjects allowed to execute the command LOAD
APPLICATION199 to specify alternative initial values to override the
default values when an object or information is created.
184 Application note 22: The refinements provide rules for setting restrictive security attributes after
reset.
185 The TOE shall meet the requirement “Management of TSF data - PIN (FMT_MTD.1/PIN)” as
specified below.
197 [assignment: access control SFP, information flow control SFP]
197 [assignment: access control SFP, information flow control SFP]
197 [assignment: access control SFP, information flow control SFP]
198 [selection, choose one of: restrictive, permissive, [assignment: other property]]
199 [assignment: the authorised identified roles]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 81 of 134
FMT_MTD.1/PIN Management of TSF data - PIN
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1/PIN The TSF shall restrict the ability to
(1)set new secret of the password objects by means of command
CHANGE REFERENCE DATA with (CLA,INS,P1)=(00,24,00)200 201
to subjects successful authenticated with the old secret of this
password object202,
(2)set new secret and change transportStatus to regular Password
of the password objects with transportStatus equal to Leer-
PIN203 204 to subject to execute the command CHANGE
REFERENCE DATA with (CLA,INS,P1)=(00,24,01)205,
(3)set new secret of the password objects by means of command
RESET RETRY COUNTER with (CLA,INS,P1)=(00,2C,00)206 207
to subjects successful authenticated with the PUC of this
password object 208
(4)set new secret of the password objects by means of command
RESET RETRY COUNTER with (CLA,INS,P1)=(00,2C,02)209 210
to subject to execute the command RESET RETRY DATA
with (CLA,INS,P1)=(00,2C,02)211.
186 Application note 23: The TOE provides access control to the commands depending on the object
system. The refinements repeat the structure of the element in order to avoid iteration of the same
SFR. The commands CHANGE REFERENCE DATA (CLA,INS,P1)=(00,24,01) and RESET
RETRY COUNTER (CLA,INS,P1)=(00,2C,02) set a new password without need of
authentication by PIN or PUC. In order to prevent bypass of the human user authentication
defined by the PIN or PUC the object system shall define access control to this command as
required by the security needs of the specific application context, cf. OE.Resp-ObjS.
187 The TOE shall meet the requirement “Management of security attributes - PIN
(FMT_MSA.1/PIN)” as specified below.
FMT_MSA.1/PIN Management of security attributes - PIN
Hierarchical to: No other components.
200 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
201 [assignment: other operations]
202 [assignment: the authorised identified roles]
203 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
204 [assignment: other operations]
205 [assignment: the authorised identified roles]
206 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
207 [assignment: other operations]
208 [assignment: the authorised identified roles]
209 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
210 [assignment: other operations]
211 [assignment: the authorised identified roles]
6 Security Requirements
Page 82 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1/PIN The TSF shall enforce the access control MF_DF SFP, access control
EF_SFP, access control TEF_SFP, access control SEF_SFP and access
control key SFP212 to restrict the ability to
(1) reset by means of commands VERIFY213 214 the security attribute
retry counter of password objects215 to subjects successful
authenticated with the secret of this password object 216,
(2) reset by means of commands CHANGE REFERENCE DATA
with (CLA,INS,P1)=(00,24,00)217 218 the security attribute
retry counter of password objects 219 to subjects successful
authenticated with the old secret of this password object 220,
(3) change by means of commands CHANGE REFERENCE
DATA with (CLA,INS,P1)=(00,24,00)221 222 the security
attribute transportStatus from Transport-PIN to
regularPassword to subjects allowed to execute the
command CHANGE REFERENCE DATA with
(CLA,INS,P1)=(00,24,00)223
(4) change by means of commands CHANGE REFERENCE
DATA with (CLA,INS,P1)=(00,24,01)224 225the security
attribute transportStatus from Leer-PIN to
regularPassword to subjects allowed to execute the
command CHANGE REFERENCE DATA with
(CLA,INS,P1)=(00,24,01)226,
(5) reset by means of commands DISABLE VERIFICATION
REQUIREMENT with (CLA,INS,P1)=(00,26,00)227 228 the
212 [assignment: access control SFP(s), information flow control SFP(s)]
213 [assignment: other operations]
214 [selection: change_default, query, modify, delete, [assignment: other operations]]
215 [assignment: list of security attributes]
216 [assignment: the authorised identified roles]
217 [assignment: other operations]
218 [selection: change_default, query, modify, delete, [assignment: other operations]]
219 [assignment: list of security attributes]
220 [assignment: the authorised identified roles]
221 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
222 [assignment: other operations]
223 [assignment: the authorised identified roles]
224 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
225 [assignment: other operations]
226 [assignment: the authorised identified roles]
227 [assignment: other operations]
228 [selection: change_default, query, modify, delete, [assignment: other operations]]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 83 of 134
security attribute retry counter of password objects229 to
subjects successful authenticated with the old secret of this
password object230,
(6) reset by means of commands ENABLE VERIFICATION
REQUIREMENT with (CLA,INS,P1)=(00,28,00)231 232 the
security attribute retry counter of password objects233 to
subjects successful authenticated with the old secret of this
password object234,
(7) reset by means of command RESET RETRY COUNTER with
(CLA,INS,P1)=(00,2C, 00) or (CLA,INS,P1)=(00,2C,01)235
236 the security attribute retry counter of password objects
237 to subjects successful authenticated with the PUC of this
password object 238,
(8) reset by means of command RESET RETRY COUNTER with
(CLA,INS,P1)=(00,2C,02) or (CLA,INS,P1)=(00,2C,03)239
240 the security attribute retry counter of password objects
241to subjects allowed to execute the command RESET
RETRY COUNTER with (CLA,INS,P1)=(00,2C,02) or
(CLA,INS,P1)=(00,2C,03)242,
(9) query by means of command GET PIN STATUS243 244 the
security attribute flagEnabled, retry
counter,transportStatus245 to World246.
(10) enable247 the security attributes flagEnabled requiring
authentication with the selected password248 to subjects
authenticated with password and allowed to execute the
229 [assignment: list of security attributes]
230 [assignment: the authorised identified roles]
231 [assignment: other operations]
232 [selection: change_default, query, modify, delete, [assignment: other operations]]
233 [assignment: list of security attributes]
234 [assignment: the authorised identified roles]
235 [assignment: other operations]
236 [selection: change_default, query, modify, delete, [assignment: other operations]]
237 [assignment: list of security attributes]
238 [assignment: the authorised identified roles]
239 [assignment: other operations]
240 [selection: change_default, query, modify, delete, [assignment: other operations]]
241 [assignment: list of security attributes]
242 [assignment: the authorised identified roles]
243 [assignment: other operations]
244 [selection: change_default, query, modify, delete, [assignment: other operations]]
245 [assignment: list of security attributes]
246 [assignment: the authorised identified roles]
247 [assignment: list of security attributes]
248 [assignment: list of security attributes]
6 Security Requirements
Page 84 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
command ENABLE VERIFICATION REQUIREMENT
(CLA,INS,P1)=(00,28,00)249,
(11) enable250 the security attributes flagEnabled
requiring authentication with the selected password251 to
subjects allowed to execute the command ENABLE
VERIFICATION REQUIREMENT
(CLA,INS,P1)=(00,28,01)252.
(12) disable253 the security attributes flagEnabled
requiring authentication with the selected password254 to
subjects authenticated with password and allowed to
execute the command DISABLE VERIFICATION
REQUIREMENT (CLA,INS,P1)=(00,26,00)255.
(13) disable256 the security attributes flagEnabled
requiring authentication with the selected password257 to
subjects allowed to execute the command DISABLE
VERIFICATION REQUIREMENT
(CLA,INS,P1)=(00,26,01)258
188 Application note 24: The TOE provides access control to the commands depending on the object
system. The refinements repeat the structure of the element in order to avoid iteration of the same
SFR. The command DISABLE VERIFICATION REQUIREMENT can be used to disable the
need to perform successful authentication via the selected password or Multi-Reference
password, i.e. any authentication attempt will be successful. The command ENABLE
VERIFICATION REQUIREMENT can be used to enable the need to perform an authentication.
The access rights to execute these commands can be limited to specific authenticated subjects.
For example: the execution of DISABLE VERIFICATION REQUIREMENT should not be
allowed for signing applications. The command DISABLE VERIFICATION REQUIREMENT
(CLA,INS,P1)=(00,26,01) allows anybody to disable the verification requirement with the PIN.
In order to prevent bypass of the human user authentication defined by the PIN the object system
shall define access control to this command as required by the security needs of the specific
application context, cf. OE.Resp-ObjS. The command ENABLE VERIFICATION
REQUIREMENT (CLA,INS,P1)=(00,28,01) allows anybody to enable the verification
requirement with the PIN and therefore the object system shall define access control to this
command according to the intended security policy of the application, cf. OE.Resp-ObjS.
249 [assignment: the authorised identified roles]
250 [selection: change_default, query, modify, delete, [assignment: other operations]]
251 [assignment: list of security attributes]
252 [assignment: the authorised identified roles]
253 [selection: change_default, query, modify, delete, [assignment: other operations]]
254 [assignment: list of security attributes]
255 [assignment: the authorised identified roles]
256 [selection: change_default, query, modify, delete, [assignment: other operations]]
257 [assignment: list of security attributes]
258 [assignment: the authorised identified roles]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 85 of 134
189 The TOE shall meet the requirement “Management of TSF data – Authentication data
(FMT_MTD.1/Auth)” as specified below.
FMT_MTD.1/Auth Management of TSF data – Authentication data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1/Auth The TSF shall restrict the ability to
(1)import by means of commands LOAD APPLICATION259 the root
public keys to roles autorized to execute this command260,
(2)import by means of commands PSO VERIFY CERTIFICATE261
the root public keys to roles autorized to execute this
command262,
(3)import by means of commands PSO VERIFY CERTIFICATE263
the certificate as device authentication reference data to roles
autorized to execute this command264,
(4)select by means of command MANAGE SECURITY
ENVIRONMENT265 the device authentication reference data to
World266 267.
The subject logical channel is allowed to execute a command if the
security attributes interface, globalPasswordList, globalSecurityList,
dfSpecificPasswordList, dfSpecificSecurityList and bitSecurityList
SessionkeyContext of the subject meet the security attributes
lifeCycleStatus, seIdentifier and interfaceDependentAccessRules of
the affected object.
190 Application note 25: The TOE provides access control to the commands depending on the object
system. The refinements repeat the structure of the element in order to avoid iteration of the same
SFR. If root public keys are imported according to clause (2) this public key will be stored in the
persistentPublicKeyList of the object system.
191 The TOE shall meet the requirement “Management of security attributes (FMT_MSA.1/Auth)” as
specified below.
FMT_MSA.1/Auth Management of security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
259 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
260 [assignment: the authorised identified roles]
261 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
262 [assignment: the authorised identified roles]
263 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
264 [assignment: the authorised identified roles]
265 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
266 [selection: World, roles autorized to execute this command]
267 [assignment: the authorised identified roles]
6 Security Requirements
Page 86 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MSA.1.1/Auth The TSF shall enforce the access control key SFP268 to restrict the
ability to query269 270 the security attributes access control rights set for
the key271 to meet the access rules of command GET SECURITY
STATUS KEY of the object dependent on lifeCycleStatus, seIdentifier
and interfaceDependentAccessRules272.
192 The TOE shall meet the requirement “Management of TSF data – No export (FMT_MTD.1/NE)”
as specified below.
FMT_MTD.1/NE Management of TSF data – No export
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
FMT_MTD.1.1/NE The TSF shall restrict the ability to
(1) export TSF data according to FTP_ITE.2273 the
(a) public authentication reference data,
(b) security attributes for objects of the object system
to none274
(2) export TSF data according to FPT_ITE.2275 the
(c) none276 277 278
to none279 280
(3) export281 the following TSF-data
a) Password
b) Multi-Reference password
c) PUC
d) Private keys
e) Session keys
f) Symmetric authentication keys
g) Private authentication keys
268 [assignment: access control SFP(s), information flow control SFP(s)]
269 [assignment: other operations]
270 [selection: change_default, query, modify, delete, [assignment: other operations]]
271 [assignment: list of security attributes]
272 [assignment: the authorised identified roles]
273 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
274 [assignment: list of security attributes of subjects]
275 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
276 [assignment: list of all TOE specific security attributes not described in COS specification [21]]
277 [assignment: list of TSF data]
278 [assignment: other operations]
279 [assignment: list of security attributes of subjects]
280 [assignment: the authorised identified roles]
281 [assignment: list of TSF data]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 87 of 134
h) none282
and the following user data
i) Private keys of the user
j) Symmetric keys of the user
k) none283 284
to nobody285.
6.1.7 Cryptographic Functions
193 The TOE provides cryptographic services based on elliptic curve cryptography (ECC) using the
following curves refered to as COS standard curves in the following
(1) length 256 bit
(a) brainpoolP256r1 defined in RFC5639 [41],
(b) ansix9p256r1] defined in ANSI X.9.62 [42],
(2) length 384
(a) brainpoolP384r1 defined in RFC5639 [41],
(b) ansix9p384r1 defined in ANSI X.9.62 [42],
(3) length 512 bit
(a) brainpoolP512r1] defined in RFC5639 [41].
194 The Authentication Protocols produce agreed parameters to generate the message authentication
key and – if secure messaging with encryption is required - the encryption key for secure
messaging. Key agreement for rsaSessionkey4SM uses RSA only with 2048 bit modul length.
195 The TOE shall meet the requirement “Random number generation (FCS_RNG.1)” as specified
below.
FCS_RNG.1 Random number generation
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_RNG.1.1 The TSF shall provide a hybrid deterministic286 287 random number
generator DRG.4288 [7] that implements:
282 [assignment: list of types of TSF data]
283 [assignment: list of types of user data]
284 [assignment: list of TSF data]
285 [assignment: the authorised identified roles]
286 [selection: deterministic, hybrid deterministic, physical, hybrid physical]
287 [selection: physical, non-physical true, deterministic, hybrid]
6 Security Requirements
Page 88 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
- (DRG.4.1) The internal state of the RNG uses a PTRNG of class
PTG.2 as a random source.
- (DRG.4.2) The RNG provides forward secrecy.
- (DRG.4.3) The RNG provides backward secrecy, even if the current
internal state is known.
- (DRG.4.4) The RNG provides enhanced forward secrecy for every call.
- (DRG.4.5)The internal state of the RNG is seeded by a PTRNG of class
PTG.2.289 .
FCS_RNG.1.2/ The TSF shall provide random numbers that meet
- (DRG.4.6) The RNG generates output for which two strings of bit
length 128 are mutually different with probability 1 - 2^128.
- (DRG.4.7) Statistical test suites cannot practically distinguish the
random number from output sequences of an ideal RNG. The random
numbers pass test procedure A as defined in AIS20/31.290.
196 The TOE shall meet the requirement “Cryptographic operation - SHA (FCS_COP.1/SHA)” as
specified below.
FCS_COP.1/SHA Cryptographic operation - SHA
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/SHA The TSF shall perform hashing291 in accordance with a specified
cryptographic algorithm
(1) SHA-1,
(2) SHA-384,
(3) SHA-256,
(4) SHA-512 292
and cryptographic key sizes none293 that meet the following TR-03116
[19] section 3.2.1, FIPS 180-4[37]294.
197 The TOE shall meet the requirement “Cryptographic key generation – 3TDES_SM
(FCS_CKM.1/ 3TDES_SM)” as specified below.
FCS_CKM.1/
3TDES_SM
Cryptographic key generation – 3TDES_SM
288 [selection: DRG.3, DRG.4, PTG.2, PTG.3]
289 [assignment: list of security capabilities of the selected RNG class]
290 [assignment: a defined quality metric]
291 [assignment: list of cryptographic operations]
292 [assignment: cryptographic algorithm]
293 [assignment: cryptographic key sizes]
294 [assignment: list of standards]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 89 of 134
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction.
FCS_CKM.1.1/
3TDES_SM
The TSF shall generate session cryptographic keys in accordance
with a specified cryptographic key generation algorithm Key
Derivation Function specified in sec. 5.6.3 in ANSI X9.63295 and
specified cryptographic key sizes 192 bit (168 bit effectively)296 that
meet the following: standard ANSI X9.63 [40]297.
198 The TOE shall meet the requirement “Cryptographic operation - COS for 3TDES (FCS_COP.1/
COS.3TDES)” as specified below.
FCS_COP.1/
COS.3TDES
Cryptographic operation - COS for 3TDES
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/
COS.3TDES
The TSF shall perform decryption and encryption for secure
messaging298 in accordance with a specified cryptographic algorithm
3TDES in CBC mode299 and cryptographic key sizes 192 bit (168 bit
effectively)300 that meet the following TR-03116 [19], NIST SP 800-67
[38]301.
199 The TOE shall meet the requirement “Cryptographic operation COS for RMAC (FCS_COP.1/
COS.RMAC)” as specified below.
FCS_COP.1/
COS.RMAC
Cryptographic operation COS for RMAC
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/
COS.RMAC
The TSF shall perform
(1) Computation and verification for command
a. MUTUAL AUTHENTICATE,
b. EXTERNAL AUTHENTICATE,
295 [assignment: cryptographic key generation algorithm]
296 [assignment: cryptographic key sizes]
297 [assignment: list of standards]
298 [assignment: list of cryptographic operations]
299 [assignment: cryptographic algorithm]
300 [assignment: cryptographic key sizes]
301 [assignment: list of standards]
6 Security Requirements
Page 90 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
(2) computation and verification of cryptographic checksum for
secure messaging302
in accordance with a specified cryptographic algorithm Retail MAC303
and cryptographic key sizes 192 bit (168 bit effectively)304 that meet the
following TR-03116 [19], COS specification [21]305.
200 The TOE shall meet the requirement “Cryptographic operation – COS for AES (FCS_COP.1/
COS.AES)” as specified below.
FCS_COP.1/
COS.AES
Cryptographic operation – COS for AES
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/
COS.AES
The TSF shall perform
1. encryption and decryption with card internal key for commands
a. MUTUAL AUTHENTICATE, b. MUTUAL
AUTHENTICATE,
2. encryption with card internal key for command INTERNAL
AUTENTICATE
3. encryption and decryption with card internal key for command
GENERAL AUTHENTICATE.
4. decryption and encryption for secure messaging
306 in accordance with a specified cryptographic algorithm AES in CBC
mode307 and cryptographic key sizes 128 bit, 192 bit, 256 bit308 that
meet the following: TR-03116 [19], COS specification [21], FIPS 197
[33]309.
201 The TOE shall meet the requirement “Cryptographic key generation – COS for SM keys
(FCS_CKM.1/ AES.SM)” as specified below.
FCS_CKM.1/
AES.SM
Cryptographic key generation – COS for SM keys
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction.
FCS_CKM.1.1/ The TSF shall generate session cryptographic keys in accordance with a
specified cryptographic key generation algorithm Key Derivation for
302 [assignment: list of cryptographic operations]
303 [assignment: cryptographic algorithm]
304 [assignment: cryptographic key sizes]
305 [assignment: list of standards]
306 [assignment: list of cryptographic operations]
307 [assignment: cryptographic algorithm]
308 [assignment: cryptographic key sizes]
309 [assignment: list of standards]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 91 of 134
AES.SM AES as specified in sec. 4.4.3 in [17]310 and specified cryptographic key
sizes 128 bit, 192 bit, 256 bit311 that meet the following TR-03111 [17],
COS specification [21], FIPS 197 [33]312.
202 Application note 26: The Key Generation FCS_CKM.1/AES.SM is done during MUTUAL
AUTHENTICATE, EXTERNAL AUTHENTICATE, INTERNAL AUTHENTICATE or GENERAL
AUTHENTICATE with establishment of secure messaging (with option Crypto Box also for trusted
channel).
203 The TOE shall meet the requirement “Cryptographic operation – COS for CMAC (FCS_COP.1/
COS.CMAC)” as specified below.
FCS_COP.1/
COS.CMAC
Cryptographic operation – COS for CMAC
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/
COS.CMAC
The TSF shall perform
(1) computation and verification of cryptographic checksum for
command
a. MUTUAL AUTHENTICATE,
b. EXTERNAL AUTHENTICATE,
(2) computation of cryptographic checksum for command
INTERNAL AUTHENTICATE,
(3) computation and verification of cryptographic checksum for
secure messaging313
in accordance with a specified cryptographic algorithm CMAC314 and
cryptographic key sizes 128 bit, 192 bit, and 256 bit315 that meet the
following TR-03116 [19] section 3.2.2, COS specification [21], NIST
SP 800-38B [36]316.
204 The TOE shall meet the requirement “Cryptographic key generation – RSA key generation
(FCS_CKM.1/RSA)” as specified below.
FCS_CKM.1/RSA Cryptographic key generation – RSA key generation
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction.
310 [assignment: cryptographic key generation algorithm]
311 [assignment: cryptographic key sizes]
312 [assignment: list of standards]
313 [assignment: list of cryptographic operations]
314 [assignment: cryptographic algorithm]
315 [assignment: cryptographic key sizes]
316 [assignment: list of standards]
6 Security Requirements
Page 92 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
FCS_CKM.1.1/RSA The TSF shall generate cryptographic RSA keys in accordance with a
specified cryptographic key generation algorithm G&D_RSAKeyGen 317
and specified cryptographic key 2048 bit and 3072 bit modulo length318
that meet the following TR-03116 [19]319.
205 The TOE shall meet the requirement “Cryptographic key generation – ECC key generation
(FCS_CKM.1/ELC)” as specified below.
FCS_CKM.1/ELC Cryptographic key generation – ECC key generation
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction.
FCS_CKM.1.1/ELC The TSF shall generate cryptographic ELC keys in accordance with a
specified cryptographic key generation algorithm ECDH compliant to
[17]320 with COS standard curves321 and specified cryptographic key
256 bit, 384 bit and 512 bit 322 that meet the following TR-03111 [17],
COS specification [21]323.
206 Application note 27: The COS specification [21] requires the TOE to support elliptic curves listed
in COS specification [21], chapter 6.5 and to implement the command GENERATE ASYMMETRIC
KEY PAIR. Depending on the characteristic needs of the TOE should support the generation of
asymmetric key pairs for the following operations:
- qualified electronic signatures,
- authentication of external entities,
- document cipher key decipherment.
207 The TOE shall meet the requirement “Cryptographic operation – RSA signature-creation
(FCS_COP.1/ COS.RSA.S)” as specified below.
FCS_COP.1/
COS.RSA.S
Cryptographic operation – RSA signature-creation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1 The TSF shall perform digital signature generation for commands
(1) PSO COMPUTE DIGITAL SIGNATURE
317 [assignment: cryptographic key generation algorithm]
318 [assignment: cryptographic key sizes]
319 [assignment: list of standards]
320 [assignment: cryptographic key generation algorithm]
321 [assignment: cryptographic key generation algorithm]
322 [assignment: cryptographic key sizes]
323 [assignment: list of standards]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 93 of 134
/COS.RSA.S (2) INTERNAL AUTHENTICATE324
in accordance with a specified cryptographic algorithm
(3) RSASSA-PSS-SIGN with SHA-256,
(4) RSA SSA PKCS1-V1_5,
(5) RSA ISO9796-2 DS1 with SHA-256 (for INTERNAL
AUTHENTICATE only),
(6) RSA ISO9796-2 DS2 with SHA-256 (for PSO Compute
DIGITAL SIGNATURE only) 325,
and cryptographic key sizes
(7) 2048 bit modulo length,
(8) 3072 bit modulo length326
that meet the following: TR-03116 [19], COS specification [21], [34],
[31]327.
208 The TOE shall meet the requirement “Cryptographic operation – RSA signature verification
(FCS_COP.1/ COS.RSA.V)” as specified below.
FCS_COP.1/
COS.RSA.V
Cryptographic operation – RSA signature verification
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/
COS.RSA.V
The TSF shall perform digital signature verification for import of RSA
keys using the commands
(1) PSO VERIFY CERTIFICATE
(2) EXTERNAL AUTHENTICATE328
in accordance with a specified cryptographic algorithm RSA ISO9796-2
DS1329 and cryptographic key sizes 2048 bit modulo length330 that meet
the following: TR-03116 [19] COS specification [21], [34], [31]331.
209 Application note 28: The command PSO VERIFY CERTIFICATE may store the imported public
keys for RSA and ELC temporarily in the volatileCache or permanently in the persistentCache or
applicationPublicList. These keys may be used as authentication reference data for asymmetric
key based device authentication (cf. FIA_UAU.5) or user data.
210 The TOE shall meet the requirement “Cryptographic operation – ECDSA signature verification
(FCS_COP.1/
COS.ECDSA.V)” as specified below.
324 [assignment: list of cryptographic operations]
325 [assignment: cryptographic algorithm]
326 [assignment: cryptographic key sizes]
327 [assignment: list of standards]
328 [assignment: list of cryptographic operations]
329 [assignment: cryptographic algorithm]
330 [assignment: cryptographic key sizes]
331 [assignment: list of standards]
6 Security Requirements
Page 94 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
FCS_COP.1/
COS.ECDSA.V
Cryptographic operation – ECDSA signature verification
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/
COS.ECDSA.V
The TSF shall perform digital signature verification for import of ELC
keys for the commands
(1) PSO VERIFY CERTIFICATE,
(2) PSO VERIFY DIGITAL SIGNATURE,
(3) EXTERNAL AUTHENTICATE332
in accordance with a specified cryptographic algorithm ECDSA with
COS standard curves using
(4) SHA-256,
(5) SHA-384,
(6) SHA-512333
and cryptographic key sizes 256 bits, 384 bits, 512 bits334 that meet the
following TR-03116 [19], TR-03111 [17], COS specification [21],
[40]335.
211 The TOE shall meet the requirement “Cryptographic operation – ECDSA signature-creation
(FCS_COP.1/ COS.ECDSA.S)” as specified below.
FCS_COP.1/
COS.ECDSA.S
Cryptographic operation – ECDSA signature-creation
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/
COS.ECDSA.S
The TSF shall perform digital signature generation for command
(1) PSO COMPUTE DIGITAL SIGNATURE
(2) INTERNAL AUTHENTICATE336
in accordance with a specified cryptographic algorithm ECDSA with
COS standard curves using
(1) SHA-256,
(2) SHA-384,
(3) SHA-512337
and cryptographic key sizes 256 bits, 384 bits, 512 bits338 that meet the
following TR-03116 [19], TR-03111 [17], COS specification [21],
[40]339.
332 [assignment: list of cryptographic operations]
333 [assignment: cryptographic algorithm]
334 [assignment: cryptographic key sizes]
335 [assignment: list of standards]
336 [assignment: list of cryptographic operations]
337 [assignment: cryptographic algorithm]
338 [assignment: cryptographic key sizes]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 95 of 134
212 Application note 29: The TOE shall support two variants of the PSO COMPUTE DIGITAL
SIGNATURE.
- PSO COMPUTE DIGITAL SIGNATURE without Message Recovery shall be used for the signing
algorithms
 RSASSA-PSS-SIGN with SHA-256 (see FCS_COP.1/ COS.RSA.S),
 RSA SSA PKCS1-V1_5, RSA (see FCS_COP.1/ COS.RSA.S),
 ECDSA with SHA-256, SHA-384 and SHA-512 (see FCS_COP.1/ COS.ECDSA.S)
- PSO COMPUTE DIGITAL SIGNATURE with Message Recovery shall be used for the for the following
signing algorithm
 RSA ISO9796-2 DS2 with SHA-256 (see FCS_COP.1/ COS.ECDSA.S).
213 The TOE shall meet the requirement “Cryptographic operation – RSA encryption and
(FCS_COP.1/ COS.RSA)” as specified below.
FCS_COP.1/
COS.RSA
Cryptographic operation – RSA encryption and decryption
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/
COS.RSA
The TSF shall perform
(1) encryption with passed key for command PSO ENCIPHER
(2) decryption with stored key for command PSO DECIPHER
(3) decryption and encryption for command PSO TRANSCIPHER
using RSA (transcipher of data using RSA keys)
(4) decryption for command PSO TRANSCIPHER using RSA
(transcipher of data from RSA to ELC)
(5) encryption for command PSO TRANSCIPHER using ELC
(transcipher of data from ELC to RSA) 340
in accordance with a specified cryptographic algorithm
(6) for encryption:
a. RSA, ES, PKCS1 V1.5, Encrypt ([34] section 7.2.1)
b. RSA, OAEP, Encrypt ([34] section 7.1.1])
(7) for decryption:
a. RSA, ES, PKCS1 V1.5, Decrypt ([34] section 7.2.2])
b. RSA, OAEP, Decrypt ([34] section 7.1.2]) 341
and cryptographic key sizes 2048 bit and 3072 bit modulo length for
RSA private key operation, 2048 bit length for RSA public key
operation, and 256 bit, 384 bit and 512 bit for the COS standard
curves342 that meet the following TR-03116 [19], COS specification
[21], [34]343.
339 [assignment: list of standards]
340 [assignment: list of cryptographic operations]
341 [assignment: cryptographic algorithm]
342 [assignment: cryptographic key sizes]
343 [assignment: list of standards]
6 Security Requirements
Page 96 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
214 The TOE shall meet the requirement “Cryptographic operation – ECC encryption and decryption
(FCS_COP.1/ COS.ELC)” as specified below.
FCS_COP.1/
COS.ELC
Cryptographic operation – ECC encryption and decryption
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1
Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/
COS.ELC
The TSF shall perform
(1) encryption with passed key for command PSO ENCIPHER
(2) decryption with stored key for command PSO DECIPHER
(3) decryption and encryption for command PSO TRANSCIPHER
using ELC (transcipher of data using ELC keys)
(4) decryption for command PSO TRANSCIPHER using ELC
(transcipher of data from ELC to RSA)
(5) encryption for command PSO TRANSCIPHER using ELC
(transcipher of data from RSA to ELC) 344
in accordance with a specified cryptographic algorithm
(1) for encryption ELC encryption,
(2) for decryption ELC decryption345
and cryptographic key sizes 2048 bit and 3072 bit modulo length for
RSA private key operation, 2048 bit length for RSA public key
operation, and 256 bits, 384 bits, 512 bits for ELC keys with COS
standard curves346 that meet the following TR-03111 [17], TR-03116
[19], and COS specification [21]347.
215 Application note 30: The TOE supports the command PSO HASH (following standard [30]).
Therefore this ST adds a SFR FCS_COP.1/CB_HASH specifying the supported hash algorithms.
PSO HASH should not be used for processing confidential data.
216
FCS_COP.1/
CB_HASH
Cryptographic operation – Hash
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation, or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/
CB_HASH
The TSF shall perform a hash value348
in accordance with a specified cryptographic algorithm
344 [assignment: list of cryptographic operations]
345 [assignment: cryptographic algorithm]
346 [assignment: cryptographic key sizes]
347 [assignment: list of standards]
348 [assignment: list of cryptographic operations]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 97 of 134
(1) SHA-1
(2) SHA-224
(3) SHA-256
(4) SHA-384
(3) SHA-512 349
and cryptographic key sizes none350 that meet the following [17], [19],
and [21]351.
217
218 The TOE shall meet the requirement “Cryptographic key destruction (FCS_CKM.4)” as specified
below.
FCS_CKM.4 Cryptographic key destruction
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method overwriting the key value with
zero values352 that meets the following: none353.
219 Application note 31: The TOE destroys the encryption session keys and the message
authentication keys for secure messaging after reset or termination of secure messaging session
(trusted channel) or reaching fail secure state according to FPT_FLS.1. The TOE clears the
memory area of any session keys before starting a new communication with an external entity in
a new after-reset-session as required by FDP_RIP.1. Explicit deletion of a secret using the
DELETE command is taken into account by the TOE.
6.1.8 Protection of communication
220 The TOE shall meet the requirement “Inter-TSF trusted channel (FTP_ITC.1/TC)” as specified
below.
FTP_ITC.1/TC Inter-TSF trusted channel
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_ITC.1.1/TC The TSF shall provide a communication channel between itself and
another trusted IT product that is logically distinct from other
communication channels and provides assured identification of its end
points and protection of the channel data from modification or
disclosure.
FTP_ITC.1.2/TC The TSF shall permit another trusted IT product354 to initiate
349 [assignment: cryptographic algorithm]
350 [assignment: cryptographic key sizes]
351 [assignment: list of standards]
352 [assignment: cryptographic key destruction method]
353 [assignment: list of standards]
6 Security Requirements
Page 98 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
communication via the trusted channel.
FTP_ITC.1.3/TC The TSF shall initiate communication via the trusted channel for
none355.
221 Application note 32: The TOE responds only to commands establishing secure messaging
channels.
6.2 Security Assurance Requirements for the TOE
222 The Security Target to be developed based upon this Protection Profile will be evaluated
according to
Security Target evaluation (Class ASE)
223 Security Assurance Requirements for the TOE for the evaluation of the TOE are those taken from
the Evaluation
Assurance Level 4 (EAL4)
224 and augmented by taking the following components:
ALC_DVS.2 (Development security)
ATE_DPT.2 (Test depth)
AVA_VAN.5 (Advanced methodical vulnerability analysis).
225 The assurance requirements are:
Class ADV: Development
Architectural design (ADV_ARC.1)
Functional specification (ADV_FSP.4)
Implementation representation (ADV_IMP.1)
TOE design (ADV_TDS.3)
Class AGD: Guidance documents
Operational user guidance (AGD_OPE.1)
Preparative user guidance (AGD_PRE.1)
Class ALC: Life-cycle support
CM capabilities (ALC_CMC.4)
CM scope (ALC_CMS.4)
Delivery (ALC_DEL.1)
Development security (ALC_DVS.2)
354 [selection: the TSF, another trusted IT product]
355 [assignment: list of functions for which a trusted channel is required]
Security Target Lite STARCOS 3.6 COSGKV C1 Page 99 of 134
Life-cycle definition (ALC_LCD.1)
Tools and techniques (ALC_TAT.1)
Class ASE: Security Target evaluation
Conformance claims (ASE_CCL.1)
Extended components definition (ASE_ECD.1)
ST introduction (ASE_INT.1)
Security objectives (ASE_OBJ.2)
Derived security requirements (ASE_REQ.2)
Security problem definition (ASE_SPD.1)
TOE summary specification (ASE_TSS.1)
Class ATE: Tests
Coverage (ATE_COV.2)
Depth (ATE_DPT.2)
Functional tests (ATE_FUN.1)
Independent testing (ATE_IND.2)
Class AVA: Vulnerability assessment
Vulnerability analysis (AVA_VAN.5)
Table 21: Assurance components
6.2.1 Refinements of the TOE Assurance Requirements
226 In the BSI-CC-PP-0035-2007 [11] refinements of the TOE assurance requirements were
performed. This Security Target takes over the refinements for the SFR listed in section 6.1.3
“Security Functional Requirements for the TOE taken over from BSI-CC-PP-0035-2007”. The
refinements must be applied for the SFR listed in section 6.1.3 (see Table 20). The refinements
and the section where the refinement in BSI-CC-PP-0035-2007 [11] is specified are listed in
Table 22 .
227 For all other Security Functional Requirements the TOE assurance requirements from Common
Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Requirements; CCMB-2012-09-003, Version 3.1, Revision 4, September 2012 [3] should be
used. Note that it is possible to use the TOE assurance requirements as defined in BSI-CC-PP-
0035-2007 [11] (see Table 22) for all SFR in this Protection Profile. According to Common
Criteria for Information Technology Security Evaluation, Part 1: Introduction and General Model;
CCMB-2012-09-001, Version 3.1, Revision 4, September 2012 [1] for that choice a justification
of why the preferred option was not chosen is required.
Refinements regarding Reference to [11]
Delivery procedure (ALC_DEL) Section 6.2.1.1 “Refinements regarding
Delivery procedure (ALC_DEL)”
Development Security (ALC_DVS) Section 6.2.1.2 “Refinements regarding
6 Security Requirements
Page 100 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
Refinements regarding Reference to [11]
Development Security (ALC_DVS)”
CM scope (ALC_CMS) Section 6.2.1.3 “Refinements regarding CM
scope (ALC_CMS)”
CM capabilities (ALC_CMC) Section 6.2.1.4 “Refinements regarding CM
capabilities (ALC_CMC)”
Security Architecture (ADV_ARC) Section 6.2.1.5 “Refinements regarding
Security Architecture (ADV_ARC)”
Functional Specification (ADV_FSP) Section 6.2.1.6 “Refinements regarding
Functional Specification (ADV_FSP)”
Implementation Representation (ADV_IMP) Section 6.2.1.7 “Refinements regarding
Implementation Representation
(ADV_IMP)”
Test Coverage (ATE_COV) Section 6.2.1.8” Refinements regarding Test
Coverage (ATE_COV)”
User Guidance (AGD_OPE) Section 6.2.1.9 “Refinements regarding
User Guidance (AGD_OPE)”
Preparative User Guidance (AGD_PRE) Section 6.2.1.10 “Refinements regarding
Preparative User Guidance (AGD_PRE)”
Refinement regarding Vulnerability Analysis
(AVA_VAN)
Section 6.2.1 “Refinement regarding
Vulnerability Analysis (AVA_VAN)”
Table 22: Refined TOE assurance requirements
228 The following sections define refinements and application notes to the chosen SAR.
6.2.2 Refinements to ADV_ARC.1 Security architecture description
229 The ADV_ARC.1 Security architecture description requires as developer action
ADV_ARC.1.1D The developer shall design and implement the TOE so that the security features
of the TSF cannot be bypassed.
And the related content and presentation element
ADV_ARC.1.5C The security architecture description shall demonstrate that the TSF prevents
bypass of the SFR-enforcing functionality.
230 The COS specification [21] allows implementation of optional features and commands. The
following refinement for ADV_ARC.1.5C defines specific evidence required for these optional
features and commands if implemented by the TOE and not being part of the TSF.
Refinement: If the features and commands identified as optional in the COS specification
are not part of the TSF the security architecture description shall demonstrate that they do
not bypass the SFR-enforcing functionality.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 101 of 134
6.2.3 Refinements to ADV_FSP.4 Complete functional specification
231 The following content and presentation element of ADV_FSP.4 Complete functional
specification is refined as follows:
ADV_FSP.4.2C The functional specification shall describe the purpose and method of use for all
TSFI.
Refinement: The functional specification shall describe the purpose and method of use for all
TSFI including
(1) the physical and logical interface of the smart card platform, both contact based and
contactless as implemented by the TOE,
(2) the logical interface of the wrapper to the verification tool.
232 Application note 33: The IC surface as external interface of the TOE provides the TSFI for
physical protection (cf. FPT_PHP.3) and evaluated in the IC evaluation as base evaluation for the
composite evaluation of the composite TOE (cf. [9], chapter 2.5.2, for details). This interface is
also analysed as attack surface in the vulnerability analysis e.g. in respect to perturbation and
emanation side channel analysis.
6.2.4 Refinement to ADV_IMP.1
233 The following content and presentation element of ADV_IMP.1 Implementation representation of
the TSF is refined as follows:
234 ADV_IMP.1.1D The developer shall make available the implementation representation for the
entire TOE.
235 Application note 34: The refinement extends the TSF implementation representation to the TOE
implementation representation, i.e. the complete executable code implemented on the Security
platform IC including all IC Embedded Software and especially the Card Operating System,
(COS).
6.2.5 Refinements to AGD_OPE.1 Operational user guidance
236 The following content and presentation element of AGD_OPE.1 Operational user guidance is
refined as follows:
AGD_OPE.1.2C The operational user guidance shall describe, for each user role, how to use the
available interfaces provided by the TOE in a secure manner.
Refinement: The operational user guidance shall describe the method of use of the wrapper
interface.
Application note 35: The wrapper will be used to interact with the smartcard for export of all
public TSF data of all objects in an object system according to “Export of TSF data
(FPT_ITE.2)”. Because the COS specification [21] identifies optional functionality the TOE’s
guidance documentation describes method of use of the TOE (as COS, wrapper) to find all
objects in the object system and to export all security attributes of these objects.
6 Security Requirements
Page 102 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
6.2.6 Refinements to ATE_FUN.1 Functional tests
237 The following content and presentation element of ATE_FUN.1 Functional tests is refined as
follows:
ATE_FUN.1.1C The test documentation shall consist of test plans, expected test results and
actual test results.
Refinement: The test plan shall include typical uses cases applicable for the TOE and the
intended application eHC, eHPC, SMC-KT, SMC-B or SMC-K.
6.2.7 Refinements to ATE_IND.2 Independent testing – sample
238 The following content and presentation element of ATE_IND.2 Functional tests is refined as
follows:
ATE_IND.2.3E The evaluator shall test a subset of the TSF to confirm that the TSF operates as
specified.
Refinement: The evaluator tests shall include typical uses cases applicable for the TOE and
the intended application eHC, eHPC, SMC-B, SMC-K and SMC-KT.
Application note 36: The evaluator should agree the typical uses cases with the certification body in order to
define an effective test approach and to use synergy for appropiate test effort. The agreed test cases support
comparable test effort for TSF defined in the main part of this ST and the optional packages included in this ST.
6.3 Security Requirements Rationale
239 This chapter comprises three parts:
- The SFR rationale provided by a table showing the coverage of security objective of the TOE
by security functional requirements, already provided in the current version of this ST, and
rationale explanatory text which will be provided in future versions of this ST
- The SFR dependency rationale missing in the current version and to be provided in future
versions of this ST
- The SAR rationale provided in section 6.3.3.
6.3.1 Security Functional Requirements Rationale
240 Table 2 in section 6.3.1 “Security Functional Requirements Rational” in BSI-CC-PP-0035-
2007 [11] gives an overview, how the security functional requirements taken over are combined
to meet the security objectives. Please refer that table and the text following after that table
justifying this in detail for the further details.
241 The following table provides an overview for security functional requirements coverage also
giving an evidence for sufficiency and necessity of the SFRs chosen.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 103 of 134
O.Identification
O.Leak-Inherent
O.Phys-Probing
O.Malfunction
O.Phys-Manipulation
O.Leak-Forced
O.Abuse-Func
O.RND
FAU_SAS.1/SICP X
FCS_RNG.1/SICP X
FDP_IFC.1/SICP X X
FDP_ITT.1/SICP X X
FMT_LIM.1/SICP X
FMT_LIM.2/SICP X
FPT_FLS.1/SICP X
FPT_ITT.1/SICP X X
FPT_PHP.3/SICP X X
FRU_FLT.2/SICP X
Table 23: Coverage of Security Objectives for the TOE IC part by SFR
242 As stated in section 2.4, this ST claims conformance to BSI-CC-PP-0035-2007 [11]. The
objectives and SFRs as used in Table 23 are defined and handled in [11]. Hence, the rationale for
these items and their correlation from Table 23 is given in [11] and not repeated here.
O.Integrity
O.Confidentiality
O.Resp-COS
O.TSFDataExport
O.Authentication
O.AccessControl
O.KeyManagement
O.Crypto
O.SecureMessaging
FDP_RIP.1 X
FDP_SDI.2 X
FPT_FLS.1 X X
FPT_EMS.1 X
FPT_TDC.1 X
FPT_ITE.1 X
FPT_ITE.2 X
FPT_TST.1 X X X
FIA_AFL.1/PIN X
FIA_AFL.1/PUC X
FIA_ATD.1 X
FIA_UAU.1 X
FIA_UAU.4 X
FIA_UAU.5 X
6 Security Requirements
Page 104 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
O.Integrity
O.Confidentiality
O.Resp-COS
O.TSFDataExport
O.Authentication
O.AccessControl
O.KeyManagement
O.Crypto
O.SecureMessaging
FIA_UAU.6 X
FIA_UID.1 X
FIA_API.1 X
FMT_SMR.1 X X
FIA_USB.1 X X
FIA_SOS.1 X X
FDP_ACC.1/ MF_DF X
FDP_ACF.1/ MF_DF X
FDP_ACC.1/EF X
FDP_ACF.1/EF X
FDP_ACC.1/TEF X
FDP_ACF.1/TEF X
FDP_ACC.1/SEF X
FDP_ACF.1/SEF X
FDP_ACC.1/KEY X
FDP_ACF.1/KEY X
FMT_MSA.3 X
FMT_SMF.1 X
FMT_MSA.1/Life X
FMT_MSA.1/SEF X
FMT_MTD.1/PIN X X
FMT_MSA.1/PIN X X
FMT_MTD.1/Auth X X
FMT_MSA.1/Auth X X
FMT_MTD.1/NE X X
FCS_RNG.1 X X
FCS_CKM.1/ 3TDES_SM X X X
FCS_CKM.1/ AES.SM X X
FCS_CKM.1/RSA X X
FCS_CKM.1/ELC X X
FCS_COP.1/SHA X
FCS_COP.1/CB_HASH X
FCS_COP.1/ COS.AES X X
FCS_COP.1/ COS.CMAC X
FCS_COP.1/ COS.RMAC X X
Security Target Lite STARCOS 3.6 COSGKV C1 Page 105 of 134
O.Integrity
O.Confidentiality
O.Resp-COS
O.TSFDataExport
O.Authentication
O.AccessControl
O.KeyManagement
O.Crypto
O.SecureMessaging
FCS_COP.1/ COS.RSA.S X
FCS_COP.1/ COS.RSA.V X
FCS_COP.1/ COS.ECDSA.S X
FCS_COP.1/ COS.ECDSA.V X
FCS_COP.1/ COS.RSA X
FCS_COP.1/ COS.ELC X
FCS_COP.1/ COS.3TDES X
FCS_CKM.4 X
FTP_ITC.1/TC X
Table 24: Mapping between security objectives for the TOE and SFR
243 A detailed justification required for suitability of the security functional requirements to achieve
the security objectives is given below.
244 The security objective O.Integrity “Integrity of internal data” requires the protection of the
integrity of user data, TSF data and security services. This objective is addressed by the SFRs
FDP_SDI.2, FPT_FLS.1 and FPT_TST.1: FPT_TST.1 requires self tests to demonstrate the
correct operation of the TSF and its protection capabilities. FDP_SDI.2 requires the TSF to
monitor user data stored in containers and to take assigned action when data integrity errors are
detected. In case of failures, FPT_FLS.1 requires the preservation of a secure state in order to
protect the user data, TSF data and security services.
245 The security objective O.Confidentiality “Confidentiality of internal data” requires the
protection of the confidentiality of sensitive user data and TSF data. This objective is addressed
by the SFRs FDP_RIP.1, FPT_FLS.1, FPT_EMS.1, FPT_TST.1 and FMT_MTD.1/NE:
FMT_MTD.1/NE restricts the ability to export sensitive TSF data to dedicated roles, some
sensitive user data like private authentication keys are not allowed to be exported at all.
FPT_EMS.1 requires that the TOE does not emit any information of sensitive user data and TSF
data by emissions and via circuit interfaces. Further, FDP_RIP.1 requires that residual
information regarding sensitive data in previously used resources will not be available after its
usage. FPT_TST.1 requires self tests to demonstrate the correct operation of the TSF and its
confidentiality protection capabilities. In case of failures, FPT_FLS.1 requires the preservation of
a secure state in order to protect the user data, TSF data and security services.
246 The security objective O.Resp-COS “Treatment of User and TSF Data” requires the correct
treatment of the user data and TSF data as defined by the TSF data of the object system. This
correct treatment is ensured by appropriate self tests of the TSF. FPT_TST.1 requires self tests to
demonstrate the correct operation of the TSF and its data treatment.
247 The security objective O.TSFDataExport “Support of TSF data export” requires the correct
export of TSF data of the object system excluding confidential TSF data. This objective is
addressed by the SFRs FPT_TDC.1, FPT_ITE.1 and FPT_ITE.2: FPT_ITE.2 requires the export
6 Security Requirements
Page 106 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
of dedicated TSF data but restricts the kind of TSF data that can be exported. Hence, confidential
data shall not be exported. Also, the TSF is required to be able to export the fingerprint of TSF
implementation by the SFR FPT_ITE.1. For Card Verifiable Certificates (CVC), the SFR
FPT_TDC.1 requires the consistent interpretation when shared between the TSF and another
trusted IT product.
248 The security objective O.Authentication “Authentication of external entities” requires the
support of authentication of human users and external devices as well as the ability of the TSF to
authenticate itself. This objective is addressed by the following SFRs:
- FIA_SOS.1 requires that the TSF enforces the length of the secret of the password
objects.
- FIA_AFL.1/PIN requires that the TSF detects repeated unsuccessful authentication
attempts and blocks the password authentication when the number of unsuccessful
authentication attempts reaches a defined number.
- FIA_AFL.1/PUC requires that the TSF detects repeated unsuccessful authentication
attempts for the password unblocking function and performs appropriate actions when the
number of unsuccessful authentication attempts reaches a defined number.
- FIA_ATD.1 requires that the TSF maintains dedicated security attributes belonging to
individual users.
- FIA_UAU.1 requires the processing of dedicated actions before a user is authenticated.
Any other actions shall require user authentication.
- FIA_UAU.4 requires the prevention of reuse of authentication data.
- FIA_UAU.5 requires the TSF to support user authentication by providing dedicated
commands. Multiple authentication mechanisms like password based and key based
authentication are required.
- FIA_UAU.6 requires the TSF to support re-authentication of message senders using a
secure messaging channel.
- FIA_UID.1 requires the processing of dedicated actions before a user is identified. Any
other actions shall require user identification.
- FIA_API.1 requires that the TSF provides dedicated commands to prove the identity of
the TSF itself.
- FMT_SMR.1 requires that the TSF maintains roles and associates users with roles.
- FIA_USB.1 requires that the TSF associates dedicated security attributes with subjects
acting on behalf of that user. Also, the TSF shall enforce rules governing changes of these
security attributes by the implementation of commands that perform these changes.
- FMT_MTD.1/PIN requires that the TSF restricts the ability to change password objects
by the implementation of dedicated commands and management functions.
- FMT_MSA.1/PIN requires that the TSF enforces the access control policy to restrict the
ability to read, change and optionally perform further operations of security attributes for
password objects. For that purpose the SFR requires management functions to implement
these operations.
- FMT_MTD.1/Auth requires that the TSF restricts the ability to import device
authentication reference data by the implementation of dedicated commands and
management functions.
- FMT_MSA.1/Auth requires that the TSF enforces the access control policy to restrict the
ability to read security attributes for the device authentication reference data. For that
purpose the SFR requires management functions to implement this operation.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 107 of 134
249 The security objective O.AccessControl “Access Control for Objects” requires the enforcement
of an access control policy to restricted objects and devices. Further, the management
functionality for the access policy is required. This objective is addressed by the following SFRs:
- FMT_SMR.1 requires that the TSF maintains roles and associates users with roles.
- FIA_USB.1 requires that the TSF associates dedicated security attributes with subjects
acting on behalf of that user. Also, the TSF shall enforce rules governing changes of these
security attributes by the implementation of commands that perform these changes.
- FDP_ACC.1/ MF_DF requires that the TSF enforces an access control policy to restrict
operations on MF and folders objects as well as applications performed by subjects of the
TOE.
- FDP_ACF.1/ MF_DF requires that the TSF enforce an access control policy to restrict
operations on MF and folders objects as well as applications based on a set of rules
defined in the SFR. Also, the TSF is required to deny access to the MF object in case of
“Termination state” of the TOE life cycle.
- FDP_ACC.1/EF requires that the TSF enforces an access control policy to restrict
operations on EF objects performed by subjects of the TOE.
- FDP_ACF.1/EF requires that the TSF enforce an access control policy to restrict
operations on EF objects based on a set of rules defined in the SFR. Also, the TSF is
required to deny access to EF objects in case of “Termination state” of the TOE life
cycle.
- FDP_ACC.1/TEF requires that the TSF enforces an access control policy to restrict
operations on transparent EF objects performed by subjects of the TOE.
- FDP_ACF.1/TEF requires that the TSF enforce an access control policy to restrict
operations on transparent EF objects based on a set of rules defined in the SFR. Also, the
TSF is required to deny access to transparent EF objects in case of “Termination state” of
the TOE life cycle.
- FDP_ACC.1/SEF requires that the TSF enforces an access control policy to restrict
operations on structured EF objects performed by subjects of the TOE.
- FDP_ACF.1/SEF requires that the TSF enforce an access control policy to restrict
operations on structured EF objects based on a set of rules defined in the SFR. Also, the
TSF is required to deny access to structured EF objects in case of “Termination state” of
the TOE life cycle.
- FDP_ACC.1/KEY requires that the TSF enforces an access control policy to restrict
operations on dedicated key objects performed by subjects of the TOE.
- FDP_ACF.1/KEY requires that the TSF enforce an access control policy to restrict
operations on on dedicated key objects based on a set of rules defined in the SFR. Also,
the TSF is required to deny access to dedicated key objects in case of “Termination state”
of the TOE life cycle.
- FMT_MSA.3 requires that the TSF enforces an access control policy that provides
restrictive default values for the used security attributes. Alternative default values for
these security attributes shall only be allowed for dedicated authorized roles.
- FMT_SMF.1 requires that the TSF implements dedicated management functions that are
given in the SFR.
- FMT_MSA.1/Life requires that the TSF enforces the access control policy to restrict the
ability to manage life cycle relevant security attributes like lifeCycleStatus. For that
purpose the SFRs require management functions to implement these operations.
- FMT_MSA.1/SEF requires that the TSF enforces the access control policy to restrict the
ability to manage of security attributes of recorde. For that purpose the SFRs require
management functions to implement these operations.
6 Security Requirements
Page 108 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
- FMT_MTD.1/PIN requires that the TSF restricts the ability to change password objects
by the implementation of dedicated commands and management functions.
- FMT_MSA.1/PIN requires that the TSF enforces the access control policy to restrict the
ability to read, change and optionally perform further operations of security attributes for
password objects. For that purpose the SFR requires management functions to implement
these operations.
- FMT_MTD.1/Auth requires that the TSF restricts the ability to import device
authentication reference data by the implementation of dedicated commands and
management functions.
- FMT_MSA.1/Auth requires that the TSF enforces the access control policy to restrict the
ability to read security attributes for the device authentication reference data. For that
purpose the SFR requires management functions to implement this operation.
- FMT_MTD.1/NE restricts the ability to export sensitive TSF data to dedicated roles,
some sensitive user data like private authentication keys are not allowed to be exported at
all.
250 The security objective O.KeyManagement “Generation and import of keys” requires the ability
of the TSF to secure generation, import, distribution, access control and destruction of
cryptographic keys. Also, the TSF is required to support the import and export of public keys.
This objective is addressed by the following SFRs:
- FCS_RNG.1 requires that the TSF provides a random number generator of a specific
class used for generation of keys.
- FCS_CKM.1/ 3TDES_SM, FCS_CKM.1/ AES.SM, FCS_CKM.1/RSA,
FCS_CKM.1/ELC, require that the TSF generates cryptographic keys with specific key
generation algorithms as stated in the SFRs. The mentioned SFRs are needed to fulfil
different requirements of the intended usage of the cryptographic keys.
- FCS_CKM.4 requires that the TSF destroys cryptographic keys in accordance with a
given specific key destruction method.
- FDP_ACC.1/KEY and FDP_ACF.1/KEY controls access to the key management and the
cryptographic operations using keys.
- FMT_MSA.1/Life requires restriction of the management of security attributes of the
keys to subjects authorized for specific commands.
251 The security objective O.Crypto “Cryptographic functions” requires the ability of the TSF to
implement secure cryptographic algorithms. This objective is addressed by the following SFRs:
- FCS_RNG.1 requires that the TSF provides a random number generator of a specific
class used for generation of keys.
- FCS_COP.1/SHA requires that the TSF provides different hashing algorithms that are
referenced in the SFR.
- FCS_COP.1/CB_HASH requires that the TSF provides different hashing algorithms that
are referenced in the SFR.
- FCS_COP.1/ COS.3TDES requires that the TSF provides decryption and encryption
using 3TDES for secure messaging.
- FCS_COP.1/ COS.AES requires that the TSF provides decryption and encryption using
AES with different key sizes.
- FCS_COP.1/ COS.RMAC requires that the TSF provides computation and verification of
cryptographic checksums using the Retail MAC algorithm.
- FCS_COP.1/ COS.CMAC requires that the TSF provides computation and verification of
cryptographic checksums using the CMAC algorithm.
- FCS_COP.1/ COS.RSA.S requires that the TSF provides the generation of digital
signatures based on the RSA algorithm and different modulus’ lengths.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 109 of 134
- FCS_COP.1/ COS.RSA.V requires that the TSF provides the verification of digital
signatures based on the RSA algorithm and different modulus’ lengths.
- FCS_COP.1/ COS.ECDSA.S requires that the TSF provides the generation of digital
signatures based on the ECDSA and different hash algorithms and different key sizes.
- FCS_COP.1/ COS.ECDSA.V requires that the TSF provides the verification of digital
signatures based on the ECDSA and different hash algorithms and different key sizes.
- FCS_COP.1/ COS.RSA requires that the TSF provides encryption and decryption
capabilities based on RSA algorithms with different modulus’ lengths.
- FCS_COP.1/ COS.ELC requires that the TSF provides encryption and decryption
capabilities based on ELC algorithms with different key sizes.
- FCS_CKM.1/ 3TDES_SM, FCS_CKM.1/ AES.SM, FCS_CKM.1/RSA,
FCS_CKM.1/ELC, require that the TSF generates cryptographic keys with specific key
generation algorithms as stated in the SFRs. The mentioned SFRs are needed to fulfil
different requirements of the intended usage of the cryptographic keys.
252 The security objective O.SecureMessaging “Secure messaging” requires the ability of the TSF to
use and enforce the use of a trusted channel to successfully authenticated external entities that
ensures the integrity and confidentiality of the transmitted data between the TSF and the external
entity. This objective is addressed by the following SFRs:
- FCS_COP.1/ COS.3TDES requires that the TSF provides decryption and encryption
using 3TDES for secure messaging.
- FCS_COP.1/ COS.AES requires that the TSF provides decryption and encryption using
AES with different key sizes. One use case of that required functionality is secure
messaging.
- FCS_COP.1/ COS.RMAC requires that the TSF provides computation and verification of
cryptographic checksums using the Retail MAC algorithm. One use case of that required
functionality is secure messaging.
- FCS_CKM.1/ 3TDES_SM requires that the TSF generates cryptographic keys with
specific key generation algorithms as stated in the SFR.
- FTP_ITC.1/TC requires that the TSF provides a communication channel between itself
and another trusted IT product. The channel provides assured identification of its end
points and protection of the channel data against modification and disclosure.
6.3.2 Rationale for SFR’s Dependencies
253 Table 3 in section 6.3.1 “Dependencies of security functional requirements” in BSI-CC-PP-0035-
2007 [11] lists the security functional requirements defined in BSI-CC-PP-0035-2007, their
dependencies and whether they are satisfied by other security requirements defined in this
Protection Profile. Please refer that table and the text following after that table justifying this in
detail for the further details on the remaining cases.
254 The dependency analysis for the security functional requirements shows that the basis for mutual
support and internal consistency between all defined functional requirements is satisfied. All
dependencies between the chosen functional components are analysed, and non-dissolved
dependencies are appropriately explained.
255 The dependency analysis has directly been made within the description of each SFR in 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-fulfilment is justified.
6 Security Requirements
Page 110 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
256 The following table lists the required dependencies of the SFRs of this ST and gives the concrete
SFRs from this document which fulfil the required dependencies.
SFR dependent on fulfilled by
FDP_RIP.1 No dependencies. n. a.
FDP_SDI.2 No dependencies n.a.
FPT_FLS.1 No dependencies. n. a.
FPT_EMS.1 No dependencies. n. a.
FPT_TDC.1 No dependencies. n. a.
FPT_ITE.1 No dependencies. n. a.
FPT_ITE.2 No dependencies. n. a.
FPT_TST.1 No dependencies. n. a.
FIA_SOS.1 No dependencies n.a.
FIA_AFL.1/PIN FIA_UAU.1 Timing of
authentication.
FIA_UAU.1
FIA_AFL.1/PUC FIA_UAU.1 Timing of
authentication.
FIA_UAU.1
FIA_ATD.1 No dependencies. n. a.
FIA_UAU.1 FIA_UID.1 Timing of identification. FIA_UID.1
FIA_UAU.4 No dependencies. n. a.
FIA_UAU.5 No dependencies. n. a.
FIA_UAU.6 No dependencies. n. a.
FIA_UID.1 No dependencies. n. a.
FIA_API.1 No dependencies. n. a.
FMT_SMR.1 FIA_UID.1 Timing of identification FIA_UID.1
FIA_USB.1 FIA_ATD.1 User attribute definition FIA_ATD.1
FDP_ACC.1/ MF_DF FDP_ACF.1 Security attribute based
access control.
FDP_ACF.1/ MF_DF
FDP_ACF.1/ MF_DF FDP_ACC.1 Subset access control,
FMT_MSA.3 Static attribute
initialisation
FDP_ACC.1/ MF_DF,
FMT_MSA.3
FDP_ACC.1/EF FDP_ACF.1 Security attribute based
access control.
FDP_ACF.1/EF
FDP_ACF.1/EF FDP_ACC.1 Subset access control,
FMT_MSA.3 Static attribute
initialisation
FDP_ACC.1/EF,
FMT_MSA.3
FDP_ACC.1/TEF FDP_ACF.1 Security attribute based
access control.
FDP_ACF.1/TEF
FDP_ACF.1/TEF FDP_ACC.1 Subset access control,
FMT_MSA.3 Static attribute
initialisation
FDP_ACC.1/TEF,
FMT_MSA.3
FDP_ACC.1/SEF FDP_ACF.1 Security attribute based
access control.
FDP_ACF.1/SEF
FDP_ACF.1/SEF FDP_ACC.1 Subset access control,
FMT_MSA.3 Static attribute
FDP_ACC.1/SEF,
FMT_MSA.3
Security Target Lite STARCOS 3.6 COSGKV C1 Page 111 of 134
SFR dependent on fulfilled by
initialisation
FDP_ACC.1/KEY FDP_ACF.1 Security attribute based
access control.
FDP_ACF.1/KEY
FDP_ACF.1/KEY FDP_ACC.1 Subset access control,
FMT_MSA.3 Static attribute
initialisation
FDP_ACC.1/KEY,
FMT_MSA.3
FMT_MSA.3 FMT_MSA.1 Management of
security attributes,
FMT_SMR.1 Security roles
FMT_MSA.1/Life,
FMT_MSA.1/SEF,
FMT_MSA.1/PIN,
FMT_MSA.1/Auth,
FMT_SMR.1
FMT_SMF.1 No dependencies. n. a.
FMT_MSA.1/Life [FDP_ACC.1 Subset access control,
or
FDP_IFC.1 Subset information flow
control],
FMT_SMR.1 Security roles,
FMT_SMF.1 Specification of
Management Functions
FDP_ACC.1/ MF_DF,
FDP_ACC.1/EF,
FDP_ACC.1/TEF,
FDP_ACC.1/SEF,
FDP_ACC.1/KEY,
FMT_SMR.1,
FMT_SMF.1
FMT_MSA.1/SEF [FDP_ACC.1 Subset access control,
or
FDP_IFC.1 Subset information flow
control],
FMT_SMR.1 Security roles,
FMT_SMF.1 Specification of
Management Functions
FDP_ACC.1/ MF_DF,
FDP_ACC.1/EF,
FDP_ACC.1/TEF,
FDP_ACC.1/SEF,
FDP_ACC.1/KEY,
FMT_SMR.1,
FMT_SMF.1
FMT_MTD.1/PIN FMT_SMR.1 Security roles,
FMT_SMF.1 Specification of
Management Functions
FMT_SMR.1,
FMT_SMF.1
FMT_MSA.1/PIN [FDP_ACC.1 Subset access control,
or
FDP_IFC.1 Subset information flow
control],
FMT_SMR.1 Security roles,
FMT_SMF.1 Specification of
Management Functions
FDP_ACC.1/ MF_DF,
FDP_ACC.1/EF,
FDP_ACC.1/TEF,
FDP_ACC.1/SEF,
FDP_ACC.1/KEY,
FMT_SMR.1,
FMT_SMF.1
FMT_MTD.1/Auth FMT_SMR.1 Security roles,
FMT_SMF.1 Specification of
Management Functions
FMT_SMR.1,
FMT_SMF.1
FMT_MSA.1/Auth [FDP_ACC.1 Subset access control,
or
FDP_IFC.1 Subset information flow
control],
FMT_SMR.1 Security roles,
FMT_SMF.1 Specification of
Management Functions
FDP_ACC.1/ MF_DF,
FDP_ACC.1/EF,
FDP_ACC.1/TEF,
FDP_ACC.1/SEF,
FDP_ACC.1/KEY,
FMT_SMR.1,
FMT_SMF.1
FMT_MTD.1/NE FMT_SMR.1 Security roles,
FMT_SMF.1 Specification of
Management Functions
FMT_SMR.1,
FMT_SMF.1
6 Security Requirements
Page 112 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
SFR dependent on fulfilled by
FCS_RNG.1 No dependencies. n. a.
FCS_COP.1/SHA [FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation],
FCS_CKM.4 Cryptographic key
destruction
The dependent SFRs are not
applicable here because
FCS_COP.1/SHA does not use
any keys.
FCS_COP.1/
COS.3TDES
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation],
FCS_CKM.4 Cryptographic key
destruction
FCS_CKM.1/ 3TDES_SM,
FCS_CKM.4
FCS_COP.1/
COS.AES
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation],
FCS_CKM.4 Cryptographic key
destruction
FCS_CKM.1/ AES.SM,
FCS_CKM.4
FCS_COP.1/
COS.RMAC
[FCS_CKM.2 Cryptographic key
distribution, or
FCS_COP.1 Cryptographic
operation],
FCS_CKM.4 Cryptographic key
destruction.
FCS_COP.1/ COS.3TDES,
FCS_CKM.4
FCS_CKM.1/
3TDES_SM
[FCS_CKM.2 Cryptographic key
distribution, or
FCS_COP.1 Cryptographic
operation],
FCS_CKM.4 Cryptographic key
destruction.
FCS_COP.1/ COS.3TDES,
FCS_CKM.4
FCS_CKM.1/
AES.SM
[FCS_CKM.2 Cryptographic key
distribution, or
FCS_COP.1 Cryptographic
operation],
FCS_CKM.4 Cryptographic key
destruction.
FCS_COP.1/ COS.AES,
FCS_CKM.4
FCS_CKM.1/RSA [FCS_CKM.2 Cryptographic key
distribution, or
FCS_COP.1 Cryptographic
operation],
FCS_CKM.4 Cryptographic key
destruction.
FCS_COP.1/ COS.RSA.S,
FCS_COP.1/ COS.RSA.V,
FCS_COP.1/ COS.RSA,
FCS_CKM.4
FCS_CKM.1/ELC [FCS_CKM.2 Cryptographic key FCS_COP.1/ COS.ELC,
Security Target Lite STARCOS 3.6 COSGKV C1 Page 113 of 134
SFR dependent on fulfilled by
distribution, or
FCS_COP.1 Cryptographic
operation],
FCS_CKM.4 Cryptographic key
destruction.
FCS_COP.1/ COS.ECDSA.S,
FCS_CKM.4
FCS_COP.1/
CB_HASH
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_COP.1 Cryptographic operation,
or
FCS_CKM.1 Cryptographic key
generation],
FCS_CKM.4 Cryptographic key
destruction
The dependent SFRs are not
applicable here because
FCS_COP.1/CB_HASH does
not use any keys.
FCS_COP.1/
COS.CMAC
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation],
FCS_CKM.4 Cryptographic key
destruction
FCS_CKM.1/ AES.SM,
FCS_CKM.4
FCS_COP.1/
COS.RSA.S
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation],
FCS_CKM.4 Cryptographic key
destruction
FCS_CKM.1/RSA,
FCS_CKM.4
FCS_COP.1/
COS.RSA.V
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation],
FCS_CKM.4 Cryptographic key
destruction
FCS_CKM.1/RSA,
FCS_CKM.4
FCS_COP.1/
COS.ECDSA.S
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation],
FCS_CKM.4 Cryptographic key
destruction
FCS_CKM.1/ELC,
FCS_CKM.4
FCS_COP.1/
COS.ECDSA.SV
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
FMT_MTD.1/Auth requires
import keys as of TSF data
used by
6 Security Requirements
Page 114 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
SFR dependent on fulfilled by
security attributes, or
FCS_CKM.1 Cryptographic key
generation],
FCS_CKM.4 Cryptographic key
destruction
FCS_COP.1/COS.ECDSA.V
(instead of import of user data
FDP_ITC.1 or FDP_ITC.2)
FCS_CKM.4
FCS_COP.1/
COS.RSA
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation],
FCS_CKM.4 Cryptographic key
destruction
FCS_CKM.1/RSA,
FCS_CKM.4
FCS_COP.1/
COS.ELC
[FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation],
FCS_CKM.4 Cryptographic key
destruction
FCS_CKM.1/ELC,
FCS_CKM.4
FCS_CKM.4 [FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation]
FCS_CKM.1/ 3TDES_SM,
FCS_CKM.1/ AES.SM,
FCS_CKM.1/RSA,
FCS_CKM.1/ELC,
FTP_ITC.1/TC No dependencies. n. a.
Table 25: Dependencies of the SFR
6.3.3 Security Assurance Requirements Rationale
257 The current assurance package was chosen based on the pre-defined assurance package EAL4.
This package permits a developer to gain maximum assurance from positive security engineering
based on good commercial development practices which, though rigorous, do not require
substantial specialist knowledge, skills, and other resources. EAL4 is the highest level, at which it
is likely to retrofit to an existing product line in an economically feasible way. EAL4 is applicable
in those circumstances where developers or users require a moderate to high level of
independently assured security in conventional commodity TOEs and are prepared to incur
additional security specific engineering costs.
258 Please refer section 6.3.3 “Rationale for the Assurance Requirements” in BSI-CC-PP-0035-
2007 [11] for the details regarding the chosen assurance level EAL4 augmented with
ALC_DVS.2 and AVA_VAN.5.
259 The selection of the component ATE_DPT.2 provides a higher assurance than the pre-defined
EAL4 package due to requiring the functional testing of SFR-enforcing modules. The functional
testing of SFR-enforcing modules is due to the TOE building a smartcard platform with very
broad and powerful security functionality but without object system. An augmentation with
Security Target Lite STARCOS 3.6 COSGKV C1 Page 115 of 134
ATE_DPT.2 only for the SFR specified in BSI-CC-PP-0035-2007 [11] would have been
sufficient to fulfil the conformance, but this would contradict the intention of BSI-CC-PP-0035-
2007. Therefore the augmentation with ATE_DPT.2 is done for the complete Protection Profile.
260 The selection of the component ALC_DVS.2 provides a higher assurance of the security of the
development and manufacturing, especially for the secure handling of sensitive material. This
augmentation was chosen due to the broad application of the TOE in security critical applications.
261 The selection of the component AVA_VAN.5 provides a higher assurance than the pre-defined
EAL4 package, namely requiring a vulnerability analysis to assess the resistance to penetration
attacks performed by an attacker possessing a high attack potential.
262 The set of assurance requirements being part of EAL4 fulfils all dependencies a priori.
263 The augmentation of EAL4 chosen comprises the following assurance components:
(1) ALC_DVS.2,
(2) ATE_DPT.2 and
(3) AVA_VAN.5.
264 For these additional assurance component, all dependencies are met or exceeded in the EAL4
assurance package:
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 -
ATE_DPT.2 ADV_ARC.1 ADV_ARC.1
ADV_TDS.3 ADV_TDS.3
ATE_FUN.1 ATE_FUN.1
AVA_VAN.5 ADV_ARC.1 ADV_ARC.1
ADV_FSP.4 ADV_FSP.4
ADV_TDS.3 ADV_TDS.3
ADV_IMP.1 ADV_IMP.1
AGD_OPE.1 AGD_OPE.1
AGD_PRE.1 AGD_PRE.1
ATE_DPT.1 ATE_DPT.2
Table 26: SAR Dependencies
7 Statement of Compatibility
Page 116 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
7 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 Infineon chip platform IFX M7892 B11. This statement
is compliant to the requirements of [8].
7.1 Classification of the 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.
TOE Security Functionality Relevant
Not
relevant
SF_DPM Device Phase Management x
SF_PS Protection against Snooping x
SF_PMA Protection against Modification
Attacks
x
SF_PLA Protection against Logical Attacks x
SF_CS Cryptographic Support x
Table 27 Classification of Platform-TSFs
All listed TSFs of the Platform-ST are relevant for the Composite-ST.
7.2 Matching statement
The TOE relies on fulfillment of the following implicit assumptions on the IC:
 Certified Infineon microcontroller IFX M7892 B11
 True Random Number Generator (TRNG) according to AIS31 [6].
 Cryptographic support based on symmetric key algorithms (AES, 3-Triple-DES) with 256-512
bits 128, 192, 256 (AES) and 192 bits (3-key Triple-DES) key length.
 Cryptographic support based on asymmetric key algorithms (RSA, ECDSA) with 2048, 3072
bits (RSA modulus) and 256-512 bits (elliptic curve) key length, including key generation.
The rationale of the Platform-ST has been used to identify the relevant SFRs, TOE objectives, threats
and OSPs. 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.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 117 of 134
7.2.1 TOE Security Environment
7.2.1.1 Threats, OSPs and Assumptions
The following OSP of this Composite-ST is directly mappable to the Platform-ST:
• P.Process-TOE
The following threats of this Composite-ST are directly related to IC functionality:
• T.Leak-Inherent
• T.Phys_Probing
• T.Phys_Manipulation
• T.Malfunction
• T.Leak-Forced
• T.Abuse-Func
• T.RND
These threats are mapped to the following Platform-ST threats:
• T.Leak-Inherent
• T.Phys-Probing
• T.Malfunction
• T.Phys-Manipulation
• T.Leak-Forced
• T.Abuse-Func
• T.RND
The following table shows the mapping of the threats.
Platform-ST
T.Leak-Inherent
T.Phys_Probing
T.Phys_Manipulation
T.Malfunction
T.Leak-Forced
T.Abuse-Func
T.RND
T.Leak-Inherent x
T.Phys_Probing x
T.Phys_Manipulation x
T.Malfunction x
T.Leak-Forced x
T.Abuse-Func x
T.RND x
7 Statement of Compatibility
Page 118 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
Table 28 Mapping of threats
T.Leak-Inherent, T.Phys_Probing, T.Phys_Manipulation, T.Malfunction, T.Leak-Forced,
T.Abuse-Func, T.RND from this Composite-ST match directly to the threats in the Platform-ST [47].
7.2.1.2 Assumptions
The assumptions of this security target make no assumptions on the Platform.
The assumptions from the Platform-ST [47] are as follows:
Assumption Classification of
assumptions
Mapping to Security Objectives of this
Composite-ST
A.Process-Sec-IC not relevant n/a
A.Plat-Appl not relevant n/a
A.Resp-Appl relevant O.Phys-Probing, O.Abuse-Func, O.Phy-
Manipulation
A.Key-Function not relevant n/a
Table 29 Mapping of assumptions
There is no conflict between security environments of this Composite-ST and the Platform-ST [47].
7.2.2 Security objectives
This Composite-ST has security objectives which are related to the Platform-ST. These are:
• O.Phys-Probing
• O.Malfunction
• O.Phys-Manipulation
• O.Abuse-Func
• O.Leak-Forced
• O.Leak-Inherent
• O.Identification
• O.RND
• O.Crypto
The following platform objectives could be mapped to composite objectives:
• O.Phys-Probing
• O.Malfunction
• O.Phys-Manipulation
• O.Abuse-Func
• O.Leak-Forced
• O.Leak-Inherent
• O.Identification
• O.RND
• O.Add-Functions
•
Security Target Lite STARCOS 3.6 COSGKV C1 Page 119 of 134
These Platform-ST objectives can be mapped to the Composite-ST objectives as shown in the
following table.
Platform-ST
O.Phys-Probing
O.Malfunction
O.Phys-Manipulation
O.Abuse-Func
O.Leak-Forced
O.Leak-Inherent
O.Identification
O.Add-Functions
O.RND
Composite-ST
O.Phys-Probing x
O.Malfunction x
O.Phys-Manipulation x
O.Abuse-Func x
O.Leak-Forced x
O.Leak-Inherent x
O.RND x
O.Identification x
O.Crypto x
Table 30 Mapping of objectives
The following Platform-ST objectives are not relevant for or cannot be mapped to the Composite-
TOE:
• O.Mem Access is not relevant because the Composite-TOE does not use area based memory access
control.
• None of the Security Objectives for the Environment are linked to the platform and are therefore not
applicable to this mapping.
There is no conflict between security objectives of this Composite-ST and the Platform-ST [47].
7.2.3 Security requirements
6.4.2.3.1 Security Functional Requirements
This Composite-ST has the following platform-related SFRs:
• FCS_COP.1/COS/3TDES
• FCS_COP.1/ COS/AES
• FCS_COP.1/ COS/CMAC
• FCS_COP.1/ COS/RMAC
•
• FCS_RNG.1
• FMT_LIM.1
• FMT_LIM.2
• FPT_EMS.1• FPT_ITT.1
7 Statement of Compatibility
Page 120 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
• FPT_PHP.3
• FPT_FLS.1
• FDP_ITT.1• FAU_SAS.1
The following Platform-SFRs could be mapped to Composite-SFRs:
• FAU_SAS.1
• FCS_COP.1/AES
• FCS_COP.1/DES
• FCS_RNG.1
• FMT_LIM.1
• FMT_LIM.2
• FDP_ITT.1
• FPT_ITT.1
• FPT_PHP.3
• FPT_FLS.1
• FRU_FLT.2
Security Target Lite STARCOS 3.6 COSGKV C1 Page 121 of 134
They will be mapped as seen in the following table.
Platform-ST
FAU_SAS.1
FCS_COP.1/AES
FCS_COP.1/DES
FCS_RNG.1
FMT_LIM.1
FMT_LIM.2
FPT_ITT.1
FDP_ITT.1
FPT_PHP.3
FPT_FLS.1
FRU_FLT.2
Composite-ST
FCS_COP.1/COS/3TDES x
FCS_COP.1/COS/AES x
FCS_COP.1/COS/CMAC x
FCS_COP.1/COS/RMAC x
FCS_RNG.1 x
FMT_LIM.1 x
FMT_LIM.2 x
FPT_EMS.1 x
FPT_ITT.1 x
FPT_PHP.3 x x x
FPT_FLS.1 x
FAU_SAS.1 x
FDP_ITT.1 x
7.3 Analysis
Overall there is no conflict between security requirements of this Composite-ST and the Platform-ST.
8 TOE summary specification
Page 122 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
8 TOE summary specification
This chapter gives the overview description of the different TOE Security Functions composing the
TSF.
8.1 TOE Security Functions
8.1.1 SF_AccessControl
The TOE provides access control mechanisms that allow the restriction of access to only specific users
(world, human users, device) based on different security attributes.
The TOE allows the restriction of access based on following attributes:
Attributes bound to the logical channel:
 Security list (Global and DF, bit)
 Password list (Global and DF).
 Interface: only Contact based.
 Session key context
Attributes bound to an object in the object system (MF, DF, Application, keys):
 Life cycle status.
 SE identifier.
 Interface only Contact based
The TOE enforces access control for following operations:
Commands for using keys (creation and verification of digitial signatures,
tranciphering, enciphering, deciphering)
Commands for using PINs (verification)
Command for generating keys
Command for the deletion of key objects
Command for managing the security environment, PINs
Commands for creation and deletion of objects
Command for reading the fingerprint
Command for reading the public keys
Commands for reading data from files and writing data to files
Command for selecting a file
Security Target Lite STARCOS 3.6 COSGKV C1 Page 123 of 134
Commands for reading the security attributes of PIN/key objects
Commands for reading Key/PIN-based security states that are evaluated by the TOE’s
access control system
The access control mechanisms ensure that access rules can be defined and applied depending on the
life cycle status, security environment and the used interface (i.e. contact based or contactless, where
as contactless communication is not supported by the TOE).
All security attributes under access control are modified in a secure way so that no unauthorised
modifications are possible.
The access control mechanism assures that the access to files, applications (MF, DF, EF) and keys is
limited to specific roles and the privileged access is granted for specific commands depening on
interface, life cycle state, security attributes and context (FDP_ACC.1/MF_DF, FDP_ACF.1/MF_DF,
FDP_ACC.1/EF, FDP_ACF.1/EF, FDP_ACC.1/TEF, FDP_ACF.1/TEF, FDP_ACC.1/SEF,
FDP_ACF.1/SEF, FDP_ACC.1/KEY, FDP_ACF.1/KEY).
The access control mechanism allows to manage and initalize security attributes and TSF data (PINs,
keys) and to query and export certain security attributes in a restrictive way (FMT_SMF.1,
FMT_MSA.1/Life, FMT_MSA.1/SEF, FMT_MSA.3, FMT_MTD.1/PIN, FMT_MSA.1/PIN,
FMT_MTD.1/Auth, FMT_MSA.1/Auth, FMT_MTD.1/NE).
8.1.2 SF_Authentication
After activation or reset of the TOE no user is authenticated.
TSF-mediated actions on behalf of a user require the user’s prior successful identification and
authentication. This user authentication typically implies a device authentication where the device
proofs its identity by proofing the ownership of a cryptographic key. TSF-mediated actions typically
imply also a TOE identification and authentication.
The TOE contains a deterministic random number generator DRG.4 according to AIS20 [5] that
provides random numbers used in the authentication. The seed for the deterministic random number
generator is provided by a true random number generator PTG.2 of the underlying IC.
The TOE supports user and device authentication by the following means:
 PIN/PUK based authentication
 Symmetric Authentication Mechanism based on AES, 3TDES
 Asymmetric Authentication Mechanism based on RSA, ECC
Proving the identity of the TOE is supported by the following means:
 Symmetric Authentication Mechanism based on AES, 3TDES
 Asymmetric Authentication Mechanism based on RSA, ECC
The TOE prevents reuse of authentication data related to:
 Symmetric Authentication Mechanism based on AES, 3TDES
 Asymmetric Authentication Mechanism based on RSA, ECC
After completion of the authentication protocol, the commands exchanged between terminal and TOE
are transferred via secure messaging using the key previously agreed between the terminal and TOE
during the authentication. This assures that after authentication user data in transit is protected from
unauthorized disclosure, modification, deletion, insertion and replay attacks.
8 TOE summary specification
Page 124 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
The authentication mechanism assures that the user and the TOE is successfully identified and
authenticated before an action is performed which requires a user or TOE identification and
authentication before execution, verifies the secrets and handles authentication faiures. The TOE
maintains security attributes for performing the authentication (FIA_ATD.1, FIA_UID.1,
FIA_UAU.1, FIA_UAU.4, FIA_UAU.5, FIA_UAU.6, FIA_API.1, FMT_SMR.1, FIA_USB.1,
FIA_SOS.1, FIA_AFL.1/PIN, FIA_AFL.1/PUC).
8.1.3 SF_AssetProtection
The TOE supports the calculation of block check values for data integrity checking. These block check
values are stored with persistently stored assets (user data) of the TOE as well as temporarily stored
hash values for data to be signed.
The TOE hides information about IC power consumption and command execution time ensuring that
no confidential information can be derived from this information. The TOE detects electromagnetic
radiation with sensors.
The TOE implements asset protection by performing an integrity monitoring of sensitive data (key,
PINs) stored in the object system. Moreover it implements protection mechanisms which assures that
information about IC power consumption and command execution time are not emitted which may be
used to figure out senstive data (keys, PIN/PUC) from the TOE. The TOE allows the export public
data and prohibits the export of secrets, private keys, PIN/PUC and passwords. The TOE verifies the
consistency of TSF data recieved from another trusted IT product by using CV certificates. The TOE
assures that all resources containg senstive information (keys, passwords) which are deallocated are
completely deleted. The TOE provides protection by setting a secure state if failures occures.
(FDP_SDI.2, FPT_ITE.2, FPT_TDC.1, FPT_EMS.1,FDP_RIP.1, FPT_FLS.1, FTP_ITC.1/TC). The
Wrapper exports all public keyauthentication reference data and all security attributes of the object
system for all objects of the object system and for all commands. However, the TOE assures that
secret data, private keys, secure messaging keys, passwords and PUCs cannot be exported.
(FPT_ITE.2).
8.1.4 SF_TSFProtection
The TOE detects physical tampering of the TSF with sensors for operating voltage, clock frequency
and temperature.
The TOE is resistant to physical tampering on the TSF. If the TOE detects with the above mentioned
sensors, that it is not supplied within the specified limits, a security reset is initiated and the TOE is
not operable until the supply is back in the specified limits. The design of the hardware protects it
against analyzing and physical tampering.
The TOE demonstrates the correct operation of the TSF by among others verifying the integrity of the
TSF and TSF data and verifying the absence of fault injections. In the case of inconsistencies in the
calculation of the block check values and fault injections during the operation of the TSF the TOE
preserves a secure state.
The TOE provides protection by setting a secure state if failures occur. The TOE is able to compute a
TOE implementation fingerprint which can be used to check the TOE integrity. It computes self-tests
during the start-up and checks the integritity of the TSF data (FPT_TDC.1, FPT_ITE.1, FPT_FLS.1,
FPT_TST.1).
8.1.5 SF_KeyManagement
The TOE supports onboard generation of cryptographic keys based on ECDH as well as generation of
RSA and ECC key pairs. Moreover it supports the generation of session keys in authentication
mechanisms (sym./asym. crypto) which includes a session key negotiation.
The TOE supports overwriting the cryptographic keys with zero values as follows:
Security Target Lite STARCOS 3.6 COSGKV C1 Page 125 of 134
 any session keys after detection of an error in a received command by verification
of the MAC
 any session keys before starting the communication with the terminal in a new
power-on-session.
 any ephemeral secret having been generated during DH key exchange
 any secret cryptographic keys, private cryptographic keys and session keys after
upon the deallocation of the key object resource
For the cryptographic services the TOE is able to generate cryptographic keys based on random
numbers and performs a destruction once the key is not used any more. (FCS_RNG.1,
FCS_CKM.1/3TDES_SM, FCS_CKM.1/AES.SM, FCS_CKM.1/RSA, FCS_CKM.1/ELC,
FCS_CKM.4).
8.1.6 SF_CryptographicFunctions
The TOE supports secure messaging for protection of the confidentiality and the integrity of the
commands received from a device and response data returned back to the device. Secure messaging is
enforced by the TOE based on access conditions defined for an object of the TOE. The TOE supports
asymmetric cryptographic algorithms to perform authentication procedures, signature computation and
verifications, data decryption and encryption. The TOE supports also symmetric cryptographic
algorithms to perform authentication procedures. The TOE includes hash functions in order to
compute a hash value over defined data. The TOE is able to generate random and contains a
deterministic random number generator DRG.4 according to AIS20 [5] that provides random numbers
used in the authentication. The seed for the deterministic random number generator is provided by a
true random number generator PTG.2 of the underlying IC.
The TOE provides cryptographic services which allows the enchipherment, decipherment,
trancipherment, signature computation/verification based based on ECC and RSA, random number
generation based on physical and hybrid deterministic generator PTG.2 and DRG.4, hash computation
based on SHA algorithms, secure messaging and trusted channels based on AES/TDES, Retail-MAC,
CMAC as well as computation and verification of cryptographic checksum (FCS_RNG.1,
FCS_COP.1/COS.3TDES, FCS_COP.1/COS.CMAC, FCS_COP.1/COS.RMAC,
FCS_COP.1/COS.AES, FCS_COP.1/COS.RSA.S, FCS_COP.1/COS.RSA.V,
FCS_COP.1/COS.ECDSA.S, FCS_COP.1/COS.ECDSA.V,FCS_COP.1/COS.RSA,
FCS_COP.1/COS.ELC, FCS_COP.1/SHA, FTP_ITC.1/TC).
8.2 Assurance Measure
This chapter describes the Assurance Measures fulfilling the requirements listed in chapter 6.2.
The following table lists the Assurance measures and references the corresponding documents
describing the measures.
Assurance Measures Description
AM_ADV The representing of the TSF is described in the documentation for
functional specification, in the documentation for TOE design, in the
security architecture description and in the documentation for
implementation representation.
AM_AGD The guidance documentation is described in the operational user
guidance documentation and in the documentation for preparative
procedures.
8 TOE summary specification
Page 126 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
AM_ALC The life-cycle support of the TOE during its development and
maintenance is described in the life-cycle documentation including
configuration management, delivery procedures, development security as
well as development tools.
AM_ASE This security target document includes the conformance claims, ST
introduction, security objectives, security problem definition and TOE
summary specification.
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 31 References of Assurance measures
8.3 Fulfilment of the SFRs
The following table shows the mapping of the SFRs to security functions of the TOE.
TOE SFR / Security
Function
SF_AccessControl
SF_Authentication
SF_AssetProtection
SF_TSFProtection
SF_KeyManagement
SF_CryptographicFunctions
FIA_AFL.1/PIN x
FIA_AFL.1/PUC x
FIA_ATD.1 x
FIA_UAU.1 x
FIA_UAU.4 x
FIA_UAU.5 x
FIA_UAU.6 x
FIA_USB.1 x
FIA_API.1 x
FMT_SMR.1 x
FDP_ACC.1/EF x
FDP_ACC.1/MF_DF x
FDP_ACC.1/TEF x
FDP_ACC.1/SEF x
FDP_ACC.1/KEY x
FDP_ACF.1/EF x
Security Target Lite STARCOS 3.6 COSGKV C1 Page 127 of 134
TOE SFR / Security
Function
SF_AccessControl
SF_Authentication
SF_AssetProtection
SF_TSFProtection
SF_KeyManagement
SF_CryptographicFunctions
FDP_ACF.1/MF_DF x
FDP_ACF.1/TEF x
FDP_ACF.1/SEF x
FDP_ACF.1/KEY x
FMT_MSA.3 x
FMT_SMF.1 x
FMT_MSA.1/Life x
FMT_MSA.1/SEF x
FMT_MTD.1/PIN x
FMT_MSA.1/PIN x
FMT_MTD.1/Auth x
FMT_MSA.1/Auth x
FMT_MTD.1/NE x
FCS_RNG.1 x x
FCS_CKM.1/3TDES_SM x
FCS_COP.1/COS.3TDES x
FCS_COP.1/COS.CMAC x
FCS_COP.1/COS.RMAC x
FCS_COP.1/COS.AES x
FCS_CKM.1/AES.SM x
FCS_CKM.1/RSA x
FCS_CKM.1/ELC x
FCS_COP.1/SHA x
FCS_COP.1/COS.RSA.S x
FCS_COP.1/COS.RSA.V x
FCS_COP.1/COS.ECDSA.S x
FCS_COP.1/COS.ECDSA.V x
FCS_COP.1/COS.RSA x
FCS_COP.1/COS.ELC x
FCS_COP.1.1/CB_HASH x
8 TOE summary specification
Page 128 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
TOE SFR / Security
Function
SF_AccessControl
SF_Authentication
SF_AssetProtection
SF_TSFProtection
SF_KeyManagement
SF_CryptographicFunctions
FCS_CKM.4 x
FIA_UID.1 x
FIA_SOS.1 x
FTP_ITC.1/TC x x
FDP_SDI.2 x
FDP_RIP.1 x
FPT_FLS.1 x x
FPT_EMS.1 x
FPT_TDC.1 x x
FPT_ITE.1 x
FPT_ITE.2 x
FPT_TST.1 x
Table 32 Mapping of SFRs to mechanisms of TOE
8.3.1 Correspondence of SRF and TOE mechanisms
Each TOE security functional requirement is implemented by at least one TOE mechanism. In section
11.1 TOE Security Functions the implementation of the TOE security functional requirements is
described in form of the TOE mechanism.
Security Target Lite STARCOS 3.6 COSGKV C1 Page 129 of 134
9 Glossary and Acronyms
265 The terminology and abbreviations of Common Criteria version 3.1 [1], [2], [3], Revision 4 and
the specification [21] apply.
Abbreviation Term
CAP Composed Assurance Package
CC Common Criteria
CCRA
Arrangement on the Recognition of Common Criteria Certificates in the field
of IT Security
CM Configuration Management
COS Card operating system
CSP-QC Certification Service Provider for qualified certificates
CVC Card verifiable certificate
EAL Evaluation Assurance Level
EF elementary file
DF Folder, i.e. Application, Dedicated file and Application Dedicated file
eHC Electronic health care card (elektronische Gesundheitskarte)
eHCT Electronic Health Card Terminal
eHPC Electronic professional card (elektronischer Heilberufsausweis)
IC Integrated Circuit
MF Master file
OS Operating System
OSP Organisational Security Policy
PC Personal Computer
PCD Proximity Coupling Device (as defined in [16] part 2)
PICC Proximity Integrated Circuit Chip (as defined in [16] part 2)
PKI Public Key Infrastructure
PP Protection Profile
SAR Security Assurance Requirement
SCA Signature creation applications
SCD Signature creation data
SEF Structured elementary file
SFP Security Function Policy
SFR Security Functional Requirement
SICP Secure integrated chip platform
SMC-B Secure modul card type B
SMC-K Secure modul card type K
SMC-KT Secure modul card type KT
SPD Security Problem Definition
SSCD Secure signature-creation device
SVD Signature verification data
9 Glossary and Acronyms
Page 130 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
Abbreviation Term
ST Security Target
TEF transparent elementary file
TOE Target of Evaluation
TSF TOE Security Functionality
TSFI TSF Interface
Security Target Lite STARCOS 3.6 COSGKV C1 Page 131 of 134
10 Bibliography
Common Criteria
[1] Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
General Model; CCMB-2012-09-001, Version 3.1, Revision 4, September 2012
[2] Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional
Components; CCMB-2012-09-002, Version 3.1, Revision 4, September 2012
[3] Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Requirements; CCMB-2012-09-003, Version 3.1, Revision 4, September 2012
[4] Common Methodology for Information Technology Security Evaluation, Evaluation
Methodology; CCMB-2012-09-004, Version 3.1, Revision 4, September 2012
[5] AIS20: Functionality classes and evaluation methodology for deterministic random number
generators, Version 2.1, 02.12.2011, Bundesamt für Sicherheit in der Informationstechnik
[6] AIS31: Functionality classes and evaluation methodology for true (physical) random number
generators, Version 2.1, 02.12.2011, Bundesamt für Sicherheit in der Informationstechnik
[7] W. Killmann, W. Schindler, „A proposal for: Functionality classes for random number
generators“, Version 2.0, September 18, 2011
[8] CC Supporting Document, Composite product evaluation for Smart Cards and similar devices,
April 2012, Version 1.2, CCDB-2012-04-001
[9] Supporting Document Mandatory Technical Document: The Application of CC to Integrated
Circuits, March 2009, Version 3.0, Revision 1, CCDB-2009-03-002
[10] Supporting Document Guidance, Smartcard Evaluation, February 2010, Version 2.0, CCDB-
2010-03-001
Protection Profiles
[11] Protection Profile Security IC Platform Protection Profile developed by Atmel, Infineon
Technologies AG, NXP Semiconductors, Renesas Technology Europe Ltd.,
STMicrocontrolles, Registered and Certified by Bundesamt für Sicherheit in der
Informationstechnik (BSI) under the reference BSI-PP-0035, Version 1.0, 15.06.2007
[12] prEN 14169-2:2012: Protection profiles for secure signature creation device — Part 2: Device
with key generation, BSI-CC-PP-0059
[13] prEN 14169-3:2012: Protection profiles for secure signature creation device — Part 3: Device
with key import, BSI-CC-PP-0075
[14] prEN 14169-4:2012: Protection profiles for secure signature creation device — Part 4:
Extension for device with key generation and trusted communication with certificate
generation application, BSI-CC-PP-0071
[15] prEN 14169-5:2012: Protection profiles for secure signature creation device — Part 5:
Extension for device with key generation and trusted communication with signature creation
application, BSI-CC-PP-0072
[50] BSI-CC-PP-0082-V2 Common Criteria Protection Profile Card Operating System Generation
2 (PP COS G2), Version 1.9, 18th
November 2014
10 Bibliography
Page 132 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
Technical Guidelines and Specification
[16] Technical Guideline TR-03110 Advanced Security Mechanisms for Machine Readable Travel
Documents Part1 – eMRTDs with BAC/PACEv2 and EACv1, Part 2, Part 2 – Extended
Access Control Version 2 (EACv2), Password Authenticated Connection Establishment
(PACE),and Restricted Identification (RI), Part 3 – Common Specifications, TR-03110,
version 2.10, 24.03.2012, Bundesamt für Sicherheit in der Informationstechnik (BSI)
[17] Technical Guideline TR-03111 Elliptic Curve Cryptography, TR-03111, version 2.0,
28.08.2012, Bundesamt für Sicherheit in der Informationstechnik (BSI)
[18] Technische Richtlinie TR-03114 Stapelsignatur mit dem Heilberufsausweis, BSI, Version:
2.0, 22.10.2007
[19] Technische Richtlinie TR-03116, eCard-Projekte der Bundesregierung, Version 3.18 vom
30.01.2014, Bundesamt für Sicherheit in der Informationstechnik (BSI)
[20] Technische Richtlinie TR-03143 „eHealth G2-COS Konsistenz-Prüftool“, Version 1,.0 vom
8.5.2015, Bundesamt für Sicherheit in der Informationstechnik (BSI)
[21] Einführung der Gesundheitskarte, Spezifikation des Card Operating System (COS),
Elektrische Schnittstelle, Version 3.7.0 vom 26.08.2014, gematik Gesellschaft für
Telematikanwendungen der Gesundheitskarte GmbH einschließlich der Errata zu Release
1.4.0 Online-Rollout (Stufe 1) Erprobung und Produktivbetrieb führt zu Release 1.4.1 vom
02.10.2014 und 2. Errata zu Release 1.4.0 Online-Rollout (Stufe 1) Erprobung und
Produktivbetrieb führt zu Release 1.4.2 vom 06.10.2014
[22] Einführung der Gesundheitskarte Spezifikation der elektronischen Gesundheitskarte eGK-
Objektsystem, Version: 3.8.0 vom 26.08.2014, gematik Gesellschaft für
Telematikanwendungen der Gesundheitskarte GmbH
[23] Einführung der Gesundheitskarte Spezifikation des elektronischen Heilberufsausweises HBA-
Objektsystem, 3.7.0 vom 21.02.2014, gematik Gesellschaft für Telematikanwendungen der
Gesundheitskarte GmbH
[24] Einführung der Gesundheitskarte Spezifikation der Secure Module Card SMC-B
Objektsystem, Version 3.7.0 vom 26.08.2014, gematik Gesellschaft für
Telematikanwendungen der Gesundheitskarte GmbH
[25] Einführung der Gesundheitskarte Spezifikation der gSMC-K Objektsystem, Version 3.4.0
vom26.08.2014, gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte
GmbH
[26] Einführung der Gesundheitskarte Spezifikation gSMC-KT Objektsystem, Version 3.4.0
vom26.08.2014, gematik Gesellschaft für Telematikanwendungen der Gesundheitskarte
GmbH
[27] Einführung der Gesundheitskarte Spezifikation Wrapper, Version 1.6.0, 26.08.2014, gematik
Gesellschaft für Telematikanwendungen der Gesundheitskarte GmbH
[27a] Errata zu Release 1.4.2 Online-Rollout (Stufe 1) Erprobung und Produktivbetrieb, Release
1.4.3
[27b] 2. Errata zu Release 1.4.0, Online-Rollout (Stufe 1) Erprobung und Produktivbetrieb, Release
1.4.2
Cryptography
[28] ISO/IEC 7816-3: 2006 (2nd edition), Identification cards — Integrated circuit cards with
contacts —Part 3: Electrical interface and transmission protocols
[29] ISO/IEC 7816-4: 2005 (2nd edition) Identification cards — Integrated circuit cards— Part 4:
Organisation, security and commands for interchange
Security Target Lite STARCOS 3.6 COSGKV C1 Page 133 of 134
[30] ISO/IEC 7816-8: 2004 (2nd edition) Identification cards — Integrated circuit cards— Part 8:
Commands for security operations
[31] ISO/IEC 9796-2:2010 Information technology -- Security techniques -- Digital signature
schemes giving message recovery -- Part 2: Integer factorization based mechanisms
[32] ISO/IEC 9797-1 Information technology – Security techniques – Message Authentication
Codes (MACs) – Part 1: Mechanisms using a block cipher
[33] Federal Information Processing Standards Publication 197, ADVANCED ENCRYPTION
STANDARD (AES), U.S. DEPARTMENT OF COMMERCE/National Institute of Standards
and Technology, November 26, 2001
[34] PKCS #1: RSA Cryptography Standard, RSA Laboratories, Version 2.2, October 27, 2012
(http://www.rsa.com/rsalabs/node.asp?id=2125)
[35] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA Laboratories Technical Note,
Version 1.4, Revised November 1, 1993
[36] Recommendation for Block Cipher Modes of Operation: The CMAC Mode for
Authentication, NIST Special Publication 800-38B, National Institute of Standards and
Technology, May 2005
[37] Federal Information Processing Standards Publication 180-4 SECURE HASH STANDARD
U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology,
2011 February, 11
[38] NIST SP 800-67, Recommandation for the Triple Data Encryption Algorithm (TDEA) Block
Cipher, National Institute of Standards and Technology
[39] American National Standard X9.62-2005, Public Key Cryptography for the Financial Services
Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA), November 16, 2005
[40] American National Standard X9.63-2001, Public Key Cryptography for the Financial Services
Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography, November
16, 2005
[41] Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation, RFC
5639, March 2010, http://tools.ietf.org/html/rfc5639
[42] ANSI X9.62 Public Key Cryptography for the Financial Services Industry, The Elliptic Curve
Digital Signature Algorithm (ECDSA), 2005
Other Sources
[43] ISO 7498-2 (1989): ‘Information processing systems - Open Systems Interconnection - Basic
Reference Model - Part 2: Security Architecture’
[44] Law Governing Framework Conditions for Electronic Signatures of 16 May 2001 (Federal
Law Gazette I page 876), last amended by Article 4 of the Act of 17 July 2009 (Federal Law
Gazette I page 2091)
[45] Ordinance on Electronic Signature of 16 November 2001 (Federal Law Gazette I page 3074),
last amended by the Act of 15 November 2010 (Federal Law Gazette I page 2631)
[47] Security Target Lite - M7892 B11 – Recertification – Including optional Software Libraries
RSA – EC – SHA-2 – Toolbox - Version 0.3, 2015-10-13, BSI-DSZ-CC-0782-V2-2015
Additional references
[48] Joint Interpretation Library: PP0084: Changes and Compliance to PP0035 and Transition
Phase, JIL application note on the transition from BSI-CC-PP-0035-2007-2007 to BSI-CC-
PP-0084-2014, Version 1.1, August 2014
[49] Protection Profile Security IC Platform Protection Profile with Augmentation Packages
developed by Inside Secure Infineon Technologies AG NXP Semiconductors Germany GmbH
10 Bibliography
Page 134 of 134 Security Target Lite STARCOS 3.6 COSGKV C1
STMicroelectronics, Registered and Certified by Bundesamt für Sicherheit in der
Informationstechnik (BSI) under the reference BSI-CC-PP-0084-2014, Version 1.0