Compliant Product - CertAgent v7.0 Patch Level 9
Certificate Date: 2021.08.06CC Certificate Security Target Validation Report
Validation Report Number: CCEVS-VR-VID11180-2021
Product Type: Certificate Authority
Conformance Claim: Protection Profile Compliant
PP Identifier: Protection Profile for Certification Authorities Version 2.1
CC Testing Lab: Leidos Common Criteria Testing Laboratory
The TOE is Information Security Corporation’s CertAgent certificate authority, a Web-based, X.509-compliant certificate authority (CA) that is intended to be used as the core component of an enterprise public key infrastructure.
The TOE is the CertAgent v7.0 patch level 9, which is an X.509-compliant certificate authority (CA). It is an easily managed, web-based certificate authority (CA) intended to be used as the core component of an enterprise public key infrastructure (PKI). Designed to meet the needs of a wide variety of organizations, the current release offers enhanced enrollment services (EST), remote administration, integrated certificate and CRL database, and an OCSP responder. It supports an unlimited number of root and intermediate CAs, providing support for as complex a certificate hierarchy as the size of the enterprise warrants.
Security Evaluation Summary
The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) process and scheme for the Protection Profile for Certification Authorities, version 2.1. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1 release 5, as well as the Assurance Activities contained in the Protection Profile. The product, when delivered and configured as identified in the guidance documentation, satisfies all of the security functional requirements stated in the Information Security Corporation CertAgent v7.0 patch level 9 Security Target for Common Criteria Evaluation. The evaluation was completed on August 6 2021. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report prepared by CCEVS.
The TOE generates audit records of administrator, user, and its own activities. Audit data includes date, time, event type, subject identity, and other data as required. Most audit data are written to the database. Audit records indicating a database failure are stored in a local text file as the database is inaccessible. The TOE allows an external IT entity to access TOE audit records in the database by polling the TOE using the DBAccess REST API.
The TOE relies on the TLS/HyperText Transfer Protocol Secure (HTTPS) when transmitting sensitive data to and from applicable endpoints.
Certificate requests, certificates, CRLs, and OCSP responses are formed and verified according to RFC 5280, RFC 6960, and RFC 7030. Certificate validation is performed by the TOE.
Sensitive data that needs to be recovered (PKCS#11 Cryptographic Module PINs and other authentication passwords) are encrypted using CMS, in conformance with RFC 5652, and then stored in the database. Sensitive data that does not need to be recovered, EST passwords, are not stored directly, but a check value is created, using PBKDF2/SHA-256, and stored.
Cryptographic support is provided by two components.
The ISC CDK is within the TOE’s boundary and is used by the TOE:
PKCS#11 Cryptographic Module
The PKCS#11 Cryptographic Module is used by the TOE:
The PKCS#11 Cryptographic Module securely stores the high value certificate authority keys and uses them to perform the signature operations that define a certificate authority. The PKCS#11 Cryptographic Module also securely stores the TLS/HTTPS server key and provides cryptographic services involving that key. PKCS#11 Cryptographic Modules often require a PIN or other authentication when the application using them starts and the TOE provides mechanisms for injecting this information during its startup procedures.
In the evaluated configuration, the PKCS#11Cryptographic Module is Thales’ Luna USB HSM.
The TOE supports the creation of multiple certificate profiles by CA Administrators. Each profile is customizable by a CA Administrator and includes a certificate-based ACL of CA Operations Staff members allowed to issue or revoke certificates using the profile. Certificate requests are assigned a unique identifier upon submission that is used to link the request to the issued certificate.
The TOE provides relying parties two methods to check the status of a certificate:
CRLs can be issued manually, on a schedule, or when a certificate is revoked for a set of configurable reason codes.
The TOE uses two different identification and authentication methods, depending on the role and action being performed:
Most TOE activities, and all activities involving the issuance or revocation of certificates, require certificate-based authentication.
PKCS#11 Cryptographic Modules support a variety of authentication options including passwords, smart cards, PED devices, and fingerprints. In all cases, someone must enable the PKCS#11 Cryptographic Module as part of the initialization of the TOE. This step is performed locally on the system during startup of the TOE.
Access to the TOE’s local console is controlled by the underlying environmental operating system which performs the required identification and authentication when an administrator logs on.
The TOE is managed by authorized administrators using a web user interface and the local console as needed. All certificate issuance related administrative actions are performed via the web interface. The TOE supports three (3) roles (Administrator, Auditor, and CA Operations Staff) each of which consists of an access control list (ACL) of one or more X.509 certificates and one or more permissions (issue, revoke, RAMI, etc.).
Only users who hold an administrator role in the TOE are allowed to have administrator privileges on the physical system on which the TOE is installed. They can:
The TOE encrypts any sensitive information, before it is sent to the environmental database, using the asymmetric “System” credential’s public key and the CMS format. These encrypted symmetric keys are the only symmetric keys that are persisted by the TOE. When the information is needed later, the encrypted data is retrieved from the database, and the TOE uses the “System” credential’s private key, via the PKCS#11 Cryptographic Module’s PKCS#11 API, to unwrap the symmetric key.
The TOE maintains the password of PKCS#11 Cryptographic Module storing the “System” credential in memory until it exits. The TOE does not store, or directly use, any private keys (they are stored and protected by the PKCS#11 Cryptographic Module which performs operations with those keys at the TOE’s request). When the TOE shuts down all sensitive data in memory is cleared.
The TOE’s Admin Site and CA Account Site display a warning banner prior to allowing any administrative actions to be performed. The TOE’s web interface will terminate sessions when they time out or when an authenticated user clicks the logout link in the navigation pane.
The TOE provides a trusted path/channel for secure communication between itself and external IT entities such as a registration authority (RA), audit server, or similar entities which are permitted to connect to the TOE, over client authenticated HTTPS/TLS. Privileged users accessing the TOE’s web interfaces also use a trusted path established and secured with client authenticated HTTPS/TLS. Subscribers with existing, valid certificates, also use a trusted path, established and secured with client authenticated HTTPS/TLS, to perform certificate renewal, via EST, or self-management, via the TOE’s Public Site web interface. Subscribers, and other non-privileged users, are permitted to connect to the TOE’s Public Site with unauthenticated HTTPS/TLS. Relying parties are permitted to connect to parts of the TOE’s Public Site, with either unauthenticated HTTPS/TLS or unprotected HTTP, to obtain certificate status or other information required to validate certificates issued by the TOE.
For communication between the TOE and environmental components (notably the database and the HSM) the Operational Environment provides a non-encrypted, trusted channel. Secure communication is enforced between the TOE and IT entities in the Operational Environment using the Operational Environment’s JRE, JNDI, JDBC, and PKCS #11 Cryptographic Module components installed on the local system. These trusted channels transfer TOE data to and from IT entities within the Operational Environment.
Information Security Corporation