eVault Certificate Management System Security Target Certificate... · eVault Technologies Sdn....

eVault Technologies Sdn. Bhd.

eV

Trust Certificate Management System ersion 3.5

Security Target 1.0

1 0 November 2010

eTrust Certificate Management System (CMS) Version 3.5 Security Target


DOCUMENT HISTORY

Version Number Version Date Change Details 0.1 8 February 2010 Fresh version, strict compliance to CIMC PP

Level 1 and upgraded to CCv3.1 0.2 9 February 2010 Version submitted for formal ASE evaluation

0.3 22 March 2010 Update base on comments from ADV table v0.20.4 24 March 2010 Update t TOE version 3.5 and updated ADV o

table v0.4. Formal version for first ASE round. 0.5 19 May 2010 Updated ST droppi g the PP‐compliance asn

MyCB refuses to accept that certified PP. 0.6 10 June 2010 Updated on review comments MySEF‐3‐PLN‐

E009‐ERR1‐d1 0.7 18 June 2010 Updated based on review comments MySEF‐3‐

PLN‐E009‐ERR1‐a1 and ERR2‐d1 0.8 6 July 2010 Updated based on feedback from MyCB 0.9 15 July 2010 Updated based on feedback from evaluators 1.0 10 November 2010 Finalized version



Table of Contents

1 Document introduction .................................................................................. 4 1.1 Document conventions................................................................................... 4 1.2 Terminology ................................................................................................... 4 1.3 References ...................................................................................................... 6 1.4 Document organization .................................................................................. 6

2 INTRODUCTION ................................................................................................. 7 2.1 ST and TOE Reference .................................................................................. 7 2.2 TOE Overview ............................................................................................... 7

2.2.1 Roles and rights in eTrust Certificate Management System .................. 7 2.2.2 TOE Type............................................................................................. 11 2.2.3 Hardware, software and firmware required by the TOE ...................... 12

2.3 TOE Description .......................................................................................... 13 2.3.1 Physical scope of the TOE ................................................................... 13 2.3.2 Typical deployment of the TOE .......................................................... 13 2.3.3 Logical scope of the TOE .................................................................... 14

3 CONFORMANCE CLAIMS ............................................................................... 19 3.1 Common Criteria Claims ............................................................................. 19 3.2 PP Conformance Claim: .............................................................................. 19

4 TOE SECURITY PROBLEM DEFINITION ....................................................... 20 5 OBJECTIVES ...................................................................................................... 21

5.1 Objectives for the TOE ................................................................................ 21 5.2 Objectives for the environment .................................................................... 21 5.3 Security Objectives rationale ....................................................................... 22

6 Extended components definition .............................................................. 24 7 SECURITY REQUIREMENTS ............................................................................ 25

7.1.1 Roles .................................................................................................... 25 7.1.2 Access Control ..................................................................................... 26 7.1.3 Identification and authentication .......................................................... 28

7.2 TOE Security Assurance Requirement ........................................................ 29 7.3 Security requirements rationales .................................................................. 29

7.3.1 SAR rationale ....................................................................................... 30 7.3.2 SAR dependencies rationale ................................................................ 30 7.3.3 SFR rationale ....................................................................................... 30 7.3.4 SFR dependencies rationale ................................................................. 35

8 TOE SUMMARY SPECIFICATION ................................................................... 36 8.1 implementatation of the SFRs ...................................................................... 36



1 Document introduction

1.1 DOCUMENT CONVENTIONS

The following conventions have been applied in this document: Security Functional Requirements – Part 2 of the CC defines the approved set of operations that may be applied to functional requirements: assignment, selection, and iteration. 1. The refinement operation is used to add detail to a requirement, and thus further restricts a requirement. Refinement of security requirements is denoted by bold underline text. 2. The selection operation is used to select one or more options provided by the CC in stating a requirement. Selections are denoted by italicized text in square brackets, [selection value]. 3. The assignment operation is used to assign a specific value to an unspecified parameter, such as the length of a password. Assignment is indicated by showing the value in square brackets, [assignment value]. 4. The iteration operation is used when a component is repeated with varying operations. Iteration is denoted by showing the iteration number in parenthesis following the component identifier, (iteration number).

1.2 TERMINOLOGY

Table 1 Terminology

Acronym Meaning

AES Advanced Encryption Standard

API Application Programming Interface

CA Certification Authority

CC Common Criteria

CIMC Certificate Issuing and Management Component

COTS Commercial Off The Shelf

CRL Certificate Revocation List

CSP Cryptographic Service Provider

DES Data Encryption Standard

DN Distinguished Name

DSA Digital Signature Algorithm

FIPS PUB Federal Information Processing Standards Publication



EAL Evaluation Assurance Level

GUI Graphical User Interface

IP Internet Protocol

PP Protection Profile

ISO International Organization for Standardization

IT Information Technology

ITU International Telecommunications Union

SAR Security Assurance Requirements

SFR Security Functional Requirements

ST Security Target

TOE Target of Evaluation

TSC TSF Scope of Control

TSF TOE Security Function

TSP TOE Security Policy

TSS TOE Summary Specification

MAC Message Authentication Code

NIST National Institute of Standards and Technology

PKCS Public Key Cryptography Standard

PKI Public Key Infrastructure

PP Protection Profile

RFC Request For Comments

RNG Random Number Generator

RSA Rivest, Shamir, Adleman [public key algorithm]

SF Security Function

SFP Security Function Policy

SFR Security Functional Requirement

SHA-1 Secure Hash Algorithm 1

SOF Strength of Function

ST Security Target

TOE Target of Evaluation

TSC TSF Scope of Control



TSF TOE Security Functions

TSP TOE Security Policy

1.3 REFERENCES

Common Criteria (informally referred to as “CCv3.1”): - Common Criteria Part 1 Version 3.1 Revision 3 - Common Criteria Part 2 Version 3.1 Revision 3 - Common Criteria Part 3 Version 3.1 Revision 3 - Common Methodology for Information Technology Security Evaluation

(CEM) version 3.1 Revision 3 Protection Profile (informally referred to as “CIMC”, “PP”, “Protection Profile”, note that this PP has been used as reference only, this ST is not compliant to the PP)

- Certificate Issuing and Management Components (CIMCs) Security Level 12 Protection Profile ”, Version 1.0, dated October 31, 2001

