CryptoServerCP5 ST Lite
CryptoServerCP5 ST Lite
CryptoServerCP5 ST Lite
Table of Contents
1 Introduction ....................................................................................................................... 5
1.1 Change History .............................................................................................................. 5
1.2 Document Introduction.................................................................................................... 5
1.2.1 Acknowledgement ..................................................................................................... 5
1.2.2 Notations ................................................................................................................ 5
1.2.3 Abbreviations ........................................................................................................... 6
1.2.4 References .............................................................................................................. 6
1.2.5 Terminology ............................................................................................................. 7
2 Security Target Introduction .................................................................................................. 8
2.1 ST and TOE Reference..................................................................................................... 8
2.2 Related Documents ........................................................................................................ 8
2.3 Organisation ................................................................................................................. 8
2.4 TOE Overview ................................................................................................................ 9
2.5 TOE Description ........................................................................................................... 12
2.5.1 TOE Configuration and TOE Environment ...................................................................... 12
2.5.2 TOE Boundary ........................................................................................................ 18
2.6 Required Non-TOE Hardware/Software/Firmware ............................................................... 21
3 Conformance Claims .......................................................................................................... 23
3.1 CC Conformance Claim .................................................................................................. 23
3.2 PP Claim .................................................................................................................... 23
3.3 Package Claim............................................................................................................. 23
3.4 Conformance Rationale ................................................................................................. 23
4 Security Problem Definition ................................................................................................. 24
4.1 Assets ....................................................................................................................... 24
4.2 Subjects ..................................................................................................................... 24
4.3 Threats ...................................................................................................................... 25
4.4 Organisational Security Policies ...................................................................................... 26
4.5 Assumptions ............................................................................................................... 27
5 Security Objectives ............................................................................................................ 29
5.1 Security Objectives for the TOE ....................................................................................... 29
5.2 Security Objectives for the Operational Environment ............................................................ 32
6 Extended Components Definition .......................................................................................... 35
6.1 Generation of Random Numbers (FCS_RNG) ...................................................................... 35
6.2 Basic TSF Self Testing (FPT_TST_EXT.1) ........................................................................... 35
7 Security Requirements ....................................................................................................... 37
7.1 Typographical Conventions ............................................................................................ 37
7.2 SFR Architecture .......................................................................................................... 37
Page 3 of 126
Table of Contents
Page 4 of 126
Introduction
1 Introduction
1.9.5 13th November 2018 First release of Security Target Lite for CryptoServer CP5
5.1.0.0, based on full Security Target with same version
2.0.0 23th November 2018 Release of Security Target Lite for CryptoServer CP5
5.1.0.0, based on full Security Target with same version
1.2.1 Acknowledgement
The author would like to acknowledge the significant contributions of the Protection Profile
[PP_CMTS] as well as [PP_CMTS_1.0].
1.2.2 Notations
The notation, formatting, and conventions used in this ST are consistent with those used in
the Common Criteria, Version 3.1, Revision 4, September 2012 [CC1], [CC2], [CC3].
The Common Criteria allow several operations to be performed on security requirements:
refinement, selection, assignment and iteration are defined in Section C.2 of [CC1].
Refinement: The refinement operation is used to add details to a requirement, and thus
further restricts a requirement.
1 Please note that the versions v0.15 and v1.0 of the Protection Profile only differ in formal and editorial
aspects, version v1.0 [PP_CMTS_1.0] being the sanitized version of v0.15 [PP_CMTS], which is the
one officially certified and listed on the Common Criteria portal as certified Protection Profile, see
https://www.commoncriteriaportal.org/. The two versions v1.0 and v0.15 do not differ in any of the
requirements, like Security Functional Requirements (SFRs), Security Assurance Requirements
(SARs) or Assumptions (A.<xxx>).
Page 5 of 126
Introduction
Selection: The selection operation occurs where a given component contains an element
where a choice from several items has to be made by the PP/ST author. Whenever an
element within a PP contains a selection, the PP author could leave the selection
uncompleted, restrict the selection by removing some of the choices (but leaving two or
more) or complete the selection by choosing one or more items. Whenever an element
within an ST contains a selection, the ST author has to complete that selection. If a
selection was already completed in the PP, the PP text is shown in non-underlined italic
letters. If a selection is completed by the ST author the text is shown in underlined
italicized letters.
Assignment: The assignment operation is used to assign a specific value to an
unspecified parameter (e.g. the length of a password). Whenever an element in a PP
contains an assignment, the PP author could leave the assignment uncompleted,
complete the assignment, narrow the assignment, to further limit the range of values that
is allowed or transform the assignment to a selection, thereby narrowing the assignment.
Whenever an element in an ST contains an assignment, the ST author has to complete
that assignment, the PP text is also given within a footnote where the original text is given.
If an assignment was already completed in the PP, the PP text is shown in non-underlined
italic letters. If an assignment is completed by the ST author the text is shown in
underlined italicized letters.
Iteration: The iteration operation is used when a component is repeated with varying
operations. Iterations within [PP_CMTS] are denoted by showing a slash “/” and an
iteration indicator after the CC component identifier. Iterations within the ST are denoted
by showing a double-slash “//” and an iteration indicator after the PP component and the
CC component, respectively, identifier.
1.2.3 Abbreviations
Assumptions, threats, organisational security policies and security objectives (for TOE and
environment) are assigned with a unique label for easy reference as follows:
T.<xxx> Threats
P.<xxx> Organisational security policies
A.<xxx> Assumptions about the TOE security environment
OT.<xxx> Security objectives for the TOE
OE.<xxx> Security objectives for the operating environment
1.2.4 References
References in this document are specified with the help of brackets (e.g.: [<Reference>]). A
list of all referenced documents can be found in chapter 10.2 “References”.
Page 6 of 126
Introduction
1.2.5 Terminology
A complete list of used terms and abbreviations can be found in chapter 10.1 “Glossary and
Acronyms”. Thereby Common Criteria and IT technology terms relevant for this ST are
described. Most of the definitions are taken out of the PP [PP_CMTS] as well as from the
Common Criteria.
Page 7 of 126
Security Target Introduction
2.3 Organisation
The main chapters of this ST are Security Target Introduction with the description of the TOE
(Target of Evaluation), Conformance claims, Security problem definition, Security objectives,
Extended components definition, Security requirements and TOE summary specification as
well as annexes. This document is structured according to the Security Target requirements
of [CC1].
Chapter 2: The TOE description provides general information about the TOE, its generic
structure and boundaries.
Page 8 of 126
Security Target Introduction
Page 9 of 126
Security Target Introduction
The CryptoServer can optionally also be used as a general purpose HSM. Thus, in addition
to Assigned keys, also General (non-Assigned) keys that have lower restrictions are
supported. General keys can for instance be exported or imported (in an encrypted way),
whereas key export or import is not allowed for Assigned keys.
In addition to its suitability as Qualified Signature Creation Device (QSCD) for local
signing/sealing and server signing in accordance with eIDAS Regulation [Regulation], the
CryptoServer can optionally also be used for implementing a QSCD for eIDAS-compliant
remote Server Signing in the sense of CEN Protection Profile EN 419 241-2, “Trustworthy
Systems Supporting Server Signing Part 2: Protection Profile for QSCD for Server Signing”,
[PP_QSCD]. In this case, the customer has to develop a Signature Activation Module (SAM)
module in the sense of [PP_QSCD] and certify it against this CEN Protection Profile EN 419
241-2, [PP_QSCD]. The SAM may be either implemented as so-called external SAM which
calls the CryptoServer’s external interface (PCIe, see below) for signature creation, and
which must be located within a physically protected environment and communicate with the
CryptoServer over a secure channel, or it may be implemented as so-called internal SAM in
form of one or more firmware modules which must be loaded into the CryptoServer CP5 and
run within its secure physical boundary. For signature creation, such internal SAM can use
the CryptoServer’s internal interface, see also Figure 6. Both architectures allow the SAM to
use the services of the TOE as a cryptographic module that is eIDAS-certified according to
CEN Protection Profile prEN 419 221-5 [PP_CMTS]. SAM and CryptoServer CP5 together
form a QSCD for remote Server Signing in the sense of CEN Protection Profile EN 419 241-2
[PP_QSCD].
An internal SAM can only be loaded into a CryptoServer CP5 if it is signed by Utimaco with a
dedicated CryptoServer CP5 Module Signature Key. Utimaco will only sign firmware modules
with this key if they belong to the TOE, or if the module is an internal SAM which is eIDAS-
certified according to [PP_QSCD], and if, as part of this eIDAS certification, it has been
validated that the SAM follows the CryptoServer CP5 User Guidance so that it doesn’t violate
the TOE Security Functionality.
All hardware components of the TOE, including the Central Processing Unit, all memory
chips, Real Time Clock, and hardware noise generator for random number generation, are
located on a printed circuit board (PCB). These hardware components are completely
Page 10 of 126
Security Target Introduction
covered with potting material (epoxy resin) and a heat sink. This hard, opaque enclosure
protects the sensitive CryptoServer hardware components from physical attacks. The
resistance of the TOE hardware and sensory to physical and chemical attacks has been
evaluated and successfully certified according to the requirements of FIPS 140-2 standard,
level 3. The protected security module PCB in form of a PCIe plug-in card is called PCIe
security module.
To enable communication of the cryptographic module with a host, the PCIe security module
offers a PCIe interface and two USB interfaces.
Before delivery the PCIe security module can be optionally integrated into a Utimaco
CryptoServer LAN appliance (see Figure 2 and Figure 3). The CryptoServer LAN exists in
two variants providing the same functionality but having a different height. Both are a 19-inch
network appliance with display, control buttons and USB interfaces on the front panel. They
contain an industry-quality PC motherboard, backplane with PCIe bus interface, flash disk
(as mass storage), two redundant power supplies and backup battery. The PCIe security
module is plugged into the PCIe bus interface of the backplane. The CryptoServer LAN may
be connected to an Ethernet network via a Gigabit network interface on the backside.
Page 11 of 126
Security Target Introduction
Page 12 of 126
Security Target Introduction
The PCIe security module provides the following interfaces (see Figure 4):
(1) PCIe interface which is used for operational power input, data input, data output,
control input and status output
(2) USB 2.0 port (can be used for receiving status output)
(3) USB 2.0 port (can be used for receiving status output)
(4) Erase pushbutton for performing External Erase
(5) LED flash light, flashes up red to indicate the activation of the Erase pushbutton
The module's cryptographic boundary consists of a physical boundary and a logical
boundary. The physical boundary is defined as the outer perimeter of the heat sink on the top
side and the epoxy surface on the bottom side of the module. Figure 5 below shows the
physical boundary from the side and the top. The red dashed line indicates the TOE’s
physical boundary.
Page 13 of 126
Security Target Introduction
The communication between the customer's application software and the cryptographic
module is supported by the PCIe interface, by a PCIe device driver and communication
software. A PIN pad (smartcard reader with keypad) and smartcards are provided to support
the administration of the cryptographic module, and for the management of key shares.
The software components integrated in the cryptographic module have a modular structure
and comprise the following parts:
Part 1 – Boot loader
Part 2 – Security Module Operating System (SMOS)
Part 3 – Firmware modules
These software components are developed by Utimaco and will be loaded by Utimaco into
the cryptographic module. Additionally, the operating system SMOS and all firmware
modules are packed in a so-called CryptoServer CP5 firmware package and can also be
loaded into the cryptographic module by the customer.
The logical boundary consists of the external TOE interface which can be accessed via the
TOE’s PCIe interface, and of an internal TOE interface which may optionally be used by an
internal SAM (Signature Activation Module). Such internal SAM consists of one or more
firmware modules which are loaded and running within the secure physical boundary of the
CryptoServer CP5. An internal SAM provides its own external interface functions which are
available at the PCIe interface in addition to the CryptoServer CP5 external interface
functions. It must use the TOE command handling as provided by the CryptoServer in order
to communicate via the PCIe interface.
The following requirements hold for an internal SAM:
1. Such internal SAM must be eIDAS-certified according to [PP_QSCD].
2. As part of this certification it is validated that the SAM follows the TOE user guidance
and does not violate the TOE Security Functionality.
Page 14 of 126
Security Target Introduction
3. An internal SAM must be signed by Utimaco with the dedicated CryptoServer CP5
Module Signature Key (this signature is only used for internal SAM modules fulfilling
(1) and (2)),
4. and it must be loaded into the CryptoServer CP5. This is only possible if the SAM is
signed with the CryptoServer CP5 Module Signature Key, and if the command for the
download is authenticated by a user in Administrator role.
Figure 6 below shows the logical boundary of the TOE (red dashed line). The physical
boundary is indicated by the blue line.
external interface
interface
Internal SAM
CryptoServer CP5 Internal SAM
CryptoServer CP5 internal interface (optional)
Firmware modules
CryptoServer CP5
For random number generation and generation of all cryptographic keys, the CryptoServer
CP5 relies on an implemented hardware random noise generator.
Page 15 of 126
Security Target Introduction
For operation purposes, the CryptoServer CP5 supports the following cryptographic services:
Functions for Initialisation:
Generation and export of Master Backup Key
Import of Master Backup Key
Cryptographic Functions:
Signature generation (ECDSA, RSA)
Signature verification (ECDSA, RSA)
Encryption (AES, RSA)
Decryption (AES, RSA)
Generation of random bytes
For the operation purpose, the CryptoServer CP5 supports the following administrative
services:
User administration (creation and deletion of users, change of reference
authentication data (RAD))
System time setting/display
Export and deletion of audit data
Unblock user
Unblock key
To support the security of the above mentioned features of the TOE, the CryptoServer CP5
provides appropriate countermeasures for resistance especially against the following attacks:
Cloning of the product
Unauthorised disclosure of confidential data (during generation, storage and
processing)
Unauthorised manipulation of data (during generation, storage and processing)
Unauthorised usage of private and secret keys
Forgery of data to be processed
Derivation of information on the private key from the related public part for generated
key pairs
Physical and chemical attacks
Furthermore, the TOE provides a secure software update mechanism. Software revisions
shall be granted security certification before their installation in the TOE.
The CryptoServer CP5 product life-cycle is decomposed into the following phases:
Page 16 of 126
Security Target Introduction
Development phase: The design and production of the TOE together constitute the
development phase of the TOE. In the design phase, the components and the
software of the TOE are designed and developed. In the production phase, the TOE
is manufactured consisting of an assembly of supplied components and the software.
The development phase ends with the delivery of the TOE parts (PCIe security
module, software and guidance documents) together with some non-TOE
deliverables to the customer.
Usage phase: The initialisation and operational use of the TOE together constitute
the usage phase of the TOE. In the initialisation phase the TOE is initialised by
generating or importing the Master Backup Key, which is a support key that will be
used for later backup and restore of e. g. signature keys. After initialisation (which
includes the creation of user accounts), the TOE is enabled for use in key
management functions of secret, public and private keys and cryptographic
operations like e. g. signing operations. The operational usage phase begins and
after authentication the user can use the TOE for key management and for
cryptographic tasks. Furthermore, the TOE provides a software update function.
Considering the TOE and its life-cycle described above, the following types of environments
can be distinguished:
Development environment corresponding to the design phase
Manufacturing environment corresponding to the production phase
Initialisation environment corresponding to the initialisation phase
Operational environment corresponding to the operational usage phase
The TOE developers ensure that the assignment of responsibilities during the design phase
is done in a manner which maintains IT security. The development environment in which
the TOE is developed is a well-structured environment with well-defined responsibilities. The
specification, implementation and tests in the development departments are well organised.
Suitable measures enforce the usage of the guidelines. The confidentiality and integrity of
development results is protected. The used measures are always documented.
In the manufacturing environment responsibilities are assigned in manner which maintains
IT security. The TOE is protected from physical attacks which might compromise security.
The manufacturing environment is well documented. Measures are defined to protect
security data like cryptographic keys against disclosure and manipulation. Security data
generation algorithms are accessible to authorised and trusted persons only. Security data
are generated, transported and inserted into the TOE, in such a way to preserve its
appropriate confidentiality and integrity. Optionally, the PCIe security module can be
integrated into an Utimaco CryptoServer LAN (19-inch network appliance).
Leaving the manufacturing environment, the TOE parts are delivered to the customer. At the
customer in the initialisation environment the administrative preparations for the
operational usage take place initially. The initialisation environment may be identical with the
operational environment.
In the operational environment the main tasks are user management, key management of
secret and private keys and creation of digital signatures or digital seals. The responsibilities
are assigned in manner which maintains IT security. After authentication the user can use
the TOE e.g. to manage cryptographic keys or to generate signatures. Furthermore, the TOE
provides a secure software update mechanism.
Page 17 of 126
Security Target Introduction
The Common Criteria (CC) does not prescribe any specific life-cycle model. However, in
order to define the application of the assurance classes, the CC assume the following implicit
life-cycle model consisting of three phases: TOE development (including the development as
well as the production of the TOE), TOE delivery and TOE operational use.
For the evaluation of the CryptoServer CP5 the development phase (consisting of design and
production phase) corresponds to the TOE development in the sense of CC. The usage
phase (consisting of initialisation and operational usage phase) corresponds to the TOE
operational use in the sense of CC. The TOE delivery takes place between both phases.
The following paragraphs outline how some CC assurance activities apply to parts of the life-
cycle (cf. chapter 7.4):
The ALC class which deals with security measures in the development environment of the
TOE applies to the development environment (belonging to the design phase) and to the
manufacturing environment (belonging to the production phase). In particular, the site where
the TOE software is developed as well as the production site are subject to this CC class.
The measures for TOE delivery to the customer are subject to the aspect ALC_DEL of the
ALC class.
The guidance documentation delivered by the TOE developer as part of the TOE delivery
procedures are subject to the AGD class. The guidance documentation describes all
measures necessary for secure usage of the TOE.
The operational usage phase of the TOE is explicitly in focus of this ST. All TOE hardware
and executable software are covered by the evaluation. In particular, the ADV class applies
to the specification and implementation of the security functionality of the TOE, its security
architecture and design. Testing is subject to the ATE class providing assurance that the
TOE behaves as described. Vulnerability assessment class AVA addresses the possibility of
exploitable vulnerabilities introduced in the development or the operation of the TOE.
Page 18 of 126
Security Target Introduction
Page 19 of 126
Security Target Introduction
User Manual:
CryptoServer Se-Series Gen2 CP5 2017-0008,
Administration Manual version 2.0.2
Interface Specifications:
CryptoServer - Firmware Module CXI for 2017-0010,
CryptoServer CP5 – Interface version 1.0.3
Specification
CryptoServer - Firmware Module ADM - 2009-0010,
Interface Specification - ADM Version ≥ version 1.7.6
3.0.0.0
CryptoServer - Firmware Module CMDS 2009-0002,
- Interface Specification - CMDS Version version 1.8.3
≥ 3.0.0.0
CryptoServer – Firmware Module MBK – 2003-0006,
Interface Specification version 1.10.1
Page 20 of 126
Security Target Introduction
PIN pad (smartcard reader HW/SW Utimaco cyberJack one FW-Version V1.0
with keypad)
Page 21 of 126
Security Target Introduction
Depending on the delivery variant, apart from the TOE itself, the following non-TOE
hardware, software and further data is delivered with the TOE (non-TOE-deliverables, not
necessarily required but help to run the TOE):
Herein denotes:
CSLAN v4/v5: CryptoServer LAN (19-inch network appliance with two redundant
power supplies, version v4 or v5) (non-TOE hardware)
Cable: power supply cable (non-TOE hardware)
Product CD: The product CD containing the following firmware, software and data:
o The CryptoServer driver (for Windows and Linux) (non-TOE software)
o The USB driver for the PIN pad “Utimaco cyberJack one” for Windows (non-
TOE software)
o Various cryptographic APIs (non-TOE software, to be used on host)
o The German versions of the Operating Manuals for both TOE delivery variants
o The documentation of the cryptographic APIs in PDF and HTML format (non-
TOE documentation)
o The installation files of various administration tools and key management tools
(non-TOE software, to be used on host)
o Further guidance documents, e. g. for all administration tools (non-TOE
documentation)
o The ADMIN.key keyfile with the authentication key for the default
administrator ADMIN of the CryptoServer (non-TOE data)
Page 22 of 126
Conformance Claims
3 Conformance Claims
as follows
CC Part 2 extended
CC Part 3 conformant
The
Common Criteria for Information Technology Security Evaluation, Evaluation
methodology; CCMB-2012-09-004, Version 3.1, Revision 4, September 2012 [CEM]
3.2 PP Claim
This Security Target claims strict conformance to the Protection Profile EN 419 221-5
Protection Profiles for TSP Cryptographic Modules – Part 5: Cryptographic Module for Trust
Services; v0.15, 2016-11-29 [PP_CMTS].
Page 23 of 126
Security Problem Definition
4.1 Assets
The assets that need to be protected by the TOE are identified below.
R.SecretKey: secret keys used in symmetric cryptographic functions and private keys used
in asymmetric cryptographic functions, managed and used by the TOE in support of the
cryptographic services that it offers. This includes user keys, owned and used by specific
users, and support keys used in the implementation and operation of the TOE. The asset
also includes copies of such keys made for external storage and/or backup purposes. The
confidentiality and integrity of these keys must be protected.
R.PubKey: public keys managed and used by the TOE in support of the cryptographic
services that it offers (including user keys and support keys). This asset includes copies of
keys made for external storage and/or backup purposes. The integrity of these keys must be
protected.
R.ClientData: data supplied by a client for use in a cryptographic function. Depending on the
context, this data may require confidentiality and/or integrity protection.
R.RAD: reference data held by the TOE that is used to authenticate a user (hence to control
access to privileged administrator functions such as TOE backup, export of audit data) or to
authorise a user for access to secret and private keys (R.SecretKey). This asset includes
copies of authentication/authorisation data made for external storage and/or backup
purposes. The integrity of the RAD must be protected; its confidentiality must also be
protected unless the authentication method used means that the RAD is public data (such as
a public key).
4.2 Subjects
The types of subjects identified in this ST are:
Page 24 of 126
Security Problem Definition
S.User: an end user of the TOE who can be associated with secret keys and
authentication/authorisation data held by the TOE. An end user communicates with the TOE
by using a client application (S.Application).
S.Admin: an administrator of the TOE. Administrators are responsible for performing the
TOE initialisation, TOE configuration and other TOE administrative functions.
Each type of subject may include many individual members, for example a single TOE will
generally have many users who are all included as members of the type S.User.
4.3 Threats
The following threats are defined for the TOE. The attacker (i.e. the ‘threat agent’) described
in each of the threats is a subject who is not authorised for the relevant action, but who may
present themselves as either a completely unknown user, or as one of the subjects in section
4.2 (but in this case the attacker will not have access to the authentication or authorisation
data for the subject).
2 See OT.KeyIntegrity in section 4.1 for further discussion of critical attributes of a key.
3
This therefore means that the threat includes unauthorised use of a cryptographic function that makes
use of a key.
Page 25 of 126
Security Problem Definition
4
A seal creator may be a legal person (see [Regulation]) rather than a natural person, and seal creation
data may therefore be authorised for use by a number of natural persons, depending on the nature and
requirements of the trust service provided.
Page 26 of 126
Security Problem Definition
4.5 Assumptions
A.ExternalData Protection of data outside TOE control
Where copies of data protected by the TOE are managed outside of the TOE, client
applications and other entities must provide appropriate protection for that data to a level
required by the application context and the risks in the deployment environment.
In particular, any backups of the TOE and its data are maintained in a way that ensures
appropriate controls over making backups, storing backup data, and using backup data to
restore an operational TOE. The number of sets of backup data does not exceed the
minimum needed to ensure continuity of the TSP service. The ability to restore a TOE to an
operational state from backup data requires at least dual person control (i.e. the participation
and approval of more than one authenticated administrator):
Page 27 of 126
Security Problem Definition
application may make use of appropriate secure channels provided by the TOE to support
these security requirements. Where required by the risks in the operational environment a
suitable entity (possibly the client application) performs a check of the signature returned
from the TOE, to confirm that it relates to the correct DTBS.
Client applications are also responsible for any required logging of the uses made of the TOE
services, such as signing (or sealing) events.
Similar requirements apply in local use cases where no client application need be involved,
but in which the TOE and its user data (such as keys used for signatures) need to be
configured in ways that will support the need for security requirements such as sole control of
signing keys.
Appropriate procedures are defined for the initial creation of data and continuing operation of
the TOE according to the specific risks applicable to the deployment environment and the
ways in which the TOE is used.
Page 28 of 126
Security Objectives
5 Security Objectives
This section identifies and defines the security objectives for the TOE and its operational
environment.
Security objectives reflect the stated intent and counter the identified threats, as well as
comply with the identified organisational security policies and assumptions.
Page 29 of 126
Security Objectives
Page 30 of 126
Security Objectives
permitted to access the key (and the purposes for which this access can be used) and allows
this to be set to the granularity of an individual subject – these access constraints apply to
use of the key even where the key value is not accessible. This objective means that the
TOE also prevents unauthorised use of any cryptographic functions that use a key.
5
Any attempt to use the key in cryptographic functions that are not permitted for that key is addressed
by OT.KeyUseConstraint.
Page 31 of 126
Security Objectives
The TOE allows import and export of secret keys only by using a secure method that
protects the confidentiality and integrity of the data during transmission – in particular, secret
keys must be exported only in encrypted form (it is not sufficient to rely on properties of a
secure channel to provide the protection: control to be identified as non-exportable, in which
case any attempt to export them will be rejected automatically. Public keys may be imported
and exported in a manner that protects the integrity of the data during transmission.
Assigned keys cannot be imported or exported.
Page 32 of 126
Security Objectives
required by the application context and the risks in the deployment environment. This
includes protection of data that is exported from, or imported to, the TOE (such as audit data
and encrypted keys).
In particular, any backups of the TOE and its data shall be maintained in a way that ensures
appropriate controls over making backups, storing backup data, and using backup data to
restore an operational TOE. The number of sets of backup data shall not exceed the
minimum needed to ensure continuity of the TSP service. The ability to restore a TOE to an
operational state from backup data shall require at least dual person control (i.e. the
participation and approval of more than one authenticated administrator).
Page 33 of 126
Security Objectives
Page 34 of 126
Extended Components Definition
Family behaviour:
This family defines quality requirements for the generation of random numbers which are intended to
be use for cryptographic purposes.
Component levelling:
Management: FCS_RNG.1
There are no management activities foreseen.
Audit: FCS_RNG.1
There are no actions defined to be auditable.
FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic,
hybrid physical, hybrid deterministic] random number generator that
implements: [assignment: list of security capabilities].
FCS_RNG.1.2 The TSF shall provide [selection: bits, octets of bits, numbers [assignment:
format of the numbers]] that meet [assignment: a defined quality metric].
Page 35 of 126
Extended Components Definition
Family behaviour:
Components in this family address the requirements for self-testing the TSF for selected
correct operation.
Component levelling:
Management: FPT_TST_EXT.1
There are no management activities foreseen.
Audit: FPT_TST_EXT.1
The following actions should be auditable if FAU_GEN Security audit data generation is
included in the PP/ST:
Indication that TSF self-test was completed.
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests [selection: during
initial start-up (on power on), periodically during normal operation, at the
request of the authorised user, at the conditions [assignment: conditions
under which self-tests should occur]] to demonstrate the correct operation
of the TSF: [assignment: list of self-tests run by the TSF].
Page 36 of 126
Security Requirements
7 Security Requirements
This chapter gives the security functional requirements (SFR) and the security assurance
requirements (SAR) for the TOE and the environment.
Security functional requirements components given in section 7.3 are drawn from Common
Criteria part 2 [CC2]. Some security functional requirements represent extensions to [CC2],
with a reasoning given in section 6. Operations for assignment, selection and refinement
have been made.
The TOE security assurance requirements statements given in section 7.4 “Security
Assurance Requirements” are drawn from the security assurance components from Common
Criteria part 3 [CC3].
If an Application Note e. g. to an SFR was added by the Protection Profile, this is denoted by
“Application Note <nn> (PP)”, with <nn> being the number of the Application Note as given
in the Protection Profile. If an additional Application Note was added by the Security Target
writer, this is denoted by “Application Note <nn> (ST)”.
Page 37 of 126
Security Requirements
Figure 5 illustrates the architecture of the SFRs from the PP that provide for the protection of
cryptographic keys. In this ST most of the SFRs are iterated (see chapter 7.3), the security
architecture therefore is enhanced in a natural way that all iterations of a specific SFR of the
PP are responsible to implement the security requirements from the PP. For example, all
Page 38 of 126
Security Requirements
cryptographic keys are generated according to all iterations of SFR FCS_CKM.1 and with
support from FCS_RNG.1, etc.
Figure 6 illustrates the architecture of the SFRs from the PP that provide for the requirements
on the user concept, TSF protection and auditing. Also here, in this ST some of the SFRs are
iterated (see chapter 7.3), the security architecture therefore is enhanced in a natural way
Page 39 of 126
Security Requirements
that dedicated iterations of a specific SFR of the PP are responsible to implement the
security requirements from the PP. In particular, users are authenticated according to
FIA_UID.1, FIA_UAU.1//UserAuth, and FIA_AFL.1//UserAuth, with unblocking of blocked
users according to FMT_SMF.1 and FMT_MTD.1/Unblock//User.
Export
Import
Use
Attributes
Generate Stored key
bound to key
Backup
Restore
Destroy
Import:
FDP_IFF.1/KeyBasics requires a secure channel (FTP_TRP.1/Local and
FTP_TRP.1/External) and import in encrypted form or by using at least two
components
FAU_GEN.1 requires auditing of key import
Generate:
FCS_CKM.1 (all iterations) requires approved algorithms
FCS_RNG.1 defines requirements on random number generation
FMT_MSA.3/Keys defines requirements on key attribute initialisation
FAU_GEN.1 requires auditing of key generation (and of failure of RNG)
Restore:
FDP_ACF.1/Backup requires that only an Administrator can restore from a backup,
all backups must preserve confidentiality and integrity of keys (as appropriate to key
type) and their attributes, and any restore must be under dual person control
FAU_GEN.1 requires auditing of a restore (or of any integrity failure during a restore
attempt)
Page 40 of 126
Security Requirements
Stored key:
FDP_IFF.1/KeyBasics requires no plaintext access
FDP_SDI.2 requires protection of the integrity of keys and their attributes
FAU_GEN.1 requires auditing of integrity errors detected
Export:
FDP_IFF.1/KeyBasics requires a secure channel (FTP_TRP.1), authorisation before
key export, no export of Assigned Keys, export controlled by the Export flag attribute,
and export in encrypted form
FAU_GEN.1 requires auditing of key export
Use:
FIA_AFL.1//KeyAuth requires blocking of access to a key on reaching an
authorisation failure threshold (FDP_IFF.1/KeyBasics and FMT_MTD.1/Unblock//Key
define requirements on unblocking)
FDP_ACF.1/KeyUsage requires authorisation before use of a key and that the key
can only be used as identified in its Key Usage attribute
FIA_UAU.6/KeyAuth requires authorisation before initial use of a key and describes
any additional requirements for re-authorisation conditions such as expiry of a time
period or number of uses of a key (or when the key authorisation period has been
explicitly ended)
FDP_RIP.1 requires protection of authorisation data on de-allocation
FDP_IFF.1/KeyBasics requires no access to intermediate values in any operation
using a secret key
FCS_COP.1 requires the use of approved algorithms
FAU_GEN.1 requires auditing of authorisation failures (and blocking or unblocking)
Backup:
FDP_ACF.1/Backup requires that only an Administrator can make a backup; all
backups must preserve confidentiality and integrity of keys (as appropriate to their
key type) and their attributes
FAU_GEN.1 requires auditing of a backup
Destroy:
FDP_RIP.1 requires keys to be protected on de-allocation
FCS_CKM.4 requires key zeroisation on de-allocation
FAU_GEN.1 requires auditing of key destruction
Page 41 of 126
Security Requirements
4.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_CKM.4
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
5.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//AES_Encr
FDP_ITC.2 Import of user data with security attributes, or
yption_CBC
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
6.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//AES_Encr
FDP_ITC.2 Import of user data with security attributes, or
yption_OFB
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
7.
[FDP_ITC.1 I
FCS_COP.1//AES_Decr
port of user data without security attributes, or
yption_CBC
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
8.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//AES_Decr
FDP_ITC.2 Import of user data with security attributes, or
yption_OFB
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
9.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//AES_CMA
FDP_ITC.2 Import of user data with security attributes, or
C
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
10.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//AES_ECB
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
11.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//AES_GC
FDP_ITC.2 Import of user data with security attributes, or
M
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
Page 42 of 126
Security Requirements
12.
[FDP_ITC.1 I
FCS_COP.1//RSA_Sign
port of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
13.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//RSA_Verif
FDP_ITC.2 Import of user data with security attributes, or
y
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
14.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//RSA_Encr
FDP_ITC.2 Import of user data with security attributes, or
yption
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
15.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//RSA_Decr
FDP_ITC.2 Import of user data with security attributes, or
yption
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
16.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//ECDSA_S
FDP_ITC.2 Import of user data with security attributes, or
ign
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
17.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//ECDSA_V
FDP_ITC.2 Import of user data with security attributes, or
erify
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
18.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//HMAC
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
19.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//Hash
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
20.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//Diffie-
FDP_ITC.2 Import of user data with security attributes, or
Hellman
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
21.
[FDP_ITC.1 Import of user data without security attributes, or
FCS_COP.1//KeyDeriva
FDP_ITC.2 Import of user data with security attributes, or
tion
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
22. FCS_RNG.1 No dependencies.
Page 43 of 126
Security Requirements
30.
FDP_IFC.1 Subset information flow control
FDP_IFF.1/KeyBasics
FMT_MSA.3 Static attribute initialisation
31.
FDP_ACF.1 Security attribute based access control
FDP_ACC.1/KeyUsage
32.
FDP_ACC.1 Subset access control
FDP_ACF.1/KeyUsage
FMT_MSA.3 Static attribute initialisation
33.
FDP_ACF.1 Security attribute based access control
FDP_ACC.1/Backup
34.
FDP_ACC.1 Subset access control
FDP_ACF.1/Backup
FMT_MSA.3 Static attribute initialisation
35. FDP_SDI.2 No dependencies
Page 44 of 126
Security Requirements
46.
FMT_SMR.1 Security roles
FMT_MTD.1/Unblock//U
FMT_SMF.1 Specification of Management Functions
ser
47.
FMT_SMR.1 Security roles
FMT_MTD.1/Unblock//K
FMT_SMF.1 Specification of Management Functions
ey
48.
FMT_SMR.1 Security roles
FMT_MTD.1/AuditLog
FMT_SMF.1 Specification of Management Functions
49.
FMT_SMR.1 Security roles
FMT_MTD.1//SWUpdat
FMT_SMF.1 Specification of Management Functions
e
50.
FDP_ACC.1 Subset access control, or
FMT_MSA.1/GenKeys//
FDP_IFC.1 Subset information flow control]
AFlag
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
51.
FDP_ACC.1 Subset access control, or
FMT_MSA.1/GenKeys//
FDP_IFC.1 Subset information flow control]
ExportF
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
52.
FDP_ACC.1 Subset access control, or
FMT_MSA.1/GenKeys//
FDP_IFC.1 Subset information flow control]
AuthD
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
53.
FDP_ACC.1 Subset access control, or
FMT_MSA.1/GenKeys//
FDP_IFC.1 Subset information flow control]
None
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
54.
FDP_ACC.1 Subset access control, or
FMT_MSA.1/AKeys//Aut
FDP_IFC.1 Subset information flow control]
hD
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
55.
FDP_ACC.1 Subset access control, or
FMT_MSA.1/AKeys//No
FDP_IFC.1 Subset information flow control]
ne
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
56.
FMT_MSA.1 Management of security attributes
FMT_MSA.3/Keys
FMT_SMR.1 Security roles
FAU Security audit data generation
58.
FAU_GEN.1 Audit data generation
FAU_GEN.2
FIA_UID.1 Timing of identification
59. FAU_STG.2 FAU_GEN.1 Audit data generation
The individual security functional requirements are specified in the sections below.
Page 45 of 126
Security Requirements
Page 46 of 126
Security Requirements
cryptographic key sizes of minimum 224 bits13 that meet the following:
ECDSA key pair generation for ECC domain parameters Curve P-224, Curve
P-256, Curve P-384 or Curve P-521 as specified in [FIPS 186-4] appendix 6,
or brainpoolP224r1, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1,
brainpoolP512r1, brainpoolP224t1, brainpoolP256t1, brainpoolP320t1,
brainpoolP384t1 or brainpoolP512t1 as specified in [ECCBP] chapter 10, or
curve FRP256v1 as specified in [ANSSI] and with random number generation
according to FCS_RNG.114.
Page 47 of 126
Security Requirements
Encrypted secret and private keys are destroyed by deleting the logical address, and by
zeroizing the encryption key in case of a physical attack: For permanent storage inside the
TOE, the TOE enforces all secret and private keys to be stored encrypted with the TOE’s
internal Master Key. The commands for key deletion delete the encrypted secret and private
keys by deletion of the logical addresses, respectively. After that it is no longer possible to
address the memory areas of the encrypted keys via the TOE interface.
Furthermore, there is no logical access from outside of the TOE to the Master Key itself. In
case of e. g. a physical attack, the Master Key is protected by the TOE’s alarm mechanism
and its hard, opaque tamper-evident enclosure. The Master Key will be actively zeroised in
case of an alarm. The Master Key will also actively be erased in case of a Clear command
(by actively overwriting it with a new Master Key).
This ensures secure storage and destruction also for encrypted secret and private keys.
Page 48 of 126
Security Requirements
16, 24 or 32 bytes length24 that meet the following: [NIST SP 800-38A] chapter
6.4, [FIPS 197] chapter 5 (AES block cipher in OFB mode)25.
FCS_COP.1//AES_CMAC
Page 49 of 126
Security Requirements
Page 50 of 126
Security Requirements
length44 that meet the following: [NIST SP 800-38A] chapter 7, [FIPS 197]
chapter 5 (AES block cipher in GCM mode)45.
Page 51 of 126
Security Requirements
Page 52 of 126
Security Requirements
and cryptographic key sizes of minimum 224 bits64 that meet the following:
signature generation according to [ANSI-X9.62] with signature keys based on
ECC domain parameters Curve P-224, Curve P-256, Curve P-384 or Curve P-
521 as specified in [FIPS 186-4] appendix D, or brainpoolP224r1,
brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1,
brainpoolP224t1, brainpoolP256t1, brainpoolP320t1, brainpoolP384t1 or
brainpoolP512t1 as specified in [ECCBP] chapter 10, or curve FRP256v1 as
specified in [ANSSI]65.
cryptographic key sizes of minimum 224 bits68 that meet the following:
signature generation according to [ANSI-X9.62] with signature keys based on
ECC domain parameters curve P-224, curve P-256, curve P-384 or curve P-
521 as specified in [FIPS 186-4] appendix D, or curve brainpoolP224r1,
brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1,
brainpoolP224t1, brainpoolP256t1, brainpoolP320t1, brainpoolP384t1 or
brainpoolP512t1 as specified in [ECCBP] chapter 10, or curve FRP256v1 as
specified in [ANSSI]69.
Page 53 of 126
Security Requirements
between 4 and 1024 bytes 72 that meet the following: [FIPS 198] and [RFC
2104], with hash value calculation according to FCS_COP.1//Hash73.
FCS_COP.1.1//Hash The TSF shall perform hash value calculation74 in accordance with a
specified cryptographic algorithm SHA-224, SHA-256, SHA-384, SHA-512,
SHA3-224, SHA3-256, SHA3-384 or SHA3-51275 and cryptographic key sizes
none76 that meet the following: [FIPS 180-4] chapter 6 for SHA-2, and [FIPS
202] for SHA-377.
Page 54 of 126
Security Requirements
Page 55 of 126
Security Requirements
Dependencies: No dependencies.
Page 56 of 126
Security Requirements
Page 57 of 126
Security Requirements
Page 58 of 126
Security Requirements
(see Application Note 1 (ST)) as mandated in the TOE Guidance. The TOE will implicitly
derive the result of key authorisation from the SAM.
102 [selection: [assignment: positive integer number], an administrator configurable positive integer within
[assignment: range of acceptable values]]
103 [PP_CMTS] [assignment: list of authentication events]
104 [selection: met, surpassed]
105 [assignment: description of the relevant functionality]
106 [selection: unblocked by [assignment: identification of the authorised subject or role], a time period
[assignment: time period] has elapsed]
107 [PP_CMTS] [assignment: list of actions]
Page 59 of 126
Security Requirements
FIA_UAU.6/KeyAuth Re-authenticating
FIA_UAU.6.1/KeyAuth The TSF shall authorise and re-authorise108 the user for access
to a secret key under the conditions
(1) Authorisation in order to be granted initial access to the key; and
(2) Re-authorisation of the key under the following conditions:
after the number of uses of the secret key (as specified in the secret
key’s attributes) for which the secret key was last authorised has
already been made;
after explicit rescinding of previous authorisation for access to the
secret key109.
Page 60 of 126
Security Requirements
who can be held responsible for use of the key (such as any case where a single
authorisation for use of a key could allow the creation of more than one signature using the
authorised key). Note that in order to make qualified electronic signatures under [Regulation]
then the user/application must be able to precisely control the signatures that can be made under
each authorisation.
Actions taken by the TOE in the case of successive authorisation failures must be specified
using an iteration of FIA_AFL.1.
FDP_IFF.1.1/KeyBasics The TSF shall enforce the Key Basics SFP112 based on the
following types of subject and information security attributes:
(1) whether a key is a secret or a public key
(2) whether a secret key is an Assigned Key
(3) whether channels selected to export keys are secure
(4) the value of the Export Flag of a key113.
113 [PP_CMTS] [assignment: list of subjects and information controlled under the indicated SFP, and for
Page 61 of 126
Security Requirements
(2) Public keys shall always be exported with integrity protection of their key
value and attributes
(3) Keys shall only be imported over a secure channel (providing
authentication and integrity protection)
(4) A secret key can only be imported if it is a non-Assigned key
(5) Secret keys shall only be imported in encrypted form or using split-
knowledge procedures requiring at least two key components to
reconstruct the key, with key components supplied by at least two
separately authenticated users
(6) Unblocking access to a key shall not allow any subject other than those
authorised to access the key at the time when it was blocked114.
FDP_IFF.1.5/KeyBasics The TSF shall explicitly deny an information flow based on the
following rules:
(1) No subject shall be allowed to access the plaintext value of any secret
key directly.
(2) No subject shall be allowed to export a secret key in plaintext.
(3) No subject shall be allowed to export an Assigned Key.
(4) No subject shall be allowed to export a secret key without submitting the
correct authorisation data for the key
(5) No subject shall be allowed to access intermediate values in any
operation that uses a secret key
114 [PP_CMTS] [assignment: for each operation, the security attribute-based relationship that must hold
between subject and information security attributes]
115 [PP_CMTS] [assignment: additional information flow control SFP rules]
116 [PP_CMTS] [assignment: rules, based on security attributes, that explicitly authorise information
flows]
Page 62 of 126
Security Requirements
(6) A key with an Export Flag value marking it as non-exportable shall not
be exported117
Direct access to a key value in FDP_IFF.1.5/KeyBasics (1) is access that makes the value
available for reading or modification – this includes operations that would subsequently allow
reading or modification of the key (e.g. making a copy of the key with different attributes, or
with a different object type that would then allow direct read access). Note that this PP
assumes that key values are never modified after they have been generated.
Export of a key as in FDP_IFF.1.5/KeyBasics (1), (2), (4) and (6) is not the same as backup
(governed by FDP_ACF.1/Backup) or external storage of keys under continuing TOE control
(governed by other parts of the Key Basics SFP in FDP_IFF.1/KeyBasics, and the Key
Usage SFP in FDP_ACF.1/KeyUsage). Thus an Export Flag of ‘non-exportable’ does not
prevent backup or external storage of the keys under continuing TOE control.
The Security Target and/or Operational Guidance shall specify how any attributes not
supplied with an imported key are set when the key is imported (or alternatively how such
keys are rejected). Similarly, the Security Target and/or Operational Guidance shall describe
how the key’s attributes are represented when exported, so that their meaning can be
understood by the receiver.
If the TOE does not provide facilities to import or export keys then the relevant part of the
SFR is trivially satisfied, and this should be stated in the Security Target.
FDP_ACC.1.1/KeyUsage The TSF shall enforce the Key Usage SFP118 to objects based
on the following
(1) Subjects: all;
(2) Object: Keys
(3) Operations: all119
117 [PP_CMTS] [assignment: rules, based on security attributes, that explicitly deny information flows]
118 [PP_CMTS] [assignment: access control SFP]
119
[PP_CMTS] [assignment: list of subjects, objects, and operations among subjects and objects
covered by the SFP]
Page 63 of 126
Security Requirements
FDP_ACF.1.1/KeyUsage The TSF shall enforce the Key Usage SFP120 to objects based
on the following:
(1) whether the subject is currently authorised to use the secret key
(2) whether the subject is currently authorised to change the attributes of the
secret key
(3) the cryptographic function that is attempting to use the secret key121.
Page 64 of 126
Security Requirements
FDP_ACF.1.1/Backup The TSF shall enforce the Backup SFP127 to objects based on
the following:
(1) whether the subject is an administrator128.
124 [PP_CMTS] [assignment: rules, based on security attributes, that explicitly deny access of subjects
to objects]
125 [PP_CMTS] [assignment: access control SFP]
126
[PP_CMTS] [assignment: list of subjects, objects, and operations among subjects and objects
covered by the SFP]
127 [PP_CMTS] [assignment: access control SFP]
128
[PP_CMTS] [assignment: list of subjects and objects controlled under the indicated SFP, and for
each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes]
Page 65 of 126
Security Requirements
(4) Any backup and restore operations shall preserve the integrity of the key
attributes, and the binding of each set of attributes to its key129.
FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF for
integrity errors132 on all keys (including security attributes)133, based on the
following attributes: integrity protection data134.
129 [PP_CMTS] [assignment: rules governing access among controlled subjects and controlled objects
using controlled operations on controlled objects]
130 [PP_CMTS] [assignment: rules, based on security attributes, that explicitly authorise access of
subjects to objects]
131 [PP_CMTS] [assignment: rules, based on security attributes, that explicitly deny access of subjects
to objects]
132 [PP_CMTS] [assignment: integrity errors
133 [PP_CMTS] objects
134 [PP_CMTS] [assignment: user data attributes]
Page 66 of 126
Security Requirements
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is
made unavailable upon the de-allocation of the resource from136 the following
objects:
(1) authorisation data
(2) secret keys137.
FTP_TRP.1.1/Local The TSF shall provide a communication path between itself and
local138 client applications139 that are logically distinct from other
Page 67 of 126
Security Requirements
FTP_TRP.1.3/Local The TSF shall require the use of the trusted path for protecting the
confidentiality and integrity of sensitive data exchanged between the local
client application and the TOE over a channel that passes through an insecure
environment 143.
Page 68 of 126
Security Requirements
An internal SAM, being an internal local client application, is authenticated by the TOE when
loaded within its physical boundary by verifying its module signature applied with the
CryptoServer CP5 Module Signature Key. In line with Application Notes 6 and 29 from the
PP, the physical protection provided by the TOE is considered a sufficiently trusted path and
no further cryptographic protection is required for the communication between the TOE and
the internal SAM (see also Application Note 1 (ST)).
FTP_TRP.1.1/External The TSF shall provide a communication path between itself and
remote144 external client applications145 that are logically distinct from other
communication paths and provides assured authentication146 of its end points
and protection of the communicated data from modification and disclosure147.
FTP_TRP.1.3/External The TSF shall require the use of the trusted path for protecting
the confidentiality and integrity of sensitive data exchanged between the
external client application and the TOE over a channel that passes through an
insecure environment 149.
Page 69 of 126
Security Requirements
The Security Target shall identify in an application note the iterations of FCS_COP.1 that
provide any cryptographic functions that contribute to the implementation of the trusted path,
and the SFRs that provide the authentication of the end points.
FPT_TST_EXT.1.1 The TSF shall run a suite of the following self-tests during initial start-
up (or power-on or reset) and at the conditions firmware download, PTRNG
request, DRBG request and key pair generation150 to demonstrate the correct
operation of the TSF:
At initial start-up (or power-on or reset):
o Software/firmware integrity test
o Cryptographic algorithm tests
150
[selection: during initial start-up (on power on), periodically during normal operation, at the request
of the authorised user, at the conditions [assignment: conditions under which self-tests should occur]]
Page 70 of 126
Security Requirements
Page 71 of 126
Security Requirements
FPT_PHP.3.1 The TSF shall resist physical manipulation152 to the entire TOE
components implementing the TSF153 by responding automatically such that
the SFRs are always enforced.
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures
occur:
1. Self-test according to FPT_TST_EXT.1 fails
2. Environmental conditions are outside normal operating range
(including temperature and power)
3. Failures of critical TOE hardware components (including the
RNG) occur
4. Corruption of TOE software occurs
5. Failures caused by sensitive TOE software components154.
Page 72 of 126
Security Requirements
155
Assigned Keys may be stored externally in a form that protects the confidentiality and integrity of the
key and the binding of the key to its attributes (in particular the requirements of the SFRs
FDP_IFF.1/KeyBasics and FDP_SDI.1 apply to externally stored keys), as discussed in [PP_CMTS]
section 1.3.1.
156
Secure operating procedures will be needed in order to ensure that the process from generation to
assignment is suitable for maintaining any requirements for non-repudiation that may apply to the
application context for use of the key (cf. OE.DataContext and the refinement to AGD_OPE.1 in section
7.4.1).
Page 73 of 126
Security Requirements
export is allowed) and ‘false’ (meaning that export is not allowed) but may be mapped to
other suitable binary values in the TOE implementation
assigned flag: indicates whether the key has currently been assigned. Once a key has
been assigned by an Administrator then its authorisation data can only be changed on
successful validation of the current authorisation data – it cannot be changed or reset by
an Administrator – and the key usage attribute cannot be changed; allowed values are
referred to in the PP as ‘assigned’ and ‘non-assigned’ but may be mapped to other
suitable binary values in the TOE implementation.
FMT_SMR.1.1 The TSF shall maintain the roles Administrator, Non-internal Local
Client Application, Internal SAM, External Client Application157, Key
User, User Administrator, Key Manager, Security Officer158 159.
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Page 74 of 126
Security Requirements
160 [selection: backup and restore functions, no backup and restore functions]
161 [selection: key import function, no key import function]
162 [selection: key export function, no key export function]
163 [assignment: list of management functions to be provided by the TOE]
Page 75 of 126
Security Requirements
FMT_MTD.1.1/Unblock//User The TSF shall restrict the ability to unblock164 the any
user account blocked due to consecutive authentication failures165 to User
Administrators166.
FMT_MTD.1.1/Unblock//Key The TSF shall restrict the ability to unblock167 the any
key blocked due to consecutive authorisation failures168 to Key
Managers169.
FMT_MTD.1.1/AuditLog The TSF shall restrict the ability to control export and deletion
of170 the audit log records171 to the Administrator, User Administrator, Key
Manager and Security Officer role (for the ability to control export) and to the
164 [PP_CMTS] [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
165 [assignment: list of TSF data]
166 [assignment: the authorised identified administrative roles]
167 [PP_CMTS] [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
168 [assignment: list of TSF data]
169 [assignment: the authorised identified administrative roles]
170 [PP_CMTS] [selection: change_default, query, modify, delete, clear, [assignment: other operations]]
171 [PP_CMTS] [assignment: list of TSF data]
Page 76 of 126
Security Requirements
Administrator and User Administrator role (for the ability to control deletion of
the audit log records)172.
FMT_MTD.1.1//SWUpdate The TSF shall restrict the ability to update170 the TSF
executable code stored in the TOE in form of software or firmware171 to the
Administrator role172.
FMT_MSA.1.1/GenKeys//AFlag The TSF shall enforce the Key Usage SFP173 to restrict
174
the ability to modify the security attributes Assigned Flag of any General
(non-Assigned) Key175 to Key Managers, and only to change from non-
Assigned to Assigned176.
Page 77 of 126
Security Requirements
FMT_MSA.1.1/GenKeys//ExportF The TSF shall enforce the Key Usage SFP177 to restrict
the ability to modify178 the security attributes Export Flag of any General (non-
Assigned) Key179 to Key Managers, and only to change from ‘true’ (meaning
that export is allowed) to ‘false’ (meaning that export is not allowed)180.
FMT_MSA.1.1/GenKeys//AuthD The TSF shall enforce the Key Usage SFP181 to restrict
182
the ability to modify the security attributes Authorisation Data of any General
(non-Assigned) Key183 to any Key User, but only when modification operation
of Authorisation Data includes presentation of current Authorisation Data, or to
Key Managers184.
FMT_MSA.1.1/GenKeys//None The TSF shall enforce the Key Usage SFP185 to restrict
186
the ability to modify the security attributes Key ID, Key Type, Re-
Authorisation conditions, Key Usage, Integrity Protection Data of any General
(non-Assigned) Key187 to none (moreover the Re-Authorisation conditions are
177 [PP_CMTS] [assignment: access control SFP(s), information flow control SFP(s)]
178 [PP_CMTS] [selection: change_default, query, modify, delete, [assignment: other operations]]
179 [assignment: list of security attributes]
180 [assignment: list of subjects, objects, and operations among subjects and objects covered by the
SFP]
181 [PP_CMTS] [assignment: access control SFP(s), information flow control SFP(s)]
182 [PP_CMTS] [selection: change_default, query, modify, delete, [assignment: other operations]]
183 [assignment: list of security attributes]
184 [assignment: list of subjects, objects, and operations among subjects and objects covered by the
SFP]
185 [PP_CMTS] [assignment: access control SFP(s), information flow control SFP(s)]
186 [PP_CMTS] [selection: change_default, query, modify, delete, [assignment: other operations]]
187 [assignment: list of security attributes]
Page 78 of 126
Security Requirements
implicit and constant for all keys, and Integrity Protection Data are maintained
automatically by TSF)188.
FMT_MSA.1.1/AKeys//AuthD The TSF shall enforce the Key Usage SFP189 to restrict
190
the ability to modify the security attributes Authorisation Data of any
Assigned Key191 to any Key User or Key Manager but only when modification
operation of Authorisation Data includes presentation of current Authorisation
Data192.
FMT_MSA.1.1/AKeys//None The TSF shall enforce the Key Usage SFP193 to restrict the
ability to modify194 the security attributes Key ID, Key Type, Re-Authorisation
conditions, Key Usage, Export Flag, Assigned Flag, Integrity Protection Data
of any Assigned Key195 to none (moreover the Re-Authorisation conditions are
implicit and constant for all keys, and Integrity Protection Data are maintained
automatically by TSF)196.
188 [assignment: list of subjects, objects, and operations among subjects and objects covered by the
SFP]
189 [PP_CMTS] [assignment: access control SFP(s), information flow control SFP(s)]
190 [PP_CMTS] [selection: change_default, query, modify, delete, [assignment: other operations]]
191 [assignment: list of security attributes]
192
[assignment: list of subjects, objects, and operations among subjects and objects covered by the
SFP]
193 [PP_CMTS] [assignment: access control SFP(s), information flow control SFP(s)]
194 [PP_CMTS] [selection: change_default, query, modify, delete, [assignment: other operations]]
195 [assignment: list of security attributes]
196
[assignment: list of subjects, objects, and operations among subjects and objects covered by the
SFP]
Page 79 of 126
Security Requirements
Modification Table; the Security Target completes the other parts not specified here (along
with any other information for other security attributes relevant to a particular TOE). The
specific attributes used by a particular TOE may vary, but the Security Target must make
clear how control is achieved over the ability to modify attributes of keys in terms of the
specific attributes and controls imposed by the TOE. Where applicable to the operational
environment for a particular TOE, these controls should be described with reference to the
ways that they are used to provide qualified electronic signatures and qualified electronic
seals that meet the requirements of [Regulation] (cf. the refinement to AGD_OPE.1 in section
7.4.1).
Where a TOE does not support one of the individual types of key then the Security Target
states this, and the requirements for that type of key are considered to be trivially satisfied.
Authorisation Data and Re-authorisation conditions are required for secret keys only. Re-
authorisation conditions include the conditions specified for FIA_UAU.6.1/KeyAuth (matching
the assignments and selections made for that SFR in the Security Target).
197
It is acceptable for a Security Target to specify more restrictive modification conditions than listed
in this table, but not to specify less restrictive modification conditions. Where no specific condition
is specified (denoted by ‘---‘) then the Security Target is not constrained by this PP, but clearly the
requirements of the system of which the cryptographic module is a part may have more detailed
requirements for a specific deployment (i.e. operational environment).
Page 80 of 126
Security Requirements
FMT_MSA.3.1/Keys The TSF shall enforce the Key Usage SFP198 to provide permissive199
default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2/Keys The TSF shall allow the Key Manager or Internal SAM200 to specify
alternative initial values to override the default values when an object
or information is created.
198 [PP_CMTS] [assignment: access control SFP, information flow control SFP]
199 [selection, choose one of: restrictive, permissive, [assignment: other property]]
200 [assignment: the authorised identified roles according to the constraints in the Key Attribute
Initialisation Table]
Page 81 of 126
Security Requirements
Attributes assigned by the TOE to any imported keys must be described in the Security
Target and in operational user guidance (see the refinements to AGD_OPE.1 in section
7.4.1), noting that a secret key can only be imported if it is a non-Assigned key (cf.
FDP_IFF.1/KeyBasics).
The Integrity Protection Data for a key is used to support FDP_SDI.2 and covers not only the
key but also its other attributes.
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable
events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the not specified201 level of audit; and202
c) Startup of the TOE;
d) Shutdown of the TOE
e) Cryptographic key generation (FCS_CKM.1 (all iterations));
f) Cryptographic key destruction (FCS_CKM.4);
g) Failure of the random number generator (FCS_RND.1);
h) Authentication and authorisation failure handling (FIA_AFL.1 (all
iterations)): all unsuccessful authentication or authorisation attempts,
the reaching of the threshold for the unsuccessful authentication or
authorisation attempts and the blocking actions taken;
i) All attempts to import or export keys (FDP_IFF.1/KeyBasics);
j) All modifications to attributes of keys (FDP_ACF.1/KeyUsage,
FMT_MSA.1/GenKeys and FMT_MSA.1/AKeys (all iterations));
k) Backup and restore (FDP_ACF.1/Backup): use of any backup function,
use of any restore function, unsuccessful restore because of detection
of modification of the backup data;
l) Integrity errors detected for keys (FDP_SDI.2);
m) Failures to establish secure channels (FTP_TRP.1/Local,
FTP_TRP.1/External);
n) Self-test completion (FPT_TST_EXT.1);
o) Failures detected by the TOE (FPT_FLS.1);
p) All administrative actions (FMT_SMF.1, FMT_MSA.1 (all iterations),
FMT_MSA.3/Keys,);
q) Unblocking of access (FMT_MTD.1/Unblock//User and
FMT_MTD.1/Unblock//Key);
r) Modifications to audit parameters (affecting the content of the audit log)
(FAU_GEN.1);
201 [PP_CMTS] [selection, choose one of: minimum, basic, detailed, not specified]
202 [PP_CMTS] Levels of audit are not required to be defined in the Security Target.
Page 82 of 126
Security Requirements
s) none203.
FAU_GEN.1.2 The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity (if
applicable), and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions of
the functional components included in the PP/ST:
none204.
FAU_GEN.2.1 For audit events resulting from actions of identified users, the TSF shall be
able to associate each auditable event with the identity of the user that
caused the event.
FAU_STG.2.1 The TSF shall protect the stored audit records in the audit trail from
unauthorised deletion.
FAU_STG.2.2 The TSF shall be able to prevent205 unauthorised modifications to the stored
audit records in the audit trail.
FAU_STG.2.3 The TSF shall ensure that all206 stored audit records will be maintained when
the following conditions occur: audit storage exhaustion207.
Page 83 of 126
Security Requirements
Page 84 of 126
Security Requirements
Refinement:
The following specific topics must be addressed as part of ADV_ARC.1 for this Protection
Profile. It is acceptable for references to deliverables supplied for other assurance families,
such as ADV_FSP, to be used to meet these requirements, provided that the relationship of
the relevant interface specifications to the concepts in the Protection Profile is clear. Note
that in some cases, the requirement for description of these particular aspects under
ADV_ARC is intended to make clear any differences between the full capabilities of the
product and the scope of the Security Target.
(1) In general cryptographic modules will make use of ‘support keys’ as part of their
implementation of protection mechanisms, where these keys are generally not held on
behalf of specific users208 or client applications, but are used by the TOE to carry out its
normal operations and as part of the implementation mechanism other SFRs and to
protect the TSF itself. These support keys may be used for a variety of purposes
(including aspects such as authentication, authorisation, secure channels, security of
external storage, or internal data protection), For the purposes of this PP, support keys
used by the TOE are treated as TSF data, and require a specific security rationale to be
included as part of the ADV_ARC.1 deliverables. This rationale must include a
description of the key architecture, identifying all support keys used by the TOE (at least
in its evaluated configuration), their method of generation and storage, their purpose in
TOE operation, and the ways in which they are protected so as to support the
requirements of FDP_IFF.1/KeyBasics and FDP_ACF.1/KeyUsage (noting that the
mechanisms used for support keys may differ from those used for user keys). Examples
would be keys used for wrapping user keys in order to allow secure storage of the user
keys, keys used to implement secure channels, and keys used to protect backups. The
description must demonstrate that sufficient entropy has been used in the generation of
each support key, and the source of that entropy. The rationale must demonstrate that
these support keys cannot be exported/imported in a way that threatens the secure
operation of the TOE. The evaluator shall include the description of the support keys in
their analysis of the protection of user data (e.g. to confirm that it does not introduce
vulnerabilities in the implementation of the SFRs).
(2) If updates to the TOE software or firmware are supported then the ADV_ARC.1
deliverables must describe how the TOE is protected against unauthorised updates, by
208
Some support keys may be seen as being held on behalf of administrators, but the main intention of
distinguishing support keys and user keys is for the ADV_ARC.1 deliverables to describe all the different
types of key available, their properties, and their relationship to the SFRs in this Protection Profile.
Page 85 of 126
Security Requirements
using digital signatures. This shall be confirmed by evaluator testing (if updates are
supported) to confirm that updates with invalid signatures are rejected without being
executed. The digital signature algorithms used to protect updates shall be included in
the scope of FCS_COP.1 signature SFR(s).
Refinement:
The following specific topics must be addressed as part of the Operational Guidance for the
TOE:
1. The specific ways in which the TOE needs to be configured and used in order to
provide qualified electronic signatures and qualified electronic seals that meet the
Page 86 of 126
Security Requirements
requirements of [Regulation]. This includes ways in which the TOE can ensure that the
signatory can, with high level of confidence, have sole control over the use of the
secret key that acts as his/her signature creation data. Thus, for example, it may be
necessary for client applications to use TOE interfaces according to certain guidance in
order to correctly implement the requirements on attributes of keys as described in this
PP. It may be necessary for the TOE to define ways in which secret keys to be used for
signing purposes can be created in a way that does not allow subsequent modification
of some or all of their attributes, e.g. by an administrator, before they are assigned to
the signatory (cf. FMT_MSA.1/AKeys (all iterations)). The intention of this aspect of the
operational user guidance documentation is to identify the configuration and secure
use required for a particular TOE, and how it is necessary to connect this with other
aspects such as procedural controls and client applications in the operational
environment.
The evaluators shall test the identified ways of using the TOE for qualified electronic
signatures and qualified electronic seals to demonstrate that the description in the
Operational Guidance is suitably complete, and that the keys produced by following the
Operational Guidance do indeed meet the requirements of requirements of
[Regulation], Annex II & Annex III], for qualified electronic signatures and qualified
electronic seals.
2. The use of trusted channels (cf. FTP_TRP.1/Local & FTP_TRP.1/External).
3. The available key attributes, their possible values, and the meaning of each of these
values (cf. FMT_MSA.1/GenKeys and FMT_MSA.1/AKeys (all iterations)), including
their use to constrain the period and number of uses that are enabled by authorisation
of a key (cf. FIA_UAU.6/KeyAuth and Application Note 19 (PP)).
4. Identification of any non-endorsed cryptographic algorithms and/or cryptographic
functions that are available (cf. FCS_COP.1 (all iterations) and [PP_CMTS] section
1.3.1.3).
5. Identification of any other cryptographic algorithms and operations that are not included
in the scope of the Security Target.
6. Possible errors from the self-test process and the actions that should be taken in
response to each (cf. FPT_TST_EXT.1 & Application Note 32 (PP)).
7. Specific failures detected by the TOE (cf. FPT_FLS.1 & Application Note 35 (PP)).
8. Audit functions and their configuration (including specification of the available audit
records), along with any other actions that are associated with audit functions (e.g.
archiving or viewing audit records, or use of an external audit server) (cf. FAU_GEN.1
& Application Note 42 (PP), FAU_STG.2 & Application Note 41 (PP),
FMT_MTD.1/AuditLog & Application Note 39 (PP)).
9. Any configuration and operation requirements for dual-control operations (cf.
FDP_ACF.1/Backup).
10. If backup is provided by the TOE (cf. FDP_ACF.1/Backup), then the Operational
Guidance shall describe the backup and restore functions, and the administrator roles
that are required to carry them out.
11. If key import is provided by the TOE, then the Operational Guidance shall describe how
attributes are defined for any imported keys (cf. FMT_MSA.3/Keys). The evaluators
shall test the import process to demonstrate that the description in the Operational
Guidance is suitably complete, and that the keys imported have attributes appropriately
defined. Similarly, if key export is provided by the TOE then the Operational Guidance
shall describe whether attributes are exported with keys (and if so, then how the
attributes are represented and associated with the exported key), and the evaluators
Page 87 of 126
Security Requirements
shall test the export process to demonstrate that the description in the Operational
Guidance is suitably complete, and that the handling of attributes is as described.
12. The Operational Guidance must contain explicit guidance for the developer of an
internal SAM how to invoke the internal TOE interface without compromising the TOE
security functionality. It must be validated in the course of the eIDAS evaluation of the
SAM that the internal SAM follows all these rules.
Refinement:
The following specific topics must be addressed as part of the independent testing of the
TOE:
1. The evaluator shall execute the electronic signature and electronic seal operations
provided by the TOE and shall confirm that the signatures and seals returned by the
TOE correspond to the correct DTBS.
2. If software and/or firmware updates are supported by the TOE, then the evaluator shall
carry out tests to ensure that only updates with valid digital signatures can be installed
on the TOE.
Refinement:
Regarding the protection of the TOE against physical attacks: because of the requirement for
a physically secure environment with regular inspections (cf. OE.Env), the level of protection
(and hence resistance to attack potential) that is required by the implementation of
FPT_PHP.1 and FPT_PHP.3 for this TOE is equivalent to the level of assessment for this
aspect of tamper detection and response in section 7.7.2 Physical security general
requirements and section 7.7.3 Physical security requirements for each physical security
embodiment in ISO/IEC 19790:2012 for Security Level 3.
Page 88 of 126
Rationales
8 Rationales
OT.KeyUseScope
OT.TamperDetect
OT.PlainKeyConf
OT.FailureDetect
OE.AuditSupport
OE.ExternalData
OT.ImportExport
.OT.KeyIntegrity
OE.Datacontext
OE.AppSupport
OT.Algorthms
OT.DataConf
OT.DataMod
OT.Backup
OE.Uauth
OT.Audit
OT.RNG
OT.Auth
OE.Env
T.KeyDisclose X X X X X X X X
T.KeyDerive X X
T.KeyMod X X X X
T.KeyMisuse X X
T.KeyOveruse X
T.DataDisclose X X X
T.DataMod X X X
T.Malfunction X
P.Algorithm X
P.KeyControl X X X X X X X
P.RNG X
P.Audit X
A.ExternalData X
A.Env X
A.DataContext X
A.AppSupport X
A.UAuth X
A.AuditSupport X
Table 6: Security Problem Definition mapping to Security Objectives
Page 89 of 126
Rationales
8.1.2.1 Threats
T.KeyDisclose is addressed by the requirement in OT.PlainKeyConf to keep plaintext secret
keys unavailable, and this is supported in terms of controls over key attributes (which might
threaten the confidentiality of the key if modified) in OT.KeyIntegrity. The confidentiality of
secret keys that are exported is protected partly by the use of a secure channel as described
in OT.DataConf and the requirements for import and export in OT.ImportExport (including the
requirement to export secret keys only in encrypted form, or to be able to exclude the export
of a key entirely). Physical tamper protection of the keys is provided by OT.TamperDetect
(supported by an appropriate inspection procedure as required in OE.Env). Protection of
secret key confidentiality during backup is ensured by OT.Backup. The environment also
contributes to maintaining secret key confidentiality by protecting any versions of a secret
key that may exist outside the TOE, as in OE.ExternalData, and by protecting the operation
of the TOE itself by providing a secure environment, as in OE.Env.
T.KeyDerive is addressed by the choice of algorithms that have been endorsed for the
appropriate purposes, and this is described in OT.Algorithms. Where keys are generated by
the TOE then the use of a suitable random number generator is required by OT.RNG in order
to mitigate the risk that an attacker can guess or deduce the key value.
T.KeyMod is addressed by requiring integrity protection of secret and public keys, and their
critical attributes in OT.KeyIntegrity, and by requiring use of secure channels that protect
integrity if a key is imported or exported (OT.ImportExport). Protection of key integrity during
backup is ensured by OT.Backup. Physical tamper protection of the keys is provided by
OT.TamperDetect (supported by an appropriate inspection procedure as required in
OE.Env).
T.KeyMisuse raises the possibility of a secret key being used for an unintended and
unauthorised purpose, and is addressed by the requirement in OT.Auth for the TOE to carry
out an authorisation check before using a secret key. OT.KeyUseConstraint expands on this
to set out requirements for the granularity of authorisation.
T.KeyOveruse is concerned with the possibility that more uses may be made of an
authorised key than were intended, and this is addressed by the requirements of
OT.KeyUseScope which requires that the TOE allows a user to define specific values for the
number of uses, or the time period of use, of a key that an authorisation allows.
T.DataDisclose is concerned with the transmission of data between client applications and
the TOE, or between separate parts of the TOE where the transmission passes through an
insecure environment. This is addressed by OT.DataConf, which requires the TOE to provide
secure channels to protect such communications. The appropriate use of such channels is a
requirement for the environment as expressed in OE.DataContext, as is the use of
appropriate procedures in OE.AppSupport.
Page 90 of 126
Rationales
data that they carry. As with T.DataDisclose, the appropriate use of such channels is a
requirement for the environment as expressed in OE.DataContext, as is the use of
appropriate procedures in OE.AppSupport.
P.Audit requires the TOE to provide an audit trail and this is addressed directly by OT.Audit
(which includes protection of the audit records).
8.1.2.3 Assumptions
Each of the Assumptions in section 3.5 is directly matched by a security objective for the
operational environment in section 4.2. The wording of each objective for the operational
environment includes the wording of each assumption, and no further rationale is therefore
given here.
Page 91 of 126
Rationales
OT.KeyUseConstraint
OT.KeyUseScope
OT.TamperDetect
OT.PlainKeyConf
OT.FailureDetect
OT.ImportExport
OT.KeyIntegrity
OT.Algorithms
OT.DataConf
OT.DataMod
OT.Backup
OT.Audit
OT.RNG
OT.Auth
FCS_CKM.1//AES X
FCS_CKM.1//RSA X
FCS_CKM.1//ECDSA X
FCS_CKM.4 X
FCS_COP.1//AES_Encryption_CBC X
FCS_COP.1//AES_Encryption_OFB X
FCS_COP.1//AES_Decryption_CBC X
FCS_COP.1//AES_Decryption_OFB X
FCS_COP.1//AES_CMAC X
FCS_COP.1//AES_ECB X
FCS_COP.1//AES_GCM X
FCS_COP.1//RSA_Sign X
FCS_COP.1//RSA_Verify X
FCS_COP.1//RSA_Encryption X
FCS_COP.1//RSA_Decryption X
FCS_COP.1//ECDSA_Sign X
FCS_COP.1//ECDSA_Verify X
FCS_COP.1//HMAC X
FCS_COP.1//Hash X
FCS_COP.1//Diffie-Hellman X
FCS_COP.1//KeyDerivation X
FCS_RNG.1 X
Page 92 of 126
Rationales
OT.KeyUseConstraint
OT.KeyUseScope
OT.TamperDetect
OT.PlainKeyConf
OT.FailureDetect
OT.ImportExport
OT.KeyIntegrity
OT.Algorithms
OT.DataConf
OT.DataMod
OT.Backup
OT.Audit
OT.RNG
OT.Auth
FIA_UID.1 X
FIA_UAU.1//UserAuth X
FIA_UAU.1//KeyAuth X
FIA_AFL.1//UserAuth X
FIA_AFL.1//KeyAuth X
FIA_UAU.6/KeyAuth X X
FDP_IFC.1/KeyBasics X X X
FDP_IFF.1/KeyBasics X X X X
FDP_ACC.1/Key_Usage X X
FDP_ACF.1/KeyUsage X X
FDP_ACC.1/Backup X
FDP_ACF.1/Backup X
FDP_SDI.2 X
FDP_RIP.1 X X
FTP_TRP.1/LOCAL X X X X X
FTP_TRP.1/External X X X X X
FPT_STM.1 X
FPT_TST_EXT.1 X
FPT_PHP.1 X
FPT_PHP.3 X
FPT_FLS.1 X
FMT_SMR.1 X X
Page 93 of 126
Rationales
OT.KeyUseConstraint
OT.KeyUseScope
OT.TamperDetect
OT.PlainKeyConf
OT.FailureDetect
OT.ImportExport
OT.KeyIntegrity
OT.Algorithms
OT.DataConf
OT.DataMod
OT.Backup
OT.Audit
OT.RNG
OT.Auth
FMT_SMF.1 X X
FMT_MTD.1/Unblock//User X
FMT_MTD.1/Unblock//Key X
FMT_MTD.1/AuditLog X
FMT_MTD.1//SWUpdate X
FMT_MSA.1/GenKeys//AFlag X
FMT_MSA.1/GenKeys//ExportF X
FMT_MSA.1/GenKeys//AuthD X
FMT_MSA.1/GenKeys//None X
FMT_MSA.1/AKeys//AuthD X
FMT_MSA.1/AKeys//None X
FMT_MSA.3/Keys X
FAU_GEN.1 X
FAU_GEN.2 X
FAU_STG.2 X
OT.Algorithms is addressed by the need to use endorsed standards for FCS_COP.1 (cf.
Application Note 14 (PP)) and the use of an appropriate random number generator in
FCS_CKM.1. Note that the refinements to assurance components in section 7.4.1 also
specify requirements that ensure clear documentation of endorsed and non-endorsed
algorithms and functions provided by the TOE.
Page 94 of 126
Rationales
OT.Backup separates out the requirements for any backup and restore properties that the
TOE may provide and is addressed directly by the Backup SFP in FDP_ACC.1/Backup and
FDP_ACF.1/Backup.
Page 95 of 126
Rationales
OT.Audit is addressed in terms of basic creation of audit records by the requirements for
audit record generation in FAU_GEN.1 and FAU_GEN.2 and provision of timestamps for use
in audit records in FPT_STM.1. Protection of the audit trail is ensured by FAU_STG.2,
FMT_MTD.1/AuditLog and FMT_SMF.1. Support for the Administrator role that controls
export and deletion of audit records from the TOE is required by FMT_SMR.1.
4.
[FDP_ITC.1 Import of user data without FCS_CKM.1//AES
FCS_CKM.4
security attributes, or FCS_CKM.1//RSA
FDP_ITC.2 Import of user data with
FCS_CKM.1//ECDSA
security attributes, or
FCS_CKM.1 Cryptographic key
generation]
5.
[FDP_ITC.1 Import of user data without FCS_CKM.1//AES
FCS_COP.1//AES_
security attributes, or FCS_CKM.4
Encryption_CBC
FDP_ITC.2 Import of user data with
security attributes, or
FCS_CKM.1 Cryptographic key
generation]
FCS_CKM.4 Cryptographic key
destruction
6.
[FDP_ITC.1 Import of user data without FCS_CKM.1//AES
FCS_COP.1//AES_
security attributes, or FCS_CKM.4
Encryption_OFB
FDP_ITC.2 Import of user data with
Page 96 of 126
Rationales
Page 97 of 126
Rationales
Page 98 of 126
Rationales
Page 99 of 126
Rationales
30.
FDP_IFC.1 Subset information flow FDP_IFC.1/ KeyBasics
FDP_IFF.1/KeyBas
control FMT_MSA.3/Keys
ics
FMT_MSA.3 Static attribute initialisation
31.
FDP_ACF.1 Security attribute based FDP_ACF.1/KeyUsage
FDP_ACC.1/Key_U
access control
sage
32.
FDP_ACC.1 Subset access control FDP_ACC.1/KeyUsage
FDP_ACF.1/KeyUs
FMT_MSA.3 Static attribute initialisation FMT_MSA.3/Keys
age
33.
FDP_ACF.1 Security attribute based FDP_ACF.1/Backup
FDP_ACC.1/Backu
access control
pl
34.
FDP_ACC.1 Subset access control FDP_ACC.1/Backup
FDP_ACF.1/Backu
FMT_MSA.3 Static attribute initialisation The dependency on
p
FMT_MSA.3 is not
relevant in this case
since the attribute used
in FDP_ACF.1/Backup
is determined by the
ability of the user to
authenticate as an
administrator according
to
FIA_UAU.1//UserAuth.
35. FDP_SDI.2 No dependencies n.a.
46.
FMT_SMR.1 Security roles FMT_SMR.1
FMT_MTD.1/Unblo
FMT_SMF.1 Specification of Management FMT_SMF.1
ck//User
Functions
47.
FMT_SMR.1 Security roles FMT_SMR.1
FMT_MTD.1/Unblo
FMT_SMF.1 Specification of Management FMT_SMF.1
ck//Key
Functions
48.
FMT_SMR.1 Security roles FMT_SMR.1
FMT_MTD.1/AuditL
FMT_SMF.1 Specification of Management FMT_SMF.1
og
Functions
49.
FMT_SMR.1 Security roles FMT_SMR.1
FMT_MTD.1//SWU
FMT_SMF.1 Specification of Management FMT_SMF.1
pdate
Functions
50.
FDP_ACC.1 Subset access control, or FDP_ACC.1/Key_Usage
FMT_MSA.1/GenK
FDP_IFC.1 Subset information flow FDP_IFC.1/KeyBasics
eys (all iterations)
control] FMT_SMR.1
FMT_SMR.1 Security roles FMT_SMF.1
FMT_SMF.1 Specification of Management
Functions
51.
FDP_ACC.1 Subset access control, or FDP_ACC.1/Key_Usage
FMT_MSA.1/AKeys
FDP_IFC.1 Subset information flow FDP_IFC.1/KeyBasics
(all iterations)
control] FMT_SMR.1
FMT_SMR.1 Security roles FMT_SMF.1
FMT_SMF.1 Specification of Management
Functions
FMT_MSA.1 Management of security FMT_MSA.1/GenKeys (all
52. FMT_MSA.3/Keys
attributes iterations)
FMT_SMR.1 Security roles
FMT_MSA.1/AKeys (all
iterations)
FMT_SMR.1
54.
FAU_GEN.1 Audit data generation FAU_GEN.1
FAU_GEN.2
FIA_UID.1 Timing of identification FIA_UID.1
55.
FAU_GEN.1
FAU_STG.2 FAU_GEN.1 Audit data generation
Key attributes during import or export: the TOE may allow import or export of keys according
to the rules in FDP_IFF.1/KeyBasics. For keys that may be imported or exported, the TOE
does not place any specific requirements on whether attributes are imported and exported
with keys. However, the refinement to AGD_OPE.1 in section 7.4.1 requires that the
behaviour of the TOE in this situation is described in documentation, and that the evaluators
confirm the behaviour that is documented. Application Note 41 (PP) (for FMT_MSA.1) also
requires that the initialisation of any attributes on import is described in the Security Target.
secure channel; hence, each authenticated user can in addition assume the role
Non-internal Local Client Application
o Internal SAM: Internal Local Client Application that invokes the internal TOE
interface. It is authenticated by signature verification when initially loaded to the
CryptoServer and integrity protected by the physical boundary of the TOE and
therefore does not need to establish a cryptographically protected secure
channel.
At registration, for every user a dedicated authentication mechanism has to be chosen. The
TOE provides two different user authentication mechanisms:
RSA Signature authentication mechanism: The authentication is performed with an RSA
signature (RSA signature scheme RSASSA-PKCS1-v1_5 according to the standard
[PKCS#1], chapter 8.2.1, with key lengths of minimum 2048 and maximum 8192 bit modulus
lengths).
HMAC Password authentication mechanism: For this mechanism a password is used.
First the host running the application software demands a 16-byte random value (challenge)
from the TOE. Then the host calculates the HMAC value over this challenge and the
command data block using the user’s authentication password as the HMAC key.
Furthermore, for Internal SAM the following authentication mechanism is provided:
Module Signature authentication mechanism: The authentication is performed with the
help of an RSA signature (PKCS#1 signature according to the standard [PKCS#1],) which
has to be calculated over the firmware module with the dedicated CryptoServer CP5 Module
Signature Key owned by the manufacturer.
After five unsuccessful user authentication attempts the corresponding user is blocked. Any
additional attempt of this user to authenticate towards the TOE will fail. Thus
SF.USER_AUTH supports FIA_AFL.1//UserAuth (Authentication failure handling). A blocked
user can only be unblocked by a User Administrator, hence fulfilling
FMT_MTD.1/Unblock//User.
For exchanging sensitive data, a Secure Messaging session (trusted channel) has to be set
up between the TOE and the (local non-internal or remote external) client application. Such a
Secure Messaging session is mandatory for each command which requires user
authentication. Here, although they may run in different environments, for local non-internal
client applications and remote external client applications the identically same trusted
communication mechanism is enforced by SF.USER_AUTH, fulfilling the SFRs
FTP_TRP.1/Local (Trusted Path) as well as FTP_TRP.1/External (Trusted Path).
SF.CRYPTO supports the user authentication and secure messaging with RSA signature
generation and verification, hash value calculation, key derivation, HMAC calculation, Diffie-
Hellman key agreement, AES encryption, AES decryption, MAC-calculation and random
number generation by hybrid RNG for the challenge value.
The key authorisation is not possible without former user authentication. Only if a defined
authentication status (e.g. authentication for the Key User role or the Key Manager role) has
been obtained, the key authorisation can be realised. Thus, this security function is related to
SF.USER_AUTH.
In addition to user authentication, key authorisation to access a secret or private key has to
be performed before a key can be used by a cryptographic function or before a key can be
exported, implementing in particular FDP_ACF.1.2/KeyUsage (2), FIA_UAU.1//KeyAuth and
FDP_ACC.1/KeyUsage. A key can be authorised for a defined number of usage access
operations, or for infinite use (until rescinding).
After five unsuccessful key authorisation attempts the corresponding key is blocked. Any
additional attempt for key authorisation for this specific key will fail. Thus, SF.KEY_AUTH
supports FIA_AFL.1//KeyAuth (Authentication failure handling). A blocked key can only be
unblocked by a Key Manager, hence fulfilling FMT.MTD.1/Unblock//Key.
The authorisation for access to a secret or private key stays valid until either the key
authorisation is explicitly rescinded with a dedicated command to end the previous key
authorisation, or until the defined number of access trials has been reached, implementing
FIA_UAU.6/KeyAuth (Re-authenticating). Key authorisation is also lost in case of reset or
power-cycle of the TOE.
SF.KEY_AUTH furthermore implements all rules defined in FDP_ACF.1/KeyUsage (Security
attribute based Access Control) for the users that shall be able to change key security
attributes.
The SAEK signature interface allows an Internal SAM application to request usage of a
signature key for which the TOE will not check the key authorisation. As a consequence, the
internal SAM calling the SAEK signature interface takes full responsibility on correct
legitimation of this operation, including key authorisation as required by [PP_CMTS]: As
mandated by TOE Guidance, an Internal SAM will only invoke the SAEK signature interface
if it has completely validated key authorisation of the signature key before. Therefore, the
TOE can implicitly derive prior successful key authorisation of the signature key from each
invocation of the SAEK signature interface.
Unblock of user accounts due to authentication failures in accordance with the SFR
FMT_MTD.1/Unblock//User
Unblock of cryptographic keys due to key authorisation failures in accordance with
the SFR FMT_MTD.1/Unblock//Key
Export of General (non-Assigned) keys in accordance with FDP_IFC.1 and
FDP_IFF.1 (and iterations)
Modifications of key attributes by authorised subjects in accordance with FDP_ACF.1
(and iterations)
System time setting to support FPT_STM.1.
The export and deletion of the audit log is performed in accordance with
FMT_MTD.1/AuditLog.
Software Update in accordance with the SFR FMT_MTD.1//SWUpdate.
For the user administration typical functions are available. Basically, the service deals with
administration of the user database (creation, deletion, changing). The commands for
creation or deletion of a user have to be authenticated by a user in User Administrator role.
The command for changing the user’s authentication token (password or public key) has to
be authenticated by the respective user himself.
FDP_ACF.1/KeyUsage (Security attribute based Access Control) enforces the Key Usage
SFP to authenticated users who are currently authorised to change attributes of secret key.
Management of security attributes of General keys and Assigned keys is performed in
accordance with FMT_MSA.1/GenKeys (Management of security attributes of General keys,
all iterations), FMT_MSA.1/AKeys (Management of security attributes of Assigned keys, all
iterations) and FMT.MSA.3/Keys (Static attribute initialisation)
SF.REL provides a service to query the audit records, this service has to be authenticated by
a user in Administrator, User Administrator, Key Manager or Security Officer role, in
accordance with FMT_MTD.1/AuditLog (Management of TSF data). The TOE does not
provide any possibility to modify the audit records except for entire clearance, whereby the
service for the clearance of the audit data has to be authenticated by a user in Administrator
or User Administrator role, in accordance with the SFRs FAU_STG.2 (Guarantees of audit
data availability) and FMT_MTD.1/AuditLog (Management of TSF data).
SF.REL preserves a secure operation state of the TOE when the following types of failures
and attacks occur:
Power supply too high/too low
Temperature too high/too low
Integrity check of cryptographic keys and stored firmware modules
Self-test fails
The TOE provides an alarm mechanism which detects physical environmental failure attacks
and reacts by destroying all sensitive data. For this mechanism a sensory is implemented
which watches temperature and voltage.
Furthermore, the TOE with its tamper-evident enclosure (the heat sink and the potting
material) implements the following physical security mechanisms against direct physical
attacks:
The cryptographic module’s hardware components are covered by hard, opaque
potting material or the heat sink, which show evidence of tampering on the enclosure
when a physical attack is attempted. This provides the capability to determine
physical tampering according to FPT_PHP.1 (Passive detection of physical attack).
The potting material is hard and opaque enough to prevent direct observation and
easy penetration to the depth of the underlying hardware components. It is highly
probable that anyone attempting to penetrate to the depth of the circuitry will break off
large pieces of potting material and tear important hardware components off the
module, causing serious damage to the TOE.
The tamper response and zeroisation circuitry is active while module is in standby mode
(powered down).
The implemented sensory and software part of the TOE react properly to all security relevant
events being generated by the hardware in response to any physical attack attempts. The
resistance of the TOE hardware and sensory to physical and chemical attacks has been
evaluated and successfully certified according to the requirements of FIPS 140-2 standard,
level 3. This is equivalent to the physical security requirements as laid down in ISO/IEC
19790:2012 for Security Level 3, sections 7.7.2 and 7.7.3. Therefore, the security function
SF.REL supplies effective hardware and software based mechanisms satisfying the SFR
FPT_PHP.3 (Resistance to physical attack).
Due to the implemented alarm mechanism the TOE preserves a secure state also if the
power supply or temperature is outside of a well-defined operational range: If extreme power
levels occur to the TOE or if extreme temperature is monitored, an alarm is triggered, all data
is deleted and the TOE will be reset cleanly according to FPT_FLS.1 (Failure with
preservation of secure state). The security function SF.REL realises effective hardware and
software based features to preserve a secure operational state of the TOE in case of induced
hardware or software failures or tampering. It satisfies directly the SFR FPT_FLS.1.
For the protection of data and firmware integrity the security function SF.REL implements
various measures:
During the boot process after power-on or reset the TOE’s boot loader and operating system
SMOS perform further self-tests, like a memory RAM test. SMOS loads and initialises all
remaining firmware modules and performs further self-tests in accordance with
FPT_TST_EXT.1 (Basic TSF self-testing).
a)
It is only possible to execute any cryptographic or other security-relevant service after these
power-on self-tests have been completed successfully. If one of these power-on self-tests
fails, the TOE enters the secure Error State.
The TOE performs the following self-tests at specific conditions in accordance with
FPT_TST_EXT.1 (Basic TSF self-testing):
a) Online Test of the digitised noise data of the PTRNG
b) Continuous DRNG tests (whenever random bytes are requested)
c) ECDSA Key Pair-wise Consistency Test (sign/verify) for any newly generated or
imported ECDSA key pair according to FIPS 140-2 §4.9.2
d) RSA Key Pair-wise Consistency Tests (encrypt/decrypt and sign/verify) for any newly
generated RSA key pair according to FIPS 140-2 §4.9.2
e) Firmware Load Test (via RSA signature verification) for every firmware module when
being loaded
If one of these conditional self-tests fails, the requested action is not performed (e. g.
firmware module to be loaded is not loaded, generated key is not stored etc.), and the
command is aborted with an error code. The successful completion of all self-tests or the
secure Error State is indicated by the “Get State” command.
Secret or private keys are deleted in accordance with the SFR FCS_CKM.4 (Cryptographic
key destruction). SF.REL ensures that any previous information content is not available after
deletion.
SF.REL monitors stored data and prohibits usage of altered data and notifies the user if
integrity errors are detected in accordance to FDP_SDI.2.
The mechanism used for fulfilling FCS_CKM.4 for key destruction, namely overwriting the
key by zeroising in case of secret or private keys, applies to all secret and private keys and
data, and therefore also ensures that any previous information content of a resource is made
unavailable upon the de-allocation of authorisation data and secret keys, which is in
accordance to FDP_RIP.1.
The “Load File” service allows the download of firmware modules only in a dedicated format
which contains also a signature calculated over the executable code (RSA signature
according to [PKCS#1], with a key length of 4096 bit according to FCS_COP.1//RSA_Verify).
The signature has to be calculated with a dedicated Module Signature Key owned by the
manufacturer. If the signature cannot be verified, the download is prohibited and the “Load
File” service will return an error code instead. If the set of loaded firmware modules is
incomplete or in any way not compliant to the software that is released for this project, the
TOE will be set to a secure Error State.
In this Error State no cryptographic operations are available, only status requests can be
performed.
SF.SWUPDATE
SF.KEY_AUTH
SF.KEY_MAN
SF.CRYPTO
SFR
SF.ADMIN
SF.REL
FCS_CKM.1//AES X X
(Cryptographic key generation)
SF.USER_AUTH
SF.SWUPDATE
SF.KEY_AUTH
SF.KEY_MAN
SF.CRYPTO
SFR
SF.ADMIN
SF.REL
FCS_CKM.1//RSA X X
(Cryptographic key generation)
FCS_CKM.1//ECDSA X X
(Cryptographic key generation)
FCS_CKM.4 X X
(Cryptographic key destruction)
FCS_COP.1//AES_Encryption_CBC X
(Cryptographic operation)
FCS_COP.1//AES_Encryption_OFB X
(Cryptographic operation)
FCS_COP.1//AES_Decryption_CBC X
(Cryptographic operation)
FCS_COP.1//AES_Decryption_OFB X
(Cryptographic operation)
FCS_COP.1//AES_CMAC X
(Cryptographic operation)
FCS_COP.1//AES_ECB X
(Cryptographic operation)
FCS_COP.1//AES_GCM X
(Cryptographic operation)
FCS_COP.1//RSA_Sign X
(Cryptographic operation)
FCS_COP.1//RSA_Verify X X
(Cryptographic operation)
FCS_COP.1//RSA_Encryption X
(Cryptographic operation)
FCS_COP.1//RSA_Decryption X
(Cryptographic operation)
FCS_COP.1//ECDSA_Sign X
(Cryptographic operation)
SF.USER_AUTH
SF.SWUPDATE
SF.KEY_AUTH
SF.KEY_MAN
SF.CRYPTO
SFR
SF.ADMIN
SF.REL
FCS_COP.1//ECDSA_Verify X
(Cryptographic operation)
FCS_COP.1//HMAC X
(Cryptographic operation)
FCS_COP.1//Hash X
(Cryptographic operation)
FCS_COP.1//Diffie-Hellman X
(Cryptographic operation)
FCS_COP.1//KeyDerivation X
(Cryptographic operation)
FCS_RNG.1 X
(Generation of random numbers)
FIA_UID.1 X
(Timing of identification)
FIA_UAU.1//UserAuth X
(Timing of Authentication)
FIA_UAU.1//KeyAuth X
(Timing of Authentication)
FIA_AFL.1//UserAuth X
(User Authentication failure handling)
FIA_AFL.1//KeyAuth X
(Key Authorisation failure handling)
FIA_UAU.6/KeyAuth X
(Re-authentication)
FDP_IFC.1/KeyBasics X
(Subset Information Control)
FDP_IFF.1/KeyBasics X X
(Simple security attributes)
FDP_ACC.1/Key_Usage X X X
(Subset access control)
SF.USER_AUTH
SF.SWUPDATE
SF.KEY_AUTH
SF.KEY_MAN
SF.CRYPTO
SFR
SF.ADMIN
SF.REL
FDP_ACF.1/KeyUsage X X X
(Security attrib. based access control)
FDP_ACC.1/Backup X
(Security attrib. based access control)
FDP_ACF.1/Backup X X
(Security attrib. based access control)
FDP_SDI.2 X
(Stored data integrity monitoring/action)
FDP_RIP.1 X
(Subset residual information protection)
FTP_TRP.1/Local X
(Trusted path)
FTP_TRP.1/External X
(Trusted path)
FPT_STM.1 X X
(Reliable time stamps)
FPT_TST_EXT.1 X
(Basic TSF self testing)
FPT_PHP.1
X
(Passive detection of physical attack)
FPT_PHP.3
X
(Resistance to physical attack)
FPT_FLS.1
X
(Failure with preservation of secure state)
FMT_SMR.1
X X X
(Security roles)
FMT_SMF.1
X X
(Security management functions)
FMT_MTD.1/Unblock//User
X X
(Management of TSF Data)
SF.USER_AUTH
SF.SWUPDATE
SF.KEY_AUTH
SF.KEY_MAN
SF.CRYPTO
SFR
SF.ADMIN
SF.REL
FMT_MTD.1/Unblock//Key
X X
(Management of TSF Data)
FMT_MTD.1/AuditLog
X X
(Management of TSF Data)
FMT_MTD.1//SWUpdate
X X
(Management of TSF Data)
FMT_MSA.1/GenKeys//AFlag
X
(Management of security attributes)
FMT_MSA.1/GenKeys//ExportF
X
(Management of security attributes)
FMT_MSA.1/GenKeys//AuthD
X
(Management of security attributes)
FMT_MSA.1/GenKeys//None
X
(Management of security attributes)
FMT_MSA.1/AKeys//AuthD
X
(Management of security attributes)
FMT_MSA.1/AKeys//None
X
(Management of security attributes)
FMT_MSA.3/Keys
X
(Static attribute initialisation)
FAU_GEN.1 X
(Audit data generation)
FAU_GEN.2 X
(Identity association)
FAU_STG.2 X
(Guarantees of audit data availability)
Table 9: Mapping SFRs to Security Functions
10 Annex
This Annex contains the following sections:
Glossary and Acronyms
References
Authentication keys General term for keys used for authentication of data (i.e. Data
authentication keys) or the identity of an entity (i.e. Entity
authentication keys)
Term Description
Data path The physical or logical route over which data passes; a physical
data path may be shared by multiple logical data paths.
Decryption algorithm Algorithm of decoding a cipher text into the plaintext using a
decryption key. The decryption algorithm reproduces the plaintext
that is used to calculate the cipher text with the corresponding
encryption algorithm and the corresponding encryption key.
Term Description
Encrypted key A cryptographic key that has been encrypted using an Endorsed
security function with a key encrypting key, a PIN, or a password
in order to disguise the value of the underlying plaintext key.
Endorsed For this security target, endorsed by the certification body for the
evaluation of products of an intended type and resistance against
attacks with attack potential addressed by the vulnerability
analysis component in the security target209.
Endorsed security For this security target, a security function (e.g., cryptographic
function algorithm, cryptographic key management technique, or
authentication technique) that is either a) specified in an Endorsed
standard, b) adopted in an Endorsed standard and specified either
in an appendix of the Endorsed standard or in a document
referenced by the Endorsed standard, or c) specified in the list of
Endorsed security functions.
Error detection code A code computed from data and comprised of redundant bits of
(EDC) information designed to detect, but not correct, unintentional
changes in the data.
209 Endorsed algorithms and functions could be similar to the list of cryptographic algorithms and
parameters published for qualified electronic signatures by the notified body Bundesnetzagentur in
Germany, the agreed cryptographic mechanisms from [SOG-IS-Crypto], or the Approved algorithms
published by NIST in the USA.
Term Description
Input data Information that is entered into a cryptographic module for the
purposes of transformation or computation using an Endorsed
security function.
Integrity The property that sensitive data has not been modified or deleted
in an unauthorised and undetected manner.
Internal secrets Confidential data inside the cryptographic boundary not intended
for export (e.g. secret or private plaintext keys, authentication
reference data).
Internal TOE Internal interface which is provided by the TOE and which can only
interface be accessed by firmware modules running within the physical
boundary of the TOE. It is intended to be used by an internal SAM.
Key establishment The process by which cryptographic keys are securely distributed
among cryptographic modules using manual transport methods
(e.g., key loaders), automated methods (e.g., key transport and/or
key agreement protocols), or a combination of automated and
manual methods (consists of key transport plus key agreement).
Key management The activities involving the handling of cryptographic keys and
other related security parameters (e.g., IVs and passwords) during
the entire life cycle of the keys, including their generation, storage,
establishment, entry and output, and destruction.
Key usage type Type of cryptographic algorithm a key can be used for (e.g. AES
encryption, RSA signature-creation)
Term Description
Logical external A logical entry or exit point of a cryptographic module that provides
interface access to the module for logical information flows representing
physical signals (see also the term “port” for the physical aspects
of a logical external interface). In the CC terminology it covers all
logical external interfaces of the TOE (direct or indirect interfaces
to the TSF or interfaces to the non-TSF portion of the TOE).
Permanent stored Keys remains stored in the TOE after power off or reset.
keys
Power interface/port Interface respective port providing all external electrical power
supply.
Term Description
Power On/Off mode Mode of operation that indicates whether the cryptographic module
is supplied by a power source. These modes may distinguish
between different power sources (e.g., primary, secondary, backup
power source or none) being applied to a cryptographic module.
Power On/Off state State related to the Power On/Off mode (cf. ADV_ARC.1).
Public key A cryptographic key used with a public key cryptographic algorithm
that is uniquely associated with an entity and that may be made
public.
Public key A cryptographic algorithm that uses two related keys, a public key
(asymmetric) and a private key. The two keys have the property that deriving the
cryptographic private key from the public key is computationally infeasible.
algorithm
Public key certificate A set of data that uniquely identifies an entity, contains the entity’s
public key, and is digitally signed by a trusted party, thereby
binding the public key to the entity.
Reference Data known for the claimed identity and used by the TOE to verify
authentication data the verification authentication data provided by an entity in an
authentication attempt to prove their identity.
Reset Action to clear any pending errors or events and to bring a system
to normal condition or initial state (e.g. after power-on).
Term Description
SAEK signature Part of the internal TOE interface using SAM Authorised External
interface Keys. This interface for signature calculation is intended to be
used by an internal SAM which itself validates key authorisation.
See Application Note 1 (ST).
Secret key A cryptographic algorithm the keys of which for both encryption
(symmetric) and decryption respective MAC calculation and MAC verification
cryptographic are the same or can easily be derived from each other and
algorithm therefore must be kept secret.
Shutdown Shutdown of the TOE initiated by the user (may not include reset
after detection of error or power-off due to loss of power supply)
Split knowledge A process by which a cryptographic key is split into multiple key
components, individually sharing no knowledge of the original key,
that can be subsequently input into, or output from, a
cryptographic module by separate entities and combined to
recreate the original cryptographic key.
Status information Information that is output from a cryptographic module for the
purposes of indicating certain operational characteristics or modes
of the module.
Term Description
Status output Interface respective port intended for all input commands, signals,
interface/port and control data (including calls and manual controls such as
switches, buttons, and keyboards) used to control the operation of
the cryptographic module).
System software The special software within the cryptographic boundary (e.g.,
operating system, compilers or utility programs) designed for a
specific computer system or family of computer systems to
facilitate the operation and maintenance of the computer system,
and associated programs, and data.
Trusted channel A means by which a TSF and a remote trusted IT product can
communicate with necessary confidence to support the TSF.
Trusted path A means by which a user and a TSF can communicate with
necessary confidence to support the TSF.
User Any entity (human user or external IT entity) outside the TOE that
interacts with the TOE (includes both authenticated and
unauthenticated entities).
The following table includes all used acronyms of this Security Target regarding to the
Common Criteria and IT technology terms in alphabetical order.
Acronym Term
Common Criteria
CC Common Criteria
n. a. Not applicable
Cryptographic Algorithms
RSA RSA stands for Rivest, Shamir and Adleman. RSA is an asymmetric
cryptographic algorithm for public-key cryptography that is based on
the presumed difficulty of factoring large integers, the factoring
problem.
IT technology terms
10.2 References
[AIS 20/31] Application Notes and Interpretation of the Scheme (AIS): AIS 20/AIS
31: A proposal for: Functionality classes for random number generators,
Version 2.0 / Wolfgang Killmann (T-Systems GEI GmbH, Bonn), Werner
Schindler (Bundesamt für Sicherheit in der Informationstechnik/BSI,
Bonn), 18. September 2011
[ANSI-X9.31] ANS X9.31-1998: Digital Signatures Using Reversible Public Key
Cryptography for the Financial Services Industry (rDSA) /
ANSI (American National Standards Institute)
[ANSI-X9.62] ANS X9.62-2005: Public Key Cryptography for the Financial Services
Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA) ANSI
(American National Standards Institute)
[CC1] Common Criteria for Information Technology Security Evaluation, Part
1: Introduction and General Model; CCMB-2012-09-001, Version 3.1,
Revision 4, September 2012
[CC2] Common Criteria for Information Technology Security Evaluation,
Part 2: Security functional components; CCMB-2012-09-002, Version
3.1, Revision 4, September 2012
[CC3] Common Criteria for Information Technology Security Evaluation,
Part 3: Security assurance components; CCMB-2012-09-003, Version
3.1, Revision 4, September 2012
[CEM] Common Methodology for Information Technology Security Evaluation,
CCMB-2012-09-004, Version 3.1, Revision 4, September 2012
[ECCBP] ECC Brainpool Standard Curves and Curve Generation, v1.0,
19.10.2005 / ECC Brainpool, http://www.ecc-brainpool.org/ecc-
standard.htm
[FIPS 140-2] FIPS PUB 140-2, Security Requirements for Cryptographic Modules /
National Institute of Standards and Technology (NIST), USA, May 2001
[FIPS 180-4] FIPS PUB 180-4, Secure Hash Standard (SHS) / National Institute of
Standards and Technology (NIST), USA, March 2012
[FIPS 186-4] FIPS PUB 186-4, Digital Signature Standard / National Institute of
Standards and Technology (NIST), USA, July 2013
[FIPS 197] FIPS PUB 197, Advances Encryption Standard (AES) / National
Institute of Standards and Technology (N11IST), USA, 26th November
2001
[FIPS 198] FIPS PUB 198, The Keyed-Hash Message Authentication Code
(HMAC) / National Institute of Standard and Technology (NIST), USA,
6th March 2002
[FIPS 202] FIPS PUB 202 (Federal Information Processing Standards Publication)
– SHA-3 Standard: Permutation-Based Hash and Extendable-Output
Functions / National Institute of Standards and Technology (NIST),
August 2015