A quick-start guide to OpenZFS native encryption

A fast-start information to OpenZFS native encryption


Enlarge / On-disk encryption is a posh subject, however this text ought to offer you a stable deal with on OpenZFS’ implementation.

One of many many options OpenZFS brings to the desk is ZFS native encryption. First launched in OpenZFS 0.8, native encryption permits a system administrator to transparently encrypt knowledge at-rest inside ZFS itself. This obviates the necessity for separate instruments like LUKS, VeraCrypt, or BitLocker.

OpenZFS encryption algorithm defaults to both aes-256-ccm (previous to 0.8.4) or aes-256-gcm (>= 0.8.4) when encryption=on is ready. However it might even be specified immediately. At the moment supported algorithms are:

  • aes-128-ccm
  • aes-192-ccm
  • aes-256-ccm (default in OpenZFS < 0.8.4)
  • aes-128-gcm
  • aes-192-gcm
  • aes-256-gcm (default in OpenZFS >= 0.8.4)

There’s extra to OpenZFS native encryption than the algorithms used, although—so we’ll attempt to offer you a short however stable grounding within the sysadmin’s-eye perspective on the “why” and “what” in addition to the easy “how.”

Why (or why not) OpenZFS native encryption?

A intelligent sysadmin who desires to supply at-rest encryption does not really need OpenZFS native encryption, clearly. As talked about within the introduction, LUKS, VeraCrypt, and lots of different schemes can be found and will be layered both beneath or atop OpenZFS itself.

First, the “why not”

Placing one thing like Linux’s LUKS beneath OpenZFS has a bonus—with the whole disk encrypted, an enterprising attacker can not see the names, sizes, or properties of ZFS datasets and zvols with out entry to the important thing. In truth, the attacker cannot essentially see that ZFS is in use in any respect!

However there are important disadvantages to placing LUKS (or comparable) beneath OpenZFS. One of many gnarliest is that every particular person disk which will likely be a part of the pool have to be encrypted, with every quantity loaded and decrypted previous to the ZFS pool import stage. This generally is a noticeable problem for ZFS programs with many disks—in some circumstances, many tens of disks. One other drawback with encryption-beneath-ZFS is that the additional layer is an additional factor to go unsuitable—and it is able to undo all of ZFS’ regular integrity ensures.

Placing LUKS or comparable atop OpenZFS removes the aforementioned issues—a LUKS encrypted zvol solely wants one key no matter what number of disks are concerned, and the LUKS layer can’t undo OpenZFS’ integrity ensures from right here. Sadly, encryption-atop-ZFS introduces a brand new drawback—it successfully nerfs OpenZFS inline compression, since encrypted knowledge is mostly incompressible. This strategy additionally requires the usage of one zvol per encrypted filesystem, together with a visitor filesystem (e.g., ext4) to format the LUKS quantity itself with.

Now, the “why”

OpenZFS native encryption splits the distinction: it operates atop the conventional ZFS storage layers and due to this fact does not nerf ZFS’ personal integrity ensures. But it surely additionally does not intrude with ZFS compression—knowledge is compressed previous to being saved to an encrypted dataset or zvol.

There’s an much more compelling purpose to decide on OpenZFS native encryption, although—one thing known as “uncooked ship.” ZFS replication is ridiculously quick and environment friendly—incessantly a number of orders of magnitude quicker than filesystem-neutral instruments like rsync—and uncooked ship makes it potential not solely to copy encrypted datasets and zvols, however to take action with out exposing the important thing to the distant system.

Which means that you need to use ZFS replication to again up your knowledge to an untrusted location, with out considerations about your non-public knowledge being learn. With uncooked ship, your knowledge is replicated with out ever being decrypted—and with out the backup goal ever having the ability to decrypt it in any respect. This implies you’ll be able to replicate your offsite backups to a good friend’s home or at a industrial service like rsync.web or zfs.lease with out compromising your privateness, even when the service (or good friend) is itself compromised.

Within the occasion that it is advisable to get well your offsite backup, you’ll be able to merely replicate it again to your individual location—then, and solely then, loading the decryption key to really entry the info. This works for both full replication (shifting each single block throughout the wire) or asynchronous incremental replication (starting from a generally held snapshot and solely shifting the blocks which have modified since that snapshot).

What’s encrypted—and what isn’t?

OpenZFS native encryption is not a full-disk encryption scheme—it is enabled or disabled on a per-dataset / per-zvol foundation, and it can’t be turned on for whole swimming pools as an entire. The contents of encrypted datasets or zvols are shielded from at-rest spying—however the metadata describing the datasets/zvols themselves just isn’t.