1.4 DOCUMENT ORGANIZATION

This ST contains: - TOE Description: Provides an overview of the TOE security functions and

describes the physical and logical scope for the TOE - TOE Security Problem Definition: Describes the threats, organizational

security policies, and assumptions that pertain to the TOE and the TOE environment.

- TOE Security Objectives: Identifies the security objectives that are satisfied by the TOE and the TOE environment.

- TOE Security Functional Requirements: Presents the Security Functional Requirements (SFRs) met by the TOE

- TOE Security Assurance Requirement: Presents the Security Assurance Requirements (SARs) met by the TOE

- TOE Summary Specification: Describes the security functions provided by the TOE to satisfy the security requirements and objectives

- Rationale: Presents the rationale for the security objectives, requirements, and the TOE summary specifications as to their consistency, completeness, and suitability



2 INTRODUCTION

2.1 ST AND TOE REFERENCE

ST Title eTrust Certificate Management System Version 3.5 Security Target

ST Version 1.0 10 November 2010

TOE Identification

eTrust Certificate Management System version 3.5

CC Identification Common Criteria for Information Technology Security Evaluation, Version 3.1 Release 3

Assurance Level EAL 2 ST Author Sam Soo, Lester Soo, Jimmy Liew,

(with support of Wouter Slegers (Your Creative Solutions)) Keyword eTrust, Commercial-off-the-shelf (COTS), certification authority,

key management, cryptographic services, digital certificate management, public-key infrastructure, digital signature, encryption, confidentiality, integrity, networked information systems, baseline information protection.

2.2 TOE OVERVIEW

The eTrust Certificate Management System (CMS) is a role-based access control system on top of the Microsoft CA service and associated services, allowing fine-grained access control to be assigned to administrators of the PKI. This mechanism allows for separation of roles in the management of certificates from creation to revocation and recovery, as appropriate for the organisation. The sections below describe the rights that can be provided.

2.2.1 Roles and rights in eTrust Certificate Management System

eTrust CMS distinguishes between administrators with various rights and the end-users. The primary administrators of eTrust CMS are the Security Officers. These Security Officers are authorized to assign the authorization to all administrative functions of the eTrust CMS including the functions to make roles with associated authorizations (such roles are called “Officer Groups”). All roles with security relevant authorizations are “Authorized Officers” (“Security Officers” are a special case of “Authorized Officers” as they have at least the right to assign the rights). In Common Criteria terms, all Officers are therefore also administrators of the TOE.



More than one role can contain the authorization to a single function and roles can be defined freely by the Security Officer, so this ST describes the access control based on whether that role includes the authorization to a specific function with the phrase “administrator with the right to ...”. Roles (“Officer Groups”) are defined using the Officer Group Policy Setup Screen and contact individuals are assigned to roles using the Officer Policy Setup Screen ( grouped under the Policies Management Module, listed under that heading in Table 3: Access Matrix). End-users can access only the eTrust CA Portal and are the ultimate recipients of eTrust CMS services. An end user is a recipient of credentials, a creator of signed and/or encrypted information, or, in other terms, the ultimate consumer of the PKI services provided by eTrust CMS. End user privileges are enforced by eTrust CMS, directly in the case of initialization and key recovery, and indirectly via certificates and revocation lists issued by eTrust CMS.

Typical role setup with Segregation of Duties

The typical administration of eTrust CMS service is managed by a number of administrative roles. Each role must have at least one contact individual (except Key Recovery Administrator which required 2 contact individuals), however the same individual may hold multiple positions of authority. It is possible (and is normally advisable) to have more than one contact individual for each position of authority. Thus it is possible in a small organization for one person to hold all the admin roles required, and perform all the actions themselves. Conversely in a large organization it is possible that each user can have only a single role, so that any attempt at fraudulent issuance of credentials is not possible by a single individual. It is strongly advised that each organization have at least one:

• Security Officer • Enrollment Administrator • Technical Administrator

And at least two:

• Key Recovery Administrator



In summary, typically five administrative roles will be used on the certificate management system application:

• Security Officer • Enrollment Administrator • Key Recovery Administrator (minimally 2 individuals) • Technical Administrator • For helpdesk operation

o 1st level: Helpdesk Operator o 2nd level: Technical Support Officer o 3rd level: Technical Expert

Each role must be designated to at least one contact individual. It is possible to designate more than one role to each contact individual. The typical responsibilities of the roles described above are listed in the table below:

Roles Responsibilities Security Officer

• Define and modify all security policies • Create new officer / administrator roles • Create new officer / administrator certificate request • Issue new officer / administrator certificate • Revoke officer / administrator certificate

Enrollment Administrator

• Create new user certificate request & issue user certificate • Revoke user certificate

Helpdesk Operator

• Accept calls and log/create user problems • Solving user problems and create remarks • Resend user certificate e-mail

Technical Support

• Accept escalated support request from helpdesk operator • Solving user problems and create remarks

Security Officer

Enrollment Administrator

Key Recovery

Administrator

Technical Administrator

Helpdesk Operation

Helpdesk Operator (1st level support)

Technical Support Officer (2nd level

support)

Technical Expert (3rd level support)

Figure 1: Typical Officer roles



Officer Technical Expert

• Accept escalated technical issues from technical support officer • Solving user problems and create remarks

Technical Administrator

• Create new device certificate request • Issue device certificate • Revoke device certificate

Key Recovery Administrator

• Approve / reject user certificate recovery request

Table 2: Typical responsibilities of typical roles

Note that this is just the common situation, the configuration of roles provides the ability to grant or deny administrative access to various operations including: user administration operations (e.g., enable user, revoke certificate), types of certificates, security policy operations, audit log access, directory operations, and database operations. End User End Users are the ultimate recipients of eTrust CMS services. An end user is a recipient of credentials, a creator of signed and/or encrypted information, or, in other terms, the ultimate consumer of the PKI services provided by eTrust CMS. End user privileges are enforced by eTrust CMS, directly in the case of initialization and key recovery, and indirectly via certificates and revocation lists issued by eTrust CMS.

ACCESS MATRIX

Based on the segregation of duties in the previous section, each role will be given access to specific screens and reports based on the following table.

Access to Screen / Reports

Secu

rity

Off

icer

Enro

llmen

t Ad

min

istr

ator

Tech

nica

