Document ID: CD.TCOS.ASE
Date: 2025-09-25
Version: 2.0.1
Hardware Base: P71
Autor: DT-Sec, Trustcenter & ID Smartcards
Confidentiality Level: Public
©
Deutsche Telekom Security GmbH, 2025
Forwarding and duplication of this documentation, utilization and communication
of its content are prohibited unless expressly permitted. Violations oblige to com-
pensation. All rights reserved, particularly in the case of a patent grant or utility
model registration.
Specification of the Security Target
TCOS CSP Module Version 2.0
Release 1/P71
Version: 2.0.1/20250925
Security Target TCOS CSP Module Version 2.0 Release 1/P71 2/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
History
Version Date Remark
2.0.1 2025-09-25 Final document
Security Target TCOS CSP Module Version 2.0 Release 1/P71 3/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Contents
Contents ..................................................................................................................................................3
1 ST Introduction........................................................................................................................5
1.1 ST Reference ............................................................................................................................5
1.2 TOE Reference .........................................................................................................................5
1.3 TOE Overview...........................................................................................................................5
1.3.1 TOE security features for operational use ...........................................................................7
1.3.2 TOE Type.............................................................................................................................7
1.3.3 File System of the TOE........................................................................................................8
1.3.4 Life Cycle Phases Mapping .................................................................................................8
1.3.5 Non-TOE hardware/software/firmware ..............................................................................10
1.3.6 TOE Boundaries.................................................................................................................10
1.3.7 Evaluated package types...................................................................................................10
1.3.8 Deliverables .......................................................................................................................11
2 Conformance Claims ............................................................................................................13
2.1 CC Conformance Claims ........................................................................................................13
2.2 PP Claims ...............................................................................................................................13
2.3 Package Claims ......................................................................................................................14
2.4 Conformance Claim Rationale ................................................................................................14
3 Security Problem Definition.................................................................................................15
3.1 Assets and External Entities ...................................................................................................15
3.2 Threats ....................................................................................................................................18
3.3 Organizational Security Policies .............................................................................................19
3.4 Assumptions............................................................................................................................20
4 Security Objectives...............................................................................................................21
4.1 Security Objectives for the TOE..............................................................................................21
4.2 Security Objectives for the Operational Environment .............................................................22
4.3 Security Objective Rationale...................................................................................................23
5 Extended Components Definition .......................................................................................25
5.1 FPT_TCT Inter-TSF TSF data confidentiality transfer protection ...........................................25
5.2 FPT_TIT Inter-TSF TSF data integrity transfer protection......................................................26
5.3 FPT_ISA TSF data import with security attributes..................................................................26
5.4 FPT_ESA TSF data export with security attributes ................................................................27
6 Security Requirements.........................................................................................................29
6.1 Security Functional Requirements for the TOE ......................................................................29
6.1.0 Overview ............................................................................................................................29
6.1.1 Key management...............................................................................................................32
6.1.2 Data encryption..................................................................................................................49
6.1.3 Hybrid encryption with MAC for user data .........................................................................49
6.1.4 Data integrity mechanisms.................................................................................................50
6.1.5 Authentication and attestation of the TOE, trusted channel ..............................................54
Security Target TCOS CSP Module Version 2.0 Release 1/P71 4/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
6.1.6 User identification and authentication................................................................................58
6.1.7 Access control....................................................................................................................63
6.1.8 Security Management ........................................................................................................71
6.1.9 Security audit .....................................................................................................................74
6.1.10 Protection of the TSF .........................................................................................................77
6.1.11 Import and verification of Update Code Package ..............................................................80
6.2 Security Assurance Requirements for the TOE......................................................................84
6.3 Security Requirements Rationale ...........................................................................................84
6.3.1 Rationale for SFR’s Dependencies....................................................................................84
6.3.2 Security Assurance Requirements Rationale ....................................................................87
7 TOE Summary Specification................................................................................................88
7.1 Key Management ....................................................................................................................88
7.2 Data Encryption.......................................................................................................................90
7.3 Hybrid Encryption with MAC for User Data.............................................................................90
7.4 Data Integrity Mechanisms .....................................................................................................90
7.5 Authentication and Attestation of the TOE, Trusted Channel.................................................90
7.6 User Identification and Authentication ....................................................................................91
7.7 Security Management .............................................................................................................91
7.8 Access Control ........................................................................................................................92
7.9 Security Audit ..........................................................................................................................92
7.10 Protection of the TSF ..............................................................................................................93
7.11 Import and Verification of Update Code Package...................................................................93
7.12 Statement of Compatibility ......................................................................................................94
7.12.1 Relevance of Hardware TSFs............................................................................................94
7.12.2 Security Requirements.......................................................................................................94
7.12.3 Security Objectives ............................................................................................................97
7.12.4 Conclusion .........................................................................................................................98
7.13 Assurance Measures ..............................................................................................................98
Appendix: Keywords and Abbreviations .........................................................................................100
References ..........................................................................................................................................102
Security Target TCOS CSP Module Version 2.0 Release 1/P71 5/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
1 ST Introduction
1 This section provides document management and overview information that are required
a potential user of the TOE to determine, whether the TOE fulfils her requirements.
1.1 ST Reference
2 Title: Specification of the Security Target TCOS CSP Module
Version 2.0 Release 1/P71
TOE: TCOS CSP Module Version 2.0 Release 1/P71
Sponsor: Deutsche Telekom Security GmbH
Editor(s): Deutsche Telekom Security GmbH, DT-Sec
CC Version: CC:2022 Release 1
Assurance Level: EAL4 augmented with ALC_DVS.2, ALC_FLR.1, ATE_DPT.2 and
AVA_VAN.5.
General Status: Final Document
Version Number: 2.0.1
Date: 2025-09-25
Certification ID: BSI-DSZ-CC-1264
Keywords: Cryptographic Service Provider, TCOS
1.2 TOE Reference
3 This Security Target refers to the Product “TCOS CSP Module Version 2.0 Re-
lease 1/P71” (TOE) of Deutsche Telekom Security GmbH for CC evaluation.
1.3 TOE Overview
4 The Target of Evaluation (TOE) addressed by this Security Target is a chip with contact-
based interfaces programmed according to [ISO7816]. The TOE is dedicated to provid-
ing cryptographic services for the protection of the confidentiality and the integrity of user
data, and for entity authentication. In this ST the TOE as a whole is called Security
Component.
5 The TOE is prepared to be used in composed IT products comprising the TOE and one
or more application components. The TOE provides the security services for these ap-
plications.
6 The TOE is defined as a device consisting of hardware, firmware and software and is
implemented as a security integrated circuit.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 6/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
7 The TOE security functionality (TSF) is logically defined by a common set of crypto-
graphic and non-cryptographic security services for users and mechanisms for internal
use. The cryptographic services for users comprise
• authentication of users,
• authentication and attestation of the TOE to entities,
• data authentication and non-repudiation including time stamps,
• encryption and decryption of user data,
• trusted channel including mutual authentication of the communicating entities,
encryption and message authentication proof for the sent data, decryption and
message authentication verification for received data,
• management of cryptographic keys with security attributes including key generation,
key derivation and key agreement, internal storage of keys, import and export of
keys with protection of their confidentiality and integrity,
• generation of random bits which may be used for security services outside the TOE.
8 The TSF provides a non-cryptographic real time service.
• The time service allows the user to query the internal time of the TSF.
• The time stamp service provides evidence that user data were presented to the TSF
and exported audit data, were generated at certain point in time and in a verifiable
sequence.
9 The audit functionality generates audit records on selected user activities controlled by
the TSF and security events of the TOE.
10 The TOE uses memory encryption for protection of internally stored data.
11 The TOE provides its services in a Client-Server architecture, where the TOE (Security
Component) and the Application Component are physically separated interacting
through a trusted channel. The Application component (in client role) uses the security
services of the TOE (in server role).
12 The communication between the TOE and the application is protected by means of se-
cure channel according to [CC]. The TOE supports cryptographically protected trusted
channels between the TOE and the external entities.
13 The internal cryptographic TSF is used for
• TSF data import including certificates and cryptographic keys,
• confidentiality protection of stored user data and TSF data.
14 The TOE implements means to prove its own identity. The authentication keys are man-
aged by the TOE manufacturer, the vendor or another trusted identity depending on the
life cycle phase.
15 The non-cryptographic TSF provides human user authentication, access control on cryp-
tographic TSF and cryptographic keys and TSF protection.
16 The TOE provides a time service, time stamp service and security audit.
17 The TOE supports download, authenticity verification and decryption of Update Code
Packages for the CSP.
18 This version of the TOE does not support clustering of TOE samples.
19 The hardware may be relevant in some context, and if so, the TOE will be identified in
more detail as “TCOS CSP Module Version 2.0 Release 1/P71”, otherwise the shorter
Security Target TCOS CSP Module Version 2.0 Release 1/P71 7/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
notion “TCOS CSP Module Version 2.0 Release 1” will be used, indicating that this con-
text may be applicable to any realization regardless which hardware base is used. The
TOE follows the composite evaluation aspects ([AIS36]). The Security Target of the un-
derlying platform ([HWST]) claims conformance to Smartcard IC Platform Protection Pro-
file ([ICPP]).
20 This composite ST is based on the ST of the underlying platform ([HWST]). The compa-
tibility of the Life Cycle Model of the Protection Profile [CSPPP] and the Life Cycle Model
required by [ICPP] will be shown in chap. 1.3.4, as required by [JIL].
21 The TOE comprises of
• the circuitry of the chip including all IC Dedicated Software being active in the Oper-
ational Phase of the TOE (the integrated circuit, IC),
• the IC Embedded Software (ES, Card Operating System, OS) including configura-
tion and initialization data related to the security functionality of the chip,
• the Application Software (AS) providing the implemented services, and
• the associated guidance documentation including the more detailed description of
the file system.
22 The Guidance documentation ([TCOSGD]) provides further requirements for the manu-
facturer and security measures required for protection of the TOE until reception by the
end-user. In addition, the guidance contains in chapter 9.9 a detailed description of the
delivery items and their protection.
1.3.1 TOE security features for operational use
23 The TOE security services are logically separated and provided through well-defined
external interfaces. The TSF is self-contained, i.e. it is provided by the TOE itself. The
operational environment cannot affect the security and correctness of the TSF, but it
supports the availability of the TSF.
1.3.2 TOE Type
24 The TOE’s type addressed by this ST is according to [CSPPP] an integrated circuit (IC)
providing different cryptographic services.
25 The typical life cycle phases for the current TOE type are development, manufacturing,
combining with the intended Application Component and operational use. The life cycle
phase development includes development of the IC itself and IC embedded software.
Manufacturing includes IC manufacturing and smart card manufacturing, and installation
of a card operating system. Installing includes completion of the operating system, instal-
lation of the smart card applications and their electronic personalization, i.e. tying the
application data up to the Application Component.
26 Operational use of the TOE is explicitly in the focus of the Protection Profile [CSPPP].
Nevertheless, some TOE functionality is already available in the manufacturing and the
card issuing life cycle phases. Therefore, it is also considered in this ST.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 8/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
1.3.3 File System of the TOE
27 The TOE is configured with a dedicated file system during life cycle phase 2 “Manufac-
turing”. It is described in more detail in the Admin Guidance [TCOSGD].
1.3.4 Life Cycle Phases Mapping
28 Following the JIL Guidance for Smart Card Evaluation [JIL] the life cycle phases of a
smart card can be divided into the following seven phases:
Phase 1: Smartcard Embedded Software Development
Phase 2: IC Development
Phase 3: IC Manufacturing and Testing
Phase 4: IC Packaging and Testing
Phase 5: Smartcard Product Finishing Process
Phase 6: Smart Card Personalization
(Phase 6 is sub-divided in the phases 6.1 Installation and 6.2 Personalization)
Phase 7: Operational Use
29 This is the base for the TOE life cycle. It is described in terms of the following four life
cycle phases, subdivided in 7 steps, with respect to [JIL].
Life cycle phase 1 “Development”
30 Step 1: The TOE is developed in phase 1. The IC developer develops the integrated
circuit, the IC dedicated software and the guidance documentation associated with these
TOE components.
31 Step 2: The software developer uses the guidance documentation for the integrated cir-
cuit and the guidance documentation for relevant parts of the IC dedicated software, and
develops the IC embedded software (operating system), the application(s) and the guid-
ance documentation associated with these TOE components.
32 The manufacturing documentation of the IC including the IC dedicated software and the
embedded software in the non-volatile non-programmable memories is securely deliv-
ered to the IC manufacturer. The IC embedded software in the non-volatile programma-
ble memories and the application(s) is securely delivered to the IC manufacturer.
33 This life cycle phase steps cover exactly phase 1 and phase 2 of [JIL]].
Life cycle phase 2 “Manufacturing and Pre-Personalization”
34 Step 3: In a first step, the TOE integrated circuit is produced. The circuit contains IC ded-
icated software, and the parts of the TOE’s embedded software (ES) in the non-volatile
non-programmable memory (ROM). The IC manufacturer writes IC identification data on-
to the chip to track and control the IC during manufacturing, and during delivery to Appli-
cation Component manufacturer. The IC manufacturer adds parts of the IC embedded
software, the object system and keys in the non-volatile programmable memory, e.g.
EEPROM.
35 Step 4: The IC may be delivered as a wafer, module or a packaged component, possibly
combined with hardware for the contact-based interface.
36 Step 5: The IC manufacturer
• adds the IC embedded software, or parts of it in the non-volatile programmable
memories, e.g. EEPROM or FLASH,
Security Target TCOS CSP Module Version 2.0 Release 1/P71 9/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
• creates the application(s), and
• equips the TOE’s chip with pre-personalization data.
37 The first step in this phase, also named phase 5.1, is called Completion, and the one
and only user of the TOE in this stage is the Completion Agent acting as manufacturer.
After Completion the operating system cannot be changed anymore, the access proto-
cols and the TSF are ready to use.
38 The other two steps, also known as phase 5.2 and phase 6, are called Installation. The
one and only one user of the TOE in this stage is the Installation Agent. This step is
sometimes also called Pre-Personalization. Creation of the application(s) implies the
creation of the master file (MF), dedicated files (DFs), and elementary files (EFs) accord-
ing to [ISO7816].
39 During Pre-Personalization the Installation agent installs keys used for key derivation
and update-in-field procedure. Further the TOE is delivered with an attestation key for at-
testation as genuine sample of the certified product, cf. chapter 6.1.5.
40 Note that step 5 and step 6 is implemented technically as part of step 3.
After Installation, the TOE is prepared for the pairing with the Application Component
and the import and generation of individual data.
41 TOE delivery appears after Pre-Personalization. The TOE is delivered as a chip
with a completed Operating System and a ready to personalization object system.
42 Application Note 1: The IC personalization phase should not be confused with the TOE’s
personalization after integration in the Application Component, which takes place only in
the next life cycle phase of the TOE.
43 The security environment for the TOE and the ST of the underlying platform match, the
IC life cycle phases up to 6 are covered by a controlled environment as required in
[HWCR, p. 41]. In IC life cycle phase 7 no restrictions apply.
Life cycle phase 3 “Personalization of the CSP”
44 Step 7. This life cycle phase corresponds to the first step of Phase 7 of [JIL].
45 The pre-personalized TOE together with the IC identifier is securely delivered from the
TOE manufacturer to the Application Component manufacturer. The TOE is personal-
ized in this phase and bound to the dedicated component. The authentication data for
Personalization is delivered securely to the Application Component manufacturer.
46 The personalization of TOE includes
1. the check of the authenticity of the TOE using the attestation key of the TOE,
2. the check that the TOE is in the original state using the user administrator’s
password,
3. the generation of application depending keys, and
4. configuration of the TSF, if necessary.
47 Configuration of the TSF is performed by the Personalization Agent.
48 This cycle phase is already an operational use of the composite product and not a per-
sonalization of the hardware. The hardware’s “Personalization” (cf. [HWST]) ends with
the Installation of the TOE (installation of the object system).
Life cycle phase 4 “Operational Use”
49 Step 7: The security functions of the TOE are used by the Application Component.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 10/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
50 This life cycle phase corresponds to the rest of Phase 7 of [JIL].
51 The life cycle of the TOE ends with implementation of any update code package chang-
ing the TOE to a new IT product.
1.3.5 Non-TOE hardware/software/firmware
52 There is no explicit non-TOE hardware, software or firmware required by the TOE to
perform its claimed security features.
1.3.6 TOE Boundaries
1.3.6.1 TOE Physical Boundaries
53 Smartcard as used in this ST means an integrated circuit containing a microprocessor,
(CPU), a coprocessor for special (cryptographic) operations, a random number gene-
rator, volatile and non-volatile memory, and associated software, packaged and em-
bedded in a carrier. The integrated circuit is a single chip incorporating CPU and me-
mory, which include RAM, ROM, and Flash.
54 The chip is embedded in a module, which provides the capability for standardized con-
nection to systems separate from the chip through TOE’s interfaces in accordance with
ISO standards.
55 The physical constituent of the TOE is the initialized chip with an operating system in
ROM and Flash and an installed object system.
1.3.6.2 TOE Logical Boundaries
56 All card accepting devices (Host Applications) will communicate through the I/O interface
of the operating system by sending and receiving octet strings. The logical boundaries of
the TOE are given by the complete set of commands of the TCOS operating system for
access, reading, writing, updating or erasing data.
57 The input to the TOE is transmitted over the physical interface as an octet string that has
the structure of Command Application Protocol Data Unit (CAPDU). The output octet
string from the TOE has the structure of a Response Application Protocol Data Unit
(RAPDU).
58 The Application Protocol Data Units or TCOS commands that can be used in the opera-
ting systems are described in more detail in another document.
1.3.7 Evaluated package types
59 The TOE can be delivered in several package types as defined in [HWST]:
• Wafer,
• Contact-less module,
• HVQFN20
Security Target TCOS CSP Module Version 2.0 Release 1/P71 11/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
60 Details about the package types can be found in [DSheet_WaferSpec]. Because wafer is
one of the evaluated package types all packages derived from this are also evaluated
package types.
1.3.8 Deliverables
Type Delivery Item Release Form of Delivery
HW/SW NXP Secure Smart
Card Controller P71
/ N7122 including its
IC Dedicated Soft-
ware
(see HW platform [HWST], [HWCR])
Hardware platform:
NXP P71D600
Wafer-Image (ChipExe):
WaferImageTCOS-
CSP20_HW04_MBBADM03020600_submission_1
The hardware part of
the TOE is delivered
by the HW Manufac-
turer in an insured
parcel to the Installa-
tion Agent. In the life
cycle of the TOE the
hardware is always
protected by an au-
thentication proce-
dure.
SW IC Embedded Soft-
ware (TCOS operat-
ing system)
TOE Embedded Software (the operating system
and completion data) TCOS CSP Module Version
2.0 Release 1/P71
OS Version: '03 02 06 00'
Completion Code Version: '00 01'
The OS part of the
TOE is implemented
in Flash of the IC, see
above. The OS, App
and Filesystem are
installed on the HW
Platform by WaferI-
nitialization by the HW
Manufacturer.
SW IC Application Soft-
ware (file system
including the CSP
Module application)
Application Version: '01 00 00 00'
Application Completion Code Version: '00 00'
The application and
filesystem part of the
TOE is implemented
in Flash of the IC, see
above. The OS, App
and Filesystem are
installed on the HW
Platform by WaferI-
nitialization by the HW
Manufacturer.
DOC Associated guid-
ance documentation
(Usage
Guidance)
TCOS CSP Module
2.0 Release 1/P71
User guidance manual,
Version 2.0.1, 25.09.2025
The guidance docu-
ment of the TOE are
delivered always in an
encrypted and signed
form. Therefore the
integrity and authen-
ticity (key validation)
can be ensured dur-
ing the delivery.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 12/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
DOC Associated guid-
ance documentation
(Personalization
Guidance)
TCOS CSP Module
Personalization
Guidance, Version 1.5,
25.08.2025
The guidance docu-
ment of the TOE are
delivered always in an
encrypted and signed
form. Therefore the
integrity and authen-
ticity (key validation)
can be ensured dur-
ing the delivery.
DOC Public part of the
Attestation key
The key is intended for the (extended) device at-
testation as genuine sample of the certified prod-
uct
The public key part of
the attestation key for
device attestation as
genuine sample of the
certified product is
published in
[TCOSGD].
DOC Initial User Admin
password value
Initial password value to check that the TOE is in
initial state and to change the User Admin pass-
word to the operational value
Textfile that contains
the intial user admin
password value as
one line of hex-coded
bytes. The Textfiles
are delivered always
in an encrypted and
signed form. There-
fore the integrity and
authenticity (key vali-
dation) can be en-
sured during the de-
livery.
DOC Secret Key Deriva-
tion Key -–
HMAC
The Key is used for Key derivation according to
[TCOSGD], chapter 8.1.5.6.
Textfile that contains
the Secret Key Deri-
vation Key content as
one line of hex-coded
bytes. The Textfiles
are delivered always
in an encrypted and
signed form. There-
fore the integrity and
authenticity (key vali-
dation) can be en-
sured during the de-
livery.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 13/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
2 Conformance Claims
2.1 CC Conformance Claims
61 This Security Target claims conformance to Common Criteria for Information Technology
Security Evaluation [CC],
Common Criteria Version CC:2022 Release 1,
• Part 1: Introduction and general model
• Part 2: Security functional components
• Part 3: Security assurance components
• Part 4: Framework for the specification of evaluation methods and activities
• Part 5: Pre-defined packages of security requirements
as follows:
Part 2 extended, Part 3 conformant.
The Common Methodology for Information Technology Security Evaluation, Evaluation
methodology, November 2022 CEM:2022 Revision 1, CCMB-2022-11-006 [CC] has to
be taken into account.
2.2 PP Claims
62 This ST claims strict conformance to the Base-PP
Common Criteria Protection Profile ‘Cryptographic Service Provider’, Version 0.9.8,
Registered and Certified by Bundesamt für Sicherheit in der Informationstechnik un-
der BSI-CC-PP-0104-2019, 2019-02
63 This ST claims strict conformance to the PP-Module
Common Criteria Protection Profile Module ‘Cryptographic Service Provider Time
Stamp and Audit’, Version 0.9.5, Registered and Certified by Bundesamt für Sicher-
heit in der Informationstechnik under BSI-CC-PP-0107-2019, 2019-05
64 Application Note 2: Both PPs are based on Common Criteria Version 3.1. This document
will explain and resolve any discrepancies, inconsistencies and deviations within applica-
tions notes or foot notes.
65 Application Note 3: The extended component FCS_CKM.5 defined in the BasePP
(([CSPPP]) is not taken over in this ST. The Common Criteria Version CC:2022 ([CC]
does also define a component named FCS_CKM.5. There is no difference in both defini-
tions, therefore no application notes in the iterations of FCS_CKM.5. are required
66 Application Note 4: The extended component definition FCS_RNG defined in the
BasePP (([CSPPP]) is not taken over in this ST. The Common Criteria Version CC:2022
([CC] does also define a component named FCS_RNG.1. The definition from CC:2022
differs only in FCS_RNG.1.2 to the one of the Base-PP. The definition of the Base-PP
can be seen as a subset of the definition from CC:2022.
67 Application Note 5: The extended component definition FIA_API defined in the BasePP
(([CSPPP]) is not taken over in this ST. The Common Criteria Version CC:2022 ([CC]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 14/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
does also define a component named FIA_API. The definition from CC:2022 differs only
slightly in the description of the family behaviour.
68 Application Note 6: The extended component definition FDP_SDC defined in the
BasePP (([CSPPP]) is not taken over in this ST. The Common Criteria Version CC:2022
([CC] does also define a component named FDP_SDC. The definition of the Base-PP
can be seen as a subset of the definition from CC:2022.
2.3 Package Claims
69 The evaluation of the TOE is a composite evaluation and uses the results of the CC
evaluation provided by [HWCR]. The IC hardware platform and its primary embedded
software are evaluated at level EAL 6+.
70 The evaluation assurance level of the TOE is EAL4 augmented with ALC_DVS.2,
ALC_FLR.1, ATE_DPT.21 and AVA_VAN.5 as defined in [CC]2.
2.4 Conformance Claim Rationale
71 The TOE type is a chip consistent with the TOE type of the claimed PPs ([CSPPP],
[CSPMOD]).
1 ALC_FLR.1 and ATE_DPT.2 were not augmented in the Base-PP but added in this security target.
2 In this ST the backslash provides line breaks for CC conformant identifiers. It should not be considered as a part of the
identifier. Identifiers containing natural words are hyphenated as usual.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 15/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
3 Security Problem Definition
3.1 Assets and External Entities
Assets
72 The assets of the TOE are
• user data which integrity and confidentiality shall be protected,
• cryptographic services and keys which shall be protected against unauthorized use or
misuse,
• Update Code Packages (UCP).
73 The cryptographic keys are TSF data because they are used for cryptographic opera-
tions protecting user data and the enforcement of the SFR relies on these data for the
operation of the TOE.
Users and subjects
74 The TOE knows external entities (users) as
• human user communicating with the TOE for security management of the TOE,
• application component using the cryptographic and other security services of the TOE
and supporting the communication with remote entities (e. g. by providing certifi-
cates),
• remote entity exchanging user data and TSF data with the TOE over insecure media.
75 The TOE communicates with
• human user through a secure channel,
• application component through a secure channel,
• remote entities over a trusted channel using cryptographic mechanisms including mu-
tual authentication.
76 The subjects as active entities in the TOE perform operations on objects. They obtain
their associated security attributes from the authenticated users on behalf they are act-
ing, or by default.
Objects
77 The TSF operates user data objects and TSF data objects (i.e. passive entities, that con-
tain or receive information, and upon which subjects perform operations). User data ob-
jects are imported, used in cryptographic operation, temporarily stored, exported and
destroyed after use. The Update Code Packages are user data objects imported and
stored in the TOE until use for creation of an updated CSP. TSF data objects are creat-
ed, temporarily or permanently stored, imported, exported and destroyed as objects of
the security management. They may contain e. g. cryptographic keys with their security
Security Target TCOS CSP Module Version 2.0 Release 1/P71 16/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
attributes, certificates, Authentication Data Records with authentication reference data of
a user. Cryptographic keys are objects of the key management.
Security attributes
78 The security attributes of user known to the TOE are stored in Authentication Data Rec-
ords containing
• User Identity (User-ID),
• Authentication reference data,
• Role with detailed access rights.
79 Passwords as Authentication Reference Data have the security attributes
• status: values initial password, operational password,
• number of unsuccessful authentication attempts.
80 Certificates contain security attributes of users including User identity, a public key and
security attributes of the key. If certificates are used as authentication reference data for
cryptographic entity authentication mechanisms, they may contain the Role of the entity.
81 The user uses authentication verification data to prove its identity to the TOE. The TSF
uses Authentication reference data to verify the claimed identity of a user. The TSF sup-
ports
• human user authentication by knowledge where the authentication verification data is
a password and the authentication reference data is a password or an image of the
password, e.g. a salted hash value or a derived cryptographic key,
• human user authentication by possession of a token or as user of a terminal imple-
menting user authentication by cryptographic entity authentication mechanism,
• cryptographic entity authentication mechanisms where the authentication verification
data is a secret or private key and the authentication reference data is a secret or
public key.
82 A human user may authenticate himself to the TOE and the TOE authenticates to an
external entity in charge of the authenticated authorized user.
83 The TOE knows at least the following roles taken by a user or a subject acting on behalf
of a user:
• Unidentified User: this role is associated with any user not (successfully) identified by
the TOE. This role is assumed after start-up of the TOE. The TSF associated actions
allowed for the Unidentified User are defined in SFR FIA_UID.1.
• Unauthenticated User: this role is associated with an identified user but not (success-
fully) authenticated user. The TSF associated actions allowed for the Unauthenticated
User are defined in SFR FIA_UAU.1.
• Administrator: successful authenticated user allowed to access the TOE in order to
perform management functions. It is taken by a human user or a subject acting on
behalf of a human user after successful authentication as Administrator.
84 The Administrator role is split in more detailed roles:
• Crypto-Officer: role that is allowed to access the TOE in order to perform manage-
ment of a cryptographic TSF.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 17/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
• User Administrator: role that is allowed to access the TOE in order to perform user
management.
• Auditor: role that is allowed to configure the audit functionality, review audit data and
export audit trails.
• Timekeeper: role that is allowed to adjust the internal clock.
• Update Agent: authorized user for import and verification of Update Code Package.
• Personalization Agent: role that is allowed to access the TOE in order to configure it
while personalization phase.
85 The SFR uses the general term Administrator or a selection between Administrator role
and these detailed roles in case they are supported by the TOE and separation of duties
is appropriate.
• Key Owner: successful authenticated user allowed to perform cryptographic operation
with their own keys. This role may be claimed by human user or an entity.
• Application Component: subjects in this role are allowed to use assigned security
services of the TOE without authenticated human user session (e. g. export and im-
port of wrapped keys). This role may be assigned to an entity communicating through
a physically separated secure channel or through a trusted channel (which requires
assured identification of its end points).
86 The TOE is delivered with initial Authentication Data Records for Unidentified User, Un-
authenticated User and administrator roles. The Authentication Data Records for Uni-
dentified User and Unauthenticated User have no Authentication Reference Data. The
roles are not exclusive, i.e. a user or subject may be in more than one role, e.g. a human
user may claim the Crypto-Officer and Key Owner role at the same time. The SFR may
define limitation on roles one user may be associated with.
87 Cryptographic keys have at least the security attributes
• Key identity that uniquely identifies the key,
• Key entity, i.e. the identity of the entity this key is assigned to,
• Key type, i.e. as secret key, private key, public key,
• Key usage type, identifying the cryptographic mechanism or service the key can be
used for, e. g. a private signature key may be used by a digital signature-creation
mechanism (cf. FCS_COP.1/CDS-ECDSA.1 or FCS_COP.1/CDS-RSA), and depend-
ing on the certificate for data authentication with identity of guarantor (cf.
FDP_DAU.2/Sig) by key usage type “Signature Service3”, or time stamp service (cf.
FDP_DAU.2/TS) by key usage type “TimeStamp”, or attestation (cf. FDP_DAU.2/Att)
by key usage type “Attestation”.
• Key access control attributes, i.e. list of combinations of the identity of the user, the
role for which the user is authenticated and the allowed key management function or
cryptographic operation, including
Import of the key is allowed or forbidden,
Export of the key is allowed or forbidden,
3 In the Protection Profile [CSPPP] this service is called “DigSign”, whereas in the corresponding
SFR the same service is called “Signature Service”. Therefore, the last term used also here.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 18/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
88 and may have the security attribute
• Key validity time period, i.e. the time period for operational use of the key; the key
must not be used before or after this time slot,
• Key usage counter, i.e. the number of operations performed with this key e. g. num-
ber of signatures created with a private signature key.
89 The UCP have at least the security attributes
• Issuer of the UCP,
• Version Number of the UCP.
3.2 Threats
90 This section describes the threats to be averted by the TOE independently or in collabo-
ration with its IT environment. These threats result from the assets stored in or protected
by the TOE and the method of TOE’s use in the operational environment.
T.DataCompr Compromise of communication data
91 An unauthorized entity gets knowledge of the information contained in data stored on
TSF controlled media or transferred between the TOE and authenticated external enti-
ties.
T.DataMani Unauthorized generation or manipulation of
communication data
92 An unauthorized entity generates or manipulates user data stored on TSF controlled
media or transferred between the TOE and authenticated external entities and accepted
as valid data by the recipient.
T.Masqu Masquerade authorized user
93 A threat agent might masquerade as an authorized entity in order to gain unauthorized
access to user data, TSF data, or TOE resources.
T.ServAcc Unauthorized access to TOE security services
94 A attacker gets as TOE user unauthorized access to security services of the TOE.
T.PhysAttack Physical attacks
95 An attacker gets physical access to the TOE and may (1) disclose or manipulate user
data under TSF control and TSF data, and (2) affect TSF by (a) physical probing and
manipulation, (b) applying environmental stress or (c) exploiting information leakage
from the TOE.
T.FaUpD Faulty Update Code Package
96 An unauthorized entity provides an unauthorized faulty Update Code Package enabling
attacks against integrity of TSF implementation, confidentiality and integrity of user data
and TSF data after installation of the faulty Update Code Package.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 19/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
3.3 Organizational Security Policies
97 The TOE and/or its environment shall comply with the following Organizational Security
Policies (OSP) as security rules, procedures, practices, or guidelines imposed by an or-
ganization upon its operations (see CC part 1, sec. 3.2).
OSP.SecCryM Secure cryptographic mechanisms
98 The TOE uses only secure cryptographic mechanisms as confirmed by the certification
body for the specified TSF, the assurance security requirements and the operational en-
vironment.
OSP.SecService Security services of the TOE
99 The TOE provides cryptographic and non-cryptographic security services to the author-
ized user for encryption and decryption of user data, authentication prove and verifica-
tion of user data, entity authentication to external entities including attestation, trusted
channel, random bit generation and time services.
OSP.KeyMan Key Management
100 The key management ensures the integrity of all cryptographic keys and the confidential-
ity of all secret or private keys over the whole life cycle which comprises their generation,
storage, distribution, application, archiving and deletion. The cryptographic keys and
cryptographic key components shall be generated, operated and managed by secure
cryptographic mechanisms according to OSP Secure cryptographic mechanisms only
and assigned to the secure cryptographic mechanisms they are intended to be used with
and to the entities authorized for their use.
OSP.TC Trust center
101 The trust centers provide secure certificates for trustworthy certificate holder with correct
security attributes. The TOE uses certificates for identification and authentication of us-
ers, access control and secure use of security services of the TOE including key man-
agement and attestation.
OSP.Update Authorized Update Code Packages
102 The Update Code Packages are delivered in encrypted form and signed by the authorized
issuer. The TOE verifies the authenticity of the received Update Code Package using the
CSP before storing in the TOE. The TOE restricts the storage of authentic Update Code
Package to an authorized user.
103 The PP-Module [CSPMOD] adds new organizational security policies OSP.TimeService
and OSP.Audit.
OSP.TimeService Audit for key management and cryptographic operations
104 The TOE provides non-cryptographic time service and cryptographic time stamp service
for user data and TSF data. The time stamp service provides evidence that user data
were presented to the TSF and exported audit data were generated at certain point in
time and in a verifiable sequence.
OSP.Audit Audit for key management and cryptographic operations
105 The TOE provides security auditing related to activities controlled by the TSF and securi-
ty critical events. The security auditing provides evidence to make users responsible for
Security Target TCOS CSP Module Version 2.0 Release 1/P71 20/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
actions they are authorized for and to protect users against unwarranted accusation. The
administrator is allowed to select auditable events.
3.4 Assumptions
106 The assumptions describe the security aspects of the environment in which the TOE will
be used or is intended to be used.
A.SecComm Secure communication
107 Remote entities support trusted channel using cryptographic mechanisms. The opera-
tional environment shall protect the local communication channels by trusted channels
using cryptographic mechanisms or by secure channel using non-cryptographic security
measures.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 21/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
4 Security Objectives
108 This chapter describes the security objectives for the TOE and for the TOE environment.
4.1 Security Objectives for the TOE
109 The following TOE security objectives address the protection provided by the TOE inde-
pendent of the TOE environment.
O.AuthentTOE Authentication of the TOE to external entities
110 The TOE authenticates themselves in charge of authorized users to external entities by
means of secure cryptographic entity authentication and attestation.
O.Enc Confidentiality of user data by means of encryption and decryption
111 The TOE provides secure encryption and decryption as security service for the users to
protect the confidentiality of user data imported, exported or stored on media in the
scope of TSF control.
O.DataAuth Data authentication by cryptographic mechanisms
112 The TOE provides secure symmetric and asymmetric data authentication mechanisms
as security services for the users to protect the integrity and authenticity of user data.
O.RBGS Random number generation service
113 The TOE provides cryptographically secure random number generation service for the
users.
O.TChann Trusted channel
114 The TSF provides trusted channel using secure cryptographic mechanisms for the com-
munication between the TSF and external entities. The TOE provides authentication of
all communication end points, ensures the confidentiality and integrity of the communica-
tion data exchanged through the trusted channel.
115 Note the TSF can establish the trusted channel by means of secure cryptographic
mechanisms only if the other endpoint supports these secure cryptographic mechanisms
as well. If trusted channel cannot be established by means of secure cryptographic
mechanisms due to missing security functionality of the user then the operational envi-
ronment shall provide a secure channel protecting the communication by non-
cryptographic security measures, cf. A.SecComm and OE.SecComm.
O.I&A Identification and authentication of users
116 The TOE shall uniquely identify users and verify the claimed identity of the user before
providing access to any controlled resources with the exception of self-test, identification
of the TOE and authentication of the TOE. The TOE shall authenticate IT entities using
secure cryptographic mechanisms.
O.AccCtrl Access control
117 The TOE provides access control on security services, operations on user data, mana-
gement of TSF and TSF data.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 22/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
O.SecMan Security management
118 The TOE provides security management of users, TSF, TSF data and cryptographic
keys by means of secure cryptographic mechanisms and using certificates. The TSF
generates, derives, agrees, import and export cryptographic keys as security service for
users and for internal use. The TSF shall destruct unprotected secret or private keys in
such a way that any previous information content of the resource is made unavailable.
O.TST Self-test
119 The TSF performs self-tests during initial start-up, at the request of the authorised user
and after power-on. The TSF enters secure state if self-test fails or attacks are detected.
O.PhysProt Physical protection
120 The TSF protects the confidentiality and integrity of user data, TSF data and its correct
operation against physical attacks and environmental stress. In case of platform archi-
tecture, the TSF protects the secure execution environment for and the communication
with the application component running on the TOE.
O.SecUpCP Secure import of Update Code Package
121 The TSF verifies the authenticity of received encrypted Update Code Package, decrypts
authentic Update Code Package and stores decrypted Update Code Package.
122
123 The PP-Module [CSPMOD] adds the following security objectives for the TOE.
O.TimeServices Time services
124 The TOE provides an internal time service and time stamp service for the user.
O.Audit Audit for cryptographic TSF
125 The TSF provides security auditing of selected user activities controlled by the TSF and
security critical events. The Administrator is allowed to select auditable events, to man-
age the audit functionality and the export of audit records.
4.2 Security Objectives for the Operational Environment
OE.CommInf Communication infrastructure
126 The operational environment shall provide public key infrastructure for entities in the
communication networks. The trust centers generate secure certificates for trustworthy
certificate holder with correct security attributes. They distribute securely their certificate
signing public key for verification of digital signature of the certificates and run a directory
service for dissemination of certificates and provision of revocation status information of
certificates.
OE.AppComp Support of the Application component
127 The Application component supports the TOE for communication with users and trust
centers.
OE.SecManag Security management
128 The operational environment shall implement appropriate security management for se-
cure use of the TOE including user management, key management. It ensures secure
Security Target TCOS CSP Module Version 2.0 Release 1/P71 23/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
key management outside the TOE and uses the trust center services to determine the
validity of certificates. The cryptographic keys and cryptographic key components shall
be assigned to the secure cryptographic mechanisms they are intended to be used with
and to the entities authorized for their use.
OE.SecComm Protection of communication channel
129 Remote entities shall support trusted channels with the TOE using cryptographic mech-
anisms. The operational environment shall protect the local communication channels by
trusted channels using cryptographic mechanisms or by secure channel using non-
cryptographic security measures.
OE.SUCP Signed Update Code Packages
130 The secure Update Code Package is delivered in encrypted form and signed by the au-
thorized issuer together with its security attributes.
131 The PP-Module [CSPMOD] adds the following security objectives for the operational
environment of the TOE.
OE.Audit Review and availability of audit records
132 The administrator shall ensure the regular audit review and the availability of exported
audit records.
OE.TimeSource External time source
133 The operational environment provides reliable external time source for the adjustment of
the TOE internal time source.
4.3 Security Objective Rationale
134 The following table provides an overview for security objectives coverage (TOE and its
environment). It shows that all threats and OSPs are addressed by the security objec-
tives. It also shows that all assumptions are addressed by the security objectives for the
TOE environment.
T.DataCompr
T.DataMani
T.Masqu
T.ServAcc
T.PhysAttack
T.FaUpD
OSP.SecCryM
OSP.SecService
OSP.KeyMa
OSP.Audit
OSP.TC
OSP.TimeService
OSP.Update
A.SecComm
O.AccCtrl x
O.AuthentTOE x x
O.DataAuth x x x
O.Enc x x x
O.I&A x x x x x
O.PhysProt x
O.RBGS x x
O.SecMan x x x x
O.SecUpCP x x
Security Target TCOS CSP Module Version 2.0 Release 1/P71 24/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
T.DataCompr
T.DataMani
T.Masqu
T.ServAcc
T.PhysAttack
T.FaUpD
OSP.SecCryM
OSP.SecService
OSP.KeyMa
OSP.Audit
OSP.TC
OSP.TimeService
OSP.Update
A.SecComm
O.TChann x x x x x x
O.TST x
O.Audit x
O.TimeService x
OE.AppComp x x x x
OE.CommInf x x x x x x
OE.SecComm x x x x
OE.SecManag x x x
OE.SUCP x x
OE.Audit x
OE.TimeService x
Table 1:Security Objective Rationale for the TOE
The corresponding complete rationale is given in the claimed by this ST Protection Pro-
files [CSPPP] and [CSPMOD]. Hence, it will not be repeated here.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 25/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
5 Extended Components Definition
135 This Security Target includes all extended components from the claimed PPs except the
ones stated in chapter 2.2 PP Claims. This includes families FPT_TCT, FPT_TIT,
FPT_ISA and FPT_ESA from [CSPPP].
5.1 FPT_TCT Inter-TSF TSF data confidentiality transfer protection
136 This section describes the functional requirements for confidentiality protection of inter-
TSF transfer of TSF data. The family is similar to the family Basic data exchange confi-
dentiality (FDP_UCT) which defines functional requirements for confidentiality protection
of exchanged user data.
137 The family “TSF data confidentiality transfer protection (FPT_TCT)” is specified as fol-
lows.
Family behavior
This family requires confidentiality protection of exchanged TSF data.
Component levelling:
FPT_TCT.1 TSF data confidentiality transfer protection requires the TOE to protect
the confidentiality of information in exchanged the TSF data.
Management: FPT_TCT.1
There are no management activities foreseen.
Audit: FPT_TCT.1
There are no actions defined to be auditable.
FPT_TCT.1 TSF data confidentiality transfer protection
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]
[FMT_MTD.1 Management of TSF data or FMT_MTD.3 Secure TSF
data]
FPT_TCT.1.1 The TSF shall enforce the [assignment: access control SFP, informa-
tion flow control SFP] by providing the ability to [selection: transmit, re-
ceive, transmit and receive] TSF data in a manner protected from un-
authorized disclosure.
TSF data confidentiality transfer protection 1
Security Target TCOS CSP Module Version 2.0 Release 1/P71 26/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
5.2 FPT_TIT Inter-TSF TSF data integrity transfer protection
138 his section describes the functional requirements for integrity protection of TSF data ex-
changed with another trusted IT product. The family is similar to the family Inter-TSF us-
er data integrity transfer protection (FDP_UIT) which defines functional requirements for
integrity protection of exchanged user data.
139 The family “TSF data confidentiality transfer protection (FPT_TCT)” is specified as fol-
lows.
Family behavior
This family requires confidentiality protection of exchanged TSF data.
Component levelling:
FPT_TIT.1 TSF data integrity transfer protection requires the TOE to protect the
integrity of information in exchanged TSF data.
Management: FPT_TIT.1
There are no management activities foreseen.
Audit: FPT_TIT.1
There are no actions defined to be auditable.
FPT_TIT.1 TSF data confidentiality transfer protection
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]
[FMT_MTD.1 Management of TSF data or FMT_MTD.3 Secure TSF
data]
FPT_TIT.1.1 The TSF shall enforce the [assignment: access control SFP, infor-
mation flow control SFP] to [selection: transmit, receive, transmit and
receive] TSF data in a manner protected from [selection: modification,
deletion, insertion, replay] errors.
FPT_TIT.1.2 The TSF shall be able to determine on receipt of TSF data, whether
[selection: modification, deletion, insertion, replay] has occurred.
5.3 FPT_ISA TSF data import with security attributes
140 This section describes the functional requirements for TSF data import with security at-
tributes from another trusted IT product. The family is similar to the family Import from
outside of the TOE (FDP_ITC) which defines functional requirements for user data im-
port with security attributes.
141 The family “TSF data import with security attributes (FPT_ISA)” is specified as follows.
TSF data integrity transfer protection 1
Security Target TCOS CSP Module Version 2.0 Release 1/P71 27/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Family behavior
This family requires TSF data import with security attributes.
Component levelling:
FPT_ISA.1 Import of TSF data with security attributes requires the TOE to import
TSF data with security attributes.
Management: FPT_ISA.1
There are no management activities foreseen.
Audit: FPT_ISA.1
There are no actions defined to be auditable.
FPT_ISA.1 TSF data confidentiality transfer protection
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]
[FMT_MTD.1 Management of TSF data orFMT_MTD.3 Secure TSF
data]
[FMT_MSA.1 Management of security attributes, or FMT_MSA.4 Se-
curity attribute value inheritance]
FPT_TDC.1 Inter-TSF basic TSF data consistency
FPT_ISA.1.1 The TSF shall enforce the [assignment: access control SFP, infor-
mation flow control SFP] when importing TSF data, controlled under
the SFP, from outside of the TOE.
FPT_ISA.1.2 The TSF shall use the security attributes associated with the imported
TSF data.
FPT_ISA.1.3 The TSF shall ensure that the protocol used provides for the unambig-
uous association between the security attributes and the TSF data re-
ceived.
FPT_ISA.1.4 The TSF shall ensure that interpretation of the security attributes of the
imported TSF data is as intended by the source of the TSF data.
FPT_ISA.1.5 The TSF shall enforce the following rules when importing TSF data
controlled under the SFP from outside the TOE: [assignment: addition-
al importation control rules].
5.4 FPT_ESA TSF data export with security attributes
142 This section describes the functional requirements for TSF data export with security at-
tributes to another trusted IT product. The family is similar to the family Export to outside
TSF data import with security attributes 1
Security Target TCOS CSP Module Version 2.0 Release 1/P71 28/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
of the TOE (FDP_ETC) which defines functional requirements for user data export with
security attributes.
143 The family “TSF data export with security attributes (FPT_ESA)” is specified as follows.
Family behavior
This family requires TSF data export with security attributes.
Component levelling:
FPT_ESA.1 Export of TSF data with security attributes requires the TOE to export
TSF data with security attributes.
Management: FPT_ESA.1
There are no management activities foreseen.
Audit: FPT_ESA.1
There are no actions defined to be auditable.
FPT_ESA.1 TSF data confidentiality transfer protection
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]
[FMT_MTD.1 Management of TSF data orFMT_MTD.3 Secure TSF
data]
[FMT_MSA.1 Management of security attributes, or FMT_MSA.4 Se-
curity attribute value inheritance]
FPT_TDC.1 Inter-TSF basic TSF data consistency
FPT_ESA.1.1 The TSF shall enforce the [assignment: access control SFP, infor-
mation flow control SFP] when exporting TSF data, controlled under
the SFP(s), outside of the TOE.
FPT_ESA.1.2 The TSF shall export the TSF data with the TSF data's associated se-
curity attributes.
FPT_ESA.1.3 The TSF shall ensure that the security attributes, when exported out-
side the TOE, are unambiguously associated with the exported TSF
data.
FPT_ESA.1.4 The TSF shall enforce the following rules when TSF data is exported
from the TOE: [assignment: additional exportation control rules].
TSF data export with security attributes 1
Security Target TCOS CSP Module Version 2.0 Release 1/P71 29/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
6 Security Requirements
144 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 se-
curity objectives for the TOE.
145 The CC allows several operations to be performed on functional requirements; refine-
ment, Selection, assignment, and iteration are defined in section 8.1 of Part 1 of the
Common Criteria [CC]. Each of these operations is used in this ST.
146 The refinement operation is used to add detail to a requirement, and thus further re-
stricts a requirement. Refinements of security requirements are denoted in such a way
that added words are in bold text and removed are crossed out. Refinements made by
the ST author appear slanted, bold and underlined.
147 The Selection operation is used to Select one or more options provided by the CC in
stating a requirement. Selections having been made by the PP author are denoted as
underlined text. Selections made by the ST author appear slanted and underlined.
148 The assignment operation is used to assign a specific value to an unspecified parame-
ter, 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 appear
slanted and underlined.
149 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 compo-
nent identifier.
6.1 Security Functional Requirements for the TOE
150 The statements of security requirements must be internally consistent. As several differ-
ent PPs with similar SFRs are claimed, great care must be taken to ensure that these
several iterated SFRs do not lead to inconsistency. Following the Protection Profile
[CSPPP] the SFR are not listed according to their classes but their functionalities.
6.1.0 Overview
151 The TOE provides cryptographic security services for encryption and decryption of user
data, entity authentication of external entities and to external entities, authentication
prove and verification of user data, trusted channel and random number generation.
152 The TOE enforces the Cryptographic Operation SFP for protection of theses crypto-
graphic services which subjects, objects, and operations are defined in the SFRs
FDP_ACC.1/Oper and FDP_ACF/Oper.
153 The TOE provides hybrid encryption and decryption combined with data integrity mech-
anisms for the cipher text as cryptographic security service of the TOE. The encryption
FCS_COP.1/HEM combines the generation of a data encryption key and message au-
thentication code (MAC) key, the asymmetric encryption of the data encryption key with
an asymmetric key encryption key, cf. FCS_CKM.1/ECKA-EG, FCS_CKM.1/RSA, and
the symmetric encryption of the data with the data encryption key and data integrity
mechanism with MAC calculation for the cipher text. The receiver reconstructs the data
Security Target TCOS CSP Module Version 2.0 Release 1/P71 30/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
encryption key and the MAC key, cf. FCS_CKM.5/ECKA-EG, FCS_CKM.5/KED-RSA,
calculates the MAC for the cipher text and compares it with the received MAC. If the in-
tegrity of the cipher text is determined then the receiver decrypts the cipher text with the
data decryption key, cf. FCS_COP.1/HDM.
154 In general, authentication is the provision of assurance of the claimed identity of an enti-
ty. The TOE authenticates human users by password, cf. FIA_UAU.5.1 clause 1. But a
human user may authenticate themselves to a token and the token authenticates to the
TOE. Cryptographic authentication mechanisms allow an entity to prove its identity or
the origin of its data to a verifying entity by demonstrating its knowledge of a secret. The
entity authentication is required by FIA_UAU.5.1 clauses (2) to (6). The chapter 5.3 de-
scribes SFR for the authentication of the TOE to external entities required by the SFR
FIA_API.1. This authentication may include attestation of the TOE as genuine TOE
sample, cf. 6.1. The authentication may be mutual as required for trusted channels in
chapter 6.1.
155 Protocols may use symmetric cryptographic algorithms, where the proving and the veri-
fying entity using the same secret key, may demonstrate that the proving entity belongs
to a group of entities sharing this key, e.g. sender and receiver (cf. FTP_ITC.1,
FCS_COP.1/TCM). In case of asymmetric entity authentication mechanisms, the proving
entity uses a private key and the verifying entity uses the corresponding public key
closely linked to the claimed identity often by means of a certificate. The same crypto-
graphic mechanisms for digital signature generation algorithm (FCS_COP.1/CDS-***)
and signature verification algorithm (cf. FCS_COP.1/VDS-***) may be used for entity au-
thentication, data authentication and non-repudiation depending on the security attrib-
utes of the cryptographic keys e.g. encoded in the certificate (cf. FPT_ISA.1/Cert).
156 Trusted channel requires mutual authentication of endpoints with key exchange of key
agreement, protection of confidentiality by means of encryption and cryptographic data
integrity protection.
157 The TSF provides security management for user and TSF data including cryptographic
keys. The key management comprises administration and use of generation, derivation,
registration, certification, deregistration, distribution, installation, storage, archiving, rev-
ocation and destruction of keying material in accordance with a security policy. The key
management of the TOE supports the generation, derivation, export, import, storage and
destruction of cryptographic keys. The cryptographic keys are managed together with
their security attributes.
158 The TOE enforces the Key Management SFP to protect the cryptographic keys (as data
objects of TSF data) and the key management services (as operation, cf. to SFR of the
FMT class) provided for Administrators, Crypto-Officers and Key Owners (as subjects),
cf. FDP_ACC.1/KM. Note the cryptographic keys will be used for cryptographic opera-
tions under Cryptographic Operation SFP as well.
159 The subjects, objects and operations of the Update SFP are defined in the SFR
FDP_ACC.1/UCP and FDP_ACF.1/UCP. The SFR for cryptographic mechanisms based
on elliptic curves refer to the following table for selection of curves, key sizes and stand-
ards.
Elliptic curve Key size (bits) Standard
brainpoolP192r1 192 RFC5639, TR-03111, section 4.1.3 [ECCTR]
brainpoolP224r1 224 RFC5639, TR-03111, section 4.1.3 [ECCTR]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 31/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
brainpoolP256r1 256 RFC5639, TR-03111, section 4.1.3 [ECCTR]
brainpoolP320r1 320 RFC5639, TR-03111, section 4.1.3 [ECCTR]
brainpoolP384r1 384 RFC5639, TR-03111, section 4.1.3 [ECCTR]
brainpoolP512r1 512 RFC5639, TR-03111, section 4.1.3 [ECCTR]
brainpoolP192t1 192 RFC5639, TR-03111, section 4.1.3 [ECCTR]
brainpoolP224t1 224 RFC5639, TR-03111, section 4.1.3 [ECCTR]
brainpoolP256t1 256 RFC5639, TR-03111, section 4.1.3 [ECCTR]
brainpoolP320t1 320 RFC5639, TR-03111, section 4.1.3 [ECCTR]
brainpoolP384t1 384 RFC5639, TR-03111, section 4.1.3 [ECCTR]
brainpoolP512t1 512 RFC5639, TR-03111, section 4.1.3 [ECCTR]
Curve P-192 192 FIPS PUB 186-4 B.4 and D.1.2.3 [FIPS186]
Curve P-256 256 FIPS PUB 186-4 B.4 and D.1.2.3 [FIPS186]
Curve P-384 384 FIPS PUB 186-4 B.4 and D.1.2.3 [FIPS186]
secp256r1 256 Koblitz curve conforming to [SEC2]
160 Application Note 7: Note that for security reasons the Curve P-521 is not supported by
the TOE.
161 Application Note 8: Please consider that since version 2023-01 of TR-02102-1 only
curves with key sizes (bits) of 256 and above are recommended because only those
curves reach the now achieved complexity of 120 bits. Therefore, the curves with sizes
below 256 bits are no longer recommended. Nevertheless, since this security target
does not claim conformance to TR-02102-1 this does not affect the list above.
162 For Diffie-Hellman key exchange refer to the following groups:
Name IANA number Standard
256-bit random ECP group 19 RFC5903
384-bit random ECP group 20 RFC5903
brainpoolP256r1 28 RFC6954
brainpoolP384r1 29 RFC6954
brainpoolP512r1 30 RFC6954
163 Application Note 9: Note that for security reasons the 521-bit ECP group is not support-
ed by the TOE.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 32/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
164 The Module-PP adds for time stamps and audit mechanism the following new SFRs
compared to the Base-PP:
FAU_GEN.1, FAU_STG.1, FAU_STG.3, FDP_ACF.1/TS, FDP_DAU.2/TS, FDP_\
ETC.2/TS, FDP_ITC.2/TS, FMT_MTD.1/Audit, FMT_MOF.1/TSA, FMT_SMF.1/TSA,
FMT_SMR.1/TSA, FPT_STM.1, FPT_TIT.1/Audit
6.1.1 Key management
6.1.1.1 Management of security attributes
165 FDP_ACC.1/KM Subset access control – Cryptographic operation
Hierarchical to: No other components
Dependencies: FDP_ACF.1 Security attribute based access control: not fulfilled but
justified (the rules are specified by FMT_MTD.1/KM)
FDP_ACC.1.1/KM
The TSF shall enforce the Key Management SFP4 on
1. subjects: Crypto-Officer5, Key Owner
2. objects: operational cryptographic keys;
3. operations: key generation, key derivation, key import, key ex-
port, key destruction.
166 FMT_MSA.1/KM Management of security attributes – Key security attributes
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control] fulfilled by FDP_ACC.1/KM
FMT_SMR.1 Security roles: fulfilled
FMT_SMF.1 Specification of Management: fulfilled
FMT_MSA.1.1/KM
The TSF shall enforce the Key Management SFP and Cryptographic
Operation SFP6 to restrict the ability to
1. change_default7 the security attributes Identity of the key, Key
entity of the key, Key type, Key usage type, Key access control
attributes, Key validity time period8 to Crypto-Officer9,
2. modify or delete7 the security attributes Identity of the key,
Key entity, Key type, Key usage type, Key validity time pe-
riod of an existing key8 to none10,
3. modify independent on key usage7 the security attributes
Key usage counter of an existing key11 to none12.
4 [assignment: access control SFP, information flow control SFP]
5 [selection: Administrator, Crypto-Officer]
6 [assignment: access control SFP]
7 [selection: change_default, query, modify, delete, [assignment: other operations]]
8 [assignment: list of security attributes]
9 [selection: Administrator, Crypto-Officer]
10 [assignment: the authorized identified roles]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 33/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
4. modify13 the security attributes Key access control attrib-
ute of an existing key14 to Crypto-Officer 15,
5. query13 the security attributes Key type, Key usage type,
Key access control attributes, Key validity time period and
Key usage counter of an identified key14 to Crypto-Officer
and Key Owner16.
167 Application Note 10: The refinements repeat parts of the SFR component in order to
avoid iteration of the component.
168 FMT_MSA.3/KM Static attribute initialisation
Hierarchical to: No other components
Dependencies: FMT_MSA.1 Management of security attributes: fulfilled
FMT_SMR.1 Security roles: fulfilled
FMT_MSA.3.1/KM
The TSF shall enforce the Key Management SFP, Cryptographic Op-
eration SFP and Update SFP17 to provide restrictive18 default values
for security attributes that are used to enforce the SFP.
FMT_MSA.3.2/KM
The TSF shall allow the Crypto-Officer 19 to specify alternative initial
values to override the default values when a cryptographic key ob-
ject or information is created.
169 FMT_MTD.1/KM Management of TSF data – Key management
Hierarchical to: No other components
Dependencies: FMT_SMR.1 Security roles: fulfilled
FMT_SMF.1 Specification of Management Functions: fulfilled
FMT_MTD.1.1/KM
The TSF shall restrict the ability to
1. create according to FCS_CKM.120 the cryptographic keys21 to
Crypto-Officerr22
2. import according to FPT_TCT.1/CK, FPT_TIT.1/CK and
FPT_ISA.1/CK23 the cryptographic keys24 to Crypto-Officer
25
11 [assignment: list of security attributes]
12 [assignment: the authorized identified roles]
13 [selection: change_default, query, modify, delete, [assignment: other operations]]
14 [assignment: list of security attributes]
15 [selection: Administrator, Crypto-Officer]
16 [selection: Administrator, Crypto-Officer, Key Owner]
17 [assignment: access control SFP, information flow control SFP]
18 [selection: choose one of: restrictive, permissive, [assignment: other property]]
19 [selection: Administrator, Crypto-Officer]
20 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
21 [assignment: list of TSF data]
22 [selection: Administrator, Crypto-Officer, Key Owner]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 34/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
3. export according to FPT_TCT.1/CK, FPT_TIT.1/CK and
FPT_ESA.1/CK26 the cryptographic keys27 to Crypto-
Officer28 if security attribute of the key allows export,
4. delete according to FCS_CKM429 the cryptographic keys30
to Crypto-Officer and Key Owner31
170 Application Note 11: The bullets (2) to (4) are refinements to avoid an iteration of com-
ponent and therefore printed in bold.
6.1.1.2 Hash based functions
171 FCS_COP.1/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]: fulfilled
FCS_CKM.632 Timing and event of cryptographic key destruction:
fulfilled
FCS_COP.1.1/Hash
The TSF shall perform hash generation33 in accordance with a speci-
fied cryptographic algorithm SHA-256, SHA-384, SHA-51234 and
cryptographic key sizes none35 that meet the following: FIPS 180-4
[FIPS180]36.
172 Application Note 12: The hash function is a cryptographic primitive used for HMAC, cf.
FCS_COP.1/HMAC, digital signature creation, cf. FCS_COP.1/CDS-*, digital signature
verification, cf. FCS_COP.1/VDS-**, and key derivation, cf. FCS_CKM.5.
6.1.1.3 Management of Certificates
173 FMT_MTD.1/RK Management of TSF data – Root key
Hierarchical to: No other components
Dependencies: FMT_SMR.1 Security roles: fulfilled
FMT_SMF.1 Specification of Management Functions: fulfilled
23 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
24 [assignment: list of TSF data]
25 [selection: Administrator, Crypto-Officer]
26 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
27 [assignment: list of TSF data]
28 [selection: Administrator, Crypto-Officer, Key Owner]
29 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
30 [assignment: list of TSF data]
31 [selection: Administrator, Crypto-Officer, Key Owner]
32 The dependency FCS_CKM.4 is replaced by FCS_CKM.6 Timing and event of cryptographic key destruction in CC:2022.
The Base-PP uses the deprecated reference.
33 [assignment: list of cryptographic operations]
34 [assignment: cryptographic algorithm]
35 [assignment: cryptographic key sizes]
36 [assignment: list of standards]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 35/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
FMT_MTD.1.1/RK
The TSF shall restrict the ability to
(1) create37, modify, clear and delete38 the root key pair39 to Cryp-
to-Officer 40,
(2) import and delete41 the known as authentic public key of a
certification authority in a PKI42 to Crypto-Officer 43
174 Application Note 13: The root key is defined here with respect to the key hierarchy
known to the TOE. In case of clause (1), i.e. may be a key pair of a TOE internal key hi-
erarchy. In clause (2) it may be a root public key of a PKI or a public key of another certi-
fication authority in a PKI known as authentic certificate signing key. The PKI may be
used for user authentication, key management and signature verification. The second
and third bullets are a refinement to avoid an iteration of component and therefore print-
ed in bold.
175 FPT_TIT.1/Cert TSF data integrity transfer protection – Certificates
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
[FMT_MTD.1 Management of TSF data orFMT_MTD.3 Secure TSF
data]: fulfilled
FPT_TIT.1.1/Cert
The TSF shall enforce the Key Management SFP44 to receive45 cer-
tificate TSF data in a manner protected from modification and inser-
tion46 errors.
FPT_TIT.1.2/Cert
The TSF shall be able to determine on receipt of certificate TSF da-
ta, whether modification or insertion47 has occurred.
176 FPT_ISA.1/Cert Import of TSF data with security attributes – Certificates
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
[FMT_MTD.1 Management of TSF data or FMT_MTD.3 Secure TSF
data]: fulfilled
[FMT_MSA.1 Management of security attributes, or FMT_MSA.4
Security attribute value inheritance]: fulfilled
37 "create” denotes initial setting a root key
38 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
39 [assignment: list of TSF data]
40 [selection: Administrator, Crypto-Officer]
41 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
42 [assignment: list of TSF data]
43 [selection: Administrator, Crypto-Officer]
44 [assignment: access control SFP, information flow control SFP]
45 [selection: transmit, receive, transmit and receive]
46 [selection: modification, deletion, insertion, replay]
47 [selection: modification, deletion, insertion, replay]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 36/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
FPT_TDC.1 Inter-TSF basic TSF data consistency: fulfilled
FPT_ISA.1.1/Cert
The TSF shall enforce the Key Management SFP48 when importing
certificates TSF data, controlled under the SFP from outside the
TOE.
FPT_ISA.1.2/Cert
The TSF shall use the security attributes associated with the imported
certificate TSF data.
FPT_ISA.1.3/Cert
The TSF shall ensure that the protocol used provides for the unam-
biguous association between the security attributes and the certifi-
cate TSF data received.
FPT_ISA.1.4/Cert
The TSF shall ensure that interpretation of the security attributes of
the imported certificates TSF data is as intended by the source of
the certificates TSF data.
FPT_ISA.1.5/Cert
The TSF shall enforce the following rules when importing certificates
TSF data controlled under the SFP from outside the TOE:
(1) The TSF imports the TSF data in certificates only after success-
ful verification of the validity of the certificate in the certificate
chain until known as authentic certificate according to
FMT_MTD.1/RK.
(2) The validity verification of the certificate shall include
(a) the verification of the digital signature of the certificate issuer
except for root certificates,
(b) the security attributes in the certificate pass the interpreta-
tion according to FPT_TDC.1 49.
177 FPT_TDC.1/Cert Inter-TSF basic TSF data consistency - Certificate
Hierarchical to: No other components
Dependencies: No dependencies
FPT_TDC.1.1/Cert
The TSF shall provide the capability to consistently interpret security
attributes of cryptographic keys in the certificate and identity of the
certificate issuer50 when shared between the TSF and another trusted
IT product.
FPT_TDC.1.2/Cert
The TSF shall use the following rules:
(1) The TOE does not change the security attributes Key identity,
48 [assignment: access control SFP, information flow control SFP]
49 [assignment: additional importation control rules]
50 [assignment: additional importation control rules]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 37/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Key entity, Key type, Key usage type and Key validity time peri-
od of public key being imported from the certificate.
(2) The identity of the certificate issuer shall meet the identity of the
signer of the certificate.51
when interpreting the certificate from a trust center TSF data from
another trusted IT product.
178 Application Note 14: The security attributes assigned to certificate holder and the crypto-
graphic key in the certificate are used as TSF data of the TOE. The certificate is import-
ed from trust center directory service or any other source but verified by the TSF (i.e. if
verified successfully the source is the trusted IT product trust center directory server).
6.1.1.4 Key generation, agreement and destruction
179 Key generation (cf. FCS_CKM.1/ECC, FCS_CKM.1/RSA) is a randomized process
which uses random secrets (cf. FCS_RNG.1), applies key generation algorithms and de-
fines security attributes depending on the intended use of the keys and which has the
property that it is computationally infeasible to deduce the output without prior
knowledge of the secret input. Key derivation (cf. FCS_CKM.5/ECC) is a deterministic
process by which one or more keys are calculated from a pre-shared key or shared se-
cret or other information. It allows repeating the key generation if the same input is pro-
vided. Key agreement (cf. FCS_CKM.5/ECDHE) is a key-establishment procedure pro-
cess for establishing a shared secret key between entities in such a way that neither of
them can predetermine the value of that key independently of the other party’s contribu-
tion. Key agreement allows each participant to enforce the cryptographic quality of the
agreed key. The component FCS_CKM.1 was refined for key agreement because it
normally uses random bits as input. Hybrid cryptosystems (FCS_CKM.1/ECKA-EG,
FCS_CKM.1/AES_RSA) are a combination of a public key cryptosystem with an efficient
symmetric key cryptosystem.
180 The user may need to specify the type of key, the cryptographic key generation algo-
rithm, the security attributes and other necessary parameters.
181 FCS_RNG.1 Random number generation
Hierarchical to: No other components
Dependencies: No dependencies
FCS_RNG.1 Random number generation (Class PTG.3)
FCS_RNG.1.1
The TSF shall provide a hybrid physical52 random number
generator that implements:
(PTG.3.1) A total failure test detects a total failure of entropy source
immediately when the RNG has started. When a total fail-
ure has been detected no random numbers will be output.
(PTG.3.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
51 [assignment: list of TSF data types]
52 [selection: physical, non-physical true, deterministic, hybrid physical, hybrid deterministic]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 38/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
failure of the entropy source53.
(PTG.3.3) The online test shall detect non-tolerable statistical de-
fects of the raw random number sequence (i) immediately
when the RNG is started, and (ii) while the RNG is being
operated. The TSF must not output any random numbers
before the power-up online test and the seeding of the
DRG.3 post-processing algorithm have been finished
successfully or when a defect has been detected.
(PTG.3.4) The online test procedure shall be effective to detect non-
tolerable weaknesses of the random numbers soon.
(PTG.3.5) The online test procedure checks the raw random number
sequence. It is triggered continuously54. The online test is
suitable for detecting non-tolerable statistical defects of
the statistical properties of the raw random numbers with-
in an acceptable period of time.
(PTG.3.6) The algorithmic post-processing algorithm belongs to
Class DRG.3 with cryptographic state transition function and crypto-
graphic output function, and the output data rate of the post-
processing algorithm shall not exceed its input data rate.
FCS_RNG.1.2
The TSF shall provide octets of bits55 that meet:
(PTG.3.7) Statistical test suites cannot practically distinguish the
internal random numbers from output sequences of an
ideal RNG. The internal random numbers must pass test
procedure A.
(PTG.3.8) The internal random numbers shall use PTRNG of class
PTG.2 as random source for the post-processing56.
182 Application Note 15: The random bit generation of PTG.3 shall be used for key genera-
tion and key agreement according to all instantiations of FCS_CKM.1, challenges in
cryptographic protocols and cryptographic operations using random values according to
FCS_COP.1/KW, FCS_COP.1/HEM and FCS_COP.1/TCE. The TOE provides the ran-
dom number generation as security service for the user. Additionally, PTG.2 provides
random bits for an option of the Get Random command.
183 FCS_CKM.1/AES Cryptographic key generation – AES key
Hierarchical to: No other components
53 [selection: 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, generates the inter-nal random numbers with a post-processing algorithm
of class DRG.3 as long as its internal state entropy guarantees the claimed output entropy]
54 [selection: externally, at regular intervals, continuously, applied upon specified internal events]
55 [selection: bits, octets of bits, numbers [assignment: format of the numbers]]
56 [selection: use PTRNG of class PTG.2 as random source for the post-processing, have [assignment: work factor], require
[assignment: guess work]].
Security Target TCOS CSP Module Version 2.0 Release 1/P71 39/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Dependencies57: [FCS_CKM.2 Cryptographic key distribution, or
FCS_CKM.5 Cryptographic key derivation, or
FCS_COP.1 Cryptographic operation]: fulfilled
[FCS_RBG.1 Random bit generation, or
FCS_RNG.1 Generation of random numbers]: fulfilled.
FCS_CKM.658 Timing and event of cryptographic key destruction:
fulfilled
FCS_CKM.1.1/AES
The TSF shall generate cryptographic AES key in accordance with a
specified cryptographic key generation algorithm AES59 and key size
128 bits, 256 bits60 that meet the following: [ISO18033-3]61.
184 Application Note 16: The cryptographic key may be used with FCS_COP.1/ED, e.g. for
internal purposes.
185 FCS_CKM.5/AES Cryptographic key derivation – AES key derivation
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryp-
tographic operation]: fulfilled
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled
FCS_CKM.5.1/AES
The TSF shall derive cryptographic AES key62 from random input
parameters63 in accordance with a specified cryptographic key deri-
vation algorithms AES key generation using bit string derived from
input parameters with DKDF_NIST_800_10864 and specified crypto-
graphic key sizes 128 bits, 256 bits65 that meet the following: [NIST
SP 800-108]66.
186 FCS_CKM.1/ECC Cryptographic key generation – Elliptic curve key pair
ECC
Hierarchical to: No other components
57 FCS_CKM.1 of CC:2022 has more dependencies compared to the Base-PP: FCS_RNG.1. FCS_RNG.1 is fulfilled. This
also applies to all subsequent iterations of FCS_CKM.1.
58 The dependency FCS_CKM.4 is replaced by FCS_CKM.6 Timing and event of cryptographic key destruction in CC:2022
and is therefore also replaced in this document. This also applies to all subsequent iterations of FCS_CKM.1. The Base-PP
uses the deprecated reference FCS_CKM.4 which covers the whole intention of FCS_CKM.6 (CC:2022).
59 [assignment: cryptographic key generation algorithm]
60 [selection: 256 bits, no other key size]
61 [assignment: list of standards]
62 [assignment: key type]
63 [assignment: input parameters]
64 [assignment: cryptographic key derivation algorithm]
65 [selection: 256 bits, no other key size]
66 [assignment: list of standards]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 40/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_CKM.5 Cryp-
tographic key derivation, or FCS_COP.1 Cryptographic operation]:
fulfilled
[FCS_RBG.1 Random bit generation, or FCS_RNG.1 Generation of
random numbers]: fulfilled.
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled.
FCS_CKM.1.1/ECC
The TSF shall generate cryptographic elliptic curve keys pairs in
accordance with a specified cryptographic key generation algorithm
ECC key pair generation with elliptic curves table 6.1.067 and crypto-
graphic key sizes key size in the table 6.1.0 68 that meet the following:
corresponding standard in the table 6.1.0 69.
187 Application Note 17: The elliptic key pair generation uses a random bit string as input for
the ECC key generation algorithm. The keys generation according to FCS_CKM.1/ECC
and key derivation according to FCS_CKM.5/ECC are intended for different key man-
agement use cases but the keys itself may be used for same cryptographic operations.
188 FCS_CKM.5/ECC Cryptographic key derivation – ECC key pair derivation
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryp-
tographic operation]: fulfilled
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled
FCS_CKM.5.1/ECC
The TSF shall derive cryptographic elliptic curve keys pair70 from
seed given from external entity71 in accordance with a specified cryp-
tographic key derivation algorithms ECC key pair generation with el-
liptic curves table 6.1.072 using bit string derived from input parame-
ters with DKDF_ECC_PRF 73 and specified cryptographic key sizes
key size in the table 6.1.074 that meet the following: standards in the
table 6.1.0, [TR-03111], [BIP32]75.
189 Application Note 18: The elliptic key pair derivation applies a key derivation function
(KDF) to the input parameter. It uses the output string of KDF instead of the random bit
string as input for the ECC key generation algorithm ([ECCTR, section 4.1.1, Algorithm 1
or 2]. The input parameters shall include a secret of the length at least of the key size to
67 [selection: elliptic curves in the table in para 159]
68 [selection: key size in the table in para 159]
69 [assignment: list of standards]
70 [assignment: key type]
71 [assignment: input parameters]
72 [selection: elliptic curves in the table in para 159]
73 [assignment: KDF]
74 [selection: key size in the table in para 159]
75 [assignment: list of standards]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 41/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
ensure the confidentiality of the private key. The input parameters may include public
known values or even values provided by external entities.
190 FCS_CKM.1/RSA Cryptographic key generation – RSA key pair
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_CKM.5 Cryp-
tographic key derivation, or FCS_COP.1 Cryptographic operation]:
fulfilled
[FCS_RBG.1 Random bit generation, or FCS_RNG.1 Generation of
random numbers]: fulfilled.
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled.
FCS_CKM.1.1/RSA
The TSF shall generate cryptographic RSA keys pairs in accordance
with a specified cryptographic key generation algorithm RSA76 and
cryptographic key sizes 2048, 3072, 4096 bits77 that meet the follow-
ing: PKCS #1 v2.2 [RFC8017]78.
191 Application Note 19: The cryptographic key sizes assigned in FCS_CKM.1/RSA must be
at least 2000 bits. Cryptographic key sizes of at least 3000 bits are recommended. The
FCS_CKM.1/RSA assigns given security attributes Key identity and Key entity. The se-
curity attribute Key usage type is DS-RSA for the private signature-creation key and pub-
lic signature-verification key, RSA_ENC for public RSA encryption key and private RSA
decryption key.
192 FCS_CKM.5/ECDHE Cryptographic key derivation – Elliptic Curve Diffie-
Hellman ephemeral key
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryp-
tographic operation]: fulfilled
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled
FCS_CKM.5.1/ECDHE
The TSF shall derive cryptographic ephemeral keys for data encryp-
tion and MAC with AES-128, [selection: AES-256, none other] 79
from an agreed shared secret80 in accordance with a specified cryp-
tographic key derivation algorithm Elliptic Curve Diffie-Hellman
ephemeral key agreement with elliptic curves table 6.1.081 and DH
group in table 6.1.082 with a key derivation from the shared secret
76 [assignment: cryptographic key generation algorithm]
77 [assignment: cryptographic key sizes]
78 [assignment: list of standards]
79 [selection: AES-256, none other]
80 [assignment: input parameters]
81 [selection: elliptic curves in table 2]
82 [selection: DH group in table 3]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 42/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
[assignment: key derivation function] 83 and specified cryptographic
key sizes 128 bits, [selection:256 bits, none other]84 that meet the
following: TR-03111 [TR-03111]85.
193 Application Note 20: The input parameter for key derivation is an agreed shared secret
established by means of Elliptic Curve Diffie-Hellman. The tables in 6.1.0 list elliptic
curves and the Diffie-Hellman Groups for agreement of the shared secret. The SHA-1
shall be supported for generation of 128 bits AES keys. The SHA-256 shall be selected
and used to generate 256 bits AES keys.
194 Application Note 21: This TSFR is not implemented in the TOE because it is neither se-
lected in FCS_COP.1/HEM nor in FCS_COP.1/HDM. The functionality of
FCS_CKM.5/ECDHE is therefore not needed in the scope of the TOE and would not be
reachable over any TSFI. For that reason, the TSFR-operation from the Base-PP was
not concretized in this ST.
195 FCS_CKM.1/ECKA-EG Cryptographic key generation – ECKA-EG key gen-
eration
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_CKM.5 Cryp-
tographic key derivation, or FCS_COP.1 Cryptographic operation]:
fulfilled
[FCS_RBG.1 Random bit generation, or FCS_RNG.1 Generation of
random numbers]: fulfilled.
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled.
FCS_CKM.1.1/ECKA-EG
The TSF shall generate an ephemeral cryptographic elliptic curve
key pair for ECKGA-EG ([ECCTR], sender role) in accordance with a
specified cryptographic key generation algorithms ECC key pair gen-
eration with elliptic curves in 6.1.086 and specified cryptographic key
sizes key sizes in 6.1.087 that meet the following: standards in 6.1.088.
196 FCS_CKM.5/ECKA-EG Cryptographic key derivation – ECKA-EG key deriva-
tion
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryp-
tographic operation]: fulfilled
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled
83 [selection: SHA-256, none other]
84 [selection: 256 bits, none other]
85 [assignment: list of standards]
86 [selection: elliptic curves in table 2]
87 [selection: key size in the table 2]
88 [assignment: list of standards]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 43/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
FCS_CKM.5.1/ECKA-EG
The TSF shall derive cryptographic data encryption key and MAC
keys for AES-128, AES-25689 from a private and a public ECC key90
in accordance with a specified cryptographic key derivation algorithm
ECKGA-EG [ECCTR] elliptic curves in 6.1.091 and X9.6 3 Key Deriva-
tion Function92 and specified cryptographic symmetric key sizes 128
bits, 256 bits93 that meet the following: TR-03111 [ECCTR, chap.
4.3.2.2]94.
197 Application Note 22: FCS_CKM.5/ECKA-EG is used by both the sender (encryption) and
the recipient (decryption) to compute a secret point SAB on an elliptic curve and the de-
rived shared secret ZAB. The shared secret is then used as input to the key derivation
function to derive two symmetric keys, the encryption key and the MAC key which are
used to encrypt or decrypt the message according to FCS_COP.1/HEM or
FCS_COP.1/HDM, respectively. Sender and recipient use however different inputs to
FCS_CKM.5/ECKA-EG. The sender first generates an ephemeral ECC key pair accord-
ing to FCS_CKM.1/ECKA-EG and uses the generated ephemeral private key and the
static public key of the recipient as input. The recipient first extracts the ephemeral public
key from the encrypted message and uses the ephemeral public key and the static pri-
vate key (cf. FCS_CKM.1/ECC for key generation) as input. The selection of elliptic
curve, the ECC key size and length of the shared secret shall correspond to the selec-
tion of the AES key size, e. g. brainpoolP256r1 and 256 bits seed, ECC key and AES
keys. FCS_CKM.1/ECKA-EG and FCS_CKM.5/ECKA-EG do not provide self-contained
security services for the user but are necessary steps for FCS_COP.1/HEM and
FCS_COP.1/HDM (refer to the next section 6.1.3).
198 FCS_CKM.1/AES_RSA Cryptographic key generation – Key generation and
RSA encryption
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_CKM.5 Cryp-
tographic key derivation, or FCS_COP.1 Cryptographic operation]:
fulfilled
[FCS_RBG.1 Random bit generation, or FCS_RNG.1 Generation of
random numbers]: fulfilled.
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled.
FCS_CKM.1.1/AES_RSA
The TSF shall generate and encrypt seed, derive cryptographic
keys from seed for data encryption and MAC with AES-128, AES-
256 95 in accordance with a specified cryptographic key algorithm
89 [selection: AES-256, none other]
90 [assignment: input parameters]
91 [selection: elliptic curves in table 2]
92 [assignment: cryptographic key derivation algorithm]
93 [selection: 256 bits, none other]
94 [assignment: list of standards]
95 [selection: AES-256, none other]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 44/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
X9.6 3 Key Derivation Function [ANSI-X9.63] and RSA EME-OAEP
[PKCS#1] 96 and specified cryptographic symmetric key sizes 128
bits, 256 bits97 that meet the following [ISO18033-3], PKCS #1 v2.2
[RFC8017, chapter 3.5]98.
199 Application Note 23: The asymmetric cryptographic key sizes used in FCS_CKM.1/
AES_RSA must be at least 2000 bits. Cryptographic key sizes of at least 3000 bits are
recommended. FCS_CKM.1/AES_RSA and FCS_CKM.5/AES_RSA do not provide self-
contained security services for the user but they are only necessary steps for
FCS_COP.1/HEM respective FCS_COP.1/HDM (refer to the next section 6.1.3).
200 FCS_CKM.5/AES_RSA Cryptographic key derivation – RSA key derivation
and decryption
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryp-
tographic operation]: fulfilled
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled
FCS_CKM.5.1/AES_RSA
The TSF shall derive cryptographic data encryption key and MAC key
for AES-128, AES-25699 from decrypted RSA encrypted seed100 in
accordance with a specified cryptographic key derivation algorithm
RSA-EME-OAEP [PKCS#1] and X9.63 [ANSI-X9.63] Key Derivation
Function101 and specified cryptographic symmetric key sizes 128
bits, 256 bits102 that meet the following: [ISO14888-2, chap. 3.5]103.
201 FCS_CKM.6 Timing and event of 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, or
FCS_CKM.5 Cryptographic key derivation]: fulfilled
FCS_CKM.6.1
The TSF shall destroy cryptographic private/secret key generated by
the iterations of FCS_CKM.1104 when upon the deallocation of the
resource.105
FCS_CKM.6.2
96 [assignment: cryptographic key generation algorithm]
97 [selection: 256 bits, none other]
98 [assignment: list of standards]
99 [selection: AES-256, none other]
100 [assignment: input parameters]
101 [assignment: cryptographic key derivation algorithm]
102 [selection: 256 bits, none other]
103 [assignment: list of standards]
104 [assignment: list of cryptographic keys (including keying material)]
105 [selection: no longer needed, [assignment: other circumstances for key or keying material destruction]]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 45/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
The TSF shall destroy cryptographic keys and keying material speci-
fied by FCS_CKM.6.1 in accordance with a specified cryptographic
key destruction method physical deletion by overwriting the memory
data with zeros, random numbers or the new key106 that meets the
following: none107.
202 Refinement: The destruction of cryptographic keys shall ensure that any previous infor-
mation content of the resource about the key is made unavailable upon the deallocation
of the resource.
203 Application Note 24: FCS_CKM.4, which was used in the Base-PP, is deprecated in
CC:2022; FCS_CKM.6 shall be used instead. FCS_CKM.6 describes additionally the
timing and event of key destruction. Because the refinement in the Base-PP defines the
timing of the destruction (“…upon the deallocation of the resource…) the SFR of the
Base-PP can be mapped to FCS_CKM.6. The Refinement above is now integrated in
the SFR but stays here for compatibility reasons to the Base-PP.
6.1.1.5 Key import and export
204 FCS_COP.1/KW Cryptographic operation – Key wrap
Hierarchical to: No other components
Dependencies: [FDP_ITC.1 Import of user data without security attributes,
orFDP_ITC.2 Import of user data with security attributes,
FCS_CKM.1 Cryptographic key generation]: fulfilled
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled
FCS_COP.1.1/KW
The TSF shall perform key wrap108 in accordance with a specified
cryptographic algorithm AES-Keywrap KW 109 and cryptographic key
sizes of the key encryption key 128 bits, 256 bits110 that meet the
following: [SP800-38F]111.
205 Application Note 25: The selection of the length of the key encryption key shall be equal
or greater than the security bits of the wrapped key.
206 FCS_COP.1/KU Cryptographic operation – Key unwrap
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]: fulfilled
FCS_COP.1.1/KU
106 [assignment: cryptographic key destruction method]
107 [assignment: list of standards]
108 [assignment: list of cryptographic operations]
109 [selection: KW, KWP]
110 [selection: 256 bits, none other]
111 [assignment: list of standards]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 46/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
The TSF shall perform key unwrap112 in accordance with a specified
cryptographic algorithm AES-Keywrap KW113 and cryptographic key
sizes of the key encryption key 128 bits, 256 bits114 that meet the
following: [SP800-38F]115.
207 Application Note 26: The selection of the length of the key encryption key shall be equal
or greater than the security bits of the wrapped key.
208 FPT_TCT.1/CK TSF data confidentiality transfer protection – Cryptographic keys
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
[FMT_MTD.1 Management of TSF data or FMT_MTD.3 Secure
TSF data]: fulfilled
FPT_TCT.1.1/CK
The TSF shall enforce the Key Management SFP116 by providing the
ability to transmit and receive117 cryptographic key TSF data in a
manner protected from unauthorized disclosure according to
FCS_COP.1/KW and FCS_COP.1/KU.
209 FPT_TIT.1/CK TSF data integrity transfer protection – Cryptographic keys
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
[FMT_MTD.1 Management of TSF data or FMT_MTD.3 Secure TSF
data]: fulfilled
FPT_TIT.1.1/CK
The TSF shall enforce the Key Management SFP118 to transmit and
receive119 cryptographic key TSF data in a manner protected from
modification and insertion120 errors according to FCS_COP.1/KW
and FCS_COP.1/KU.
FPT_TIT.1.2/CK
The TSF shall be able to determine on receipt of cryptographic key
TSF data, whether modification and insertion121 has occurred ac-
cording to FCS_COP.1/KU.122.
210 FPT_ISA.1/CK Import of TSF data with security attributes – Cryptographic keys
112 [assignment: list of cryptographic operations]
113 [selection: KW, KWP]
114 [selection: 256 bits, none other]
115 [assignment: list of standards]
116 [assignment: access control SFP, information flow control SFP]
117 [selection: transmit, receive, transmit and receive]
118 [assignment: access control SFP, information flow control SFP]
119 [selection: transmit, receive, transmit and receive]
120 [selection: modification, deletion, insertion, replay]
121 [selection: modification, deletion, insertion, replay]
122 [assignment: list of standards]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 47/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
[FMT_MTD.1 Management of TSF data or FMT_MTD.3 Secure TSF
data]: fulfilled
[FMT_MSA.1 Management of security attributes or FMT_MSA.4
Security attribute value inheritance]: fulfilled
FPT_TDC.1 Inter-TSF basic TSF data consistency: fulfilled
FPT_ISA.1.1/CK
The TSF shall enforce the Key Management SFP123 when importing
cryptographic key TSF data, controlled under the SFP, from outside
of the TOE.
FPT_ISA.1.2/CK
The TSF shall use the security attributes associated with the imported
cryptographic key TSF data.
FPT_ISA.1.3/CK
The TSF shall ensure that the protocol used provides for the unam-
biguous association between the security attributes and the crypto-
graphic key TSF data received.
FPT_ISA.1.4/CK
The TSF shall ensure that interpretation of the security attributes of
the imported TSF data is as intended by the source of the crypto-
graphic key TSF data.
FPT_ISA.1.5/CK
The TSF shall enforce the following rules when importing crypto-
graphic key TSF data controlled under the SFP from outside the
TOE124:
(1) The TSF imports the TSF data in certificates only after success-
ful verification of the validity of the certificate including verifica-
tion of digital signature of the issuer and validity time period.
(2) none125.
211 Application Note 27: The operational environment is obligated to provide trust center
services for secure key management, cf. OE.SecManag.
212 FPT_TDC.1/CK Inter-TSF basic TSF data consistency – Keys
Hierarchical to: No other components
Dependencies: No dependencies
FPT_TDC.1.1/CK
The TSF shall provide the capability to consistently interpret security
attributes of the imported cryptographic keys126 when shared be-
tween the TSF and another trusted IT product.
123 [assignment: access control SFP, information flow control SFP]
124 [assignment: importation control rules]
125 [assignment: additional importation control rules]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 48/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
FPT_TDC.1.2/CK
The TSF shall use the following rules:
(1) the TOE reports about conflicts between the Key identity of
stored cryptographic keys and cryptographic keys to be import-
ed,
(2) the TOE does not change the security attributes Key identity,
Key type, Key usage type and Key validity time period of the
key being imported127
when interpreting the imported key data object TSF data from an-
other trusted IT product.
213 FPT_ESA.1/CK Export of TSF data with security attributes – Cryptographic keys
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
[FMT_MTD.1 Management of TSF data or FMT_MTD.3 Secure TSF
data]: fulfilled
[FMT_MSA.1 Management of security attributes or FMT_MSA.4
Security attribute value inheritance]: fulfilled
FPT_TDC.1 Inter-TSF basic TSF data consistency: fulfilled
FPT_ESA.1.1/CK
The TSF shall enforce the Key Management SFP128 when exporting
cryptographic key TSF data, controlled under the SFP(s), outside of
the TOE.
FPT_ESA.1.2/CK
The TSF shall export the cryptographic key TSF data with the cryp-
tographic key’s TSF data associated security attributes.
FPT_ESA.1.3/CK
The TSF shall ensure that the security attributes, when exported out-
side the TOE, are unambiguously associated with the exported cryp-
tographic key TSF data.
FPT_ESA.1.4/CK
The TSF shall enforce the following rules when cryptographic key
TSF data is exported from the TOE: none129.
214 Application Note 28: There are no fixed rules for presentation of security attributes de-
fined. The element FPT_ESA.1.4/CK must define rules expected in FPT_TDC.1 Inter-
TSF basic TSF data consistency if inter-TSF key exchange is intended. In this ST are no
rules for inter-TSF key exchange foreseen.
126 [assignment: list of TSF data types]
127 [assignment: list of interpretation rules to be applied by the TSF]
128 [assignment: access control SFP, information flow control SFP]
129 [assignment: exportation control rules]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 49/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
6.1.2 Data encryption
215 FCS_COP.1/ED Cryptographic operation – Data 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]: fulfilled
FCS_COP.1.1/ED
The TSF shall perform data encryption and decryption130 in accord-
ance with a specified cryptographic algorithm symmetric data encryp-
tion according to AES-128 and AES-256131 in CBC and no other
mode 132 and cryptographic key size 128 bits, 256 bits133, that meet
the following: [SP800-38A], [ISO18033-3], [ISO10116]134.
216 Application Note 29: Data encryption and decryption should be combined with data in-
tegrity mechanisms in Encrypt-then-MAC order, i. e. the MAC is calculated for the ci-
phertext and verified before decryption. The modes of operation should combine encryp-
tion with data integrity mechanisms to authenticated encryption, e. g. the Cipher Block
Chaining Mode (CBC, cf. NIST SP800-38A) should be combined with CMAC (cf.
FCS_COP.1/MAC) or HMAC (cf. FCS_COP.1/HMAC). For combination of symmetric
encryption, decryption and data integrity mechanisms by means of CCM or GCM refer to
the next section.
6.1.3 Hybrid encryption with MAC for user data
217 FCS_COP.1/HEM Cryptographic operation – Hybrid data encryption and MAC calcula-
tion
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]: fulfilled
FCS_COP.1.1/HEM
The TSF shall perform hybrid data encryption and MAC calculation135
in accordance with a specified cryptographic algorithm asymmetric
key encryption according to FCS_CKM.1/ECKA-EG,
FCS_CKM.1/AES_RSA136, symmetric data encryption according to
AES-128, AES-256137 [FIPS197] in CBC [NIST-SP800-38A] 138 mode
130 [assignment: list of cryptographic operations]
131 [selection: AES-256, no other algorithm]
132 [selection: CRT mode, OFB mode, CFB mode, no other mode]
133 [selection: 256 bits, no other key size]
134 [assignment: list of standards]
135 [assignment: list of cryptographic operations]
136 [selection: FCS_CKM.1/ECKA-EG, FCS_CKM.1/AES_RSA]
137 [selection: AES-256, none other]
138 [selection: CBC, CCM, GCM]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 50/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
with CMAC[NIST-SP800-38B ], calculation139 and cryptographic
symmetric key sizes 128 bits, 256 bits140 that meet the following:
[ISO18033-3], [ISO10116], [FIPS197]141.
218 Application Note 30: Hybrid data encryption and MAC calculation is a self-contained se-
curity service of the TOE. The generation and encryption of the seed, derivation of en-
cryption and MAC keys as well as the AES encryption and MAC calculation are only
steps of this service. The hybrid encryption is combined with MAC as data integrity
mechanisms for the cipher text, i.e. encrypt-then-MAC creation for CMAC.
219 FCS_COP.1/HDM Cryptographic operation – Hybrid data decryption and MAC verifica-
tion
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]: fulfilled
FCS_COP.1.1/HDM
The TSF shall perform MAC verification and hybrid data decryption142
in accordance with a specified cryptographic algorithm asymmetric
key decryption according to FCS_CKM.5/ECKA-EG,
FCS_CKM.5/AES_RSA143, verification of CMAC[NIST-SP800-38B],
144 and symmetric data decryption according to AES with AES-128,
AES-256145 [FIPS197] in mode CBC [NIST-SP800-38A] 146 and cryp-
tographic symmetric key sizes 128 bits, 256 bits147 [FIPS197] that
meet the following: [ISO18033-3], [ISO10116], [FIPS197]148.
220 Application Note 31: Hybrid data decryption and MAC verification is a self-contained se-
curity service of the TOE. The decryption of the seed and derivation of the encryption
key and MAC keys as well as the AES decryption and MAC verification are only steps of
this service. The used symmetric key shall meet the AES CMAC and the AES algorithm
for decryption of the cipher text for MAC, e.g. verification-then-decrypt for CMAC.
6.1.4 Data integrity mechanisms
221 Cryptographic data integrity mechanisms comprise 2 types of mechanisms – symmetric
message authentication code mechanisms and asymmetric digital signature mecha-
nisms. A message authentication code mechanism comprises the generation of a MAC
for original message, the verification of a given pair of message and MAC and symmetric
139 [selection: CMAC, GMAC, HMAC]
140 [selection: 256 bits, none other]
141 [assignment: list of standards]
142 [assignment: list of cryptographic operations]
143 [selection: FCS_CKM.1/ECKA-EG, FCS_CKM.1/AES_RSA]
144 [selection: CMAC, GMAC, HMAC]
145 [selection: AES-256, none other]
146 [selection: CBC, CCM, GCM]
147 [selection: 256 bits, none other]
148 [assignment: list of standards]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 51/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
key management. The MAC may be applied to plaintext without encryption but if com-
bined with encryption it should be applied to cipher texts in Encrypt-then-MAC order.
222 FCS_COP.1/MAC Cryptographic operation – MAC using 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]: fulfilled
FCS_COP.1.1/MAC
The TSF shall perform MAC generation and verification149 in accord-
ance with a specified cryptographic algorithm AES-128 and AES-
256150 [FIPS197] CMAC [NIST-SP800-38B] and no other 151 and
cryptographic key sizes 128 bits, 256 bits152 that meet the following:
[SP800-38B], [ISO9797-1], [SP800-38D], [FIPS197]153.
223 Application Note 32: The MAC may be applied to plaintext and cipher text. The AES-128
CMAC is mandatory. The selection of AES-256 and the key sizes shall correspond to
each other.
224 FCS_COP.1/HMAC Cryptographic operation – HMAC
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]: fulfilled
FCS_COP.1.1/HMAC
The TSF shall perform HMAC generation and verification154 in ac-
cordance with a specified cryptographic algorithm HMAC-SHA256
and no other155 and cryptographic key sizes 128, 256 bits156 that
meet the following: [RFC2104], [ISO9797-2]157.
225 Application Note 33: The cryptographic key is a random bit string generated by. FCS_\
RNG.1 or a referenced internal secret. The cryptographic key sizes assigned in FCS_\
COP.1/HMAC must be at least 128 bits.
226 FCS_COP.1/CDS-ECDSA Cryptographic operation – Creation of digital signatures EC-
DSA
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]: fulfilled
149 [assignment: list of cryptographic operations]
150 [selection: AES-256, none other]
151 [selection: GMAC, no other]
152 [selection: 256 bits, none other]
153 [assignment: list of standards]
154 [assignment: list of cryptographic operations]
155 [selection: HMAC-SHA-1, HMAC- SHA384, no other]
156 [assignment: cryptographic key sizes]
157 [assignment: list of standards]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 52/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
FCS_COP.1.1/CDS-ECDSA
The TSF shall perform signature-creation158 in accordance with a
specified cryptographic algorithm EC-DSA with elliptic curves in the
table 6.1.0159 and specified cryptographic key sizes corresponding
key sizes in the table 6.1.0 160 that meet the following: corresponding
standard in the table, [ANSX9.63], [SP800-56C]161.
227 Application Note 34: The selection of elliptic curve and cryptographic key sizes shall cor-
respond to each other, e.g. elliptic curve brainpoolP256r1 and key size 256 bits.
228 FCS_COP.1/VDS-ECDSA Cryptographic operation – Verification of digital signatures
ECDSA
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]: fulfilled
FCS_COP.1.1/VDS-ECDSA
The TSF shall perform signature-verification162 in accordance with a
specified cryptographic algorithm EC-DSA with elliptic curves in the
table 6.1.0163 and specified cryptographic key sizes corresponding
key sizes in the table 6.1.0164 that meet the following: corresponding
standard in the table, [ANSX9.63], [SP800-56C]165.
229 FCS_COP.1/CDS-RSA Cryptographic operation – Creation of digital signatures
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]: fulfilled
FCS_COP.1.1/CDS-RSA
The TSF shall perform signature-creation166 in accordance with a
specified cryptographic algorithm RSA and EMSA-PSS167 and cryp-
tographic key sizes 2048, 3072, 4096 bits168 that meet the following:
[ISO14888-2], PKCS #1, v2.2 [RFC8017]169.
230 Application Note 35: The cryptographic key sizes assigned in FCS_CKM.1/RSA must be
at least 2000 bits. Cryptographic key sizes of at least 3000 bits are recommended.
158 [assignment: list of cryptographic operations]
159 [selection: elliptic curves in the table in para 159]
160 [selection: key size in the table in para 159]
161 [assignment: list of standards]
162 [assignment: list of cryptographic operations]
163 [selection: elliptic curves in the table in para 159]
164 [selection: key size in the table in para 159]
165 [assignment: list of standards]
166 [assignment: list of cryptographic operations]
167 [assignment: cryptographic algorithm]
168 [assignment: cryptographic key sizes]
169 [assignment: list of standards]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 53/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
231 FCS_COP.1/VDS-RSA Cryptographic operation – Verification of digital signatures RSA
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]: fulfilled
FCS_COP.1.1/VDS-RSA
The TSF shall perform signature-verification170 in accordance with a
specified cryptographic algorithm RSA and EMSA-PSS171 and cryp-
tographic key sizes 2048, 3072, 4096 bits172 that meet the following:
[ISO14888-2], PKCS #1, v2.2 [RFC8017]173.
232 Application Note 36: The cryptographic key sizes assigned in FCS_CKM.1/RSA must be
at least 2000 bits. Cryptographic key sizes of at least 3000 bits are recommended.
233 FDP_DAU.2/Sig Data Authentication with Identity of Guarantor - Signature
Hierarchical to: FDP_DAU.1 Basic Data Authentication
Dependencies: FIA_UID.1 Timing of identification: fulfilled
FDP_DAU.2.1/Sig
The TSF shall provide a capability to generate evidence that can be
used as a guarantee of the validity of user data174 imported accord-
ing to FDP_ITC.2/UD by means of FCS_COP.1/CDS-RSA,
FCS_COP.1/CDS-ECDSA175 and keys holding the security attrib-
utes Key identity assigned to the guarantor and Key usage type
“Signature service”.
FDP_DAU.2.2/Sig
The TSF shall provide external entities176 with the ability to verify evi-
dence of the validity of the indicated information and the identity of
the user that generated the evidence.
234 Application Note 37: The TSF according to FDP_DAU.2/Sig is intended for a signature
service for user data. The user data source shall select the security attributes Key entity
of the guarantor and Key usage type “Signature service” of the cryptographic key for the
signature service in the security attributes provided with the user data. The user data
source subject shall meet the Key access control attributes for the signature-creation
operation. The verification of the evidence requires a certificate showing the identity of
the key entity as user generated the evidence and the key usage type as digital signa-
ture.
235 FDP_DAU.2/TS Data Authentication with Identity of Guarantor – Signature with time
stamp and optional key usage counter
Hierarchical to: FDP_DAU.1 Basic Data Authentication
170 [assignment: list of cryptographic operations]
171 [assignment: cryptographic algorithm]
172 [assignment: cryptographic key sizes]
173 [assignment: list of standards]
174 [assignment: list of objects or information types]
175 [selection: FCS_COP.1/CDS-RSA, FCS_COP.1/CDS-ECDSA]
176 [assignment: list of subjects]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 54/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Dependencies: FIA_UID.1 Timing of identification: fulfilled
FDP_DAU.2.1/TS
The TSF shall provide a capability to generate evidence that can be
used as a guarantee of the existence at certain point in time, se-
quence and validity of
(a) user data imported according to FDP_ITC.2/UD,
(b) exported audit trails according to FMT_MTD.1/Audit clause (1)
and FAU_STG.4 clause (1)177
with
(1) time stamp of the evidence generation according to
FPT_STM.1,
(2) and optionally the key usage counter of the signature key
by means of digital signature generated according to
FCS_COP.1/CDS-RSA, FCS_COP.1/CDS-ECDSA178 and keys
holding the dedicated values of the security attributes Key iden-
tity that indicate key ownership of the TOE and Key usage type
“Time stamp service” 179.
FDP_DAU.2.2/TS
The TSF shall provide external entities180 with the ability to verify evi-
dence of the validity of the indicated information and the identity of
the user that generated the evidence.
236 Application Note 38: The TSF according to FDP_DAU.2/TS is intended for time stamp
service of the TOE for any provided user data and exported audit records. The user data
source shall select the security attribute Key usage type “TimeStamp” of the signature
key of the time stamp service. The signature key of exported audit records shall be de-
fined according to FMT_MOF.1.1 clause (9). The Key usage counter allows to verify the
sequence of signed data e.g. in an audit trail. The verification of the evidence requires a
certificate showing the identity of the TOE sample and the key usage type of time stamp
service. The format of input data and output data shall meet the BSI TR-03151 [SE API].
6.1.5 Authentication and attestation of the TOE, trusted channel
237 FIA_API.1/PACE Authentication Proof of Identity – PACE authentication to Application
component
Hierarchical to: No other components
Dependencies: No dependencies
FIA_API.1.1/PACE
The TSF shall provide a PACE in ICC role181 to prove the identity of
the TOE182 to an external entity and establishing a trusted channel
according to FTP_ITC.1 case 1 or 2.
177 [assignment: list of objects or information types]
178 [selection: FCS_COP.1/CDS-RSA, FCS_COP.1/CDS-ECDSA]
179 Der hier "Time stamp service" genannte Key Usage Type wird außerhalb der SFR generell als "TimeStamp" bezeichnet.
180 [assignment: list of subjects]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 55/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
238 FIA_API.1/CA Authentication Proof of Identity – Chip authentication to user
Hierarchical to: No other components
Dependencies: No dependencies
FIA_API.1.1/CA
The TSF shall provide a Chip Authentication Version 2 according to
[EACTR, part 2, section 3.4]183 to prove the identity of the TOE184 to
an external entity and establishing a trusted channel according to
FTP_ITC.1 case 3.
239 FDP_DAU.2/Att Data Authentication with Identity of Guarantor – Attestation
Hierarchical to: FDP_DAU.1 Basic Data Authentication
Dependencies: FIA_UID.1 Timing of identification: fulfilled
FDP_DAU.2.1/Att
The TSF shall provide a capability to generate evidence that can be
used as a guarantee of the validity of attestation data185 by means of
FCS_COP.1/CDS-ECDSA186 and keys holding the security attrib-
utes Key identity assigned to the TOE sample and Key usage
type “Attestation”.
FDP_DAU.2.2/Att
The TSF shall provide external entities187 with the ability to verify evi-
dence of the validity of the indicated information and the identity of
the user that generated the evidence.
240 Application Note 39: The attestation data shall represent the TOE sample as genuine
sample of the certified product. The attestation data may include the identifier of the cer-
tified product, the serial number of the device or a group of product samples as certified
product, the hash value of the TSF implementation and some TSF data as result of self-
test or other data. It may be generated internally or may include internally generated and
externally provided data. The assigned cryptographic mechanisms shall be appropriate
for attestation meeting OSP.SecCryM, e.g. digital signature, a group signature or a direct
anonymous attestation mechanism as used for Trusted Platform Modules [TPM] or FIDO
U2F Authenticators [FIDO].
241 FTP_ITC.1 Inter-TSF trusted channel
Hierarchical to: No other components
Dependencies: No dependencies
FTP_ITC.1.1
The TSF shall provide a communication channel between TSF and
another trusted IT product that is logically distinct from other commu-
181 [assignment: authentication mechanism]
182 [assignment: object, authorized user or role]
183 [assignment: authentication mechanism]
184 [assignment: object, authorized user or role]
185 [assignment: list of objects or information types]
186 [selection: FCS_COP.1/CDS-RSA, FCS_COP.1/CDS-ECDSA, ECDAA according to [selection: [TPM], [FIDO]]
187 [assignment: list of subjects]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 56/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
nication channels logically separated from other communication
channels188 and provides assured identification of its end points Au-
thentication of TOE and remote entity according to the case in
the following table189 and protection of the channel data from modi-
fication or disclosure according to the case in the following ta-
ble190 as required by cryptographic operation according to the
case in the table191.
FTP_ITC.1.2
The TSF shall permit the remote trusted IT product192 determined
according to FMT_MOF.1.1 clause (3) to initiate communication via
the trusted channel.
FTP_ITC.1.3
The TSF shall initiate communication via the trusted channel for
communication with entities defined according to FMT_MOF.1.1
clause (4)193.
Case Authentication of TOE and
remote entity
Key agreement Protection of
communica-
tion data
Cryptographic
operation
1 FIA_API.1/PACE,
FIA_UAU.5.1(2)
FCS_CKM.1/PAC
E
modification FCS_COP.1/TC
M
2 FIA_API.1/PACE,
FIA_UAU.5.1 (2)
FCS_CKM.1/PAC
E
modification FCS_COP.1/TC
M
disclosure FCS_COP.1/TC
E
3 FIA_API.1/CA,
FIA_UAU.5.1 (4) or (5),
and (6)
FCS_CKM.1/TCA
P
modification FCS_COP.1/TC
M
disclosure FCS_COP.1/TC
E
Table: Operation in SFR for trusted channel
242 FCS_CKM.1/PACE Cryptographic key generation – Key agreement for trusted channel
PACE
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Crypto-
graphic operation]: fulfilled
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
188 [selection: logically separated from other communication channels, using physical separated ports]
189 [selection: Authentication of TOE and remote entity according to the case in the table]
190 [assignment: according to the case in the table]
191 [selection: cryptographic operation according to the case in the table]
192 [selection: the TSF, the remote trusted IT product]
193 [assignment: list of functions for which a trusted channel is required]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 57/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
filled
FCS_CKM.1.1/PACE
The TSF shall generate cryptographic keys for MAC with
FCS_COP.1/TCM and if selected encryption keys for
FCS_COP.1/TCE in accordance with a specified cryptographic key
generation agreement algorithm PACE with elliptic curves in the ta-
ble 6.1.0194 and Generic Mapping in ICC role195 and specified crypto-
graphic key sizes 256 bits196 that meet the following: [ICAO9303, Part
11, section 4.4]197.
243 Application Note 40: PACE is used to authenticate the TOE and the application compo-
nent or TOE and human user using a terminal. It establishes a trusted channel with MAC
integrity protection and if selected encryption.
244 FCS_CKM.1/TCAP Cryptographic key generation – Key agreement by Terminal and
Chip authentication protocols
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution or FCS_COP.1 Crypto-
graphic operation]: fulfilled
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled
FCS_CKM.1.1/TCAP
The TSF shall generate cryptographic keys for encryption accord-
ing to FCS_COP.1/TCE and MAC according to FCS_COP.1/TCM
in accordance with a specified cryptographic key generation agree-
ment algorithm Terminal Authentication version 2 and Chip Authenti-
cation Version 2 198 and specified cryptographic key sizes 256 bits199
that meet the following: [EACTR, section 3.3 and 3.4]200.
245 Application Note 41: The terminal authentication protocol version 2 is used for authen-
tication of the Application component according to FIA_UAU.5 and is a prerequisite for
Chip Authentication Version 2.
246 FCS_COP.1/TCE Cryptographic operation - Encryption for trusted channel
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]: fulfilled
FCS_COP.1.1/TCE
194 [selection: elliptic curves in para 159 ]
195 [assignment: cryptographic algorithm]
196 [selection: 128 bits, 192 bits, 256 bits]
197 [assignment: list of standards]
198 [assignment: cryptographic algorithm]
199 [selection: 128 bits, 192 bits, 256 bits]
200 [assignment: list of standards]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 58/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
The TSF shall perform encryption and decryption201 in accordance
with a specified cryptographic algorithm AES in CBC [NIST-SP800-
38A] mode202 and cryptographic key sizes 256 bits 203 that meet the
following: [FIPS197] 204.
247 FCS_COP.1/TCM Cryptographic operation - MAC for trusted channel
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]: fulfilled
FCS_COP.1.1/TCM
The TSF shall perform MAC calculation and MAC verification205 in
accordance with a specified cryptographic algorithm AES in
CMAC[NIST-SP800-38B], mode206 and cryptographic key sizes 256
bits 207 that meet the following: [FIPS197] 208.
6.1.6 User identification and authentication
248 FIA_ATD.1 User attribute definition – Identity based authentication
Hierarchical to: No other components
Dependencies: No dependencies
FIA_ATD.1.1
The TSF shall maintain the following list of security attributes belong-
ing to individual users209:
(1) Identity,
(2) Authentication reference data,
(3) Role.
249 FMT_MTD.1/RAD Management of TSF data – Authentication reference data
Hierarchical to: No other components
Dependencies: FMT_SMR.1 Security roles: fulfilled
FMT_SMF.1 Specification of Management Functions: fulfilled
FMT_MTD.1.1/RAD
The TSF shall restrict the ability to
(1) create210 the initial Authentication reference data of all author-
201 [assignment: list of cryptographic operations]
202 [selection: CBC, CCM, GCM]
203 [selection: 128 bits, 192 bits, 256 bits]
204 [assignment: list of standards]
205 [assignment: list of cryptographic operations]
206 [selection: CMAC[NIST-SP800-38B ], GMAC[NIST-SP800-38D]]]
207 [selection: 128 bits, 192 bits, 256 bits]
208 [assignment: list of standards]
209 [assignment: list of security attributes]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 59/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
ized users211 to User Administrator212 213,
(2) delete210 the Authentication reference data of an authorized
user211 to User Administrator 213,
(3) modify210 the Authentication reference data211 to the corre-
sponding authorized user213
(4) create210 the permanently stored session key of trusted
channel as Authentication reference data211 to User Admin-
istrator 213
(5) define210 the time in range [0..6553.5, infinity seconds]214
after which the user security attribute Role is reset accord-
ing to FMT_SAE.1 211 to User Administrator 213,
(6) define210 the value Unidentified user215 to which the securi-
ty attribute Role shall be reset according to FMT_SAE.1 211
to User Administrator 213.
250 Application Note 42: The Administrator is responsible for user management. The Admin-
istrator install and revoke a user as known authorized user of the TSF as defined in
clause (1). The Administrator may define additional authentication reference data as de-
scribed in clause (3), i. e. the trusted channel combines initial authentication of commu-
nication endpoints (cf. FIA_UAU.5.1 clause (3) and (4)) with agreement of session keys
used for authentication of exchanged messages (cf. FIA_UAU.5.1 clause (5)). The ses-
sion keys may be permanently stored for the trusted communication with the known au-
thorized entity. The user manages its own authentication reference data to prevent im-
personation based of known authentication data (e.g. as addressed by FMT_MTD.3).
The bullets (2) to (6) are refinements in order to avoid an iteration of component and
therefore printed in bold.
251 FMT_MTD.3 Secure TSF data
Hierarchical to: No other components
Dependencies: FMT_MTD.1 Management of TSF data: fulfilled
FMT_MTD.3.1
The TSF shall ensure that only secure values are accepted for pass-
words216 by enforcing change of initial passwords after first suc-
cessful authentication of the user to different operational pass-
word.
252 FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components
Dependencies: FIA_UAU.1 Timing of authentication: fulfilled
FIA_AFL.1.1
210 [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
211 [assignment: list of TSF data]
212 [selection: Administrator, User Administrator]
213 [assignment: the authorized identified roles]
214 [assignment: time frame]
215 [selection: Unidentified user, Unauthenticated user]
216 [assignment: list of TSF data]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 60/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
The TSF shall detect when a positive integer number as shown in the
rows of the following Table 217unsuccessful authentication attempts
occur related to user authentication218.
FIA_AFL.1.2
When the defined number of unsuccessful authentication attempts
has been met219, the TSF shall block the corresponding user authen-
tication220.
253 Application Note 43: All password ADRs are configured to use the transmission format
ASCII, i.e. each digit has a value range from 0 to 255. A minimum password length of
e.g. 10 Bytes means therefore that the probability of acceptance of an authentication
failure is about 2-80
.
254 FIA_USB.1 User-subject binding
Hierarchical to: No other components
Dependencies: FIA_ATD.1 User attribute definition: fulfilled
FIA_USB.1.1
The TSF shall associate the following user security attributes with
subjects acting on the behalf of that user:
(1) Identity,
(2) Role221.
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: the
initial role of the user is Unidentified user222.
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
217 [selection: [assignment: positive integer number], an [selection: Administrator, User Administrator] configurable positive
integer within [assignment: range of acceptable values]]
218 [assignment: list of authentication events]
219 [selection: met, surpassed]
220 [assignment: list of actions]
221 [assignment: list of user security attributes]
222 [assignment: rules for the initial association of attributes]
ADR Role Retry Counter
Minimum password
length
PWD.TimeAdmin Timekeeper None, i.e. infinite 16 bytes
PWD.Auditor Auditor None, i.e. infinite 16 bytes
PWD.UpdateAgent Update Agent 8 10 Bytes
PWD.CryptoOfficer Crypto Officer None, i.e. infinite 16 bytes
PWD.UserAdmin User Administrator 5 16 bytes
Security Target TCOS CSP Module Version 2.0 Release 1/P71 61/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
of users:
(1) after successful identification of the user the attribute Role of
the subject shall be changed from Unidentified user to Unau-
thenticated user;
(2) after successful authentication of the user for a selected role the
attribute Role of the subject shall be changed from Unauthenti-
cated User to that role;
(3) after successful re-authentication of the user for a selected role
the attribute Role of the subject shall be changed to that role223.
255 FMT_SAE.1 Time-limited authorization
Hierarchical to: No other components
Dependencies: FMT_SMR.1 Security roles: fulfilled
FPT_STM.1 Reliable time stamps: fulfilled
FMT_SAE.1.1
The TSF shall restrict the capability to specify an expiration time for
Role224 to User Administrator225.
FMT_SAE.1.2
For each of these security attributes, the TSF shall be able to reset
the Role to the value assigned according to FMT_MTD.1/RAD, clause
(6)226 after the expiration time for the indicated security attribute has
passed.
256 Application Note 44: The TSF implement means to handle expiration time for the roles
within a session (i.e. between power-up and power-down of the TOE) which may not
necessarily meet the requirements for a reliable time stamp as required by FPT_STM.1.
Since this ST requires FPT_STM.1 this time stamp is used to meet FMT_SAE.1.
257 FIA_UID.1 Timing of identification
Hierarchical to: No other components
Dependencies: No dependencies
FIA_UID.1.1
The TSF shall allow227
(1) self test according to FPT_TST.1,
(2) identification of the TOE to the user,
(3) none228
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 the
223 [assignment: rules for the changing of attributes]
224 [assignment: list of security attributes for which expiration is to be supported]
225 [selection: Administrator, User Administrator] [assignment: the authorized identified roles]
226 [assignment: list of actions to be taken for each security attribute]
227 [assignment: list of TSF mediated actions]
228 [assignment: list of other TSF-mediated actions]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 62/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Unauthenticated User.
258 FIA_UAU.1 Timing of authentication
Hierarchical to: No other components
Dependencies: FIA_UID.1 Timing of identification: fulfilled
FIA_UAU.1.1
The TSF shall allow229
(1) self test according to FPT_TST.1,
(2) authentication of the TOE to the user,
(3) identification of the user to the TOE and selection of a role230
for authentication,
(4) none231
on behalf of the user to be performed before the user is authenticat-
ed.
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 us-
er.
259 Application Note 45: Clause (2) and (3) in FIA_UAU.1.1 allows mutual identification for
mutual authentication, e.g. by exchange of certificates.
260 FIA_UAU.5 Multiple authentication mechanisms
Hierarchical to: No other components
Dependencies: No dependencies
FIA_UAU.5.1
The TSF shall provide232
(1) password authentication,
(2) PACE with Generic Mapping with TOE in ICC and user in PCD
context with establishment of trusted channel according to
FTP_ITC.1,
(3) certificate based Terminal Authentication Version 2 according to
section 3.3 in [EACTR-2] with the TOE in ICC and user in PCD
context,
(4) Terminal Authentication Version 2 with the TOE in ICC context
and user in PCD context modified by omitting the verification of
the certificate chain according to [EACTR-2],
(5) certificate based Chip Authentication Version 2 with establish-
ment of trusted channel according to FTP_ITC.1,
(6) message authentication by MAC verification of received mes-
sages
to support user authentication.
229 [assignment: list of TSF mediated actions]
230 [selection: a role, a set of role]
231 [assignment: list of other TSF mediated actions]
232 [assignment: list of multiple authentication mechanisms]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 63/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
FIA_UAU.5.2
The TSF shall authenticate any user’s claimed identity according to
the rules233
(1) password authentication shall be used for authentication of hu-
man users if enabled according to FMT_MOF.1.1, clause (1),
(2) PACE shall be used for authentication of human users using
terminals with establishment of trusted channel according to
FTP_ITC.1,
(3) PACE may be used for authentication of IT entities with estab-
lishment of trusted channel according to FTP_ITC.1,
(4) certificate based Terminal Authentication Version 2 may be
used for authentication of users which certificate imported as
TSF data,
(5) simplified version of Terminal Authentication Version 2 may be
used for authentication of identified users associated with
known user’s public key,
(6) certificate based Chip Authentication Version 2 with establish-
ment of trusted channel according to FTP_ITC.1 may be used
for authentication of users which certificate imported as TSF da-
ta,
(7) message authentication by MAC verification of received mes-
sages shall be used after initial authentication of remote entity
according to clauses (2), (3) or (6) for trusted channel according
to FTP_ITC.1,
(8) none 234.
261 FIA_UAU.6 Re-authenticating
Hierarchical to: No other components
Dependencies: No dependencies
FIA_UAU.6.1
The TSF shall re-authenticate the user under the conditions235
(1) changing to a role not selected for the current valid authentica-
tion session,
(2) power on or reset,
(3) every message received from entities after establishing trusted
channel according to FIA_UAU.5.1, clause (2), (3) or (6),
(4) none 236.
6.1.7 Access control
262 FDP_ITC.2/UD Import of user data with security attributes – User data
Hierarchical to: No other components
233 [assignment: rules describing how the multiple authentication mechanisms provide authentication]
234 [assignment: additional rules]
235 [assignment: list of conditions under which re-authentication is required]
236 [assignment: list of other conditions under which re-authentication is required]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 64/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
[FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path]:
fulfilled
FPT_TDC.1 Inter-TSF basic TSF data consistency: fulfilled
FDP_ITC.2.1/UD
The TSF shall enforce the Cryptographic Operation SFP237 when
importing user data, controlled under the SFP, from outside of the
TOE.
FDP_ITC.2.2/UD
The TSF shall use the security attributes associated with the imported
user data.
FDP_ITC.2.3/UD
The TSF shall ensure that the protocol used provides for the unam-
biguous association between the security attributes and the user data
received.
FDP_ITC.2.4/UD
The TSF shall ensure that interpretation of the security attributes of
the imported user data is as intended by the source of the user data.
FDP_ITC.2.5/UD
The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TOE:
(1) user data imported for encryption according to FCS_COP.1/ED
shall be imported with Key identity of the key and the identifica-
tion of the requested cryptographic operation,
(2) user data imported for encryption according to FCS_COP.1/
HEM shall be imported with Key identity of the public key en-
cryption key or key agreement method,
(3) user data imported for decryption according to FCS_COP.1/
HDM shall be imported with Key identity of the asymmetric de-
cryption key, encrypted seed and data integrity check sum,
(4) user data imported for digital signature creation shall be import-
ed with the Key identity of the private signature key,
(5) user data imported for digital signature verification shall be im-
ported with digital signature and Key identity of the public signa-
ture key238.
263 Application Note 46: Keys to be used for the cryptographic operation of the imported
user data are identified by security attribute Key identity.
264 FDP_ETC.2 Export of user data with security attributes
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
237 [assignment: access control SFP]
238 [assignment: additional importation control rules]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 65/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
FDP_ETC.2.1
The TSF shall enforce the Cryptographic Operation SFP239 when
exporting user data, controlled under the SFP(s), outside of the TOE.
FDP_ETC.2.2
The TSF shall export the user data with the user data's associated
security attributes.
FDP_ETC.2.3
The TSF shall ensure that the security attributes, when exported out-
side the TOE, are unambiguously associated with the exported user
data.
FDP_ETC.2.4240
The TSF shall ensure that interpretation of the security attributes of
the exported user data is as intended by the owner of the user data.
FDP_ETC.2.5
The TSF shall enforce the following rules when user data is exported
from the TOE:
(1) user data exported as ciphertext according to FCS_COP.1/HEM
shall be exported with reference to key decryption key, encrypt-
ed data encryption key and data integrity check sum,
(2) user data exported as plaintext according to FCS_COP.1/HDM
shall be exported only if the MAC verification confirmed the in-
tegrity of the ciphertext,
(3) user data exported as signed data according to FCS_COP.1/
CDS-ECDSA or FCS_COP.1/CDS-RSA shall be exported with
digital signature and Key identity of the used signature-creation
key241.
265 Application Note 47: The TOE imports data to be signed by CSP with Key identity of the
signature key and exports the signature. In case of internally generated data exported as
signed data shall be exported with Key identity of the used key in order to enable identi-
fication of the corresponding signature verification key. Note, the TOE may implement
more than one signature-creation key for signing internally generated data.
266 FDP_ETC.1 Export of user data without security attributes
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
FDP_ETC.1.1
The TSF shall enforce the Cryptographic Operation SFP242 when
exporting user data as plaintext according to FCS_COP.1/HDM,
controlled under the SFP(s), outside of the TOE.
239 [assignment: access control SFP]
240 FDP_ETC.2.4 of CC:2022 was inserted compared to the version V3.1 of common criteria
241 [assignment: additional exportation control rules]
242 [assignment: access control SFP]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 66/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
FDP_ETC.1.2
The TSF shall export the user data successfully MAC verified and
decrypted ciphertext as plaintext according to FCS_COP.1/HDM
without the user data's associated security attributes.
267 FDP_ACC.1/Oper Subset access control – Cryptographic operation
Hierarchical to: No other components
Dependencies: FDP_ACF.1 Security attribute based access control: fulfilled
FDP_ACC.1.1/Oper
The TSF shall enforce the Cryptographic Operation SFP243 on
(1) subjects: Crypto-Officer244, Key Owner, none245;
(2) objects: operational cryptographic keys, user data;
(3) operations: cryptographic operation246.
268 FDP_ACF.1/Oper Security attribute based access control – Cryptographic operations
Hierarchical to: No other components
Dependencies: FDP_ACC.1 Subset access control: fulfilled
FMT_MSA.3 Static attribute initialization: fulfilled
FDP_ACF.1.1/Oper
The TSF shall enforce the Cryptographic Operation SFP247 to objects
based on the following:
(1) subjects: subjects with security attribute Role Crypto-Officer248,
Key Owner, none249;
(2) objects:
(a) cryptographic keys with security attributes: Identity of the
key, Key entity, Key type, Key usage type, Key access control
attributes, Key validity time period;
(b) user data250.
FDP_ACF.1.2/Oper
The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
(1) Subject in Crypto-Officer251 role is allowed to perform crypto-
graphic operation on cryptographic keys in accordance with
their security attributes.
(2) Subject Key Owner is allowed to perform cryptographic opera-
243 [assignment: access control SFP]
244 [selection: Administrator, Crypto-Officer]
245 [assignment: other roles]
246 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
247 [assignment: access control SFP]
248 [selection: Administrator, Crypto-Officer]
249 [assignment: other roles]
250 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attrib-
utes, or named groups of SFP-relevant security attributes]
251 [selection: Administrator, Crypto-Officer]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 67/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
tion on user data with cryptographic keys in accordance with the
security attribute Key entity, Key type, Key usage type, Key ac-
cess control attributes and Key validity time period;
(3) none252.
FDP_ACF.1.3/Oper
The TSF shall explicitly authorize access of subjects to objects based
on the following additional rules:
(1) subjects with security attribute Role are allowed to perform
cryptographic operation on user data and cryptographic keys
with security attributes as shown in the rows of the following
Table.
(2) none253.
FDP_ACF.1.4/Oper
The TSF shall explicitly deny access of subjects to objects based on
on the following additional rules:
(1) No subject is allowed to use cryptographic keys by cryptograph-
ic operation other than those identified in the security attributes
Key usage type and the Key access control attributes;
(2) No subject is allowed to decrypt ciphertext according to
FCS_COP.1/HDM if MAC verification fails.
(3) none254.
Access control rules for cryptographic operation
Crypto-Officer,
Key Owner255
Key type: symmetric
Key usage type: Key wrap
Key validity time period
FCS_COP.1/KW
Crypto-Officer 255 Key type: symmetric
Key usage type: Key unwrap
Key validity time period
FCS_COP.1/KU
(any authenticat-
ed user))
Key type: public
Key usage type: ECKA-EG
Key validity time period: as in certifi-
FCS_COP.1/HEM,
FCS_CKM.1/ECKA-EG
252 [assignment: other rules governing access among controlled subjects and controlled objects using controlled operations
on controlled objects]
253 [assignment: additional rules, based on security attributes, that explicitly authorize access of subjects to objects]
254 [assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects]
255 [selection: Administrator, Crypto-Officer]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 68/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
cate
Key Owner Key type: private
Key usage type: ECKA-EG
Key validity time period:
FCS_COP.1/HDM,
FCS_CKM.5/ECKA-EG
(any authenticat-
ed user)
Key type: public
Key usage type: RSA_ENC
Key validity time period: as in certifi-
cate
FCS_COP.1/HEM,
FCS_CKM.1/AES_RSA
Key Owner Key type: private
Key usage type: RSA_ENC
Key validity time period: as in certifi-
cate
FCS_COP.1/HDM,
FCS_CKM.5/AES_RSA
Key Owner Key type: private
Key usage type: DS-ECDSA
Key validity time period:
FCS_COP.1/DS-ECDSA
(any authenticat-
ed user)
Key type: public
Key usage type: DS-ECDSA
Key validity time period:
FCS_COP.1/DS-ECDSA
Key Owner Key type: private
Key usage type: DS-RSA
Key validity time period:
FCS_COP.1/CDS-RSA
(any authenticat-
ed user)
Key type: public
Key usage type: DS-RSA
Key validity time period:
FCS_COP.1/VDS-RSA
269 FDP_ITC.2/TS Import of user data with security attributes – User
data for time stamping
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
[FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path]:
fulfilled
Security Target TCOS CSP Module Version 2.0 Release 1/P71 69/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
FPT_TDC.1 Inter-TSF basic TSF data consistency: fulfilled
FDP_ITC.2.1/TS
The TSF shall enforce the Cryptographic Operation SFP256 when
importing user data, controlled under the SFP, from outside of the
TOE.
FDP_ITC.2.2/TS
The TSF shall use the security attributes associated with the imported
user data.
FDP_ITC.2.3/TS
The TSF shall ensure that the protocol used provides for the unam-
biguous association between the security attributes and the user data
received.
FDP_ITC.2.4/TS
The TSF shall ensure that interpretation of the security attributes of
the imported user data is as intended by the source of the user data.
FDP_ITC.2.5/TS
The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TOE:
(1) user data imported for time stamp generation to FDP_\
DAU.2/TS shall be imported with security attributes Key identity
of the signature key and Key usage type TimeStamp, and the
identification of the requested cryptographic operation257.
270 Application Note 48: Keys to be used for the cryptographic operation of the imported
user data are identified by security attribute Key identity.
271 FDP_ETC.2/TS Export of user data with security attributes – User
data with time stamp
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
FDP_ETC.2.1/TS
The TSF shall enforce the Cryptographic Operation SFP258 when
exporting user data, controlled under the SFP(s), outside of the TOE.
FDP_ETC.2.2/TS
The TSF shall export the user data with the user data's associated
security attributes.
FDP_ETC.2.3/TS
The TSF shall ensure that the security attributes, when exported out-
side the TOE, are unambiguously associated with the exported user
256 [assignment: access control SFP]
257 [assignment: additional importation control rules]
258 [assignment: access control SFP]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 70/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
data.
FDP_ETC.2.4/TS259
The TSF shall ensure that interpretation of the security attributes of
the exported user data is as intended by the owner of the user data.
FDP_ETC.2.4/TS
The TSF shall enforce the following rules when user data is exported
from the TOE:
(1) user data exported as time stamped data according to FDP_\
DAU.2/TS shall be exported with digital signature and Key iden-
tity of the used signature-creation key260.
272 Application Note 49: The TOE imports data to be signed by CSP shall be imported with
Key identity of the signature key and exports the signature. In case of internally generat-
ed data (e.g. audit records) exported as signed data shall be exported with Key identity
of the used key in order to enable identification of the corresponding signature-
verification key. Note, the TOE may implement more than one signature-creation key for
signing internally generated data.
273 FDP_ACF.1/TS Security attribute based access control – Crypto
graphic operations
Hierarchical to: No other components
Dependencies: FDP_ACC.1 Subset access control: fulfilled
FMT_MSA.3 Static attribute initialization: fulfilled
FDP_ACF.1.1/TS
The TSF shall enforce the Cryptographic Operation SFP261 to objects
based on the following:
(1) subjects: subjects with security attribute Role Application Com-
ponent, no other role262;
(2) objects: user data263.
FDP_ACF.1.2/TS
The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
(1) Application Component, no other role264 is allowed to perform
cryptographic operation according to FDP_DAU.2/TS on user
data with cryptographic keys with Key usage type TimeStamp.
(2) none265.
FDP_ACF.1.3/TS
259 FDP_ETC.2.4 of CC:2022 was inserted compared to the version V3.1 of common criteria
260 [assignment: additional exportation control rules]
261 [assignment: access control SFP]
262 [assignment: other roles]
263 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attrib-
utes, or named groups of SFP-relevant security attributes]
264 [assignment: other roles]
265 [assignment: other rules governing access among controlled subjects and controlled objects using controlled operations
on controlled objects]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 71/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
The TSF shall explicitly authorize access of subjects to objects based
on the following additional rules: none266.
FDP_ACF.1.4/TS
The TSF shall explicitly deny access of subjects to objects based on
on the following additional rules:
(1) No subject is allowed to use cryptographic keys by cryptograph-
ic operation other than those identified in the security attributes
Key usage type and the Key access control attributes;
(2) none267.
6.1.8 Security Management
274 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) management of security functions behavior (FMT_MOF.1),
(2) management of Authentication reference data
(FMT_MTD.1/RAD),
(3) management of security attributes of cryptographic keys
(FMT_MSA.1/KM, FMT_MSA.2, FMT_MSA.3/KM,
(4) none268.
275 FMT_SMR.1 Security roles
Hierarchical to: No other components
Dependencies: FIA_UID.1 Timing of identification: fulfilled
FMT_SMR.1.1
The TSF shall maintain the roles269:
Unidentified User, Unauthenticated User, Key Owner, Application
component, Crypto-Officer, User Administrator, Update Agent270,
Personalization Agent, no other roles271.
FMT_SMR.1.2
The TSF shall be able to associate users with roles.
266 [assignment: additional rules, based on security attributes, that explicitly authorize access of subjects to objects]
267 [assignment: additional rules, based on security attributes, that explicitly deny access of subjects to objects]
268 [assignment: list additional of security management functions to be provided by the TSF]
269 [assignment: authorized identified roles]
270 [selection: Administrator, Crypto-Officer, User Administrator, Update Agent]
271 [selection: [assignment: other roles], no other roles]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 72/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
276 FMT_SMR.1/TSA Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1/TSA
The TSF shall maintain the roles additional to those required by
FMT_SMR.1 in the Base-PP: Auditor and Timekeeper272.
FMT_SMR.1.2/TSA
The TSF shall be able to associate users with roles.
277 FMT_SMF.1/TSA Specification of Management Functions
Hierarchical to: No other components
Dependencies: No dependencies
FMT_SMF.1.1/TSA
The TSF shall be capable of performing the following management
functions:
(1) management of security functions behavior MT_MOF.1/TSA273.
278
279 FMT_MSA.2 Secure security
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control] : fulfilled
FMT_MSA.1 Management of security attributes: fulfilled
FMT_SMR.1 Security roles: fulfilled
FMT_MSA.2.1
The TSF shall ensure that only secure values are accepted for securi-
ty attributes
(1) Key identity,
(2) Key type,
(3) Key usage type,
(4) none274.
The cryptographic keys shall have
(1) Key identity uniquely identifying the key among all keys
implemented in the TOE,
(2) exactly one Key type as secret key, private key, public key,
(3) exactly one Key usage type identifying exactly one crypto-
graphic mechanism the key can be used for.
280 FMT_MOF.1 Management of security functions behaviour
272 [selection: Auditor,Timekeeper, no other roles]
273 [assignment: list of management functions to be provided by the TSF]
274 [assignment: additional security attributes]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 73/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Hierarchical to: No other components
Dependencies: FMT_SMR.1 Security roles: fulfilled
FMT_SMF.1 Specification of Management Functions: fulfilled
FMT_MOF.1.1
The TSF shall restrict the ability to
(1) enable275 the functions password authentication according to
FIA_UAU.5.1, clause (1)276 to User Administrator277.
(2) disable275 the functions password authentication according
to FIA_UAU.5.1, clause (1)276 to User Administrator277,
(3) determine the behavior of275 the functions trusted channel
according to FDP_ITC.1.2276 by defining the remote trusted
IT products permitted to initiate communication via the
trusted channel to User Administrator277,
(4) determine the behavior of275 the functions trusted channel
according to FDP_ITC.1.3276 by defining the entities for
which the TSF shall enforce communication via the trusted
channel to User Administrator277.
281 Application Note 50: The refinements of FMT_MOF.1.1 in bullets (2) to (4) are made in
order to avoid iteration of the component. In case of client-server architecture the appli-
cations using the TOE and supporting cryptographically protected trusted channel be-
long to the entities for which the TSF shall enforce trusted channel according to
FDP_ITC.1, cf. FMT_MOF.1.1 in bullet (4).
282 FMT_MOF.1/TSA Management of security functions behaviour
Hierarchical to: No other components
Dependencies: FMT_SMR.1 Security roles: fulfilled
FMT_SMF.1 Specification of Management Functions: ful-
filled
FMT_MOF.1.1/TSA
The TSF shall restrict the ability to
(1)modify the behaviour of278 the functions adjustment of the internal clock
according to FPT_STM.1 clause (1)279 to Timekeeper 280,
(2) modify the behaviour of281 the functions adjustment of the internal clock
according to FPT_STM.1 clause (2)282 to Timekeeper 283,,
275 [selection: determine the behavior of, disable, enable, modify the behavior of]
276 [assignment: list of functions]
277 [selection: Administrator, User Administrator]
278 [assignment: list of management functions to be provided by the TSF]
279 [assignment: list of functions]
280 [selection: Administrator, Timekeeper]
281 [selection: determine the behaviour of, disable, enable, modify the behaviour of]
282 [assignment: list of functions]
283 [selection: Administrator, Timekeeper]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 74/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
(3)determine the behaviour of and modify the behaviour of284 the func-
tions select the auditable events according to FAU_GEN.1285 to Au-
ditor 286,
(4)determine the behaviour of and modify the behaviour of287 the func-
tions automatic export of audit trails according to FAU_STG.4.1
clause (1) 288 to Auditor 289
(5)determine the behaviour of and modify the behaviour of290 the
functions FDP_DAU.2/TS by selection of signature key used to sign
exported audit trails291 to Auditor 292.
283 Application note 51: The SFR defines additional management of security functions be-
haviour for new SFR with respect to the Base-PP. The refinements of
FMT_MOF.1.1/TSA in bullets (2) to (5) are made in order to avoid further iterations of the
component.
6.1.9 Security audit
284 FAU_GEN.1 Audit data generation
Hierarchical to: No other components
Dependencies: FPT_STM.1 Reliable time stamps: fulfilled
FAU_GEN.1.1
The TSF shall be able to generate audit data
of the following auditable events:
(a) Start-up and shutdown of the audit functions;
(b) All auditable events for the not specified293 level of audit;
(c) Discrete adjustment of the real time clock
(1) by automatic adjustment of the clock according to
FPT_STM.1.1 clause (2) if selected as auditable event,
(2) by Administrator according to FPT_STM.1.1 clause (1)
or(2),
(3) failure of adjustment according to FPT_STM.1.1
(d) other auditable events
(1) Start-up after power-up,
(2) Import of UCP (FDP_ITC.2/UCP),
284 [selection: determine the behaviour of, disable, enable, modify the behaviour of]
285 [assignment: list of functions]
286 [selection: Administrator, Auditor]
287 [selection: determine the behaviour of, disable, enable, modify the behaviour of]
288 [assignment: list of functions]
289 [selection: Administrator, Auditor]
290 [selection: determine the behaviour of, disable, enable, modify the behaviour of]
291 [assignment: list of functions]
292 [selection: Administrator, Auditor]
293 [selection: choose one of: minimum, basic, detailed, not specified]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 75/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
(3) Authentication failure handling (FIA_AFL.1): the reaching of
the threshold for the unsuccessful authentication attempts
with claimed Identity of the user,
(4) no other event294
FAU_GEN.1.2
The TSF shall record within the audit data at least the following infor-
mation:295
(a) Date and time of the event, type of event, subject identity (if ap-
plicable), and the outcome (success or failure) of the event;
(b) For each audit event type, based on the auditable event defini-
tions of the functional components included in the PP, PP-
Module, functional package or ST, none296.
285 Application Note 52: The SFR FDP_ITC.2/UCP, FIA_AFL.1, FCS_CKM.1, FCS_COP.1,
FCS_CKM.4297, FPT_FLS.1 and FMT_MOF.1 are defined in the Base-PP. The SFR
FPT_\ STM.1, FMT_MOF.1/TSA and FMT_MTD.1/AUDIT are defined in the PP-Module.
286 FMT_MTD.1/Audit Management of TSF data
Hierarchical to: No other components
Dependencies: FMT_SMR.1 Security roles: fulfilled
MT_SMF.1 Specification of Management Functions: fulfilled
FMT_MTD.1.1/Audit
The TSF shall restrict the ability to
(1) manual export,
(2) clear after manual export,
(3) select audited events in FAU_GEN.1,
(4) define the number of audit records causing automatic export
and clearing of exported audit records according to
FAU_STG.4.1 clause (1),
(5) define the percentage of storage capacity of audit records if
actions are assigned in FAU_STG.4.1 clause (2)298
the audit records299 to Auditor300.
287 Application Note 53: The selection of auditable events according to FMT_MTD.1.1/Audit,
clause (3) enables or disables or specifies the generation of audit records as defined in
FAU_GEN.1. For security reasons the selection of auditable events according to clause
(3) can only be done once and the functionality is then blocked for the remaining life cy-
cle of the TOE. Clause (2) requires that the TOE only allow the deletion of the audit rec-
ords after the current status of the audit records has been read out.
294 [selection: …] cf. the list of other events in the Protection Profile CSPPP
295 PPCSP uses the old text of CC3.1: ‘The TSF shall record within each audit record at least the following information:’
296 [assignment: other audit relevant information]
297 FCS_CKM.4 defined in the Base-PP is replaced by FCS_CKM.6 since CC:2022
298 [selection: change_default, query, modify, delete, clear,[assignment: other operations]]
299 [assignment: list of TSF data]
300 [selection: Auditor, Administrator]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 76/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
288 Application Note 54: Automatic export as defined in clause (4) is not possible on a typi-
cal smartcard or secure element hardware. The Auditor defines the maximum number of
records to store. The threshold for automatic export of audit trails is therefore defined to
be always higher than the number of records to store.
289 FAU_STG.2301 Protected audit trail storage
Hierarchical to: No other components
Dependencies302: FAU_GEN.1 Audit data generation: fulfilled
FTP_ITC.1 Inter-TSF trusted channel: fulfilled
FAU_STG.2.1
The TSF shall protect the stored audit records in the audit trail from
unauthorized deletion.
FAU_STG.2.2
The TSF shall be able to prevent303 unauthorized modifications to the
stored audit records in the audit trail.
290 FAU_STG.4304 Action in Case of Possible Audit Data Loss
Hierarchical to: No other components
Dependencies: FAU_STG.2 Protected audit trail storage: fulfilled
FAU_STG.4.1
The TSF shall
(1) automatically export audit trails and clear automatically export-
ed audit records305 if the audit trail exceeds an Auditor306 de-
fined number of audit records within [maximum number of audit
records+1.. maximum number of audit records+1]307
(2) blocks all TSF which possibly trigger an audit event308 if
the audit trail exceeds an Auditor309 settable percentage of
storage capacity.
291 FPT_STM.1 Reliable time stamps
Hierarchical to: No other components
Dependencies: No dependencies
FPT_STM.1.1
The TSF shall be able to provide reliable time stamps by means
of 310 internal clock with accuracy 10 percent 311 with the ability
of adjustment of the clock by the TimeKeeper 312.
301 CC:2022 moved FAU_STG.1 Protected audit trail storage to FAU_STG.2.
302 CC:2022 additional defines FTP_ITC.1 Inter-TSF trusted channel as dependency, CSPMOD does not. This dependency is
fulfilled, anyway.
303 [selection: choose one of: prevent, detect]
304 CC:2022 moved FAU_STG.3 Action in Case of Possible Audit Data Loss to FAU_STG.4.
305 [assignment: actions to be taken in case of possible audit storage failure]
306 [selection: Administrator, Auditor]
307 [assignment: pre-defined range]
308 [assignment: actions to be taken in case of possible audit storage failure]
309 [selection: Administrator, Auditor]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 77/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
292 Application Note 55: The external trustable source (e.g. signed Network Time Protocol)
provides a reliable time source for adjustment of the internal clock. The time intervals of
adjustments in clause (2) may be configured by the administrator. Any adjustment or
failure of adjustment of the internal clock is an auditable event according to
FAU_GEN.1.1.The refinement with selection defines different cases for internal clocks
and are therefore printed in bold.
293 FPT_TIT.1/Audit TSF data integrity transfer protection – Audit functionality
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
[FMT_MTD.1 Management of TSF data or FMT_MTD.3 Secure TSF
data]: fullfilled
FPT_TIT.1.1/Audit
The TSF shall enforce the Update SFP, Cryptographic Operation SFP
313 to transmit314 TSF data audit records in a manner protected from
modification, deletion, insertion and replay315 errors.
FPT_TIT.1.2/Audit
The TSF shall be able to determine on receipt of TSF data time,
whether modification316 has occurred.
294 Application Note 56: The Update SFP is enforced by the export of audit records about
import of UCP, cf. FAU_GEN.1.1 clause c) (2). The selection of the Key Management
SFP or Cryptographic Operation SFP depends of the selection of auditable events of key
management, cryptographic operations and adjustment of the internal clock (e. g. used
for verification of validity time period) in FAU_GEN.1.1 clause c). The TSF transmits au-
dit records and receives time as TSF data for security audit. The TSF protects the audit
records by means of digital signature against modification and by means of time stamps
and key usage counter of the signature key as part of the signature against deletion, in-
sertion and replay as required in FPT_TIT.1.1.
6.1.10 Protection of the TSF
295 FDP_SDC.1 Stored data confidentiality
Hierarchical to: No other components
Dependencies: No dependencies
FDP_SDC.1.1
310 [selection: (1) internal clock with accuracy [assignment: approximate deviation] with the ability of adjustment of the clock
by the [selection: Administrator, Timekeeper], (2) internal clock with accuracy [assignment: approximate deviation] with au-
tomatic adjustment of the clock by an externally trustable source in a cryptographically verifiable manner (e.g. by signed
Network Time Protocol) and the ability of adjustment of the clock by the [selection: administrator, timekeeper]]
311 [assignment: approximate deviation]
312 [selection: administrator, timekeeper]
313 [selection: Key Management SFP, Cryptographic Operation SFP]
314 [selection: transmit, receive, transmit and receive]
315 [selection: modification, deletion, insertion, replay]
316 [selection: modification, deletion, insertion, replay]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 78/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
The TSF shall ensure the confidentiality of the information of the user
data317 while it is stored in the memory protected by PUF of the
hardware318 by encryption according to FCS_COP.1/SDE.
296 Application Note 57: The memory encryption does not distinguish between user data
and TSF data when encrypting memory areas. The refinement extends the SFR to any
data in the assigned memory area, which may contain user data, TSF data, software
and firmware as TSF implementation.
297 Application Note 58: The extended component definition FDP_SDC defined in the
BasePP (([CSPPP]) was a subset of the one defined in CC:2022. This SFR uses the
CC:2022 version and
298 FCS_CKM.1/SDEK Cryptographic key generation – Stored data encryption key
generation
Hierarchical to: No other components
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryp-
tographic operation]: fulfilled
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled
FCS_CKM.1.1/SDEK
The TSF shall generate cryptographic stored data encryption key in
accordance with a specified cryptographic generation key algorithm
PUF319 using random bit generation according to FCS_RNG.1
and specified cryptographic key sizes 128 bit320 that meet the follow-
ing: [HWST] 321.
299 FCS_COP.1/SDE Cryptographic operation – Stored data encryption
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] : fulfilled
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled
FCS_COP.1.1/SDE
The TSF shall perform stored data encryption and decryption322 in
accordance with a specified cryptographic algorithm PUF323 and cryp-
tographic key sizes 128 bit 324 that meet the following: [HWST]325.
317 [selection: all user data, the following user data [assignment: list of user data]]
318 [assignment: memory area]
319 [assignment: cryptographic key generation algorithm]
320 [assignment: cryptographic key sizes]
321 [assignment: list of standards]
322 [assignment: list of cryptographic operations]
323 [assignment: cryptographic algorithm]
324 [assignment: cryptographic key sizes]
325 [assignment: list of standards]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 79/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
300 Application Note 59: The generation of data encryption keys according to FCS_\
CKM.1/SDEK, the encryption and the decryption according to FCS_COP.1/SDE are only
used for stored data in the memory areas assigned in FDP_SDC.1.1. They are not secu-
rity services of the TOE to the user. If cryptographic algorithm does not provide integrity
protection for stored user data the stored data should contain redundancy for detection
of data manipulation, e.g. in order to meet FPT_TST.1.2 and FPT_TST.1.3.
301 FRU_FLT.2 Limited fault tolerance
Hierarchical to: FRU_FLT.1 Degraded fault tolerance
Dependencies: FPT_FLS.1 Failure with preservation of secure state: fulfilled
FRU_FLT.2.1
The TSF shall ensure the operation of all the TOE’s capabilities when
the following failures occur: exposure to operating conditions which
are not detected according to the requirement Failure with preserva-
tion of secure state (FPT_FLS.1)326.
302 Refinement: The term “failure” above means “circumstances”. The TOE prevents failures
for the “circumstances” defined above.
303 Application Note 60: Environmental conditions include but are not limited to power sup-
ply, clock, and other external signals (e.g., reset signal) necessary for the TOE opera-
tion.
304 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) self test fails,
(2) exposure to operating conditions which may not be tolerated
according to the requirement Limited fault tolerance
(FRU_FLT.2) and where therefore a malfunction could occur,
(3) manipulation and physical probing is detected and secure state
is reached as response (FPT_PHP.3).
305 Refinement: When the TOE is in a secure error mode the TSF shall not perform any
cryptographic operations and all data output interfaces shall be inhibited by the TSF.
306 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-up, at the
request of the authorized user and after power-on327 to demonstrate
the correct operation of the Random Number Generator PTG.2 pro-
326 [assignment: list of types of failures]
327 [selection: during initial start-up, periodically during normal operation, at the request of the authorized user, at the condi-
tions[assignment: conditions under which self test should occur]]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 80/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
vided by the hardware328.
FPT_TST.1.2
The TSF shall provide authorized users with the capability to verify
the integrity of TSF data329.
FPT_TST.1.3
The TSF shall provide authorized users with the capability to verify
the integrity of TSF implementation330.
307 Application Note 61: Note that beside the Random Number Generator other parts of the
TSF are tested periodically during normal operation as well. Nevertheless, this cannot be
requested by the authorized user, except by a power reset. Due to this restriction only
the RNG is included in FPT_TST.
308 FPT_PHP.3 Resistance to physical attack
Hierarchical to: No other components
Dependencies: No dependencies
FPT_PHP.3.1
The TSF shall resist
(1) physical probing and manipulation331 to the TSF implementa-
tion332
(2) perturbation and environmental stress331 to the TSF332 by re-
sponding automatically such that the SFRs are always en-
forced.
309 Refinement: The TSF will implement appropriate mechanisms continuously to counter
physical probing and manipulation.
310 Application Note 62: “Automatic response” of protection against physical probing and
manipulation means (i) assuming that there might be an attack at any time and (ii) coun-
termeasures are provided at any time. Perturbation and environmental stress to the TSF
are relevant when the TOE is running. Note, exploration of information leakage from the
TOE like side channels is addressed as bypassability of TSF by the security architecture
(cf. ADV_ARC.1.1D and ADV_ARC.1.5C) and shall consider these physical attack sce-
narios.
6.1.11 Import and verification of Update Code Package
311 The TOE imports Update Code Package as user data objects with security attributes
according to FDP_ITC.2/UCP, verifies the authenticity of the received Update Code
Package according to FCS_COP.1/VDSUCP, decrypts authentic Update Code Package
according to FCS_COP.1/DecUCP.
328 [selection: [assignment: parts of TSF], the TSF]
329 [selection: [assignment: parts of TSF data], TSF data]
330 [selection: [assignment: parts of TSF], TSF]
331 [assignment: physical tampering scenarios]
332 [assignment: list of TSF devices/elements]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 81/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
312 Note that update packages can only be built by the developer of the TOE and not by the
customer. The customer must coordinate the update strategy with the developer of the
TOE in case of necessary updates.
313 FDP_ITC.2/UCP Import of user data with security attributes – Update Code
Package
Hierarchical to: No other components
Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset infor-
mation flow control]: fulfilled
[FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path]:
fulfilled
FPT_TDC.1 Inter-TSF basic TSF data consistency: fulfilled
FDP_ITC.2.1/UCP
The TSF shall enforce the Update SFP 333 when importing user data,
controlled under the SFP, from outside of the TOE.
FDP_ITC.2.2/UCP
The TSF shall use the security attributes associated with the imported
user data.
FDP_ITC.2.3/UCP
The TSF shall ensure that the protocol used provides for the unam-
biguous association between the security attributes and the user data
received.
FDP_ITC.2.4/UCP
The TSF shall ensure that interpretation of the security attributes of
the imported user data is as intended by the source of the user data.
FDP_ITC.2.5/UCP
The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TOE:
(1) storing of encrypted Update Code Package only after success-
ful verification of authenticity according to
FCS_COP.1/VDSUCP,
(2) decrypts authentic Update Code Package according to
FCS_COP.1/DecUCP334.
314 FPT_TDC.1/UCP Inter-TSF basic TSF data consistency
Hierarchical to: No other components
Dependencies: No dependencies
FPT_TDC.1.1/UCP
The TSF shall provide the capability to consistently interpret security
attributes Issuer and Version Number335 when shared between the
TSF and another trusted IT product.
333 [assignment: access control SFP(s) and/or information flow control SFP(s)]
334 [assignment: additional importation control rules]
335 [assignment: list of TSF data types]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 82/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
FPT_TDC.1.2/UCP
The TSF shall use the following rules:
(1) the Issuer must be identified and known,
(2) the Version Number must be identified
when interpreting the TSF data from another trusted IT product.
315 FCS_COP.1/VDSUCP Cryptographic operation – Verification of digital signature of
the Issuer
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]: fulfilled
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled
FCS_COP.1.1/VDSUCP
The TSF shall perform verification of the digital signature of the au-
thorized Issuer336 in accordance with a specified cryptographic algo-
rithm ECDSA with brainpoolP512t1337 and cryptographic key sizes
512 bit 338 that meet the following: [TCOSGD].339.
316 Application Note 63: The authorized Issuer is identified in the security attribute of the
received Update Code Package and the public key of the authorized Issuer shall be
known as TSF data before receiving the Update Code Package. Only public key of the
authorized Issuer shall be used for verification of the digital signature of the Update
Code Package.
317 FCS_COP.1/DecUCP Cryptographic operation – Decryption of authentic Update
Code Package
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]: fulfilled
FCS_CKM.6 Timing and event of cryptographic key destruction: ful-
filled
FCS_COP.1.1/DecUCP
The TSF shall perform decryption of authentic encrypted Update
Code Package340 in accordance with a specified cryptographic algo-
rithm AES-256 in OFB mode341 and cryptographic key sizes 256
bit342 that meet the following: [FIPS197]343.
336 [assignment: list of cryptographic operations]
337 [assignment: cryptographic algorithm]
338 [assignment: cryptographic key sizes]
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]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 83/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
318 FDP_ACC.1/UCP Subset access control – Update code Package
Hierarchical to: No other components
Dependencies: FDP_ACF.1 Security attribute based access control: fulfilled
FDP_ACC.1.1/UCP
The TSF shall enforce the Update SFP344 on
(1) subjects: Update Agent345;
(2) objects: Update Code Package;
(3) operations: import, store346.
319 FDP_ACF.1/UCP Security attribute based access control – Import Update
Code Package
Hierarchical to: No other components
Dependencies: FDP_ACC.1 Security attribute based access control: fulfilled
FMT_MSA.3 Static attribute initialization: not fulfilled, the security at-
tributes of the UCP are imported according to FDP_ITC.2/UCP
without default values
FDP_ACF.1.1/UCP
The TSF shall enforce the Update SFP347 to objects based on the
following:
(1) subjects: Update Agent348
(2) objects: Update Code Package with security attributes Issuer
and Version Number349.
FDP_ACF.1.2/UCP
The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
(1) Update Agent348 is allowed to import Update Code Package ac-
cording to FDP_ITC.2/UCP.
(2) Update Agent348 is allowed to store Update Code Package if
(a) authenticity is successful verified according to
FCS_COP.1/VDSUCP and decrypted according to
FCS_COP.1/DecUCP
(b) the Version Number of the Update Code Package is equal
or higher than the Version Number of the TSF350.
FDP_ACF.1.3/UCP
The TSF shall explicitly authorize access of subjects to objects based
on the following additional rules: none 351.
344 [assignment: access control SFP(s) and/or information flow control SFP(s)]
345 [selection: Administrator, Update Agent]
346 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
347 [assignment: access control SFP]
348 [selection: Administrator, Update Agent]
349 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attrib-
utes, or named groups of SFP-relevant security attributes]
350 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on
controlled objects]
351 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 84/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
FDP_ACF.1.4/UCP
The TSF shall explicitly deny access of subjects to objects based on
the following additional rules: none352.
320 FDP_RIP.1/UCP Subset residual information protection
Hierarchical to: No other components
Dependencies: No dependencies
FDP_RIP.1.1/UCP
The TSF shall ensure that any previous information content of a re-
source is made unavailable upon the deallocation of the resource
after unsuccessful verification of the digital signature of the Is-
suer according to FCS_COP.1/VDSUCP353 the following objects:
received Update Code Package354.
6.2 Security Assurance Requirements for the TOE
321 The assurance requirements for the evaluation of the TOE, its development and ope-
rating environment are to choose as the predefined assurance package EAL4 augmen-
ted by the following components:
▪ ALC_DVS.2 (Sufficiency of security measures),
▪ ALC_FLR.1 (Basic flaw remediation)
▪ AVA_VAN.5 (Advanced methodical vulnerability analysis).
▪ ATE_DPT.2 (Testing: security enforcing modules)
322 The Protection Profiles BSI-CC-PP0035 [ICPP] and BSI-CC-PP0104 [CSPPP] define
refinements to the TOE Assurance Requirements, which are considered by the TOE De-
veloper under the corresponding assurance packages.
6.3 Security Requirements Rationale
323 A detailed justification required for suitability of the security functional requirements to
achieve the security objectives is given in the PP [CSPPP] and is therefore not repeated
here.
6.3.1 Rationale for SFR’s Dependencies
324 The following table provides an overview for security functional requirements coverage
also giving an evidence for sufficiency and necessity of the SFRs chosen. It refers the
corresponding Table of the Protection Profile [CSPPP]. Note that the SFRs and objec-
tives related to the hardware ST are not considered here.
352 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
353 [selection: allocation of the resource to, deallocation of the resource from]
354 [assignment: list of objects]
Security Target TCOS CSP Module Version 2.0 Release 1/P71 85/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
O.I&A
OT.AuthentTOE
O.Enc
O.DataAuth
O.RBGS
O.TChann
O.AccCtrl
O.SecMan
O.PhysProt
O.TST
O.SecUpCP
O.Audit
O.TimeService
FAU_GEN.1 x
FAU_STG.1 x
FAU_STG.3 x
FCS_CKM.1/AES x x x
FCS_CKM.1/AES_RSA x x x
FCS_CKM.1/ECC x x x x
FCS_CKM.1/ECKA-EG x x x
FCS_CKM.1/PACE x x x
FCS_CKM.1/RSA x x x x
FCS_CKM.1/SDEK x
FCS_CKM.1/TCAP x x x
FCS_CKM.6
FCS_CKM.5/AES x x x
FCS_CKM.5/AES_RSA x x x
FCS_CKM.5/ECC x x x
FCS_CKM.5/ECDHE x x x
FCS_CKM.5/ECKA-EG x x x
FCS_COP.1/CDS-ECDSA x x
FCS_COP.1/CDS-RSA x x x
FCS_COP.1/DecUCP x
FCS_COP.1/ED x x
FCS_COP.1/Hash x x
FCS_COP.1/HDM x x
FCS_COP.1/HEM x x
FCS_COP.1/HMAC x x
FCS_COP.1/KU x
FCS_COP.1/KW x
FCS_COP.1/MAC x
FCS_COP.1/SDE x
FCS_COP.1/TCE x
FCS_COP.1/TCM x
FCS_COP.1/VDS-ECDSA X
FCS_COP.1/VDS-RSA x
FCS_COP.1/VDSUCP X
FCS_RNG.1 x x
FDP_ACC.1/KM x x
FDP_ACC.1/Oper x
FDP_ACC.1/UCP x
FDP_ACF.1/Oper x
FDP_ACF.1/TS x
FDP_ACF.1/UCP x
FDP_DAU.2/Att x
FDP_DAU.2/Sig X
FDP_DAU.2/TS X x
FDP_ETC.1 x
FDP_ETC.2 x x
FDP_ETC.2/TS x
FDP_ITC.2/TS x
FDP_ITC.2/UCP x
FDP_ITC.2/UD x x
Security Target TCOS CSP Module Version 2.0 Release 1/P71 86/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
O.I&A
OT.AuthentTOE
O.Enc
O.DataAuth
O.RBGS
O.TChann
O.AccCtrl
O.SecMan
O.PhysProt
O.TST
O.SecUpCP
O.Audit
O.TimeService
FDP_RIP.1/UCP X
FDP_SDC.1 x
FIA_AFL.1 x
FIA_API.1/CA x x x
FIA_API.1/PACE x x x
FIA_ATD.1 x x x
FIA_UAU.1 x x
FIA_UAU.5 x x
FIA_UAU.6 x
FIA_UID.1 x
FIA_USB.1 x
FMT_MOF.1 x x
FMT_MOF.1/TSA x
FMT_MSA.1/KM x x x x x
FMT_MSA.2 x x
FMT_MSA.3/KM x x x
FMT_MTD.1/Audit x
FMT_MTD.1/KM X
FMT_MTD.1/RAD x
FMT_MTD.1/RK x x x x
FMT_MTD.3 x
FMT_SAE.1 x
FMT_SMF.1 x
FMT_SMF.1/TSA x x
FMT_SMR.1/TSA x x
FMT_SMR.1 x x
FPT_ESA.1/CK x
FPT_FLS.1 x x
FPT_ISA.1/Cert x x x X
FPT_ISA.1/CK x
FPT_PHP.3 x
FPT_STM.1 x x
FPT_TCT.1/CK x x
FPT_TDC.1/Cert x x x X
FPT_TDC.1/CK X
FPT_TDC.1/UCP x
FPT_TIT.1/Audit X
FPT_TIT.1/Cert x x X x
FPT_TIT.1/CK X
FPT_TST.1 x
FRU_FLT.2 x
FTP_ITC.1 X
Table 2: SFR coverage
325 The dependency analysis for the security functional requirements given in the corre-
sponding Table of the Protection Profile [CSPPP] shows that the mutual support and in-
ternal consistency between all defined functional requirements is satisfied or justified.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 87/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
6.3.2 Security Assurance Requirements Rationale
326 The EAL4 was chosen to permit 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 be economically feasible to retrofit to an
existing product line. 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 sensitive security specific engineering costs.
327 The augmentation of the component AVA_VAN.5 provides a higher assurance of the
security by vulnerability analysis to assess the resistance to penetration attacks per-
formed by an attacker possessing a high attack potential.
328 Development security is concerned with physical, procedural, personnel and other tech-
nical measures that may be used in the development environment to protect the TOE. In
the particular case of a cryptographic module the TOE implements security mechanisms
in hardware which details about the implementation, (e. g., from design, test and devel-
opment tools) may make such attacks easier. Therefore, in the case of a cryptographic
module, maintaining the confidentiality of the design and protected manufacturing is very
important and the strength of the corresponding protection measures shall be balanced
with respect to the assumed moderate attack potential. Therefore ALC_DVS.2 was
augmented.
329 ALC_FLR.1 requires that discovered security flaws be tracked and corrected by the de-
veloper.
330 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.
331 The set of assurance components being part of EAL4 fulfils all dependencies a priori.
332 The component AVA_VAN.5 has the following dependencies: ADV_ARC.1, ADV_FSP.4,
ADV_TDS.3, ADV_IMP.1, AGD_OPE.1, AGD_PRE.1, and ATE_DPT.1. All of these are
met or exceeded in the EAL4 assurance package.
333 The component ALC_DVS.2 has no dependencies.
334 The component ALC_FLR.1 has no dependencies.
335 The component ATE_DPT.2 has the following dependencies: ADV_ARC.1, ADV_TDS.3
and ADV_FUN.1. All of these are met or exceeded in the EAL4 assurance package.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 88/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
7 TOE Summary Specification
336 This section presents an overview of the security functionalities implemented by the TOE
and the assurance measures applied to ensure their correct implementation.
337 According to the SFRs the TOE provides the following functionalities
• Key Management
• Data Encryption
• Hybrid Encryption with User Data Authentication
• Data Integrity Mechanisms
• Authentication and Attestation of the TOE, Trusted Channel
• User Identification and Authentication
• Access Control
• Security Management
• Security Audit
• Protection of the TSF
• Import and Verification of Update Code Package
338 According to the Protection Profiles [CSPPP] and [CSPMOD] all security function are
supported by the coordinated and matching SFRs. In the following the SFRs are associ-
ated to security functions implemented by the TOE.
7.1 Key Management
339 The TSFRs FDP_ACC.1/KM, FMT_MSA.1/KM, FMT_MSA.3/KM and FMT_MTD.1/KM
require the TOE to implement several management functions on/with the cryptographic
keys and enforce the access control security functional policies of subject on the objects
(cryptographic keys). The TOE implements the functionality via the Export Key, Import
Key and key management commands.
340 The TOE implements the cryptographic algorithm SHA-256, SHA-384, SHA-512
(FCS_COP.1/Hash). The hash function is a cryptographic primitive used for HMAC, cf.
FCS_COP.1/HMAC, digital signature creation, cf. FCS_COP.1/CDS-*, digital signature
verification, cf. FCS_COP.1/VDS-*, and key derivation, cf. FCS_CKM.5. Additionally the
Hash-function is directly usable via the PSO:Hash – command.
341 The root key of a public key infrastructure (PKI)s imported via a link certificate using the
Verify Certificate command. While verifying the command assures the requirements of
FPT_TIT.1/Cert, FPT_ISA.1/Cert and FPT_TDC.1/Cert.
342 The TOE provides a hybrid deterministic random number generator of class PTG.3 and
PTG.2 according to [AIS31] (FCS_RNG.1).
343 The TOE implements cryptographic checksum functions, including hash functions used
for signature verification and key generation and derivation and message authentication
codes (MACs) addressed by FCS_COP.1.
344 The TOE provides the symmetric encryption algorithm AES with standardized key
lengths of 128 and 256 bits (FCS_COP.1).
Security Target TCOS CSP Module Version 2.0 Release 1/P71 89/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
345 The TOE implements asymmetric crypto algorithms used for encryption/decryption, key
agreement and digital signatures based elliptic curves.
346 Cryptographic functions are necessary for different security protocols implemented by
the TOE, e.g. PACE, Chip and Terminal Authentication, key derivation or the Update
procedure.
347 Cryptographic keys are explicitly deleted by overwriting the memory data with zeros or
random numbers, e.g. the new key according to FCS_CKM.6355.
348 SFRs supporting cryptographic functions are listed below:
• FCS_RNG.1
• FCS_CKM.1/AES
• FCS_CKM.5/AES
• FCS_CKM.1/ECC
• FCS_CKM.5/ECC
• FCS_CKM.1/RSA
• FCS_CKM.5/ECDHE
• FCS_CKM.1/ECKA-EG
• FCS_CKM.5/ECKA-EG
• FCS_CKM.1/AES_RSA
• FCS_CKM.5/AES_RSA
• FCS_CKM.6356
349 The TOE implements function to securely export and import cryptographic keys keeping
integrity, authenticity and confidentiality. Exported key (via Export Key – command) can
only be imported by the TOE sample which has exported the key because every sample
maintains its own key-wrap key.
350 SFRs supporting export/import are listed below:
• FCS_COP.1/KW
• FCS_COP.1/KU
• FPT_TCT.1/CK
• FPT_TIT.1/CK
• FPT_ISA.1/CK
• FPT_TDC.1/CK
• FPT_ESA.1/CK
355 Changed to FCS_CKM.6 because of migration to CC:2022
356 Changed to FCS_CKM.6 because of migration to CC:2022
Security Target TCOS CSP Module Version 2.0 Release 1/P71 90/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
7.2 Data Encryption
351 The TOE provides the symmetric encryption algorithm AES with standardized key
lengths of 128 and 256 bits (FCS_COP.1/ED). The functionality is available via a self-
contained command PSO:Encipher/Decipher.
7.3 Hybrid Encryption with MAC for User Data
352 The TOE provides hybrid data encryption/decryption and MAC calculation/verification of
user data as required in AES FCS_COP.1/HEM and FCS_COP.1/HDM. The functionality is
available over the TSFI PSO:Encipher and PSO:Decipher.
7.4 Data Integrity Mechanisms
353 The TOE implements cryptographic checksum functions, including hash functions used
for message authentication codes (MACs) addressed by FCS_COP.1/MAC and
FCS_COP.1/HMAC. The functionality is available via the TSFI PSO:Verify Cryptographic
Checksum and PSO:Compute Cryptographic Checksum.
354 Digital signature generation and verifications as required by FCS_COP.1/CDS-ECDSA,
FCS_COP.1/VDS-ECDSA, FCS_COP.1/CDS-RSA, FCS_COP.1/VDS-RSA,
FDP_DAU.2/Sig and FDP_DAU.2/TS is implemented by the TOE and reachable via the
commands PSO:Compute Digital Signature and PSO:Verify Digital Signature.
7.5 Authentication and Attestation of the TOE, Trusted Channel
355 The secure data exchange in a trusted channel is required by FTP_ITC.1. It is supported
by cryptographic operations. The TOE enforces a protected communication by means of
the PACE or Chip Authentication protocol. The trusted channel supports confidential in-
formation exchange which integrity is assured.
356 The randomness of the parameters of the PACE protocol is guaranteed by the RNG
class PTG.3 (FCS_RNG).
357 The strength of algorithms for ensuring confidentiality and integrity is supplied by
FCS_COP.1.
358 The TOE supports attestation to ensure that the sample is a genuine sample of the certi-
fied product via the command Compute Attestation.
359 The SFRs supporting Authentication and Attestation are listed below:
• FIA_API.1/PACE
• FIA_API.1/CA
• FDP_DAU.2/Att
• FTP_ITC.1
• FCS_CKM.1/PACE
• FCS_CKM.1/TCAP
• FCS_COP.1/TCE
Security Target TCOS CSP Module Version 2.0 Release 1/P71 91/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
• FCS_COP.1/TCM
7.6 User Identification and Authentication
360 The protocols for identification and authentication of users and devices are described in
the TCOS Guidance [TCOSGD]. The roles assigned after successful authentication are
listed in FMT_SMR.1 and its iterations.
361 The security and the reliability of the identification and authentication are supported by
the correct key agreement (FIA_UAU.1, FIA_UAU.5 and FIA_UAU.6) and the quality of
random numbers (FCS_RNG.1). As soon the authentication state is left, the session
keys cannot be used anymore (FCS_CKM.6).
362 User is authenticated with means of PACE passwords and PINs represented on the
TOE by ADRs, which are bound by corresponding failure or usage counters
(FIA_AFL.1). A Terminal is authenticated by using a correct key derived from the provid-
ed certificate and the authentication context.
363 Before a user or device is identified only dedicated commands can be executed. This is
supported by the iterated SFRs FIA_UID.1.
364 The SFRs supporting identification and authentication are listed below:
• FIA_ATD.1
• FMT_MTD.1/RAD
• FMT_MTD.3
• FIA_USB.1
• FMT_SAE.1
• FIA_UID.1
• FIA_UAU.1
• FIA_UAU.5
• FIA_UAU.6
7.7 Security Management
365 The TOE supports the management of security functions and its behavior. Password can
be changed and modified via Change Reference Data and Reset Retry Counter com-
mand. Cryptographic keys are managed by using the command Manage Key.
366 The internal clock can be adjusted via the command ManageTime. The behavior of the
audit functions can be changed using the command Manage Audit Functions.
367 The SFRs supporting security management are listed below:
• FMT_SMF.1
• FMT_SMR.1
• FMT_MSA.2
• FMT_MOF.1
Security Target TCOS CSP Module Version 2.0 Release 1/P71 92/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
• FMT_SMF.1/TSA
• FMT_SMR.1/TSA
• FMT_MOF.1/TSA
7.8 Access Control
368 The access to User Data is restricted according to the different iterations of the SFRs
FDP_ACC.1 and FDP_ACF.1.
369 The access to the TOE security functions and the TSF data is controlled by the function-
ality of the class FMT.
370 User data are imported as required by FDP_ITC.2/UD via the command
PSO:Encipher/Decipher and PSO:CDS respective PSO:VDS.
371 User data are exported as required by FDP_ETC.1 and FDP_ETC.2 via the command
PSO:Encipher/Decipher and PSO:CDS respective PSO:VDS.
372 The SFRs supporting identification and authentication are listed below:
• FDP_ITC.2/UD
• FDP_ITC.2/TS
• FDP_ETC.2
• FDP_ETC.2/TS
• FDP_ETC.1
• FDP_ACC.1/Oper
• FDP_ACF.1/Oper
• FDP_ACF.1/TS
7.9 Security Audit
373 The TOE supports audit data generation on occurrence of several auditable events.
Event data are stored in an audit trail and can be exported later via the command
GetAuditData. Exported audit trails are digitally signed. Therefore modification, deletion,
insertion and replay can be easily determined. Events can be activated and deactivated
by using the command ManageAuditFunctions.
374 The SFRs supporting identification and authentication are listed below:
• FAU_GEN.1
• FMT_MTD.1/Audit
• FAU_STG.1
• FAU_STG.3
• FPT_STM.1
• FPT_TIT.1/Audit
Security Target TCOS CSP Module Version 2.0 Release 1/P71 93/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
7.10Protection of the TSF
375 According to the SFRs FDP_ACC.1 and FDP_ACF.1 and their iterations the access to
cryptographic keys is restricted by defined rules laid down in the certified object system.
The details can be found in the corresponding SFPs. Note that the TOE enforces these
access rules based on roles taken by authentication against the corresponding ADR, but
there is no a priori protection of a said object. Some of the roles can also be taken by
verifying certificates followed by authentication to the corresponding imported public key
ADR. The TOE is able to interpret these certificates accordingly.
376 Data stored on the TOE is protected by FDP_SDC.1, FCS_COP.1/SDE and
FCS_CKM.1/SDEK which is implemented by using the hardware features of the chip.
377 Residual information of sensitive data in previously used resources will not be available
after its usage (FDP_RIP.1/UCP). Session keys and message authentication keys will
be destroyed after reset or termination of the secure messaging channel
(FCS_CKM.6357). The TOE hides the correlation of power or timing variations and the
command execution accessing sensitive user data as different keys and passwords
(FPT_EMS.1). In case of a malfunction, operating errors or integrity check failures the
TOE enters a secure state (FPT_FLS.1). This is supported by the functional services of
the hardware.
378 The TOE executes self-tests (FPT_TST.1) to demonstrate the correct operation of the
TSF and its confidentiality protection capabilities. In case of failures, FPT_FLS.1 re-
quires the preservation of a secure state in order to protect the user data, TSF data and
security services. FRU_FLT.2 ensures the operation of all the TOE’s capabilities when
an exposure to operating conditions which are not detected according to the previous
requirement occurs.
379 The SFRs supporting protection of the TOE are listed below:
• FDP_DAU.2/Sig
• FMT_MSA.1/KM
• FMT_MSA.2
• FMT_MSA.3/KM
• FMT_MTD.1/KM
• FMT_MTD.1/RAD
• FMT_MTD.1/RK
• FMT_MTD.3
7.11Import and Verification of Update Code Package
380 The TSFR in this group require the functionality to load update code packages in the
TOE in operational phase. The TOE implements this via the commands Application
Management Request and Load Application.
381 The SFRs supporting Import and Verification of Update Code Package are listed below:
• FDP_ITC.2/UCP
357 Changed to FCS_CKM.6 because of migration to CC:2022
Security Target TCOS CSP Module Version 2.0 Release 1/P71 94/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
• FPT_TDC.1/UCP
• FCS_COP.1/VDSUCP
• FCS_COP.1/DecUCP
• FDP_ACC.1/UCP
• FDP_ACF.1/UCP
• FDP_RIP.1/UCP
7.12Statement of Compatibility
382 This is the statement of compatibility between this Composite Security Target and the
Security Target Chip of the underlying hardware [HWST].
7.12.1 Relevance of Hardware TSFs
383 In the following lists the relevance of the hardware security functionality (SF) for the
composite security target is considered. All are relevant:
• TSF.Service: Service functionality beside cryptographic operations
• TSF.Protection: General security measures to protect the TSF
• TSF.Control: Operating conditions, memory and hardware access control
• TSF.Crypto: Crypto Service
7.12.2 Security Requirements
Security Functional Requirements
384 The relevant Security Requirements of the TOE and the hardware can be mapped or are
not relevant. They show no conflict between each other.
Security Requirements of the TOE related to the Composite ST:
385 The Security Requirements of the TOE of the classes FAU, FCS, FIA, FDP, FMT and
FTP are specific for the Operating System and have no conflicts with the underlying
hardware.
386 The Security Requirements of the TOE of the classes FPT, FRU are supported by the
Security Feature SF.PHY and SF.OPC of the hardware ([HWST]). The requirements
FPT_FLS and FPT_PHP are also not conflicting with the requirements for the hardware.
They support each other. The requirements for test (FPT_TST) in the operating system
are supported by various tests of the hardware (FPT_TST [HWST]), and there are no
conflicts with the underlying hardware.
Security Requirements of the hardware
387 The Security Requirements of the TOE’s hardware based on PP-0084 [ICPP, sec.6.1]
can be mapped to Security Requirements of the TOE. They show no conflict between
each other.
SFR of the hardware Relevance SFR of the TOE using it or
meaning
Security Target TCOS CSP Module Version 2.0 Release 1/P71 95/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
SFR of the hardware Relevance SFR of the TOE using it or
meaning
FAU_SAS.1 IR
FDP_IFC.1 ReP concerns information flow policy between parts of
the hardware
FDP_SDC.1 ReP concerns low level stored data protection (confi-
dentiality)
FDP_SDI.1 ReP concerns low level stored data protection (integri-
ty)
FDP_ITT.1 ReP concerns basic internal transfer protection of the
hardware
FMT_LIM.1 IR concerns limited capabilities and availability of
Deploying Test Features of the hardware
FMT_LIM.1/Loader IR
FMT_LIM.2 IR
FMT_LIM.2/Loader IR
FPT_FLS.1 Re FPT_FLS.1
FRU_FLT.2 Re FRU_FLT.2
FPT_ITT.1 ReP concerns basic hardware internal TSF data trans-
fer protection
FPT_PHP.3 Re FPT_PHP.3
FCS_CKM.1/PUF,
FCS_CKM.4/PUF,
FCS_COP.1/AES_PUF,
FCS_COP.1/MAC_PUF
ReP concerns internal data protection and therefore
does not conflict with key generation in this ST
FPT_TST.1 Re FPT_TST.1
FCS_COP.1/AES Re FCS_COP.1/ED, FCS_COP.1/HEM,
FCS_COP.1/HDM, FCS_COP.1/MAC
Note that the hardware itself only supports AES
in ECB-Mode. The CMAC is implemented by the
software using the ECB-Mode of the hardware as
base and using the symmetric coprocessor for
computing the Xor-operations. The hardware
supports Xor-operation of two data-blocks to
support chaining-modes which is used here.
FCS_CKM.4/TDES IR TDES is not used
FCS_COP.1/TDES IR TDES is not used
FCS_RNG.1/PTG.2 Re FCS_RNG.1
FDP_ACC.1/ACP Re FDP_ACC.1 and its iterations of the Composite
TOE.
FDP_ACF.1/ACP Re FDP_ACF.1 and its iterations
Security Target TCOS CSP Module Version 2.0 Release 1/P71 96/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
SFR of the hardware Relevance SFR of the TOE using it or
meaning
FDP_SDI.2 ReP concerns low level stored data protection and
monitoring and does not conflict with the re-
quirements of this ST
FMT_MSA.1/ACP ReP concerns the management of security attributes
on hardware’s level, does not conflict with the
SFRs of the TOE
FMT_MSA.3/ACP ReP concerns the management of security attributes
on hardware’s level, does not conflict with the
SFRs of the TOE
FMT_SMF.1 ReP concerns the access of the configuration regis-
ters of the Memory Management Unit, does not
conflict with the SFRs of the TOE
FCS_CKM.4/AES ReP concerns the internal destruction of the key in the
AES coprocessor. It does not conflict with the
SFRs of the TOE.
FTP_ITC.1/Loader
FDP_UCT.1/Loader,
FDP_UIT.1/Loader,
FDP_ACC.1/Loader,
FDP_ACF.1/Loader
IR Not relevant because the Loader is blocked after
TOE delivery
FCS_COP.1/TDES_LIB,
FCS_COP.1/AES_LIB,
FCS_CKM.4/TDES_LIB,
FCS_CKM.4/AES_LIB,
FCS_RNG.1/DRG.4
FCS_RNG.1/PTG.3,
FCS_COP.1/RSA,
FCS_CKM.5/
RSA_PubkeyDerivation,
FCS_CKM.1/
RSA_KeyGen,
FCS_CKM.4/RSA,
FCS_COP.1/ECDSA,
FCS_COP.1/ECC_DHKE,
FCS_CKM.1/
ECC_KeyGen,
FCS_CKM.4/ECC,
FCS_COP.1/SHA
IR All SFRs from the hardware ST related to the
crypto library of the hardware are not mapped
because the library is not used in the presented
TOE.
388 IR means: Irrelevant Platform-SFRs not being used by the Composite-ST.
389 Re means: Relevant Platform-SFRs being used by the Composite-ST to implement a
security service with associated TSFI.
390 ReP means: Relevant Platform-SFRs being used by the Composite-ST because of its
security properties providing protection against attacks to the TOE as a whole.
Security Assurance Requirements
Security Target TCOS CSP Module Version 2.0 Release 1/P71 97/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
391 The level of assurance of the TOE is EAL 4 augmented with ALC_DVS.2, ALC_FLR.1,
ATE_DPT.2 and AVA_VAN.5.
392 The chosen level of assurance of the hardware is EAL 6 augmented with ALC_FLR.1
and ASE_TSS.2. This includes ALC_DVS.2, ATE_DPT.3 and AVA_VAN.5.
393 This shows that the Assurance Requirements of the TOE matches the Assurance Re-
quirements of the hardware.
7.12.3 Security Objectives
394 The Security Objectives of the TOE and the hardware can be mapped or are not rele-
vant. They show no conflict between each other.
395 The following Security Objectives of the TOE are related to the Composite ST and are
not relevant for the hardware:
• O.AccCtrl
• O.AuthentTOE
• O.DataAuth
• O.SecMan
• O.SecUpCP
• O.TChann
• O.Audit
• O.TimeService
396 Security Objectives of the TOE related to the Composite ST, that can be mapped to Ob-
jectives of the hardware:
• O.PhysProt
• O.RBGS
• O.TST
• O.Enc
• O.I&A
397 The following Security Objectives of the Hardware are covered by objectives of the TOE
• O.Leak-Forced, O.Leak-Inherent and O.PUF contribute to O.PhysProt
• O.Abuse-Func, O.Phys-Probing, O.Malfunction, O.Phys-Manipulation contribute to
O.TST
• O.RND contribute to O.RBGS
• O.AES is covered by O.Enc
• O.Identification contribute to O.I&A
398 The objective O.TDES is not relevant because the TOE does not use TDES.
399 The remaining objectives of the hardware concern the internal processing of the hard-
ware and are not related to specific objectives of the TOE. They do not conflict to each
other:
• O.NVM-Integrity
• O.Access-Control
• O.Self-Test
Security Target TCOS CSP Module Version 2.0 Release 1/P71 98/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
• O.RSA, O.ECC both not relevant as the crypto library of the hardware is not used
400 The Security Objectives for the Environment of the TOE are related to the life cycle
phase “Operational Use” and do not conflict with the Security Objectives for the hard-
ware which are related to the manufacturing process. Therefore, they do not conflict to
each other.
401 Security Objective for the environment of TOE’s hardware:
• OE.Resp-Appl
• OE.Process-Sec-IC
• OE.Lim_Block_Loader
• OE.Loader_Usage
• OE.Check-Init
402 Security Objective for the environment of composite TOE:
• OE.CommInf
• OE.AppComp
• OE.SecComm
• OE.SUCP
• OE.Audit
• OE.TimeSource
7.12.4 Conclusion
403 No contradictions between the Security Targets of the TOE and the underlying hardware
can be found.
7.13Assurance Measures
404 The documentation is produced compliant to the Common Criteria Version CC:2022.
The following documents provide the necessary information to fulfil the assurance re-
quirements listed in section 6.2 Security Assurance Requirements for the TOE.
Development
ADV_ARC.1 Security Architecture Description TCOS CSP 1.0 Release 1
ADV_FSP.4 Functional Specification TCOS CSP 1.0 Release 1
ADV_IMP.1 Implementation of the TSF TCOS CSP 1.0 Release 1
ADV_TDS.3 Modular Design of TCOS CSP 2.0 Release 1
Guidance documents
AGD_OPE.1 User Guidance TCOS CSP 2.0 Release 1
AGD_PRE.1 Administrator Guidance TCOS CSP 2.0 Release 1
Life-cycle support
ALC_CMC.4, ALC_CMS.4
Documentation for Configuration Management
ALC_DEL.1 Documentation for Delivery and Operation
ALC_LCD.1 Life Cycle Model Documentation TCOS CSP 2.0 Release 1
ALC_FLR.1 Documentation of Flaw Remediation Procedures
ALC_TAT.1, ALC_DVS.2
Development Tools and Development Security for TCOS CSP 2.0
Release 1
Security Target TCOS CSP Module Version 2.0 Release 1/P71 99/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Tests
ATE_COV.2, ATE_DPT.2 Test Documentation for TCOS CSP 2.0 Release 1
ATE_FUN.1 Test Documentation of the Functional Testing
Vulnerability assessment
AVA_VAN.5 Independent Vulnerability Analysis TCOS CSP 2.0 Release 1
405 The developer team uses a configuration management system that supports the genera-
tion of the TOE. The configuration management system is well documented and identi-
fies all different configuration items. The configuration management tracks the imple-
mentation representation, design documentation, test documentation, user documen-
tation, administrator documentation, and security flaws. The security of the configuration
management is described in detail in a separate document.
406 The delivery process of the TOE is well defined and follows strict procedures. Several
measures prevent the modification of the TOE based on the developer’s master copy
and the user’s version. The Administrator and the User are provided with necessary
documentation for installation, personalization and start-up of the TOE.
407 The implementation is based on an informal high-level and low-level design of the com-
ponents of the TOE. The description is sufficient to generate the TOE without other de-
sign requirements.
408 The tools used in the development environment are appropriate to protect the confiden-
tiality and integrity of the TOE design and implementation. The development is controlled
by a life-cycle model of the TOE. The development tools are well-defined and use semi-
formal methods, i.e. a security model.
409 The development department is equipped with organizational and personnel means that
are necessary to develop the TOE. The testing and the vulnerability analysis require
technical and theoretical know-how available at Deutsche Telekom Security GmbH.
410 As the evaluation is identified as a composite evaluation based on the CC evaluation of
the hardware, the assurance measures related to the hardware (IC) will be provided by
documents of the IC manufacturer.
Security Target TCOS CSP Module Version 2.0 Release 1/P71 100/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Appendix: Keywords and Abbreviations
411 The terminology and abbreviations of Common Criteria version 3.1 [CC], Revision 5
apply to this ST. The following table is taken over from the PP [CSPPP]
Term Description
authentication reference
data
data used by the TOE to verify the authentication attempt of a user
authentication verification
data
data used by the user to authenticate themselves to the TOE
authenticity the property that ensures that the identity of a subject or resource is the one
claimed (cf. ISO/IEC 7498-2:1989)
cluster a system of TOE samples initialized by an administrator and communication
through trusted channels in order to manage known users and to share the
cryptographic keys
cryptographic key a variable parameter which is used in a cryptographic algorithm or protocol
data integrity the property that data has not been altered or destroyed in an unauthorized
manner (cf. ISO/IEC 7498-2:1989)
firmware executable code that is stored in hardware and cannot be dynamically written
or modified during execution while operating on a non-modifiable or limited
execution platform, cf. ISO/IEC 19790
hardware physical equipment or comprises the physical components used to process
programs and data or to protect physically the processing components, cf.
ISO/IEC 19790
Issuer of update code
package
Trusted authority issuing an update code package (UCP) and holding the sig-
nature private key for signing the UCP and corresponding to the public key
implemented in the TOE for verification of the UCP. The issuer is typically the
TOE manufacturer. The issuer of an UCP is identified by the security attribute
Issuer of the UCP.
private key confidential key used for asymmetric cryptographic mechanisms like decryption
of cipher text, signature-creation or authentication proof, where it is difficult for
the adversary to derive the confidential private key from the known public key
public key public known used for asymmetric cryptographic mechanisms like encryption of
cipher text, signature-verification or authentication verification, where it is diffi-
cult for the adversary to derive the confidential private key from the known
public key
secret key key of symmetric cryptographic mechanisms, using two identical keys with the
same secret value or two different values, where one may be easy calculated
from the other one, for complementary operations like encryption / decryption,
signature-creation / signature-verification, or authentication proof / authentica-
tion verification.
secure channel a trusted channel which is physically protected and logical separated commu-
nication channel between the TOE and the user, or is protected by means of
cryptographic mechanisms
software executable code that is stored on erasable media which can be dynamically
written and modified during execution while operating on a modifiable execu-
tion platform, cf. ISO/IEC 19790
trusted channel a means by which a TSF and another trusted IT product can communicate with
necessary confidence (cf. CC part 1 [1], paragraph 97)
update code package code if implemented changing the TOE implementation at the end of the TOE
life time
Security Target TCOS CSP Module Version 2.0 Release 1/P71 101/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
Acronym Term
A.xxx Assumption
CC Common Criteria
CSP Cryptographic Service Provider
ECC Elliptic curve cryptography
HMAC Keyed-Hash Message Authentication Code
KDF Key derivation function
MAC Message Authentication Code
n. a. not applicable
O.xxx Security objective for the TOE
OE.xxx Security objective for the TOE environment
OSP.xxx Organizational security policy
PACE Password Authenticated Connection Establishment
PKI Public Key Infrastructure
PP Protection Profile
SAR Security Assurance Requirements
SFR Security Functional Requirement
T.xxx Threat
TOE Target of Evaluation
TSF TOE Security Functionality
UCP Update Code Package
Security Target TCOS CSP Module Version 2.0 Release 1/P71 102/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
References
[AIS31]
Bundesamt für Sicherheit in der Informationstechnik, Anwendungshinweise und Interpre-
tationen zum Schema (AIS), AIS 31, A proposal for Functionality classes for random num-
ber generators Version 2.0 vom 18.09.2011, Bundesamt für Sicherheit in der Informati-
onstechnik (BSI)
[AIS36]
Bundesamt für Sicherheit in der Informationstechnik, Anwendungshinweise und Interpre-
tationen zum Schema (AIS), AIS 36, Version 5 vom 15.03.2017, Bundesamt für Sicherheit
in der Informationstechnik (BSI)
[ANSX9.63]
American National Standard X9.63-2001, Public Key Cryptography for the Financial Ser-
vices Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography,
2005-11
[CC]
Common Criteria Version CC:2022 Release 1,
• Part 1: Introduction and general model
• Part 2: Security functional components
• Part 3: Security assurance components
• Part 4: Framework for the specification of evaluation methods and activities
• Part 5: Pre-defined packages of security requirements
• Common Methodology for Information Technology Security Evaluation, Evaluation
methodology, November 2022 CEM:2022 Revision 1, CCMB-2022-11-006
• Errata and Interpretation for CC:2022 (Release 1) and CEM:2022 (Release 1) Ver-
sion 1.1, 2024-07-22
[EACTR]
Technical Guideline TR-03110: Advanced Security Mechanisms for Machine Readable
Travel Documents,
Part 1 – eMRTDs with BAC/PACEv2 and EACv1, Version 2.20, 2015-02
Part 2 – Protocols for electronic IDentification, Authentication and trust Services (eIDAS),
Version 2.21, 2016 -12
Part 3 – Common Specifications, Version 2.21, Bundesamt für Sicherheit in der Informati-
onstechnik (BSI), 2016-12
[ECCTR]
Technical Guideline TR-03111: Elliptic Curve Cryptography, Version 2.10, Bundesamt für
Sicherheit in der Informationstechnik (BSI), 2018-06
[SE API]
Technical Guideline TR-03151: Secure Element API (SE API)
• Part 1: Interface Definition, Version 1.1.1 2024-01-08
• Part 2: Interface Mapping, Version 1.1.0 2023-02-13
Security Target TCOS CSP Module Version 2.0 Release 1/P71 103/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
[FIPS180]
Federal Information Processing Standards Publication FIPS PUB 180-4, Secure Hash
Standard (SHS), 2015-08
[FIDO]
FIDO Alliance Proposed Standard FIDO ECDAA Algorithm, FIDO Alliance, 2017-04
[FIPS186]
Federal Information Processing Standards Publication FIPS PUB 186-4, Digital Signature
Standard (DSS), 2013-07
[FIPS197]
Federal Information Processing Standards Publication 197, Advanced Encryption Stan-
dard (AES), U.S. Department of Commerce/National Institute of Standards and Techno-
logy, 2001-11-26
[ISO18033-3]
ISO/IEC 18033-3:2010 Information technology – Security techniques – Encryption algo-
rithms – Part 3: Block ciphers, ISO, 2010-12
[HWCR]
Certification Report of the underlying hardware platform BSI-DSZ-CC-1149-V4-2025 for
NXP Smart Card Controller N7122 with IC Dedicated Software and Crypto Library
(R1/R2/R3) from NXP Semiconductors Germany GmbH
[HWST]
Security Target of the underlying hardware platform, NXP Secure Smart Card Controller
N7122 with IC Dedicated Software and Crypto Library (R1/R2/R3), Security Target lite
Rev. 2.0 – 4 August 2025, BSI-DSZ-CC-1149
[DSheet_WaferSpec]
NXP Secure Smart Card Controller N7122 – Wafer and delivery specification, Product
datasheet addendum.
[ICAO9303]
ICAO Doc 9303, Machine Readable Travel Documents, Eigth Edition, 2021
[ISO7816]
ISO 7816-4:2013, Identification cards – Integrated circuit cards with contacts, Part 4: Or-
ganization, security and commands for interchange, ISO, 2013-04
[ISO9796-2]
ISO/IEC 9796-2:2010 Information technology – Security techniques – Digital signature
schemes giving message recovery – Part 2: Integer factorization-based mechanisms,
ISO, 2010-12
[ISO9797-1]
ISO/IEC 9797-1:1999, Information technology – Security techniques – Message Authenti-
cation Codes (MACs) – Part 1: Mechanisms using a block cipher, ISO, 2005-01-04
[ISO9797-2]
ISO/IEC 9797-2:2011, Information technology – Security techniques – Message Authenti-
cation Codes (MACs) – Part 2: Mechanisms using a dedicated hash-function, ISO, 2011-
05
Security Target TCOS CSP Module Version 2.0 Release 1/P71 104/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
[ISO10116]
ISO/IEC 10116:2017, Information technology – Security techniques – Modes of operation
for an n-bit block cipher, 2017-07
[ISO14888-2]
ISO/IEC 14888-2:2008, Information technology – Security techniques – Digital signatures
with appendix – Part 2: Integer factorization-based mechanisms, ISO, 2008-04
[CSPPP]
CC Protection Profile Cryptographic Service Provider, Version 0.9.8, Registered and Cer-
tified by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC-PP-0104-
2019, 2019-02
[CSPMOD]
Protection Profile-Module CSP Time Stamp Service and Audit (PPM-TS-Au), Version
0.9.5, Registered and Certified by Bundesamt für Sicherheit in der Informationstechnik
under BSI-CC-PP-0107-2019, 2019-05
[JIL]
CC Joint Interpretation Library, Guidance for smartcard evaluation, Version 3.0, 2024-04
[ICPP]
Security IC Platform Protection Profile with Augmentation Packages Version 1.0, Regis-
tered and Certified by Bundesamt für Sicherheit in der Informationstechnik under BSI-CC-
PP-0084-2014, 2014-01
[RFC2104]
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authenti-
cation", RFC 2104, IETF, 1997-02
[RFC5639]
M. Lochter, J. Merkle, Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and
Curve Generation, RFC 5639, IETF, 2010-03
[RFC5903]
D. Fu, J. Solinas, Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2,
RFC 5903, IETF, 2010-06
[RFC6954]
M. Lochter, J. Merkle, Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for
the Internet Key Exchange Protocol Version 2 (IKEv2), RFC 6954, IETF, 2013-07
[RFC8017]
K. Moriarty, B. Kaliski, J. Jonsson, A. Rusch, PKCS #1: RSA Cryptography Specifications
Version 2.2, RFC 8017, IETF, 2016-11
[SP800-38A]
Recommendation for Block Cipher Modes of Operation: Methods and Techniques, NIST
Special Publication 800-38A, National Institute of Standards and Technology, 2001-12
[SP800-38B]
Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentica-
tion, NIST Special Publication 800-38B, National Institute of Standards and Technology,
2005-05
Security Target TCOS CSP Module Version 2.0 Release 1/P71 105/105
Specification of the Security Target TCOS CSP Module Version 2.0 Release 1
Version: 2.0.1 Date: 2025-09-25
Deutsche Telekom Security GmbH, 2025
[SP800-38D]
Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and
GMAC, NIST Special Publication 800-38D, National Institute of Standards and Technolo-
gy, 2007-11
[SP800-56C]
Recommendation for Key-Derivation Methods in Key-Establishment Schemes Rev.1,
NIST Special Publication 800-56C, National Institute of Standards and Technology, 2018-
04
[TPM]
Trusted Platform Module Library, Part 1: Architecture, Family “2.0”, Level 00 Revision
01.38, TCG, 2016-09
[SP800-38F]
Recommendation for Block Cipher Modes of Operation: Methods for Key Wrapping, NIST
Special Publication 800-38F, National Institute of Standards and Technology, 2012-12
[SP800-67]
Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, NIST
Special Publication 800-67, Revised January 2012, National Institute of Standards and
Technology, 2012-01
[TCOSGD]
TCOS CSP Module 2.0, User's Guidance, Deutsche Telekom Security GmbH, Version
2.0.1, 2025-09
[TR-02102-1]
Technische Richtlinie TR-02102-1 Kryptographische Verfahren Empfehlungen und
Schlüssellängen, Version 2025-01, Bundesamt für Sicherheit in der Informationstechnik
(BSI), 2025-01-31
[BIP32]
Bitcoin Improvement Proposal number 32: “Hierarchical Deterministic Wallets”, 11. Febru-
ary 2012
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
[NIST SP 800-108]
NIST Special Publication 800-108: “Recommendation for Key Derivation Using Pseu-
dorandom Functions”, October 2009
[SEC2]
Standards for Efficient Cryptography, SEC 2: Recommended Elliptic Curve Domain Pa-
rameters, Certicom Research, January 27, 2010, Version 2.0