Project acronym: CESECORE Security Target for CESeCore v1.1.2

boreddizzyΔιαχείριση Δεδομένων

16 Δεκ 2012 (πριν από 4 χρόνια και 8 μήνες)

381 εμφανίσεις


Project acronym:
CESECORE

Project full title:
CERTIFIED SECURITY CORE
Security Target for CESeCore v1.1.2
Deliverable Id :
D5.3
Deliverable Name
:
Security Target
Status
:
Draft
Dissemination Level :
Public
Due date of deliverable :
30-11-2009
Actual submission date
:
02-06-2010
Work Package
:
WP5
Organisation name of lead contractor for

this deliverable
:
PrimeKey
Author(s):
Tomas Gustavsson, Pedro Borges, Nuno Ponte, Nuno Santos,

Hasan Subaşi
Partner(s)
contributing :
e-Imza, MULTICERT
Abstract:
This document defines the Security Target according to which the CESeCore product will be

EAL 4+ Common Criteria evaluated.
Project funded by the Eurostars Programme
©

Copyright by the CESeCore Consortium
Security Target for CESeCore v1.1.2
Version 1.1
History
Version
Date
Modification reason
Modified by
Approved by
0.1
14-10-2009
Initial draft
Tomas Gustavsson
Steering Committee
0.2
02-06-2010
Release candidate
Pedro Borges
Steering Committee
0.3
09-09-2010
Update header
Pedro Borges
Steering Committee
0.4
06-10-2010
SFR dependency review
Pedro Borges
-
0.5
25-10-2010
Include comments received from

Oppida and internal reviewers
Pedro Borges
-
0.6
13-05-2011
Clarify the TOE's possible usage

scenarios
Pedro Borges
-
1.0
14-10-2011
Final reviewed deliverable
Pedro Borges
Steering Committee
1.1
29-04-2012
Perform changes requested by the

certifier
Pedro Borges
Steering Committee
Copyright
©
2009-2012 CESeCore Consortium
Page
2
of
65

Security Target for CESeCore v1.1.2
Version 1.1
Table of contents
HISTORY
....................................................................................................................................
2
TABLE OF CONTENTS
............................................................................................................
3
LIST OF FIGURES
.....................................................................................................................
5
LIST OF TABLES
......................................................................................................................
6
1 INTRODUCTION
.....................................................................................................................
7
1.1 D
ESCRIPTION

OF
CES
E
C
ORE
......................................................................................................
7
1.2 TOE R
EFERENCE
......................................................................................................................
8
1.3 TOE O
VERVIEW
.......................................................................................................................
8
1.3.1 C
OMPONENTS
.......................................................................................................................
9
1.4 TOE D
ESCRIPTION
..................................................................................................................
11
1.4.1 S
ECURITY

FUNCTIONS
..........................................................................................................
11
1.4.2 TOE
BOUNDARY
................................................................................................................
13
1.4.3 TOE
PHYSICAL

SCOPE
.........................................................................................................
14
2 CONFORMANCE CLAIMS
..................................................................................................
15
2.1 CC C
ONFORMANCE
C
LAIM
.......................................................................................................
15
2.2 PP
CONFORMANCE

CLAIM
..........................................................................................................
15
2.3 C
ONFORMANCE
R
ATIONALE
.......................................................................................................
15
3 SECURITY PROBLEM DEFINITION
.................................................................................
16
3.1 I
NTRODUCTION
........................................................................................................................
16
3.2 T
HREATS
................................................................................................................................
16
3.2.1 A
UTHORIZED

USERS
............................................................................................................
16
3.2.2 S
YSTEM
............................................................................................................................
16
3.2.3 C
RYPTOGRAPHY
.................................................................................................................
17
3.2.4 E
XTERNAL

ATTACKS
............................................................................................................
17
3.3 O
RGANISATIONAL
S
ECURITY
P
OLICIES
.........................................................................................
17
3.4 A
SSUMPTIONS
.........................................................................................................................
18
3.4.1 P
ERSONNEL
.......................................................................................................................
18
3.4.2 C
ONNECTIVITY
...................................................................................................................
19
3.4.3 P
HYSICAL
..........................................................................................................................
19
4 SECURITY OBJECTIVES
....................................................................................................
20
4.1 H
IGH
-
LEVEL

SOLUTION
.............................................................................................................
20
4.2 S
ECURITY

OBJECTIVES

FOR

THE
TOE
..........................................................................................
20
4.2.1 A
UTHORIZED

USERS
............................................................................................................
20
4.2.2 S
YSTEM
............................................................................................................................
21
4.2.3 C
RYPTOGRAPHY
.................................................................................................................
21
4.2.4 E
XTERNAL

ATTACKS
............................................................................................................
21
Copyright
©
2009-2012 CESeCore Consortium
Page
3
of
65

Security Target for CESeCore v1.1.2
Version 1.1
4.3 S
ECURITY

OBJECTIVES

FOR

THE

OPERATIONAL

ENVIRONMENT
...........................................................
21
4.3.1 N
ON
-IT
SECURITY

OBJECTIVES

FOR

THE

ENVIRONMENT
.............................................................
21
4.3.2 IT
SECURITY

OBJECTIVES

FOR

THE

ENVIRONMENT
.....................................................................
23
4.4 S
ECURITY

OBJECTIVES

FOR

BOTH

THE
TOE
AND

THE

OPERATIONAL

ENVIRONMENT
..............................
23
4.5 S
ECURITY

OBJECTIVES

RATIONALE
...............................................................................................
25
5 EXTENDED COMPONENTS DEFINITION
.......................................................................
26
6 SECURITY REQUIREMENTS
.............................................................................................
27
6.1 S
ECURITY

FUNCTIONAL

REQUIREMENTS
........................................................................................
27
6.1.1 S
ECURITY
A
UDIT
................................................................................................................
29
6.1.2 R
OLES
..............................................................................................................................
33
6.1.3 B
ACKUP

AND
R
ECOVERY
.....................................................................................................
34
6.1.4 A
CCESS
C
ONTROL
..............................................................................................................
35
6.1.5 I
DENTIFICATION

AND
A
UTHENTICATION
..................................................................................
36
6.1.6 R
EMOTE
D
ATA
E
NTRY

AND
E
XPORT
.....................................................................................
37
6.1.7 K
EY
M
ANAGEMENT
............................................................................................................
38
6.1.8 C
ERTIFICATE

AND
P
ROFILE
M
ANAGEMENT
.............................................................................
39
6.2 S
ECURITY

ASSURANCE

REQUIREMENTS
.........................................................................................
43
6.3 S
ECURITY

REQUIREMENTS

RATIONALE
..........................................................................................
44
6.3.1 SFR
DEPENDENCIES
............................................................................................................
45
6.3.2 SAR
DEPENDENCIES
...........................................................................................................
48
7 TOE SUMMARY SPECIFICATIONS
..................................................................................
54
7.1 S
ECURITY
A
UDIT
.....................................................................................................................
54
7.2 R
OLES
...................................................................................................................................
55
7.3 B
ACKUP

AND
R
ECOVERY
..........................................................................................................
56
7.4 A
CCESS
C
ONTROL
...................................................................................................................
56
7.5 I
DENTIFICATION

AND
A
UTHENTICATION
........................................................................................
57
7.6 R
EMOTE
D
ATA
E
NTRY

AND
E
XPORT
...........................................................................................
58
7.7 K
EY
M
ANAGEMENT
.................................................................................................................
60
7.8 C
ERTIFICATE