l Ad

min

istr

ator

Key

Reco

very

Ad

min

istr

ator

H

elpd

esk

Ope

rato

r \

Tech

nica

l Sup

port

O

ffic

er \

Te

chni

cal E

xper

t

Certificate Enrollment Module Individual Certificate Request Screen X Individual Certificate Issuance Screen X X Individual Certificate Revocation Screen X X Individual Certificate Expiry Notice Screen X X Individual Certificate Bulk Registration Screen X X Certificate Request Report X X Certificate Issuance Report X X



Certificate Revocation Report X X Device Certificate Request Screen X X Device Certificate Issuance Screen X X Device Certificate Revocation Screen X X Device Certificate Expiry Notice Screen X X Key Management Module Key Recovery Request Screen X X Key Administration Screen X X Key Recovery Request Report X X Key Administration Report X X Help Desk Module Certificate Request Support Report X X Certificate Issuance Support Report X X Certificate Revocation Request Support Report X X Certificate Expiry Notice Support Report X X Key Recovery Request Support Report X X Help Desk Case Search Screen X X Help Desk Case Create Screen X X Certificate Enrollment Management Report X X Certificate Help Desk Activities Report X X Policies Management Module Officer Group Policy Setup Screen X Officer Policy Setup Screen X Project Policy Setup Screen X Package Policy Setup Screen X Procedure Policy Setup Screen X Organization Policy Setup Screen X Helpdesk System Setup Screen X Access Right Setup Screen X System Configuration Setup Screen X Database Archiving Setup Screen X Audit Log Viewing Screen X

Table 3: Access Matrix

2.2.2 TOE Type

The TOE (eTrust CMS) is a web-based frontend to the MS CA services, providing convenient access to the certificate issuing/revocation/recovery functions and role based access control on these functions.



2.2.3 Hardware, software and firmware required by the TOE

eTrust Certificate Management System version 3.5 (eTrust CMS) is developed with Microsoft DotNet 2.5 C# programming language. This application requires from the environment the following software: • Microsoft Windows 2003 Server Certificate Authority and above • Microsoft Internet Information Server (IIS) 6.0 and above • Microsoft SQL Server 2005 eTrust CMS version 3.5 is intended to be hosted on Windows Server 2003 operating system. eTrust CMS will apply to the library hosted on 32-bit Microsoft Windows Server 2003; SP 1 running on Intel x86 architectures. The operating system has obtained Common Criteria Evaluation and Validation Scheme (CCEVS) certificate for the TOE assurance level EAL 4. Validation ID for Microsoft Windows Server 2003; SP 1 is 4025. Windows includes a CAPI-compatible FIPS 140 Level 1 validated cryptographic module. eTrust CMS relies on the underlying operating system and its Server Certificate Authority application to provide certificate generation and distribution services, certificate revocation list generation and distribution services, and certificate status protocol services for TOE. eTrust CMS does not require any additional privileges from the operating system. eTrust CMS relies on the Secure Socket Layer (SSL) of IIS to secure the communication channel with the users and the application. The Private Key used by the server side in the SSL can optionally be stored in a Hardware Security Module (HSM), using the Cryptographic Services Provider (CSP) provided by the HSM vendor. The eTrust CMS version 3.5 requires from the environment the following hardware: 1) eTrust CMS Website

• 2 Gbytes of RAM • Intel Xeon Dual Core 2.83 GHz or better • One 16X or faster CD-ROM drive • TCP/IP protocol stack installed • 300 Gbyte hard disk

2) eTrust CA Portal

• 2 Gbytes of RAM • Intel Xeon Dual Core 2.83 GHz or better • One 16X or faster CD-ROM drive • TCP/IP protocol stack installed • 300 Gbyte hard disk



No firmware is needed by the eTrust CMS 3.5.

2.3 TOE DESCRIPTION

2.3.1 Physical scope of the TOE

The TOE physically consists of • eTrust CMS installation CD (to be installed according the guidance) • Guidance:

o eTrust Certificate Management System Version 3.5 Installation Manual o eTrust Certificate Management System Version 3.5 Operation Manual o eTrust Certificate Management System Version 3.5 Training Manual

2.3.2 Typical deployment of the TOE

The below diagram illustrates eTrust conceptual network architecture. The final live system can be varied from the above design to cater for the enterprise unique environment.

Figure 2: Typical deployment in a network



As can be seen from the diagram above, eTrust CMS version 3.5 is separated into 2 sections: the eTrust CMS Website and the eTrust CA Portal. The eTrust CMS Website and its database hosted behind the second firewall in the corporate network is served for the internal authorized officer to manage the certificate lifecycle. The eTrust CA Portal is intended to serve the public user over the internet. If the organization that used eTrust CMS decided to publish its PKI services online, it can operate a website (eTrust CA Portal) for online user to download the certificate and its root certificate. The diagram illustrates the best practice system architecture of eTrust CMS to provide high performance, scalability & availability for frequent certificate lifecycle management activities. The high availability system architecture has the following (unevaluated) features: • Network load balancing (NLB) of web/application servers (2 nos. of

web/application servers) by using Microsoft built-in NLB services or external hardware load balancing appliance such as Big-IP series from F5 Networks. This method supports the following advantages:

o Balancing the loads either equally or at different ratio between servers. o Failover loads to the healthy servers when one of the servers down. o Provide system scalability. Add on server to the NLB services at any time

to increase load handling capacity. • Database server failsafe (2 nos. of database servers) by using Microsoft SQL

Server clustering. • Providing external storage with Storage Area Network (SAN) facility by using

external storage device such as IBM System Storage’s DS4700 device. • Optional disaster recovery site. Enterprise can allocate an extra server for

disaster recovery.

2.3.3 Logical scope of the TOE

Figure below illustrates the subsystems and boundary of the TOE in logical view along with the environment in which it is used.



Figure 3: TOE boundary and TOE subsystems (logical view)

There are two TOE subsystems in an eTrust Certificate Management System, namely:

• eTrust CMS Website • eTrust CA Portal

Although not part of the TOE, the following two parts of the environment perform services essential to the operation of the TOE:

• Database • Directory (Certificate & CRL Repository) manages by Microsoft Certificate

Authority

eTrust CMS Website

