© 2020 CommVault Systems, Inc. All rights reserved. http://www.commvault.com
This document may be freely reproduced and distributed whole and intact including this copyright notice.
CommVault Systems, Inc.
CommVault Crypto Library, v2.0
FIPS 140-2 Non-Proprietary
Security Policy
Level 1 Validation
January 2021
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
2
Table of Contents
1 Introduction.............................................................................................................................................2
1.1 Overview.................................................................................................................................................2
1.2 Purpose ..................................................................................................................................................2
1.3 References .............................................................................................................................................3
1.4 Document History ...................................................................................................................................3
2 Cryptographic Module Specification.......................................................................................................3
3 Cryptographic Module Ports and Interfaces ...........................................................................................4
4 Roles, Services and Authentication........................................................................................................7
4.1 Identification and Authentication.............................................................................................................7
4.2 Roles and Services.................................................................................................................................7
5 Physical Security ....................................................................................................................................8
6 Operational Environment........................................................................................................................8
7 Cryptographic Key Management............................................................................................................9
7.1 Implemented algorithms .........................................................................................................................9
7.2 Key Generation.......................................................................................................................................9
7.3 Key Entry and Output .............................................................................................................................9
7.4 Key Storage............................................................................................................................................9
7.5 Zeroization of Keys.................................................................................................................................9
7.6 Supported keys.....................................................................................................................................10
8 Self-Tests..............................................................................................................................................11
8.1 Power-On Self Tests ............................................................................................................................11
8.1.1 Software Integrity Test ........................................................................................................11
8.1.2 Known Answer Tests ..........................................................................................................11
8.2 Conditional Tests..................................................................................................................................12
8.2.1 RSA Key Pair Generation Test ...........................................................................................12
8.3 Failure of the Self-Tests .......................................................................................................................12
9 Design Assurance.................................................................................................................................12
9.1 Configuration Management ..................................................................................................................12
9.2 Development.........................................................................................................................................12
10 Crypto-Officer and User Guide...........................................................................................................12
10.1 Secure Setup and Initialization........................................................................................................13
10.2 Module Security Policy Rules..........................................................................................................13
11 Mitigation of Other Attacks .................................................................................................................14
1 INTRODUCTION
1.1 Overview
CommVault Crypto Library (CVCL) is a cryptographic software module used in various products by
CommVault Systems, Inc. The module provides a collection of FIPS Approved and Non-FIPS Approved
cryptographic services for key generation, symmetric and asymmetric encryption, hash, HMAC and
signature generation/verification.
1.2 Purpose
This document is a non-proprietary FIPS 140-2 Level 1 Security Policy for the CVCL Module version 2.0
serving the following purposes:
1. It describes how the module conforms to the eleven sections of the FIPS 140-2 Level 1
Standard.
2. It provides user with instructions on how to install and operate the module in order to comply with
FIPS 140-2.
3. It is required for the FIPS 140-2 validation.
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
3
FIPS 140-2 (Federal Information Processing Standards Publication 140-2) specifies the security
requirements for a cryptographic module protecting sensitive information. Based on four security levels
for cryptographic modules this standard identifies requirements in eleven sections. For more information
about the standard please visit http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-2.pdf.
1.3 References
• NIST Security Requirements for Cryptographic Modules, FIPS PUB 140-2, December 03, 2002
• NIST Security Requirements for Cryptographic Modules, Annex A: Approved Security Functions for
FIPS PUB 140-2, May 19, 2007
• NIST Security Requirements for Cryptographic Modules, Annex B: Approved Protection Profiles for
FIPS PUB 140-2, June 14, 2007
• NIST Security Requirements for Cryptographic Modules, Annex C: Approved Random Number
Generators for FIPS PUB 140-2, March 19, 2007
• NIST Security Requirements for Cryptographic Modules, Annex D: Approved Key Establishment
Techniques for FIPS PUB 140-2, June 26, 2007
• Advanced Encryption Standard, FIPS PUB 197, November 11, 2001
• The Keyed-Hash Message Authentication Code (HMAC), FIPS PUB 198, March 6, 2002
• Additional publications can be found on NIST website at
http://csrc.nist.gov/publications/PubsFIPS.html
• For more information about CommVault Systems, Inc. visit http://www.commvault.com.
1.4 Document History
Authors Date Version Comment
Andrei Erofeev 11/01/07 1.0 Initial revision
Andrei Erofeev 09/30/08 1.1 Feedback from DOMUS
Andrei Erofeev 12/30/08 1.2 Feedback from CMVP
Andrei Erofeev 02/23/09 1.3 More comments from CMVP
Andrei Erofeev 04/27/09 1.4 Clarified DRBG retries
Alex Miege 03/20/16 1.5 Redraft for new validation.
Andrei Erofeev 05/15/16 1.6 Corrections
Alex Miege 03/04/2017 1.7 Added new alg. certificates
Alex Miege 03/20/2017 1.8 Modifications to table 4 and 5
Brad Proffitt 05/05/2017 1.9 Typo fixes
Brad Proffitt
Brad Proffitt
05/11/2017
08/18/2017
2.0
2.1
Added details on platforms on page 4 and 8
Updated to address CMVP comments
Brad Proffitt 09/28/2017 2.2 Updated to address CMVP comments
Brad Proffitt 10/24/2017 2.3 Updated to address CMVP comments
Brad Proffitt 11/01/2017 2.4 Updated to address CMVP comments
Brad Proffitt 11/06/2017 2.5 Updated to address CMVP comments
David Cunningham 01/15/2021 2.6 Updated to address FIPS 186-2 transition
2 CRYPTOGRAPHIC MODULE SPECIFICATION
CommVault Crypto Library (CVCL) is a software library providing cryptographic services to all CommVault
products, particularly to Simpana, the enterprise level backup solution. Simpana is composed of several
program modules allowing one to perform data backup, hierarchical storage management (data archiving)
and continuous data replication.
CVCL implements Triple-DES, AES (data encryption, key protection), RSA (key generation, signing,
verification), SHA-1, SHA-256, SHA-512, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA512, and CTR-
DRBG-AES256 algorithms in the approved FIPS mode.
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
4
In addition to the FIPS Approved algorithms CVCL implements Blowfish, Serpent, Twofish, DES, RSA
(encrypt/decrypt), MD5, and HMAC-MD5 algorithms. These algorithms shall not be used when operating
in the FIPS Approved mode of operation.
CVCL is packaged as a dynamic (shared) software module exporting cryptographic API to any software
that supports C calling conventions.
The product meets the overall requirements applicable to Level 1 security for FIPS 140-2 as outlined in
the following table.
Security Requirements Section Level
Cryptographic Module Specification 1
Cryptographic Module Ports and Interfaces 1
Roles and Services and Authentication 1
Finite State Machine Model 1
Physical Security N/A
Operational Environment 1
Cryptographic Key Management 1
EMI/EMC 3
Self-Tests 1
Design Assurance 3
Mitigation of Other Attacks N/A
Cryptographic Module Security Policy 1
Overall Level of Certification 1
Table 1: Module Compliance Table
The module was tested and validated on a Dell PowerEdge R210 running Microsoft Windows Server
2012 R2.
The module was tested and validated on a Dell PowerEdge R410 running Red Hat Enterprise Linux v7.
The module was tested and validated on a HP EliteDesk 800 G1 USDT running Solaris 11.
3 CRYPTOGRAPHIC MODULE PORTS AND INTERFACES
The module is classified as a multi-chip standalone module designed to meet FIPS 140-2 Level 1
requirements. The physical interfaces of the module are the same as the computer system on which it is
executing. The logical interfaces are the C API calls through which the module is providing its services. In
particular, Data Input Interface is a collection of C API calls that accept through their arguments data to
be used in cryptographic operations, Data Output Interface is a collection of C API calls that return
processed or generated data back to the controlling program through their arguments or return codes,
Control Input Interface is a collection of C API calls that are used to initialize and control the operation of
the module. Status Output Interface is a C API call that is used to query the status of the module.
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
5
Logical Cryptographic Boundary
Figure 1: Software Block Diagram
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
6
Data Storage Battery
CPU
Memory
Network
Interface
SCSI Interface
Network
Mouse
Tape
Storage
Keyboard
Monitor
System Bus
Status
Output
Control
Input
Physical Cryptographic Boundary
Data flow, Control Input,
and Status Output
Status Output
Control Input
Figure 2: Hardware Block Diagram
The table below describes supported logical and physical interfaces as well as the relationships between
them.
FIPS 140-2 Interface Logical Interface Physical Interface
Data Input interface The API C calls that accept
input data for processing
through their arguments.
Ethernet, mouse, keyboard.
Data Output interface The API C calls that return by
means of their return codes
or arguments generated or
processed data back to the
caller.
Ethernet, mouse, keyboard,
monitor.
Control Input interface The API C calls that are used
to initialize and control the
operation of the CVCL
module.
Ethernet, mouse, keyboard.
Status Output interface The API C calls that are used
to query the status of the
Ethernet, mouse, keyboard,
monitor, hard disk.
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
7
CVCL module. Cvcl.log file
where the status is being
output to after completion of
initialization and POST.
Power Interface N/A 120V Power Supply
Table 2: Mapping Physical and Logical Interfaces
4 ROLES, SERVICES AND AUTHENTICATION
4.1 Identification and Authentication
The CVCL module implements the following two roles: Crypto-Officer and User role. Maintenance role is
not supported. The roles are implicitly assumed and the module does not provide an authentication
mechanism that would allow to explicitly distinguish users between the two supported roles. The module
relies on the Operating System to implement fine-grained access control, thus if only certain user should
be permitted to use the module’s services, the OS authentication mechanisms should be enabled by the
OS administrator.
Role Type of Authentication Authentication Data
User N/A N/A
Crypto Officer N/A N/A
Table 3: Authentication Type Table
4.2 Roles and Services
The table below lists supported FIPS Approved, FIPS Allowed and Non-FIPS Approved authorized
services. For each service it specifies which role the service can be used in, what cryptographic keys and
critical security parameters (CSP) the service can access and how.
R - The item is read or referenced by the service.
W -The item is written or updated by the service.
E - The item is executed by the service. (The item is used as part of a cryptographic function.)
Role
Approved
Cryptographic Keys and
CSPs
Access
Type
Crypto
Officer
User
FIPS Approved
X Installation of the Module None N/A
X X Initialization of the Module None N/A
X X Power-on self-test Module RSA Public Signature
Key
RE
X X Key Generation
• Triple-DES, AES, HMAC Keys
• RSA KeyGen (FIPS 186-4)
Symmetric Keys, Asymmetric
Key Pairs
RWE
X X Key Zeroization Symmetric Keys, Asymmetric
Key Pairs
WE
X X Querying the state of the module None N/A
X X Symmetric Data Encryption/Decryption
• Triple-DES – ECB, CBC modes
with 192-bit keys.
• AES – ECB, CBC modes with
128-bit and 256-bit keys.
Triple DES, AES keys RE
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
8
X X Digest Algorithms
• SHA-1
• SHA-256
• SHA-512
None N/A
X X Message Authentication
• HMAC-SHA-1
• HMAC-SHA-256
• HMAC-SHA-512
• RSA signature generation and
verification
RSA key pairs,
HMAC keys
RE
X X Pseudo-Random Number Generation
• CTR-DRBG-AES256
AES-CTR DRBG Seed
AES-CTR DRBG Entropy
Input AES-CTR DRBG V
AES-CTR DRBG Key
RWE
X X Module RSA Public Key RSA key pairs RE
FIPS Allowed
X X NDRNG Seeds the CTR-DRBG-
AES256
RWE
Non-FIPS Approved
X X Symmetric Data Encryption/Decryption
• DES – ECB, CBC modes
• Blowfish with 128-bit and 256-bit
keys – ECB, CBC modes
• Serpent with 128-bit and 256-bit
keys – ECB, CBC modes
• Twofish with 128-bit and 256-bit
keys – ECB, CBC modes
DES, Blowfish, Serpent, and
Twofish keys
RE
X X Digest Algorithms
• MD5
None N/A
X X Asymmetric Data Encryption/Decryption
• RSA with 2048- 3072- and
4096-bit keys
RSA 186-2 Key Generation
RSA key pairs RE
X X Data Authentication:
• HMAC-MD5
HMAC-MD5 key RE
Table 4: Roles and Services
Note: Non-FIPS Approved algorithms listed above shall not be used when operating in the FIPS
Approved mode of operation.
5 PHYSICAL SECURITY
Physical security is not applicable to this software module at Security Level 1.
6 OPERATIONAL ENVIRONMENT
CVCL Module is designed to work on a General-Purpose Computer with one of the supported operating
systems:
1. Microsoft Windows Server 2012 R2 (Tested on Intel Xeon X3430 with and without AES-NI);
2. Red Hat Enterprise Linux v7 (Tested on Intel Xeon E5504 with and without AES-NI); and
3. Solaris 11 (Intel Core i7 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 CVCL module
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
9
functions completely within the address space of the process that loads it. CVCL module does not
attempt to communicate with other processes or other components of operating system, and operating
system shouldn’t allow other processes to interfere with the module. On this accord the module satisfies
the FIPS 140-2 requirement for a single user mode of operation.
It is the administrator’s responsibility to configure OS authentication mechanisms and ensure that only
authorized users have access to the software that is loading the CVCL Module.
Since CVCL Module is software executing within a General-Purpose Computer, and physical
cryptographic boundary is drawn through all the hardware interfaces of the Computer, such as Ethernet
or SCSI Bus, all major data paths within computer must be protected.
The replacement or modification of the Module by unauthorized parties is explicitly prohibited.
7 CRYPTOGRAPHIC KEY MANAGEMENT
7.1 Implemented algorithms
CVCL 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 FIPS Approved and Non-FIPS
Approved algorithms, it is the responsibility of the user to ensure that only the FIPS Approved services
are being used (Please refer to Section 10 “Crypto-Officer and User Guide” for more details).
7.2 Key Generation
The module provides services to generate pseudo-random symmetric and asymmetric keys. For
asymmetric key generation a provable prime method is used in accordance with FIPS 186-4 standard.
7.3 Key Entry and Output
CVCL Module does not import or export keys across the physical cryptographic boundary. 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 boundary. It is also the responsibility of the application to
ensure that only FIPS Approved cryptographic algorithms are being used for key protection.
CVCL Module accepts and passes keys across logical cryptographic boundary as parameters via API
calls.
7.4 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.
7.5 Zeroization of Keys
The following precautions are taken to make sure that all keys and seeds are being destroyed properly:
1. CVCL Module zeroizes all intermediate security sensitive material.
2. CVCL Module zeroizes all keys passed to the authorized services when the services are no
longer needed and are being destroyed.
3. CVCL Module provides API that can be used to explicitly reset any of the authorized services at
any time and to zeroize keys and seeds being used by them.
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
10
7.6 Supported keys
The following table summarizes the module’s keys and CSP’s:
Key Generation Use Role
Symmetric Triple-DES,
AES Keys
Generated internally using a
CTR-DRBG-AES256
Used to encrypt, decrypt data
and protect keys.
User, CO
Asymmetric RSA Keys Generated internally using a
provable prime method in
accordance with FIPS 186-4
standard.
Used to perform encrypt/
decrypt operations and
signature generation/
verification.
User, CO
Module RSA Public Key Hard coded within the module Used to verify the software
integrity at initialization
User, CO
HMAC keys Generated internally using a
CTR-DRBG-AES256
Used to generate and verify
HMAC
User, CO
DRBG (CTR AES) Seeded by the NDRNG
entropy source residing in the
physical boundary.
V (256 bits) and AES key
(256 bits), entropy input
(length dependent on security
strength)
User, CO
Table 5: Cryptographic Keys and CSPs
The module keys map to the following algorithms certificates:
Approved Security Function Certificate
Encryption/Decryption
Triple-DES (ECB, CBC) 2362
AES (ECB, CBC) key sizes(128,256) 4368
Hash Functions
SHA-1 3605
SHA-256 3605
SHA-512 3605
Message Authentication
HMAC-SHA-1 2907
HMAC-SHA-256 2907
HMAC-SHA-512 2907
Digital Signatures
186-2 KeyGen (see transition statement below)
186-2 SigGen (4096)
186-4 SigGen (2048, 3072)
186-4 KeyGen (2048, 3072)
186-4 SigVer (1024, 2048, 3072)
2365
Random Number Generation
DRBG-CTR-AES256 1405
Table 6: FIPS Approved Algorithms Table
Note: The resulting symmetric key and generated seed is an unmodified output from the implemented
DRBG.
RSA 186-2 Transition: Please be advised that the RSA entry in Table 6 above, specifies the use of RSA 186-2 for key
generation. RSA 186-2 key generation is no longer allowed as of September 1st
, 2020. Any use of RSA 186-2 for key
generation will mean that the module is operating in a non-Approved and non-compliant manner. (The use of 186-2 RSA 4096
SigGen remains compliant, due to the requisite RSA 186-4 (2048 and 3072) modes supported in the module.) Please see FIPS
140-2: IG G.18 for more information.
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
11
8 SELF-TESTS
8.1 Power-On Self Tests
As described in Section 2 “Cryptographic Module Specification”, CommVault Crypto Library 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 following two Power-On Self
Tests, upon successful completion of which the library is switched to the Initialized State. While running
the POST, data output and data input interfaces are inhibited.
In order to run the POST manually on-demand, the module must be re-instantiated.
8.1.1 Software Integrity Test
The module is shipped with a precomputed RSA EMSA-PKCS1-v1_5 signature. As part of the software
integrity check, the entire module shared library (DLL) is verified against this signature. If the signature
verification fails, Module is transitioned to the error and finally back to the non-initialized state, where no
further cryptographic operations are possible. In this case the user should retry initialization, and if this
doesn’t fix the error, uninstall and re-install the module from the original installation media.
8.1.2 Known Answer Tests
During Initialization the module performs a series of Known Answer Tests for all FIPS Approved and Non-
FIPS Approved algorithms according to the following table:
Algorithm Type Known Answer Test Executed
Symmetric Encryption, Decryption:
AES and Triple-DES in ECB and CBC
modes
For each of the supported symmetric encryption algorithm
(Triple-DES and AES), a hard coded plaintext is encrypted
with a hard coded key and the result is checked to match the
pre-computed ciphertext. If the comparison is successful, the
ciphertext is decrypted back, and the result is compared with
the original plaintext.
RSA Encryption, Decryption Hard coded plaintext is encrypted with hard coded RSA public
key, and the result is compared with precomputed ciphertext.
If the comparison is successful, the ciphertext is decrypted
back using matching hard coded RSA private key, and the
result is compared with the original plaintext.
RSA signature generation and
verification
A hard coded signature of a hard coded plaintext is verified
using a hard coded RSA public key.
A hard coded text is signed using a hard coded RSA private
key, and the signature is immediately verified using the
corresponding RSA public key.
Hash Functions: SHA-1, SHA-256 and
SHA-512
For each of the supported hash functions, a hard coded
sample text of various length is hashed, and the result is
compared with the precomputed hashes.
Message Authentication: HMAC-SHA-
1, HMAC-SHA-256 and HMAC-SHA-
512
For each of the supported HMACs, a hard coded sample text
of various lengths is used along with hard coded keys to
generate HMAC. The results are compared with the
precomputed values.
Random number generation The CTR-DRBG-AES256 is initialized with known values,
which are checked against pre-computed values. The CTR-
DRBG-AES256 is the only DRBG available in the module.
Table 7: Known Answer Tests
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
12
8.2 Conditional Tests
Conditional tests are executed after the CVCL Module has been successfully initialized, during execution
of one of the relevant Cryptographic Services.
8.2.1 RSA Key Pair Generation Test
Each time a new RSA Key Pair is generated, it is immediately checked for correctness by generating and
verifying signature of a SHA-1 hash. If the signature generation or verification fails, the Module will
attempt to generate the keys 4 more times, after which it will be switched to the Error State.
8.3 Failure of the Self-Tests
If one of the Power-On Self Tests fails, the Module is transitioned to the error state and then back to the
non-initialized state, and the appropriate error code is returned to the program that attempted to load the
Module. While the POST is being executed, both data input and data output interfaces are inhibited.
If one of the Conditional Tests fails, the Module is allowed to retry the operation 4 more times. If
Conditional Tests fail for all of the following attempts, the Module is transitioned to the Error state and no
further cryptographic operations can be executed until the controlling application reinitializes the Module.
9 DESIGN ASSURANCE
This section describes design, coding and testing practices used at CommVault during the production of
the CVCL Module. It also contains Crypto Officer and User Guides detailing the correct installation,
configuration, management and usage procedures that are required for the secure operation of the
Module.
9.1 Configuration Management
A Concurrent Versioning System (CVS) is being used by the CVCL 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 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.
9.2 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.
A software defect tracking software call 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.
10 CRYPTO-OFFICER AND USER GUIDE
In order to use the CVCL Cryptographic Module in an FIPS Approved Mode, it must be installed and
operated in accordance with the rules described in this section. After the module initializes all services
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
13
are available to the user, it is the user’s responsibility to only call approved or allowed services to ensure
the module is in an approved mode of operation.
10.1Secure Setup and Initialization
CVCL Cryptographic Module is distributed on a DVD bundled with one of the CommVault Systems
Products. In order to install CVCL correctly, you must follow installation instructions received with your
CommVault DVD. You must have sufficient amount of 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 the module after it has been installed. In order to use the CVCL module in single user
mode, the Operating System must be configured by the administrator in such a way that only
administrator’s account is enabled and all other user accounts including guest’s are disabled.
To validate that the CVCL Module has been installed successfully and is operated in the FIPS Approved
Mode, you should do the following:
• Check version of the CVCL Module from the command line:
1. Open command line window on the machine where Simpana is installed
2. Navigate to the software’s Base folder
3. Execute cvcl_ver.exe executable (Windows) or cvcl_ver (UNIX) and make sure that it
displays version 2.0 of CVCL Module
• Check whether the CVCL module successfully loaded and switched to the FIPS mode by opening
cvcl.log file on involved computers and searching for “CVCL: Running in FIPS Mode” message.
• Check version of the CVCL Module from the Java GUI
1. Start CommCell Console Java GUI
2. Right-click CommServe name in the list on the left, select “Properties”
3. In the “CommCell Properties” window open the “Version” tab
4. Make sure that there is a “Crypto Library Version: 2.0” line on top of the window.
• Make sure that one of the FIPS Approved cryptographic services is being used for data protection
1. Start CommCell Console Java GUI
2. Right-click the name of the client, which data you are going to back up. Select “Properties”
from the appeared popup menu
3. In the “Properties” window navigate to the “Encryption” tab.
4. Make sure that the “Data Encryption Algorithm” displays either “AES” or “Triple-DES”.
10.2Module Security Policy Rules
The module will operate in FIPS Approved mode if only FIPS Approved Cryptography Services are being
used. Since the CVCL Module provides both FIPS Approved and Non-FIPS Approved Services, it will be
the responsibility of the application that loaded the Module to ensure that it is using only the Approved
Services.
Please refer to Table 4 for the list and classification of all Cryptographic Services.
From the perspective of the Simpana user, correct data encryption method should be selected in the
properties of each of the client machines in the CommCell:
1. Start CommCell Console Java GUI
2. Right-click the name of the client, which data you are going to back up. Select “Properties” from
the appeared popup menu
3. In the “Properties” window navigate to the “Encryption” tab.
4. Make sure that the “Data Encryption Algorithm” displays either “AES” or “Triple-DES”.
Non-Proprietary FIPS 140-2 Security Policy
CommVault Systems Crypto Library (CVCL) v2.0
14
11 MITIGATION OF OTHER ATTACKS
The module does not mitigate against any specific attacks.