AND
P
ROFILE
M
ANAGEMENT
...................................................................................
61
REFERENCES
..........................................................................................................................
62
GLOSSARY
...............................................................................................................................
63
A CIMC TOE ACCESS CONTROL POLICY
........................................................................
65
Copyright
©
2009-2012 CESeCore Consortium
Page
4
of
65

Security Target for CESeCore v1.1.2
Version 1.1
List of figures
F
IGURE
1: I
NTEGRATION

OF
CES
E
C
ORE

WITH

OTHER

APPLICATIONS
........................................................
7
F
IGURE
2: CES
E
C
ORE
A
RCHITECTURE
...............................................................................................
9
F
IGURE
3: TOE
BOUNDARY
............................................................................................................
13
Copyright
©
2009-2012 CESeCore Consortium
Page
5
of
65

Security Target for CESeCore v1.1.2
Version 1.1
List of tables
T
ABLE
1: FIPS 140-1 (
OR

HIGHER
) L
EVEL

FOR
V
ALIDATED
C
RYPTOGRAPHIC
M
ODULE
..........................
11
T
ABLE
2: E
XTENDED
C
OMPONENTS
D
EFINITION
.................................................................................
26
T
ABLE
3: TOE F
UNCTIONAL
S
ECURITY
R
EQUIREMENTS
......................................................................
29
T
ABLE
4: TOE F
UNCTIONAL
S
ECURITY
R
EQUIREMENTS
– S
ECURITY
A
UDIT
..........................................
30
T
ABLE
5: A
UDITABLE
E
VENTS

AND
A
UDIT
D
ATA
...............................................................................
32
T
ABLE
6: TOE F
UNCTIONAL
S
ECURITY
R
EQUIREMENTS
– R
OLES
.........................................................
33
T
ABLE
7: A
UTHORIZED
R
OLES

FOR
M
ANAGEMENT

OF
S
ECURITY
F
UNCTIONS
B
EHAVIOUR
.........................
34
T
ABLE
8: TOE F
UNCTIONAL
S
ECURITY
R
EQUIREMENTS
– B
ACKUP

AND
R
ECOVERY
................................
34
T
ABLE
9: TOE F
UNCTIONAL
S
ECURITY
R
EQUIREMENTS
– A
CCESS
C
ONTROL
.........................................
35
T
ABLE
10: A
CCESS
C
ONTROLS
........................................................................................................
36
T
ABLE
11: TOE F
UNCTIONAL
S
ECURITY
R
EQUIREMENTS
– I
DENTIFICATION

AND
A
UTHENTICATION
...........
37
T
ABLE
12: TOE F
UNCTIONAL
S
ECURITY
R
EQUIREMENTS
– R
EMOTE
D
ATA
E
NTRY

AND
E
XPORT
..............
38
T
ABLE
13: TOE F
UNCTIONAL
S
ECURITY
R
EQUIREMENTS
– K
EY
M
ANAGEMENT
.....................................
39
T
ABLE
14: TOE F
UNCTIONAL
S
ECURITY
R
EQUIREMENTS
– C
ERTIFICATE

AND
P
ROFILE
M
ANAGEMENT
.......
42
T
ABLE
15: A
SSURANCE
R
EQUIREMENTS
............................................................................................
43
T
ABLE
16: S
UMMARY

OF
SFR
DEPENDENCIES

FOR
S
ECURITY
L
EVEL
3
..................................................
48
T
ABLE
17: S
UMMARY

OF
SAR
DEPENDENCIES

FOR
S
ECURITY
L
EVEL
3
.................................................
53
T
ABLE
18: R
ATIONALE

FOR

THE
S
ECURITY
A
UDIT
S
ECURITY
R
EQUIREMENTS
..........................................
55
T
ABLE
19: R
ATIONALE

FOR

THE
R
OLES
S
ECURITY
R
EQUIREMENTS
........................................................
55
T
ABLE
20: R
ATIONALE

FOR

THE
B
ACKUP

AND
R
ECOVERY
S
ECURITY
R
EQUIREMENTS
...............................
56
T
ABLE
21: R
ATIONALE

FOR

THE
A
CCESS
C
ONTROL
S
ECURITY
R
EQUIREMENTS
........................................
57
T
ABLE
22: R
ATIONALE

FOR

THE
I
DENTIFICATION

AND
A
UTHENTICATION
S
ECURITY
R
EQUIREMENTS
............
58
T
ABLE
23: R
ATIONALE

FOR

THE
R
EMOTE
D
ATA
E
NTRY

AND
E
XPORT
S
ECURITY
R
EQUIREMENTS
...............
59
T
ABLE
24: R
ATIONALE

FOR

THE
K
EY
M
ANAGEMENT
S
ECURITY
R
EQUIREMENTS
......................................
60
T
ABLE
25: R
ATIONALE

FOR

THE
C
ERTIFICATE

AND
P
ROFILE
M
ANAGEMENT
S
ECURITY
R
EQUIREMENTS
........
61
Copyright
©
2009-2012 CESeCore Consortium
Page
6
of
65

Security Target for CESeCore v1.1.2
Version 1.1
1
Introduction
1.1
Description of CESeCore
The CESeCore is a software product providing a security core for the development of trustworthy

systems, gathering common security functions typically found on such systems into stable, well-
defined and self-contained modules.
A security vendor willing to develop a new trustworthy system (i.e., an application) may build its

specific functionalities on top of the CESeCore security functions provided out of the box. By

using a stable CC EAL (Common Criteria Evaluation Assurance Level) certified core, the

integrator is able to continuously extend its system without the need to perform a re-evaluation of

the whole system and, specifically, the security functions.
The CESeCore provides its functionalities to external applications by means of APIs and a

combination of configuration parameters. Different applications may use different selected API

methods and customized configurations to implement security functions, as illustrated in
Figure 1
.
The main security functions provided in the CESeCore are:

Electronic signatures creation;

Create digital certificates and CRLs
1
;

OCSP
2
support;

Data integrity protection;

Secure audit logs;
1
Certificate Revocation Lists [1]
.
2
Online Certificate Status Protocol [2].
Copyright
©
2009-2012 CESeCore Consortium
Page
7
of
65

Figure
1
:
Integration of CESeCore with other applications
CESeCore
EJBCA
CESeCore
Timestamp Server
CESeCore
Mail Sign Server
CESeCore
Secure Archive Server
Security Target for CESeCore v1.1.2
Version 1.1

Authentication and authorization management;

Token management;

Key generation and management;

Backup of system data.
The rest of this document describes the CESeCore Target of Evaluation (TOE) that is in the scope

of this Common Criteria evaluation and the corresponding Security Target (ST).
1.2
TOE Reference
ST Title
Security Target for CESeCore v1.1.2
ST Reference
D5.3
TOE Identification
CESeCore v1.1.2
CC Conformance
Common Criteria for Information Technology Security Evaluation, Version

3.1 (revision 3)
PP Conformance
Certificate Issuing and Management Components (CI
MC) Security Level 3

Protection Profile, Version 1.0, October 31, 2001
Assurance Level
Evaluation Assurance Level 4 augmented with
ALC_FLR.2
1.3
TOE Overview
CESeCore is composed by a set of Java Enterprise Edition (JEE) modules that implement the

security functionalities needed to create PKI
3
-based applications.
Each implemented security function
is available through a set of APIs, either Java APIs or JEE

specific APIs. Apart from the security functions, CESeCore does not provide any high level

functionality (e.g. document signing), which should be implemented by the relying third-party

applications. Examples of third-party applications that can make use of CESeCore are certificate

management software, Time-stamp servers, OCSP responders, document signing solutions and

