In practice, as we are dealing with company data, our own or even more so entrusted, it is always a good idea to keep it on encrypted disks. This makes several things easier, such as the fact that the data on the disks leaving our servers becomes worthless. Contrary to what you might think, we don't always replace completely inoperable disks. Sometimes we want to widen the pool sometimes drives start reporting errors and we replace them before the actual final damage. Admittedly, in a fit of healthy paranoia anyway, it's a good idea to play with a psycho-dyer or perform a deep clean by overwriting the entire disk with zeros, for example.

Keep in mind that, especially when replacing a damaged disk, the data stored on the platters in the case of platter drives, or on the chips in the case of "flash" memory, using unintelligible carbon paper from the English language, will remain on them and there may not be much way to erase them.

Additionally, I have a strong feeling that you have or should have in your RODO documents that you encrypt your drives.

How does it work?

In practice, disk encryption in ZFS is trivial because you just need to enable it when creating a pool. Immediately note as far as I know there is no possibility to encrypt the created pool. This is worth keeping in mind when planning our NAS. Admittedly, in principle nothing is lost because ZFS works hierarchically from the perspective of disk resources.

Hierarchicality of ZFS

I'm already in a hurry to explain. In ZFS we mount our pool somewhere in the file system in the case of TrueNAS it is the /mnt directory. The pool itself can be encrypted or not. Now every new Zvol or Dataset we add is mounted inside our pool, which means that if we add a dataset called "Data" it will have the address " /mnt/pool-name/Data" and by default it will inherit all the properties of the pool itself, and this will apply both to encryption and encryption parameters, but also other parameters which I won't talk about today, such as de-duplication, compression and a few others.

Flexibility of ZFS Hierarchy

The default parameters, however, can be safely changed when creating a Dataset or Zvol. I emphasize that here, too, if you create a resource with encryption enabled, it is impossible to turn it off, and vice versa an encrypted resource cannot be decrypted. The only option is to delete and create the resource again. But this is still more flexible than creating the entire pool from scratch to encrypt it. Quite clearly, even if we create an unencrypted pool it will be easy to create encrypted Datasets in it.

Always an unencrypted resource can contain an encrypted one. Remember, however, that this only works one way. If we have an encrypted pool or resource then we will not create an unencrypted resource in it. So it's a bit of a one-way street.

Interestingly By building our dataset hierarchically we can have different encryption in each Dataset. This gives a very interesting situation in which we can encrypt one Dataset differently and not have access to its contents at all. What can this be useful for? This is actually very useful. Imagine a situation where you have several instances of TrueNAS at different locations or branches or even at several clients. Well, and one TrueNAS instance to which all this is replicated. I talk more about replication in the material TrueNAS – replikacja – coś więcej niż backup. Each instance has encrypted data, each differently. Replication makes us replicate the data to the other server ,even or especially encrypted data. Not at all by providing the keys to that data.

From the perspective of this central TrueNAS instance, we are a backup host for many other TrueNAS. As a result, we have many Datasets replicated from other TrueNAS in our pool each one is encrypted and it is encrypted with different keys. What's more, we never need to know that key. See how good this solution is. We have a central backup that doesn't even need to know what it stores.

ZFS encryption methods

Well encryption, keys, passwords, but what passwords, what keys well and where are they? Let's start with the fact that we can encrypt our asset in two ways. With a password and with a key.

Key encryption

Key encryption, in addition to another form of storage, differs functionally in that the keys are stored in the configuration of our TrueNAS. Consequently, our resources are always available to us from within our TrueNAS. This is a good solution, but it has the disadvantage that if someone steals the whole server, he will de facto also have the keys. Of course, the keys are not stored anywhere in their pure form, but once the server starts up, the keys are in RAM so that you can decrypt the data on the fly. Once entered, the key is stored in the conjuction and remains there. We have no simple way to lock a resource once unlocked with a key.

ZFS password encryption

The second way to secure data is through a password. To unlock access to the resource we must manually enter the password every time we start. This is certainly more secure, but every reboot will force us to manually log into the server and enter the password to make the resource accessible. For this reason, it is not possible in TrueNAS to encrypt the pool with a password, but only with a key.

Password encryption is definitely a more uncompromising solution than key encryption. A password-encrypted resource can be locked and unlocked at any time about unlike a key-encrypted resource.

ZFS encryption - what can we change?

During the life of a Dataset or Zvol resource, we can change the type of encryption from key to password and vice versa, we can change both the password and the keys. However, we cannot change either the fact of encryption, i.e. decrypt or encrypt, and we cannot change the encryption algorithm. That is, once we choose encryption such as AES-256-GCM at the time of setting up a given resource, it will remain so.

ZFS encryption requirements

As for the requirements. We must remember that the process of encryption and decryption loads the processor and takes place every time we write or read data. Very helpful and even necessary in the case of data encryption is a set of AES-NI processor routines. And if our processor has such a set of procedures, the CPU overhead for encryption should not be significant, but enabling encryption on a processor without a set of these procedures will cause significant performance degradation. So rather not recommended.

All new server processors are more likely to have AES-NI. Older processors or those not designed for servers will not always have this set of routines anymore. You can check this on the processor manufacturer's website or simply by typing the command in the console.

dmesg | grep -i aes

or

cpuid | grep -i aes

Summary

An important note at the end. I say this a little bit on principle but also to avoid questions like "I didn't write down the encryption key or password, what should I do?". The answer is quite simple "NOTHING". For this, if you decide to encrypt always put the keys or password in the hashtag. Well, and so that this our hashtag is not sometimes on our encrypted resource. Does this seem obvious to you? Oh you can be cut.

If you would like to learn more about TrueNAS write to us. We will tell you how it works and why it is worth it?