Encryption at rest is crucial for safeguarding data from unauthorized access, ensuring it remains unreadable without the appropriate decryption key, even if a storage device is lost, stolen, or improperly disposed of. Self-encrypting drives (SEDs) provide a hardware-based solution by embedding encryption technology directly into the drive. This approach encrypts data automatically as it is written and decrypts it as it is read, with minimal performance impact. SEDs also support secure, instant data erasure by deleting the encryption key. However, SEDs have limitations, including restricted support across drives, vendors, and capacities, which can complicate procurement and increase lead times. Additionally, managing encryption keys for SEDs introduces operational complexity. Moreover, SEDs are counterintuitive to software-defined storage (SDS) concepts, as they rely on hardware-based encryption, which can conflict with the flexibility SDS offers.
Software-based encryption at rest, such as solutions using dm-crypt or LUKS on Linux, removes these hardware dependencies, offering compatibility across a wide range of devices and storage configurations. These approaches enable organizations to implement encryption without relying on specific hardware vendors or models. However, dm-crypt and LUKS can introduce performance bottlenecks, particularly for systems with high I/O workloads, as encryption and decryption processes rely heavily on CPU resources. Organizations must carefully evaluate these trade-offs to select the most suitable encryption solution for their specific needs.
Comparing Encryption Approaches: Per-Drive vs. Per-Volume
Encryption at the disk level can be implemented in either hardware, using Self-Encrypting Drives (SEDs), or software. This method uses a single encryption key for the entire disk, meaning all data on that disk is encrypted and decrypted using the same key. This approach offers a straightforward solution for securing data, as it automatically protects everything stored on the disk. In contrast, encryption per-volume allows each volume to have its own encryption key, providing greater flexibility and control over data protection.
In a distributed system, where data can be replicated across different servers or striped across multiple disks, encryption per-volume is more efficient. Since data is encrypted only once at the volume level, it can be replicated or transferred without requiring re-encryption. Additionally, if a drive fails and its data needs to be rebuilt across multiple drives, the encrypted data can be read and written as-is, without the need for decryption and re-encryption. This approach improves performance and reduces complexity in such scenarios.
Per-volume encryption allows for more tailored security and greater efficiency in distributed systems. Furthermore, when a volume is deleted, the corresponding encryption key can be erased, ensuring that the data cannot be recovered—acting like a secure erase. In contrast, with per-disk encryption, you cannot simply drop the key, as the disk may hold data from multiple volumes, including those that were not deleted.
Lightbits Software-Based Encryption
Lightbits software encryption, available since version 3.12, provides granular data security by allowing each volume to be encrypted with a unique key. This feature maintains optimal performance, comparable to Lightbits without encryption or when using SEDs, as demonstrated in Lightbits’ performance lab and customer deployments. For enhanced security, Lightbits offers optional TPM protection for encryption keys.
How Does It Work?
Lightbits uses a well-known technique called envelope encryption, which provides multiple layers of security:
- Data Encryption Keys (DEKs): Each volume in your cluster is encrypted with its own unique DEK.
- Key Encryption Key (KEK): A KEK is used to encrypt all the individual DEKs.
This two-tiered approach offers several advantages:
- Reduced attack surface
- Ability to rotate the KEK frequently without re-encrypting all data
- Granular and distributed control over encryption at the volume level
The primary server receiving write operations from clients first compresses the data (if compression is enabled for the volume), encrypts it using the Data Encryption Key (DEK) associated with the volume, replicates the already encrypted data to secondary servers based on the volume’s replication factor, and stores the encrypted data locally on NVMe devices.
The secondary servers, receiving the already compressed and encrypted data, simply store it on their NVMe storage devices without any additional decryption or encryption processing.
If a server fails, either transiently or permanently, Lightbits can create new replicas within the cluster. Thanks to per-volume encryption, the encrypted data can be read, transmitted over the network, and written to a new location without requiring any additional decryption or re-encryption operations.
In the event of an NVMe device failure, Lightbits’ Elastic RAID mechanism reconstructs the lost data as encrypted data and writes it back to the drives. This process occurs without performing additional decryption and encryption steps, ensuring efficient and secure handling of failures.
Key Features
- AES-XTS-256 Cipher: Lightbits uses the robust AES-XTS encryption algorithm to secure your data.
- Flexible and Secure KEK Storage: Choose between encrypted file-based KEK storage or hardware-based Trusted Platform Module (TPM) 2.0 for added security.
- Key Export: Securely export your KEK for offline storage in a key vault or Hardware Security Module (HSM).
Getting Started
Enabling Cluster-Level Encryption is a straightforward process using Lightbits CLI:
Look for the encryption status in the output to confirm that it’s enabled.
Exporting the KEK
To safeguard the KEK, it is advisable to create a backup and store it offline, separate from the cluster. The getClusterRootKey API can be utilized to export the KEK, which can then be safely stored in a key vault or HSM.
In order to keep the KEK secure, you will be required to create a RSA4096 or RSA3072 private/public key pair and submit the public key in the API. The cluster will encrypt the KEK with the given public key, and you can then decrypt it, if needed, with your private key.
Note that RSA-OAEP is used for better security and to validate the HASH of the script. If you need to decrypt the KEK, use RSA OAEP with your private key to decrypt it.
Lightbits Performance with Software Encryption @ Rest
As shown in the graphs below, the performance difference between encryption enabled and encryption disabled is minimal. The graphs present normalized results, where 100% represents the performance with encryption disabled. They include measurements for both 4KB and 128KB random block sizes across various read and write mix ratios.
Conclusion
Software Encryption at rest represents a significant step forward in data security for Lightbits users. By implementing this feature, you can ensure that your data remains secure, even against physical access attempts, without compromising performance or requiring SED drives.
Stay tuned for more updates as we continue to enhance our security offerings. If you have any questions about enabling software-based encryption for Lightbits clusters, please refer to our documentation or reach out via email or slack channel.