secure archive servers.
Regarding its usage
, CESeCore does not function as a standalone application itself, but is

integrated into JEE applications and deployed into an application server in order to provide

security functions for a complete system. Thus, it can be used in two different ways:

by a local (in the server) application using the local EJB API;

by a remote application using the remote EJB API.
Therefore, the features of CESeCore are not available with a simple JAR import, meaning that

its security functions are only usable if it is deployed in an application server and the

local/remote bean interfaces accessed. However, a very limited functionality is available

without deployment, such as small utility classes and local CryptoToken functionality.
Figure 2
depicts the layered architecture that can be observed in a system where the TOE is

deployed.
3
Public Key Infrastructure.
Copyright
©
2009-2012 CESeCore Consortium
Page
8
of
65

Security Target for CESeCore v1.1.2
Version 1.1
Fig
ure
2
:
CESeCore Architecture
1.3.1
Components
The usage of CESeCore relies not only on its implementation, but also on several other additional

components described in the following subsections.
1.3.1.1
CESeCore
The CESeCore component consists of a set of Java classes that provide such functionalities as:

Electronic signatures creation;

Create digital certificates and CRLs;

OCSP support;

Data integrity protection;

Secure audit;

Authentication and authorization management;

Token management;

Key generation and management;

Backup of TOE data.
Given CESeCore's modular structure, in order to provide more advanced functionalities the TOE

also includes a set of JEE components that can be deployed in any JEE compliant application

server. Additionally, depending on the exact functionalities required by the client application,

CESeCore can be configured to include or exclude certain parts.
Copyright
©
2009-2012 CESeCore Consortium
Page
9
of
65

Security Target for CESeCore v1.1.2
Version 1.1
1.3.1.2
Configurati
on
artifacts
Configuration
artifacts
are basic TOE configuration items provided by the CESeCore-dependant

application. The configuration
artifacts
define details on how the specific instance of the TOE

works
and
consist of key-value pairs, stored in a configuration file or in a database. Examples of

configuration
artifacts
are PKCS#11 library path for the hardware security module (HSM), key

labels for cryptographic keys and modes for secure audit.
However, in order to run in an CC-certified configuration certain restrictions on the configuration

a
rtifact
s may apply.
1.3.1.3
Java Virtual Machine
CESeCore is developed in the Java programming language and, as such, runs in a Java Virtual

Machine (JVM). Additionally, since the JVM specifications are public, it can be implemented by

independent vendors.
1.3.1.4
Application server
CESeCore can be (optionally) deployed on an JEE 5 compliant application server, which provides

a number of resources and services to CESeCore, namely:

Database connectivity services (e.g. object mappings and connection pooling);

Component creation and management (e.g. session bean pooling and life-cycle

management);

Communication interfaces (e.g. HTTP and JEE).
These resources and services not only make development and maintenance more efficient, but

also enable high performance, scalability and availability.
1.3.1.5
Database
Data persisted by CESeCore is handled by a standard relational database, where the following

information is kept:

Key pairs
4
and references to key pairs;

Certificates and CRLs;

Audit logs of all security relevant operations;

Authentication data, such as TOE user information;

Authorization data, such as which TOE user is authorized to which resources.
CESeCore enforces access control and maintains integrity of the data for which it is required.
1.3.1.6
Cryptographic module
All cryptographic operations performed at the request of the TOE should take place in FIPS 140-1

(or higher) validated cryptographic modules, either in software or in a hardware (HSM). The

interaction with the cryptographic module is performed through a standard PKCS#11 library

provided by the respective vendor.
However, the level of FIPS 140-1 (or higher) required varies according to the type of operation

performed, as depicted in
Table 1
.
4
Where the private key is encrypted.
Copyright
©
2009-2012 CESeCore Consortium
Page
10
of
65

Security Target for CESeCore v1.1.2
Version 1.1
Category of Use
FIPS 140-1
5

Level Required
Certificate and Status Signing:
- single party signature
3
- multiparty signature
2
Integrity or Approval Authentication:
2
General Authentication
2
Long Term Private Key Protection
3
Long Term Confidentiality
2
Short Term Private key Protection
2
Short Term Confidentiality
1
Hash Generation
1
Signature Verification
1
Table
1
:
FIPS 140-1 (or higher) Level for Validated Cryptographic Module
1.4
TOE Description
The CESeCore TOE should be enough to provide applications built on top of CESeCore with all

the security functions required by PKI-enabled applications. Therefore, CESeCore-enabled

applications shouldn't have to implement important security functions of their own. Additionally,

the TOE depends on several external components for it's operation.
The TOE's JEE components use transactions as defined by JEE. This means that applications built

on top of the TOE can draw benefits of these transactions thus including security functions in the

overall application transactions.
1.4.1
Security functions
Though the security functions can be used independently of each other, the implementation of

some functions depends on others. For example, the
secure audit
security function depends on

data integrity protection
and
electronic signatures creation
.
1.4.1.1
Electronic signatures creation
Creation of electronic signatures is a vital part of PKI applications. Electronic signatures can be

created in a number of ways, low level and high level. The TOE will provide means to obtain a

private key reference (compliant with the standard JCA) that can be used by relying applications

for signing of specific document types. Signatures can be created
in FIPS 140-1 (or higher)

validated cryptographic modules,
both using software or hardware (such as HSMs and smart

cards).
5
Or higher.
Copyright
©
2009-2012 CESeCore Consortium
Page
11
of
65

Security Target for CESeCore v1.1.2
Version 1.1
1.4.1.2
Create digital certificates and CRLs
PKI management systems need to be able to create and process certificates and CRLs. These sets

of security functions are aimed at systems that need to create and sign certificates and CRLs. The

functions are also used by PKI enabled client systems that need to generate and process certificate

services requests (CSRs) using standard formats such as PKCS#10 and CRMF (Certificate

Request Message Format).
1.4.1.3
OCSP support
Though CRLs may be enough for some digital certificate usage scenarios, business-critical

applications tend to require a more flexible and up to date source of revocation information.

Therefore, the TOE natively supports OCSP request parsing and response generation, making
it

very easy for CESeCore-dependant applications
to act as an OCSP responder and provide

realtime revocation status information.
1.4.1.4
Data integrity protection
The functions for data integrity protection are used to ensure that data, in transit or in storage,

cannot be tampered without detection. Integrity protection can be ensured using several

techniques, where the most common are message authentication codes and digital signatures.
1.4.1.5
Secure audit
One very common requirement on sensitive systems is to provide secure audit records. Though

creating audit records is simple, ensuring that they are not tampered with is much more difficult.

By using the security audit functions of the TOE, an application will be able to create audit trails

that meets CWA 14167-1 requirements for secure audit.
1.4.1.6
Authentication and authorization
Authentication and authorization are the most basic security functions needed in order for an

application to provide services to TOE users.
Authentication is the process of identifying the TOE users. Authentication can be performed in

many ways and the TOE provides a framework that can be extended by relying applications in

order to meet their specific authentication needs
Authorization approves or rejects a request for accessing a specific resource. In order to control

authorization, the TOE also keeps a database of access rules. The access rules are connected to the

authorization system so that TOE user's access to resources can be controlled. Some access rules

are already built-in in the TOE but they can be changed by the relying application.
Additionally, access control is also enforced through role separation, based on a combination of

access rules.
1.4.1.7
Token management
The private keys used by the TOE to perform cryptographic operations are kept inside tokens,

which can be activated/deactivated in order to allow/prevent using the keys they hold.
1.4.1.8
Key generation and management
The TOE is able to generate key pairs for its own usage, kept inside a FIPS 140-1 (or higher)

