Dataset encryption

gary_1

Explorer
Joined
Sep 26, 2017
Messages
78
There are two encryption types you can select: key or passphrase. If you select key, the encryption key is stored on the boot drive, the dataset will automatically unlock on boot, and you can't manually lock the dataset. In contrast, a passphrase is not stored and you can lock/unlock the dataset at will.

The important part is, does an unlocked dataset that you used a password on survive a reboot as was suggested in earlier posts? If it does, then that that implies the key used for dataset encryption is been written decrypted to disk in order to survive reboot and be used.

I assume when using a password that it really unlocks a stored key rather than using key derivation, since you'd want to be able to change passwords in the future without re-encrypting data. So, where is that encrypted key stored? As part of the pool or also on the boot drive?
 

Constantin

Vampire Pig
Joined
May 19, 2017
Messages
1,828
I like the current approach as of FreeNAS 11.x where a reboot / shutdown results in a encrypted dataset with a passphrase to be locked by default on restart. The admin then has to unlock the share manually. That solves the most urgent theft-related issue for me. I know that having encryption turned on may result in other issues but I'm OK with the tradeoffs (encrypted backups!).

The most glaring issue with the server re: security is that anyone with physical access can become root (via root password reset followed by shell access), etc. However, since I'm not a nation-state target, I'll focus on the dope-addicts stealing assets for resale rather than folk trying to infect / penetrate / whatever my little server by doing a sneaky break-in. Pool encryption addresses that problem nicely. The inconvenience on reboot is trivial, we don't reboot without a good reason, eh? :smile:
 
Joined
Dec 2, 2015
Messages
730
I like the current approach as of FreeNAS 11.x where a reboot / shutdown results in a encrypted dataset with a passphrase to be locked by default on restart. The admin then has to unlock the share manually. That solves the most urgent theft-related issue for me. I know that having encryption turned on may result in other issues but I'm OK with the tradeoffs (encrypted backups!).

The most glaring issue with the server re: security is that anyone with physical access can become root (via root password reset followed by shell access), etc. However, since I'm not a nation-state target, I'll focus on the dope-addicts stealing assets for resale rather than folk trying to infect / penetrate / whatever my little server by doing a sneaky break-in. Pool encryption addresses that problem nicely. The inconvenience on reboot is trivial, we don't reboot without a good reason, eh? :smile:
I fully agree that a need to enter a passphrase on boot is a trivial inconvenience.

The move to encrypted datasets from encrypted pools is a big step forward though, as only some of my data really needs to be encrypted. My most sensitive data probably only needs to be rarely accessed, so it could be locked most of the time.
 

Constantin

Vampire Pig
Joined
May 19, 2017
Messages
1,828
Everyone has a different use case.

I use GELI for at-rest protection. Nothing stops anyone from using further encryption for sensitive assets inside the pool... :smile:
 

EtienneB

Explorer
Joined
Feb 19, 2018
Messages
78
I think I am going to like the dataset encryption a lot.
I prefer that it locks the system when shutdown / rebooted.
Also I would like to unlock a bunch of shares at once (assuming multiple datasets have the same password).

For unlocking, it would be nice to be able to unlock the dataset with a password given when I try to connect to it via an SMB connection. In that case I don't need to login to the TrueNAS UI but can do it when my laptop connects to it. (Perhaps even lock it when you disconnect from the share?). Using some sort of user / share password perhaps? If that is technically feasible at all.
 

Constantin

Vampire Pig
Joined
May 19, 2017
Messages
1,828
Being able to lock datasets individually is certainly an upgrade, especially since it could allow servers to come up with a minimum functionality by default while keeping more sensitive assets under lock and key. For example, in the home context you may not consider your music collection as sensitive as documents, so a power outage doesn't necessitate logging into the server to make your player happy again. Other data sets can be kept secure except on a as-needed basis, i.e. documents.

I disagree re: auto-unlocking as long as the right users is doing the logging in via SMB. The web interface makes the whole process so easy, I'd much prefer the current approach to the potential of unintentionally creating new security risks. A better approach to keep data secure yet easily accessible is likely something like an encrypted sparsebundle on the Mac where your keychain can auto-unlock and mount the contents once you've connected to the unencrypted share. It's literally a one-click solution that is built into the OS, proven, etc.

I hope we get to keep pool-level encryption in addition to dataset-level encryption, as the pool-level encryption gives me the at-rest protection I want to deal with theft. Pool-level encryption also allows all datasets in that pool to become available at once. However, datasets can also be organized in a way to allow multiple sub-directories to be shared separately, yet one password can unlock the whole data set (and by definition the data hosted by those sub-directories) all at once. Thus, I can see why dataset-level encryption is preferable - far more flexibility.
 

EtienneB

Explorer
Joined
Feb 19, 2018
Messages
78
I disagree re: auto-unlocking as long as the right users is doing the logging in via SMB. The web interface makes the whole process so easy, I'd much prefer the current approach to the potential of unintentionally creating new security risks. A better approach to keep data secure yet easily accessible is likely something like an encrypted sparsebundle on the Mac where your keychain can auto-unlock and mount the contents once you've connected to the unencrypted share. It's literally a one-click solution that is built into the OS, proven, etc.

I hope we get to keep pool-level encryption in addition to dataset-level encryption, as the pool-level encryption gives me the at-rest protection I want to deal with theft. Pool-level encryption also allows all datasets in that pool to become available at once. However, datasets can also be organized in a way to allow multiple sub-directories to be shared separately, yet one password can unlock the whole data set (and by definition the data hosted by those sub-directories) all at once. Thus, I can see why dataset-level encryption is preferable - far more flexibility.

The Sparsebundle is indeed a nice solution for the automatic security. Will look into that.

Pool level security or some switch for dataset lock for theft protection (power off) would be nice.
 

Constantin

Vampire Pig
Joined
May 19, 2017
Messages
1,828
Pool level security exists today though with caveats. The pool has to be created with encryption set on, it is not something that can be added later.

Many demi-gods here don't like it. For example, @Heracles put together a long, thoughtful post on the subject. There are more threads, I'd consume them and then make up your mind how you'd like to organize your pool / NAS.

I use pool encryption for the benefit of at-rest protection, particularly in combination with a secured console login. But once physical access has obtained to a running NAS, data-set protection is realistically nigh-impossible to maintain. Even the chassis intrusion detecting switch only goes so far when you consider that a keylogger in the console keyboard can compromise the keys to the kingdom. Makes you wonder... are folk allowed to bring their own keyboards into a shared data center?

Anyhow, one way to help mitigate the risks of physical NAS compromise could be the encrypted sparsebundle approach, i.e. don't rely on the NAS to maintain security for sensitive stuff.
 
Last edited:

stillka

Explorer
Joined
Nov 15, 2014
Messages
55
Hello, can some IT experts decrypt my pool in worst case? Some cryptography specialists....its "enterprise" safe?
 

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,702
The truthful answer is yes, but the important question is how long will it take.

With conventional computers (all that's available right now), it's likely to take many years to break the encryption. As soon as quantum computing is available, that becomes minutes.

For now, the encryption technology included is considered safe for enterprise data.
 
Top