Established NAS manufacturers often offer some kind of encryption to their users. While anyone can use “military-grade AES-256 encryption”, the implementation details vary greatly. Synology, Asustor, and TerraMaster implement folder-based encryption, while QNAP, Thecus, and Asustor (MyAcrhive) employ full-disk encryption; the full comparison is available here. In this article, we’ll have a look at encryption methods used in TrueNAS, a system commonly used by computer enthusiasts for building custom NAS servers.

What is TrueNAS?

TrueNAS is an integrated open-source software that, once installed on a computer, turns it into a Network Attached Storage device. TrueNAS is based on FreeNAS that was initially released in 2005 by Olivier Cochard-Labbé. The project was soon acquired by iXSystems, a commercial company that continued developing the project. iXSystems split the project into two branches: the free, open-source FreeNAS for the enthusiasts and the commercial but still open-source TrueNAS marketed to enterprise customers. This year, the two branches were merged into a single product (TrueNAS), which was split again into FreeBSD-based TrueNAS Core and Debian Linux-based TrueNAS Scale.

Today, there is only one product (TrueNAS) in two branches:

• TrueNAS Core (based on FreeBSD)
• TrueNAS Scale (based on Debian Linux, currently in beta)

TrueNAS Branches: FreeBSD and Debian Linux

The two branches share a lot of the codebase, but are based on two different operating systems. From the forensic point of view, a major difference between the two branches is in the types of encryption supported.

• FreeNAS and TrueNAS (legacy versions): FreeBSD; GELI (supported)
• TrueNAS Core (FreeBSD): GELI (deprecated) and native ZFS encryption
• TrueNAS Scale (Debian Linux): native ZFS encryption only

As you may notice, TrueNAS Core can still access disks protected with GELI, but GELI is no longer officially supported: this type of encryption is deprecated, and users cannot encrypt newly created volumes with GELI. Users can migrate their encrypted data to use native ZFS encryption instead; however, even that is only supported in TrueNAS Core and not in TrueNAS Scale for reasons outlined below.

What you should know about TrueNAS

TrueNAS is a complex project with loads of features. If, however, your goal is decrypting the data, you must be aware of the following pecularities:

1. TrueNAS is always installed onto a dedicated storage device (hard drive, SSD drive, NVME or USB storage device). The boot device cannot be used to create storage pools. The boot device cannot be encrypted (unless the user activates device-level encryption, which is not a supported scenario). This allows for two things: one can safely move the datasets to a different TrueNAS installation, and one can attempt to extract the stored encryption keys from the boot device.
2. The data can be encrypted with a password or binary encryption key.
3. If a binary encryption key is used, TrueNAS can store the key on the boot device to facilitate automatic unlocks of encrypted datasets. If this is the case, these keys can be extracted from the boot device and used to unlock the encrypted datasets.
4. Native ZFS encryption is not full-disk encryption. Certain ZFS structures remain available without the encryption key for scrubs (integrity checks), snapshotting, replication, deduplication and other tasks accessible via zpool and zfs commands. In particular, one can extract information about the size of the file system; however, the number and sizes of individual files (let alone their content) are inaccessible without the encryption key. In comparison, folder-based eCryptFS encryption employed in Synology, Asustor and TerraMaster appliances exposes information about the file count and file sizes even without the encryption key.
5. The user can pick the encryption algorithm (AES-256-GCM by default) and the number of pbkdf2 iterations if they use passphrase-based encryption (350,000 by default). This choice is saved in encryption metadata; there is no need to guess the number of iterations when launching a brute-force attack.

TrueNAS encryption methods

TrueNAS distributions support several different encryption methods.

SED (Self Encrypting Drive) for SED-capable disks. The feature has a detailed description, which makes its intended function clear: in TrueNAS, SED encryption is designed specifically to protect data at rest. SED makes all ZFS features unavailable until the encrypted drive is unlocked, which, combined with the hardware requirements, makes this a niche solution for enthusiasts. At the same time, SED is commonly used in enterprise environments as the first layer of protection.

A SED-protected disk locked by TrueNAS is no different to a SED-protected disk locked by any other system.

GELI is a legacy encryption method that was used in TrueNAS and FreeNAS systems prior to TrueNAS 12. GELI is a block device-layer full-disk encryption system written specifically for FreeBSD. Since TrueNAS 12, GELI is no longer supported; however, users can still mount existing volumes and migrate them to ZFS native encryption. The migration process is lengthy and intrusive, so some existing users preferred not to migrate. These users may still have GELI-encrypted volumes in their TrueNAS systems.

If you encounter a GELI-encrypted disk, you may be able to mount it through one of the following paths:

