Looking for encrypted pool security mechanism

[Apollo]

I am looking at encrypting my pool on my current system. I have conducted some testing on my backup system, but I am wondering what mechanism is at play when it comes to accessing an encrypted pool by someone who is not authorized to do so, given it may have access to the system (I am considering the case when someone breaks in and want to gain access to the system).

The Freenas documentation doesn't provide a detail explanation on the system behavior in preventing access to the encrypted pool.

During my testing, I found the pool will be locked upon restart, which is good if the system is stolen and power has powered down.
My concern lies in the other scenario when the system remain live.
What happens when the system is not powered down. Can the drive be accessed after default CLI/web interface password has been reset.
Can someone be able to download the encryption key from the encrypted pool as well as the recovery key?

Is there a detailed flow chart or similar diagram explaining what steps Freenas takes in order to maintain a secured system?
Will the pool lock itself if the system password is reset from the CLI console?
I haven't had the time to test that scenario yet.

 

[joeschmuck]

I'm not an encryption expert but I'll answer what I can.

While the system is in operation the drives are accessible. Encryption doesn't protect your data once the system is running, it protects your data if someone steals your FreeNAS system and then tries to plug it in and stops them because they don't have the encryption key to unlock the drives.

The key cannot be extracted from the hard drives. If you forget the key, your data is gone.

The system password is not drive encryption.

Before you encrypt your pool you need to be certain you fully understand how to use your system and what data you need to replace a failed/failing drive. I strongly recommend that you setup a Virtual Machine (like VMWare Player) and create a FreeNAS VM with several VM hard drives and then encrypt them, replace the drives int he VM world as well. Test it out and understand it before pulling that trigger. Take a lot of good notes because you will come to the point where a hard drive needs to be replaced and if you don't know what you are doing, well your data will be at risk while you pull your hair out trying to figure out what to do.

 

[Apollo]

I have been trying to get familiar with the process using spare drives and using replication to populate the test pool.
The process went smoothly.
I agree that on a live system, weeks or month down the road, when something goes wrong, the process could get tricky with messy results.

Last night, I was able to experiment to answer my concern related to CLI console access.
It turns out, that indeed, if someone is familiar with Freenas, and get access to the system while under power, resetting the password then accessing to Freenas with the GUI, then it is possible to download the Geli encryption key, the recovery key or simply replace or remove the passphrase.
In a nutshell, it is possible to gain access to the pool even after the system has been power cycled.

Getting familiar with the process of failing one disk and have it replaced requires to know which course has to be taken concerning encryption safeguarding.

As I was experimenting, I found the process to be inadequate, int the sense that there are no safeguard of feedback from the system to keep track of the safeguarding of the encryption files and passphrase.
What I mean by that is that it would be good to have some summary about the status of the encryption such as follow:

- Date and time when passphrase, rekey, download of recovery key are updated.
- A mean to see if the recovery key has been successfuly downloaded after any action that will require a new recovery key.
- A mean to validate if a key or the Geli encryption is a match with the downloaded files.

As I was replacing a drive, I was asked to enter the passphrase twice. This one got me confused, because it sounded like a new passphrase was required erasing the one already in place. It turns out I still need the original passphrase, but then why asking confirmation of the passphrase in this case/

I wish, a diagram or a checklist already existed showing the steps to do and the one to avoid.
Is there a way to prevent some of these action to be active after a password reset?
I would think ideally, only "lock", should be the only valid action available at this time. One extra step to help safeguard the system.