Commvault Crypto Library

Certificate

Approved Algorithms (13)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for Commvault Crypto Library
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>self-test<br/>Status output<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>application</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
    I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
    R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
    E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  C6 --> I6 --> R6 --> E6
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Commvault Crypto Library
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>self-test<br/>Status output<br/>Show Status</i><br/>src: text:keyword"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>application</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C5,C6 clueLow;

Security Policy, page by page

Commvault Systems, Inc. Commvault Crypto Library Software Version: 3.0 FIPS 140-3 Non-Proprietary Security Policy Level 1 Validation November 2024 Prepared by: www.acumensecurity.net Public Material – May be reproduced only in its original entirety (without revision).

1. General Introduction Federal Information Processing Standards Publication 140-3

• Security Requirements for Cryptographic modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) runs the Cryptographic Module Validation Program (CMVP) program. The NVLAP accredits independent testing labs to perform FIPS 140-3 testing; the CMVP validates modules meeting FIPS 140-3 validation. Validated is the term given to a module that is documented and tested against the FIPS 140-3 criteria. More information is available on the CMVP website at: https://csrc.nist.gov/projects/cryptographic-module-validation-program. About this document This non-proprietary cryptographic module security policy for the Commvault Systems, Inc. Commvault Crypto Library, provides an overview of the product and a high-level description of how it meets the overall Level 1 security requirements of FIPS 140-3. The Commvault Crypto Library may also be referred to as the “module” in this document. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Commvault Systems, Inc. shall have no liability for any error or damages of any kind resulting from the use of this document. Notices This document may be freely reproduced and distributed in its entirety without modification. Public Material
• May be reproduced only in its original entirety (without revision).

This document describes the cryptographic module security policy for the Commvault Crypto Library (also referred to as the “module” hereafter) with software version 3.0 from Commvault Systems, Inc. The module type is software and has a multi-chip standalone embodiment. It contains specification of the security rules, under which the cryptographic module operates, including the security rules derived from the requirements of the FIPS 140-3 standard. The following table lists the level of validation for each area in FIPS 140-3: Table 1

• Security Levels The module claims an overall Security Level 1. Public Material
• May be reproduced only in its original entirety (without revision).

2. Cryptographic module specification The tested platforms are as follows: Table 2

• Tested Operational Environments The module is vendor-affirmed to operate on the platforms listed below. The CMVP makes no claim as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment which is not listed on the validation certificate. Table 3
• Vendor Affirmed Operational Environments Module usage & cryptographic boundary Commvault Crypto Library is a library-based software cryptographic module, providing cryptographic services to all Commvault products. Particularly Commvault Backup and Recovery and Metallic™. Commvault Backup and Recovery and Metallic is composed of several program modules allowing one to perform data backup, hierarchical storage management (data archiving) and continuous data replication. The cvcl.dll and libcvcl.so, version 3.0, binaries provide encryption services for Commvault Backup and Recovery and Metallic platforms and represent the cryptographic boundary of the module. The module implements AES (data encryption, key protection), RSA (key generation, signing, verification), SHA-1, SHA2-256, SHA2-512, HMAC-SHA-1, HMAC-SHA2-256, HMAC-SHA2-512, and AES

256 CTR_DRBG algorithms in the approved mode. The module type is software and has a multichip

stand-alone embodiment. Commvault Crypto Library is packaged as a dynamic (shared) software module exporting the cryptographic API to any software that supports C calling conventions. The cryptographic module’s operational environment is a modifiable operational environment. The cryptographic boundary of the software module consists of cvcl.dll and libcvcl.so, per the image in Figure 1. No components have been excluded from the cryptographic boundary of the module. Public Material – May be reproduced only in its original entirety (without revision).

Figure 1

• Cryptographic Boundary Block Diagram Public Material
• May be reproduced only in its original entirety (without revision).

General Purpose Computing Platform Figure 2

