GELI Encryption of pool (volume) - Why passphrase was removed

[onlineforums]

I realize in release TrueNAS 12 there will be ZFS dataset encryption ability. For now, though, I'm wildly confused as to the history and reasoning as to why, as the latest FreeNAS 11.3 there isn't passphrase combination with key for GELI whole pool (volume) encryption?

In the recent past (within the last few years release) when encrypting a volume it would ask for a passphrase to use. When the FreeNAS box would start, the pool would be locked and encrypted until someone went into the webUI and put in the passphrase.

I'm doing some testing right now on 11.3 and there is no ability to put in a passphrase. You simply get to download a key which is stored on disk anyway so if someone got physical access to the FreeNAS box itself then the data isn't encrypted. It seems like the only purpose this serves currently is if an intruder only has access to the hard drive(s) and not the FreeNAS box itself.

I greatly look forward to TrueNAS 12 with dataset encryption but still would love to know the history, reasoning, logic, etc as to why passphrase aspect of the GELI encryption process was removed. Were there major bugs associated? Were too many people not understanding the process to rekey/repassphrase during resilvering in a bad HDD situation?

It seems like the reward is no longer there for whole pool encryption using only GELI key. If the only thing I am protecting by doing a whole pool GELI encryption is the physical hard disks being stolen themselves then I can resolve that with proper physical security measurements. I also will properly destroy a hard disk, irrespective if it was encrypted, if a disk fails. So is there absolutely no benefit to whole volume encryption if physical security isn't a concern?

 

[Samuel Tai]

This is in the Known Impacts section of the Release Notes at https://www.ixsystems.com/blog/library/freenas-11-3-release/.

The system no longer allows moving the system dataset to an encrypted pool containing a passphrase. Since Directory Services and some SMB state information is stored in the system dataset, these services will not function correctly if the system dataset is locked or otherwise unavailable. It is recommended to move the system dataset to a non-encrypted pool or an encrypted pool not containing a passphrase.​

Only the pool holding the system dataset no longer accepts a passphrase, probably for better compatibility with Active Directory in corporate environments. All other pools still do.

 

[onlineforums]

Where is the GELI key located? Is a solution potentially to simply remove it off of the machine and only load it in at time of unlocking an encrypted pool?

When rebooting the machine in 11.3 it doesn't require unlocking the pool as it comes online unlocked. Thus, the key must be on the machine somewhere which defeats a significant portion of the purpose of encryption.

Is my understanding that the only thing that this prevents is theft of hard drive(s)? Or in cases where a hard drive fails, a user can remove that hard drive and RMA it without concern over contents of the disk?

As long as physical security is in place, is there any advantage to encrypting pool without passphrase?

 

[Samuel Tai]

GELI keys are in /data/geli. However, I don't believe it's feasible to remove the keys from this directory and reinsert them on boot, because the system reads them well before displaying the console menu.

You're correct that in previous versions, it was possible to boot up with the pool in a locked state, requiring an admin to login and unlock the pool with a passphrase or recovery key to finalize the startup. This has both security and operational impacts. If the server was stolen, or seized per warrant, then the server needed manual intervention to unlock the pool. However, this also increases the risk of the pool failing to unlock if the administrator forgets the passphrase or loses the recovery key.

In 11.3, the system dataset pool now unlocks automatically using the stored GELI keys. This reduces the risk of the system being inaccessible due to a lost passphrase or recovery key, but increases the risk of third parties reading the data when the server is stolen or seized per warrant. As GELI has proved rather fragile in operation over several versions of FreeNAS, this is a reasonable first step to take to deprecate GELI in favor of native ZFS dataset encryption in 12.

GELI still has value for preventing data recovery when disposing of individual disks.

The balance of risks has shifted, and focusing solely on the risk with a change in encryption profile is too narrowly focused. You have to consider the entire spectrum of risks.

 

[onlineforums]

@Samuel Tai
Thank you for your response. What you mentioned is my understanding and you confirmed it.

I suspect that in version 12 that we'll be able to take a pre-existing dataset and apply ZFS dataset encryption to it. That is probably the best bet for new deployments of FreeNAS right now: don't use GELI and just wait to encrypt appropriate datasets on the dataset level using ZFS.