SvSAN Data Encryption FAQ
This FAQ provides answers to a series of questions surrounding the features and benefits of SvSAN's Data Encryption element. Click on any of the questions in the list to be taken to the corresponding answer further down the page.
If you cannot find the answer to your question, you can contact the StorMagic team at [email protected].
This FAQ only deals with the Data Encryption feature of SvSAN. For the main SvSAN FAQ, please click here.
- What is data encryption?
- What cryptographic library does SvSAN Data Encryption use?
- What encryption algorithm/cipher is used to encrypt the data?
- What is the crypto key length?
- Does SvSAN Data Encryption conform to the Federal Information Processing Standard (FIPS) 140-2?
- What is Enterprise Key Management (EKM)?
- What is the OASIS Key Management Interoperability Protocol (KMIP)?
- Does SvSAN Data Encryption support KMIP, if so, what versions?
- What network ports are required to communicate to the KMS?
- What KMS solutions have been tested with SvSAN Data Encryption?
- How many key management servers should I have?
- Does SvSAN Data Encryption require any special encryption hardware?
- Is it possible to encrypt an existing volume that has data stored on it?
- Is it possible to re-key and re-encrypt a volume?
- What is the performance impact of enabling encryption on a volume?
- Is it possible to Secure Erase a disk drive or volume?
Gartner defines encryption as:
“Encryption is the process of systematically encoding a bit stream before transmission so that an unauthorized party cannot decipher it.”
Encryption should be considered as one aspect of a wider security strategy and is the process of translating data from one form (plaintext) to another (ciphertext). It ensures that if the data falls into an unauthorised parties hands, the data cannot accessed without having the correct encryption keys to decrypt the data.
Data-at-rest encryption protects data when it is stored on disk and can be used to protect data from unauthorized access or equipment theft.
In the event of a disk failure, the failed disks can now be disposed or replaced without fear of data being accessed, as it is encrypted. This eliminates the requirement for data destruction techniques such as “degaussing” of magnetic disks, physical destruction or “disk scrubbing”.
The SvSAN Data Encryption feature uses the widely available open source “OpenSSL” library that provides the encryption algorithms.
The current version is OpenSSL 1.0.2n.
SvSAN Data Encryption uses the XTS-AES-256 cipher.
The SvSAN Data Encryption feature uses an embedded FIPS 140-2 (Level 1) validated cryptographic module (OpenSSL Object Module v2.0, Certificate #1747) running on SvSAN platform per FIPS 140-2 Implementation Guidance section G.5 guidelines.
It utilizes a military grade cryptographic cipher (XTS-AES-256) that is FIPS 140-2 compliant and meets HIPAA, PCI DSS and SOX standards.
However, SvSAN itself is not currently FIPS 140-2 validated.
Gartner defines Enterprise Key Management (EKM) as:
“Enterprise key management (EKM) provides a single, centralized software or network appliance for multiple symmetric encryption or tokenization cryptographic solutions. Critically, it enforces consistent data access policies through encryption and tokenization management. It also facilitates key distribution and secure key storage, and maintains consistent key life cycle management.”
In addition, they also state that:
“EKM products adopt the Key Management Interoperability Protocol (KMIP) standard, sponsored by the Organization for the Advancement of Structured Information Standards (OASIS). EKM solutions can manage any cryptographic solutions that are compliant with KMIP.”
Key Management Interoperability Protocol (KMIP) was introduced by OASIS in 2010 and is a single, standard protocol for communication between key management systems and encryption solutions.
Prior to KMIP each vendor would have their own encryption key management solution leading to multiple key management solutions (KMS) being used, which increases management overhead.
KMIP provides a standard mechanism for applications, storage arrays, tape libraries, disk drives (Self-Encrypting Drives) and networking equipment to communicate with key management solutions (KMS) from different vendors, reducing the number of key management solutions required.
SvSAN Data Encryption supports KMIP versions 1.0 to 1.4.
By default, KMIP uses port the 5696, as assigned by IANA (Internet Assigned Numbers Authority). This is the only port that should need to be opened of a firewall between SvSAN and the KMS.
As the SvSAN Data Encryption uses KMIP for encryption key management, then it should just work with all KMIP compliant KMS solutions. This includes software based KMS solutions and hardware security modules (HSM). A HSM is a hardened, tamper-resistant appliance that is specifically designed for the protection of the cryptographic keys.
Example KMS solutions include:
- Hytrust KeyControl
- Gemalto SafeNet KeySecure
- Thales Vormetric Data Security Manager
- Dell/EMC Cloudlink
- Fornetix Key Orchestration
- HPE Secure Key Manager
- IBM Security Key Lifecycle Manager
- Townsend Security Alliance Key Manager
- Hancom Secure
- Cryptomathic Key Management System
- Oracle Key Manager
- QuintessenceLabs qCrypt Key and Policy Manager
Availability is the most important requirement of key management. Therefore, it is highly recommended to have at least two or possibly more key management servers to ensure keys are always available.
If it is not possible to contact the KMS to retrieve the cryptographic keys, it is not possible to encrypt or more importantly, decrypt the data and the data is lost.
Having multiple key management servers allows the keys to be replicated, and ideally they would be installed in different locations/datacenters to ensure that power outages, floods, fire, etc do not interrupt availability.
In addition to having multiple servers, good key management best practices should be followed, such as:
- Take frequent backups of the KMS
- Don't store the keys on the storage that the keys are protecting
It is always best to consult with the KMS provider to ensure everything is configured and setup according to their best practices.
No, SvSAN Data Encryption is a software only encryption solution and does not require any special encryption cards, RAID cards, FPGAs or ASICs.
However, as encryption can be quite CPU intensive, many of the modern CPUs now provide instructions to provide hardware acceleration instructions to significantly improve encryption performance, these are known as “Advanced Encryption Standard New Instruction” (AES-NI) operations. (https://en.wikipedia.org/wiki/AES_instruction_set)
SvSAN Data Encryption uses the OpenSSL library and the XTS-AES-265 cipher which in turn uses the AES-NI hardware acceleration instructions, if they are present and enabled in the CPU. The AES-NI hardware acceleration instructions may need to be enabled in the server BIOS.
Yes, it will be possible to encrypt an existing volume with data stored on it.
In the initial release of the SvSAN Data Encryption feature, the volume will need to be taken offline. However, online encryption of volumes is planned for a future release.
Yes. Changing the encryption keys will be possible. However, in the initial release of the SvSAN Data Encryption feature, this will have to be performed with the volume offline.
Online re-keying of volumes is on the roadmap and scheduled for a future release.
There are many variables that determine the impact on performance when using encryption, including:
- How “fast” is the the CPU?
- Does the CPU support AES-NI?
(Most modern processors support AES-NI and newer generations of CPUs have made performance improvements for these instructions over the previous generation, making them faster to perform encryption calculations.)
- How fast is the underlying disks?
- How much I/O and amount of data is being generated?
Therefore the answer about performance impact is: “it depends” - and will be specific to each customer environment.
Yes, deleting the cryptographic keys will instantly make the data on a volume inaccessible.