4 ms·

Zfs has a per dataset data encryption key. When you destroy a filesystem or volume, the key is also destroyed. This makes recovery of data in deleted datasets e

Zfs has a per dataset data encryption key. When you destroy a filesystem or volume, the key is also destroyed. This makes recovery of data in deleted datasets exceedingly hard even with raw disk access. LUKS and other FDE schemes tend not to have the ability to have fine grained encryption keys. If you have raw access to the LUKS device on which your filesystem resides, you can recover plaintext of blocks that have not been overwritten or erased via TRIM or similar. zfs on a self encrypting drive seems like a good combination. Even if the Opal implementation is garbage (see CVEs from a couple years back) the exposure is minimal because zfs is encrypting data. My measurements of performance impact IO with and without encryption suggest there is no performance nor increased cpu consumption with self-encrypting drives.

aborsy 4y ago
Can you elaborate on this a bit further? Suppose that I have encrypted ZFS datasets. Naturally, sometimes the process of working with datasets is interrupted (due to, eg, power loss and so on). Is it known how much plaintext could potentially leak to disk outside encrypted ZFS datasets, possibly accessible by forensic analysis? That would violate the confidentiality guarantee in the event of an accident. Related to this, if I recall correctly, if the encryption key is changed, ZFS may not destroy the old wrapped key and may keep it stored on disk outside the dataset. This is apparently due to the copy-on-write system.
- mgerdts 4y ago
  > Is it known how much plaintext could potentially leak to disk outside encrypted ZFS datasets, possibly accessible by forensic analysis? When a write to an encrypted dataset happens, no plaintext data is written to disk. Your data is every bit as secure from disclosure as if the write completed normally. Think of ZFS encryption like you would TLS encryption. They both hide your data, but leak metadata. With ZFS encryption, someone with access to the disk can see what you name your datasets (don't name your dataset "people-i-killed" or name your snapshot @before-starting-the-fire), the order that each block was written (via birth txg in block pointer), how much data was written to which datasets, when the last write happened (via ub_timestamp in uberblock copies in vdev labels), etc. Likewise, with TLS someone with access to the network can tell who the endpoints of the connection are, when each party sent data, and how much data was sent. If you have full disk encryption under encrypted ZFS, you get the goodness of encrypted ZFS plus after your drive has been powered off, no one can determine anything about the content of the drive (except maybe that which is leaked via SMART and similar data). This is kinda like having a VPN and using TLS. Someone with access to the network under the VPN can still see that there's activity but has a much harder time figuring out information about the data and metadata with the VPN.

aborsy 4y ago

Can you elaborate on this a bit further? Suppose that I have encrypted ZFS datasets. Naturally, sometimes the process of working with datasets is interrupted (due to, eg, power loss and so on). Is it known how much plaintext could potentially leak to disk outside encrypted ZFS datasets, possibly accessible by forensic analysis? That would violate the confidentiality guarantee in the event of an accident. Related to this, if I recall correctly, if the encryption key is changed, ZFS may not destroy the old wrapped key and may keep it stored on disk outside the dataset. This is apparently due to the copy-on-write system.

mgerdts 4y ago
> Is it known how much plaintext could potentially leak to disk outside encrypted ZFS datasets, possibly accessible by forensic analysis? When a write to an encrypted dataset happens, no plaintext data is written to disk. Your data is every bit as secure from disclosure as if the write completed normally. Think of ZFS encryption like you would TLS encryption. They both hide your data, but leak metadata. With ZFS encryption, someone with access to the disk can see what you name your datasets (don't name your dataset "people-i-killed" or name your snapshot @before-starting-the-fire), the order that each block was written (via birth txg in block pointer), how much data was written to which datasets, when the last write happened (via ub_timestamp in uberblock copies in vdev labels), etc. Likewise, with TLS someone with access to the network can tell who the endpoints of the connection are, when each party sent data, and how much data was sent. If you have full disk encryption under encrypted ZFS, you get the goodness of encrypted ZFS plus after your drive has been powered off, no one can determine anything about the content of the drive (except maybe that which is leaked via SMART and similar data). This is kinda like having a VPN and using TLS. Someone with access to the network under the VPN can still see that there's activity but has a much harder time figuring out information about the data and metadata with the VPN.