• Physical Perimeter Public Material
• May be reproduced only in its original entirety (without revision).

The module claims an overall Security Level of

1. The module does not implement any non-invasive security mitigations or mitigations of other attacks and thus the requirements per these sections are not applicable. Modes of operation The module supports both an approved and non-approved mode of operation. Both modes of operation are determined by this security policy, as the module does not enforce the rules associated with each mode. It is the responsibility of the caller to ensure that only approved algorithms and services are utilized. The module provides an indicator for each available algorithm, which specifies whether the algorithm is approved or non-approved. The module must always be zeroised when switching between the approved mode of operation and the non-approved mode of operation and vice-versa. Approved mode To use the module in the approved mode, it must be installed and operated in accordance with the rules described in this section. After the module initializes, all services are available to the user, and it is the user’s responsibility to only call approved or allowed services to ensure the module is operating in the approved mode of operation. Please see Section 11 of this document for secure setup and initialization requirements. Module security policy rules The module will operate in the approved mode only if approved cryptographic services are used. Since the module provides both approved and non-approved services, it is the application loading the module that is responsible to ensure that it is using only approved services. (Please refer to Table 9 for the list and classification of all module services.) For the Backup and Recovery user, the correct data encryption method should be selected in the properties of each of the client machines in the CommCell. Non-approved mode If non-approved cryptography and services are selected, the module will be operating in the nonapproved mode. These algorithms and services shall not be used when operating in the approved mode of operation. Degraded operation The module does not support a degraded mode of operation. Overall security rules of operation The module design corresponds to the security rules below. The term shall in this context specifically refers to a requirement for correct usage of the module in the Approved mode; all other statements indicate a security rule implemented by the module.
2. Self-tests do not require any operator action. Public Material – May be reproduced only in its original entirety (without revision).

2. Data output is inhibited during SSP generation, self-test execution, zeroisation, and error states.
3. Status information does not contain SSPs or sensitive data that if misused could lead to a compromise of the module.
4. There are no restrictions on which SSPs are zeroised by the zeroisation service. Successful zeroisation (by either restart or function call procedure) for the operator is implicitly indicated by the successful completion of the procedural zeroisation service method.
5. The module does not support a maintenance interface or role.
6. The module does not output intermediate key values.
7. The module does not output plaintext CSPs.
8. The Crypto Officer shall retain control of the module while zeroisation is in process.
9. From the perspective of the Backup and Recovery user, the correct data encryption method should be selected in the properties of each of the client machines in the CommCell. There are algorithms, modes, and key/moduli sizes that have been CAVP-tested but are not used by any approved service of the module. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are used by an approved service of the module. Public Material – May be reproduced only in its original entirety (without revision).

B=U Table 4

• Approved Algorithms The module does not support any non-Approved algorithms in the Approved mode. (It supports neither Non-Approved Algorithms Allowed in the Approved Mode of Operation, nor Non-Approved Algorithms Allowed in the Approved Mode of Operation with No Security Claimed.) Note: The resulting symmetric key and generated seed is an unmodified output from the implemented DRBG. Public Material
• May be reproduced only in its original entirety (without revision).

Table 5 – Non-Approved Algorithms Not Allowed in the Approved Mode of Operation

3. Cryptographic module interfaces Table 6 – Ports and Interfaces
4. Roles, services, and authentication The module supports a Crypto Officer (CO) role. The maintenance role is not supported, nor is authentication. The module also does not support concurrent operators. The Crypto-Officer role is implicitly assumed, and the module does not provide an authentication mechanism for the supported role. The module relies on the underlying operating system to implement fine-grained access control. The OS authentication mechanisms should be enabled by the administrator of the OS. The Triple-DES algorithm was CAVP tested but does not comply with the requirements of IG C.G, so is therefore classified as a Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 9

• Approved Services G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g. the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. 1024-bit modulo only used for signature verification Public Material
• May be reproduced only in its original entirety (without revision).

