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-256-ccm(default in OpenZFS < 0.8.4)
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,
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
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.
LUKS or comparable atop OpenZFS removes the aforementioned issues—a
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
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
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
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 root@banshee:~#
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.