validated cryptographic module. Additionally,
it is also possible to use the generate extractable

key pairs, that are encrypted and stored in the database.
Copyright
©
2009-2012 CESeCore Consortium
Page
12
of
65

Security Target for CESeCore v1.1.2
Version 1.1
1.4.1.9
Backup of TOE data
The various security functions of the TOE manage different types of data, including configuration

data, cryptographic tokens, certificates, CRLs and secure audit logs. Disaster recovery procedures

require that it must be possible to restore a security system in a determined state recovered from

existing backups. Therefore, the backup functions of the TOE make it possible not only to

perform secure backup operations, but also to restore the contents of those backups at another

installation. The security functions of the backup makes it possible to ensure that the backup, and

thus the restored system, cannot be compromised and that confidential data is not revealed.
1.4.2
TOE boundary
As illustrated by
Figure 3
, the TOE includes the CESeCore library and its configuration files.
Excluded from the TOE is:

Hardware and operating system platform (abstract machine);

Application server and execution environment;

Hardware security module (HSM);

Database engine.
Figure
3
:
TOE boundary
The rationale for excluding components from the TOE is elaborated in the following sections.
Copyright
©
2009-2012 CESeCore Consortium
Page
13
of
65

Security Target for CESeCore v1.1.2
Version 1.1
1.4.2.1
Hardware and operating system platform
CESeCore is independent of hardware and operating system and is expected to work on any

platform that provides a reliable time source and is capable of running a JVM. The TOE security

functions do not depend on the security functions of the underlying platform.
1.4.2.2
Application server and execution environment
CESeCore is independent of the application server and execution environment where it is used, as

long as the execution environment is a compliant Java VM and the application server implements

the Enterprise Java Beans (EJB) standard. Though the TOE security functions do not depend on

the security functions of the application server or execution environment, it should be ensured that

only the relying application is allowed to run on the same JVM as the TOE.
1.4.2.3
Hardware security module
The HSM supplies its own set of security functions and is FIPS
6

140-1 (or higher)
evaluated and,

as such, is regarded as a trusted device.
1.4.2.4
Database
All connections to the database are performed using the appropriate JDBC
7
drivers. Given that it

is located in the same machine as the TOE, no specific mechanisms are needed to ensure the

integrity and confidentiality of the information
transferred
to/from the database by the TOE.
1.4.3
TOE physical scope
By running on an application server inside a JVM, the TOE is independent of the underlying

hardware and software platforms. Therefore, as long as a fully compliant JVM is available and

may be used on such a platform, it should be possible to use the TOE.
Nevertheless, since there are several versions of the JVM specification, we have chosen to

explicitly support Oracle JDK 1.6.0_20 (32 or 64 bit).
To perform the evaluation process we limit the hardware platform to the the most commonly

used: Generic x86 32 or 64 bit server.
Moreover, and though it should be possible to deploy and use it in any Linux (32 or 64 bit) or

Windows (32 bit) operating system, the TOE has been successfully tested in Red Hat Enterprise

Linux 5.5 x86 (64 bit) and Windows Server 2008 (32 bit).
Regarding the database, any SQL
8
compliant database can be used, with successful tests already

performed in the following versions:

MySQL 5.1;

PostgreSQL 9.0.
Additionally, CESeCore should run on any JEE 5 certified application server, having been

successfully tested in the following:

JBoss 5.1.0;

Glassfish v2.
Finally, using the PKCS#11 interface makes it possible to use virtually any of the FIPS 140-1
(or

higher)
evaluated HSMs available on the market, with SafeNet Luna SA and Utimaco

CryptoServer having been successfully tested.
6
Federal Information Processing Standard.
7
Java Database Connectivity.
8
Structured Query Language.
Copyright
©
2009-2012 CESeCore Consortium
Page
14
of
65

Security Target for CESeCore v1.1.2
Version 1.1
2
Conformance Claims
2.1
CC Conformance Claim
The TOE conforms to:

Common Criteria for Information Technology Security Evaluation, Version 3.1, part 2

extended;

Common Criteria for Information Technology Security Evaluation, Version 3.1, part 3

conformant;

Evaluation Assurance Level 4 augmented with the
ALC_FLR.2
component.
2.2
PP conformance claim
As previously mentioned in this ST, CESeCore is demonstrably conformed to the following

Protection Profiles (PP):

Ce
rtificate Issuing and Management Components (CIMC) Security Level 3
PP, version

1.0, October 31, 2001
.
2.3
Conformance Rationale
All of the assumptions, threats, policies, objectives and security requirements defined for CIMC

PP Security Level 3
have been reproduced in this ST and adapted for CC v3.1
. No additional

assumption, threat, policy, objective or security requirement has been used.
All operations performed on the IT security requirements are within the bounds set by the CIMC

PP for
Security Level 3
. Assignment and selection operations on security requirements are

indicated in Section
6
.
Copyright
©
2009-2012 CESeCore Consortium
Page
15
of
65

Security Target for CESeCore v1.1.2
Version 1.1
3
Security problem definition
3.1
Introduction
The security problem definition is extracted from the CIMC family of protection profiles and

includes the following parts:

Threats;

Organizational security policies;

Secure usage assumptions.
3.2
Threats
The threats are organized in four categories: authorized users, system, cryptography, and external

attacks.
3.2.1
Authorized users
T.Administrative errors of omission
Administrators, Operators, Officers or Auditors fail

to perform some function essential to security.
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.
T.Administrators, Operators,

Officers and Auditors commit errors

or hostile actions
An Administrator, Operator, 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.
3.2.2
System
T.Critical system component fails
Failure of one or more system components results in

the loss of system critical functionality.
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.
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.
T.Flawed code
A system or applications developer delivers code

that does not perform according to specifications or

contains security flaws.
Copyright
©
2009-2012 CESeCore Consortium
Page
16
of
65

Security Target for CESeCore v1.1.2
Version 1.1
3.2.3
Cryptography
T.Disclosure of private and secret

keys
A private or secret key is improperly disclosed.
T.Modification of private/secret

keys
A secret/private key is modified.
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.
3.2.4
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.
T.Hacker physical access
A hacker physically interacts with the system to

exploit vulnerabilities in the physical environment,

resulting in arbitrary security compromises.
T.Social engineering
A hacker uses social engineering techniques to gain

information about system entry, system use, system

design, or system operation.
3.3
Organisational Security Policies
P.Authorized use of information
Information shall be used only for its authorized

purpose(s).
P.Cryptography
FIPS-approved or NIST-recommended

cryptographic functions shall be used to perform all

cryptographic operations.
Copyright
©
2009-2012 CESeCore Consortium
Page
17
of
65

Security Target for CESeCore v1.1.2
Version 1.1
3.4
Assumptions
The usage assumptions are organized in three categories: personnel, connectivity and

physical.
3.4.1
Personnel
Personnel assumptions about administrators and users of the system, as well as any threat agent.
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

and variations) (Note: this assumption is not

applicable to biometric authentication data.)
A.Competent Administrators,

Operators, Officers and Auditors
Competent Administrators, Operators, Officers and

Auditors will be assigned to manage the TOE and

the security of the information it contains.
A.CPS
All Administrators, Operators, 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, Operators, 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, operators, officers

and auditors are trained in techniques to thwart

social engineering attacks.
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.
Copyright
©
2009-2012 CESeCore Consortium
Page
18
of
65

Security Target for CESeCore v1.1.2
Version 1.1
3.4.2
Connectivity
Connectivity assumptions about other IT systems that are necessary for the secure operations of

