Is an encryption passphrase useful in my case?

[fyboqyovjy]

Hello,
I've read the documentation about encrypted pools in FreeNAS. It says:

Encrypted pools that have no passphrase are unlocked at startup. Pools with a passphrase remain locked until a user enters the passphrase to unlock them.

This is my current setup:
I have Proxmox on my server and FreeNAS is a VM on it.

The boot device and also the VM image storage is a mirror with two self encrypting SSDs.
So if I want to boot the server and run a VM, I already have to type a password to decrypt the boot device.

For FreeNAS I passthrough a PCIe HBA. Then I created an encrypted pool on it.
Now I'm not sure if it makes sense to add a passphrase to this encrypted pool, or not?

The pool will unlock automatically if I start the FreeNAS VM.
But to be able to do that, I have to type a password anyway.

What do you think?
Will I gain anything if I add a passphrase to manually unlock the encrypted pools?

Also:

FreeNAS® generates a randomized encryption key whenever a new encrypted pool is created. This key is stored in the system dataset. It is the primary key used to unlock the pool each time the system boots.

In my case the system dataset is the encrypted pool. Where's the logic to store the encryption key on the encrypted pool?
Isn't that ridiculous? Or is there something I didn't understand? Should I use the boot device as system dataset in this case?

 

[sretalla]

I'm not sure if it's enforced, but you can't have the system dataset on a pool encrypted with a password for exactly that reason... you would be without a system dataset until you enter the password.

I would question what you expect from encryption... first be clear about that and then we can recommend what to do.

The primary purpose of geli encryption (currently available in FreeNAS) is to protect the contents of the disks if those disks are ever separated from the system. If the intention is to protect the data while still resident in the system which has the keys in it, you're barking up the wrong tree (the Open ZFS 2 dataset encryption options coming in TrueNAS 12 Core will get you further down the road in that direction... but maybe still not what you want).

 

[fyboqyovjy]

I'm not sure if it's enforced, but you can't have the system dataset on a pool encrypted with a password for exactly that reason... you would be without a system dataset until you enter the password.

But I can have to system dataset on an encrypted pool without a passphrase.
Since the encryption keys are stored on that system dataset, wouldn't that make the encryption useless anyway?

If someone steals an encrypted drive and put it in his FreeNAS box, he could access the data?
Because there is no passphrase and the encryption key is stored on that drive?

I would question what you expect from encryption... first be clear about that and then we can recommend what to do.

If someone steals the server or a drive, he shouldn't be able to access the data on it.
I know that data isn't encrypted while the system is running.

 

[Samuel Tai]

No, the encryption keys in /data/geli are on the boot pool, not the data pool.

 

[sretalla]

But I can have to system dataset on an encrypted pool without a passphrase.

AFAIK, the key is also stored in the config (boot pool), so the pool is unlocked with that copy of the key.

If someone steals the server or a drive, he shouldn't be able to access the data on it.

True

If someone steals the server or a drive, he shouldn't be able to access the data on it.

A good sentiment, but not how geli does it for now. OpenZFS 2.0 may get you closer to that.

 

[fyboqyovjy]

No, the encryption keys in /data/geli are on the boot pool, not the data pool.

Where do you have this information from? Because the documentation tells something different:

FreeNAS® generates a randomized encryption key whenever a new encrypted pool is created. This key is stored in the system dataset. It is the primary key used to unlock the pool each time the system boots.

See here

 

[Samuel Tai]

If it were on the system dataset, that introduces a chicken-and-egg scenario, where the key to unlock the pool exists encrypted within the pool.

 

[fyboqyovjy]

Yes that's true. So then it is an error in the documentation?
The encryption key is always stored on the boot device, no matter if it is the system dataset or not?

 

[Samuel Tai]

Yes, I believe this is a documentation erratum. So far as I know, the /data directory is always on the boot pool, regardless of the location of the system dataset.

 

[fyboqyovjy]

Okay. Thank you for clarification.

So in this case I think I don't need to set an encryption passphrase, because the key is stored on the boot device which resides on the SEDs.
This will protect me from both scenarios. Stolen server and stolen disks.