Certified CA Kernel SC
Security Target
Version 3.3.4, Feb, 20th
, 2024
Certification-ID: BSI-DSZ-CC-1216
secunet Security Networks AG
2
Contents
Contents................................................................................................................................ 2
Figures .................................................................................................................................. 6
Tables ................................................................................................................................... 7
1 INTRODUCTION ........................................................................................................... 9
1.1 ST reference and TOE reference......................................................................... 9
1.2 TOE overview...................................................................................................... 9
1.2.1 TOE definition and operational usage .................................................... 9
1.2.1.1 Cryptographic functionality................................................................... 10
1.2.1.2 CRL and OCSP ................................................................................... 12
1.2.2 TOE major security features for operational use .................................. 12
1.2.3 Required non-TOE hardware /software/firmware ................................. 12
1.2.3.1 CA-Server............................................................................................ 12
1.2.3.2 Operating system................................................................................. 13
1.2.3.3 JVM ..................................................................................................... 13
1.2.3.4 Adapter................................................................................................ 13
1.3 Conventions ...................................................................................................... 13
2 TOE DESCRIPTION .................................................................................................... 14
2.1 Physical scope of the TOE ................................................................................ 14
2.2 Logical scope of the TOE .................................................................................. 14
2.2.1 CA-Core............................................................................................... 15
2.2.1.1 CA-Core Interface to the cryptographic implementation in the environment
............................................................................................................ 15
2.2.1.2 CA-Core Interface to the Adapter......................................................... 16
2.2.2 Challenge Request and Response....................................................... 16
2.2.3 User Authorization and Challenge Verification ..................................... 16
2.2.4 Configuration Security.......................................................................... 16
2.2.5 Profile Validation and Certificate/CRL generation ................................ 17
2.2.6 Audit .................................................................................................... 17
2.3 CIMC Intended Environment.............................................................................. 18
2.4 CIMC Keys ........................................................................................................ 18
2.4.1 Cryptographic Functions Involving Private or Secret Keys ................... 18
2.5 Data Input.......................................................................................................... 19
3
2.6 Trusted Public Key Entry, Deletion, and Storage................................................ 19
2.7 Bootstrapping .................................................................................................... 19
3 Conformance Claim ..................................................................................................... 20
3.1 CC Conformance Claim..................................................................................... 20
3.2 PP Claim ........................................................................................................... 20
3.3 Package Claim .................................................................................................. 20
3.4 CC Conformance Claim Rationale..................................................................... 20
3.4.1 PP conformance .................................................................................. 20
4 SECURITY PROBLEM DEFINITION............................................................................ 21
4.1 Assets ............................................................................................................... 21
4.2 Subjects/External Entities.................................................................................. 21
4.3 Secure Usage Assumptions............................................................................... 22
4.4 Threats.............................................................................................................. 23
4.5 Organization Security Policies............................................................................ 24
5 SECURITY OBJECTIVES............................................................................................ 25
5.1 Security Objectives for the TOE ......................................................................... 25
5.2 Security Objectives for the Environment............................................................. 26
6 Extended Components Definition................................................................................. 29
7 TOE SECURITY FUNCTIONAL REQUIREMENTS...................................................... 30
7.1 Security Audit .................................................................................................... 31
7.2 Roles................................................................................................................. 35
7.3 Access Control .................................................................................................. 36
7.4 Identification and authentication......................................................................... 39
7.5 Remote Data Entry and Export .......................................................................... 40
7.5.1 Certificate Status Export ...................................................................... 41
7.6 Key Management .............................................................................................. 42
7.6.1 Public Key Storage .............................................................................. 42
7.6.2 Private and Secret Key Destruction ..................................................... 42
7.6.3 Cryptographic operation of the TOE..................................................... 42
7.7 Certificate Profile Management.......................................................................... 43
4
7.8 Certificate Revocation List Profile Management................................................. 44
7.9 Certificate Registration ...................................................................................... 45
7.10 Certificate Revocation........................................................................................ 46
7.10.1 Certificate Revocation List Validation................................................... 46
8 TOE SECURITY ASSURANCE REQUIREMENTS....................................................... 47
9 RATIONALE ................................................................................................................ 48
9.1 Security Objectives Rationale ............................................................................ 48
9.1.1 Security Objectives Sufficiency............................................................ 50
9.1.1.1 Threats and Objectives Sufficiency...................................................... 51
9.1.1.2 Policies and Objectives Sufficiency...................................................... 56
9.1.1.3 Assumptions and Objectives Sufficiency.............................................. 56
9.2 Security Requirements Rationale....................................................................... 58
9.2.1 Security Requirements Coverage ........................................................ 58
9.2.2 Security Requirements Sufficiency....................................................... 59
9.2.2.1 Security Objectives for the TOE........................................................... 59
9.3 Requirement Dependency Rationale ................................................................. 61
9.3.1 Rationale that Dependencies are satisfied........................................... 61
9.3.1.1 Security Functional Requirements Dependencies................................ 61
9.4 Extended Requirements Rationale..................................................................... 63
10 ACCESS CONTROL POLICIES................................................................................... 64
10.1 CIMC TOE Access Control Policy ...................................................................... 64
11 TOE Summary Specification ........................................................................................ 65
11.1 TOE security functionality.................................................................................. 65
11.1.1 SF1 Security Audit ............................................................................... 65
11.1.1.1 SF1.1 Audit message generation......................................................... 65
11.1.1.2 SF1.2 Audit trail protection................................................................... 65
11.1.2 SF2 Management of the TSF............................................................... 67
11.1.3 SF3 Data Authenticity and Authorization.............................................. 67
11.1.3.1 SF3.1 Challenge Request and Response ............................................ 67
11.1.3.2 SF3.2 Remote Data entry Verification, Authorization and Challenge
Verification........................................................................................... 67
11.1.4 SF4 Certificate and Certificate Status management............................. 68
11.1.4.1 SF4.1 Certificate Generation................................................................ 68
11.1.4.2 SF4.2 Certificate Revocation ............................................................... 68
11.1.4.3 SF4.3 Certificate Status Export............................................................ 68
11.1.5 SF5 Access Control ............................................................................. 68
5
11.1.6 SF6 Cryptographic Key Management .................................................. 69
11.2 Fulfilling the security functional requirements......................................................... 69
12 GLOSSARY OF TERMS .............................................................................................. 70
Appendix...................................................................................................................... 73
13.1 Audit record....................................................................................................... 73
13.2 Trail header ....................................................................................................... 73
13.3 Trail footer......................................................................................................... 73
14 ACRONYMS................................................................................................................ 74
15 References .................................................................................................................. 75
6
Figures
Figure 1: TOE boundary................................................................................................................. 15
7
Tables
Table 1 Cryptographic Algorithms of the CA card ............................................................................. 10
Table 3 Cryptographic Algorithms of the TOE .................................................................................. 10
Table 4 supported elliptic curves...................................................................................................... 11
Table 5 Scope of TOE delivery........................................................................................................ 14
Table 6 CIMC TOE Functional Security Requirements....................................................................... 30
Table 7 Auditable Events and Audit Data.......................................................................................... 32
Table 8 Authorized Roles for Management of Security Functions Behavior .......................................... 35
Table 9 Access Controls ................................................................................................................. 37
Table 10 Assurance Requirements.................................................................................................... 47
Table 11 Relationship of Security Objectives for the TOE to Threats.................................................... 48
Table 12 Relationship of Security Objectives for the Environment to Threats ........................................ 49
Table 13 Relationship of Organizational Security Policies to Security Objectives .................................. 50
Table 14 Relationship of Assumptions to IT Security Objectives ......................................................... 50
Table 15 Security Functional Requirements Related to Security Objectives........................................... 58
Table 16 Summary of Security Functional Requirements Dependencies................................................ 61
Table 17 Audit trail protection during operation................................................................................. 66
Table 18 Audit trail protection on a regular shutdown......................................................................... 66
8
9
1 INTRODUCTION
1.1 ST reference and TOE reference
Title: secunet eID PKI Suite Certified CA Kernel SC Security Target
Sponsor: secunet Security Networks AG
Editor: secunet Security Networks AG
Version: 3.3.4
Date: 2024/02/20
CC Version: Version 3.1, Revision 5
Assurance Level: EAL 4 augmented with ALC_FLR.2
General Status: Draft
Certification-ID: BSI-DSZ-CC-1216
Keywords: Public Key Infrastructure, PKI, Certificate Issuing and Management Component
TOE name: secunet eID PKI Suite Certified CA Kernel SC (in short: Certified CA Kernel SC )
TOE version: 3.0.0
1.2 TOE overview
The Certified CA Kernel SC of secunet eID PKI Suite (abbr. Certified CA Kernel SC ) consists of different
components that are responsible for the request, issuance, revocation, and overall management of certificates and
certificate status information. It supports Extended Access Control Certification Authorities (EAC CAs,) according
Technical Guidline BSI TR-03110 [BSI TR-03110] and International Civil Aviation Organization CAs (ICAO CAs),
which are X.509 CAs according ITU-T X.509 [ITU-T X.509]. The TOE triggers generation of X.509 certificates and
CRLs.
The Certified CA Kernel SC provides Registration Authority (RA) functionality as well as CA functionality.
The functionality of the TOE follows the stipulations from the CIMC PP [CIMC PP]. However, it should be noted
that this Security Target does not claim conformance to this PP.
The Certified CA Kernel SC is JAVA-based and uses the Bouncy Castle cryptography libraries.
1.2.1 TOE definition and operational usage
The Target of Evaluation (TOE) described in this Security Target is a Certificate Issuing and Management
Component, called Certified CA Kernel SC . A Public Key Infrastructure (PKI) is a security infrastructure that creates
and manages public key certificates to facilitate the use of public key cryptography. To achieve this goal, the Certified
CA Kernel SC performs two basic tasks:
• generates and distributes public key certificates to bind public keys to other information after validating the
accuracy of the binding; and
• maintains and distributes certificate status information for unexpired certificates.
By expanding passports through electronic and biometric data, new security relevant requirements have emerged: on
the one hand, the data stored on the chip must be protected against manipulation and forgery. On the other hand, it
must be guaranteed that only authorized persons have access to the electronic data on the passport. These security
requirements are implemented by different certification-instances within Certified CA Kernel SC : ICAO PKI and
EAC PKI.
10
1.2.1.1 Cryptographic functionality
An external key storage is used to generate key material, to store these keys and to execute cryptographic operations
with them. In addition, the TOE implements some cryptographic primitives by itself. All in all, three entities are
involved in the cryptographic implementation of the TOE:
The CA card (environment)
The CA card generates, stores and allows the use of EC keys for a CA. The CA card also provides an AES key that the
TOE uses for encryption of data and provides secure storage for this key. The CA card supports the following
algorithms:
Table 1 Cryptographic Algorithms of the CA card
Algorithm Key Sizes (bit) Purpose Standard
ECGDSA key
generation
256, 320, 384,
512
Generation of EC keys for a CA [BSI TR-03111]
ECGDSA signature
generation
256, 320, 384,
512
Generation of signatures [BSI TR-03111]
ECDSA key generation 256, 320, 384,
512
Generation of EC keys for a CA [BSI TR-03111]
AES key generation 128, 256 Generation of AES keys [FIPS197]
Random Number
Generation
- PTRNG [RNG_Classes]
The CA card shall fulfill the following requirements:
1) Provide the required functionality as needed for the use case (as identified in the previous table)
2) Provide sufficient trust into the implementation. This is shown by a recommendation of BSI for use of the card
in the specific context that the TOE is used in.
As an example, the Giesecke und Devrient STARCOS-3.5 on Infineon SLE78CLX1280P (M7820A11) could be used.
The TOE
The TOE itself utilizes an implementation of the following cryptographic primitives:
Table 2 Cryptographic Algorithms of the TOE
Algorithm Key Sizes (bit) Purpose Standard
RSA key generation 2048, 3072 Audit Trail security PKCS#1/[FIPS 186-5]
RSA encryption/decryption 2048, 3072 Audit Trail security PKCS#1/[FIPS 186-5]
RSA signature creation
• RSA_SHA256_PKCS1
• RSA_SHA384_PKCS1
• RSA_SHA512_PKCS1
• RSA_SHA256_PSS
• RSA_SHA384_PSS
• RSA_SHA512_PSS
2048, 3072 Audit Trail security
Certificates
PKCS#1/[FIPS 186-5]
RSA signature verification
• RSA_SHA256_PKCS1
• RSA_SHA384_PKCS1
• RSA_SHA512_PKCS1
• RSA_SHA256_PSS
• RSA_SHA384_PSS
2048, 3072 Audit Trail security
Certificates
PKCS#1/[FIPS 186-5]
11
• RSA_SHA512_PSS
ECDSA signature verification see Table 3 Verification of
signatures
[BSI TR-03111]
ECGDSA signature verification see Table 3 Verification of
signatures
[BSI TR-03111]
AES key generation 128, 256 Encryption and
decryption of secrets
[FIPS197]
AES HMAC_SHA256 128, 256 Audit Trail Security [SP 800-38B]
AES encryption/decryption with
CBC and PKCS5Padding
128, 256 Encryption and
decryption of secrets
[SP 800-38B]
SHA-256
SHA-11
256, 384, 512 Hashing for various
functions
[FIPS180-2]
Table 3 supported elliptic curves for signature generation and verification
Name Reference
NIST-P224/secp224r1 [FIPS 186-2][ANSI-X9.62]
NIST-P384/secp384r1
NIST-P521/secp521r1
NIST-P256/secp256r1
NIST-K233/sect233k1
NIST-B233/sect223k1
NIST-K283/sect283k1
NIST-B283/sect283r1
NIST-K409/sect409k1
NIST-B409/sect409r1
NIST-K571/sect571k1
NIST-B571/sect571r1
brainpoolP256r1 [BSI TR-03111]
brainpoolP256t1
brainpoolP320r1
brainpoolP320t1
brainpoolP384r1
brainpoolP384t1
brainpoolP512r1
brainpoolP512t1
1 It is important to mention that the SHA-1 is only used to derive a fingerprint and to support legacy PKI
systems that have been set up using SHA-1
12
Beside the curves that are mentioned in the table, also other curves with length of parameters more than or equal to 256
bit may be used as long as the parameters have been created based on the stipulations in RFC5639.
It should be noted that [CIMP PP] contains stipulations about the implementation of cryptographic primitives in the
environment. These requirements are not met by the description in this Security Target. This is the main reason that this
Security Target does not claim conformance to [CIMP PP].
1.2.1.2 CRL and OCSP
As described above the CSCA (X.509-CA) of Certified CA Kernel SC triggers generation of complete CRLs
according [RFC5280] for certificates which are no longer trustworthy and were revoked. CRL generation and
distribution is part of the TOE. The CRL is provided via a distribution point that is determined in the appropriate
CAProfile via user interface.
The secunet Certified CA Kernel SC does not act as Online Certificate Status Protocol (OCSP) responder according
[RFC6960]. It only generates and transfers certificates and certificate status information to OCSP responders that are
part of the TOE environment. According CIMC PP [CIMC PP], Section 2, “The features provided by repositories,
OCSP servers, key recovery servers, and roaming credential servers are optional in a PKI implementation.” And
according [CIMC PP], Section 2: Only “Where the CA acts as an OCSP server, this service is within the boundary of
the CIMC.” I. e., an OCSP server is not part of the TOE.
1.2.2 TOE major security features for operational use
The Certified CA Kernel SC provides the following security features to cover the CIMC PP [CIMC PP] requirements:
• Security Audit (FAU) includes a chronological logging of events that occur in a system to act as a deterrent against
security violations.
• Communication (FCO) involves the transport of information and enforces non-repudiation of origin and receipt as
well as replay detection.
• Cryptographic Support (FCS) employs cryptographic functionality and addresses key management and the
operational use of cryptographic keys.
• User Data Protection (FDP) relates to the protection of user data including certificate issuance, revocation, and
profile management of certificates, as well as Certificate Revocation List (CRL).
• Identification and Authentication (FIA) supports the administration and enforcement of the TOE access control
policies to unambiguously identify the person and/or entity performing functions in the TOE.
• Security Management (FMT) specifies several aspects of management of security functions including distinct roles
to maintain the security of the TOE.
• Protection of the TOE Security Functions (FPT) supports functions that protect the integrity of TSF data from
modification through the use of reliable time stamps and protected audit logs resp. audit trails.
1.2.3 Required non-TOE hardware /software/firmware
1.2.3.1 CA-Server
The CA-Server must fulfill the following minimal requirements:
• 4096 MB RAM
• 2,4 GHz CPU (64 Bit)
• 64 GB storage entity
The hardware must be compatible with the JVM (see Section 1.2.3.3). The physical connections are:
• Network Card
• Power Supply
• PS/2- or USB-attached keyboard
13
• VGA graphics adapter
• Card reader
1.2.3.2 Operating system
The certified Certified CA Kernel SC supports Windows Server 2016, Windows Server 2019, RHEL 7 and RHEL8
operating systems. The operating system must be appropriately prepared for the operation of the TOE. It is sufficient
if the operating system was installed in the basic configuration. Particularly, the server does not need any additional
services such as print servers or web servers. In addition to the base installation, the JVM as identified in the following
section must be installed.
1.2.3.3 JVM
The Certified CA Kernel SC is implemented in Java. Thus, it interacts with the interfaces of the Java Virtual Machine
instead of directly interacting with the underlying Operating System. The Certified CA Kernel SC require one of
the following JVM being present in its environment:
• Oracle JVM 17
While the use of the JVM as a universal interface allows the Certified CA Kernel SC to operate under all Operating
Systems that allow the operation of the aforementioned JVM, it is recommended to utilize an Operating System that
provides adequate security measures and is actively maintained. Specifically, the Certified CA Kernel SC is tested for
operation under the following OS:
• Windows Server 2016 and 2019,
• Red Hat Enterprise Linux 7 and 8 or Rocky Linux 8 (which is equivalent to RHEL 8)
1.2.3.4 Adapter
All data of Certified CA Kernel SC may be stored in or retrieved from a database via an Adapter. The Adapter
provides the interfaces to the TOE and to the database. Certified CA Kernel SC and the Adapter run on the same
machine (CA Server, see Figure 1).
1.3 Conventions
With a few exceptions, the notation, formatting, and conventions used in this document are consistent with version 3.1
revision 5 of the CC. Specific style and clarifying information conventions were developed to aid the reader, as
described below.
• Whenever an operation (assignment, selection, or refinement) has been applied to a security functional requirement,
the corresponding text is underlined.
• Whenever a security functional requirement has been used more than once in the ST, the title of the security
functional requirement is followed by an iteration number (e.g., iteration 1) to distinguish between the different
iterations of the security functional requirement.
• Notes provide additional information about the requirement or provide clarification of the intent of the requirement
(e.g., NOTE: One method of meeting the requirements of FAU_STG.1 is to write audit data directly to non-
modifiable media).
• Wherever possible, the security functional requirements used in the ST were taken from CIMC PP [CIMP PP] and
thus part 2 of the CC. Those functional security requirements that were not drawn from part 2 of the CC contain
“CIMC” in their names in order to clearly identify them as requirements that are unique to the CIMC PP. Where a
new requirement was closely related to one of the existing families of security requirements in part 2 of the CC, the
new requirement name consists of that family’s name followed by CIMC (e.g., FCO_NRO_CIMC.3). Where a new
requirement was not closely related to any existing family of security requirements, the most closely related class
was used as the basis for the requirement’s name (e.g., FDP_CIMC_CER.1).
• Whenever a unique requirement has been specified in the document, the rationale for including this requirement is
located immediately following the security functional requirement. This has been done as an alternative to including
the rationale.
• The ST author added application notes in Section 6. In order to distinguish between CIMC PP [CIMP PP]
application notes and the added application notes the suffix “_D” is added.
14
2 TOE DESCRIPTION
2.1 Physical scope of the TOE
The Certified CA Kernel / Certified CA Kernel SC consists of software and the related guidance documents; both
delivered in a zip file, which is a common archive and compression standard file. The following table lists all
deliverables contained in the zip file:
Certified CA Kernel SC Zip File:
Table 4 Scope of TOE delivery
Category Description Version Remarks
Software Certified CA Kernel SC (zip file)
that contains:
3.0.0 Delivered as download via secunet
Download-Portal
CertifiedCAKernel.jar 3.0.0 JAR archive with the Certified CA Kernel
SC functionality
HSMHandlerSinacard.jar 3.0.0 Secunet eID PKI Suite Certified CA
Kernel SC functionality
bootstrap.bat 3.0.0 Batch file with bootstrapping functionality
for Windows
bootstrap.sh 3.0.0 Shell file with bootstrapping functionality
for Linux
Public key for signature verification - Can be used for verification of the
signature of the ZIP file (after verification
of its fingerprint, see below).
Guidance
Documents
Manual inkl. API documentation 3.0.0 Certified CA Kernel SC Manual
javadoc-cc.zip
Release Notes 3.0.0 ReleaseNotes.pdf
Security Target See chapter
1.1
secunet eID PKI Suite Certified CA
Kernel SC Security Target
Signature Signature over ZIP file containing
all previous items
- Signature is not part of the ZIP file but
delivered separately
The manual will describe all procedures that are necessary to maintain security when distributing versions of the TOE.
The fingerprint of the key that can be used for verification of integrity and authenticity of the delivered items is
• 5040af99068e11769776f4ed5b47394f6836b6f7796f34edd1668d55a206a4e5 (in SHA-256)
2.2 Logical scope of the TOE
From the logical point of view the Certified CA Kernel SC provides RA functionality to verify the information in the
public key certificates and determine certificate status and CA functionality to generate certificates and certificate
status information as well as audit data generation according example CIMC-3 (single component) of CIMC PP [CIMC
PP]. The following figure shows the TOE boundary with the TOE components:
15
Figure 1: TOE boundary
2.2.1 CA-Core
The CA-Core is responsible for CA-internal tasks such as key generation and issuing certificates. The CA-Core can
manage multiple CAs. The CA-Core is managed during bootstrapping with bootstrapping tool (see Section 2.7).
The CA-Core is realized as library and has a defined Java-API. The Java-API of the CA-Core has two interfaces: One
is for controlling the CA-Core (Java methods) and the second is for storing CA-Core data (Output) via Adapter. The
main Java methods are:
• Generate a CA
• Generate a CRL
• Generate a Certificate
• Change Profile Configuration
• Generate Challenge
By implementing an Adapter (not part of the TOE) the CA-Core and Audit can be integrated into any PKI solution.
Such an Adapter may perform for example Workflow-based processes. The processes of a CA – by example certificate
creation – are called Jobs.
To prevent replay, selected Java methods like certificate generation, CRL generation or change configuration require
a challenge-response algorithm.
Thanks to the Java-API an Adapter can be implemented and adjusted to customer-specific requirements and systems.
Due to security reason the user roles are predefined within the TOE and cannot be changed. User roles are also encoded
as X.509 extension into the user certificate.
2.2.1.1 CA-Core Interface to the cryptographic implementation in the environment
A part of the required cryptographic functionality is implemented within the environment of the TOE (see
Section1.2.1.1).The CA-Core uses the environment for:
• Random generation for challenge-response,
• cryptographic Key generation,
16
• cryptographic Key operation (hashing, signing, signature verification) and
• cryptographic Key deletion.
2.2.1.2 CA-Core Interface to the Adapter
The required Adapter (see Section 1.2.3.4) is part of the TOE-Environment (see A.Physical Protection). The interface
between CA-Core and Adapter is a Java-API. The CA-Core uses the Adapter for:
• Fetching Jobs – dedicated for CA-Core – created and stored by external components (Web-Frontend, SPOC,
nSPOC, CMP,…),
• Storing Job results for external components (Web-Frontend, SPOC, nSPOC, CMP,…),
• Storing and fetching the following data
o CA configuration
o CAProfile/CRLProfile
o CRLs
2.2.2 Challenge Request and Response
To prevent replay the CA-Core triggers a challenge-response algorithm. In a first step the external component must
request a challenge via Adapter from the CA-Core. The request is not cryptographic protected. The CA-Core then
triggers generation of a challenge (10 Byte) within the environment. The environments Deterministic Random Number
Generator (DRNG) is then used to generate the challenge. The CA-Core then maintains the challenges with the user
identification given in the request (it is possible to have more than one challenge per user at any given time) and sends
the challenge back to the external component via Adapter. Now the external component may request Job processing
via Adapter in a second step. A Job must contain amongst others the requested challenge and must be signed with the
user’s private key.
2.2.3 User Authorization and Challenge Verification
Before CA-Core starts a particular process, it performs the following checks to ensure the integrity of the consigned
Java method data: The CA-Core
• performs user certificate validation and the appropriate certificate chain validation
• performs the signature verification with all consigned data
• checks whether the given challenge and the signature identity matches a stored challenge/identity and
• checks whether the role of the signature identity has the right to perform the requested process (for example creating
a new certificate or a new certification revocation list).
If all checks succeed, the Audit generates an audit log record and starts request processing (see Section 2.2.4 and 2.2.5).
If a check fails, the Audit generates an audit log record and the CA-Core does not start request processing.
2.2.4 Configuration Security
At the first startup the CA-Core has no configuration. Thus, the CA-Core must first be configured (e. g. CA
configuration) via the Java-API. The CA-Core performs the same checks for Java configuration method as described
in Section 2.2.3. That is certificate validation, signature verification, challenge/identity check and role check. If all
checks succeed, the Audit generates an audit log and the CA-Core triggers the generation of a new symmetric key
within the environment. Then the CA-Core triggers HMAC [RFC2104] protection of the configuration within the
environment. Finally, the CA-Core stores the HMAC protected configuration via Java-API to the Adapter.
To prevent replay every change of a configuration requires that the CA-Core triggers the generation a new symmetric
key and the deletion of the formerly used symmetric key within the environment.
If a configuration is needed during processing the CA-Core loads all information via Java-API from the Adapter. Then
the CA-Core triggers HMAC verification within the environment. If HMAC verification fails the Audit generates an
audit log record and the CA-Core does not further continue processing. If HMAC verification succeeds the CA-Core
Job processing is continued.
17
2.2.5 Profile Validation and Certificate/CRL generation
In case of a certificate request the CA-Core
• validates the certificate request against the loaded CAProfile,
• triggers signature verification of the certificate request within the environment,
• transforms the CAProfile and merge it with the certificate request into a certification template,
• triggers signing of certificate template to generate a certificate within the environment and
• returns the new certificate via Java-API to the Adapter.
In case of a certificate revocation list request the CA-Core
• merges the CRLProfile and the list of revoked certificates into the certificate revocation list template,
• triggers singing of the certificate revocation list template within the environment and
• returns the new certificate revocation list via Java-API to the Adapter.
2.2.6 Audit
The Audit protects audit messages against modification or deletion to ensure accountability of user actions.
The Audit logs of the security-relevant events that were performed by the TOE. These events are either triggered
internally or by external components/users via Java methods. That is the CA-Core logs amongst others every event and
the appropriate event state, in the case that this event triggers a process of the CA-Core.
For that the CA-Core sends the log messages to the Audit. The Audit unit of the TOE then generates uniquely
identifiable audit messages, so called audit records. The TOE triggers that a set of these chronological ordered audit
records (called audit trail) are periodically signed by means of a digital signature by the Hardware Security Module,
resulting in a so-called protected audit trail. This period is configurable. To protect audit messages against modification
or deletion the Audit uses timestamps and audit trail sequence numbers.
The Audit also triggers some cryptographic operations with the environment to protect these messages. The Audit
needs three different cryptographic keys to protect the audit trails. It needs two asymmetric key pairs, one signature
key pair (ASK) and one encryption key (AEK) and also one current symmetric trail record key (TRK) (FCS_COP.1).
All these keys are generated by the TOE (FCS_CKM.1) are stored in the environment. The file that is used to store the
keys within the environment is further encrypted utilizing an AES key from the CA card. The asymmetric keys are
generated during the bootstrap process of the TOE (see Section 2.7). Audit records and audit trails are stored via Java-
API in the Adapter.
The CA-Core generates audit messages for the following auditable events:
• Start-up and shutdown of the audit functions and
• further security-relevant events
Each audit record contains:
• Sequence number of the trail to which the record belongs to
• Sequence number of the record inside this trail
• Creation date of this record
• Event type of the log message
• Identifier of the module who creates this entry
• Identifier of the user who issues this entry
• This element contains the log message
• MAC over this log record generated with current trail record key (TRK)
The TOE performs on every startup of the Audit an integrity check of the latest audit trail with the environment. Any
error during this check shows manipulation or deletion of the audit trail storage. In this case the TOE does not startup.
18
2.3 CIMC Intended Environment
The Certified CA Kernel SC is operated in a protected environment (A.Physical Protection). The sensitivity of the
information protected by the certificates issued by CIMCs will vary significantly. Users will be required to evaluate
the environment and the associated threats and vulnerabilities and determine the level of risk they are willing to accept
based on the sensitivity of the information.
Certified CA Kernel SC is appropriate for environments where risks and consequences of data disclosure and loss of
data integrity are moderate to low. This ST requires integrity controls to ensure data is not modified and includes
additional assurance requirements to ensure the CIMC is functioning securely.
Certified CA Kernel SC provides some protection against malicious authorized users by requiring, at a minimum,
three distinct roles. One role – Administrator – will be responsible for account administration, key generation, and
audit configuration; a second role – Officer – will be responsible for issuing and revoking certificates; and a third role
– Auditor – responsible for maintaining the audit logs. Please note that the role Operator as defined in CIMC PP
[CIMC] is not a distinct ST role as backup and recovery functionality is not part of the Certified CA Kernel SC in
accordance with CIMC PP [CIMP PP], Section 5.3.
Cryptographic functionality responsible for long-term private key protection or for signing certificates or certificate
status information (please see chapter 1.2.1.1). Finally, there is public key protection and digital signatures are required
on all messages.
Within this ST, the applicable CC assurance level is EAL 4 (methodically designed, tested and reviewed) augmented
by ALC_FLR.2 (flaw reporting procedures) to further ensure that identified flaws in the product are addressed
appropriately.
2.4 CIMC Keys
The TOE may manage the following keys:
• Component keys: Keys, other than CIMS personnel keys, which are used by the CIMC. Certified CA Kernel SC
uses Component keys to sign certificates and certificate status information. Component keys are also used to sign
audit logs and to ensure the integrity of changed Jobs by CA-Core. Component secret keys are neither used to
encrypt CIMC stored or transmitted data nor to compute authentication codes.
Please note that Certified CA Kernel SC does not manage Certificate subject private keys as defined in CIMC PP
[CIMC PP], Section “CIMC Keys” as the Certified CA Kernel SC does not provide key recovery. These keys are
managed in TOE environment.
Please further note that Certified CA Kernel SC does not manage CIMS personnel keys as defined in CIMC PP [CIMC
PP], Section “CIMC Keys”. These keys are managed in TOE environment. CIMS personnel keys are used to sign
configuration files and Jobs created by users of external Components for authentication against CA-Core.
2.4.1 Cryptographic Functions Involving Private or Secret Keys
Private and secret keys within a CIMC are separated into different usage categories as described below. Listed in
brackets next to each usage category are the associated key user categories defined in the CIMC Keys section.
• Certificate and Status Signing Keys: Private keys used to sign certificates, CRLs, or other statements about the
status of certificates. [Component keys]
• Integrity or Approval Authentication Keys: Secret keys used to protect the integrity of all data stored by CIMC in
the database. [Component keys]
Please note that Certified CA Kernel SC does not manage General Authentication Keys as defined in CIMC PP [CIMC
PP], Section “Cryptographic Functions Involving Private or Secret Keys”. These keys are managed in TOE
environment.
Please further note that Certified CA Kernel SC does not require any of the following keys defined in CIMC PP
[CIMC PP], Section “Cryptographic Functions Involving Private or Secret Keys”: Long Term Private Key Protection
Keys, Long Term Confidentiality Keys, Short Term Private Key Protection Keys, or Short Term Confidentiality Keys.
19
2.5 Data Input
Certified CA Kernel SC receives information of the following category 3) as already defined in CIMC PP [CIMC PP],
Section “Data Input”:
1) Unauthenticated Data Entry: Certified CA Kernel SC never accepts unauthenticated data.
2) Local Data Entry: Certified CA Kernel SC does not support local data entry.
3) Remote Data Entry: Certified CA Kernel SC fetches via Adapter data from a database in such a way
that it can be bound to the identity of the sender of the data (signed Jobs).
2.6 Trusted Public Key Entry, Deletion, and Storage
All “trust anchors” created during bootstrapping (see Section 2.7) are stored in the environment. The TOE identifies
trust anchors by a special prefix of the public key name. The TOE can simply use these public keys, to verify the issued
certificates.
2.7 Bootstrapping
In order to protect audit data or to verify Java methods or configuration data the TOE requires a bootstrapping process
to first generate the required cryptographic keys or certificates with help of the environment. The bootstrapping process
is provided by the so called bootstrapping tool, installed on the CA-Server. After bootstrapping, the bootstrapping tool
must be deleted from the CA-Server. During bootstrapping the following cryptographic keys or certificates are
generated:
• signature key pair (ASK) for the Audit
• user key pair and user root certificate for user PKI
It should be noted that the encryption key (AEK) for the Audit that is stored on the CA card is created during the
personalization of this card. At the time of the bootstrapping process it is already existing.
20
3 Conformance Claim
3.1 CC Conformance Claim
This Security Target claims conformance to
• Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and general model; CCMB-2017-04-001, Version 3.1, Revision 5, April 2017
• Common Criteria for Information Technology Security Evaluation, Part 2:
Security functional components; CCMB-2017-04-002, Version 3.1, Revision 5, April 2017
• Common Criteria for Information Technology Security Evaluation, Part 3:
Security assurance components; CCMB-2017-04-003, Version 3.1, Revision 5, April 2017
as follows
• Part 2 extended,
• Part 3 conformant.
The
• Common Methodology for Information Technology Security Evaluation,
Evaluation methodology; CCMB-2017-04-004, Version 3.1, Revision 5, April 2017
has to be taken into account.
3.2 PP Claim
This Security Target does not claim conformance to any Protection Profile.
3.3 Package Claim
The current Security Target is conformant to the following security requirements package: Assurance package EAL4
augmented by ALC_FLR.2
3.4 CC Conformance Claim Rationale
3.4.1 PP conformance
This Security Target does not claim conformance to any Protection Profile.
21
4 SECURITY PROBLEM DEFINITION
This chapter introduces the security problem definition of the TOE. This comprises:
• The assets which have to be protected by the TOE.
• The subjects/external entities which are interacting with the TOE.
• The assumptions which have to be made about the environment of the TOE.
• The threats which exist against the assets of the TOE
• The organizational security policies the TOE has to comply to.
This information provides the basis for the Security Objectives specified in Section 5, the security functional
requirements for the TOE specified in Section 6, and the TOE Security Assurance Requirements specified in Section
8.
Application Note_D: This chapter has been reproduced from [CIMC PP]. Any changes from the text in [CIMC PP] are
clearly marked using grey background for the text or by Application Notes.
4.1 Assets
The following assets need to be protected by the TOE and its environment:
Audit records The TOE generates uniquely identifiable audit messages (so called audit records) that
need to be protected against modification.
CRLs The TOE generates so called Certificate Revocation Lists. These lists contain
information about revoked certificates. These lists need to be protected against
modification.
TSF data All configuration files (CA configuration, CAProfile and CRLProfile) are
created/edited with external components and protected against modification. Only
unmodified configuration files must be processed by the TOE.
Requests E. g. certificate or certificate revocation list requests. All requests are created/edited
with external components and protected against modification. Only unmodified
requests must be processed by the TOE.
Cryptographic Keys Cryptographic keys require protection. The TOE utilizes the environment for some of
this protection. Please refer to chapter 1.2.1.1 for more details.
4.2 Subjects/External Entities
The following subjects/external entities may interact with the TOE:
Administrator Role authorized to install, configure and maintain the TOE, establish and maintain user
accounts, configure profiles, access rights and audit parameters and manage
component keys.
Auditor Role authorized to view and maintain audit logs.
Officer Role authorized to request or approve certificates or certificate revocations.
Attacker Any entity (human or IT) outside the TOE that interacts (or may inter-act) with the
TOE – also called hacker. A goal of an attacker may be to change configuration files or
send unauthorized requests. Attackers with an Enhanced-Basic attack potential are
assumed.
22
4.3 Secure Usage Assumptions
The usage assumptions are organized in three categories: personnel (assumptions about administrators and users of the
system as well as any threat agents), physical (assumptions about the physical location of the TOE or any attached
peripheral devices), and connectivity (assumptions about other IT systems that are necessary for the secure operation
of the TOE).
Personnel
A.Auditors Review
Audit Logs
Audit logs are required for security-relevant events and must be reviewed by the
Auditors.
A.Authentication Data
Management
An authentication data management policy is enforced to ensure that users change their
authentication data at appropriate intervals and to appropriate values (e.g., proper
lengths, histories, variations, etc.) (Note: this assumption is not applicable to biometric
authentication data.)
A.Competent
Administrators, Officers
and Auditors
Competent Administrators, Officers and Auditors will be assigned to manage the TOE
and the security of the information it contains. It is further assumed that these people are
non-hostile.
A.Cooperative Users Users need to accomplish some task or group of tasks that require a secure IT
environment. The users require access to at least some of the information managed by
the TOE and are expected to act in a cooperative manner.
A.CPS All Administrators, Officers, and Auditors are familiar with the certificate policy
(CP) and certification practices statement (CPS) under which the TOE is operated.
A.Disposal of
Authentication Data
Proper disposal of authentication data and associated privileges is performed after access
has been removed (e.g., Job termination, change in responsibility).
A.Malicious Code Not
Signed
Malicious code destined for the TOE is not signed by a trusted entity.
A.Notify Authorities of
Security Issues
Administrators, Officers, Auditors, and other users notify proper authorities of any
security issues that impact their systems to minimize the potential for the loss or
compromise of data.
A.Social Engineering
Training
General users, administrators, officers and auditors are trained in techniques to thwart
social engineering attacks.
Connectivity
A.HSM The smart card in the environment (CA card) that are used by the TOE must only be
used exclusively by the TOE. That is no other IT component is allowed to use the smart
card.
A.Operating System The operating system has been selected to provide the functions required by this CIMC
to counter the perceived threats identified in this ST.
Although this ST does not specifically address the operating system, functions/requirements traditionally attributed to
an operating system are distributed throughout this ST in appropriate sections. PKIs incorporating CIMC components
that rely on operating systems to provide/enforce these functions/requirements must utilize operating systems with
features that counter the perceived threats identified in this ST.
Physical
A.Communications
Protection
The system is adequately physically protected against loss of communications i. e.,
availability of communications.
A.Physical Protection The TOE and non TOE hardware, software, and firmware critical to security policy
enforcement will be protected from unauthorized physical modification.
23
4.4 Threats
The threats are organized in four categories: authorized users, system, cryptography, and external attacks.
Authorized Users
Threat agent for the following threats is an authorized user. Asset that can be compromised are the CIMC and/or the
systems that rely on the PKI objects such as certificates or CRLs. The latter systems are termed relying party
systems.
T.Administrative errors
of omission
Administrators, Officers or Auditors fail to perform some function essential to security.
T.Administrators,
Officers and Auditors
commit errors or hostile
actions
An Administrator, Officer or Auditor commits errors that change the intended security
policy of the system or application or maliciously modify the system’s configuration to
allow security violations to occur.
T.User abuses
authorization to collect
and/or send data
User abuses granted authorizations to improperly collect and/or send sensitive or
security-critical data.
T.User error makes data
inaccessible
User accidentally deletes user data rendering user data inaccessible.
System
T.Critical system
component fails
Failure of one or more system components results in the loss of system critical
functionality. Threat agent in this case is the CIMC hardware. Adverse action can be
compromise of the security of the CIMC and/or relying party systems that rely on the
PKI objects such as certificates or CRLs.
T.Flawed code A system or applications developer delivers code that does not perform according to
specifications or contains security flaws. Threat agent in this case is the TOE developer.
Adverse action can be compromise of the security of the CIMC and/or relying party
systems that rely on the PKI objects such as certificates or CRLs.
T.Malicious code
exploitation
An authorized user, IT system, or hacker downloads and executes malicious code, which
causes abnormal processes that violate the integrity, availability, or confidentiality of
the system assets. Threat agent could be an authorized user, TOE itself, or an
unauthorized user. Adverse action can be compromise of the security of the CIMC
and/or relying party systems that rely on the PKI objects such as certificates or CRLs.
T.Message content
modification
A hacker modifies information that is intercepted from a communications link between
two unsuspecting entities before passing it on to the intended recipient. Threat agent is
an unauthorized user. Adverse action can be compromise of the security of the CIMC
and/or relying party systems that rely on the PKI objects such as certificates or CRLs.
Cryptography
T.Disclosure of private
and secret keys
A private or secret key is improperly disclosed. Threat agent is the authorized user or
erroneous protocol. Adverse action can be compromise of the security of the CIMC
and/or relying party systems that rely on the PKI objects such as certificates or CRLs.
T.Modification of
private/secret keys
A secret/private key is modified. Threat agent is the authorized user or erroneous
protocol. Adverse action can be compromise of the security of the CIMC and/or relying
party systems that rely on the PKI objects such as certificates or CRLs.
24
T.Sender denies sending
information
The sender of a message denies sending the message to avoid accountability for sending
the message and for subsequent action or inaction. Threat agent is a subscriber to CIMC.
Adverse action can be reduced trust in CIMC.
External Attacks
T.Hacker gains access A hacker masquerades as an authorized user to perform operations that will be attributed
to the authorized user or a system process or gains undetected access to a system due to
missing, weak and/or incorrectly implemented access control causing potential
violations of integrity, confidentiality, or availability. Threat agent is the unauthorized
user. Adverse action can be compromise of the security of the CIMC and/or relying party
systems that rely on the PKI objects such as certificates or CRLs.
T.Hacker physical access A hacker physically interacts with the system to exploit vulnerabilities in the physical
environment, resulting in arbitrary security compromises. Threat agent is the
unauthorized user. Adverse action can be compromise of the security of the CIMC
and/or relying party systems that rely on the PKI objects such as certificates or CRLs.
T.Social engineering A hacker uses social engineering techniques to gain information about system entry,
system use, system design, or system operation. Threat agent is the unauthorized user.
Adverse action can be compromise of the security of the CIMC and/or relying party
systems that rely on the PKI objects such as certificates or CRLs.
4.5 Organization Security Policies
P.Authorized use of
information
Information shall be used only for its authorized purpose(s).
P.Cryptography Cryptographic functions of sufficient quality shall be used to perform all cryptographic
operations. Please refer to chapter 1.2.1.1 for a definition of appropriate algorithms and
key lengths.
25
5 SECURITY OBJECTIVES
This section includes the security objectives for the TOE and the security objectives for the environment as listed in
CIMC PP [CIMC PP], Sections 4.1 and 4.2. Please note that the security objectives listed in CIMC PP [CIMC PP],
Section 4.3 “Security Objectives for both the TOE and the Environment”, are either assigned to “Security Objectives
for the TOE”, see Section 5.1 or to “Security Objectives for the Environment”, see Section 5.2. Please further note that
all security objectives for the environment are renamed with the suffix “OE.” In order to distinguish between both
types of security objectives.
The CIMC PP [CIMC PP] covers all kinds of architectures for a PKI and does not require a particular architecture.
Thus, for Certified CA Kernel SC architecture all CIMC PP [CIMC PP] Security Functional Requirements are
checked for application. Table 5 shows which CIMC PP [CIMC PP] Security Functional Requirements are stated in
this Security Target. See also description below Table 5 for further details.
The following CIMC PP [CIMC PP] Security Objectives are not stated in the Security Target because the appropriate
Security Functional Requirements are not applicable at all for the TOE:
• O.Data import/export (FDP_ETC_CIMC.5 Extended user private and secret key export, FMT_MTD_CIMC.7
Extended TSF private and secret key export, FPT_ITC.1 Inter-TSF confidentiality during transmission
(iterations 1 and 2) and FDP_UCT.1 Basic data exchange confidentiality (iterations 1 and 2))
• O.Protect user and TSF data during internal transfer (FDP_ITT.1 Basic internal transfer protection (iterations
3 and 4) and FPT_ITT.1 Basic internal TSF data transfer protection (iterations 3 and 4))
Application Note_D: This chapter has been reproduced from [CIMC PP]. Any changes from the text in [CIMC PP] are
clearly marked using grey background for the text or Application Notes.
5.1 Security Objectives for the TOE
This section includes the security objectives for the TOE, divided among six categories: authorized users, system,
cryptography, external attacks, management and audits.
Authorized Users
O.Certificates The TSF must ensure that certificates, certificate revocation lists, and certificate
status information are valid.
O.Individual
accountability and audit
records
Provide individual accountability for audited events. Record in audit records: date
and time of action and the entity responsible for the action.
O.Limitation of
administrative access
Design administrative functions so that Administrators, Officers and Auditors do not
automatically have access to user objects, except for necessary exceptions. Control
access to the system by Administrators who troubleshoot the system and perform
system updates.
O.Maintain user
attributes
Maintain a set of security attributes (which may include role membership, access
privileges, etc.) associated with individual users. This is in addition to user identity.
O.Restrict actions before
authentication
Restrict the actions a user may perform before the TOE authenticates the identity of
the user.
O.Security roles Maintain security-relevant roles and the association of users with those roles.
O.User authorization
management
Manage and update user authorization and privilege data to ensure they are
consistent with organizational security and personnel policies.
System
26
O.React to detected
attacks
Implement automated notification (or other responses) to the TSF-discovered
attacks in an effort to identify attacks and to create an attack deterrent.
Cryptography
O.Non-repudiation Prevent user from avoiding accountability for sending a message by providing
evidence that the user sent the message.
O.Integrity protection of
user data
Provide appropriate integrity protection for user data.
External Attacks
O.Control unknown
source communication
traffic
Control (e.g., reroute or discard) communication traffic from an unknown source to
prevent potential damage.
Management
O.Manage behavior of
security functions
Provide management functions to configure, operate, and maintain the security
mechanisms.
O.Configuration
Management
Implement a configuration management plan. Implement configuration
management to assure identification of system connectivity (software, hardware,
and firmware), and components (software, hardware, and firmware), auditing of
configuration data, and controlling changes to configuration items.
Audit
O.Protect stored audit
records
Protect audit records against unauthorized access, modification, or deletion to
ensure accountability of user actions.
O.Respond to possible
loss of stored audit
records
Respond to possible loss of audit records when audit trail storage is full or nearly
full by restricting auditable events.
5.2 Security Objectives for the Environment
This section specifies the security objectives for the environment.
OE.Administrators,
Officers and Auditors
guidance documentation
Deter Administrator, Officer or Auditor errors by providing adequate
documentation on securely configuring and operating the CIMC.
OE.Auditors Review
Audit Logs
Identify and monitor security-relevant events by requiring auditors to review audit
logs on a frequency sufficient to address level of risk.
OE.Authentication Data
Management
Ensure that users change their authentication data at appropriate intervals and to
appropriate values (e.g., proper lengths, histories, variations, etc.) through enforced
authentication data management (Note: this objective is not applicable to biometric
authentication data.)
27
OE.Communications
Protection
Protect the system against a physical attack on the communications capability by
providing adequate physical security.
OE.Competent
Administrators, Officers
and Auditors
Provide capable management of the TOE by assigning competent Administrators,
Officers and Auditors to manage the TOE and the security of the information it
contains. Only non-hostile people are entrusted with administrative tasks.
OE.Cooperative Users Ensure that users are cooperative so that they can accomplish some task or group of
tasks that require a secure IT environment and information managed by the TOE.
OE.CPS All Administrators, Officers and Auditors shall be familiar with the certificate
policy (CP) and the certification practices statement (CPS) under which the TOE is
operated.
OE.Detect modifications
of firmware, software,
and backup data
Provide integrity protection to detect modifications to firmware, software, and
backup data.
OE.Disposal of
Authentication Data
Provide proper disposal of authentication data and associated privileges after
access has been removed (e.g., Job termination, change in responsibility).
OE.HSM The smart card in the environment (CA card) that is used by the TOE shall only be
used exclusively by the TOE. That is no other IT component is allowed to use the
smart card.
OE.Installation Those responsible for the TOE must ensure that the TOE is delivered, installed,
managed, and operated in a manner which maintains IT security.
OE.Lifecycle security Provide tools and techniques used during the development phase to ensure security
is designed into the CIMC. Detect and resolve flaws during the operational phase.
OE.Malicious Code Not
Signed
Protect the TOE from malicious code by ensuring all code is signed by a trusted
entity prior to loading it into the system.
OE.Notify Authorities of
Security Issues
Notify proper authorities of any security issues that impact their systems to
minimize the potential for the loss or compromise of data.
OE.Object and data
recovery free from
malicious code
Recover to a viable state after malicious code is introduced and damage occurs.
That state must be free from the original malicious code.
OE.Operating System The operating system used is validated to provide adequate security, including
domain separation and non-bypassability, in accordance with security requirements
recommended by the National Institute of Standards and Technology.
OE.Periodically check
integrity
Provide periodic integrity checks on both system and software.
OE.Physical Protection Those responsible for the TOE must ensure that the security-relevant components
of the TOE and non TOE are protected from physical attack that might compromise
IT security.
OE.Preservation/trusted
recovery of secure state
Preserve the secure state of the system in the event of a secure component failure
and/or recover to a secure state.
OE.Procedures for
preventing malicious
code
Incorporate malicious code prevention procedures and mechanisms.
OE.Repair identified
security flaws
The vendor repairs security flaws that have been identified by a user.
OE.Require inspection
for downloads
Require inspection of downloads/transfers.
OE.Security-relevant
configuration
management
Manage and update system security policy data and enforcement functions, and
other security-relevant configuration data, to ensure they are consistent with
organizational security policies.
OE.Social Engineering
Training
Provide training for general users, Administrators, Officers and Auditors in
techniques to thwart social engineering attacks.
28
OE.Sufficient backup
storage and effective
restoration
Provide sufficient backup storage and effective restoration to ensure that the system
can be recreated.
OE.Time stamps Provide time stamps to ensure that the sequencing of events can be verified.
OE.Trusted Path Provide a trusted path between the user and the system. Provide a trusted path to
security-relevant (TSF) data in which both end points have assured identities.
OE.Validation of
security function
Ensure that security-relevant software, hardware, and firmware are correctly
functioning through features and procedures.
OE.Cryptographic
functions
Provide algorithms for authentication and signature generation/verification; key
generation techniques. Please refer to chapter 1.2.1.1 for more details on the
required algorithms.
29
6 Extended Components Definition
The additional components for random number generation (FCS_RNG) are defined within this chapter as part of the
existing class FCS (cryptographic support). This definition has been taken from [RNG_Classes].
FCS_RNG Generation of random numbers
Family behaviour
This family defines quality requirements for the generation of random numbers which are intended to be use for
cryptographic purposes.
Component levelling:
FCS_RNG.1 Generation of random numbers requires that random numbers meet a defined
quality metric.
Management: FCS_RNG.1
There are no management activities foreseen.
Audit: FCS_RNG.1
There are no actions defined to be auditable.
FCS_RNG.1 Random number generation
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic,
hybrid physical, hybrid deterministic] random number generator that
implements: [assignment: list of security capabilities].
FCS_RNG.1.2 The TSF shall provide random numbers that meet [assignment: a defined quality
metric].
30
7 TOE SECURITY FUNCTIONAL REQUIREMENTS
This section specifies the security requirements that are applicable to CIMC functionality, such as key management,
certificate registration, and CIMC configuration and management functions.
Table 5 lists all the functional security requirements for the TOE that are included in this ST. They are listed in
alphabetical order in Table 5 for ease of reference. Also included are the applicable CIMC ST sections to which each
requirement applies.
Please note that the functional security requirement suffix “iteration” is taken exactly from the CIMC PP [CIMC PP],
Section 6.
Application Note_D: This chapter addresses all requirements from [CIMC PP]. Any changes from the text in [CIMC
PP] are clearly marked using grey background for the text or by Application Notes.
Table 5 CIMC TOE Functional Security Requirements
Security Functional Components CIMC ST Section
FAU_GEN.1 Audit data generation (iteration 2) 6.1 Security Audit
FAU_GEN.2 User identity association (iteration 2) 6.1 Security Audit
FAU_SEL.1 Selective audit (iteration 2) 6.1 Security Audit
FAU_STG.1 Protected audit trail storage (iteration 2) 6.1 Security Audit
FAU_STG.4 Prevention of audit data loss (iteration 2) 6.1 Security Audit
FCO_NRO_CIMC.3 Enforced proof of origin and verification of origin 6.5 Remote Data Entry and
Export
FCO_NRO_CIMC.4 Advanced verification of origin 6.5 Remote Data Entry and
Export
FCS_CKM_CIMC.5 CIMC private and secret key zeroization 6.4.4 Private and Secret Key
Destruction
FCS_CKM.1 Cryptographic key generation 7.6.3 Cryptographic Operation of the
TOE
FCS_CKM.4 Cryptographic key destruction 7.6.3 Cryptographic Operation of the
TOE
FCS_COP.1 Cryptographic operation 7.6.3 Cryptographic Operation of the
TOE
FCS_RNG.1 Random Number Generation 7.6.3 Cryptographic Operation of the
TOE Operation of the TOE
FDP_ACC.1 Subset access control (iteration 2) 6.3 Access Control
FDP_ACF.1 Security attribute based access control (iteration 2) 6.3 Access Control
FDP_CIMC_CER.1 Certificate Generation 6.10 Certificate Registration
FDP_CIMC_CRL.1 Certificate revocation list validation 6.11.1 Certificate Revocation
List Validation
FDP_CIMC_CSE.1 Certificate status export 6.5.1 Certificate Status Export
FDP_SDI_CIMC.3 Stored public key integrity monitoring and action 6.6.2 Public Key Storage
FIA_ATD.1 User attribute definition 6.2 Roles
FIA_SOS.1 Verification of secrets (iteration 2) 6.4 Identification and
Authentication
FIA_UAU.1 Timing of authentication (iteration 2) 6.4 Identification and
Authentication
FIA_UID.1 Timing of identification (iteration 2) 6.4 Identification and
Authentication
FIA_USB.1 User-subject binding (iteration 2) 6.4 Identification and
Authentication
31
FMT_MOF.1 Management of security functions behavior (iteration 2) 6.2 Roles
FMT_MOF_CIMC.3 Extended certificate profile management 6.7 Certificate Profile
Management
FMT_MOF_CIMC.5 Extended certificate revocation list profile
management
6.8 Certificate Revocation List
Profile Management
FMT_MTD.1 Management of TSF data 6.2 Roles
FMT_MSA.1 Management of security attributes 6.2 Roles
FMT_SMR.1 Security roles 6.2 Roles
FPT_CIMC_TSP.1 Audit log signing event 6.1 Security Audit
Due to the chosen TOE design The following CIMC PP [CIMC PP] functional security requirements are not applicable
and thus not included in this ST:
• Since the TOE provides CRL functionality but not OCSP functionality – consistently with CIMC PP [CIMC PP] –
FDP_CIMC_OCSP.1 is not applicable.
• Since the TOE does not provide Basic Response Validation according FDP_CIMC_OCSP.1 the functional
requirement FMT_MOF_CIMC.6 is not applicable.
• Since there are no physically-separated parts of the TOE, there is no need to employ specific security mechanisms
according FDP_ITT.1 (iterations 3 and 4).
• Since the TOE does not transmit confidential objects, there is no need to employ specific security mechanisms
according FDP_UCT.1 (iteration 2).
• Since the TOE does not transmit confidential TSF data, there is no need to employ specific security mechanisms
according FPT_ITC.1 (iteration 2).
• Since the TOE does neither manage CIMS personal keys nor certificate subject private keys FDP_ACF_CIMC.2
is not applicable.
• Based on the description given in chapter 1.2.1.1 FMT_MTD_CIMC.4 and FMT_MTD_CIMC.5 have not been
added to this ST.
• Since the TOE does not manage user secret keys FDP_ACF_CIMC.3 is not applicable.
• Since the TOE does neither export user private keys nor TSF private keys FDP_ETC_CIMC.5 and
FMT_MTD_CIMC.7 are not applicable.
• Since there are no physically-separated parts of the TOE, there is no need to employ specific security mechanisms
according FPT_ITT.1 (iterations 3 and 4).
• Since reliable time stamps are provided by the TOE environment (see OE.Time stamps) there is no need to employ
specific security mechanism according FPT_STM.1 Reliable time stamps (iterations 2).
7.1 Security Audit
Audit includes a chronological recording of events that occur in a system. The objective is to track what occurs to
enable the reconstruction and examination of a sequence of events and/or changes in an event. This is useful in ensuring
that the system is operated securely and in providing evidence when a suspected or actual security compromise has
occurred. Audit also provides for reconstructing a specific state of a system. The objective in a PKI system is to enable
an appropriate authority to determine whether a signature should have been accepted as valid.
The audit will be used to reconstruct important events that were performed by the TOE, such as issuance of a CA
certificate, and the user or event (e.g., a signed certificate request) that caused them. The audit will be used to arbitrate
future disputes by establishing the validity of a signature at a particular time. The audit log records the security-
relevant events that were performed by the TOE and the users or events (e.g., a signed certificate request) that caused
them. This subsection specifies the security requirements for maintaining and protecting the integrity of the audit logs.
The TOE maintains a single audit log in the database.
32
FAU_GEN.1 Audit data generation (iteration 2)
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 minimum level of audit; and
c) The events listed in Table 6 below.
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, the information specified in the Additional Details column in Table 6 below.
Additionally, the audit shall not include plaintext private or secret keys or other critical security parameters.
Table 6 Auditable Events and Audit Data
Section/Function Component Event Additional Details
6.1; Security Audit FAU_GEN.1 Audit
data generation
(iteration 2)
Any changes to the audit
parameters, e.g., audit
frequency, type of event
audited
Any attempt to delete the
audit log
FPT_CIMC_TSP.1
Audit log signing event
Audit log signing event Digital signature,
keyed hash, or
authentication code
shall be included in the
audit log.
Local Data Entry All security-relevant data
that is entered in the
system
Application Note_D:
Not applicable, since the
TOE does not support
local data entry.
The identity of the
data entry individual if
the entered data is
linked to any other
data (e.g., clicking an
“accept” button). This
shall be included with
the accepted data.
Remote Data Entry All security-relevant
messages that are received
by the system
Data Export and
Output
All successful and
unsuccessful requests for
confidential and security-
relevant information
Application Note_D:
Not applicable, since the
TOE does not provide
confidential or security-
relevant information
Key Generation FCS_CKM.1
Cryptographic Key
Generation
Whenever the TSF
requests generation of a
cryptographic key. (Not
mandatory for single
session or one-time use
symmetric keys.)
The public component
of any asymmetric key
pair generated
33
Private Key Load The loading of
Component private keys
Application Note_D:
Not applicable, since
component private keys
are generated and stored
in the environment.
6.6.1: Private Key
Storage
All access to certificate
subject private keys
retained within the TOE
for key recovery purposes
Application Note_D:
Not applicable, since the
TOE does not manage
certificate
subject private keys
Trusted Public Key
Entry, Deletion and
Storage
All changes to the trusted
public keys, including
additions and deletions
The public key and all
information associated
with the key
6.6.3: Secret Key
Storage
The manual entry of
secret keys used for
authentication
Application Note_D:
Not applicable, since the
TOE does use Secret
Key Storage
6.6.5: Private and
Secret Key Export
FDP_ETC_CIMC.5
Extended user private
and secret key
export;
The export of private and
secret keys (keys used for
a single session or
message are excluded)
Application Note_D:
Not applicable, since the
TOE does not export
any private or secret
keys.
FMT_MTD_CIMC.7
Extended TSF private
and secret key export
44_D: Not applicable,
since the TOE does not
export any private or
secret keys.
6.10: Certificate
Registration
FDP_CIMC_CER.1
Certificate
Generation
All certificate requests If accepted, a copy of
the certificate. If
rejected, the reason for
rejection (e.g., invalid
data, request rejected
by Officer, etc.).
Certificate Status
Change Approval
All requests to change the
status of a certificate
Whether the request
was
Accepted or rejected.
CIMC
Configuration
Any security-relevant
changes to the
configuration of the TSF.
6.7: Certificate
Profile Management
FMT_MOF_CIMC.3
Extended certificate
profile management
All changes to the
certificate Profile
The changes made to
the
Profile
Revocation Profile
Management
All changes to the
revocation profile
The changes made to
the Profile
6.8: Certificate
Revocation List Profile
Management
FMT_MOF_CIMC.5
Extended certificate
revocation list profile
management
All changes to the
certificate revocation list
profile
The changes made to
the profile
34
6.9: Online Certificate
Status
Protocol (OCSP)
Profile Management
FMT_MOF_CIMC.6
OCSP Profile
Management
All changes to the OCSP
profile
The changes made to
the Profile
Application Note_D:
Not applicable, since the
TOE does not provide
OCSP functionality.
FAU_GEN.2 User identity association (iteration 2)
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_SEL.1 Selective audit (iteration 2)
FAU_SEL.1.1 The TSF shall be able to select the set of events to be audited from the set of all auditable events
based on the following attributes:
a) [object identity, user identity, event type]
b) [no list of additional attributes that audit selectivity is based upon].
Application Note: For FAU_SEL.1.1a, the ST author should select whether the security attributes upon
which audit selectivity is based, is related to object identity, user identity, subject identity, host
identity, or event type. For FAU_SEL.1.1b, the ST author should specify any additional attributes upon
which audit selectivity is based.
Application Note_D: Done
FAU_STG.1 Protected audit trail storage (iteration 2)
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit trail from unauthorized deletion.
FAU_STG.1.2 The TSF shall be able to detect unauthorized modifications to the stored audit records in the audit
trail.
NOTE: One method of meeting the requirements of FAU_STG.1 is to write audit data directly to non-modifiable
media.
Application Note_D: The audit trail is protected by cryptographic means.
FAU_STG.4 Prevention of audit data loss (iteration 2)
FAU_STG.4.1 The TSF shall prevent auditable events, except those taken by the Auditor if the audit trail is full.
Application Note_D: If the audit trail is full the TOE shutdowns. In that case no role (even the Auditor) is able to
perform any actions apart from starting the TOE again. Thus neither role (even the Auditor) may further trigger
auditable events. Thus, the administrator first has to free up memory on the trail storage (not part of the TOE).
Otherwise the TOE will not start up again.
FPT_CIMC_TSP.1 Audit log signing event
FPT_CIMC_TSP.1.1 The TSF shall periodically create an audit log signing event in which it computes a
digital signature, keyed hash, or authentication code over the entries in the audit log.
FPT_CIMC_TSP.1.2 The digital signature, keyed hash, or authentication code shall be computed over, at least,
every entry that has been added to the audit log since the previous audit log signing event and the digital signature,
keyed hash, or authentication code from the previous audit log signed event.
35
FPT_CIMC_TSP.1.3 The specified frequency at which the audit log signing event occurs shall be configurable.
FPT_CIMC_TSP.1.4 The digital signature, keyed hash, or authentication code from the audit log signing event
shall be included in the audit log.
Dependencies: FAU_GEN.1 Audit data generation
FMT_MOF.1 Management of security functions behavior
Rationale: This component is necessary to specify a unique requirement for certificate issuing and management
components that is not addressed by existing CC requirements. It supports the security objective O.Protect stored audit
records, by providing additional protection for stored audit records.
7.2 Roles
The ability to perform many of the functions specified in this ST will be allocated to distinct roles to maintain the
security of the TOE.
FIA_ATD.1 User attribute definition
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [role].
FMT_MOF.1 Management of security functions behavior (iteration 2)
FMT_MOF.1.1 The TSF shall restrict the ability to modify the behavior of the functions listed in Table 7
to the authorized roles as specified in Table 7.
FMT_MSA.1 Management of security attributes
FMT_MSA.1.1 The TSF shall enforce the [the CIMC TOE Access Control Policy specified in section 9.1] to restrict
the ability to [modify, [no other operations]] the security attributes [role] to [Administrators].
FMT_MTD.1 Management of TSF data
FMT_MTD.1.1 The TSF shall restrict the ability to [modify, [no other operations]] the [Configurations and Profiles]
to [Administrators].
FMT_SMR.1 Security roles
FMT_SMR.1.1 The TSF shall maintain the roles [Administrators, Officers and Auditors].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Table 7 Authorized Roles for Management of Security Functions Behavior
Section/Function Component Function Authorized Role
36
6.1: Security Audit The capability to configure the audit parameters
shall be restricted to Administrators.
The capability to change the frequency of the
audit log signing event shall be restricted to
Administrators.
6.11: Certificate
Registration
The capability to approve fields or extensions
to be included in a certificate shall be restricted
to Officers.
If an automated process is used to approve
fields or extensions to be included in a
certificate, the capability to configure that
process shall be restricted to Officers.
Data Export and
Output
The export of CIMC private keys shall require
the authorization of at least two Administrators
or one Administrator and one Officer or Auditor.
Application Note_D: Not applicable, since the
TOE does not export CIMC private keys.
Certificate Status
Change Approval
Only Officers shall configure the automated
process used to approve the revocation of a
certificate or information about the revocation
of a certificate.
Only Officers shall configure the automated
process used to approve the placing of a
certificate on hold or information about the on
hold status of a certificate.
CIMC
Configuration
The capability to configure any TSF functionality
shall be restricted to Administrators. (This
requirement applies to all configuration
parameters unless the ability to configure that
aspect of the TSF functionality has been assigned
to a different role elsewhere in this document.)
6.8: Certificate
Profile Management
FMT_MOF_CIMC.3
Extended certificate profile
management
The capability to modify the certificate profile
shall be restricted to Administrators.
Revocation Profile
Management
The capability to modify the revocation profile
shall be restricted to Administrators.
6.9: Certificate
Revocation List
Profile Management
FMT_MOF_CIMC.5
Extended certificate
revocation list profile
management
The capability to modify the certificate
revocation list profile shall be restricted to
Administrators.
Online
Certificate Status
Protocol (OCSP)
Profile
Management
FMT_MOF_CIMC.6 OCSP
profile management
The capability to modify the OCSP profile shall
be restricted to Administrators.
Application Note_D: Not applicable, since the
TOE does not provide OCSP functionality.
7.3 Access Control
FDP_ACC.1 Subset access control (iteration 2)
FDP_ACC.1.1 The TSF shall enforce the CIMC TOE Access Control Policy specified in section 9.1 on
37
[subjects: Certificate Request, Certificate Revocation List Request; objects: certificates, CRLs and operations:
generate; among subjects and objects covered by the SFP].
Application Note: The terms object and subject refer to generic elements in the TSF. For a policy to be
implemented, these entities must be clearly identified. For most systems there is only one type of subject,
usually called a process or task, which needs to be specified in the ST. For a PP, the objects and
operations might be expressed as types such as: named objects, data repositories, observe accesses, etc.
The ST author should specify the list of subjects, objects, and operations among subjects and objects
covered by the SFP.
Application Note_D: Done
FDP_ACF.1 Security attribute based access control (iteration 2)
FDP_ACF.1.1 The TSF shall enforce the CIMC TOE Access Control Policy specified in section 9.1 to objects
based on the following: the identity of the subject and the role that the subject is authorized to assume.
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects
and controlled objects is allowed: specified in Table 8.
FDP_ACF.1.3 The TSF shall explicitly 37uthorize access of subjects to objects based on the following
additional rules: [no additional rules].
Application Note: The rules that govern the CIMC TOE Access Control Policy may vary between TOEs;
those rules need to be specified in the ST. The ST must list the attributes that are used for access
decisions. These attributes may include permission bits, access control lists, and object ownership. The
ST author should specify the rules, based on security attributes, that explicitly authorize access of
subjects to objects. These rules are in addition to those specified in FDP_ACF.1.1. They are included in
FDP_ACF.1.3 as they are intended to contain exceptions to the rules in FDP_ACF.1.1.
Application Note_D: No additional rules defined.
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following additional rules:
[no additional rules].
Application Note: The rules that govern the CIMC TOE Access Control Policy may vary between TOEs;
those rules need to be specified in the ST. The ST must list the attributes that are used for access
decisions. These attributes may include permission bits, access control lists, and object ownership. The
ST author should specify the rules, based on security attributes, that explicitly deny access of subjects to
objects. These rules are in addition to those specified in FDP_ACF.1.1. They are included in
FDP_ACF.1.4 as they are intended to contain exceptions to the rules in FDP_ACF.1.1.
Application Note_D: No additional rules defined.
Table 8 Access Controls
Section/Function Event
Certificate Request
Remote and Local
Data Entry
The entry of certificate request data shall be restricted to Officers and the subject
of the requested certificate.
Certificate Revocation
Request Remote and
Local Data Entry
The entry of certificate revocation request data shall
be restricted to Officers and the subject of the certificate to be revoked.
Data Export and
Output
The export or output of confidential and security-
relevant data shall only be at the request of authorized users.
Application Note_D: Not applicable, since the TOE does not export or output
confidential or security-
relevant data.
38
Key Generation The capability to request the generation of Component keys (used to protect data
in more than a single session or message) shall be restricted to Administrators.
Private Key Load The capability to request the loading of Component private keys into
cryptographic modules shall be restricted to Administrators.
Application Note_D: Not applicable, since the TOE does not load Component
private keys.
6.7.1: Private Key
Storage
The capability to request the decryption of certificate subject private keys shall be
restricted to Officers.
The TSF shall not provide a capability to decrypt certificate subject private keys
that may be used to generate digital signatures.
At least two Officers or one Officer and an Administrator or Auditor shall be
required to request the decryption of a certificate subject private key.
Application Note_D: Not applicable, since the TOE does not manage certificate
subject private keys.
Trusted Public Key
Entry, Deletion, and
Storage
The capability to change (add, revise, delete) the trusted public keys shall be
restricted to Administrators.
6.7.3: Secret Key
Storage
The capability to request the loading of CIMC secret keys into cryptographic
modules shall be restricted to Administrators.
Application Note_D: Not applicable, since the TOE generates and stores CIMC
secret keys in the environment.
6.7.4: Private and
Secret Key
Destruction
The capability to zeroize CIMC plaintext private
and secret keys shall be restricted to Administrators, Auditors and Officers.
6.7.5: Private and
Secret Key Export
The capability to export a component private key
shall be restricted to Administrators.
The capability to export certificate subject private keys shall be restricted to
Officers.
The export of a certificate subject private key shall require the authorization of at
least two Officers or one Officer and an Administrator or Auditor.
Application Note_D: Not applicable, since the TOE does neither export
component private keys nor nor subject private keys.
39
Certificate Status
Change Approval2
Only Officers and the subject of the certificate shall
be capable of requesting that a certificate be placed on hold.
Only Officers shall be capable of removing a certificate from on hold status.
Only Officers shall be capable of approving the placing of a certificate on hold.
Only Officers and the subject of the certificate shall be capable of requesting the
revocation of a certificate.
Only Officers shall be capable of approving the revocation of a certificate and all
information about the revocation of a certificate.
7.4 Identification and authentication
Identification and authentication includes recognizing an entity (e.g., user, device, or system) and verifying the
identity of that entity.
FIA_SOS.1 Verification of secrets (iteration 2)
FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [
1) For each attempt to use the authentication mechanism, the probability shall be less than one in
1,000,000 that a random attempt will succeed or a false acceptance will occur (e.g., guessing a password
or PIN, false acceptance error rate of a biometric device, or some combination of authentication methods.) and
2) For multiple attempts to use the authentication mechanism during a one-minute period, the
probability shall be less than one in 100,000 that a random attempt will succeed or a false acceptance will
occur].
FIA_UAU.1 Timing of authentication (iteration 2)
FIA_UAU.1.1 The TSF shall allow [requesting TOE state and requesting a challenge] on behalf of the user to be
performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-
mediated actions on behalf of that user.
FIA_UID.1 Timing of identification (iteration 2)
FIA_UID.1.1 The TSF shall allow [requesting TOE state and requesting a challenge] on behalf of the user to be
performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-
mediated actions on behalf of that user.
2 Every request to change certificate status, for example, revoke a certificate, place a certificate on hold, or remove a
certificate from hold must be accepted or rejected. If a request is accepted, any information about the request that
may be exported from the TOE must be approved. Approval may be manual or automated.
40
Application Note: FIA_UAU.1 and FIA_UID.1 allow the ST author to specify TSF-mediated actions that
may be performed on behalf of a user before that user is identified and/or authenticated. However, the
TSF shall not perform any security-relevant functions or export/output any confidential information on
behalf of a user before that user has been identified or authenticated. Examples of TSF-mediated actions
that may be performed on behalf of a user before that user is identified and/or authenticated include:
16) Responding to a request for public information (e.g., responding to an Online Certificate Status
Protocol (OCSP) request).
b) Accepting data from a user that will not be processed until an (identified and authenticated) authorized
user has accepted the data (e.g., a unauthenticated user may submit a certificate request message so
long as the certificate is not generated until after an Officer has approved the request).
Application Note_D: Before a user is identified and authenticated no TSF-mediated actions that are
security relevant are allowed.
FIA_USB.1 User-subject binding (iteration 2)
FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects acting on the behalf of
that user: [the role that a user is authorized to assume].
FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user security attributes with
subjects acting on the behalf of users: [A subject shall not have more rights than the associated role].
FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user security attributes associated
with subjects acting on the behalf of users: [none].
7.5 Remote Data Entry and Export
This section covers cases in which data is to be associated with a user who is not acting locally. In most cases, this
will involve data that has been received in a message that has been signed or that contains an authentication code or
keyed hash allowing the source of the message to be determined (in which case the data may be associated with the
source of the message). Data received over a secure communication channel (e.g., SSL) could be treated similarly.
The security requirements of remote data entry apply whenever data has been received from a remote source that is
considered reliable (i.e., the source of the information can be determined).
This section also specifies security requirements associated with the export of data from TOEs. The data may be
distributed to a device that is outside the boundary of a TOE (either locally or remotely). The remote device or computer
may not be directly connected to the TOE. Data export also applies when data is sent between physically distributed
subcomponents of a TOE (e.g., data sent between a CA and RA) and the data is transmitted over an untrusted network.
FCO_NRO_CIMC.3 Enforced proof of origin and verification of origin
FCO_NRO_CIMC.3.1 The TSF shall enforce the generation of evidence of origin for certificate status information
and all other security-relevant information at all times.
FCO_NRO_CIMC.3.2 The TSF shall be able to relate the identity and [no other attributes] of the originator of
the information, and the security-relevant portions of the information to which the evidence applies.
FCO_NRO_CIMC.3.3 The TSF shall verify the evidence of origin of information for all security-relevant
information.
Dependencies: FIA_UID.1 Timing of identification
Rationale: This component is necessary to specify a unique requirement for certificate issuing and management
components that is not addressed by existing CC requirements. It supports the security objective O.Non-repudiation
and O.Control unknown source communication traffic.
41
NOTE: Based on FCO_NRO_CIMC.3, the TSF shall reject any information whose origin cannot be verified
unless:
16) Acceptance of the information will not cause the TSF to perform any security relevant functions;
and
b) Acceptance of the data will not cause the TSF to output or export any confidential information.
The TSF may, for example, accept information whose origin cannot be verified in the following cases:
16) The received information is a request for public information (e.g., an Online Certificate Status
Protocol (OCSP) request).
b) The received information will not be processed until an authorized user has accepted its contents
(e.g., a certificate request). In this case, the received information may be processed as if it had
originated from the authorized user who approved it.
Application Note_D: In order to prevent replay FCO_NRO_CIMC.3.3 also comprises the verification if a given
challenge/identity matches or not.
FCO_NRO_CIMC.4 Advanced verification of origin
FCO_NRO_CIMC.4.1 The TSF shall, for initial certificate registration messages sent by the certificate subject,
only accept messages protected using an authentication code, keyed hash, or digital signature algorithm.
FCO_NRO_CIMC.4.2 The TSF shall, for all other security-relevant information, only accept the information if
it was signed using a digital signature algorithm.
Dependencies: FCO_NRO_CIMC.3
Rationale: This component is necessary to specify a unique requirement for certificate issuing and management
components that is not addressed by existing CC requirements. It supports the security objective O.Non-repudiation.
7.5.1 Certificate Status Export
All CIMCs must be capable of exporting certificate status information. Any message sent by a CIMC containing
certificate status information must meet the requirements for Certificate Status Export in addition to the requirements
for Data Export specified in Section 6.6.
The following requirements apply to Certificate Status Export.
FDP_CIMC_CSE.1 Certificate status export
FDP_CIMC_CSE.1.1 Certificate status information shall be exported from the TOE in messages whose format
complies with [the X.509 [ITU-T X.509] standard for CRLs].
Application Note: The ST should specify the format used to supply certificate status information. If a
standard format is not used, then the ST shall include a description of the format.
Application Note_D: A standard format is used.
Dependencies: No dependencies
Rationale: This component is necessary to specify a unique requirement for certificate issuing and management
components that is not addressed by the CC.
NOTE: As certificate status information is exported using the X.509 CRL format, the functional security requirements
FDP_CIMC_CRL.1 and FMT_MOF_CIMC.5 apply.
42
7.6 Key Management
Cryptographic keys are used by CIMCs for many different reasons: to ensure the integrity of messages sent over
untrusted networks, to authenticate users, to protect the confidentiality of private information, and to protect the
confidentiality of stored information such as audit logs. As such, the unauthorized modification, disclosure, or
substitution of any of these cryptographic keys could result in a loss of security.
Keys have a life cycle that begins with their generation. After generation, keys are stored, activated, deactivated, and
destroyed. In many cases, keys are backed up and audited. Typically, public keys are distributed.
7.6.1 Public Key Storage
This subsection specifies security requirements that are designed to detect the unauthorized modification of public keys
stored in a CIMC.
FDP_SDI_CIMC.3 Stored public key integrity monitoring and action
FDP_SDI_CIMC.3.1 Public keys stored within the CIMC, but not within a FIPS 140-2 validated cryptographic
module, shall be protected against undetected modification through the use of digital signatures, keyed hashes, or
authentication codes.
FDP_SDI_CIMC.3.2 The digital signature, keyed hash, or authentication code used to protect a public key
shall be verified upon each access to the key. If verification fails, the TSF shall [generate an audit log and not use this
public key].
Application Note: The ST should specify the actions to be taken in case the verification fails.
Application Note_D: Done
Dependencies: No dependencies
Rationale: This component is necessary to specify a unique requirement for certificate issuing and management
components that is not addressed by the CC.
7.6.2 Private and Secret Key Destruction
This section specifies requirements for the zeroization/destruction of plaintext private and secret keys stored within
CIMCs.
FCS_CKM_CIMC.5 CIMC private and secret key zeroization
FCS_CKM_CIMC.5.1 The TSF shall provide the capability to zeroize plaintext secret and private keys within
the environment and the TOE.
Dependencies: FCS_CKM.4 Cryptographic key destruction
FDP_ACF.1 Security attribute based access control
Rationale: This component is necessary to specify a unique requirement for certificate issuing and management
components that is not addressed by the CC.
7.6.3 Cryptographic operation of the TOE
FCS_CKM.1 Cryptographic key generation
43
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic
key generation algorithm [algorithms as defined in Table 2] and specified cryptographic key sizes [key sizes as
defined in Table 2] that meet the following: [standards as defined in Table 2].
Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic
operation] FCS_CKM.4 Cryptographic key destruction
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic
key destruction method [overwriting with zeros] that meets the following: [none].
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import
of user data with security attributes, or FCS_CKM.1 Cryptographic key
generation]
FCS_COP.1 Cryptographic operation
FCS_COP.1.1 The TSF shall perform [operations as defined in Table 3] in accordance with a specified
cryptographic algorithm [algorithms as defined in Table 3] and cryptographic key sizes [key sizes as defined in Table
3] that meet the following: [standards as defined in Table 3].
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import
of user data with security attributes, or FCS_CKM.1 Cryptographic key
generation] FCS_CKM.4 Cryptographic key destruction
FCS_RNG.1 Random Number Generation
FCS_RNG.1.1 The TSF shall provide a [deterministic] random number generator that implements:[
• (DRG.3.1) If initialized with a random seed [of 125 bit from the PTRNG of the CA
CARD], the internal state of the RNG shall have [125bit].
• (DRG.3.2) The RNG provides forward secrecy.
• (DRG.3.3) The RNG provides backward secrecy even if the current internal state is
known.]
FCS_RNG.1.2 The TSF shall provide random numbers that meet:[
• (DRG.3.4) The RNG, initialized with a random seed [from the PTRNG of the CA CARD],
generates output for which [2^19] strings of bit length 128 are mutually different with
probability [2^-10].
• (DRG.3.5) Statistical test suites cannot practically distinguish the random numbers from
output sequences of an ideal RNG. The random numbers must pass test procedure A
[[BSI-TEST-SUITE]]].
7.7 Certificate Profile Management
A certificate profile defines the set of acceptable values for fields and extensions in a certificate. Examples of
information that may be specified in a certificate profile include:
• constraints on the key owner’s identifier (e.g., subject and/or subjectAltName in X.509);
• the set of allowable algorithms for the subject’s public/private key pair;
• the certificate issuer’s identifier (e.g., issuer and/or issuerAltName in X.509);
• the limitations on the length of time for which the certificate is valid;
44
• additional information that may/must be included in a certificate (e.g., which extensions may/must be included
in an X.509 certificate);
• whether the subject of the certificate may be a CA;
• the types of operations that may be performed using the private key corresponding to the public key in the
certificate (e.g., possible values for keyUsage and/or extKeyUsage in X.509);
• the policy (policies) under which the certificate may/must be issued.
FMT_MOF_CIMC.3 Extended certificate profile management
FMT_MOF_CIMC.3.1 The TSF shall implement a certificate profile and shall ensure that issued certificates are
consistent with that profile.
FMT_MOF_CIMC.3.2 The TSF shall require the Administrator to specify the set of acceptable values for the
following fields and extensions:
• the key owner’s identifier;
• the algorithm identifier for the subject’s public/private key pair;
• the identifier of the certificate issuer;
• the length of time for which the certificate is valid;
FMT_MOF_CIMC.3.3 If the certificates generated are X.509 public key certificates, the TSF shall require the
Administrator to specify the set of acceptable values for the following fields and extensions:
• keyUsage;
• basicConstraints;
• certificatePolicies
FMT_MOF_CIMC.3.4 The Administrator shall specify the acceptable set of certificate extensions.
Dependencies: FMT_MOF.1 Management of security functions behavior
FMT_SMR.1 Security roles
Rationale: This component is necessary to specify a unique requirement of certificate issuing and management
components that is not addressed by the CC. It supports the security objective O.Configuration Management.
7.8 Certificate Revocation List Profile Management
A certificate revocation list profile is used to define the set of acceptable values for fields and extensions in
Examples of values that may be covered by a certificate revocation list profile include:
• extensions – the set of extensions that may/must be included in a CRL and the value of each extension’s
criticality bit.
• issuer, issuerAltName – the name of the CRL issuer.
• nextUpdate – a promise of next CRL in specified time.
FMT_MOF_CIMC.5 Extended certificate revocation list profile management
FMT_MOF_CIMC.5.1 If the TSF issues CRLs, the TSF must implement a certificate revocation list profile and
ensure that issued CRLs are consistent with the certificate revocation list profile.
45
FMT_MOF_CIMC.5.2 If the TSF issues CRLs, the TSF shall require the Administrator to specify the set of
acceptable values for the following fields and extensions:
• issuer;
• issuerAltName (NOTE: If a CIMC does not issue CRLs with this extension, then it is not required within the
certificate revocation list profile.)
• nextUpdate (i.e., a promise of next CRL in specified time).
FMT_MOF_CIMC.5.3 If the TSF issues CRLs, the Administrator shall specify the acceptable set of CRL and
CRL entry extensions.
Dependencies: FMT_MOF.1 Management of security functions behavior
FMT_SMR.1 Security roles
Rationale: This component is necessary to specify a unique requirement of certificate issuing and management
components that is not addressed by the CC. It supports the security objective O.Configuration Management.
7.9 Certificate Registration
The functions in this section address the validation, approval, and signing of public key certificates. X.509 public
key certificates issued by CIMCs must be compliant with the X.509 standard. Any fields or extensions to be
included in an X.509 certificate will either be created by the CIMC according to the rules of the X.509 standard or
validated by the CIMC to ensure compliance.
The data entered in each field and extension to be included in a certificate must be approved. Generally, a certificate
field or extension value may be approved in one of four ways:
1) The data may be approved manually by an Officer.
2) An automated process may be used to review and approve the data.
3) The value for a field or extension may be automatically generated by the CIMC.
4) The value for a field or extension may be taken from the certificate profile.
FDP_CIMC_CER.1 Certificate Generation
FDP_CIMC_CER.1.1 The TSF shall only generate certificates whose format complies with [the X.509 [ITU-T
X.509] standard for public key certificates and BSI TR-03110 [BSI TR-03110] standard].
Application Note: The ST should specify the format (or formats) used to generate certificates. If a
standard format is not used, then the ST shall include a description of the format.
Application Note_D: Only standard formats for certificate generation are used.
FDP_CIMC_CER.1.2 The TSF shall only generate certificates that are consistent with the currently defined
certificate profile.
FDP_CIMC_CER.1.3 The TSF shall verify that the prospective certificate subject possesses the private key that
corresponds to the public key in the certificate request before issuing a certificate, unless the public/private key pair
was generated by the TSF, whenever the private key may be used to generate digital signatures.
FDP_CIMC_CER.1.4 If the TSF generates X.509 public key certificates, it shall only generate certificates that
comply with requirements for certificates as specified in ITU-T Recommendation X.509. At a minimum, the TSF shall
ensure that:
a) The version field shall contain the integer 0, 1, or 2.
46
b) If the certificate contains an issuerUniqueID or subjectUniqueID then the version field shall contain the
integer 1 or 2.
c) If the certificate contains extensions then the version field shall contain the integer 2.
D) The serialNumber shall be unique with respect to the issuing Certification Authority.
e) The validity field shall specify a notBefore value that does not precede the current time and a notAfter
value that does not precede the value specified in notBefore.
f) If the issuer field contains a null Name (e.g., a sequence of zero relative distinguished names), then the
certificate shall contain a critical issuerAltName extension.
g) If the subject field contains a null Name (e.g., a sequence of zero relative distinguished names), then the
certificate shall contain a critical subjectAltName extension.
h) The signature field and the algorithm in the subjectPublicKeyInfo field shall contain the OID for a FIPS-
approved or recommended algorithm.
Dependencies: No dependencies
Rationale: This component is necessary to specify a unique requirement for certificate issuing and management
components that is not addressed by the CC.
7.10 Certificate Revocation
The functions in this section address the validation and approval of certificate revocation information.
7.10.1 Certificate Revocation List Validation
Certificate revocation lists (CRLs) issued by CIMCs shall be compliant with the X.509 standard. Any fields or
extensions to be included in a CRL shall be created by the CIMC according to the X.509 standard.
FDP_CIMC_CRL.1 Certificate revocation list validation
FDP_CIMC_CRL.1.1 A TSF that issues CRLs shall verify that all mandatory fields in any CRL issued contain
values in accordance with ITU-T Recommendation X.509. At a minimum, the following items shall be validated:
1. If the version field is present, then it shall contain a 1.
2. If the CRL contains any critical extensions, then the version field shall be present and contain the integer 1.
3. If the issuer field contains a null Name (e.g., a sequence of zero relative distinguished names), then the
CRL shall contain a critical issuerAltName extension.
4. The signature and signatureAlgorithm fields shall contain the OID for a FIPS-approved digital signature
algorithm.
5. The thisUpdate field shall indicate the issue date of the CRL.
6. The time specified in the nextUpdate field (if populated) shall not precede the time specified in the
thisUpdate field.
Dependencies: No dependencies
Rationale: This component is necessary to specify a unique requirement for certificate issuing and management
components that is not addressed by the CC.
Application Note_D: The chapter on “Strength of Function Requirements” from [CIMC PP], has been removed.
47
8 TOE SECURITY ASSURANCE REQUIREMENTS
The assurance requirements for the TOE are EAL 4 augmented with ALC_FLR.2 (flaw reporting procedures) as listed
in Table 9. Please refer to the CIMC PP [CIMC PP], Section 7, for a detailed description of these requirements.
These requirements are designed to provide evidence that the CIMC has been methodically designed, tested and
reviewed, and that it provides useful protection suitable for an environment requiring moderate to high confidence in
security of commercial products at a reasonable development and evaluation cost.
Application Note_D: This chapter has been reproduced from [CIMC PP]. Any changes from the text in [CIMC PP] are
clearly marked using grey background for the text or by Application Notes.
Table 9 Assurance Requirements
Requirement Class Requirement Component
ADV: Development ADV_ARC.1: Security architecture description
ADV_FSP.4: Complete functional specification
ADV_IMP.1 Implementation representation of the TSF
ADV_TDS.3: Basic modular design
AGD: Guidance documents AGD_OPE.1: Operational user guidance
AGD_PRE.1: Preparative procedures
ALC: Life-cycle support ALC_CMC.4: Production support, acceptance procedures
and automation
ALC_CMS.4: Problem tracking CM coverage
ALC_DEL.1: Delivery procedures
ALC_DVS.1 Identification of security measures\
ALC_FLR.2: Flaw reporting procedures
ALC_LCD.1 Developer defined life-cycle model
ALC_TAT.1 Well-defined development tools
ATE: Tests ATE_COV.2: Analysis of coverage
ATE_DPT.1 Testing: basic design
ATE_FUN.1: Functional testing
ATE_IND.2: Independent testing – sample
AVA: Vulnerability assessment AVA_VAN.3: Focused vulnerability analysis
48
9 RATIONALE
This section includes the rationale for the functional and assurance requirements specified for the TOE. The
rationale is based on specified objectives, threats, assumptions, and policies.
Application Note_D: This chapter has been reproduced from [CIMC PP]. Any changes from the text in [CIMC PP]
are clearly marked using grey background for the text or by Application Notes.
9.1 Security Objectives Rationale
This section demonstrates that the stated security objectives counter all identified threats, policies, or assumptions.
The following tables provide a mapping of security objectives to the environment defined by the threats, policies,
and assumptions, illustrating that each security objective covers at least one threat, policy or assumption and
that each threat, policy or assumption is covered by at least one security objective. Table 10 maps security objectives
for the TOE to threats and Table 11 maps security objectives for the environment to threats. Table 12 maps the
organizational security policies to security objectives. Table 13 maps assumptions to IT security objectives, listing
which objectives each assumption helps to cover. The items in the tables are ordered alphabetically, sorted on the
first column.
Table 10 Relationship of Security Objectives for the TOE to Threats
IT Security Objective Threat
Authorized Users
O.Certificates T.Administrators, Officers and Auditors commit
errors or hostile actions
O.Individual accountability and audit records T.Administrative errors of omission,
T.Hacker gains access,
T.Administrators, Officers and Auditors commit errors or
hostile actions,
T.User abuses authorization to collect and/or send data
O.Limitation of administrative access T.Disclosure of secret and private keys,
T.Administrators, Officers and Auditors commit errors or
hostile actions
O.Maintain user attributes T.Administrators, Officers and Auditors
commit errors or hostile actions
O.Restrict actions before authentication T.Hacker gains access,
T.Administrators, Officers and Auditors commit errors or
hostile actions
O.Security roles T.Administrators, Officers and Auditors
commit errors or hostile actions
System
O.React to detected attacks T.Hacker gains access
Cryptography
O.Non-repudiation T.Sender denies sending information
O.Integrity protection of user data T.Modification of private/secret keys,
T.Malicious code exploitation
External Attacks
O.Control unknown source communication traffic T.Hacker gains access
Management
49
O.Manage behavior of security functions T.Critical system component fails,
T.Administrators, Officers and Auditors commit errors or
hostile actions
Audit
O.Protect stored audit records T.Modification of secret/private keys,
T.Administrators, Officers and Auditors commit errors or
hostile actions
O.Respond to possible loss of stored audit records T.Administrators, Officers and Auditors
commit errors or hostile actions
O.Configuration Management T.Critical system component fails
T.Malicious code exploitation
Table 11 Relationship of Security Objectives for the Environment to Threats
Non-IT Security Objective Threat
OE.Administrators, Officers and Auditors
guidance documentation
T.Disclosure of private and secret keys,
T.Administrators, Officers and Auditors commit errors
or hostile actions,
T.Social engineering
OE.Competent Administrators, Officers and
Auditors
T.Administrators, Officers and Auditors
commit errors or hostile actions
OE.CPS T.Administrative errors of omission
OE.Detect modifications of firmware, software, and
backup data
T.User error makes data inaccessible,
T.Administrators, Officers and Auditors commit errors
or hostile actions
OE.HSM T.Disclosure of private and secret keys
OE.Installation T.Critical system component fails
OE.Lifecycle security T.Critical system component fails,
T.Malicious code exploitation
OE.Notify Authorities of Security Issues T.Hacker gains access
OE.Object and data recovery free from malicious code T.Modification of secret/private keys,
T.Malicious code exploitation
OE.Periodically check integrity T.Malicious code exploitation
OE.Physical Protection T.Hacker physical access
OE.Procedures for preventing malicious code T.Malicious code exploitation,
T.Social engineering
OE.Repair identified security flaws T.Flawed code,
T.Critical system component fails
OE.Require inspection for downloads T.Malicious code exploitation
OE.Security-relevant configuration management T.Administrative errors of omission
OE.Social Engineering Training T.Social Engineering
OE.Sufficient backup storage and effective restoration T.Critical system component fails,
T.User error makes data inaccessible
OE.Trusted Path T.Hacker gains access,
T.Message content modification
OE.Validation of security function T.Malicious code exploitation, T.Administrators,
Officers and Auditors
50
OE.Time stamps T.Critical system component fails,
T.Administrators, Officers and Auditors commit errors
or hostile actions
OE.Preservation/trusted recovery of secure state T.Critical system component fails
OE.Cryptographic functions T.Disclosure of private and secret keys,
T.Modification of secret/private keys
Table 12 Relationship of Organizational Security Policies to Security Objectives
Security Policy Objective
P.Authorized use of information OE.Auditors Review Audit Logs
O.Maintain user attributes
O.Restrict actions before authentication
O.Security roles
O.User authorization management
P.Cryptography OE.Cryptographic functions
Table 13 Relationship of Assumptions to IT Security Objectives
Assumption IT Security Objective
A.Auditors Review Audit Logs OE.Auditors Review Audit Logs
A.Authentication Data Management OE.Authentication Data Management
A.Communications Protection OE.Communications Protection
A.Competent Administrators, Officers and
Auditors
OE.Competent Administrators, Officers and
Auditors,
OE.Installation,
OE.Security-relevant configuration management
A.Cooperative Users OE.Cooperative Users
A.CPS OE.CPS,
OE.Security-relevant configuration
management
A.HSM OE.HSM
A.Disposal of Authentication Data OE.Disposal of Authentication Data
A.Malicious Code Not Signed OE.Procedures for preventing malicious code,
OE.Require inspection for downloads,
OE.Malicious Code Not Signed
A.Notify Authorities of Security Issues OE.Notify Authorities of Security Issues
A.Operating System OE.Operating System
A.Physical Protection OE.Physical Protection
A.Social Engineering Training OE.Social Engineering Training
9.1.1 Security Objectives Sufficiency
The following discussions provide information regarding:
Why the identified security objectives provide for effective countermeasures to the threats;
51
Why the identified security objectives provide complete coverage of each organizational security policy;
Why the identified security objectives uphold each assumption.
9.1.1.1 Threats and Objectives Sufficiency
9.1.1.1.1 Authorized users
T.Administrative errors of omission addresses errors that directly compromise organizational security objectives
or change the technical security policy enforced by the system or application. It is countered by:
OE.CPS provides Administrators, Officers, and Auditors with information regarding the policies and practices used
by the system. Providing this information ensures that these authorized users of the system are aware of their
responsibilities, thus reducing the likelihood that they will fail to perform a security-critical operation.
O.Individual accountability and audit records provides individual accountability for audited events. Each user
is uniquely identified so that auditable actions can be traced to a user. Audit records provide information about
past user behavior to an authorized individual through system mechanisms. These audit records will expose
administrators that fail to perform security-critical operations so they can be held accountable.
OE.Security-relevant configuration management ensures that system security policy data and enforcement
functions, and other security-relevant configuration data are managed and updated. This ensures that they are consistent
with organizational security policies and that all changes are properly tracked and implemented.
T.User abuses authorization to collect and/or send data addresses the situation where an authorized user abuses
granted authorizations by browsing files in order to collect data and/or violates export control policy by sending data
to a recipient who is not authorized to receive the data.
It is countered by:
O.Individual accountability and audit records provides individual accountability for audited events. Each user is
uniquely identified so that auditable actions can be traced to a user. Audit records provide information about past
user behavior to an authorized individual through system mechanisms. This audit records will expose users who abuse
their authorized to collect and/or send data.
T.User error makes data inaccessible addresses a user accidentally deleting user data. Consequently, the user data is
inaccessible. Examples include the following:
User accidentally deletes data by striking the wrong key on the keyboard or by striking the enter key as an automatic
response.
User does not understand the implications of the prompt at hand and inadvertently gives a response that deletes user
data.
User misunderstands a system command and issues a command that unintentionally deletes user data.
It is countered by:
OE.Sufficient backup storage and effective restoration ensures that there is sufficient backup storage and effective
restoration to recreate the system, when required. This ensures that user data is available from backup, even if the
current copy is accidentally deleted.
OE.Detect modifications of firmware, software, and backup data ensures that if the backup components have been
modified, that it is detected. If modifications of backup data cannot be detected, the backup copy is not a reliable source
for restoration of user data.
T.Administrators, Officers and Auditors commit errors or hostile actions addresses:
52
Errors committed by administrative personnel that directly compromise organizational security objectives, change
the technical security policy enforced by the system or application, or Malicious obstruction by administrative
personnel of organizational security objectives or modification of the system’s configuration to allow security
violations to occur.
It is countered by:
OE.Competent Administrators, Officers and Auditors ensures that users are capable of maintaining effective
security practices. This reduces the likelihood that they will commit errors.
OE.Administrators, Officers and Auditors guidance documentation which deters administrative personnel errors
by providing adequate guidance.
O.Certificates ensures that certificates, certificate revocation lists, and certificate status information are valid. The
validation of information provided by Officers that is to be included in certificates helps to prevent improperly
entered information from appearing in certificates.
OE.Detect modifications of firmware, software, and backup data ensures that if the backup components have been
modified, that it is detected.
O.Individual accountability and audit records provides individual accountability for audited events. Each user is
uniquely identified so that auditable actions can be traced to a user. Audit records provide information about past
user behavior to an authorized individual through system mechanisms. These audit records will expose administrators
that perform inappropriate operations so they can be held accountable.
O.Limitation of administrative access. The administrative functions are designed in such a way that administrative
personnel do not automatically have access to user objects, except for necessary exceptions. In general, the exceptions
tend to be role specific. Limiting the set of operations that a user may perform limits the damage that a user may cause.
O.Maintain user attributes. Maintains a set of security attributes (which may include group membership, access
rights, etc.) associated with individual users in addition to user identity. This prevents users from performing operations
that they are not authorized to perform.
O.Manage behavior of security functions provides management controls/functions for security mechanisms. This
ensures that security mechanisms which protect against hostile users are properly configured.
O.Protect stored audit records ensures that audit records are protected against unauthorized access, modification,
or deletion to provide for traceability of user actions.
O.Respond to possible loss of stored audit records ensures that only auditable events executed by the Auditor
shall be audited if the audit trail is full. This ensures that operations that are performed by users other than the Auditor
are audited and so can be detected.
O.Restrict actions before authentication ensures that only a limited set of actions may be performed before a user
is authenticated.
O.Security roles ensures that security-relevant roles are specified and that users are assigned to one (or more) of the
defined roles. This prevents users from performing operations that they are not authorized to perform.
OE.Time stamps ensures that time stamps are provided to verify a sequence of events. This allows the reconstruction
of a timeline of events when performing an audit review.
OE.Validation of security function. Ensure that security-relevant software, hardware, and firmware are correctly
functioning through features and procedures such as underlying machine testing and integrity checks.
53
9.1.1.1.2 System
T.Critical system component fails addresses the failure of one or more system components that results in the loss
of system-critical functionality. This threat is relevant when there are components that may fail due to hardware and/or
software imperfections and the availability of system functionality is important.
It is countered by:
O.Configuration Management assures that a configuration management program is implemented. The configuration
management program includes configuration identification and change control. This ensures that critical system
components do not fail as a result of improper configuration.
OE.Installation ensures that the TOE is delivered, installed, managed, and operated in a manner which maintains IT
security. This ensures that critical system components do not fail as a result of improper installation.
O.Manage behavior of security functions provides management controls/functions for security mechanisms. This
ensures that critical system components do not fail as a result of improper configuration of security mechanisms.
OE.Preservation/trusted recovery of secure state ensures that the system remains in a secure state throughout
operation in the presence of failures and subsequent system recovery. This objective is relevant when system failures
could result in insecure states that, when the system returns to operational mode (or continues to operate), could lead
to security compromises.
OE.Sufficient backup storage and effective restoration ensures that there is sufficient backup storage and effective
restoration to recreate the system, when required. This ensures that data is available from backup, even if the current
copy is lost through failure of a system component (e.g., a disk drive).
OE.Time stamps provides time stamps to ensure that the sequencing of events can be verified. If the system must be
reconstructed, it may be necessary to establish the order in which transactions were performed to return the system
to a state consistent with the state when a critical component failed.
OE.Lifecycle security provides tools and techniques that are used throughout the development phase reducing the
likelihood of hardware or software imperfections. OE.Lifecycle security also addresses the detection and resolution
of flaws discovered during the operational phase that may result in failure of a critical system component.
OE.Repair identified security flaws. The vendor repairs security flaws that have been identified by a user. Such
security flaws may result in critical system component failures if not repaired.
T.Flawed code addresses accidental or deliberate flaws in code made by the developer. Examples of accidental
flaws are lack of engineering detail or bad design. An example of a deliberate flaw would be the inclusion of a trapdoor
for later entry into the TOE.
It is countered by:
OE.Repair identified security flaws ensures that identified security flaws are repaired.
T.Malicious code exploitation addresses the threat where an authorized user, IT system, or hacker downloads and
executes malicious code, which causes abnormal processes that violate the integrity, availability, or confidentiality
of the system assets. The execution of malicious code is done through a triggering event.
It is countered by:
O.Configuration Management assures that a configuration management program is implemented. The configuration
management program includes configuration identification and change control. This ensures that malicious code is not
introduced during the configuration process.
54
O.Integrity protection of user data ensures that appropriate integrity protection is provided for user data. This
prevents malicious code from attaching itself to user data.
OE.Object and data recovery free from malicious code ensures that the system recovers to a viable state after
malicious code has been introduced and damage has occurred. The malicious code, e.g., virus or worm, is removed
as part of the process.
OE.Periodically check integrity ensures that periodic integrity checks are performed on both system and software. If
these checks fail, malicious code may have been introduced into the system.
OE.Procedures for preventing malicious code provides a set of procedures and mechanisms that work to prevent
incorporation of malicious code into the system.
OE.Require inspection for downloads ensures that software that is downloaded/transferred is inspected prior to
being made operational.
OE.Validation of security function. Ensure that security-relevant software, hardware, and firmware are correctly
functioning through features and procedures such as underlying machine testing and integrity checks.
OE.Lifecycle security provides tools and techniques that are used throughout the development phase, reducing the
likelihood that malicious code was included in the product by the developer. OE.Lifecycle security also addresses the
detection and resolution of flaws discovered during the operational phase, such as modifications of components by
malicious code.
OE.Malicious Code Not Signed protects the TOE from malicious code by ensuring all code is signed by a trusted
entity prior to loading it into the system.
T.Message content modification addresses the situation where a hacker modifies information that is intercepted
from a communications link between two unsuspecting entities before passing it on to the intended recipient. Several
kinds of modification are possible: modification of a single message, deletion or reordering of selected messages,
insertion of bogus messages, replay of previous messages, and modification of accompanying message security
attributes.
It is countered by:
OE.Trusted Path ensures that a trusted path is established between the user and the system. The trusted path protects
messages from interception or modification by a hacker.
9.1.1.1.3 Cryptography
T.Disclosure of private and secret keys addresses the unauthorized disclosure of secret and/or private keys.
It is countered by:
OE.Administrators, Officers and Auditors guidance documentation ensures that adequate documentation on
securely configuring and operating the CIMC is available to Administrators, Officers and Auditors. This documentation
will minimize errors committed by those users.
OE.Cryptographic functions ensures that TOE environment provides cryptographic algorithms for
encryption/decryption, key-generation, authentication, and signature generation/verification;
O.Limitation of administrative access. The administrative functions are designed in such a way that administrative
personnel do not automatically have access to user objects, except for necessary exceptions. In general, the exceptions
tend to be role specific. Limiting the number of users who have access to cryptographic keys reducing the likelihood
of unauthorized disclosure.
OE.HSM ensures that a subset of the relevant key material can be securely created, stored and used in the environment
of the TOE. Please refer to chapter 1.2.1.1 for an overview of the smart cards and their provided functionality.
55
T.Modification of private/secret keys addresses the unauthorized revision of a secret and/or private key.
It is countered by:
OE.Cryptographic functions ensures that TOE environment provides approved cryptographic algorithms for
encryption/decryption, authentication, and signature generation/verification; approved key generation techniques
and uses validated cryptographic modules. Use of validated cryptographic modules ensures that cryptographic keys are
adequately protected when they are stored within cryptographic modules.
O.Integrity protection of user data that ensures that appropriate integrity protection is provided for ensures that
appropriate integrity protection is provided for user data.
OE.Object and data recovery free from malicious code ensures that the system recovers to a viable state after
malicious code has been introduced and damage has occurred. If the malicious code cause private or secret keys to
be revised in an unauthorized manner, this objective ensures that they are recovered to their correct values.
O.Protect stored audit records ensures that audit records are protected against unauthorized access, modification,
or deletion to provide for traceability of user actions. This objective ensures that modifications to private and secret
keys can be detected through the audit trail.
T.Sender denies sending information addresses the situation where the sender of a message denies sending the
message to avoid accountability for sending the message and for subsequent action or inaction.
It is countered by:
O.Non-repudiation which ensures that the sender/originator of a message cannot successfully deny sending the
message to the recipient.
9.1.1.1.4 External Attacks
T.Hacker gains access addresses:
Weak system access control mechanisms or user attributes
Weak implementation methods of the system access control
Vulnerabilities found in system or application code that allow a hacker to break into a system undetected.
It is countered by:
O.Restrict actions before authentication ensures that only a limited set of actions may be performed before a user
is authenticated. This prevents a hacker who is unable to circumvent the access control mechanisms from performing
security-relevant operations.
O.Control unknown source communication traffic ensures that communication traffic from an unknown source is
controlled (e.g., rerouted or discarded) to prevent potential damage. Various kinds of hacker attacks can be detected or
prevented by rerouting or discarding suspected hacker traffic.
O.Individual accountability and audit records provides individual accountability for audited events. Each user is
uniquely identified so that auditable actions can be traced to a user. Audit records provide information about past
user behavior to an authorized individual through system mechanisms. This allows for the detection of unauthorized
activity. Once detected, the damage resulting from such activity can be eliminated or mitigated.
OE.Notify Authorities of Security Issues ensures that proper authorities are notified regarding any security issues
that impact their systems. This minimizes the potential for the loss or compromise of data.
56
O.React to detected attacks ensures that automated notification or other reactions to the TSFdiscovered attacks is
implemented in an effort to identify attacks and to create an attack deterrent. This objective is relevant if actions that
the organization deems essential also pose a potential attack that could be exploited.
OE.Trusted Path ensures that a trusted path is established between the user and the system. The trusted path is used
to protect authentication data, thus reducing the likelihood that a hacker can masquerade as an authorized user.
T.Hacker physical access addresses the threat where an individual exploits physical security weaknesses to gain
physical control of system components.
It is countered by:
OE.Physical Protection ensures that physical access controls are sufficient to thwart a physical attack on system
components.
T.Social Engineering addresses the situation where a hacker uses social engineering techniques to gain information
about system entry, system use, system design, or system operation.
It is countered by:
OE.Administrators, Officers and Auditors guidance documentation which deters administrative personnel errors
by providing adequate guidance.
OE.Procedures for preventing malicious code provides a set of procedures and mechanisms that work to prevent
incorporation of malicious code into the system. The introduction of malicious code into the system may be a goal
of the social engineering attack.
OE.Social Engineering Training which ensures that general users, Administrators, Officers, and Auditors are trained
in techniques to thwart social engineering attacks.
9.1.1.2 Policies and Objectives Sufficiency
P.Authorized use of information establishes that information is used only for its authorized purpose(s). This is
addressed by the following objectives: O.Maintain user attributes, O.Restrict actions before authentication,
O.Security roles, and O.User authorization management. O.Restrict actions before authentication ensures that
the capability to perform security-relevant operations is limited to those who have been authorized to perform those
operations. O.Maintain user attributes, O.Security roles, and O.User authorization management ensure that users
are only authorized to perform those operations that are necessary to perform their Jobs. Finally, OE.Auditors Review
Audit Logs deters users from misusing the authorizations they have been provided.
P.Cryptography establishes that accepted cryptographic standards and operations shall be used in the design of the
TOE environment. This is addressed by OE.Cryptographic functions which ensures that such standards are used.
9.1.1.3 Assumptions and Objectives Sufficiency
9.1.1.3.1 Personnel
A.Auditors Review Audit Logs establishes that audit logs are necessary for security-relevant events and that they
must be reviewed by auditors. This is addressed by OE.Auditors Review Audit Logs, which ensures that security-
relevant events recorded in audit logs are reviewed by auditors.
57
A.Authentication Data Management establishes that management of user authentication data is external to the TOE.
This is addressed by OE.Authentication Data Management, which ensures that users modify their authentication
data in accordance with appropriate security policy.
A.Competent Administrators, Officers and Auditors establishes that security of the TOE is dependent upon those
that manage it. This is addressed by OE.Competent Administrators, Officers and Auditors, which ensures that the
system managers will be competent in its administration. OE.Installation further specifies that those responsible for
the TOE must ensure that the TOE is delivered, installed, managed, and operated in a manner which maintains IT
security. OE.Security-relevant configuration management further specifies that system security policy data and
enforcement functions, and other security-relevant configuration data must be managed and updated, to ensure they
are consistent with organizational security policies.
A.CPS establishes that Administrators, Officers, and Auditors are familiar with the CP and CPS under which the TOE
is operated. This is addressed by OE.CPS, which ensures that Administrators, Officers, and Auditors are familiar
with the CP and CPS under which the TOE is operated. OE.Security-relevant configuration management further
specifies that system security policy data and enforcement functions, and other security-relevant configuration data
shall be managed and updated, to ensure they are consistent with organizational security policies.
A.Disposal of Authentication Data establishes that users shall not retain access to the system after their authorization
has been removed. This is addressed by OE.Disposal of Authentication Data, which ensures that access to the
system will be denied after a user’s privileges have been removed.
A.HSM requires that the smart cards in the environment must only be used exclusively by the TOE. That is no other
IT component is allowed to use the smart cards. This is addressed by
A.Malicious Code Not Signed establishes that code not designed for the TOE will not be signed by a trusted party.
This is addressed by OE.Malicious Code Not Signed, which ensures that code must be signed by a trusted party or it
will not be loaded onto the system. OE.Procedures for preventing malicious code and OE.Require inspection for
downloads further specifies that malicious code prevention procedures and mechanisms shall be incorporated, for
example during donwloads/transfers.
A.Notify Authorities of Security Issues establishes that users notify proper authorities of any security issues that
impact their systems to minimize the potential for the loss of compromise of data. This is addressed by OE.Notify
Authorities of Security Issues which ensures that user notify proper authorities of any security issues that impact
their systems.
A.Social Engineering Training establishes that individuals will attempt to gain access to the system using social
engineering practices. This is addressed by OE.Social Engineering Training, which ensures that all users will be
training to thwart social engineering attacks.
A.Cooperative Users establishes that a secure IT environment is required to securely operate the TOE, and that
users must work within the constraints of that environment. This is addressed by OE.Cooperative Users, which
ensures that users will cooperate with the constraints established.
9.1.1.3.2 Connectivity
A.Operating System establishes that an insecure operating system will compromise system security. This is addressed
by OE.Operating System, which ensures that an operating system that meets security requirements recommended by
the National Institute of Standards and Technology will be used.
9.1.1.3.3 Physical
A.Communications Protection establishes that the communications infrastructure is outside the TOE. This is
addressed by OE.Communications Protection, which ensures that adequate physical protections are afforded the
necessary communications infrastructure.
58
A.Physical Protection establishes that physical modification of the TOE and non TOE hardware, software, and
firmware will compromise system security. This is addressed by OE.Physical Protection, which ensures that adequate
physical protection will be provided.
9.2 Security Requirements Rationale
This section provides the rationale for necessity and sufficiency of security requirements, demonstrating that each of
the security objectives is addressed by at least one security requirement, and that every security functional requirement
is directed toward solving at least one objective.
9.2.1 Security Requirements Coverage
The following tables provide a mapping of the relationships of security requirements to objectives, illustrating that
each security requirement covers at least one objective and that each objective is covered by at least one security
requirement. The first table in this section, Table 14, addresses the mapping of security functional requirements to
security objectives.
Table 14 Security Functional Requirements Related to Security Objectives
Functional Requirement Objective
FAU_GEN.1 Audit data generation (iteration 2) O.Individual accountability and audit records
OE.Time stamps
FAU_GEN.2 User identity association (iteration 2) O.Individual accountability and audit records
FAU_SEL.1 Selective audit (iteration 2) O.Individual accountability and audit records
FAU_STG.1 Protected audit trail storage (iteration 2) O.Protect stored audit records
FAU_STG.4 Prevention of audit data loss (iteration 2) O.Respond to possible loss of stored audit records
FCO_NRO_CIMC.3 Enforced proof of origin and
verification of origin
O.Non-repudiation, O.Control unknown source
communication traffic
FCO_NRO_CIMC.4 Advanced verification of origin O.Non-repudiation
FCS_CKM_CIMC.5 CIMC private and secret key
zeroization
OE.Procedures for preventing malicious code, O.React
to detected attacks
FCS_CKM.1 Cryptographic key generation O.Integrity protection of user data
FCS_CKM.4 Cryptographic key destruction O.Integrity protection of user data
FCS_RNG.1 Random Number Generation O.Integrity protection of user data
FCS_COP.1 Cryptographic operation O.Integrity protection of user data
FDP_ACC.1 Subset access control (iteration 2) O.Limitation of administrative access
FDP_ACF.1 Security attribute based access control
(iteration 2)
O.Limitation of administrative access
FDP_CIMC_CER.1 Certificate Generation O.Certificates
FDP_CIMC_CRL.1 Certificate revocation list validation O.Certificates
FDP_CIMC_CSE.1 Certificate status export O.Certificates
FDP_SDI_CIMC.3 Stored public key integrity
monitoring and action
O.Integrity protection of user data
FIA_ATD.1 User attribute definition O.Maintain user attributes
59
FIA_SOS.1 Verification of secrets (iteration 2) O.Limitation of administrative access
O.React to detected attacks
FIA_UAU.1 Timing of authentication (iteration 2) O.Limitation of administrative access, O.Restrict
actions
before authentication
FIA_UID.1 Timing of identification (iteration 2) O.Individual accountability and audit records,
O.Limitation of administrative access
FIA_USB.1 User-subject binding (iterations 2) O.Maintain user attributes
FMT_MOF.1 Management of security functions
behavior (iteration 2)
O.Configuration Management, O.Manage behavior of
Security functions, O.Security-relevant configuration
management
FMT_MOF_CIMC.3 Extended certificate profile
management
O.Configuration Management
FMT_MOF_CIMC.5 Extended certificate revocation list
profile management
O.Configuration Management
FMT_MSA.1 Management of security attributes O.Maintain user attributes, O.User authorization
management
FMT_MTD.1 Management of TSF data O.Individual accountability and audit records,
O.Protect stored audit records
FMT_SMR.1 Security roles O.Security roles
FPT_CIMC_TSP.1 Audit log signing event O.Protect stored audit records
9.2.2 Security Requirements Sufficiency
9.2.2.1 Security Objectives for the TOE
9.2.2.1.1 Authorized Users
O.Certificates is provided by FDP_CIMC_CER.1 (Certificate Generation) which ensures that certificates are
valid, and FDP_CIMC_CRL.1 (Certificate revocation list validation) and FDP_CIMC_CSE.1 (Certificate
status export) which ensure that certificate revocation lists and certificate status information are valid.
O.Individual accountability and audit records is provided by a combination of requirements. FIA_UID.1
(Timing of identification) (iteration 2) covers the requirement that users be identified before performing any
security-relevant operations. FAU_GEN.1 (Audit data generation) (iterations 2) and FAU_SEL.1 (Selective
audit) (iterations 2) cover the requirement that security-relevant events be audited with date and time in the audit
records while FAU_GEN.2 (User identity association) (iterations 2) cover the requirement that audit records
contain identities of the entities responsible for the actions. FMT_MTD.1 (Management of TSF data) covers
the requirement that audit data be available for review by ensuring that users, other than Auditors, cannot delete
audit logs.
O.Limitation of administrative access is provided by FDP_ACC.1 (Subset access control) (iteration 2),
FDP_ACF.1 (Security attribute based access control) (iteration 2), FIA_SOS.1 (Verification of secrets)
(iteration 2), FIA_UAU.1 (Timing of authentication) (iteration 2), and FIA_UID.1 (Timing of identification)
(iteration 2). FIA_UAU.1 (Timing of authentication) (iteration 2), FIA_SOS.1 (Verification of secrets)
(iteration 2), and FIA_UID.1 (Timing of identification) (iteration 2) ensure that Administrators, Officers, and
Auditors cannot perform any security-relevant operations until they have been identified and authenticated and
FDP_ACC.1 (Subset access control) (iteration 2) and FDP_ACF.1 (Security attribute based access control)
(iteration 2) ensure that Administrators, Officers, and Auditors can only perform those operations necessary to
perform their Jobs.
O.Maintain user attributes is provided by FIA_ATD.1 (User attribute definition) and FIA_USB.1 (User-
subject binding) (iteration 2) which cover the requirement to maintain a set of security attributes associated with
individual users and/or subjects acting on users’ behalves. FMT_MSA.1 (Management of security attributes)
ensures that only authorized users can modify security attributes.
60
O.Restrict actions before authentication is provided by FIA_UAU.1 (Timing of authentication) (iteration
2) which covers the requirement that no security-relevant actions are performed on behalf of a user until that
user has been authenticated.
O.Security roles is provided by FMT_SMR.1 (Security roles) which covers the requirement that a set of security
roles be maintained and that users be associated with those roles.
O.User authorization management is provided by FMT_MSA.1 (Management of security attributes) which
covers the requirement that Administrators manage and update user’s security attributes.
9.2.2.1.2 System
O.React to detected attacks is provided by FCS_CKM_CIMC.5 (CIMC private and secret key zeroization)
which cover the requirement that the user who detected the attack be able to destroy any plaintext keys within the
TOE in order to prevent the attacker from obtaining copies of these keys. FIA_SOS.1 (Verification of secrets)
(iteration 2) covers the requirement that the TSF respond to detected attacks (in the form of repeated authentication
attempts) by taking actions to prevent the attacker from successfully authenticating him/herself. In the case that
an attack is detected by an Administrator, Auditor or Officer.
9.2.2.1.3 External Attacks
O.Control unknown source communication traffic is provided by FCO_NRO_CIMC.3 (Enforced proof of
origin and verification of origin) which covers the requirement that the TOE discard messages from an unknown
source that contain security-relevant information.
9.2.2.1.4 Cryptography
O.Non-repudiation is provided by FCO_NRO_CIMC.3 (Enforced proof of origin and verification of origin)
which covers the requirement that messages containing security-relevant data are not accepted by the TOE unless
they contain evidence of origin and FCO_NRO_CIMC.4 (Advanced verification of origin) which covers the
requirement that digital signatures be used so that the evidence of origin for a message may be verified by a third-
party.
O.Integrity protection of user data is provided by FDP_SDI_CIMC.3 (Stored public key integrity monitoring
and action) which cover the requirement that user data be protected. Also FCS_CKM.1, FCS_CKM.5 and
FCS_COP.1 contribut to the implementation of this objective as these requirements model the cryptographic
functionality provided by the TOE.
9.2.2.1.5 Management
O.Manage behavior of security functions is provided by FMT_MOF.1 (Management of security functions
behavior) (iteration 2) which covers the requirement that authorized users be able to configure, operate, and maintain
the security mechanisms.
O.Configuration Management is provided by FMT_MOF.1 (Management of security functions behavior)
(iteration 2) which covers the requirement that only authorized users can change the configuration of the system.
FMT_MOF_CIMC.3 (Extended certificate profile management) covers the requirement that Administrators be
able to control the types of information that are included in generated certificates. FMT_MOF_CIMC.5 (Extended
certificate revocation list profile management) covers the requirement that Administrators be able to control to
the types of information that are included in generated certificate revocation lists.
9.2.2.1.6 Audit
O.Protect stored audit records is provided by FAU_STG.1 (Protected audit trail storage) (iteration 2) which
covers the requirement that audit records be protected against modification or unauthorized deletion and
FMT_MTD.1 (Management of TSF data) which covers the requirement that audit records be protected from
61
unauthorized access. Where the threat of malicious activity is greater, FPT_CIMC_TSP.1 (Audit log signing event)
is required so that modifications to the audit logs can be detected.
O.Respond to possible loss of stored audit records is provided by FAU_STG.4 (Prevention of audit data loss)
(iteration 2) which covers the requirement that no auditable events, except those taken by the Auditor, can be
performed when audit trail storage is full.
9.3 Requirement Dependency Rationale
This section demonstrates that the stated security requirements together form a mutually supportive and internally
consistent whole. Internal consistency is demonstrated in an analysis of dependencies. Mutual support is shown
through consideration of the interactions between and among the SFRs.
9.3.1 Rationale that Dependencies are satisfied
The selected security requirements include related dependencies, both direct and indirect. The indirect dependencies
are those required by the direct dependencies. All of these dependencies must be met or their exclusion justified.
9.3.1.1 Security Functional Requirements Dependencies
The following table provides a summary of the security functional requirements dependency analysis.
Table 15 Summary of Security Functional Requirements Dependencies
Component Dependencies Which is:
FAU_GEN.1 Audit data generation
(iteration 2)
FPT_STM.1 Reliable time stamps Not included
FAU_GEN.2 User identity association
(iteration 2)
FAU_GEN.1 Audit data generation FAU_GEN.1 Audit data
generation (iteration 2)
FIA_UID.1 Timing of identification FIA_UID.1 Timing of
identification (iteration 2)
FAU_SEL.1 Selective audit (iteration
2)
FAU_GEN.1 Audit data generation FAU_GEN.1 Audit data
generation (iteration 2)
FMT_MTD.1 Management of TSF
data
FMT_MTD.1 Management of
TSF data
FAU_STG.1 Protected audit trail
storage (iteration 2)
FAU_GEN.1 Audit data generation FAU_GEN.1 Audit data
generation (iteration 2)
FAU_STG.4 Prevention of audit data
loss (iteration 2)
FAU_STG.1 Protected audit trail
storage
FAU_STG.1 Protected audit trail
storage (iteration 2)
FCO_NRO_CIMC.3 Enforced proof
of origin and verification of origin
FIA_UID.1 Timing of identification FIA_UID.1 Timing of
identification (iteration 2)
FCO_NRO_CIMC.4 Advanced
verification of origin
FCO_NRO_CIMC.3 FCO_NRO_CIMC.3 Enforced
proof of origin and verification of
origin
FCS_CKM_CIMC.5 CIMC private
and secret key zeroization
FCS_CKM.4 Cryptographic key
destruction
Not included
FDP_ACF.1 Security attribute based
access control
FDP_ACF.1 Security attribute
based
access control (iteration 2)
FCS_CKM.1 Cryptographic key
generation
FCS_CKM.2 Cryptographic key
distribution, or FCS_COP.1
Cryptographic operation
FCS_COP.1 Cryptographic
operation
62
FCS_CKM.4 Cryptographic key
destruction
FCS_CKM.4 Cryptographic key
destruction
FCS_CKM.4 Cryptographic key
destruction
FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or FCS_CKM.1
Cryptographic key generation
FCS_CKM.1 Cryptographic key
generation
FCS_RNG.1 Random Number
Generation
None
FCS_COP.1 Cryptographic operation FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or FCS_CKM.1
Cryptographic key generation]
FCS_CKM.1 Cryptographic key
generation
FCS_CKM.4 Cryptographic key
destruction
FCS_CKM.4 Cryptographic key
destruction
FDP_ACC.1 Subset access control
(iteration 2)
FDP_ACF.1 Security attribute based
access control
FDP_ACF.1 Security attribute
based
access control (iteration 2)
FDP_ACF.1 Security attribute based
access control (iteration 2)
FDP_ACC.1 Subset access control FDP_ACC.1 Subset access
control (iteration 2)
FMT_MSA.3 Static attribute
initialization
Not included
FDP_CIMC_CER.1 Certificate
Generation
None
FDP_CIMC_CRL.1 Certificate
revocation list validation
None
FDP_CIMC_CSE.1 Certificate status
export
None
FDP_SDI_CIMC.3 Stored public key
integrity monitoring and action
None
FIA_ATD.1 User attribute definition None
FIA_SOS.1 Verification of secrets
(iteration 2)
None
FIA_UAU.1Timing of Authentication
(iteration 2)
FIA_UID.1 Timing of identification FIA_UID.1 Timing of
identification (iteration 2)
FIA_UID.1 Timing of identification
(iteration 2)
None
FIA_USB.1 User-subject binding FIA_ATD.1 User attribute definition FIA_ATD.1 User attribute
definition
FMT_MOF.1 Management of security
functions behavior (iteration 2)
FMT_SMR.1 Security roles FMT_SMR.1 Security roles
FMT_SMF.1 Specification of
Management Functions
Not included
FMT_MOF_CIMC.3 Extended
certificate profile management
FMT_MOF.1 Management of security
functions behavior
FMT_MOF.1 Management of
security functions behavior
(iteration 2)
FMT_SMR.1 Security roles FMT_SMR.1 Security roles
FMT_MOF.1 Management of security
functions behavior
FMT_MOF.1 Management of
security functions behavior
(iteration 2)
63
FMT_MOF_CIMC.5 Extended
certificate revocation list profile
management
FMT_SMR.1 Security roles FMT_SMR.1 Security roles
FMT_MSA.1 Management of security
attributes
FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow
control
FDP_ACC.1 Subset access
control (iteration 2)
FMT_SMR.1 Security roles FMT_SMR.1 Security roles
FMT_SMF.1 Specification of
Management Functions
Not included
FMT_MTD.1 Management of TSF
data
FMT_SMR.1 Security roles FMT_SMR.1 Security roles
FMT_SMF.1 Specification of
Management Functions
Not included
FMT_SMR.1 Security roles FIA_UID.1 Timing of identification FIA_UID.1 Timing of
identification (iteration 2)
FPT_CIMC_TSP.1 Audit log signing
event
FAU_GEN.1 Audit data generation FAU_GEN.1 Audit data
generation (iteration 2)
FMT_MOF.1 Management of
security functions behavior
Included
9.3.1.1.1 Justification of Unsupported Dependencies Regarding FMT_SMF.1
The following components depend on FMT_SMF.1 Specification of Management Functions:
• FMT_MOF.1 Management of security functions behavior
• FMT_MSA.1 Management of security attributes
• FMT_MTD.1 Management of TSF data
This requirement need not be explicitly covered by the product since requirements in Table 7 meet or exceed the
requirement for FMT_SMF.1 Specification of Management Functions.
9.3.1.1.2 Justification of Unsupported Dependencies Regarding FMT_MSA.3
Not applicable, since the default value for the security attribute “role” of a new user is “none”. Thus always
restrictive values are enforced. This can’t be changed.
9.3.1.1.3Justification of Unsupported Dependencies Regarding FPT_STM.1 Reliable time
stamps
Not applicable, since the reliable time stamps are provided by the TOE environment (see OE.Time stamps).
9.4 Extended Requirements Rationale
This ST includes a number of extended requirements. Each of the extended requirements is defined in the CIMC PP
and rationale immediately follows the statement of each such requirement. The extended requirements can be identified
by the use of the keyword “CIMC” in the requirement component and element identifiers.
64
10 ACCESS CONTROL POLICIES
10.1 CIMC TOE Access Control Policy
The TOE shall support the administration and enforcement of a CIMC TOE access control policy that provides the
capabilities described below.
Subjects (Certificate Request, Certificate Revocation List Request) will be granted access to objects (certificates and
CRLs) based upon the:
• Identity of the subject requesting access,
• Role (or roles) the subject is authorized to assume,
• Type of access requested,
Subject identification includes roles with different access authorizations.
Access to objects is defined by the simple access types used on access rules:
• accept;
• decline;
• unused (default).
The default access decision for an unused access rule is to deny access.
The TOE will support the following predefined roles:
• Administrator: role authorized to install, configure and maintain the TOE, establish and maintain user accounts,
configure profiles, access rights and audit parameters and manage Component keys;
• Auditor: role authorized to view and maintain audit logs;
• Officer: role authorized to request or approve certificates or certificate revocations.
65
11 TOE Summary Specification
11.1 TOE security functionality
11.1.1 SF1 Security Audit
11.1.1.1 SF1.1 Audit message generation
The Audit (also called Audit system or Audit unit) logs the security-relevant events that were performed by the
TOE. These events are either triggered internally or by external components/users via Java methods. That is the
CA-Core logs amongst others every event and the appropriate event state, in the case that this event triggers a
process of the CA-Core.
The CA-Core generates audit messages for the following auditable events (FAU_GEN.1 Audit data generation
(iteration 2)):
• Start-up and shutdown of the audit functions and
• further security-relevant events according to Table 6
These audit messages are send to the Audit.
If the audit trail is full the TOE shutdowns (FAU_STG.4).
11.1.1.2 SF1.2 Audit trail protection
After audit message generation the Audit unit of the TOE generates uniquely identifiable audit messages, so called
audit records.
The Audit is able to associate each auditable event with the identity of the user that caused the event as the identity
(UserIdentity) is contained in the audit record (see Section 13.1; FAU_GEN.2 User identity association (iteration
2)).
The Audit is able to select the set of events to be audited from the set of all auditable events based on the following
attributes contained in the audit record (see Section 13.1; FAU_SEL.1 Selective audit (iteration 2): object identity
(Module), user identity (UserIdentity) and event type (EventType).
The TOE triggers that a set of these chronological ordered audit records (called audit trail) are periodically signed
by means of a digital signature (FCS_COP.1), resulting in a so called protected audit trail (see Sections 13.2 and
13.3; FPT_CIMC_TSP.1 Audit log signing event). This period is configurable. In order to protect audit messages
against modification or deletion the Audit uses timestamps (OE.Time stamps) and sequence numbers.
The Audit also triggers further cryptographic operations with the environment or within the TOE itself to protect
the audit messages (FAU_STG.1 Protected audit trail storage (iteration 2)). The Audit needs four different
cryptographic keys to protect the audit trails. It needs two asymmetric key pairs, one signature key pair (ASK)
and one encryption key (AEK) and also one current symmetric trail record key (TRK). All these keys are generated
by and stored within the TOE. Audit records and audit trails are stored via Java-API in the Adapter.
66
Table 16 Audit trail protection during operation
Step Operation
1 The audit system generates a symmetric key TRK
2 The symmetric key TRK will encrypted with the public key AEKpub resulting in ENCAEKpub (TRK)
3 The current audit trail sequence number TRAILSEQ is determined
The audit system creates trail header data object and generates an following signature
SIGASKpriv(TRAILSEQ | Timestamp | ENCAEKpub(TRK))
4 The new TRAIL_RECSEQ will be set to zero.
5 If a preceding trail is available, then the following step will performed using the security nodule.
The audit system generates a MAC over the new trail key ENCAEKpub(TRK) with the last trail key
TRK of the preceding trail
MACTRK ( ENCAEKpub(TRK) )
The audit system generates a signature over the preceding trail footer
SIGASKpriv(TRAIL_SEQ | TRAIL_RECSEQ | MACTRKn(TRAIL_RECSEQ) | MACTRK (
ENCAEKpub(TRK) ) )
The audit stores the footer information of the preceding audit trail.
The trail key TRK of the preceding trail will deleted.
The preceding audit trail is now closed.
6 The audit system stores the new audit trail header including the signature SIGASKpriv(TRAILSEQ |
Timestamp | ENCAEKpub(TRK))
The process of creating the new audit trail is now finished.
7 CA-Core sends a new log entry.
The audit system creates a new audit record REC and calculates the MACTRK(REC)
8 The audit system stores the REC and the MACTRK(REC)
9 The TRAIL_RECSEQ incremented by one
10 The process continues at step 7 if the trail capacity not reached yet. After reaching the maximum
audit trail capacity the process will continue with step 1.
Additional the audit system performs the following steps on a regular shutdown of the audit system:
Table 17 Audit trail protection on a regular shutdown
Step Operation
1 The audit system logs the shutdown process.
2 The audit system creates the trail footer with the current information
TRAILSEQ | TRAIL_RECSEQ | MACTRK(TRAIL_RECSEQ) | SIGASKpriv(TRAIL_SEQ
| TRAIL_RECSEQ + 1 | MACTRK(TRAIL_RECSEQ + 1) | MACTRK ( ENCAEKpub(TRK)) )
The field of the MAC over the next exported TRK for the next audit trail will not filled by the audit
system
67
11.1.2 SF2 Management of the TSF
At the first startup the CA-Core has no configuration. Thus, the CA-Core must first be configured (CA
configuration, CAProfile (FMT_MOF_CIMC.3.2 and FMT_MOF_CIMC.3.3) and CRLProfile
(FMT_MOF_CIMC.5.2 and FMT_MOF_CIMC.5.3)) via the Java-API. The Administrator shall specify the
acceptable set of certificate extensions (FMT_MOF_CIMC.3.4)
The CA-Core performs the same checks for Java configuration method as described in SF3.2. That is certificate
validation, signature verification, challenge/identity check and role check. If all checks succeed, the CAProfile
fulfills the requirements FMT_MOF_CIMC.3.2 and FMT_MOF_CIMC.3.3 and the CRLProfile fulfills the
requirements FMT_MOF_CIMC.5.2 and FMT_MOF_CIMC.5.3, the Audit generates an audit log (see SF1.1)
and the CA-Core triggers the generation of a new symmetric key within the environment (see SF6). Then the CA-
Core performs HMAC [RFC2104] protection (see SF6) of the configuration. Finally, the CA-Core stores the
HMAC protected configuration via Java-API to the environment.
In order to prevent replay every change of a configuration requires that the CA-Core creates a new symmetric key
(see SF6) deletes the formerly used symmetric key (see SF6, FCS_CKM_CIMC.5, FCS_CKM.4, FCS_COP.1).
If a configuration is needed during processing the CA-Core loads all information via Java-API from the Adapter.
Then the CA-Core verifies the HMAC (see SF6). If HMAC verification fails, the Audit generates an audit log
record (see SF1.1) and the CA-Core does not further continue processing. If HMAC verification succeeds the CA-
Core Job processing is continued.
11.1.3 SF3 Data Authenticity and Authorization
11.1.3.1 SF3.1 Challenge Request and Response
In order to prevent replay the CA-Core triggers a challenge-response algorithm (FCO_NRO_CIMC.3). In a first
step the external component must request a challenge via Adapter from the CA-Core. The request is not
cryptographic protected according FIA_UAU.1 (iteration 2) and FIA_UID.1 (iteration 2). The CA-Core then
triggers generation of a challenge (10 Byte). The environments Deterministic Random Number Generator
(DRNG) of the CA card is used to generate the challenge. The CA-Core then stores the challenge with the user
identification given in the request (it is possible to have more than one challenge per user at any given time) and
sends the challenge back to the external component via Adapter. Now the external component may request Job
processing via Adapter in a second step. A Job must contain amongst others the requested challenge and must be
signed with the user’s private key.
11.1.3.2 SF3.2 Remote Data entry Verification, Authorization and Challenge Verification
Before CA-Core starts a particular process it performs the following checks to ensure the integrity of the consigned
Java method data: The CA-Core
• performs user certificate validation and the appropriate certificate chain validation (FCO_NRO_CIMC.3.3)
• performs the signature verification with all consigned data (FCO_NRO_CIMC.3.3, FIA_UAU.1 (iteration 2)
and FIA_UID.1 (iteration 2)
• checks whether the given challenge and the signature identity matches a stored challenge/identity
(FCO_NRO_CIMC.3) and
• checks whether the role (FIA_USB.1) of the signature identity has the right to perform the requested process
according to FMT_MOF.1 (for example creating a new certificate or a new certification revocation list). The
security attribute role belongs to individual users (FIA_ATD.1). The allowed roles are: Administrator, Auditor
and Officer (FMT_SMR.1). The right to modify configuration files and profiles (FMT_MTD.1) and modify
the security attribute role (FMT_MSA.1) is limited to Administrators.
68
If all checks succeed, the Audit generates an audit log record (see SF1.1) and starts request processing. If a check
fails, the Audit generates an audit log record (see SF1.1) and the CA-Core does not start request processing.
11.1.4 SF4 Certificate and Certificate Status management
The TOE triggers generation of X.509 certificates and CRLs according to the standards:
• X.509v3 [ITU-T X.509] and
• RFC 5280 [RFC 5280].
In addition to this, the TOE also generates CVC for EAC e-Passport infrastructure according to the BSI TR-03110
[BSI TR-03110] standard.
The TOE maintains via Adapter all issued certificates and their current state in a database, in order to serve status
information. Status information of certificates is made available through CRLs and delta CRLs (RFC 5280
[RFC5280]).
11.1.4.1 SF4.1 Certificate Generation
In case of a certificate request the CA-Core
• validates the certificate request against the loaded CAProfile (FDP_CIMC_CER.1.2 and
FMT_MOF_CIMC.3.1),
• performs signature verification of the certificate request (FDP_CIMC_CER.1.3 and FCO_NRO_CIMC.4),
• transforms the CAProfile and merge it with the certificate request into a certification template
(FDP_CIMC_CER.1.1 and FDP_CIMC_CER1.4),
• triggers signing of certificate template to generate a certificate within the environment (CA card) (see SF6)
and
• returns the new certificate via Java-API to the Adapter.
11.1.4.2 SF4.2 Certificate Revocation
In case of a certificate revocation list request the CA-Core
• merges the CRLProfile and the list of revoked certificates into the certificate revocation list template
(FDP_CIMC_CRL.1 and FMT_MOF_CIMC.5.1),
• triggers singing of the certificate revocation list template within the environment (CA Card) (see SF6) and
• returns the new certificate revocation list via Java-API to the Adapter.
11.1.4.3 SF4.3 Certificate Status Export
Issued CRLs are stored via Java-API in the Adapter (FDP_CIMC_CSE.1 Certificate status export).
11.1.5 SF5 Access Control
The TOE enforces the CIMC TOE Access Control Policy specified in Section 10.1. The access to resources in
the TOE is controlled using access control lists according to FDP_ACC.1 (iteration 2), based on:
• access rule – accept or decline access to a resource,
• resource – a resource to which access is controlled,
• user – an entity that have access rights to a resource,
• role – a role that a user is allowed to take on. Since access rules are defined on a role, so for a user to have
access rights he must be assigned roles.
When a controlled resource is accessed, the CA-Core verifies that the caller meets the appropriate access rules for
the resource and, if not, denies access and generates an error. If there are no access rules associated to the resource,
access is denied. The TOE access control system maps authentication information to a user entity. The entity is
then associated to a role in order to acquire privileges according FDP_ACF.1 (iteration 2).
69
11.1.6 SF6 Cryptographic Key Management
For cryptographic operations the TOE partly relies on its environment. An external key storage is used to generate
key material, to store these keys and to execute cryptographic operations with them. In addition, the TOE
implements some cryptographic primitives by itself. All in all, three entities are involved in the cryptographic
implementation of the TOE:
The CA card (environment)
The CA card generates, stores and allows the use of EC keys for a CA. The CA card supports the algorithms as
defined in Table 1.
The CA card also holds an AES key that is used for encryption/decryption of audit trails, the data store in the
environment and the encryption/decryption of the core configuration. Please note however that the CA card is
only used to generate these keys while the actual encryption and decryption is performed by the TOE.
The TOE
The TOE itself implements the cryptographic primitives as defined in Table 2 (FCS_COP.1, FCS_CKM.1) and
securely deletes cryptographic keys if not longer used (FCS_CKM.4).
The TOE also provides a hash base deterministic random number generator (FCS_RNG.1)
It should be noted that [CIMP PP] contains stipulations about the implementation of cryptographic primitives in
the environment. These requirements are not met by the description in this Security Target. This is the main reason
that this Security Target does not claim conformance to [CIMP PP].
The integrity and authenticity of keys stored by the TOE in the environment is protected by the usage of a digital
signature, namely of the digital certificate structure in which it has been included (FDP_SDI_CIMC.3.1). Every
time a public key (which is stored in form of a certificate) needs to be used to perform any cryptographic operation,
its protective digital signature will be verified and, in case of failure, an audit log entry (see SF1.1) will be
generated and the key will be marked as tampered with, becoming unusable for all types of operations
(FDP_SDI_CIMC.3.2).
The TOE triggers or performs zeroizing private keys in the environment and within the TOE, if required
(FCS_CKM_CIMC.5).
The TOE may trigger the cryptographic operations within its environment which includes amongst others all
cryptographic operations required for FCO_NRO_CIMC.3.3.
11.2 Fulfilling the security functional requirements
See Section 11.1 and:
Since the TOE performs identification and authentication only via signature verification algorithms FIA_SOS.1
(iteration 2) is implicitly fulfilled.
70
12 GLOSSARY OF TERMS
The following definitions are used throughout this standard:
Authentication code: a cryptographic checksum, based on a FIPS-approved or recommended security
method; also known as a Message Authentication Code (MAC) in ANSI standards.
CIMC: the set of hardware, software, firmware, or some combination thereof, that issues, revokes, and
manages public key certificates and certificate status information, and is contained within the CIMC
boundary.
CIMC boundary: an explicitly defined contiguous perimeter that establishes the physical bounds of a
CIMC.
Complete CRL: a complete CRL lists all unexpired certificates, within its scope, that have been revoked
for one of the revocation reasons covered by the CRL scope.
Compromise: the unauthorized disclosure, modification, substitution or use of sensitive data (including
plaintext cryptographic keys and other CSPs).
Confidentiality: the property that sensitive information is not disclosed to unauthorized individuals,
entities or processes.
CMP: a component of the secunet eID PKI Suite that supports the Certificate Management Protocol
arrording RFC4210 and RFC4211.
Critical security parameter (CSP): security-related information (e.g., secret and private cryptographic
keys, authentication data such as passwords and PINs) appearing in plaintext or otherwise unprotected
form and whose disclosure or modification can compromise the security of a CIMC or the security of the
information protected by the CIMC.
Cryptographic key (key): a parameter used in conjunction with a cryptographic algorithm that determines:
o the transformation of plaintext data into ciphertext data,
o the transformation of ciphertext data into plaintext data,
o a digital signature computed from data,
o a keyed hash computed from data,
o the verification of a digital signature computed from data,
o an authentication code computed from data, or
o an exchange agreement of a shared secret.
Cryptographic key component (key component): a parameter used in conjunction with other key
components in a FIPS-approved or recommended security method to form a plaintext cryptographic key
or perform a cryptographic function.
Delta CRL: a delta CRL only lists those certificates, within its scope, whose revocation status has changed
since the issuance of a referenced complete CRL. The referenced complete CRL is referred to as a base
CRL.
Digital signature: a non-forgeable transformation of data that allows proof of the source (with non-
repudiation) and verification of the integrity of that data.
Encrypted key: a cryptographic key that has been encrypted with a key encrypting key, a PIN or a
password in order to disguise the value of the underlying plaintext key.
71
Error detection code (EDC): a code computed from data and comprised of redundant bits of information
designed to detect, but not correct, unintentional changes in the data.
FIPS-Approved or recommended mode of operation: a mode that employs only the operation of FIPS-
approved or recommended security methods.
FIPS-approved or recommended security method: a security method (e.g., cryptographic algorithm,
cryptographic key generation algorithm or key distribution technique, authentication technique, or
evaluation criteria) that is either a) specified in a FIPS or b) adopted in a FIPS and specified either in an
appendix to the FIPS or in a document referenced by the FIPS.
Firmware: the programs and data stored in hardware (e.g., ROM, PROM, or EPROM) such that the
programs and data cannot be dynamically written or modified during execution. Hardware: the
physical equipment used to process programs and data in a CIMC.
HMAC: Keyed-Hash Message Authentication Code, RFC2104
Integrity: the property that sensitive data has not been modified or deleted in an unauthorized and
undetected manner.
Key encrypting key: a cryptographic key that is used for the encryption or decryption of other keys.
Key management: the activities involving the handling of cryptographic keys and other related security
parameters (e.g., Ivs, passwords) during the entire life cycle of the keys, including their generation,
storage, distribution, entry and use, deletion or destruction, and archiving.
nSPOC: see SPOC
Password: a string of characters (letters, numbers, and other symbols) used to authenticate an identity
or to verify access authorization.
Personal Identification Number (PIN): a 4 or more character alphanumeric code or password used to
authenticate an identity, commonly used in banking applications.
Physical protection: the safeguarding of a CIMC, cryptographic keys, or other CSPs using physical
means.
Plaintext key: an unencrypted cryptographic key.
Private key: a cryptographic key used with a public key cryptographic algorithm, uniquely associated
with an entity, and not made public.
Protection Profile: an implementation-independent set of security requirements for a category of
Targets of Evaluation (TOEs) that meet specific consumer needs.
Public key: a cryptographic key used with a public key cryptographic algorithm, uniquely associated with
an entity, and which may be made public. (Public keys are not considered CSPs.)
Public key certificate: a set of data that unambiguously identifies an entity, contains the entity’s public
key, is digitally signed by a trusted party, and binds the public key to the entity.
Public key (asymmetric) cryptographic algorithm: a cryptographic algorithm that uses two related
keys, a public key and a private key. The two keys have the property that, given the public key, it is
computationally infeasible to derive the private key.
72
Secret key: a cryptographic key used with a secret key cryptographic algorithm, uniquely associated with
one or more entities, and which shall not be made public. The use of the term “secret” in this context
does not imply a classification level rather the term implies the need to protect the key from disclosure
or substitution.
Secret key (symmetric) cryptographic algorithm: a cryptographic algorithm that uses a single, secret
key for both encryption and decryption.
Security policy: a precise specification of the security rules under which a CIMC shall operate, including
the rules derived from the requirements of this document and additional rules imposed by the vendor.
Software: the programs and associated data that can be dynamically written and modified.
Split knowledge: a condition under which two or more entities separately have key components that
individually convey no knowledge of the plaintext key that will be produced when the key components
are combined in the cryptographic module.
SPOC: a component of the secunet eID PKI Suite that supports the communication protocol CSN 36
9791 (SPOC) and the Technical Guideline 03129 of the German Federal Office for Information Security.
nSPOC is a national SPOC.
Target of Evaluation (TOE) – An information technology product or system and its associated
administrator and user guidance documentation that is the subject of an evaluation.
TOE Security Functions (TSF) – A set consisting of all hardware, software, and firmware of the TOE
that must be relied upon for the correct enforcement of the TSP.
TOE Security Policy (TSP) – A set of rules that regulate how assets are managed, protected and
distributed within a TOE.
Trusted path: a means by which a user and a TSF can communicate with the necessary confidence
to support the TSP.
User: an individual, or a process (subject) operating on behalf of the individual, accessing CIMC.
Zeroization: a method of erasing electronically stored data by altering or deleting the contents of the data
storage so as to prevent the recovery of the data.
73
13 Appendix
13.1 Audit record
The audit record REC stores the log message of the CA-Core.
13.2 Trail header
13.3 Trail footer
74
14 ACRONYMS
ANSI American National Standards Institute
API Application Programming Interface
BAT Batch File
CA Certification Authority
CC Evaluation Criteria for Information Technology Security (Common Criteria)
CIMC Certificate Issuing and Management Component
CIMS Certificate Issuing and Management System
CMS Certificate Management System
CP Certificate Policy
CPS Certification Practices Statement
CRL Certificate Revocation List
EAL Evaluation Assurance Level
I&A Identification and Authentication
IEC International Electrotechnical Commission
ISO International Organization for Standardization
IT Information Technology
ITU International Telecommunication Union
ITU-T ITU Telecommunication Standardization Sector
JAR Java Archive
KRA Key Archival and Retrieval Authority
OCSP Online Certificate Status Protocol
OID Object Identifier
PKI Public Key Infrastructure
POP Proof of Possession
PP Protection Profile
RA Registration Authority
SFP Security Function Policy
SSL Secure Socket Layer
ST Security Target
TOE Target of Evaluation
TSF TOE Security Functions
TSP TOE Security Policy
75
15 References
[BSI TR-03110] BSI, Technical Guideline Advanced Security Mechanisms for Machine Readable
Travel Documents, Part 1-3, Version 2.10, 20. March 2012, www.bsi.de
[CIMC PP] Certificate Issuing and Management Component”, Version 1.5, 11th
August
2011, www.commoncriteriaportal.org
[FIPS140-2] FEDERAL INFORMATION PROCESSING STANDARDS
PUBLICATION, FIPS PUB 140-2, SECURITY REQUIREMENTS FOR
CRYPTOGRAPHIC MODULES, NIST, 12.03.2002, www.nist.gov
[FIPS 186-2] FIPS PUB 186-2: Digital Signature Standard (DSS) / National Institute of
Standards and Technology (NIST), January 2000
[ITU-T X.509] ITU, X.509 : Information technology – Open Systems Interconnection – The
Directory: Public-key and attribute certificate frameworks, www.itu.int
[RFC2104] RFC2104, HMAC: Keyed-Hashing for Message Authentication, February 1997,
http://tools.ietf.org/html/rfc2104
[RFC5280] RFC5280, Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile, May 2008, http://tools.ietf.org/html/rfc5280
[RFC6960] RFC6960, X.509 Internet Public Key Infrastructure Online Certificate Status
Protocol – OCSP, June 2013, http://tools.ietf.org/html/rfc6960
[TR-03111] TR-03111 Technical Guideline TR-03111 – Elliptic Curve Cryptography,;
Version 1.11, April 2009 / Bundesamt für Sicherheit in der Informationstechnik
(BSI)
[PP-TSPCM] CEN/TC 224 Secretariat: AFNOR, Protection profiles for TSP Cryptographic
modules - Part 5 Cryptographic Module for Trust Services
[BSI TR-03111] Elliptic Curve Cryptography, Version 2.1, 2018-06-01
[FIPS197] ADVANCED ENCRYPTION STANDARD (AES), FIPS 197, November 26,
2001
[SP 800-38B] NIST Special Publication 800-38B, Recommendation for Block Cipher Modes of
Operation: the CMAC Mode for Authentication
[FIPS180-4] Secure Hash Standard (SHS), 8/04/2015
[BSI-TEST-SUITE] BSI Test suite, Implementation of test procedure A and test procedure B of AIS
31.
[RNG_Classes] A proposal for: Functionality classes for random number generators, Version 2.0
18 September 2011
[FIPS 186-5] FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION
Digital Signature Standard (DSS), Published: February 3, 2023