the TOE.

A.Operating System
The operating system has been selected to provide

the functions required by this ST to counter the

perceived threats for the the CIMC Security Level 3

PP.
3.4.3
Physical
Physical assumptions about the physical location of the TOE or any attached peripheral devices.
A.Communications Protection
The system is adequately physically protected

against loss of communications i.e., availability of

communications.
A.Physical Protection
The TOE hardware, software, and firmware critical

to security policy enforcement will be protected

from unauthorized physical modification.
Copyright
©
2009-2012 CESeCore Consortium
Page
19
of
65

Security Target for CESeCore v1.1.2
Version 1.1
4
Security objectives
The security objectives are based on the CIMC family of protection profiles and include the

following parts:

High-level solution;

Security objectives for the TOE;

Security objectives for the operational environment;

Security objectives for both the TOE and operational environment;

Security objectives rationale.
4.1
High-level solution
In general terms, this TOE aims to ensure:

That all information generated by the system (e.g. certificates, CRLs and status

information) is trustworthy;

Protection against unknown/malicious communication traffic;

The preservation and (if needed) recovery of a coherent and viable system state, despite

component failures or security incidents (e.g. malicious code);

Non-repudiation and auditability of relevant events;

Control over its development and deployment, by implementing a configuration

management plan;

Confidentiality of sensitive information received or generated by the TOE;

The protection of system and data integrity (including backup information), allowing

prompt detection of unauthorized modification;

An appropriate access control policy that restricts actions of unauthenticated users, fosters

segregation of duties and grants only the essential access rights required by each role;

The sequencing of events through the usage of reliable time stamps;

Tamper protection of audit records.
4.2
Security objectives for the TOE
The objectives are organized in four categories: authorized users, system, cryptography, and

external attacks.
4.2.1
Authorized users
O.Certificates
The TSF must ensure that certificates, certificate

revocation lists, and certificate status information

are valid.
Copyright
©
2009-2012 CESeCore Consortium
Page
20
of
65

Security Target for CESeCore v1.1.2
Version 1.1
4.2.2
System
O.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.
O.Sufficient backup storage and

effective restoration
Provide sufficient backup storage and effective

restoration to ensure that the system can be

recreated.
4.2.3
Cryptography
O.Non-repudiation
Prevent user from avoiding accountability for

sending a message by providing evidence that the

user sent the message. (Security Levels 3 and 4) .
4.2.4
External attacks
O.Control unknown source

communication traffic
Control (e.g., reroute or discard) communication

traffic from an unknown source to prevent potential

damage.
4.3
Security objectives for the operational environment
4.3.1
Non-IT security objectives for the environment
O.Administrators, Operators,

Officers and Auditors guidance

documentation
Deter Administrator, Operator, Officer or Auditor

errors by providing adequate documentation on

securely configuring and operating the CIMC.
O.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.
O.Authentication Data Management
Ensure that users change their authentication data at

appropriate intervals and to appropriate values (e.g.,

proper lengths, histories and variations) through

enforced authentication data management (Note:

this objective is not applicable to biometric

authentication data.).
O.Communications Protection
Protect the system against a physical attack on the

communications capability by providing adequate

physical security.
O.Competent Administrators,

Operators, Officers and Auditors
Provide capable management of the TOE by

assigning competent Administrators, Operators,

Officers and Auditors to manage the TOE and the

security of the information it contains.
Copyright
©
2009-2012 CESeCore Consortium
Page
21
of
65

Security Target for CESeCore v1.1.2
Version 1.1
O.CPS
All Administrators, Operators, Officers and

Auditors shall be familiar with the certificate policy

(CP) and the certification practices statement (CPS)

under which the TOE is operated.
O.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).
O.Installation
Those responsible for the TOE must ensure that the

TOE is delivered, installed, managed, and operated

in a manner which maintains IT security.
O.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.
O.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.
O.Physical Protection
Those responsible for the TOE must ensure that the

security-relevant components of the TOE are

protected from physical attack that might

compromise IT security.
O.Social Engineering Training
Provide training for general users, Administrators,

Operators, Officers and Auditors in techniques to

thwart social engineering attacks.
O.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. (Security Levels 1 – 3).
O.Lifecycle security
Provide tools and techniques used during the

development phase to ensure security is designed

into CESeCore. Detect and resolve flaws during the

operational phase. (Security Levels 2 – 4)
O.Repair identified security flaws
The vendor repairs security flaws that have been

identified by a user. (Security Levels 2 – 4)
O.Require inspection for downloads
Require inspection of downloads/transfers.
O.User authorization management
Manage and update user authorization and privilege

data to ensure they are consistent with

organizational security and personnel policies.
Copyright
©
2009-2012 CESeCore Consortium
Page
22
of
65

Security Target for CESeCore v1.1.2
Version 1.1
4.3.2
IT security objectives for the environment
O.Cryptographic functions
The TOE must implement approved cryptographic

algorithms for encryption/decryption,

authentication, and signature

generation/verification; approved key generation

techniques and use validated cryptographic

modules. (Validated is defined as FIPS 140-1 or

higher validated.)
O.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 (available at

http://checklists.nist.gov
).
O.Periodically check integrity
Provide periodic integrity checks on both system

and software.
O.Security roles
Maintain security-relevant roles and the association

of users with those roles.
O.Validation of security function
Ensure that security-relevant software, hardware,

and firmware are correctly functioning through

features and procedures.
O.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. (Security Levels 3 and 4)
4.4
Security objectives for both the TOE and the operational

environment
This section specifies the security objectives that are jointly addressed by the TOE and the

environment.
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.
O.Data import/export
Protect data assets when they are being transmitted

to and from the TOE, either through intervening

untrusted components or directly to/from human

users.
O.Detect modifications of firmware,

software, and backup data
Provide integrity protection to detect modifications

to firmware, software, and backup data.
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.
Copyright
©
2009-2012 CESeCore Consortium
Page
23
of
65

Security Target for CESeCore v1.1.2
Version 1.1
O.Integrity protection of user data

and software
Provide appropriate integrity protection for user data

and software.
O.Limitation of administrative

access
Design administrative functions so that

Administrators, Operators, Officers and Auditors do

not automatically have access to user objects, except

for necessary exceptions. Control access to the

system by Operators and Administrators who

troubleshoot the system and perform system

updates.
O.Maintain user attributes
Maintain a set of security attributes (which may

include role membership and access privileges)

associated with individual users. This is in addition

to user identity.
O.Manage behavior of security

functions
Provide management functions to configure,

operate, and maintain the security mechanisms.
O.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.
O.Procedures for preventing

malicious code
Incorporate malicious code prevention procedures

and mechanisms.
O.Protect stored audit records
Protect audit records against unauthorized access,

modification, or deletion to ensure accountability of

user actions.
O.Protect user and TSF data during

internal transfer
Ensure the integrity of user and TSF data transferred

internally within the system.
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.
O.Restrict actions before

authentication
Restrict the actions a user may perform before the

TOE authenticates the identity of the user.
O.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.
O.Time stamps
Provide time stamps to ensure that the sequencing of

events can be verified.
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.

(Security Levels 2 - 4)
Copyright
©
2009-2012 CESeCore Consortium
Page
24
of
65

Security Target for CESeCore v1.1.2
Version 1.1
Common Criteria version 3.1 requires the strict separation between security objectives for

the TOE and security objectives for the operational environment.
This section is directly extracted from the CIMC protection profile and is however considered as

acceptable because:

separation between security requirements for the TOE and security requirements for

the environment is clearly defined in the rationale for objectives coverage (section

6.3
);