eTrust CMS Website, is used to manage certificate lifecycle by authorized officers. That is, to perform initial configuration of eTrust CMS based on data provided during software setup, to verify the integrity of the Database, to schedule backups of the database, and to perform exceptional PKI-management events such as PKI key recovery. In other words, eTrust CMS Website provides the interface into initialization and maintenance services, as well as the primary operator interface for day-to-day management of authorized officers following the assigned roles and their rights. The eTrust CMS Website is the primary interface to the eTrust CMS services. For every service offered there is at least one corresponding set of functions (called “modules” in eTrust documentation) that enables operators to invoke that service.



eTrust CA Portal

eTrust CA Portal is used to handle the certificate download by the applicant over the Internet. During certificate issuance on eTrust CMS an Authentication Code is generated and e-mail to the certificate holder to be used for future certificate download on eTrust CA Portal at later stage. The CA Portal allows users internally or externally download their respective certificates that are generated by the authorized officer. Notification is send to the users via email to inform them to log on to the CA portal and download their certificate to the desktop/laptop. The communication between CA Portal to eTrust CMS website is via web services under HTTPS secure connection to query any certificate created. Depending on the organization policy, the certificate holder’s keys and certificate can be backed up (also known as key escrow). The keys and certificate will be protected under two-person control. In an exceptional event, such as certificate holder lost its private key, a request for key recovery can be entered. Key administrators that have been appointed are responsible to approve on key recovery request. As soon as the approval of key recovery, Certificate holders will get an e-mail key recovery notice with an Authentication Code, he/she will then login to CA Portal to obtain their recovered certificate.

Database

eTrust CMS stores information about eTrust users and the infrastructure itself in a database. The Database stores:

• User status information, including the distinguished name (DN) of each user • The certificate request, issuance and revocation histories for all users • Encrypted Private keys and its public key certificates for each user and officer • Public key certificates for each user • The validity periods for user key pairs and certificates • Security Officer and Administrator information

eTrust CMS enforces access control and maintains integrity of these resources by performing only well-formed operations on these resources and only on behalf of authorized administrators.

Directory

The Directory is a repository of public information. It contains the name of each end entity in the CA domain. Public certificates of each user, certificate revocation lists (lists of certificates that have been revoked for various reasons), and other



information is written from eTrust CMS to Microsoft Certificate Authority engine and then to the Directory.

Exclusion from the TOE Boundary

The components excluded from the eTrust CMS TOE boundary are given below. The justification for excluding these components is provided in the sections to follow.

• Database • Directory • Hardware and Operating System (including Microsoft Certificate Authority

and Hardware Security Module (HSM))

Justification of Exclusion

Database The justification for excluding the database from the eTrust CMS TOE boundary is based on the following factors: • Database security provided by eTrust: This Security Target makes no claims

about inherent database security. All access control to the database security is provided by eTrust CMS, not the database.

• Database functionality not mapped to SFRs: This Security Target makes no claims about database functionality (aside from the inherent, fundamental, and basic function of data storage). The Database operates only as a data warehouse for user and system data. Database functionality is not mapped to any of the SFRs in this Security Target.

• Well-defined database interface: The only interface to the database is through eTrust CMS and it uses the ODBC-API. That is, database access is only available through a well-defined interface (ODBC-API).

Directory The justification for excluding the directory from the eTrust CMS TOE boundary is based on the following factors:

• Directory functionality not mapped to SFRs: This Security Target makes no claims about directory functionality (aside from the inherent, fundamental, and basic function of data storage). The directory operates only as a data warehouse for X.509 certificates. Directory functionality is not mapped to any of the SFRs in this Security Target.

• Well-defined directory interface: eTrust CMS don’t manage directory publishing; it was manage by Microsoft Certificate Authority (CA) provided by Microsoft Windows 2003 server. No directory items are considered sensitive since they are publicly available and all certificates have inherent authenticity and integrity protection as they are digitally signed by the Microsoft CA.



Hardware, operating system platform, Microsoft Certificate Authority and Hardware Security Module (HSM) The TOE makes no claims about the Windows 2003 operating system and software services (such as Microsoft Certificate Authority) and any hardware used1. The justification for excluding the abstract machine from the eTrust CMS TOE boundary is based on the following factors: • Operating system (including Microsoft Certificate Authority): The TSP is enforced

by the TOE and the SFRs are completely satisfied by TOE functions (aside from those with environmental dependencies). The operating system (including the Microsoft Certificate Authority) with which the TOE interfaces, is assumed to be trusted, meaning that it can be relied upon to correctly execute the TOE functions. As well, Windows 2003 is certified to the Common Criteria EAL4 level.

• Hardware independence (including optional HSM): The eTrust software is optimized to execute any x86 (i.e., Intel or equivalent processor)-based machines, regardless of the hardware vendor. That is, any hardware platform that meets the minimum system requirements suffices. The optional HSM can be used by the Microsoft Certificate Authority to store the CA key in this HSM. This is functionality completely contained within the Microsoft Certificate Authority software and transparent from the TOE point of view. That is, any HSM supported by Microsoft Certificate Authority will result in the same functionality to the TOE.

1 Not shown in “ ” as the TOE is software and it is obvious the hardware underlies all the shown software.

Figure 3: TOE boundary and TOE subsystems (logical view)



3 CONFORMANCE CLAIMS

3.1 COMMON CRITERIA CLAIMS

The TOE conforms to: • Common Criteria for information Technology Security Evaluation, Version 3.1

Release 3, part 2 conformant. • Common Criteria for Information Technology Security Evaluation, Version 3.1

Release 3, part 3 conformant. • Evaluation Assurance Level 2 (EAL2) conformant

3.2 PP CONFORMANCE CLAIM:

This Security Target claims no conformance with a PP. Note that this ST is written in line with the terminology used in the Certificate Issuing and Management Components (CIMCs) Security Level 1 Protection Profile, Version 1.0, dated October 31, 2001.



4 TOE SECURITY PROBLEM DEFINITION

