Encryption Queries

[hardwired]

Just a couple of pre-purchase queries regarding encryption I had when running this in a test VM:

• Can a pool be encrypted with a password as opposed to a key during initial configuration? Requiring a password before mount?
  I noted when creating a test pool it automatically encrypted with a key with no option for a password. Attempting to change that to a password it throws an error that the pool contains the system dataset and that would need to be moved prior to changing from key to password key_format.
• On boot I noticed that the encrypted pools mounted automatically, where is the encryption key stored?
  I assume on the TrueNAS OS drive itself? Offering similar protection to that of removing a drive from its associated TPM?
• Is there anything inherently wrong with just encrypting Datasets/ZVOL underneath an unencrypted pool?
• Is TrueNAS/ZFS encryption production ready? The Enterprise offering looks like it allows for KMIP, and supports FIPS 140-2 drives, so yes?

Thanks all.

 

[winnielinnie]

Attempting to change that to a password it throws an error that the pool contains the system dataset and that would need to be moved prior to changing from key to password key_format.

The System Dataset cannot live under a pool in which the root dataset is encrypted with a passphrase. No way around that. Either use a key or relocate the System Dataset to another pool (or employ the pseudo-roots method I use, where the top-level root dataset is only an encrypted place-holder protected with a key. You can even leave the top-level root dataset non-encrypted, which is done during the pool creation step.)

On boot I noticed that the encrypted pools mounted automatically, where is the encryption key stored?
I assume on the TrueNAS OS drive itself?

That's correct, on the boot device itself. To be technical, under /data I believe. Either way, export the key for safekeeping. It's needed for re-importing a pool too. The exported "keyfile" is really just a .json text file with the names of the datasets and their accompanying 64-character HEX strings (which serve as the keystrings when unlocking / re-importing.)

Is there anything inherently wrong with just encrypting Datasets/ZVOL underneath an unencrypted pool?

Nope. It'll be protected just like any other encrypted dataset. Just because the parent dataset (or even top-level root dataset) is non-encrypted, the specific dataset you encrypted with a passphrase is protected unless unlocked.

Is TrueNAS/ZFS encryption production ready? The Enterprise offering looks like it allows for KMIP, and supports FIPS 140-2 drives, so yes?

No idea about KMIP, haven't used it myself, but ZFS native encryption is definitely production ready and stable. It's even cross-platform compatible.

 

[hardwired]

Thanks for that. One more from me:

Either way, export the key for safekeeping. It's needed for re-importing a pool too. The exported "keyfile" is really just a .json text file with the names of the datasets and their accompanying 64-character HEX strings (which serve as the keystrings when unlocking / re-importing.)

Does that mean one should export their pool key whenever a change of the underlying datasets/ZVOLs is made?

 

[winnielinnie]

Does that mean one should export their pool key whenever a change of the underlying datasets/ZVOLs is made?

Only if you change the keystring or other encryption properties, such as whether or not the dataset is inheriting its encryption properties from a higher-up parent (i.e, an "encryptionroot"), or if you make the dataset its own encryptionroot.

Essentially, any of the following should be proceded by exporting the pool keys:

• Changing a dataset's encryption properties from inherited to non-inherited
• Changing a dataset's encryption properties from non-inherited to inherited
• Changing the encryption keystring

None the above applies to passphrase-protected datasets, as it is up to you to memorize the passphrase.

Remember, with OpenZFS 2 and beyond, no "pool" is really encrypted. It happens at a per-dataset level. The way TrueNAS Core 12+ presents the option during pool creation gives the impression you are creating an "encrypted pool", when in fact all it is doing is offering to encrypted the top-level root dataset. If you leave everything at their defaults, then each subsequent child dataset you create will inherit the root dataset's encryption properties, so it does come across as an "encrypted pool". (The reality is, you have many datasets that all happen to be encrypted and protected with the same keystring / passphrase.) You can break this inheritance at any point.

EDIT: It's better to export your pool keys "too many times" rather than keep holding it off. It doesn't hurt to have more than one copy of the file. The worst it can do is cost you an extra few bytes of data whereever you happen to store your key files.

 

[winnielinnie]

I forgot to mention, if your boot device is an SSD or m.2 drive, you can always relocate the System Dataset and syslog to the boot-pool, this way your data pools and root datasets are not beholden to any limitations of passphrase protection.