How to set up data encryption the most secure way

gegtor

Explorer
Joined
Sep 16, 2017
Messages
99
Hello

I'm managing a TrueNAS Core install for a small business that has a high risk of the system being stolen

There are confidential files on the system with no way to keep the system off site

How do I set up disk encryption that way so when the system is unplugged from power there is no way of unlocking the pools without the encryption key that will be kept on a secure flash drive in a secure location?

From what I know the keys are kept on the system somewhere?

I'm planning on using the ZFS Native encryption

Also what encryption cipher is the safest to use and is it possible to decrypt the data with current tech?

Thank you!
 

artlessknave

Wizard
Joined
Oct 29, 2016
Messages
1,506
you can set it to not store the keys locally, requiring manual entry of keys/phrase on every import of the pool (or dataset in 12 afaik).
I don't, however, know how to do that, as I have been waiting for 12 to every try encryption (didnt like GELI, seemed like a janky hack)
 

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,703
Also what encryption cipher is the safest to use and is it possible to decrypt the data with current tech?
AES 256-CGM would take trillions of years to brute-force with current tech.

If you use the Passphrase Encryption Type, you should be able to have datasets locked until the passphrase is entered on boot (although you'll need to do your own testing to satisfy yourself of that and will need to implement operational procedure to make sure any reboot is followed with the unlock),

If you use the Key encryption type, the key is stored and the unlock status survives a reboot, so not what you want.

I would suggest using a very long and complex passphrase, so I suppose you could store that somewhere (ideally in a password manager) separate from the server, but it won't be something that you can just keep on a USB and plug it in to unlock the dataset(s).

I'm not convinced that the approach is wise in general if you're essentially planning to have your server stolen... but I guess real-world happens.
 

gegtor

Explorer
Joined
Sep 16, 2017
Messages
99
AES 256-CGM would take trillions of years to brute-force with current tech.

If you use the Passphrase Encryption Type, you should be able to have datasets locked until the passphrase is entered on boot (although you'll need to do your own testing to satisfy yourself of that and will need to implement operational procedure to make sure any reboot is followed with the unlock),

If you use the Key encryption type, the key is stored and the unlock status survives a reboot, so not what you want.

I would suggest using a very long and complex passphrase, so I suppose you could store that somewhere (ideally in a password manager) separate from the server, but it won't be something that you can just keep on a USB and plug it in to unlock the dataset(s).

I'm not convinced that the approach is wise in general if you're essentially planning to have your server stolen... but I guess real-world happens.
So what you are saying is there is no point to keeping the encryption key off the server and just use a very strong passphrase with the key?

The key would be useless without the passphrase right?

This is exactly how I have it implemented right now but with the old geli encryption

I have the passphrase somewhere offline and I'm just worried that the keys are on the machine
 

sretalla

Powered by Neutrality
Moderator
Joined
Jan 1, 2016
Messages
9,703
The key would be useless without the passphrase right?
Yes, without the passphrase, the keys can't be used... if you use the other encryption type, the keys are in the open and unlocked pools/datasets stay so after a reboot.
 

no_connection

Patron
Joined
Dec 15, 2013
Messages
480
Question you should be asking is, are you worried some random going to steal the system and happen to find files and try to use them.
Or are you worried someone is going to attack just to get the files.

Just throwing encryption at the problem isn't really security in the same way RAID isn't backup.
 
Top