Topics | How To | Support |FAQ| Related Topics
How can I tell if a job has been encrypted and by what method?
What kind of performance hit can I expect from encryption?
Which is the most secure encryption algorithm?
Can I encrypt NDMP data during backup or auxiliary copy?
Does Encryption require a Certificate Authority?
What is the cryptographic library used?
What is the AES block mode of operation and IV management for encrypted data?
What integrity checks are performed on encrypted data?
How are User passwords encrypted, transmitted, and stores?
What happens to encrypted data if you uninstall the license?
Does Calypso Monitor software encrypted data stay encrypted during auxiliary copy?
Where does Offline/Auxiliary copy encryption occur - at the source or target MediaAgent?
Is Offline/Auxiliary copy Encryption supported on all MediaAgent host operating systems?
If I enable encryption during both backup and offline/auxiliary copy – is the data encrypted twice?
If hardware encryption is enabled – will this further encrypt already encrypted data?
Can I restore hardware encrypted data using Media Explorer?
Does hardware encryption require a License?
What Encryption-capable tape drives are supported?
What happens to jobs if Hardware encryption is selected but the drive does not support it?
Do we support any third party encryption hardware?
Can Bull Calypso set the Encryption algorithm and key length for hardware encryption?
What is the ANSI 9.31 implementation?
Is a persistent seed used for the random number generator?
How often are keys changed for each system?
How are keys integrity checked?
How are keys stored in the CommServe database?
If someone had access to the CommServe database could they use the keys to decrypt data?
Are keys stored anywhere else?
How are keys backed up for disaster recovery purposes?
Who has access to the encryption keys?
How are keys destroyed when they are no longer needed?
When would I use a Pass Phrase?
How are Pass Phrases used to authenticate a restore?
Where are Pass Phrases stored?
Can I restore Pass Phrase protected data using the Command Line Interface?
The Jobs in Storage Policy report will show a superscript E or an HE next to the job ID for jobs that have been software or hardware encrypted respectively.
Software encryption is a CPU intensive operation and can reduce your backup or auxiliary copy performance by an estimated 40%-50%.
Hardware encryption has a significantly less impact of about 10%.
RijnDael, by virtue of it being the Advanced Encryption Standard (AES), would be considered the most secure encryption algorithm; However, AES was selected based on a series of requirements of which security level was just one. All candidates for AES met or exceeded the security requirement. Serpent and Twofish ciphers were also AES candidates. Twofish is faster and Serpent is considered more secure.
If the NDMP data is directed to a NDMP Remote Server-enabled MediaAgent for data protection or auxiliary copy you can software and hardware encrypt the data. For NDMP data sent directly to a filer-attached library only hardware encryption is supported. Filer direct Hardware encryption requires a 3rd party key management system.
Certificate Authority is required only for Asymmetric cryptography where different keys are used to encrypt (using private key) and decrypt (using public key) the data. All of our encryption is symmetric cryptography (the same key is used to encrypt and decrypt) ,so there is no need for a certificate or a certificate authority.
Asymmetric crypto is typically used when you are sending data over insecure lines (like over the internet) and the identity of entities at each end is not known, the CA helps validate the authenticity of that sent data so that malicious data is not sent. In our case, since there are known entities at both ends this issue does not exist.
| We do not encrypt data set with a single key. Instead we generate a key for every chunk of data that is written which means there is an extremely minimal chance of the entire data being lost even if one key is compromised. |
CommVault Cryptographic Library Version – 1.0 (FIPS 140-2 Certified)
AES 256 - CBC mode. Each 64KB block is a single CBC chain. IVs are randomly generated using a ANSI 9.31 random number generator. There is no extra special management of IVs. They are included into the ciphertext stream.
Integrity for each up-to-64KB encrypted data block is checked with CRC32.
| Type of encrypted data | Decryption will occur on: |
| Hardware | Hardware device |
| Software |
|
Bull Calypso user passwords are encrypted using a proprietary algorithm and transmitted/stored only in encrypted format. External (Active Directory) user passwords are not stored.
Existing data remains encrypted and can be recovered. New data will not have the option for encryption.
Yes, source or primary encrypted data remains encrypted for all subsequent copies within the storage policy. However, if the auxiliary copy source is an encrypted dedupe store then data encrypted as part of the dedupe process will be decrypted by an auxiliary copy job. In this case, if you want to retain encryption then Offline encryption must be enabled on the destination copy.
Offline encryption which can be configured to occur during auxiliary copy also allows you to retain the existing cipher method – or use an alternate cipher method
Offline Encryption performed during an auxiliary copy operation is performed at the source MediaAgent. This provides transmission path security.
No, the Netware MediaAgent does not support auxiliary copy encryption.
No, the data is not encrypted twice. Data that has been encrypted by Calypso Monitor software is flagged. During an auxiliary copy operation the flag is checked and, if the data has already been encrypted, no additional software encryption is applied. Only data that has not been encrypted by Bull Calypso will be encrypted during the auxiliary copy process.
Yes, software encrypted data will be further encrypted if hardware encryption is enabled. We strongly recommend enabling one or the other – not both.
Yes, Media Explorer supports restore of hardware encrypted data from a supported drive.
Encryption licensing is broken up into following parts:
| License Type | Provided for | Applied at |
| Data Encryption |
|
The CommCell® level for all client data. |
| Auxiliary Copy Encryption | Secondary copy encryption during the auxiliary copy operation | The MediaAgent level and is required for each destination MediaAgent performing Offline Encryption. |
Bull Calypso software currently supports only LTO-4 encryption capable tape drives. Refer to Hardware Encryption for more details.
The Hardware encryption option is enabled on the Storage Policy copy as a property of the data path. Hardware encryption is only applicable for supported Tape Devices. If the drive does not support hardware encryption and the option is selected, backups running to the drive will fail.
Hardware encryption devices with their own key management software such as Network Appliances (formerly Decru’s) Datafort can be used. These inline devices are transparent to the data flow from Bull Calypso. However, data written via these devices must be restored via these devices and it is the customer’s responsibility to provide and manage these devices.
No, hardware encryption algorithm and key length is fixed by the hardware vendor. Most of tem use AES-256 for FIPS compliance. Bull Calypso can enable or disable hardware encryption. Any variance to algorithm or key length used is hardware vendor dependent.
Keys are generated from a random number generator. The random number generator we use is ANSI 9.31 It’s used to produce RSA key pair for the client, generate random 128-bit or 256-bit data encryption keys for every chunk and initial vectors (IV) for CBC chaining during data encryption.
ANSI 9.31 is the standard for digital signatures based on the RSA algorithm. It requires the MDC-2 hash algorithm.
Refer to http://csrc.nist.gov/groups/STM/cavp/documents/rng/931rngext.pdf for more information.
No. Various random OS-supplied data is used.
We generate a different random 128 or 256 key for every chunk we write. Each job can contain multiple chunks, so each backup job can have multiple randomly generated keys. With multiple different keys the strength of the encryption is very high.
Every key stored in the Database has CRC32 embedded. This is used only to check whether a key has been entered incorrectly. If an error is detected the user will be prompted to re-enter the pass phrase or check for network/media corruption.
Keys are identified by their storage location in the database. We don’t embed IDs into the keys.
They are wrapped using AES Key Wrap Specification.
Refer to AES Key Wrap Specification for more details.
Data encryption keys are stored in the database encrypted with RSA public key of the client. RSA private key of the client is stored encrypted either with a built-in pass-phrase or with the pass-phrase provided by user, depending on the settings.
If the data is encrypted:
Keys can optionally be written to the backup media for manual recovery of data using Media Explorer.
A regularly scheduled Export and Backup of the CommServe Database (DR Backup task) provides Disaster Recovery protection.
No users are allowed access to the keys. Our keys are stored in the CommServe Database encrypted with RSA public key of the client. RSA private key of the client is stored encrypted either with a built-in pass-phrase or with the pass-phrase provided by user, depending on the settings. The user provided Pass Phrase is not stored anywhere. Only authorized users (configured from user management) can set and change these pass phrases. Pass phrases are never displayed in clear text.
When chunks are pruned (erased), the database entry and associated key for that chunk is deleted. Open keys in memory are deleted using memset().
A Pass Phrase can be enabled and set differently for each client providing unique protection of the encryption keys for data .For example; you may want to provide unique Pass Phrases for certain financial data servers and personnel file servers. When restoring Pass Phrase encrypted data, you must manually provide the Pass Phrase. If you lose the Pass Phrase, the encrypted data is unrecoverable.
Yes, you can change the Pass Phrase at anytime. You do not need to maintain the older Pass Phrase. Since a Pass Phrase can only be used for CommCell® recovery of encrypted data, the latest version of the Pass Phrase cannot be used to decrypt all previous Pass Phrase protected data.
They are used to decrypt the RSA private key of the client. The RSA private key is then used to decrypt the chunk keys. Chunk keys are used to decrypt the data.
Pass phrases are not stored. Pass phrase must be entered manually by the user for each recovery. However, by creating and exporting a file that contains the scrambled pass-phrase of the client computer to a dedicated directory on another computer, the system can recover the client's data to that (and only that) computer without prompting for the pass-phrase.
Yes, by exporting the pass phrase to the target client then use the normal Command Line Interface restore process to recover the data.
Refer to Export an Encryption Pass Phrase for more details.