security requirements statement is the basis for CC 3.1 evaluation tasks (e.g. for ADV

class evaluation workunits).
4.5
Security objectives rationale
The Security Problem Definition and the Security Objectives are identical to the CIMC protection

profile.
Copyright
©
2009-2012 CESeCore Consortium
Page
25
of
65

Security Target for CESeCore v1.1.2
Version 1.1
5
Extended components definition
Extended components have been defined in the CIMC Protection Profile.
Extended security requirements are explicitly identified in
Table 2
, and thoroughly described in

the PP.
Extended Security

Requirements
CIMC Page

Reference
FCO_NRO_CIMC.3
49
FCO_NRO_CIMC.4
51
FCS_CKM_CIMC.5
53
FDP_ACF_CIMC.2
52
FDP_ACF_CIMC.3
53
FDP_CIMC_BKP.1
44
FDP_CIMC_BKP.2
44
FDP_CIMC_CER.1
58
FDP_CIMC_CRL.1
59
FDP_CIMC_CSE.1
51
FDP_CIMC_OCSP.1
59
FDP_ETC_CIMC.5
54
FDP_SDI_CIMC.3
52
FMT_MOF_CIMC.3
55
FMT_MOF_CIMC.5
57
FMT_MOF_CIMC.6
57
FMT_MTD_CIMC.4
52
FMT_MTD_CIMC.5
53
FMT_MTD_CIMC.7
54
FPT_CIMC_TSP.1
41
Table
2
:
Extended Components Definition
Copyright
©
2009-2012 CESeCore Consortium
Page
26
of
65

Security Target for CESeCore v1.1.2
Version 1.1
6
Security requirements
The security requirements are based on the CIMC family of protection profiles and include the

following parts:

Security functional requirements (SFRs);

Security assurance requirements (SARs);

Security requirements rationale.
6.1
Security functional requirements
Table
3
lists all the TOE's functional security requirements.
Security Functional Requirement
CIMC PP Section
CC Part 2

Extended
FAU_GEN.1 Audit data generation
6.1 Security Audit
FAU_GEN.2 User identity

association
6.1 Security Audit
FAU_SEL.1 Selective audit
6.1 Security Audit
FAU_STG.1 Protected audit trail

storage
6.1 Security Audit
FAU_STG.4 Prevention of audit

data loss
6.1 Security Audit
FCO_NRO_CIMC.3 Enforced proof of

origin and verification of

origin
6.6 Remote Data Entry and Export
yes
FCO_NRO_CIMC.4 Advanced

verification of origin
6.6 Remote Data Entry and Export
yes
FCS_CKM_CIMC.5 CIMC private and

secret key zeroization
6.7 Key Management
yes
FDP_ACC.1 Subset access control
6.4 Access Control
FDP_ACF.1 Security attribute

based access control
6.4 Access Control
FDP_ACF_CIMC.2 User private key

confidentiality protection
6.7 Key Management
yes
FDP_ACF_CIMC.3 User secret key

confidentiality protection
6.7 Key Management
yes
FDP_CIMC_BKP.1 CIMC backup and

recovery
6.3 Backup and Recovery
yes
FDP_CIMC_BKP.2 Extended CIMC

backup and recovery
6.3 Backup and Recovery
yes
Copyright
©
2009-2012 CESeCore Consortium
Page
27
of
65

Security Target for CESeCore v1.1.2
Version 1.1
FDP_CIMC_CER.1 Certificate

Generation
6.11 Certificate Registration
yes
FDP_CIMC_CRL.1 Certificate

Revocation
6.12 Certificate Revocation
yes
FDP_CIMC_CSE.1 Certificate

status export
6.6 Remote Data Entry and Export
yes
FDP_CIMC_OCSP.1 Basic Response

Validation
6.12 Certificate Revocation
yes
FDP_ETC_CIMC.5 Extended user

private and secret key export
6.7 Key Management
yes
FDP_ITT.1 Basic internal

transfer protection (iteration 1

and 2)
6.6 Remote Data Entry and Export
FDP_SDI_CIMC.3 Stored public key

integrity monitoring and action
6.7 Key Management
yes
FDP_UCT.1 Basic data exchange

confidentiality
6.6 Remote Data Entry and Export
FIA_UAU.1 Timing of

authentication
6.5 Identification and Authentication
FIA_UID.1 Timing of

identification
6.5 Identification and Authentication
FIA_USB.1 User-subject binding
6.5 Identification and Authentication
FMT_MOF.1 Management of security

functions behaviour
6.2 Roles
FMT_MOF_CIMC.3 Extended

certificate profile management
6.8 Certificate Profile Management
yes
FMT_MOF_CIMC.5 Extended

certificate revocation list

profile management
6.9 Certificate Revocation List Profile

Management
yes
FMT_MOF_CIMC.6 OCSP Profile

Management
6.10 Online Certificate Status Protocol

(OCSP) Profile Management
yes
FMT_MTD_CIMC.4 TSF private key

confidentiality protection
6.7 Key Management
yes
FMT_MTD_CIMC.5 TSF secret key

confidentiality protection
6.7 Key Management
yes
FMT_MTD_CIMC.7 Extended TSF

private and secret key export
6.7 Key Management
yes
FPT_CIMC_TSP.1 Audit log signing

event
6.1 Security Audit
yes
Copyright
©
2009-2012 CESeCore Consortium
Page
28
of
65

Security Target for CESeCore v1.1.2
Version 1.1
FPT_ITC.1 Inter-TSF

confidentiality during

transmission
6.6 Remote Data Entry and Export
FPT_ITT.1 Basic internal TSF

data transfer protection

(iteration 1 and 2)
6.6 Remote Data Entry and Export
FPT_STM.1 Reliable time stamps
6.1 Security Audit
Table
3
:
TOE Functional Security Requirements
6.1.1
Security Audit
Table
4
describes the SFRs related to security audit.
FAU_GEN.1 Audit data generation
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 5

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 i
dentity
(if applicable)
, and

the outcome (success or failure) of the event; and
b) For each audit event ty
pe,
the information specified in the Additional Details

column in

Table 5

below

.
Additionally, the audit shall not include plaintext private or secret keys or other

critical security parameters
.
FAU_GEN.2 User identity association
FAU_GEN.2.1
For audit events resulting from the 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
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, subject identity and event type
;
b)
date
.
FAU_STG.1 Protected audit trail storage
FAU_STG.1.1
The TSF shall prot
ect the stored audit records in the audit trail from

unauthorised deletion.
FAU_STG.1.2
The TSF shall be able to
detect

unauthorised
modifications to t
he stored audit

records in the audit trail.
Copyright
©
2009-2012 CESeCore Consortium
Page
29
of
65

Security Target for CESeCore v1.1.2
Version 1.1
FAU_STG.4 Prevention of audit data loss
FAU_STG.4.1
The TSF shall
prevent audited events, except those taken by the

Auditor

and
no

other actions
if the audit trail is full.
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.
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.
FPT_STM.1 Reliable time stamps
FPT_STM.1.1
The TSF shall be
able to provide reliable time stamps.
Table
4
:
TOE Functional Security Requirements – Security Audit
Table
5
describes the auditable events and respective data.
Sec
t
i
o
n/
F
unc
t
i
o
n
C
o
m
p
o
nent
E
v
ent
Addi
t
i
o
n
a
l

De
ta
ils
6.1

Sec
u
ri
t
y

A
u
d
it
F
A
U
_
GEN.1

A
u
d
it

d
ata

g
e
n
e
r
ati
o
n
A
n
y