Table 10

• Non-Approved Services Public Material
• May be reproduced only in its original entirety (without revision).

5. Software/Firmware security The module is shipped with a precomputed RSA signature file, (cvcl.dll.sig or libcvcl.so.sig). The signature is generated using an RSA EMSA-PKCS1-v1_5 4096-bit with SHA2-512 private key. The public/private RSA 4096-bit key pair is generated during manufacturing. The public key is hard coded in the module and is used for signature verification. The RSA public key used for the integrity test is not considered an SSP. As part of the software integrity check, the entire cvcl.dll Windows module or libcvcl.so Unix based module shared library is verified against this signature. If the signature verification fails, the module transitions to the error state, and finally back to the non-initialized state, where no further cryptographic operations are possible.
6. Operational environment The module is designed to work on a General-Purpose Computer with one of the supported modifiable operating systems: • Microsoft Windows Server 2019 (Tested on Intel Xeon R Silver 4208 with and without AES-NI) • Red Hat Enterprise Linux 8.4 (Tested Intel Xeon R Silver 4208 with and without AES-NI) The operating system segregates the computing environment into processes spaces. Though all processes share the same hardware resources, they are logically separated from each other by the operating system. Each process has an independent pool of virtual memory, and the module functions completely within the address space of the process that loads it. The module does not attempt to communicate with other processes or other components of the operating system, and the operating system shouldn’t allow other processes to interfere with the module. It is the administrator’s responsibility to configure the operating system authentication mechanisms and ensure that only authorized users have access to the software that is loading the module. Since the Commvault Crypto Library is a software module executing within a general-purpose computer, and the physical cryptographic perimeter is drawn through the hardware interfaces of the computer, (i.e.: Ethernet or SCSI Bus), all major data paths within the computer must be protected. The replacement or modification of the module by unauthorized parties is explicitly prohibited. There are no restrictions on the configuration of the operational environment.
7. Physical security Physical security is not applicable to this software module at Security Level 1.
8. Non-invasive security The module does not implement non-invasive security measures.
9. Sensitive security parameter management Implemented algorithms Public Material – May be reproduced only in its original entirety (without revision).

The module provides low-level key generation and management routines for all algorithms listed in Table 4 of this Security Policy. Since the module implements both approved and non-approved algorithms, it is the responsibility of the user to ensure that only the approved services are being used (please refer to the sub-sections “Secure setup and initialization” and “Module security policy rules” for more details). Key generation The module provides services to generate pseudo-random symmetric and asymmetric keys and is passively receiving entropy. The module sets a function callback whenever entropy is required using “void cvcl_set_getentropy_cb(cvcl_get_rand_t get_rand)” API. The callback function requires a minimum of 384 bits of entropy. Symmetric keys are generated using the direct output of the CTR_DRBG. For asymmetric key generation, a provable prime method is used in accordance with FIPS 186-4 standard. Key entry and output The module does not import or export keys across the physical cryptographic perimeter. It is the responsibility of the application that loads the module to protect keys when they’re being exported or imported across the physical cryptographic perimeter. It is also the responsibility of the application to ensure that only Approved cryptographic algorithms are being used for key protection. The module accepts and passes keys across the cryptographic boundary as parameters via API calls. Key storage The module does not provide any long-term key storage. Keys stored in the NVRAM are protected from unauthorized disclosure, access or modification by the operating system that is responsible for allocating isolated and independent virtual memory for the module and the process using it. Zeroisation of keys All data output is inhibited during the zeroisation of SSPs. The following precautions are taken to make sure that all keys and seeds are being destroyed properly:

• CVCL module zeroises all intermediate security sensitive material.
• CVCL module zeroises all keys passed to the authorized services when the services are no longer needed and are being destroyed.
• The following API is used to call init and call destroy: CVCL_API void * cvcl_XXX_init(int * error_num, char * error_buf, int error_len); CVCL_API void cvcl_XXX_destroy(void * XXX); Note: “XXX” is the algorithm being used.
• The zeroisation is performed by overwriting the SSPs with zeroes. Public Material
• May be reproduced only in its original entirety (without revision).