A Public Key Infrastructure consists of the means to create, distribute, revoke and if need be re-cover certificates. The public key cryptography and associated protocols used ensure the integrity and authenticity of the certificates. The core entity in these protocols, the Certificate Authority (CA), digitally signs these certificates and associated status information. What the public key cryptography does not in itself provide, is that only authorized personnel can instruct the CA software to perform these signing operations. This access control is the function that the eTrust Certificate Management System adds to the MS CA engine (which functions as the CA software). The primary asset is the authorization of the action leading to the CA’s signing operations. As the public key cryptography ensures the authenticity and integrity protection, and the confidentiality is not applicable here, there are no secondary assets. To fulfil this, the following threats are identified. There are no organisational security policies or assumptions. The eTrust Certificate Management System protects against the following attacks up to enhance-basic attack potential: T.Unauthorized_Issuance An attacker, not in possession of valid identification and authentication data of an administrator authorized to issue certificates, causes the CA to issue a certificate that the authorized administrators would not have issued. T.Unauthorized_Revocation An attacker, not in possession of valid identification and authentication data of an administrator authorized to revoke certificates, causes the CA to revoke a certificate that the authorized administrators would not have revoked. T.Unauthorized_Recovery An attacker, not in possession of valid identification and authentication data of an administrator authorized to recover stored private keys, causes the CA to recover the private key associated to a certificate that the authorized administrators would not have recovered.



5 OBJECTIVES

5.1 OBJECTIVES FOR THE TOE

O.Identification_and_authentication The TOE ensures that all administrators are identified and authenticated prior to further access to the TOE. O.Authorization_of_administrators The TOE ensures that only the security officers can assign the roles and associated access rights to the administrators. O.Issuance The TOE ensures that only administrators with the right to issue certificates assigned to them, can issue certificates. O.Revocation The TOE ensures that only administrators with the right to revoke certificates assigned to them, can revoke certificates. O.Recovery The TOE ensures that only administrators with the right to recover the private key associated to the certificates assigned to them, can recover this private key. O.Export The TOE ensures that only administrators can cause the TOE to export potential sensitive data, such as backups.

5.2 OBJECTIVES FOR THE ENVIRONMENT

OE.Hosting The environment must provide a platform according to the minimal requirements described in the TOE scope. This platform must be hardened and deployed such that attacks on the TOE running on the platform are only possible over the communication channel used by legitimate users (the web interface provided). OE.TrustedAdmins The environment must ensure that all TOE administrators are well trained and actively working to keep the TOE correctly configured and otherwise protected against all attacks. He has to read the guidance documentation carefully, completely understand and apply it.



5.3 SECURITY OBJECTIVES RATIONALE

The following shows that the complete security problem definition (SPD) with all threats, OSPs and assumptions is covered in the objectives. SPD Rationale T.Unauthorized_Issuance With O.Identification_and_authentication the TOE

ensures that it identifies and authenticates the administrators. With “O.Authorization_of_administrators” the TOE ensures that only the security officer can assign the authorizations to the administrators on behalf of the organization. With O.Issuance the TOE ensures that only administrators authorized to perform the issuance can issue a certificate, countering any direct implementation of T.Unauthorized_Issuance. O.Export ensures that only the authorized administrators can export sensitive information that could be used to create certificates outside the system. The administrators are trusted (OE.TrustedAdmins) and will ensure that this data is securely handled. This analysis is valid when the TOE is not bypassed or tampered with. The environment must provide a safe environment for the CA and the TOE (OE.Hosting) and trusted administrators (OE.TrustedAdmins) to facilitate the TOE’s self defence (considered under ADV_ARC.1).

T.Unauthorized_Revocation With O.Identification_and_authentication the TOE ensures that it identifies and authenticates the administrators. With “O.Authorization_of_administrators” the TOE ensures that only the security officer can assign the authorizations to the administrators on behalf of the organization. With O.Revocation the TOE ensures that only administrators authorized to perform the revocation can revoke a certificate, countering any



direct implementation of T.Unauthorized_Revocation. O.Export ensures that only the authorized administrators can export sensitive information that could be used to create certificate revocations (CRLs) outside the system. The administrators are trusted (OE.TrustedAdmins) and will ensure that this data is securely handled. This analysis is valid when the TOE is not bypassed or tampered with. The environment must provide a safe environment for the CA and the TOE (OE.Hosting) and trusted administrators (OE.TrustedAdmins) to facilitate the TOE’s self defence (considered under ADV_ARC.1).

T.Unauthorized_Recovery With O.Identification_and_authentication the TOE ensures that it identifies and authenticates the administrators. With “O.Authorization_of_administrators” the TOE ensures that only the security officer can assign the authorizations to the administrators on behalf of the organization. With O.Recovery the TOE ensures that only administrators authorized to perform the recovery of the private key associated to the certificate can recover that private key, countering any direct implementation of T.Unauthorized_Recovery. O.Export ensures that only the authorized administrators can export sensitive information that could be used to recover certificates outside the system. The administrators are trusted (OE.TrustedAdmins) and will ensure that this data is securely handled. This analysis is valid when the TOE is not bypassed or tampered with. The environment must provide a safe environment for the CA and the TOE (OE.Hosting) and trusted administrators (OE.TrustedAdmins) to facilitate the TOE’s self defence (considered under ADV_ARC.1).

Table 4: Security Objectives Rationale



6 Extended components definition

Not applicable: no extended components have been defined.



7 SECURITY REQUIREMENTS

7.1.1 Roles

FMT_SMR.1 Security roles Hierarchical to: No other components. FMT_SMR.1.1 The TSF shall maintain the roles [administrator with authorization to issue certificates, administrator with authorization to revoke certificates, administrator with authorization to recover private keys associated with certificates, administrator with the authorization to export potentially sensitive data, security officer]23 FMT_SMR.1.2 The TSF shall be able to associate users with roles. Dependencies: FIA_UID.1 Timing of identification FMT_MOF.1 Management of security functions behaviour Hierarchical to: No other components. FMT_MOF.1.1 The TSF shall restrict the ability to [modify the behaviour of]4 he functions [listed in Table 7-7]5 to [the authorized roles as specified in Table 7-7]6. Dependencies: FMT_SMR.1 Security roles FMT_SMF.1 Specification of Management Functions

Table 7-7 Authorized Roles for Management of Security Functions Behaviour

Section/Function Function/Authorized Role Backup and Recovery The capability to configure the backup parameters shall

be restricted to administrators authorized to export sensitive data. The capability to initiate the backup or recovery function shall be restricted to administrators authorized to export sensitive data

Certificate Registration The capability to approve fields or extensions to be included in a certificate shall be restricted to administrators authorized to issue certificates.

