Linux Unified Key Setup (LUKS) is a specification for disk encryption across Linux distributions. It relies on dm-crypt, a kernel module that uses the passphrase selected by the user to encrypt and decrypt data on-the-fly on a LUKS volume, and make the filesystem mountable from a virtual device-mapper block device. The cryptsetup utility is used to create and manage LUKS volumes.
Compared to application level encryption such as NextCloud server side encryption, full disk encryption with LUKS results in a lower performance overhead, and more comprehensive data protection – including metadata. LUKS can also be used in conjunction with application level encryption – since once a LUKS volume is opened and mounted, the LUKS encryption is transparent to the application. In other words, once a LUKS volume is decrypted, it is no different than an ordinary, unencrypted volume.
Application level encryption is often implemented in a way where the keys are stored on disk, making it less secure than using LUKS, where the key resides in-memory only while the system is in operation. There is a clear tradeoff between convenience and security. If the key is stored on the disk in a key file referenced in /etc/crypttab, it is more vulnerable to being found by an attacker, especially if they manage to escalate to root privileges, or gain physical access to the disks. The drawback of course, with not storing the key anywhere on disk, means that you must provide the passphrase following every reboot.
If the boot volume is encrypted with LUKS, the LUKS passphrase must be given at a terminal before the system can continue with the boot process. In the case of servers with only SSH access, a lightweight SSH server called dropbear may be loaded into initramfs to faciliate the entering of the passphrase to unlock the LUKS volume.
Despite being called full disk encryption, it isn’t always necessary (or even desirable) to encrypt the boot volume. With detailed planning and configuration, application data can be written only to certain directories which are mounted to a LUKS encrypted volume. It can be a perfectly rational choice to only encrypt data directories such as /var/lib/mysql/ or /var/lib/docker/, along with log directories such as /var/log/mysql/ and /var/log/docker/, and swap partitions, which might reveal sensitve data. With this approach, the LUKS open and mounting of the /dev/mapper/… device can happen after boot, before the relevant services such as a database or Docker daemon are manually started by an operator.
Encrypting the boot disk for cloud servers is not always straightforward, because cloud providers rely on standardized machine images, without an encrypted boot disk, to provision new instances. It can sometimes be accomplished by uploading a custom image, or by using customer-supplied keys with a cloud-hosted key management service, although the process varies from cloud provider to cloud provider.
Full disk encryption is more precisely known as encryption at-rest, because the data is only decrypted on demand. As soon as the server loses its power source, it will prompt for the passphrase at the next startup. If an adversary steals the hard drives then plugs them into a different system, they will only see gibberish on the LUKS encrypted volumes, since they would not possess the passphrase to decrypt them.
The most straightforward way to set up a LUKS on a cloud-based system, is by attaching a new block storage volume, creating a LUKS device with it using cryptsetup, formatting the LUKS device with the desired filesystem such as xfs or ext4, then finally mounting the mapper device to a mountpoint.
If your cloud server comes with a significant amount of local storage, you might want to leverage the capacity of the root volume to set up a LUKS device using a loop device – especially if the local storage is more performant than the block storage service at your cloud provider. A loop device is an .img file on your disk that is enumerated as a block device. cryptsetup can create a LUKS device within a loop device, and the rest of the steps to format the LUKS device remain the same as with a physical block storage device.
Data encryption is a technical measure favoured by the EU GDPR for the protection of data subjects’ personal data, and encryption at-rest is required for compliance with protecting personally identifiable information (PII) under PCI-DSS, and personal health information (PHI) under HIPAA. Many organizations are now well aware than data should be protected in transit over public networks with SSL/TLS, but encryption at-rest is an equally important consideration to reduce the likelihood of data breaches. Disk encryption with LUKS can form an essential element of “defense in depth” to strengthen your security posture. Contact our team to learn how operating system level encryption can work with any application to improve the privacy and security of your data in the cloud.