Many Linux distributions offer full disk encryption (LUKS), encryption of folders and files (eCryptFS), or even encryption using ZFS, a file system not native to Linux, as standard security tools. Which of the available methods makes sense to choose today? Let's try to figure it out.
Hash functions, or one-way cryptographic conversion functions, are used to convert a password to a binary key as part of a Key Derivation Function (KDF). LUKS supports the following options: SHA-1, SHA-256, SHA-512, RIPEMD160, and Whirlpool. I definitely do not recommend using SHA-1 and RIPEMD160. SHA-256 is the default choice, but SHA-512 and Whirlpool are just as good.
One of the interesting features of LUKS is the support for up to eight key slots. Each of the eight slots can be protected with its own unique password or key. On the one hand, it allows different users to unlock encrypted drives, each with their own password. On the other hand, to decrypt the data, it is enough to crack any password for any of the occupied slots. The LUKS header contains information about which of the key slots are occupied (that is, they contain valid keys for accessing data), and which are empty.
An important consequence of this mechanism: deleting the last available key makes data decryption impossible, which allows you to instantly (or very quickly) permanently block access to encrypted data.
However, LUKS has its drawbacks. On the one hand, disk or partition encryption perfectly protects data, while the speed of access to encrypted data differs little from the speed of access to an unencrypted array of information. On the other hand, encryption of really all data means that in order to carry out any operations with an encrypted disk, including checking the integrity of the file system, the entire disk must also be mounted. You cannot make a backup copy, create or restore a snapshot of an encrypted disk without entering the encryption key.
The problem of creating and restoring backups, including to untrusted remote computers, prompted developers to look for alternative methods of encryption. One of them is cryptographic (encryption) file systems.
A fairly wide selection of cryptographic file systems is available to users. Two of them can be distinguished: eCryptFS, which runs at the kernel level and does not use FUSE, and EncFS, which runs in user space through FUSE.
eCryptFS encrypts each file separately; encryption metadata for each file is stored in its header. Thus, both individual files and entire folders can be easily copied between computers. This allows you to organize a system of "blind" backup, when only those encrypted files that have been changed are copied or synchronized. At the same time, eCryptFS does not allow using the file system deduplication functions: each encrypted file uses a unique salt, as a result of which the contents of even initially identical files in encrypted form will differ (from a security point of view, this is correct).
eCryptFS is often used to encrypt users' home directories (in this case, the administrator can set up a blind backup), as well as in a number of network attached storage (NAS) products from Asustor, QNAP, Synology, TerraMaster and some others ...
eCryptFS supports several encryption algorithms including AES, Blowfish, DES3_EDE, Twofish, CAST6, and CAST5. As in other cases, it makes no sense to use an encryption algorithm other than AES: the reliability of AES is sufficient, and the speed of this cipher is much higher than the speed of alternatives due to hardware acceleration by the AES-NI instruction set ...
eCryptFS encrypts each file separately; optionally, the names of files and folders can also be encrypted (in this case, restrictions are imposed on the length of file names, which cannot exceed 143 ASCII characters).
Each file is encrypted with a randomly generated session key, which is encrypted (user key or password) stored in the metadata. The metadata themselves are written into the file header, which allows you to simply copy the encrypted file to another computer and decrypt it in a regular way.
This method of protection seems to allow you to bypass the restrictions imposed by LUKS: to create or restore a backup, you do not need an encryption key - encrypted files are copied and restored, each of which contains everything you need to decrypt them. Unfortunately, this is probably the only merit of eCryptFS and similar cryptographic file systems. The disadvantages include:
ZFS is more than just a file system. Using ZFS, you can create and manage multi-disk configurations without using mdadm and LVM, create and replicate snapshots, including on remote servers. Unsurprisingly, the ZFS developers have developed their own embedded system, which does not use dm-crypt, to protect data as well.
Perhaps the main point is that the built-in ZFS encryption is positioned as a modern replacement for traditional disk encryption tools like LUKS or the built-in FreeBSD GELI OS, and at the same time it has a number of advantages previously only available when using cryptographic file systems. ZFS encryption is tightly integrated with the file system functionality. Unlike LUKS, most if not all zfs and zpool commands can be executed on encrypted volumes without entering an encryption key, including data integrity verification operations, snapshots and their replication, data deduplication, and much more. For comparison: if the disk is encrypted using dm-crypt, then in order to perform such operations, you will first need to enter the encryption key.
Compared to file system-level encryption (eCryptFS), which also allows you to create and replicate encrypted snapshots and control the integrity of encrypted data without a key, ZFS encryption has several advantages. Here, there is a significantly higher encryption speed (especially noticeable on small files), and a higher level of security: data on the number and size of folders and files and the time of their modification are not leaked to the side. Of course, you can change the encryption key at any time (eCryptFS does not allow you to do this), and if necessary (for example, when selling a disk or sending it to a service), you can almost instantly destroy all data by simply overwriting the encryption metadata.
The developers argue that using the encryption built into ZFS can solve the following problems with traditional methods.
The developers mention another data type that is not protected on ZFS-encrypted volumes. These are deduplication tables that are created when a user enables data deduplication. Every block of data, duplicate or not, is still encrypted, but analysis of the deduplication tables can reveal which blocks are duplicated on disk. The value of this information to an attacker is questionable, so this moment cannot be considered a serious vulnerability. At the same time, when deduplication is enabled, the IV and salt generation algorithm changes (since identical data blocks must match after they are encrypted), so it is recommended to disable deduplication when storing critical data.
Another potential vulnerability - CRIME (Compression Ratio Info-leak Made Easy) can be implemented in a scenario where data is compressed before being encrypted.
# zfs create -o encryption=[algorithm] -o keylocation=[location] -o keyformat=[format] poolname/datasetname
If you create an encrypted boot partition and want it to be mounted automatically at boot, then the only available encryption option is using a binary key (a file whose path is specified in the file: /// path / to / keyfile format). The encryption key size is strictly 32 bytes; generate a random key with the command
# if=/dev/urandom bs=32 count=1 of=/path/to/keyfile
For other volumes, you can use either a binary key or a password. The password length can be from 8 to 512 characters.
# zfs create -o encryption=aes-256-gcm -o keyformat=passphrase poolname/ datasetname
It is important to note that ZFS (as well as other modern systems, including BitLocker) will not encrypt data directly with a key that is generated from a password or binary key. For the actual encryption, a master key is used, which, in turn, is protected with an encryption key (binary or a key obtained as a result of password conversion by N iterations of the PBKDF2 function).
Thus, the following ZFS encryption properties can be enumerated:
Disk or partition encryption protects the entire data array; the only leak that is possible in some cases is the ability to find out the amount of used and free space on an encrypted partition. At the same time, any operations with an encrypted disk or partition require that the entire amount of data be mounted; you will not be able to check the integrity of files or make a backup without entering the encryption key.
Cryptographic file systems like eCryptFS encrypt the contents of each file separately, which allows a number of operations on the file system to be performed without mounting encrypted folders. Commands for monitoring the integrity of the file system, defragmentation, creating and synchronizing snapshots are available. Files and folders can be transferred between systems, you can create and restore backups using, including remote computers, whose security is not sure. All this is available without entering encryption keys or decrypting data.
At the same time, common cryptographic file systems in Linux impose a number of functional restrictions, the main of which are severe restrictions on the length of file and folder names and relatively low operating speed, especially when encrypting small files. For encrypted folders, the deduplication features available on file systems such as BTRFS generally do not work. The security of the solution also suffers greatly: a compromised encryption key cannot be changed, and cracking a password from a single encrypted file will allow decryption of the rest of the encrypted folder. Without an encryption key, a significant amount of metadata is available: information about the folder structure, the number and size of files, the date of the last modification.
Introduced in OpenZFS in 2019, native ZFS encryption, running on Linux and FreeBSD, successfully addresses both types of security by offering a compromise between security, speed, and functionality. Without encryption keys, the functions of checking the integrity of the file system, snapshots and their synchronization, as well as data deduplication are available (if enabled, the deduplication tables will be stored in clear text, which is a security concession). At the same time, data on the size of files and folders, and the time of file modification are not leaked to the side; there are no restrictions on the length of file names inherent in cryptographic file systems. The encryption performance is high, comparable to that of traditional disk encryption systems.
Which encryption method should you choose? Whether you use ZFS or can use ZFS, the choice is clear: the built-in ZFS encryption will ensure high performance, sufficient security and convenience. If you are the only user and you cannot use ZFS for some reason, LUKS is still a fast and secure option. On multiuser systems without ZFS, it makes sense to enable file system encryption: in this case, the administrator will be able to create and restore backups without mounting each encrypted folder for each user on the system.
Finally, sometimes you just don't have an alternative: some NAS vendors only allow a single method. Synology - Encryption of network folders (eCryptFS). Asustor - encryption of network folders (eCryptFS) on internal volumes or encryption of a partition (LUKS) on MyArchive volumes. QNAP (on models with Intel processors and QTS operating system) allows you to create multilayered protection: SED, LUKS and eCryptFS can be used in any combination.
LUKS
LUKS (Linux Unified Key Setup), or to be precise, dm-crypt, is a classic, universal, high-performance, well-researched and free of discovered vulnerabilities disk encryption system. LUKS supports numerous encryption algorithms and modes of operation, as well as several hash functions. As an encryption algorithm, you can choose one of the many supported, in particular AES, Serpent, Twofish, CAST-128 and CAST-256, which can work in one of four modes: ECB, CBC-PLAIN64, CBC-ESSIV: hash or XTS- PLAIN64. The most common default is a combination of cbc-essiv: sha256 with AES encryption and a 256-bit key.INFO
During the creation of an encrypted disk or container, the user can specify any encryption algorithm. Nevertheless, the use of any encryption algorithm except AES is counterproductive: real security (as well as the speed of guessing a password during an attack) does not increase, but the speed of work suffers greatly due to the fact that AES is the only encryption algorithm that received hardware support in in the form of a set of instructions for the AES-NI processor.Hash functions, or one-way cryptographic conversion functions, are used to convert a password to a binary key as part of a Key Derivation Function (KDF). LUKS supports the following options: SHA-1, SHA-256, SHA-512, RIPEMD160, and Whirlpool. I definitely do not recommend using SHA-1 and RIPEMD160. SHA-256 is the default choice, but SHA-512 and Whirlpool are just as good.
One of the interesting features of LUKS is the support for up to eight key slots. Each of the eight slots can be protected with its own unique password or key. On the one hand, it allows different users to unlock encrypted drives, each with their own password. On the other hand, to decrypt the data, it is enough to crack any password for any of the occupied slots. The LUKS header contains information about which of the key slots are occupied (that is, they contain valid keys for accessing data), and which are empty.
An important consequence of this mechanism: deleting the last available key makes data decryption impossible, which allows you to instantly (or very quickly) permanently block access to encrypted data.
However, LUKS has its drawbacks. On the one hand, disk or partition encryption perfectly protects data, while the speed of access to encrypted data differs little from the speed of access to an unencrypted array of information. On the other hand, encryption of really all data means that in order to carry out any operations with an encrypted disk, including checking the integrity of the file system, the entire disk must also be mounted. You cannot make a backup copy, create or restore a snapshot of an encrypted disk without entering the encryption key.
The problem of creating and restoring backups, including to untrusted remote computers, prompted developers to look for alternative methods of encryption. One of them is cryptographic (encryption) file systems.
CRYPTOGRAPHIC FILE SYSTEMS
In addition to encrypting entire disks, in Linux you can also use encryption at the folder level (cryptographic filesystems). This encryption can be enabled on both regular and encrypted drives. In ready-made network storages, the first option is most often used, but in some cases (for example, in some QNAP models), you can also use the second.A fairly wide selection of cryptographic file systems is available to users. Two of them can be distinguished: eCryptFS, which runs at the kernel level and does not use FUSE, and EncFS, which runs in user space through FUSE.
eCryptFS encrypts each file separately; encryption metadata for each file is stored in its header. Thus, both individual files and entire folders can be easily copied between computers. This allows you to organize a system of "blind" backup, when only those encrypted files that have been changed are copied or synchronized. At the same time, eCryptFS does not allow using the file system deduplication functions: each encrypted file uses a unique salt, as a result of which the contents of even initially identical files in encrypted form will differ (from a security point of view, this is correct).
eCryptFS is often used to encrypt users' home directories (in this case, the administrator can set up a blind backup), as well as in a number of network attached storage (NAS) products from Asustor, QNAP, Synology, TerraMaster and some others ...
WARNING
The most popular eCryptFS alternative is the EncFS encryption file system. Unlike the previous eCryptFS, EncFS runs in user space without any additional privileges through the FUSE framework. Unfortunately, not so long ago a serious vulnerability was found in it, which makes it unsafe to exploit.eCryptFS supports several encryption algorithms including AES, Blowfish, DES3_EDE, Twofish, CAST6, and CAST5. As in other cases, it makes no sense to use an encryption algorithm other than AES: the reliability of AES is sufficient, and the speed of this cipher is much higher than the speed of alternatives due to hardware acceleration by the AES-NI instruction set ...
eCryptFS encrypts each file separately; optionally, the names of files and folders can also be encrypted (in this case, restrictions are imposed on the length of file names, which cannot exceed 143 ASCII characters).
Each file is encrypted with a randomly generated session key, which is encrypted (user key or password) stored in the metadata. The metadata themselves are written into the file header, which allows you to simply copy the encrypted file to another computer and decrypt it in a regular way.
This method of protection seems to allow you to bypass the restrictions imposed by LUKS: to create or restore a backup, you do not need an encryption key - encrypted files are copied and restored, each of which contains everything you need to decrypt them. Unfortunately, this is probably the only merit of eCryptFS and similar cryptographic file systems. The disadvantages include:
- Low performance. A header is added to each encrypted file that contains the encryption metadata. The speed of access to small files suffers especially strongly.
- Low level of security. Data on the number of files in directories, the size and modification date of each file are leaking outside.
- When encrypting folders in network attached storage, there is no way to change the encryption password. A compromised password means that the data must be completely re-encrypted.
- Functional limitations. When encrypting file and folder names, the file name cannot exceed 143 ASCII characters. Depending on some parameters, there may be other restrictions (for example, it is impossible to use network folders with NFS).
- Some functions of the file system do not work. In particular, the deduplication mechanism does not work in encrypted folders.
ZFS
The ZFS file system, with its roots in Solaris, has long been available to Linux and FreeBSD users. Some distributions include OpenZFS 2.0 as a standard package, in others it can be installed separately. Most distributions boot without problems from ZFS partitions.ZFS is more than just a file system. Using ZFS, you can create and manage multi-disk configurations without using mdadm and LVM, create and replicate snapshots, including on remote servers. Unsurprisingly, the ZFS developers have developed their own embedded system, which does not use dm-crypt, to protect data as well.
INFO
What's interesting about ZFS encryption?Perhaps the main point is that the built-in ZFS encryption is positioned as a modern replacement for traditional disk encryption tools like LUKS or the built-in FreeBSD GELI OS, and at the same time it has a number of advantages previously only available when using cryptographic file systems. ZFS encryption is tightly integrated with the file system functionality. Unlike LUKS, most if not all zfs and zpool commands can be executed on encrypted volumes without entering an encryption key, including data integrity verification operations, snapshots and their replication, data deduplication, and much more. For comparison: if the disk is encrypted using dm-crypt, then in order to perform such operations, you will first need to enter the encryption key.
Compared to file system-level encryption (eCryptFS), which also allows you to create and replicate encrypted snapshots and control the integrity of encrypted data without a key, ZFS encryption has several advantages. Here, there is a significantly higher encryption speed (especially noticeable on small files), and a higher level of security: data on the number and size of folders and files and the time of their modification are not leaked to the side. Of course, you can change the encryption key at any time (eCryptFS does not allow you to do this), and if necessary (for example, when selling a disk or sending it to a service), you can almost instantly destroy all data by simply overwriting the encryption metadata.
The developers argue that using the encryption built into ZFS can solve the following problems with traditional methods.
Encryption folder problems (ecryptfs)
- If the data is encrypted before being compressed, it becomes incompressible.
- Deduplication does not work.
- Encryption metadata is written in the header of each file (the amount of data stored increases, especially if many small files are stored).
Full disk encryption (dm-crypt)
- Multiple encryption of duplicate data.
- You cannot perform any operations with an encrypted disk if the encryption key is not loaded.
- Backups, snapshots, replication are impossible without encryption keys.
The developers mention another data type that is not protected on ZFS-encrypted volumes. These are deduplication tables that are created when a user enables data deduplication. Every block of data, duplicate or not, is still encrypted, but analysis of the deduplication tables can reveal which blocks are duplicated on disk. The value of this information to an attacker is questionable, so this moment cannot be considered a serious vulnerability. At the same time, when deduplication is enabled, the IV and salt generation algorithm changes (since identical data blocks must match after they are encrypted), so it is recommended to disable deduplication when storing critical data.
Another potential vulnerability - CRIME (Compression Ratio Info-leak Made Easy) can be implemented in a scenario where data is compressed before being encrypted.
HOW ENCRYPTION WORKS IN ZFS
AES-256 cipher in GCM mode is used as an encryption algorithm; Optionally, you can select AES with a key length of 128, 192 or 256 bits in CCM or GCM modes. Information about which cipher is selected is stored in the encryption metadata. The encryption key is protected with a key generated by an arbitrary number of iterations of the PBKDF2 function. By default, 350,000 iterations are used, the minimum value is 100,000. The following command is used to create an encrypted pool:# zfs create -o encryption=[algorithm] -o keylocation=[location] -o keyformat=[format] poolname/datasetname
If you create an encrypted boot partition and want it to be mounted automatically at boot, then the only available encryption option is using a binary key (a file whose path is specified in the file: /// path / to / keyfile format). The encryption key size is strictly 32 bytes; generate a random key with the command
# if=/dev/urandom bs=32 count=1 of=/path/to/keyfile
For other volumes, you can use either a binary key or a password. The password length can be from 8 to 512 characters.
# zfs create -o encryption=aes-256-gcm -o keyformat=passphrase poolname/ datasetname
It is important to note that ZFS (as well as other modern systems, including BitLocker) will not encrypt data directly with a key that is generated from a password or binary key. For the actual encryption, a master key is used, which, in turn, is protected with an encryption key (binary or a key obtained as a result of password conversion by N iterations of the PBKDF2 function).
Thus, the following ZFS encryption properties can be enumerated:
- The speed is comparable to the speed of disk encryption systems and does not depend on the size of the files.
- Security can be increased by specifying an increased number of hash iterations in the password translation function.
- The amount and severity of data "leaking" from the encrypted pool is relatively small if you do not use the deduplication function.
- Data deduplication is supported, but has a negative impact on security.
- The functions of "cold" backup by means of snapshots and their replication are supported. No encryption key is required.
- You can protect both entire disks and individual data sets.
SUMMING UP
Just a couple of years ago, the choice of encryption tools for Linux was limited to two types: encrypting an entire disk or partition (as an option, a container), or encrypting files and folders using eCryptFS or analogs working through FUSE (for example , EncFS or gocryptfs). Both types of encryption have their own advantages and disadvantages.Disk or partition encryption protects the entire data array; the only leak that is possible in some cases is the ability to find out the amount of used and free space on an encrypted partition. At the same time, any operations with an encrypted disk or partition require that the entire amount of data be mounted; you will not be able to check the integrity of files or make a backup without entering the encryption key.
Cryptographic file systems like eCryptFS encrypt the contents of each file separately, which allows a number of operations on the file system to be performed without mounting encrypted folders. Commands for monitoring the integrity of the file system, defragmentation, creating and synchronizing snapshots are available. Files and folders can be transferred between systems, you can create and restore backups using, including remote computers, whose security is not sure. All this is available without entering encryption keys or decrypting data.
At the same time, common cryptographic file systems in Linux impose a number of functional restrictions, the main of which are severe restrictions on the length of file and folder names and relatively low operating speed, especially when encrypting small files. For encrypted folders, the deduplication features available on file systems such as BTRFS generally do not work. The security of the solution also suffers greatly: a compromised encryption key cannot be changed, and cracking a password from a single encrypted file will allow decryption of the rest of the encrypted folder. Without an encryption key, a significant amount of metadata is available: information about the folder structure, the number and size of files, the date of the last modification.
Introduced in OpenZFS in 2019, native ZFS encryption, running on Linux and FreeBSD, successfully addresses both types of security by offering a compromise between security, speed, and functionality. Without encryption keys, the functions of checking the integrity of the file system, snapshots and their synchronization, as well as data deduplication are available (if enabled, the deduplication tables will be stored in clear text, which is a security concession). At the same time, data on the size of files and folders, and the time of file modification are not leaked to the side; there are no restrictions on the length of file names inherent in cryptographic file systems. The encryption performance is high, comparable to that of traditional disk encryption systems.
Which encryption method should you choose? Whether you use ZFS or can use ZFS, the choice is clear: the built-in ZFS encryption will ensure high performance, sufficient security and convenience. If you are the only user and you cannot use ZFS for some reason, LUKS is still a fast and secure option. On multiuser systems without ZFS, it makes sense to enable file system encryption: in this case, the administrator will be able to create and restore backups without mounting each encrypted folder for each user on the system.
Finally, sometimes you just don't have an alternative: some NAS vendors only allow a single method. Synology - Encryption of network folders (eCryptFS). Asustor - encryption of network folders (eCryptFS) on internal volumes or encryption of a partition (LUKS) on MyArchive volumes. QNAP (on models with Intel processors and QTS operating system) allows you to create multilayered protection: SED, LUKS and eCryptFS can be used in any combination.