c
h
a
ng
e
s

to t
h
e

a
u
d
it

para
m
ete
r
s
,

e.
g
., a
u
dit

f
r
e
q
u
e
n
c
y
,

t
y
p
e
o
f

e
v
e
n
t

a
u
d
ited
A
n
y

a
tt
e
m
p
t

to
d
elete

t
h
e

a
u
d
it l
o
g
F
P
T_
C
I
MC
_
T
SP.1

A
u
d
it

l
o
g

s
i
g
n
i
n
g e
v
e
n
t
A
u
d
it

l
o
g

s
i
g
n
i
n
g

e
v
e
n
t
Di
g
ital

s
i
gn
a
t
u
r
e,
k
e
y
ed

h
a
s
h
,
o
r a
u
t
h
e
n
ticati
o
n

c
od
e

s
h
a
ll
b
e

i
n
cl
u
d
ed

in

t
h
e a
u
d
it

l
o
g
.
6.6 Remote Data

Entry and Export
A
ll

sec
u
ri
t
y
-rele
v
a
n
t

d
ata

t
h
at

is

e
n
tered

in

t
h
e

s
y
st
e
m

(local data entry)
T
h
e i
d
e
n
ti
t
y

o
f

t
h
e
d
ata e
n
t
r
y

i
n
d
i
v
i
d
u
al
i
f

t
h
e
e
n
tered
d
ata

is

li
n
k
ed

to a
n
y

o
t
h
er
d
ata

(e.
g
.,

clic
k
i
n
g

a
n


accept”

b
u
tt
o
n
)
.

T
h
is

s
h
a
l
l

b
e

i
n
c
l
u
d
ed

w
i
t
h

t
h
e accepted

da
ta.
Copyright
©
2009-2012 CESeCore Consortium
Page
30
of
65

Security Target for CESeCore v1.1.2
Version 1.1
Sec
t
i
o
n/
F
unc
t
i
o
n
C
o
m
p
o
nent
E
v
ent
Addi
t
i
o
n
a
l

De
ta
ils
A
ll

sec
u
ri
t
y
-rele
v
a
n
t

m
e
s
s
a
g
e
s

t
h
a
t

are

recei
v
ed

b
y

t
h
e
s
y
s
t
e
m (remote data

entry)
A
ll

s
u
cc
e
s
s
f
u
l

a
n
d

u
n
su
cc
e
s
s
f
u
l
req
u
e
s
t
s

f
o
r

c
o
n
f
i
d
e
n
tial
a
n
d

sec
u
ri
t
y
-

r
ele
v
a
n
t
i
n
f
o
r
m
ati
o
n

(
S
ec
u
r
i
t
y

L
e
v
els

2
,
3
,
4)
5.6

Key

Management
FCS
_
CKM.1

C
r
y
p
t
o
g
r
a
p
h
ic

K
e
y Ge
n
e
r
ati
o
n
W
h
e
n
e
v
er

t
h
e
T
SF req
u
e
s
ts

g
e
n
e
r
ati
o
n

o
f

a

c
r
y
p
t
o
g
r
a
p
h
ic

k
e
y (except

single session or one-time

use symmetric keys)
T
h
e
p
u
b
lic
co
m
po
n
e
n
t

o
f

a
n
y

a
s
y
m
m
et
r
ic
k
e
y

p
air

g
e
n
e
r
ated
T
h
e loadi
n
g

of

C
o
m
p
o
n
e
n
t

pri
v
ate
k
e
y
s
9
6.7

Key

Management
A
ll acc
e
s
s

to

certificate

su
b
j
ect pri
v
ate
k
e
y
s

retai
n
ed
w
i
t
h
i
n

t
h
e
T
OE
f
o
r

k
e
y
reco
v
e
r
y

p
u
rpo
s
es
9
A
ll

c
h
a
ng
e
s

to t
h
e

tr
u
s
ted

p
u
b
lic
k
e
ys
, i
n
c
l
u
d
i
ng

a
dd
iti
o
n
s a
n
d
d
eleti
o
n
s
T
h
e
p
u
b
lic
k
e
y

a
n
d

all

in
f
o
r
m
ation

a
ss
o
ciated

w
i
t
h

t
h
e

k
e
y
T
h
e
m
a
n
u
al

e
n
t
r
y

of

s
ecret

k
e
y
s

u
s
e
d
f
o
r
a
u
t
h
entication

(
S
ec
u
r
i
t
y
L
e
v
els

3
a
n
d
4)
FD
P
_
E
T
C
_
C
I
M
C
.
4

U
s
er pri
v
ate

a
n
d
s
ecret

k
e
y

e
x
port;

FM
T
_
M
T
D
_
C
I
MC.6

T
SF pri
v
ate

a
n
d

s
ecret

k
e
y

e
x
port
T
h
e
e
x
por
t
o
f

pri
v
at
e

a
n
d

s
ecre
t
k
e
y
s (except keys

used for a single session or

message)
6.11

C
e
r
ti
f
i
ca
te

R
e
g
i
s
t
r
ati
o
n
FD
P
_
C
I
MC
_
C
E
R
.1

C
ertificate

Ge
n
e
r
ati
o
n
A
ll cert
i
f
icate

req
u
e
s
ts
If

accepted,

a copy

of

t
h
e

certi
f
icate.

If

re
j
ected,

t
h
e

rea
s
o
n

f
o
r
re
j
ectio
n

(e.
g
.,

i
nv
a
lid

d
ata, re
q
u
est

re
j
ected

b
y

O
f
f
i
cer
,
etc.).
C
ertificate Sta
t
u
s

Ch
a
n
g
e

A
ppro
v
al
A
ll re
q
u
e
s
ts

to
c
h
a
n
g
e
t
h
e

s
tatus

of

a cert
i
f
icate
W
h
et
h
er

t
h
e req
u
e
s
t
w
as

accepte
d

o
r

r
e
j
ected.
C
I
MC

C
on
f
i
gu
r
ati
o
n
Any

s
ec
u
r
it
y
-
r
ele
v
a
n
t

c
h
an
g
es

t
o
t
h
e

con
f
ig
u
rati
o
n
o
f

the

T
SF
9
Audit log not generated since this operation is not supported by the TOE.
Copyright
©
2009-2012 CESeCore Consortium
Page
31
of
65

Security Target for CESeCore v1.1.2
Version 1.1
Sec
t
i
o
n/
F
unc
t
i
o
n
C
o
m
p
o
nent
E
v
ent
Addi
t
i
o
n
a
l

De
ta
ils
6.8

C
erti
f
icate

P
ro
f
ile Ma
n
a
g
e
m
e
nt
FM
T
_
MOF
_
C
I
MC.3

E
x
te
n
d
ed

certificate

pro
f
ile

m
a
n
a
g
e
m
e
nt
A
ll
c
h
a
ng
e
s

to

t
h
e

cert
i
f
icate
pro
f
ile
T
h
e c
h
a
ng
e
s

m
ade

to

t
h
e

pro
f
ile
Re
v
o
cati
o
n

P
ro
f
ile

Ma
n
a
g
e
m
e
nt
A
ll

c
h
a
ng
e
s

to t
h
e

re
v
o
cati
o
n

pro
f
ile
T
h
e c
h
a
ng
e
s

m
ade

to

t
h
e

pro
f
ile
6.9

C
erti
f
icate

R
e
v
o
cati
o
n

L
i
st

P
ro
f
ile Ma
n
a
g
e
m
e
nt
FM
T
_
MOF
_
C
I
MC.5

E
x
te
n
d
ed

certificate

