Pros / Cons of Key vs. Passphrase ZFS Encryption and How They Work

[hearts12181]

I'm migrating from TrueNAS Core 11.3 to 12.0-U6 and am migrating the data to the new ZFS encryption scheme. I see that you can either encrypt using a HEX key or a passphrase. I just want to understand how each type works and the pros / cons of each method.

1. If using the key method, is it correct that the key is stored inside the system dataset and therefore, the pool is automatically unlocked upon reboot?
   1. If yes, then is the benefit of this method that the access to the data is convenient (and you can throw away the hard drives without wiping them), but at the cost that if the entire computer is taken (with TrueNAS installed) then the data is effectively not encrypted because the pool will unlock without intervention?
      
      
   2. If using the key method, is there any way to set the key storage location to be outside of the system dataset, like on a USB key drive? That way, you can physically remove the USB key drive and the pool will not unlock upon reboot?
      
      
   3. If using the key method, is there a way to temporarily "lock" the pool while the system is on? I don't see any option to do this -- it looks like using the key method, the pool is always unlocked when the system is powered on.
2. If using the passphrase method, it is correct that there is no key stored on the system and therefore, the pool cannot be accessed upon reboot without a person typing in the password after boot?
   1. If yes, then is the benefit of this method that there is added protection to unauthorized access to the data upon reboot, but at the cost of convenience and automation?
      
      
   2. If using the passphrase method, is there a way to temporarily "lock" the pool while the system is on? And then unlock it upon entry of the password?
      
      
   3. While the pool is locked, is it correct that tasks such as snapshots, scrubs, resilver, etc. would continue to work correctly? In other words, it is correct that you don't need to unlock the pool to perform these ZFS tasks?

I would greatly appreciate your comments on my understand above. I am just trying to understand the pros and cons, and welcome suggestions about how each method might be used for different types of data.

 

[sretalla]

1. If using the key method, is it correct that the key is stored inside the system dataset and therefore, the pool is automatically unlocked upon reboot?
   1. If yes, then is the benefit of this method that the access to the data is convenient (and you can throw away the hard drives without wiping them), but at the cost that if the entire computer is taken (with TrueNAS installed) then the data is effectively not encrypted because the pool will unlock without intervention?

Yes and yes.

1. 
   
2. If using the key method, is there any way to set the key storage location to be outside of the system dataset, like on a USB key drive? That way, you can physically remove the USB key drive and the pool will not unlock upon reboot?

Yes, but not on a USB key (rather a KIMP server) and not with the Free CORE version, only Enterprise.

If using the key method, is there a way to temporarily "lock" the pool while the system is on? I don't see any option to do this -- it looks like using the key method, the pool is always unlocked when the system is powered on.

Not really... you can unmount it from CLI.

If using the passphrase method, it is correct that there is no key stored on the system and therefore, the pool cannot be accessed upon reboot without a person typing in the password after boot?

1. If yes, then is the benefit of this method that there is added protection to unauthorized access to the data upon reboot, but at the cost of convenience and automation?

Yes and yes.

If using the passphrase method, is there a way to temporarily "lock" the pool while the system is on? And then unlock it upon entry of the password?

Yes, via the GUI... on the dataset, select the three dots and lock/unlock.

While the pool is locked, is it correct that tasks such as snapshots, scrubs, resilver, etc. would continue to work correctly? In other words, it is correct that you don't need to unlock the pool to perform these ZFS tasks?

True

 

[winnielinnie]

If using the key method, is it correct that the key is stored inside the system dataset and therefore, the pool is automatically unlocked upon reboot?

1. If yes, then is the benefit of this method that the access to the data is convenient (and you can throw away the hard drives without wiping them), but at the cost that if the entire computer is taken (with TrueNAS installed) then the data is effectively not encrypted because the pool will unlock without intervention?

To add more relevance to the discussion of TrueNAS (and not simply ZFS in general), it requires the ability to auto-unlock the top-level root dataset upon startup if you have the System Dataset (i.e, .system) located on the pool in question. If you wish to be able to use a passphrase for the top-level root dataset, you need to either place the System Dataset on the boot device or on a different data pool.

