Encrypt or not Encrypt?

[Erwin]

Hi,
Just setting up a new FreeNAS system, I have some problems in understanding whether or not to use the new disk encryption feature:

Thinking through all the if's and then's I came to the conclusion that this feature just helps when you have to swap disks: In this case you won't need to care about sensitive content, as it is encrypted. You can just send it back to the hd manufacturer e.g. for guarantee replacement without any additional tasks (like wiping out).

In all other cases I cannot see a real added value. The key to mount an encrypted ZFS pool on the attached disks is stored anywhere in the freenas operating system. So when someone has physical access to my FreeNAS box, he has the key already and just needs to boot it. Then it will mount the encrypted ZFS pool with the exiting key without asking about a pass phrase. Ok, to get root access later on should not be a real obstacle. Then he can read all data on the encrypted volume.

So the only way to protect the data would be to run the FreeNAS OS (inlcuding the key) from an USB stick and to remove it as long as you will not use the NAS. But this is not really practable and a bit contradicting to the idea of a NAS. In the moment this encryption feature looks more like a load test of the CPU and a nice opportunity to accidently loose access to your own data when the USB stick fails (and you do not find the passphrase protected copy of your key).

Did I miss something major?


BR
erwin

 

[cyberjock]

It doesn't work like that. If your zpool is encrypted when you bootup the server the zpool isn't mounted. You have to log into the GUI and put in the key+passphrase or the recovery key. Then it mounts. If you reboot it'll be unmounted again until you enter the key+passphrase or the recovery key.

The security does 2 things:

1. If you have to RMA a disk your data is safe.
2. If someone steals your server(or your disks) they'll lose access to the data without your encryption keys because they'll unplug your server to take it away.

The USB stick doesn't store your encryption key at all. You download it from the FreeNAS GUI. Lose your key and lose your data. :P

 

[Erwin]

Hi,
I need to apologize. I just repeated a ZFS volume + dataset setup from scratch and finally it behaves as you described: After reboot, the volume (and the associated CIFS shares are NOT mounted, and after typing in the passphrase in the GUI they are available again. It was a missunderstanding on my side, you are absolutely right. The passphrase is finally the key for disk encryption (and not only a key to open something like a certificate store). So the feature really makes sense to protect the data in the case of hw theft.

Just for info: On my AMD C-60 hw, the encryption reduces read performance by 52% and write performance by 56%, so it will require some more CPU power ;-)

br
erwin

 

[panz]

Or AES-NI enabled CPU :)

 

[wtfuar]

... You have to log into the GUI and put in the key+passphrase or the recovery key. Then it mounts. If you reboot it'll be unmounted again until you enter the key+passphrase or the recovery key.
...

To mount an geli encrypted pool that was previously created on the same freenas installation you just need the passphrase or recovery-key. You will need the key+passphrase if you import an zfspool.

Anyway there seems to be a bug with encrypted drives that I struggle with.

You always have to auto-import with passphrase+key if the zfs pool was not initially created on your freenas installation.
I think it requires editing of the freenas-v1.db with sqlite. But this is somewhat dangerous and possibly hazardous so I would await a patch from iXsystem for that.

Just keep that in mind if you wanna use the geli encryption feature with freenas.

 

[panz]

Anyway there seems to be a bug with encrypted drives that I struggle with.

You always have to auto-import with passphrase+key if the zfs pool was not initially created on your freenas installation.
.

This is how GELI works. I successfully imported a FreeNAS-created encrypted pool in FreeBSD; you have to:

Code:

attach -k recovery_key

then it asks for disk's password and you're done.

 

[wtfuar]

@panz, the point is, you have to do it every time you restart freenas. On the tab 'storage' is the already per auto-import imported zfs pool but you can't mount it by just click the 'Unlock' button when the pool wasn't initialy created on that very freenas installation.

Freenas does not fail to auto-import, it fails to 'Unlock'.

Just try it and create a new freenas image on an usb-stick if you got a spare and do the auto-import.
Then restart freenas and try to 'Unlock' the pool by just providing the passphrase.

You will get the error: freenas manage.py: [middleware.notifier:1200] Failed to geli attach gptid/...: geli: Wrong key for gptid/....

Now you have to detach the Locked pool and do the auto-import again.

All I mentioned above is done by the GUI.

 

[panz]

I think that, after having first imported your "previous" pool, you have to regenerate the (rectius: generate a new) encryption key for that imported pool.

 

[wtfuar]

I'll try this on a vm testsample and see if that is the way to go.

 

[wtfuar]

I think that, after having first imported your "previous" pool, you have to regenerate the (rectius: generate a new) encryption key for that imported pool.

You could try to detach the volume, reboot and auto-import again.
If auto-import works then rekey the volume right after.

This solved the "problem"

 

[panz]

Update: just playing with encryption, ZFS and replacing an hard drive.

Situation: ZFS mirror (2 disks), on top of GELI. As usual the right sequence is:
1) change passphrase;
2) create and download a new recovery key;
3) download encryption key.

Now the replacing failed disk part:
1) shutdown the system;
2) disconnect HD n.1 (this simulates hardware failure);
3) reboot FreeNAS.

Now the pool status is degraded, so we add a new (and different disk) to the pool and commit resilvering:
1) replace disk;
2) check if finally the status is "Healthy" (OK);
3) reboot.

Now the fun part: after rebooting the pool unlocks correctly only if I use the passphrase.
If I use the Recovery Key the pool is ALWAYS degraded.

So, the solution is: re-key the pool and generate a new Recovery Key. After that, at next reboot, I can unlock the pool either by passphrase or by the newly generated Recovery key.

I think this procedure should the described in the documentation.

 

[cyberjock]

Yeah, I found this issue in May. See ticket 2178 to see the long discussion there. The short is that the issue should be fixed in FreeNAS 9. Personally, I think a public service announcement should have gone out over this issue. You and I appear to have been pretty vigilant at checking that everything is in good working order with replacing a hard drive in an encrypted zpool. I just wonder how many other people don't know and will figure it out the hard way later.

 

[panz]

I've just found another "issue": FreeNAS GUI doesn't offer an option to backup provider's metadata (those we backup via "geli backup /dev/somedrive /mnt/somewheresafe/somedrive.eli and /var/backups/somedrive.eli).

I tried to:
# clear -v da0p2
and
# clear -v da1p2
on my ZFS GELI encrypted test machine and, obviously, then, I couldn't attach the drives via GUI (notification area says "cannot read metadata...").

Fortunately, I had:

# geli backup da0p2 /mnt/usb/da0p2.eli
and
# geli backup da1p2 /mnt/usb/da1p2.eli
:)

 

[cyberjock]

Put in a ticket at support.freenas.org :)

 

[panz]

Done ;)

https://support.freenas.org/ticket/2375#ticket