Data Export and Output Private key recovery and subsequent export shall be

2 Note that these roles are non-exclusive: depending on an organization’s needs, individual administrators may hold all or only a limited set of these authorizations. 3 [assignment: the authorised identified roles] 4 [selection: determine the behaviour of, disable, enable, modify the behaviour of] 5 [assignment: list of functions] 6 [assignment: the authorised identified roles]



restricted to the two administrators authorized to recover that particular private key.

Certificate Status Change Approval

The revocation of a certificate shall be restricted to administrators authorized to revoke a certificate.

TSF Configuration The capability to configure any TSF functionality shall be restricted to security officers. (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.)

Certificate Profile Management

The capability to modify the certificate profile shall be restricted so that no one can change it.

Revocation Profile Management

The capability to modify the revocation profile shall be restricted so that no one can change it.

Certificate Revocation List Profile Management

The capability to modify the certificate revocation list profile shall be restricted so that no one can change it.

Online Certificate Status Protocol (OCSP) Profile Management

The capability to modify the OCSP profile shall be restricted so that no one can change it.

FMT_SMF.1 Specification of Management Functions Hierarchical to: No other components. FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: [listed in Table 7-7].7 Dependencies: No dependencies.

7.1.2 Access Control

FDP_ACC.1 Subset access control Hierarchical to: No other components. FDP_ACC.1.1 The TSF shall enforce the [TOE Access Control Policy]8 on [the users and administrators as subjects, the issued/revoked/recovered certificates as objects, and the operations of issuing/revoking/recovering/exporting the certificates and the associated data].9 Dependencies: FDP_ACF.1 Security attribute based access control

7 [assignment: list of management functions to be provided by the TSF] 8 [assignment: access control SFP]. 9 [assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]



FDP_ACF.1 Security attribute based access control Hierarchical to: No other components. FDP_ACF.1.1 The TSF shall enforce the [TOE Access Control Policy]10 to objects based on the following: [the set of roles that the subject is authorized to assume, and the rights required for each operation].11 FDP_ACF.1.2 The TSF shall enforce the following12rules specified in Table 7-813to determine if an operation among controlled subjects and controlled objects is allowed: [see Table 7-8]14. FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [none].15 FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [none].16 Dependencies: FDP_ACC.1 Subset access control

FMT_MSA.3 Static attribute initialization Table 7-8 Access Controls

Section/Function Event Certificate Issuance The issuance of a certificate shall be restricted to

administrators authorized to issue certificates17. Certificate Revocation The revocation of a certificate

shall be restricted to administrators authorized to revoke certificates18.

Data Export and The export or output of confidential and

10 [assignment: access control SFP] 11 [assignment: list of subjects and objects controlled under the indicated SFP, and for each, the SFP-relevant security attributes, or named groups of SFP-relevant security attributes], explicitly stated that it is the role 12 Refinement: the location for the rules is explicitly named. This is cleared then “following” so this is a valid operation. 13 Refinement: the location for the rules is explicitly named. This is cleared then “following” so this is a valid operation. 14 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects], refinement for readability to explicitly refer to the one central location of the defined access control rules. This is a valid operation for readability. 15 [assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects] 16 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects] 17 Informal note: the subject of the requested certificate typically pre-fills the data, but the administrator has the final say of the data, ultimately by accepting or refusing to issue the certificate. Therefore this is pre-filling is seen as an administrative optimalization outside the scope of the evaluation. 18 Informal note: the subject of the certificate to be revoked can request such a revocation, but the administrator actually issues the revocation (also without such a request). Therefore this is request is seen as an administrative optimalization outside the scope of the evaluation.



Output security-relevant data shall only be at the request of administrators authorized to export this potentially sensitive data.

Private Key Recovery The recovery of certificate subject private keys shall be restricted to the two administrators authorized to recover the private keys of that specific certificate.

Role assignment Assignment of authorization to administrators shall be restricted to the security officer.

7.1.3 Identification and authentication

FIA_UAU.1 Timing of authentication Hierarchical to: No other components. FIA_UAU.1.1 The TSF shall allow [access to the login screen and help menu (of the eTrust CA portal for end-users, and of the eTrust CMS for Officers)]19 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. Dependencies: FIA_UID.1 Timing of identification FIA_UID.1 Timing of identification Hierarchical to: No other components. FIA_UID.1.1 The TSF shall allow [access to the login screen and help menu (of the eTrust CA portal for end-users, and of the eTrust CMS for Officers)]20 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. Dependencies: No dependencies. FIA_USB.1 User-subject binding Hierarchical to: No other components.

19 [assignment: list of TSF mediated actions] 20 [assignment: list of TSF mediated actions]



FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects acting on behalf of that user: [user role and assigned rights21] 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: [no rules for the initial association of attributes22]. FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user security attributes associated with the subjects acting on the behalf of users: [only the Security Officer can change these security attributes (user role and assigned rights) 23]. Dependencies: FIA_ATD.1 User attribute definition FIA_ATD.1 User attribute definition Hierarchical to: No other components. FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users: [user role and assigned rights].24 Dependencies: No dependencies

7.2 TOE SECURITY ASSURANCE REQUIREMENT

This ST and TOE claim compliance to EAL2, which consists of ADV_ARC.1, ADV_FSP.2, ADV_TDS.1, AGD_OPE.1, AGD_PRE.1, ALC_CMC.2, ALC_CMS.2, ALC_DEL.1, ASE_CCL.1, ASE_ECD.1, ASE_INT.1, ASE_OBJ.2, ASE_REQ.2, ASE_SPD.1, ASE_TSS.1, ATE_COV.1, ATE_FUN.1, ATE_IND.2 and AVA_VAN.2. All SARs are drawn by reference from CC Part 3.

7.3 SECURITY REQUIREMENTS RATIONALES

All open operations have been performed as indicated in the chapter “SECURITY REQUIREMENTS”.

21 [assignment: list of user security attributes] 22 [assignment: rules for the initial association of attributes]: all attributes are immediately configured by the user when creating the subject, hence there is not relevant initialization value. 23 [assignment: rules for the changing of attributes]. 24 [assignment: list of security attributes]



7.3.1 SAR rationale

EAL2 was originally chosen to be consistent with the minimum requirements of the CICM PP (EAL1+AVA_SOF.1+ATE_FUN.1) and augment these to a consistent assurance package. This assurance level is deemed to be a good balance between assurance sought by the users and evaluation costs for this product.