The part highlighted in red is not correct. It's stored on the boot device.


---


Example of such a layout.

• pool: bigtank (pool commands apply to this; dataset commands apply to the top-level root datasetinstead)
  • top-level root dataset: bigtank (same name as the pool, hierarchy: bigtank)
    • downloads (hierarchy: bigtank/downloads)
    • media (hierarchy: bigtank/media)
    • archives (hierarchy: bigtank/archives)
    • iocage (used for jails/plugins, hierarchy: bigtank/iocage)
    • .system (the System Dataset, hierarchy: bigtank/.system)

In the above scenario, because you selected the pool bigtank for your System Datset to live (done via the TrueNAS GUI), you cannot use a passphrase on the top-level root dataset bigtank. Upon reboot, the top-level root dataset bigtank is automatically unlocked using the HEX keystring saved on the boot device (located in the directory /data), and thus the (important) System Dataset is immediately available.

If you ever move the System Dataset (.system) to another pool or to the boot device itself, you can then use a passphrase on the top-level root dataset bigtank (if you wish).

 

[ShimadaRiku]

Each dataset has it's own MasterKey. Does this mean in theory nested child datasets could be unlocked without unlocking the parent?

 

[winnielinnie]

Each dataset has it's own MasterKey. Does this mean in theory nested child datasets could be unlocked without unlocking the parent?

Theoretically? Yes. But for all intents and purposes, you only ever unlock each "encryptionroot".

Unlocking the "encryptionroot" dataset subsequently unlocks all inherited datasets underneath. (This is seen when entering only a single passphrase or providing only a single keystring, yet multiple nested datasets are now available after the "encryptionroot" is unlocked.)

It can be as simple as the top-level dataset being the "encryptionroot" for everythying else below.

Or as complex as every single dataset being its own "encryptionroot".

 

[sretalla]

I think (have done no testing with this) that if you're breaking encryption inheritance and setting encryption again, you can unlock children separately from parents... however, you would need to deal with another problem that it would create... mounts.

If you try to mount a child which wants to mount inside the parent which is locked and hence not mounted... who knows what interesting trouble you will have to work through with that.

You could have datasets with mount points outside their parent... but we're getting into crazy edge cases here that only serve to be problems somewhere later when the programmers don't consider that edge case.

 

[Paul5]

Late to the party but...Hearts 12181 I have been doing what you seem to want with GLI since <2013 and now with TN12 ZFS and the indisputable help using APIs with sretalla's help I have successfully done it with, at the moment, one HDD drive which contains the System Dataset and an Encrypted dataset that is decrypted based upon the correct IP being available and the remote mounted USBs being available. 100% physical theft protection.

You will need to setup postinit and or cronjobs to keep looking for when to lauch the scripts.

You can unlock your encrypted Datasets using local or remote USB's ZFS Encryption USB auto unlock and mount
You can unlock your encrypted Datasets when an IP is present on the network as well.

You can also do the reverse using the lock API though I have had trouble with getting the scripts to work automatically without rebooting and have temporarily abandoned it > midclt call pool.dataset.lock poolname or midclt call pool.dataset.lock poolname/dataset/child will lock your respective pool or dataset.

Their is also a Python script from around 2013 that will shutdown FN/TN after XXX time if no IP's on the list are present. Needless to say that TN does support Wake On Lan.

From what I understand everything you ask about can be done in one form or another such as a script on your working PC that uses putty or other to lock and unlock your datasets whilst getting the pass-phrases from an inserted USB. I have never done it but I know it can be done.

 

[Rosin0416]

Hello,

Having recently migrated from freenas 9.3 to truenas 13 (new installation), I knew that the encryption method had changed and I was looking for information on the subject. The Truenas documentation is not very complete in this respect.
Your exchanges are very interesting and answer a lot of my questions.

I have a question about passphrases :
As I understand it, the passphrase now replaces the encryption key. Isn't there a security problem?
A passphrase, even if it is complex, is less secure than an encryption key.
Is there any mathematical processing done on this passphrase to make it as efficient as an encryption key?