(Commvault Systems, Inc. © 2024) Version Public Material – May be reproduced only in its original entirety (without revision).

Table 11

• SSPs (Commvault Systems, Inc. © 2024) Version Public Material
• May be reproduced only in its original entirety (without revision).

Table 12

• Non-Deterministic Random Number Generation Specification 10. Self-tests The module is a software shared library that can be loaded by one of the Commvault applications. Before the library can be used in cryptographic operations, it must be initialized. The loading application performs initialization by calling the CVCL initialization function, which internally executes the self-tests. Upon successful completion, the library is switched to the Initialized State. While self-tests are running, data input and data output interfaces are inhibited. To run the self-tests on-demand, the module must be re-instantiated. Prior to the execution of the pre-operational software integrity test, a conditional CAST is performed for RSA. The module performs the following self-tests: Pre-operational self-tests: Software Integrity Test: RSA 4096 with SHA-512 signature verification computed on the cvcl.dll file for Windows and libcvcl.so file for UNIX and makes sure that the signature matches the precomputed value provided in the signature file (cvcl.dll.sig or libcvcl.so.sig). To initiate the software integrity test ondemand, explicitly call the following API that performs the test: api - cvcl_verify_sig(dll_fname, error_buf, error_len) Conditional self-tests: Conditional Cryptographic Algorithm Self-tests (CAST) (#A2412):
• AES-CBC 256 bits Encrypt KAT
• AES-CBC 256 bits Decrypt KAT
• AES-ECB 256 bits Encrypt KAT
• AES-ECB 256 bits Decrypt KAT
• RSA 2048 bits SHA2-256 Sign KAT
• RSA 3072 bits SHA2-256 Sign KAT
• RSA 4096 bits SHA2-256 Sign KAT
• RSA 1024 bits SHA2-256 Verify KAT
• RSA 2048 bits SHA2-256 Verify KAT Public Material
• May be reproduced only in its original entirety (without revision).

• RSA 3072 bits SHA2-256 Verify KAT
• RSA 4096 bits SHA2-256 Verify KAT
• SHA-1 KAT
• SHA2-256 KAT
• SHA2-512 KAT
• HMAC-SHA-1 KAT
• HMAC-SHA2-256 KAT
• HMAC-SHA2-512 KAT
• CTR_DRBG (AES256) KAT (Generate, Instantiate and Reseed) Conditional Pairwise Consistency Self-tests:
• Pairwise consistency test when generating RSA key pairs (for signature generation/verification) At power-up, the pre-operational and conditional self-tests are carried out. If any self-test fails, the module transitions to the error state and back to the non-initialized state, where the applicable error code (6) is returned to the program that attempted to load the module. While the self-tests are being executed, and when the module is in an error state, the data input and data output interfaces are inhibited. When conditional self-tests fail, the module transitions to the error state (return code 7), and no further cryptographic operations can be executed until the controlling application successfully reinitializes the module. In the event of a pre-operational or conditional self-test failure, the user should retry initialization and if this doesn’t fix the error, uninstall, and re-install the module from the original installation media. 11. Life-cycle assurance This section describes design, coding and testing practices used at Commvault during the production of the module. Please refer below for Crypto Officer and Commvault administrative end user guides detailing the correct installation, configuration, management, and usage procedures that are required for the secure operation of the module. Secure setup and initialization The module is bundled with the Commvault software platform, distributed and installable using the Commvault download manager. To install the module correctly, you must follow the installation instructions provided in the Commvault documentation. You must have enough space on the hard disk, enough memory, and possess administrative privileges on the computer where the product is being installed. The operating system must have an authentication mechanism configured that will allow only authorized users to use the product (and module) after it has been installed. The host operating system must be configured by the administrator such that only the administrator’s account is enabled, while all other user accounts (including guest accounts) are disabled. Public Material
• May be reproduced only in its original entirety (without revision).

Once the Commvault product is installed, there are no other procedures for secure installation, initialization and startup of the cryptographic module. Once the hardware platform is powered on, the module will be in initialized state. To validate that the module has been installed successfully and is operating in the approved mode, the following action is required:

• Navigate to the software’s Base folder.
• Check the module version from the command line by opening the command line window on the GPC where Commvault is installed. Execute cvcl_ver.exe executable (Windows) or cvcl_ver (UNIX) and make sure that it displays “CVCL version 3.0” of the module. The module version 3.0 is returned by the API cvcl_get_version(). Check that the module successfully loaded and entered the approved mode by opening the cvcl.log file on the applicable computers and searching for the message “CVCL: Running in FIPS”. Also, check that the individual algorithms are reporting whether they are approved algorithms or not. Please note that the module identifier is also obtained by accessing the cvcl.log mentioned above, which contains “CVCL” in the first line of output “CVCL: Running in FIPS”. It can be used to correlate the output “CVCL” to “Commvault Crypto Library”, which is the name of the module. The following is an example of the possible log output:

8924 3d68 06/28 16:44:21 ### Cvcl::init() - CVCL: Running in FIPS

8924 3d68 06/28 16:44:21 ### Cvcl::init() - 3DES: Not FIPS-approved

8924 3d68 06/28 16:44:21 ### Cvcl::init() - AES: FIPS-approved

8924 3d68 06/28 16:44:21 ### Cvcl::init() - Blowfish: Not FIPS-approved

8924 3d68 06/28 16:44:21 ### Cvcl::init() - DES: Not FIPS-approved

8924 3d68 06/28 16:44:21 ### Cvcl::init() - GOST: Not FIPS-approved

8924 3d68 06/28 16:44:21 ### Cvcl::init() - RSA sign/verify: FIPS-approved

8924 3d68 06/28 16:44:21 ### Cvcl::init() - RSA encrypt/decrypt: Not FIPS-approved

8924 3d68 06/28 16:44:21 ### Cvcl::init() - Serpent: Not FIPS-approved

8924 3d68 06/28 16:44:21 ### Cvcl::init() - Twofish: Not FIPS-approved

8924 3d68 06/28 16:44:21 ### Cvcl::init() - SHA1: FIPS-approved

8924 3d68 06/28 16:44:21 ### Cvcl::init() - SHA256: FIPS-approved

8924 3d68 06/28 16:44:21 ### Cvcl::init() - SHA512: FIPS-approved

8924 3d68 06/28 16:44:21 ### Cvcl::init() - MD5: Not FIPS-approved

Figure 3

• Log Output Example Configuration management A Concurrent Versioning System (CVS) is used by the module development team for configuration management, change control and version control. All modifications made to the module are logged, along with the comments that accompanied them, and a complete history of changes is maintained in the CVS repository. Every individual change is assigned a unique version number. In addition, for every Public Material
• May be reproduced only in its original entirety (without revision).

software release, a release-specific symbolic tag is assigned to all source files and documents thereby creating a snapshot of the components included in the release. Development The module is written using high level language “C” with several time-critical pieces optimized using architecture-specific low-level assembler instructions on some platforms (AES-NI). A software defect tracking software called Silk Radar is being used to log defects discovered during testing and to keep track of their resolution by the development team. As part of the build sequence the module is compiled, linked, self-tested and signed. For every build released to the system test, a series of acceptance tests is conducted to verify at a higher level that cryptographic operations are working as expected. End-of-life The module can be sanitized by resetting the host platform on which it is run, zeroising all SSPs. 12. Mitigation of other attacks The module does not mitigate against any specific attacks outside of the scope of FIPS 140-3. Public Material – May be reproduced only in its original entirety (without revision).