Why do you need a passphrase set to replace an encrypted disk?

[virtualdxs]

Why do you need a passphrase set to replace an encrypted disk? Shouldn't the keys be on the boot media and not need any special procedures?

 

[Chris Moore]

Why do you need a passphrase set to replace an encrypted disk? Shouldn't the keys be on the boot media and not need any special procedures?

No. The whole reason for encrypting your disks is to prevent anyone else from accessing your pool. The keys are not supposed to be stored. You should need to enter them every time you boot the system before you can access the encrypted pool. The system should ask you for the credentials often to ensure some unauthorized person is not in possession of your system.

 

[Apollo]

Hi Chris Moore, I hate when the post refers to the title and an answer is requested. It just gets lost.

 

[virtualdxs]

No. The whole reason for encrypting your disks is to prevent anyone else from accessing your pool. The keys are not supposed to be stored. You should need to enter them every time you boot the system before you can access the encrypted pool. The system should ask you for the credentials often to ensure some unauthorized person is not in possession of your system.

Not in all cases. Our main reason is to make drive disposal easier. And I know for a fact that the key is stored somewhere non-volatile, as rebooting the system does not require a password to be entered. So why is that storage location not sufficient?

 

[Chris Moore]

Our main reason is to make drive disposal easier.

That is a reason for encrypting, but it doesn't change how the technology works.

I know for a fact that the key is stored somewhere non-volatile, as rebooting the system does not require a password to be entered.

It is supposed to ask, every time, it it doesn't I would say you have it configured wrong.

So why is that storage location not sufficient?

Because that is how it is made. It is supposed to be re-keyed when a disk is replaced. Do it differently than it is intended to work and your data is at risk. Also, the replaced disk might not get encrypted if you don't re-key the pool after a disk replace.

 

[virtualdxs]

The combination of encryption key location and whether a passphrase is used provide several different security scenarios:

• Key stored locally, no passphrase: the encrypted pool is decrypted and accessible when the system running. Protects “data at rest” only.
• Key stored locally, with passphrase: the encrypted pool is not accessible until the passphrase is entered by the FreeNAS® administrator.
• Key not stored locally: the encrypted pool is not accessible until the FreeNAS® administrator provides the key. If a passphrase is set on the key, it must also be entered before the encrypted pool can be accessed (two factor authentication).

From the manual, bold emphasis mine.

 

[Chris Moore]

So you setup your system with no passphrase. Good luck.

 

[Apollo]

So you setup your system with no passphrase. Good luck.

I don't understand your behavior/reaction.

If I understood the post title correctly, the question is why the "Passphrase" has to exist so that the replacement of a disk ( in the event of a faulty disk replacement for example) can be successful and accept the Rekey process.

There are two ways encrypted pools can exist:

1) "Passphrase" is present and the pool will require unlocking after every reboot. All services related to the use of this pool will need to be restarted to be able to manage the open pool. This gets compounded if you have more than one encrypted pool on your system.
It can take a long time for decrypting the pool and have the service restarted.
This is the most secured and least flexible solution.

2)"Passphrase" is not present and as a result rekeying may not necessarily work ( I have alsways been having some doubts about the veracity of this information from my own experience, but it might have been contributed to bug related migration).
Rebooting the system is much quicker as the contnent of the pool is made available at boot-up.
Content of the pool can be accessed if the Freenas boot disk is stolen with the pool.
On the other hand, once the Freenas boot disk is not with the pool or the geli.hey not available, when system is off, the content of the pool will be mostly inaccessible.

Both scenario have advantage and disadvantage, yet both have valid arguments.
Yet, the encryption mechanism being so unforgiving, there is little hard evidence in how the process flow really works (outside of the encryption in itself).

A flowchart or state machine representation depicting the process would be a very good thing to have.

 

[Chris Moore]

I don't understand your behavior/reaction.

I have used encryption with a passphrase, so I have a small amount of experience with that, but I don't have any information with regard to a system with no passphrase, as I have never done that. I don't want to give bad or incorrect information, so I stop.

 

[Apollo]

Ok, make sense.
With your "Good luck" in the post, I was just under the impression you were telling the OP what he was doing was wrong and he would be on his own as a result.
My misunderstanding.

 

[i716]

>> The whole reason for encrypting your disks is to prevent anyone else from accessing your pool. The keys are not supposed to be stored. You should need to enter them every time you boot the system <<

This is exactly what FDE on Linux or BSD does when the drive is encrypted with either LUKS or Geli. And you are right, that's the way it should be done. However, and I have asked that question here a few days ago, FreeNAS does not ask for a passphrase at boot. And that is currently the only reason for me to not use it.
I know that I can encrypt pools and put a passphrase on top. Unfortunately that does not work for the first pool which by default holds the system dataset. So I can only choose between not having a passphrase or put the system dataset on the boot drive - both very bad ideas and a design fault in my eyes.