I ask myself this question because on the old freenas/truenas encryption system, and unless I am mistaken, when a passphrase was added, it was only used to unlock the access to the GELI encryption key.
We had to give the encryption key + the passphrase to decrypt a pool.

Can you please enlighten me?
Regards

 

[winnielinnie]

As I understand it, the passphrase now replaces the encryption key. Isn't there a security problem?

You can choose to use a keyfile (i.e, a 64-character HEX string) or a passphrase. It's not passphrase-only.

A passphrase, even if it is complex, is less secure than an encryption key.

How? You can use the following as a passphrase, which is difficult for even a supercomputer to brute-force or crack:
I enjoy 7 cups of lemonade every week!

Is there any mathematical processing done on this passphrase to make it as efficient as an encryption key?

Whether you choose keyfile or passphrase, it's still run through 350,000 iterations (by default I believe.)

when a passphrase was added, it was only used to unlock the access to the GELI encryption key.

It's the same concept with native ZFS encryption. The "user key" is either a keyfile (64-character HEX) or passphrase, which is used to decrypt the Master Key that encrypts/decrypts your actual data.

We had to give the encryption key + the passphrase to decrypt a pool.

That was optional. GELI could use a keyfile + passphrase if desired. By default, it was keyfile only. Yet it's moot when you consider the above. Not to mention native ZFS encryption is worlds superior to GELI + ZFS.

 

[Rosin0416]

Hello,
Thank you for your quick feedback.
Sorry I misspoke.

As I understand it, the passphrase now replaces the encryption key. Isn't there a security problem?

You can choose to use a keyfile (i.e, a 64-character HEX string) or a passphrase. It's not passphrase-only.

Yes, I did understand that we had the choice between an encryption key and a passphrase.


I believe you if you tell me that the sentence you gave (I enjoy 7 cups of lemonade every week!) cannot yet be discovered by brute force in a reasonable time.

However, the passphrase you gave is 38 characters long. So it would be less robust than the 64 character of keyfile?

I would like to point out that this is a subject that interests me but I am not a great specialist. I'm just trying to understand how it works.

So what is different between the old encryption method on freenas / truenas and the new encryption method on Truenas?

Regards

 

[danb35]

So it would be less robust than the 64 character of keyfile?

Not really. The 64-character keyfile represents a 32-byte, or 256-bit, number. Therefore, there are 16^64, or 2^256, or about 10^77, possible values. In the case of the passphrase you quoted, it contains uppercase, lowercase, numerals, and special characters. If we assume that any printable ASCII character (plus spaces) can be in the passphrase, that's 96 possible characters, or 96^38 possible values, assuming 38 characters were the maximum length of a passphrase. That's about 2 x 10^75--so yes, still less secure by a factor of about fifty. But there's no reason to limit the passphrase length to 38 characters, it could easily be considerably longer. And that's a key that you can store in your mind, rather than on the boot media.

 

[winnielinnie]

However, the passphrase you gave is 38 characters long.

It contains:

• lowercase letters
• uppercase letters
• numbers
• spaces
• symbols