7.3.2 SAR dependencies rationale

The SARs of the ST are defined as EAL2. All EALs are consistent and all dependencies are met.

7.3.3 SFR rationale

The below table shows for each objective for the TOE, how it is fully covered in the SFRs. Security objective for the TOE Detail SFRs Rationale O.Identification_and_authentication all

administrators are identified [...] prior to further access to the TOE

FIA_UID.1 A direct implementation of the objective into the requirement.

all administrators are [...] authenticated prior to further access to the TOE

FIA_UAU.1 A direct implementation of the objective into the requirement.

O.Authorization_of_administrators

only the security officers can assign the roles and associated access rights to the administrators

FMT_MOF.1 FMT_MOF.1 describes that the TSF configuration is restricted to only the security officer, preventing an unauthorized administrator to change these settings



and obtain the rights that indirect way.

FMT_SMR.1, FMT_SMF.1

FMT_SMR.1 and FMT_SMF.1 describe the administrator roles (including the security officer) assignment needed for the above access control.

FIA_ATD.1, FIA_USB.1

FIA_ATD.1 describes the attributes as the specific rights assigned to a role and the roles assigned to a user. FIA_USB.1 states that only the Security Officer can change these attributes.

O.Issuance only administrators with the right to issue certificates assigned to them, can issue certificates.

FDP_ACC.1, FDP_ACF.1

Both SFRs refer to Table 7-8, where the function “Certificate Issuance” covers exactly this objective in a direct implementation into the requirement.

FMT_MOF.1 FMT_MOF.1 describes that the rights to manage the



TSF related to the certificate issuance are given only to administrators who have the right to issue certificates, preventing an unauthorized administrator to change these settings and obtain the rights that indirect way.


FMT_SMR.1 and FMT_SMF.1 describe the administrator role assignment needed for the above access control.

O.Revocation only administrators with the right to revoke certificates assigned to them, can revoke certificates.


Both SFRs refer to Table 7-8, where the function “Certificate Revocation” covers exactly this objective in a direct implementation into the requirement.

FMT_MOF.1 FMT_MOF.1 describes that the rights to manage the TSF related to the certificate revocation are given only to



administrators who have the right to revoke certificates, preventing an unauthorized administrator to change these settings and obtain the rights that indirect way.



O.Recovery only administrators with the right to recover the private key associated to the certificates assigned to them, can recover this private key.


Both SFRs refer to Table 7-8, where the function “Private Key Recovery” covers exactly this objective in a direct implementation into the requirement.

FMT_MOF.1 FMT_MOF.1 describes that the rights to manage the TSF related to the private key recovery are given only to administrators who have the right to recover



the secret keys related to that certificate, preventing an unauthorized administrator to change these settings and obtain the rights that indirect way.



O.Export

only administrators can cause the TOE to export potential sensitive data, such as backups.


Both SFRs refer to Table 7-8, where the function “Data Export and Output” covers exactly this objective in a direct implementation into the requirement.

FMT_MOF.1 FMT_MOF.1 describes that the rights to manage the TSF related to the export o potentially sensitive data are given only to administrators who have the right to export



the potential sensitive data, preventing an unauthorized administrator to change these settings and obtain the rights that indirect way.



Table 5: SFR rationale

7.3.4 SFR dependencies rationale

The following table shows the SFR dependencies and whether they are met. SFR Dependencies Met? FMT_SMR.1 FIA_UID.1 Yes FMT_MOF.1 FMT_SMR.1 Yes FMT_SMF.1 Yes FMT_SMF.1 None Yes FDP_ACC.1 FDP_ACF.1 Yes FDP_ACF.1 FDP_ACC.1 Yes FMT_MSA.3 Not applicable, see below FIA_UAU.1 FIA_UID.1 Yes FIA_UID.1 None Yes FIA_USB.1 FIA_ATD.1 Yes FIA_ATD.1 None Yes Table 6: SFR dependencies rationale

The SFR FDP_ACF.1 has a dependency on FMT_MSA.3 that is not applicable. Security attributes of the administrators (their authorizations) are immediately assigned by the security officer at the creation of the administrator account, there are no applicable default initial values.



8 TOE SUMMARY SPECIFICATION

8.1 IMPLEMENTATATION OF THE SFRS

The below table shows per SFR and relevant detail how the eTrust CMS meets these details. The below table is an excerpt from the ADV evaluation evidence, ensuring consistency and ease of evaluation until deep into the design, at the cost slightly reduced readability.

SFR SFR

detail level 1

Detail level 2 Detail level 3

Subsystem(s)

Rationale

Roles FMT_SMR.1 Security roles

maintain the roles

[administrator with authorization to issue certificates, administrator with authorization to revoke certificates, administrator with authorization to recover private keys associated with certificates, administrator with the authorization to export potentially sensitive data, security officer]

eTrust CMS

eTrust CMS controls access to all eTrust system data associated with operations initiated by any eTrust operator. The rights assigned by the Security Officer to these administrators are defined in roles. To issue certificates the role requires access to the “Individual Certificate Issuance Screen” and/or the “Device Certificate Issuance Screen”. These screens guide the Officer through the issuing of the certificate, asking the required information. To revoke certificates the role requires access to the “Individual Certificate Revocation Screen” and/or the “Device Certificate Revocation Screen”. These screens guide the Officer through the process, providing an interface for searching and selecting the



certificate to revoke. To recover certificates the role requires access to the “Key administration Screen”. This screen guides the Officers (key recovery requires both Officers assigned to a specific certificate) through the process of recovery of the certificate and its associated private key. To export potentially sensitive information (besides the recovery as described directly above) the role requires access to the “Database Archiving Setup Screen”. This screen guides the Officer through the database backup process. The Security Officer is defined as having the right to assign the rights, requiring access to the “Officer Group Policy Setup Screen” for the role definitions and/or the “Officer Policy Setup Screen” for the assignment of Officer to roles.

associate users with roles

FMT_MOF.1 Management of security functions behavior

restrict the ability to [modify the behaviour]

Backup and Recovery

The capability to configure the backup parameters shall be restricted

eTrust CMS

The eTrust CMS allows only administrators authorized to access the “Database Archiving Setup Screen” to make backups and restore them. Note that with direct