For example we create an encrypted dataset named pool/encrypted, and beneath it we create a number of extra little one datasets. The encryption property for the kids is inherited by default from the dad or mum dataset, so we are able to see the next:

root@banshee:~# zfs create -o encryption=on -o keylocation=immediate -o keyformat=passphrase banshee/encrypted
Enter passphrase: 
Re-enter passphrase: 

root@banshee:~# zfs create banshee/encrypted/child1
root@banshee:~# zfs create banshee/encrypted/child2
root@banshee:~# zfs create banshee/encrypted/child3

root@banshee:~# zfs listing -r banshee/encrypted
NAME                       USED  AVAIL     REFER  MOUNTPOINT
banshee/encrypted         1.58M   848G      432K  /banshee/encrypted
banshee/encrypted/child1   320K   848G      320K  /banshee/encrypted/child1
banshee/encrypted/child2   320K   848G      320K  /banshee/encrypted/child2
banshee/encrypted/child3   320K   848G      320K  /banshee/encrypted/child3

root@banshee:~# zfs get encryption banshee/encrypted/child1
NAME                      PROPERTY    VALUE        SOURCE
banshee/encrypted/child1  encryption  aes-256-gcm  -

In the mean time, our encrypted datasets are all mounted. However even when we unmount them and unload the encryption key—making them inaccessible—we are able to nonetheless see that they exist, together with their properties:

root@banshee:~# wget -qO /banshee/encrypted/child2/HuckFinn.txt http://textfiles.com/etext/AUTHORS/TWAIN/huck_finn

root@banshee:~# zfs unmount banshee/encrypted
root@banshee:~# zfs unload-key -r banshee/encrypted
1 / 1 key(s) efficiently unloaded

root@banshee:~# zfs mount banshee/encrypted
can't mount 'banshee/encrypted': encryption key not loaded

root@banshee:~# ls /banshee/encrypted/child2
ls: can't entry '/banshee/encrypted/child2': No such file or listing

root@banshee:~# zfs listing -r banshee/encrypted
NAME                       USED  AVAIL     REFER  MOUNTPOINT
banshee/encrypted         2.19M   848G      432K  /banshee/encrypted
banshee/encrypted/child1   320K   848G      320K  /banshee/encrypted/child1
banshee/encrypted/child2   944K   848G      720K  /banshee/encrypted/child2
banshee/encrypted/child3   320K   848G      320K  /banshee/encrypted/child3

As we are able to see above, after unloading the encryption key, we are able to not see our freshly-downloaded copy of Huckleberry Finn in /banshee/encrypted/child2/. What we can nonetheless see is the existence—and construction—of our whole ZFS-encrypted tree. We are able to additionally see every encrypted dataset’s properties, together with however not restricted to the USED, AVAIL, and REFER of every dataset.

It is price noting that attempting to ls an encrypted dataset which does not have its key loaded will not essentially produce an error:

root@banshee:~# zfs get keystatus banshee/encrypted
NAME               PROPERTY   VALUE        SOURCE
banshee/encrypted  keystatus  unavailable  -
root@banshee:~# ls /banshee/encrypted

It is because a unadorned listing exists on the host, even when the precise dataset just isn’t mounted. Reloading the important thing does not routinely remount the dataset, both:

root@banshee:~# zfs load-key -r banshee/encrypted
Enter passphrase for 'banshee/encrypted': 
1 / 1 key(s) efficiently loaded
root@banshee:~# zfs mount | grep encr
root@banshee:~# ls /banshee/encrypted
root@banshee:~# ls /banshee/encrypted/child2
ls: can't entry '/banshee/encrypted/child2': No such file or listing

With a view to entry our recent copy of Huckleberry Finn, we’ll additionally want to really mount the freshly key-reloaded datasets:

root@banshee:~# zfs get keystatus banshee/encrypted/child2
NAME                      PROPERTY   VALUE        SOURCE
banshee/encrypted/child2  keystatus  obtainable    -

root@banshee:~# ls -l /banshee/encrypted/child2
ls: can't entry '/banshee/encrypted/child2': No such file or listing

root@banshee:~# zfs mount -a
root@banshee:~# ls -lh /banshee/encrypted/child2
whole 401K
-rw-r--r-- 1 root root 554K Jun 13  2002 HuckFinn.txt

Now that we have each loaded the required key and mounted the datasets, we are able to see our encrypted knowledge once more.

Supply hyperlink

Leave a Reply

Your email address will not be published. Required fields are marked *