Data Encryption - FAQ
- 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?
- Where does decryption occur?
- How are user passwords encrypted, transmitted, and stored?
- What happens to encrypted data if you uninstall the license?
- Does encryption have an impact on compression when writing to media?
- Auxiliary Copy
- Where does Offline or Auxiliary copy encryption occur - at the source or target MediaAgent?
- If I enable encryption during both backup and offline/auxiliary copy – is the data encrypted twice?
- How does deduplication affect data encryption?
- Pass Phrase
- When would I use a Pass Phrase?
- Can I change the 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?
- If hardware encryption is enabled – will this further encrypt already encrypted data?
- Can I restore hardware encrypted data using Media Explorer?
- 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 NetApp set the Encryption algorithm and key length for hardware encryption?
- How are keys derived?
- 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 identified?
- How are keys authenticated?
- How are keys stored in the CommServe database?
- 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?
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%. Note that this estimated performance hit is not applicable to deduplicated data as deduplication process discards all duplicate data and only encrypts data blocks that are unique in the entire deduplication database. Hence the performance hit for deduplicated data will be low.
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 cipher text stream.
Integrity for each data block up-to 64 KB is checked with CRC32.
|Type of Encrypted Data||Decryption Will Occur On|
NetApp 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, by using encryption when performing backup operations, the data is effectively randomized. This means that the compression algorithms will not be as effective when compressing the encrypted data. So when this data gets written to media there will be a noticeable difference in the compression ratio.
Example: A tape with a Native capacity of 110GB which at one time got 190GB compressed may now only get 124GB written to the same tape when using encryption as well.
The amount of data that can be written to tape varies depending on the type of data getting written that is Image files will not be compressed as they are already considered compressed but a TXT file is highly compressible.
Offline Encryption performed during an auxiliary copy operation is performed at the source MediaAgent. This provides transmission path security.
No, the data is not encrypted twice. Data that has been encrypted by SnapProtect 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 NetApp 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.
Some tape drives such as, Ultrium (LTO-4 or later), are encryption-capable. Other drive types might also support encryption. However, to confirm encryption support, we recommend that you refer to the drive vendor’s documentation.
For more information on hardware encryption, see Hardware Encryption.
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 NetApp. 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 the terms use AES-256 for FIPS compliance. NetApp 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.
For Hardware Encryption, we generate a different random 128 or 256 key for every data 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.
For SnapProtect software encryption, a new key is generated for each backup.
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 malfunction.
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.
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().
Pass-phrase option is not supported with deduplication.
If you are creating a secondary copy from an encrypted-deduplicated source copy, the software automatically decrypts the deduplicated data during the creation of the secondary copy. Thus, if you wish to create a fully encrypted secondary copy of data from an encrypted-deduplicated source copy, ensure that the secondary copy is configured for re-encryption. Otherwise, the deduplicated portion of the data will remain decrypted.
- The Pass-Phrase feature is deprecated. For similar functionality, use Privacy.
- Clients with existing Pass-Phrase configurations are supported.
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.
See Reset a Pass Phrase for instructions.
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.