Some Encrypted Volumes Automatically mount after reboot

[jvanas]

........ but not others.

Does anyone know:
1. Why some encrypted volumes automatically mount without typing the unlock the key after a reboot and not the others?
2. Is there a way to get the functionality back on the volumes that stop working (yes, even if it isn't supported)?

And for those that will ignore my actual question and just tell me this is functionality by design:
1. Then the design isn't working, as 2 out of 3 of my Encrypted volumes do automatically mount after a reboot, every time.

2. And why is this the design? The argument I have read elsewhere, that in the event someone steals my hardware they could access the data, doesn't really hold water for my use cases. Not to start a religious battle here, but it really is no more or less secure if the system (as configured by the admin) boots normally unlocked because there are still OS and Share based authentications that normally protect the system every day. If those aren't good enough protections, then by all means we should never use FreeNas for secure data. What really needs protected here in the case of theft, is someone removing my drives and plugging them into their FreenNas setup and gaining access to the data without the keys or user authentication. IMO, it is far more risky to have a non-redundant storage controller that cannot recover from crashes automatically than it is to have a server stolen and then accessed. The former happens all the time, the latter, well it's never happened to me, so why is this the design case? If you disagree for your use case fine, can we at least agree that auto-encrypted-remount should be an optional configuration for the admin?

Thanks for everyone's help in advance,
Josh

 

[dlavigne]

Do you have different passphrases for each pool?

 

[jvanas]

Do you have different passphrases for each pool?

No, all pools are using the same passphrase.

Thanks!

 

[jvanas]

I do believe that the pool that doesn't re-mount was one that I had to re-key because a disk failed and was replaced. But I did re-key it with the same passphrase.

 

[NickB]

I'm not an expert with drive encryption, but from my testing, if you only encrypt the volume and do nothing else, then they should automatically mount on boot.

Once I set a paraphrase for the volumes, it required the paraphrase before unlocking.

If you want the volumes to come online on reboot, just remove the paraphrase.

My take on it is that drive encryption is good if you have positive control on your machine and you want encryption for data at rest (good if you need to RMA a hard drive). The paraphrase would be good if you're replicating to a friend's house and you don't want to provide them the chance to back door the root account on reboot and get to your data (since they won't be able to decrypt your geli key to then decrypt your drive).

 

[jvanas]

...
If you want the volumes to come online on reboot, just remove the paraphrase.....

Thank you! I'll try removing the passphrase and post results next time I reboot.

 

[jvanas]

Once I set a paraphrase for the volumes, it required the paraphrase before unlocking.

If you want the volumes to come online on reboot, just remove the paraphrase.

Based on this dialog, should I be setting a recovery key either?

 

[NickB]

Sorry about the delay. I did some testing with this, and it appears that the recovery key is an alternative to using the passphrase when unlocking the volume on boot. So I don't think you would need it. But I would do some testing to make sure it works the way you're using it.

 

[ToBeFrank]

Sorry about the delay. I did some testing with this, and it appears that the recovery key is an alternative to using the passphrase when unlocking the volume on boot. So I don't think you would need it. But I would do some testing to make sure it works the way you're using it.

Always, always, always set a recovery key. It is not an alternative to a passphrase. If your boot drive fails you will lose access to the key to decrypt your drives. If you do not have a recovery key at that point your data is gone.

 

[Bidule0hm]

I agree; in "recovery key" there is "recovery" for a reason

 

[NickB]

Always, always, always set a recovery key. It is not an alternative to a passphrase. If your boot drive fails you will lose access to the key to decrypt your drives. If you do not have a recovery key at that point your data is gone.

I did some more testing, and I believe my original statement is correct. However, I do agree that the recovery key is a good idea and should be created, but not required for a restore onto a new server. I was able to recover encrypted volumes using just the base encryption key and passphrase (if it had one configured) onto a new FreeNAS server that had not seen the volume previously.


Here are the steps I took for peer review.

=====================
Recovery Key Purpose Testing
=====================
***********
Question: When is the FreeNAS recovery key needed?

***********
Hypothesis: Only needed if encryption key and/or paraphrase is lost.

***********
Experiment: Five FreeNAS virtual machines were built using a base 9.3 on ESXi using VM hardware version 8, 1 CPU socket, 1 CPU core, 1 GB memory and 8 GB thick provisioned disk (all of the default options). A new machine was used for each test simulating a restore to a new FreeNAS system (server names: FN1, FN2, FN3, FN4, and FN5).

- Base: Attach 2 virtual drives to FN1 and create an encrypted stipe volume (stripe was picked to ensure both disks were brought in correctly - not suggested unless you know that's what you want). CIFS share was created to copy data to the volume/dataset to ensure the data stays intact. No recovery key or paraphrase was created at this time. The encryption key for the volume was downloaded. The volume was detached and imported to verify that everything works correctly.

- Test 1: Detach volume from FN1 and drives from FN1 VM and attach to FN2 VM and attempt to import using the encryption key only.

- Test 2: Detach volume from FN2 and drives from FN2 VM, attach to FN1 VM (and import using the encryption key). Create a passphrase (which is required on reboot) but no recovery key at this time. Reboot FN1 to ensure the volume is locked and unlock to verify everything is working correctly. Detach volume from FN1 and drives from FN1 VM and attach to FN3 VM. Import with encryption key and passphrase.

- Test 3: Detach volume from FN3 and drives from FN3 VM and attach again to FN1 VM while importing the volume with the key and passphrase. Create a recovery key for the volume. Detach from FN1 and drives from FN1 VM and attach to FN4 VM. Try to import using the encryption key and passphrase (same as Test 2, but to ensure nothing changed with the recovery key creation).

- Test 4: Detach volume from FN4 and drives from FN4 VM and attach to FN5. Attach the disks to FN5 and try the import only using the recovery key.

***********
Analysis:
- Test 1 (FN2): Success. Was able to import the volume using the encryption key.

- Test 2 (FN3): Success. Was able to create the passphrase, reboot, and unlock on FN1. Was able to import onto FN3 with both the encryption key and passphrase.

- Test 3 (FN4): Success. Was able to add a recovery key using FN1. Locked the volume and unlocked as normal (encryption key and passphrase). Attached the drives to FN4 and was able to unlock using the encryption key and passphrase.

- Test 4 (FN5): Success. Was able to unlock using only the recovery key on FN5 (no encryption key or passphrase).

 

[ToBeFrank]

I did some more testing, and I believe my original statement is correct.

If you store the passphrase with your backed up key, then yes, a recovery key is equivalent to a passphrase. If you store the passphrase only in your head, then no, a recovery key is not equivalent to a passphrase. In the latter case, if anything happens to you that causes you to not know the passphrase and you don't have a recovery key, your data is gone if the volume is ever locked.