re
v
o
cati
o
n

list

pro
f
ile

m
a
n
a
g
e
m
e
nt
A
ll
c
h
a
ng
e
s

to

t
h
e

cert
i
f
icate re
v
o
cati
o
n

list

pro
f
ile
T
h
e c
h
a
ng
e
s

m
ade

to

t
h
e

pro
f
ile
6.10

O
n
li
n
e

C
ertificate Sta
t
u
s

Pro
t
o
c
o
l
(
O
C
S
P)

P
ro
f
ile

Ma
n
a
g
e
m
e
nt
FM
T
_
MOF
_
C
I
MC.6

OCSP

P
ro
f
ile

Ma
n
a
g
e
m
e
nt
A
ll

c
h
a
ng
e
s

to t
h
e

O
C
SP

pro
f
ile
T
h
e c
h
a
ng
e
s

m
ade

to

t
h
e

pro
f
ile
Minimal Events to

be logged (as

defined in CC – Part

2)
FAU_SEL.1

Selective Audit
All modifications to the

audit configuration that

occur while the audit

collection functions are

operating
FDP_ACF.1

Security

attribute based

access control
Successful requests to

perform an operation on an

object covered by the SFP
FDP_UCT.1 Basic

data exchange

confidentiality
The identity of any user or

subject using the data

exchange mechanisms
FIA_UAU.1

Timing of

authentication
Unsuccessful use of the

authentication mechanism
FIA_UID.1

Timing of

identification
Unsuccessful use of the

user identification

mechanism, including the

user identity provided
FIA_USB.1 User-
subject binding
Unsuccessful binding of

user security attributes to a

subject (e.g. creation of a

subject)
FPT_STM.1

Reliable time

stamps
Changes to the time
Since this takes place at the

operating system level, the

TOE is not able to detect and

log this type of events.
Table
5
:
Auditable Events and Audit Data
Copyright
©
2009-2012 CESeCore Consortium
Page
32
of
65

Security Target for CESeCore v1.1.2
Version 1.1
6.1.2
Roles
Table
6
describes the SFRs related to role management.
FMT_MOF.1 Management of security functions behaviour
FMT_MOF.1.1
The TSF shall restrict the ability to
modify the behavi

or of

the functions
listed

in

Table 7

to
the authorized roles as specified in

Table 7

.
Table
6
:
TOE Functional Security Requirements – Roles
Table
7
describes the roles authorised to manage the security functions behaviour.
Sec
t
i
o
n/
F
unc
t
i
o
n
C
o
m
p
o
nent
Function/Authorized Role
6.1

Sec
u
ri
t
y

A
u
d
it
T
h
e ca
p
a
b
ility

to c
on
f
i
g
u
r
e t
h
e a
u
d
it
p
ar
a
m
eters
s
h
all
b
e

re
s
t
ricte
d

t
o
A
d
m
i
n
i
s
t
rators.
T
h
e capability

to c
h
a
ng
e
t
h
e

f
req
u
e
n
c
y

o
f

t
h
e a
u
dit log

sig
n
i
n
g

e
v
e
n
t

s
h
all

be restrict
e
d

to
A
d
m
i
n
istrators.

(Sec
u
ri
t
y

L
e
v
els

2
-
4).
6.3

Bac
ku
p

a
n
d

R
eco
v
e
r
y
T
h
e capability

to con
f
ig
u
re the bac
ku
p par
a
m
eters
s
h
all be

re
s
tricted

to
A
d
m
i
n
i
s
trators.
6.11

C
e
r
ti
f
i
ca
te

R
e
g
i
s
t
r
ati
o
n
T
h
e ca
p
a
b
ility

to a
ppro
v
e
f
ie
l
d
s

o
r e
x
te
ns
i
o
n
s

to
b
e

i
n
c
l
u
d
ed in

a certi
f
icate
sh
a
l
l be

re
s
tricted

to

O
ff
icer
s
.
I
f

a
n

au
t
o
m
ated

proce
s
s

is

us
e
d

to
a
p
pro
v
e
f
i
e
l
d
s

or

e
x
te
n
s
i
on
s to
b
e i
n
cl
u
d
ed

in

a

certi
f
icate,

t
h
e ca
p
a
b
ili
t
y to

co
n
f
i
gu
r
e

t
h
at proce
s
s

sh
a
ll

be

re
s
tricted

to

O
ff
icer
s
.
Data

E
x
por
t

a
n
d

O
u
t
put
T
h
e
e
x
por
t
o
f

C
IM
C

pri
v
at
e

k
e
y
s

s
h
al
l
req
u
ir
e

t
h
e

a
u
t
h
or
izati
o
n

o
f

at least

t
w
o

A
d
m
i
n
i
strat
o
rs
o
r
o
n
e

A
d
m
i
n
i
s
t
rato
r
a
n
d
o
n
e
O
f
ficer
,
A
u
ditor
,
o
r
Op
e
rator.

(S
ec
u
r
i
t
y

L
e
v
els

3
a
n
d
4)
C
ertificate Sta
t
u
s

Ch
a
n
g
e

A
ppro
v
al
O
n
l
y

Of
f
ice
r
s

sh
a
ll con
f
i
gu
r
e

t
h
e a
u
t
o
m
ated proce
s
s
us
e
d

t
o
appro
v
e

t
h
e
re
v
ocatio
n

o
f

a
certi
f
icat
e

or
in
f
o
r
m
ation

abo
u
t

t
h
e re
v
o
cat
i
o
n

of

a certi
f
icate.
O
n
l
y

Of
f
ice
r
s

sh
a
ll con
f
i
gu
r
e

t
h
e a
u
t
o
m
ated proce
s
s
us
ed

to

appro
v
e

t
h
e placi
n
g

o
f a certi
f
icate

on

h
o
ld or

in
f
o
r
m
atio
n

abo
u
t

t
h
e
o
n

h
ol
d
s
t
atu
s

o
f

a
cert
i
f
i
cate.
C
I
MC

C
on
f
i
gu
r
ati
o
n
T
h
e

ca
p
a
b
ility

to c
on
f
i
g
u
r
e

a
n
y

T
SF

f
u
n
cti
o
n
ali
t
y

s
h
all
b
e

re
s
t
ricte
d

t
o
A
d
m
i
n
i
s
t
rators
.

(
T
h
is

req
u
ir
e
m
e
n
t a
pp
lies to

all

c
o
n
f
i
gu
r
ati
o
n

p
ar
a
m
eters

un
l
e
ss

t
h
e a
b
ili
t
y

to c
on
f
i
g
u
r
e

t
h
a
t

as
p
ect
o
f

t
h
e

T
SF

f
un
c
t
i
o
n
ali
t
y
h
as been

a
ss
i
gn
ed to

a

dif
f
ere
n
t

role

el
s
e
w
h
ere
i
n

t
h
is
docu
m
en
t
.
)
6.8

C
erti
f
icate

P
ro
f
ile Ma
n
a
g
e
m
e
nt
FM
T
_
MOF
_
C
I
MC.3

E
x
te
n
d
ed

certificate

pro
f
ile

m
a
n
a
g
e
m
e
nt
T
h
e ca
p
a
b
ility

to

m
od
i
fy

t
h
e
c
erti
f
icate
pro
f
ile
s
h
all
b
e

re
s
t
ricte
d

t
o
A
d
m
i
n
i
s
t
rator
s
.
Copyright
©
2009-2012 CESeCore Consortium
Page
33
of
65

Security Target for CESeCore v1.1.2
Version 1.1
Sec
t
i
o
n/
F
unc
t
i
o
n
C