to administrators authorized to export sensitive data. The capability to initiate the backup or recovery function shall be restricted to administrators authorized to export sensitive data

access to the underlying platform one can also make backups, but this is not considered in the scope of the evaluation (as described in OE.Hosting and OE.TrustedAdmins).

Certificate Registration

The capability to approve fields or extensions to be included in a certificate shall be restricted to administrators authorized to issue certificates.

eTrust CMS

All management access to the eTrust CMS requires Officer-level access (i.e. an authorized administrator).

Data Export and Output

Private key recovery and subsequen

eTrust CMS

The export of private keys requires access to the GUI, which is restricted to



t export shall be restricted to the two administrators authorized to recover that particular private key.

administrators. This operation is performed via the Key Management Module, which is restricted to administrators authorized to access this page. The operation itself requires the authorization of at least two administrators.

Certificate Status Change Approval

The revocation of a certificate shall be restricted to administrators authorized to revoke a certificate.

eTrust CMS

The automated process of CRL issuance (the output of the revocation) is not configurable except with direct access to the underlying platform. Certificate management is performed in the Certificate Enrollment module, which requires access to the eTrust CMS GUI and hence restricted to administrators authorized to revoke certificates only.

TSF Configuration

The capability to configure any TSF functionality shall be restricted to security officers. (This requirement applies to all configuration parameters unless the

eTrust CMS

The capability to configure any TSF functionality is only provided via the eTrust CMS GUI or direct access to the underlying platform. Direct access to the underlying platform is out of scope based on OE.Hosting, except for trusted administrators and based on OE.TrustedAdmins these are also out of scope. Specific configurations all have their own setup screens with specific access rights associated to them. The Security Officers are the only



ability to configure that aspect of the TSF functionality has been assigned to a different role elsewhere in this document.)

administrators given this right.

Certificate Profile Management

The capability to modify the certificate profile shall be restricted so that no one can change it.

N/A Fulfilled by absence of the functionality: eTrust CMS does not provide the ability to change this.

Revocation Profile Management

The capability to modify the revocation profile shall be restricted so that no one can change it.


Certificate Revocation List Profile Management

The capability to modify the certificate revocation list profile shall be restricted so that no




one can change it.

Online Certificate Status Protocol (OCSP) Profile Management

The capability to modify the OCSP profile shall be restricted so that no one can change it.


FMT_SMF.1 Specification of Management Functions

capable of performing the following management functions (reference to FMT_MOF.1)

See above (FMT_MOF.1) for the specifics.

Identical to the implementation of FMT_MOF.1.

Access control

FDP_ACC.1 Subset access control

enforce the TOE Access Control Policy

eTrust CMS

eTrust CMS controls access to all eTrust system data associated with operations initiated by any eTrust operator.

[the users and administrators as subjects, the issued/revoked/recovered certificates as objects, and the

eTrust CMS

To issue certificates the role requires access to the “Individual Certificate Issuance Screen” and/or the “Device Certificate Issuance Screen”. To revoke certificates the role requires access to the “Individual Certificate Revocation Screen” and/or the “Device Certificate Revocation Screen”.



operations of issuing/revoking/recovering/exporting the certificates and the associated data]

To recover certificates the role requires access to the “Key administration Screen”. To export potentially sensitive information (besides the recovery as described directly above) the role requires access to the “Database Archiving Setup Screen”.

FDP_ACF.1 Security attribute based access control

enforce the TOE Access Control Policy

See FDP_ACC.1 Subset access control


the set of roles that the subject is authorized to assume, and the rights required for each operation



enforce the rules specified in Table 7-8

Certificate Issuance

The issuance of a certificate shall be restricted to administrators authorized to issue certificates

eTrust CMS

This operation can be only performed using the eTrust CMS GUI, restricting it to administrators. Only administrators holding the right to access the certificate enrolment module can perform this task.

Certificate Revocation

The revocation of a certificate

See above See above



shall be restricted to administrators authorized to revoke certificates.

Data Export and Output

The export or output of confidential and security-relevant data shall only be at the request of administrators authorized to export this potentially sensitive data.

eTrust CMS

This operation can be only performed using the eTrust CMS GUI, restricting it to administrators. Only administrators holding the right to the certificate enrolment and/or key recovery functions can perform this task.

Private Key Recovery

The recovery of certificate subject private keys shall be restricted to the two administrators authorized to recover the private keys of that specific

eTrust CMS

The capability to request the decryption of certificate subject private keys is restricted to administrators during key recovery for the requested users. The private keys are themselves encrypted to the keys of exactly two of the administrators with the key recovery rights. This ensures that both administrators are involved in this recovery step.



certificate. None N/A N/A N/A N/A None N/A N/A N/A N/A Identification_and_authentication

FIA_UAU.1 Timing of authentication

allow access to the login screen and help menu (of the eTrust CA portal for end-users, and of the eTrust CMS for Officers)

eTrust CMS

eTrust CMS allows access to the login screen to allow the attempt to identify / authenticate. This login screen also has a help screen.

require each user to be successfully authenticated

eTrust CMS

eTrust CMS does not allow the selection of any eTrust CMS-mediated function before the administrator is successfully authenticated with an authorized administrator certificate using SSL/TLS 2-way authentication. All functions require the operator to be authenticated before allowing any eTrust CMS-mediated action.

FIA_UID.1 Timing of identification

allow access to the login screen and help menu

See FIA_UAU.1

See FIA_UAU.1



(of the eTrust CA portal for end-users, and of the eTrust CMS for Officers)

require each user to be successfully authenticated

See FIA_UAU.1

See FIA_UAU.1

FIA_USB.1 User-subject binding

user role and assigned rights

eTrust CMS

The user identity is authenticated at login and remains associated with subjects acting on behalf of the user as long as the login session is valid.

no rules for the initial association of attributes

N/A N/A

rules for the changing of attributes

N/A N/A

FIA_ATD.1 User attribute definition

maintain the following list of security attributes belonging to individu

See FIA_USB.1

See FIA_USB.1



al users: [user role and assigned rights]

Table 7: TOE Summary Specification: implementation of the SFRs

eVault Certificate Management System Security Target Certificate... · eVault Technologies Sdn....

Documents

Transcript of eVault Certificate Management System Security Target Certificate... · eVault Technologies Sdn....