Encryption state of the art

[Pestaninha]

Hi,
I've been using full disk encryption for a long time, since 2009 IIRC... When I first started out with FreeNAS, that is one feature I turned on right out of the bat and I've had my sweats with it over the years but, ultimately, no regrets.
Right now, I'm in a bind. I've upgraded to TrueNAS and lost the ability to create GELI encrypted drives. I'm also unable (at least so far) to move my GELI encrypted data into an encrypted ZFS pool (tried several methods and read up on a lot of winnielinnie's posts (kudos for those, hope to be able to buy you a beer someday!)). To make matters worse, I don't really want to move my data to ZFS encrypted pools as they don't offer full disk encryption. I also have a failsafe plan, with encryption keys and recovery keys which don't seem to work on this new method of encryption.
Is this going to be the only encryption that TrueNAS will offer to the users, making those of us that really want to use full disk encryption to be forced to purchase the more expensive self encrypting drives? Is there any deprecation notice on GELI (I couldn't find one) that forced the hand on this change? Are there any plans to fully discontinue the support for GELI in TrueNAS? Are there any plans to support some other suite of full disk encryption in the future, such as LUKS?
At this point, I'm considering using GELI for the foreseeable future, but I'm not sure if I'm not delaying my problem just for a couple of months more :D

 

[Samuel Tai]

Storage Encryption

Describes how to encrypt a storage pool in TrueNAS CORE.

www.truenas.com

GELI is deprecated, due to its fragility and UI gotchas that resulted in data loss for too many TruNAS/FreeNAS users.

SEDs are the only way forward for full-disk encryption.

 

[Samuel Tai]

As for removing GELI encryption from a pool, see https://www.truenas.com/community/t...om-a-zfs-volume-while-keeping-the-data.16467/

 

[Pestaninha]

Storage Encryption

Describes how to encrypt a storage pool in TrueNAS CORE.

www.truenas.com

GELI is deprecated, due to its fragility and UI gotchas that resulted in data loss for too many TruNAS/FreeNAS users.

SEDs are the only way forward for full-disk encryption.

This is too bad, as I'd prefer to have full disk encryption without resorting to dedicated hardware.
Are there no plans for supporting other methods of full disk encryption going forward?
As for the tutorial for removing disk encryption, I've seen it and, aside from the complexity, it forces you to fill your disks with your unencrypted data, which I'd rather not do.

 

[sretalla]

As for the tutorial for removing disk encryption, I've seen it and, aside from the complexity, it forces you to fill your disks with your unencrypted data, which I'd rather not do.

I'm not sure you understood the options if you came to that conclusion... you can for sure remain encrypted at all times during the process if you select a path where that's the case.

This is too bad, as I'd prefer to have full disk encryption without resorting to dedicated hardware.

SED is something that's pretty common... have you checked if your disks support it (reasonable chance that they do).

Are there no plans for supporting other methods of full disk encryption going forward?

None that I have seen. I don't imagine there's any interest in it.

 

[Pestaninha]

I'm not sure you understood the options if you came to that conclusion... you can for sure remain encrypted at all times during the process if you select a path where that's the case.

I didn't spot that on the guide, would you care to point at the method?

SED is something that's pretty common... have you checked if your disks support it (reasonable chance that they do).

They are WD Red disks, I checked and they don't support SED. I prefer to use software encryption either way

None that I have seen. I don't imagine there's any interest in it.

I've read through a lot of posts of people using full disk encryption and complaining of the native ZFS encryption, so I'd say the interest is there... I'm just not sure if IX systems will want to continue to offer it. I'd love to be able to continue to use GELI if that is a possibility. In fact, I'm strongly considering using GELI for the time being on this new pool, just don't know for how long this will be allowed

 

[sretalla]

With GELI still active, create ZFS encrypted datasets and move your content to them.

Then do the resilver to remove GELI from each disk.

 

[winnielinnie]

I'd love to be able to continue to use GELI if that is a possibility. In fact, I'm strongly considering using GELI for the time being on this new pool, just don't know for how long this will be allowed

When feasible, it's highly advised to (safely) migrate over to the new method of native ZFS encryption.

Not only is GELI outright unsupported on SCALE (or Linux for that matter) if you ever decide to side-step to SCALE, and not only will you be unable to create new GELI containers going forwards in Core, but the process of resilvering/expanding/replacing drives in a pool has greater risks and complexities when GELI is involved, as opposed to native ZFS encryption.

I've read through a lot of posts of people using full disk encryption and complaining of the native ZFS encryption

I, too, was tentative and confused prior to switching exclusively to native ZFS encryption away from GELI, but I have long-since changed my mind and fully accept that I'm losing the extra layer of privacy/deniability that one achieves with block-device encryption over native ZFS encryption.



---



To borrow from an old post of mine, in regards to what is encrypted/private "at rest":

Native ZFS, at rest (or powered off):

• Inaccessible
  
  • File Data
  • File Names and Properties
  • Sizes of individual files (unsure about this one)
  • Directory listings and structures
  • Logs (if logs are saved here)
• Accessible
  
  • Encryption Options and Hashes
  • ZFS Metadata and Options
  • Number of Files and Blocks (via pointers and inodes) [1]
  • Dataset Names
  • Snapshot Names
  • Free Space
  • Used Space

LUKS, at rest (or powered off):

• Inaccessible
  
  • File Data
  • File Names and Properties
  • Directory listings and structures
  • Sizes of individual files and folders
  • Number of files and folders
  • Logs (if logs are saved here)
  • Free Space (can be inferred if underlying devices were not filled with random data prior to creation)
  • Used Space (can be inferred if underlying devices were not filled with random data prior to creation)
  • File System and metadata within
• Accessible
  
  • Encryption Options and Hashes

VeraCrypt container, at rest (or powered off):

• Inaccessible
  
  • File Data
  • File Names and Properties
  • Directory listings and structures
  • Sizes of individual files and folders
  • Number of files and folders
  • Logs (if logs are saved here)
  • Free Space (container filled with random data upon creation)
  • Used Space (container filled with random data upon creation)
  • File System and metadata within
  • Encryption Options and Hashes
• Accessible
  
  • Apparently [nothing, just a suspicious mess of random data [2]

[1] Seems like native ZFS encryption is "leakier" than I first suspected, but it makes sense considering it requires certain information and metadata in order to send and recv, create snapshots, scrub, etc, without requiring encrypted datasets to be unlocked.

[2] Until decrypted, a VeraCrypt partition/device appears to consist of nothing more than random data (it does not contain any kind of "signature"). Therefore, it should be impossible to prove that a partition or a device is a VeraCrypt volume or that it has been encrypted.



---



The reason for why the above properties are "accessible" with native ZFS encryption, even "at rest", is what allows us to do the following, regardless if a dataset is locked or unlocked:

• scrubs
• create, delete, and manage snapshots, bookmarks, and holds
• resilvers
• expansions/replacements
• dedup
• replications and send/recv (with the "raw" flag)

The last example, for instance as a home user, you can outright give a friend full responsibility to safeguard an internal or external drive(s) with your backups on it without ever once having to unlock / decrypt any of the data, even when they bring the drive(s) over for a backup replication. Heck, they can even plug it into a Linux or FreeBSD box (or their own TrueNAS server) and run a full scrub on your behalf. At no point will they ever have access to any of your data.

Think of it as a grassroots, cheap way to "offsite" your own ZFS backups without the need of owning another property/home/office/server, while keeping your data private with at-rest encryption.

You will have to change some habits when switching over to native ZFS encryption: do not use identifiable or "interesting" names with your datasets and snapshots. This is something I had to become accustomed to. For example, I have some datasets named "data2", "data3", "data-green", etc. It's boring, uninteresting, vague, and it's not obvious I'm trying to obfuscate anything. I, personally, know what the contents are within, but to an outsider, there's nothing discernable that can be deduced from those names.

 

[winnielinnie]

With GELI still active, create ZFS encrypted datasets and move your content to them.

I did this via a simpler and safer method by exploiting the fact that I wanted to expand my pool capacity shortly after TrueNAS Core 12 was released.

I created the new pool (with new Red Plus drives I had purchased for the very reason of expansion), migrated everything over from the old pool (GELI) to the new pool (native ZFS encryption). Upon confirming everything was safely copied over, I destroyed the old pool, and then used the drives from the former old pool to expand my new pool with an additional mirror vdev.

Tada! A little "two-in-one" bonus. I was able to migrate over and expand my pool capacity in one go because of timing my upgrade purchase with TrueNAS 12's release.

So if you are thinking of expanding your pool's capacity, you can hold out on GELI for now until a later time when you feel you need to upgrade, which will allow you to leverage the fact that you have fresh new drives to facilitate in the migration process.

"I was going to increase my pool's capacity anyways, so I might as well use the new drives for the first data vdev in my new pool creation, and then later just keep my old pool's drives to add them as a second data vdev to the new pool to increase its overall capacity."

 

[sretalla]

I did this via a simpler and safer method

Great alternative if you have the capacity/possibility to do it.

 

[Arwen]

One last note about TrueNAS encryption. While their are a specific set of encryption options for ZFS, it is likely in the future that more will be added.

It's possible that FreeBSD GELI encryption will also get new encryption options. But, since FreeBSD's main file system is now ZFS, it's also possible that disk encryption improvements will more focused on ZFS than GELI.

Plus, ZFS encryption is cross-platform, like has been mentioned before. It's available with Linux, MacOS, and maybe even MS-Windows.