1. Accessing encrypted disk(s) through a computer running a new FreeNAS/TrueNAS Core install. The version of TrueNAS should be the same or newer as the original user’s version to avoid conflicts with ZFS metadata version mismatch.
2. Accessing encrypted disk(s) via FreeBSD according to the documentation.

ZFS native encryption appeared in OpenZFS, which is now used in both TrueNAS branches. While ZFS native encryption protects the entire dataset, it is not considered a full-disk encryption. Some ZFS metadata such as the size of the file system (but not the number or sizes of individual files and folders) is exposed even without an encryption key, along with deduplication tables. On the other hand, users can scrab encrypted datasets, perform maintenance operations, create and replicate snapshots and basically do everything that zfs and zpool commands can do. Unlike folder-based encryption methods such as eCryptFS (used in Synology, Asustor and TerraMaster devices), ZFS native encryption allows changing the password without re-encrypting the dataset. Ars Technica published a very nice Quick-start guide to OpenZFS native encryption that is well worth reading.

When creating an encrypted dataset, the user can specify the encryption algorithm (the default is AES-256-GCM) and, in the case of passcode-based encryption, the number of pbkdf2 iterations (the default is 350,000).

Information about the encryption algorithm and the number of iterations is stored in the encryption metadata; you won’t have to guess it when setting up an attack.

The data can be encrypted with a passphrase (text password) or key. If a key is used, it can be stored on the TrueNAS boot device to facilitate automatic unlock of encrypted datasets.

TrueNAS supports inherited encryption settings, enabling inherited or different encryption settings for child data sets.

Importantly, ZFS native encryption is supported in both TrueNAS Core (FreeBSD based) and TrueNAS Scale (Debian Linux based), while GELI is only supported in FreeBSD-based FreeNAS and TrueNAS Core.

By design, ZFS encryption has several weaknesses that leak certain type of information about encrypted datasets. The first piece of information is the name and size of the file system, as well as other information available through the use of the zfs and zpool commands. I want to say it again: unlike eCryptFS, ZFS native encryption does not leak the number and size of encrypted files and folders.

ZFS encryption does not protect deduplication tables, which leaks the addresses of duplicate blocks on the disk (but not the content of individual data blocks). Finally, I will mention the CRIME (Compression Ratio Info-leak Made Easy), which is a theoretical vulnerability describing certain scenarios in which the data is compressed before encryption.

Additional information on ZFS native encryption is available at the following links:

• TrueNAS Core: Storage Encryption | (truenas.com)
• TrueNAS Scale: Encryption | (truenas.com)

How native ZFS encryption compares to other encryption methods

In my review of encryption methods used in commercial NAS appliances I was unpleasantly surprised. Folder-based encryption via eCryptFS, which is a fused encrypting file system, lacks in so many respects that its choice can raise questions. Folder-based encryption is slow, especially on smaller files. It leaks too much information about encrypted data (including the size and number of files in the folders), which enables profiling attacks on encrypted folders. The fact that you cannot (literally!) change the encryption password is just icing on the cake.

Some manufacturers prefer using full-disk encryption (LUKS) instead of or in addition to folder-based encryption. While LUKS is faster, more secure and more convenient compared to eCryptFS (hey, you can change that leaked password!), it does limit functionality: you cannot snapshot LUKS-encrypted volumes without unlocking them first; you can’t do multi-user; you cannot back up or restore encrypted data without providing the encryption key; you cannot scrub the data or perform file system maintenance without providing the encryption key. The many “can’t” are easily possible with eCryptFS, the very encryption option I criticized just one paragraph earlier.

ZFS native encryption addresses all the points of critique mentioned above. Access speed? It’s plenty fast. Changing a leaked password without re-encrypting the dataset? Easily possible. Scrubs and maintenance operations? You’ve got it. Snapshots of locked data sets? Yep. Replication without an encryption key? Doable. Add to that the ability to customize encryption and attack resistance (via a custom number of hash iterations), and you have a nicely balanced encryption scheme.

Does ZFS native encryption have drawbacks? I listed all known weaknesses, most of which are design decisions made to strike the right balance between security, convenience, and functionality. In my opinion, ZFS native encryption is currently the most well-rounded encryption method available for NAS appliances. While it leaks more information about encrypted data compared to LUKS, it’s infinitely more convenient than the former. Compared to folder-based encryption, it’s several generations ahead.

Conclusion

We have not discovered (nor looked for) any major vulnerabilities in the encryption methods supported by TrueNAS. The new ZFS native encryption standard does, but design, leak certain types of data. This is a well-documented phenomenon that is a result of a tradeoff between convenience and security. In our view, the new ZFS native encryption method strikes the right balance between features, convenience, and security, with none of the drawbacks of full-disk encryption and encrypting file systems and most of their benefits.