ZFS on Linux - Native encryption

[Arwen]

Bugs in OpenZFS native encryption send / receive are being worked on. Here is one;

https://github.com/zfsonlinux/zfs/pull/6864

Turns out their was an on-disk format problem with the original OpenZFS native encryption. Tom had to squash another bug, and then fix his code a bit more. The end result is any currently existing OpenZFS native enrypted datasets or Zvols will be mounted R/O when using the new code.

Good example for people not to be early adopters for production data.

 

[Ericloewe]

Interesting. Glad to see a relatively elegant solution to handle the incompatibility.

 

[Arwen]

Interesting. Glad to see a relatively elegant solution to handle the incompatibility.

He also added a version number for encrypted datasets. Anything without a version is 0 / Zero. The new encrypted on-disk format is version 1.

 

[Ericloewe]

It's somewhat inevitable with an on-disk format change and was bound to happen sooner or later. It should be an additional tiny bit of metadata for each dataset.

 

[Arwen]

It's somewhat inevitable with an on-disk format change and was bound to happen sooner or later. It should be an additional tiny bit of metadata for each dataset.

It's only for the encrypted dataset / Zvols. The other aspects of ZFS are un-changed, (if I understand correctly).

 

[Ericloewe]

It's only for the encrypted dataset / Zvols.

Yeah, good point, even better.

The other aspects of ZFS are un-changed, (if I understand correctly).

As far as I understand, the structure is the same, it's just that some of the checksums are computed differently to allow for raw send/recv. If we had BPR, I imagine there could be a script that ran through all encrypted blocks and fixed them, saving the send/recv step to migrate to a new dataset.

 

[Arwen]

Here is my wish list for OpenZFS native encryption:

1. It would be nice to have at least 2 sets of passwords / keys. Linux disk encryption supports 8 slots. Having a second may allow recovery. Meaning you can have a master encryption key on a USB flash drive, kept locked up. But the normal operations staff have access to a another one with a password. If the password get's lost or changed without knowing what it is, the master can be used.
   
2. If we have more than 1 slot, then I would think an option to allow either R/W or R/O keys. This would affect mounting the dataset and ability to change the keys, (like operations for backups would only need R/O). But, there would be a safeguard to prevent deleting the last R/W key.
3. If we have more than 1 slot, then perhaps a Master / Secondary flag. This would allow 2 slots to be both R/W, but a Secondary could not delete / change the key or password from the Master slot. Again useful when dealing with operations staff who may perform scheduled changes involving reboots or pool imports. Again there should be a safeguard in place that would prevent the last Master key from being deleted.
   
4. Ability to use partitions on a USB drive for RAW keys. It can be done today, but requires scripting. If the ZFS dataset supported it directly, no scripting needed. Just specify the USB device path, (including partition identifier).
5. A very lightweight encryption algorythm, just for casual users. Enough to prevent many hardware thieves, and vendor returns from being able to look at the data. Of course, I am not talking quad pass ROT13 .
6. Grub / InitRD support for encrypted pools or datasets / Zvols. This is probably pretty straight forward and may be simple to add, since LUKS does allow fully encrypted root drives, (but separate /boot).

Anyone else have a wish for OpenZFS native encryption?

 

[Arwen]

Tom Caputi updated his slides and made a new presentation about OpenZFS at rest encryption;

https://docs.google.com/presentation/d/1km-z3MVNHYwlQLY6yEC3iq-TD05eredH9Ih4umGdkJw/edit#slide=id.p4

I have not gone through it yet. But, seems nice.

On the general status of OpenZFS at rest encryption, it's still months away from being stable. They found another gotcha. Nothing too serious, but going forward, they have to change the on-disk format again. But only for encrypted datasets and ZVols.