Is TrueNAS encryption safe against physical attacks?

[Vallevert]

Hi there,

I recently started encrypting the data on my NAS and I have some questions about the security of this system:

1) Does the fact of having encrypted my data make it unreadable for a person who has physical access to the NAS.
For example, if my Mac is stolen, I know that it is not possible for the thief to read the data on it, because the SSD is encrypted and there is no way to access the content without my password.
With TrueNAS (if I understood correctly), you just have to "Reset Root Password" on the console, and the Web GUI is accessible to anyone. Is this correct? Can TrueNAS protect my data from the police force for example?

2) I use the "Key" method to encrypt my data [see image]. I have downloaded all my keys on my Mac just in case, to have a backup. Did I do it right? Do you have any suggestions?

3) Personally, for completely random reasons, "Boot-pool" has already died twice. That means I had to reinstall TrueNAS from scratch on my "Boot-pool" disk. Now that my Pools are encrypted, what would happen if "Boot-pool" dies knowing that it contains the encryption keys?

Thank you for your answers and your time.

 

[Kris Heslop]

I thought I had seen this answered before, but looking at a related search I did not see an answer and understand your desire.

My understanding is that:

(1) if someone physically gets your disks, without the full pool's disks [(less the parity data disk(s)] and the encryption code to use on a TrueNAS server, the disk contents are gibberish and useless to them.
(2) You may be understating the minimal risk of someone gaining your Macbook password. The strength of your password would have a large impact on this area.
(3) If a person has physical or electronic access to the file system including password access they could be able to access the files post decryption. (This is like anyone that gets inside a bank's inner cash vaults without supervision could take the money without force because they are inside the protection.)
(4) The encryption would protect against someone copying the encrypted files off of a server and attempting to access them through a (decryption/TrueNAS system) without the keys. (I have read several reports of data breaches where they get "in" but are not able to access because they are not inside the encrypted area and the files are useless to them.)
(5) Keeping up robust password protocols and periodic changes can significantly reduce these risks since most data exposures are due to password hacking risks or phishing exposing a password.

My thoughts above are not expert, but just what I have picked up from some of the software projects I have helped on.

 

[winnielinnie]

If they have physical access while the system is powered on and the dataset(s) is unlocked, then you're likely hedging on the strength of your root/user password. (But that's not to say they cannot circumvent this.)

If you system is powered off and/or your dataset(s) is locked, then your data is inaccessible if you're using a passphrase instead of a keyfile.

If you're using a keyfile, you might not be out of the woods, since by default TrueNAS stores the keyfile on the boot device, in the plain. (This is by-design for TrueNAS, and not inherit with ZFS.)

 

[superboringdev]

If they have physical access while the system is powered on and the dataset(s) is unlocked, then you're likely hedging on the strength of your root/user password. (But that's not to say they cannot circumvent this.)

If you system is powered off and/or your dataset(s) is locked, then your data is inaccessible if you're using a passphrase instead of a keyfile.

If you're using a keyfile, you might not be out of the woods, since by default TrueNAS stores the keyfile on the boot device, in the plain. (This is by-design for TrueNAS, and not inherit with ZFS.)

I understand that "by default TrueNAS stores the keyfile on the boot device" but how can I change this behavior? I'd like to store my key on a different drive than the boot drive so that I can use it instead of a passphrase and destroy the key if deemed necessary.

 

[winnielinnie]

I'd like to store my key on a different drive than the boot drive so that I can use it instead of a passphrase and destroy the key if deemed necessary.

To put it simply, you can't do that with TrueNAS (which is an appliance).

TrueNAS was designed to automatically unlock encrypted datasets at boot time. This allows the System Dataset and iocage dataset to be immediately available. On SCALE, ix-applications dataset is unencrypted, so it's a moot point (ever since recent updates to SCALE).


iXsystems does not want a user to break their system by creating a situation where the System Dataset, iocage dataset, and/or ix-applications dataset are unavailable if encryption is being used.

This is why you're left with three restrictions:

• If the top-level root dataset is encrypted, it cannot be with a passphrase; only with a key
• The key ("keyfile / string") must be available at bootup; hence, it is stored on the boot device, in the plain
• Going forwards, new versions of TrueNAS won't even allow you to use encryption above unencrypted datasets in the hierarchy

If you're thinking of a custom layout/setup where the above concerns are no longer issues, then good luck submitting a feature request. It's very unlikely to be accepted.

 

[superboringdev]

To put it simply, you can't do that with TrueNAS (which is an appliance).

TrueNAS was designed to automatically unlock encrypted datasets at boot time. This allows the System Dataset and iocage dataset to be immediately available. On SCALE, ix-applications dataset is unencrypted, so it's moot point. (Since recent updates to SCALE.)


iXsystems does not want a user to break their system by creating a situation where the System Dataset, iocage dataset, and/or ix-applications dataset are unavailable if encryption is being used.

This is why you're left with three restrictions:

• If the top-level root dataset is encrypted, it cannot be with a passphrase; only with a key
• The key ("keyfile / string") must be available at bootup; hence, it is stored on the boot device, in the plain
• Going forwards, new versions of TrueNAS won't even allow you to use encryption above unencrypted datasets in the hierarchy

If you're thinking of a custom layout/setup where the above concerns are no longer issues, then good luck submitting a feature request. It's very unlike to be accepted.

Thanks for the explanation.
Am I understanding correctly that there is no way to store the key to a non-system dataset on a different drive?
If I have two separate pools, it's impossible to store the encryption key of a dataset inside second pool (that doesn't contain a system dataset) on a usb drive or third disk?

 

[winnielinnie]

Am I understanding correctly that there is no way to store the key to a non-system dataset on a different drive?

If I have two separate pools, it's impossible to store the encryption key of a dataset inside second pool (that doesn't contain a system dataset) on a usb drive or third disk?

It's very much possible to do so manually. But then you risk breaking your TrueNAS system, and it veers way off the trail to get any support when something goes wrong.

The "limitations" and "restrictions" of TrueNAS are specific to TrueNAS, and by design.

Pure ZFS + FreeBSD / Linux do not have these restrictions. But then you're on your own to configure everything manually, which defeats the purpose of using an appliance (TrueNAS) that already built a solution for you.

 

[superboringdev]

It's very much possible to do so manually. But then you risk breaking your TrueNAS system, and it veers way off the trail to get any support when something goes wrong.

The "limitations" and "restrictions" of TrueNAS are specific to TrueNAS, and by design.

Pure ZFS + FreeBSD / Linux do not have these restrictions. But then you're on your own to configure everything manually, which defeats the purpose of using an appliance (TrueNAS) that already built a solution for you.

I understand, thanks.

I would have liked the possibility to use an "external key" instead of key or passphrase so I can just plug in the drive containing the key and have the dataset unlocked.

I will just use a passphrase for those datasets I lwant to protect and the other ones are going to use a key. I don't want to do anything manually that could break the system in the future so I'm just going to accept the design.

 

[Arwen]

Back in 2017, (I think it was then), I suggested the ability to use a USB flash drive as the encryption key to the OpenZFS team working on native encryption. But, it was beyond the scope of those early days. And it could still have been implemented with boot time scripts, external to the OpenZFS project.

As you describe, it makes a neat solution. As long as the USB key is plugged in at boot, the dataset(s) get de-crypted and mounted. After that happens, you could remove the USB key and lock it away. Any theft of the hardware that does not include the USB key, would still protect those dataset(s).

 

[Patrick M. Hausen]

Now imagine we could use e.g. a Yubikey to store the encryption keys so you would need to physically touch it to unlock it with your finger print ...

 

[superboringdev]

As you describe, it makes a neat solution. As long as the USB key is plugged in at boot, the dataset(s) get de-crypted and mounted. After that happens, you could remove the USB key and lock it away. Any theft of the hardware that does not include the USB key, would still protect those dataset(s).

Exactly what I thought.

Now imagine we could use e.g. a Yubikey to store the encryption keys so you would need to physically touch it to unlock it with your finger print ...

This would be really neat, too!