Meaning an attacker has to include lowercase letters, uppercase letters, numbers, and all types of special characters/symbols in order to include the possibility of such being used. (They don't know I'm also using spaces and exclamation points, so they're going to go ahead and add !@#$%^& etc, etc, etc, to their character set.) It will take them "centuries" to crack.

Cygnius Password Strength Test

As for me? It's easy to remember and write "I enjoy 7 cups of lemonade every week!" I don't need to juggle with random keystrings or memorize/write complex random characters of text.

The phrase "I enjoy 7 cups of lemonade every week!" is meaningful to me; easy to write; easy to remember; yet very hard for a computer to crack.

So what is different between the old encryption method on freenas / truenas and the new encryption method on Truenas?

A. Lot.

Native ZFS encryption is integrated with OpenZFS, meaning it's easier and more flexible to:

• replace devices in a vdev
• expand pools
• use granular protection (some datasets encrypted, some not)
• allow for scrubbing, snapshots, and replications without unlocking/decrypting any data
• and so on and so on

EDIT: @danb35 beat me to it.

 

[danb35]

It's easy to remember and write "I enjoy 7 cups of lemonade every week!" I don't need to juggle with random keystrings or memorize/write confabulated random characters of text.

...and kind of a middle point could be diceware passphrases:

How to Roll a Strong Password with 20-Sided Dice and Fandom-Inspired Wordlists

Here’s the not-so-secret recipe for strong passphrases: a random element like dice, a long list of words, and math. And as long as you have the first two, the third takes care of itself. All together, this adds up to diceware, a simple but powerful method to create a passphrase that even the most...

www.eff.org

Edit: If you don't have 20-sided dice, here's an alternative method using ordinary 6-sided dice:

https://theworld.com/~reinhold/diceware.html

Each word is one of 4000 (or 7776 with six-sided dice), so represents just under 12 bits of entropy (assuming the attacker has the word list you used, i.e., the worst-case scenario). The words are chosen by rolls of the dice, so they're truly random. It's going to give you a long phrase, but it'll be secure and easier to remember than a hex string.

 

[Rosin0416]

Ok I understand much better.

So it would be less robust than the 64 character of keyfile?

Not really. The 64-character keyfile represents a 32-byte, or 256-bit, number. Therefore, there are 16^64, or 2^256, or about 10^77, possible values. In the case of the passphrase you quoted, it contains uppercase, lowercase, numerals, and special characters. If we assume that any printable ASCII character (plus spaces) can be in the passphrase, that's 96 possible characters, or 96^38 possible values, assuming 38 characters were the maximum length of a passphrase. That's about 2 x 10^75--so yes, still less secure by a factor of about fifty. But there's no reason to limit the passphrase length to 38 characters, it could easily be considerably longer. And that's a key that you can store in your mind, rather than on the boot media.

I thought it took a very large and complex passphrase to equal an encryption key. But obviously, this is much more affordable than I thought. In the end, with about forty characters (all type of characters included), we exceed even the robustness of the key file.

ps: this is probably not very important here, I think there are 95 characters and not 96. The 127th character seems to be the "DEL" key.
https://fr.m.wikipedia.org/wiki/Fichier:ASCII-Table-wide.svg

So what is different between the old encryption method on freenas / truenas and the new encryption method on Truenas?

A. Lot.

Native ZFS encryption is integrated with OpenZFS, meaning it's easier and more flexible to:

• replace devices in a vdev
• expand pools
• use granular protection (some datasets encrypted, some not)
• allow for scrubbing, snapshots, and replications without unlocking/decrypting any data
• and so on and so on

Indeed, I do a lot of testing to understand what can and cannot be done.
I noticed the following things in terms of what you call granular protection :

1. When a parent dataset is encrypted via a keyfile, the children and great-grandchildren can be encrypted either by a keyfile or by a "passphrase". On the other hand, when a parent dataset is encrypted via a "passphrase", the children and great-grandchildren datasets will have no choice but to be encrypted via a "passphrase". But each children and great-grandchildren can have its own "passphrase".
2. It is possible to not encrypt the root dataset of the pool and to encrypt one or more children and great-grandchildren
3. Conversely, it is possible to fully encrypt the root dataset of the pool and not encrypt one or more children and great-grandchildren
4. Each children and great-grandchildren can have its own encryption keyfile or passphrase (attention on the keyfile, it is conditioned to the 1.)
5. At any time, it is possible to switch from an encryption key to a "passphrase" (attention to switch to the keyfile, it is conditioned to the 1.)

2. If using the key method, is there any way to set the key storage location to be outside of the system dataset, like on a USB key drive? That way, you can physically remove the USB key drive and the pool will not unlock upon reboot?

I am quite attracted by this solution proposed by @hearts12181 which seems very practical . Unfortunately it seems to be complicated to implement.
Ror example when I go on vacation for 3 weeks, I usually stop the nas because I only use it locally.
It would be reassuring to remove a usb device containing the encryption keys, rather than having to connect to the web interface to unlock the datasets with a passphrase.


Regards