Alllowing encrypting all datasets, including system ones using a passphrase and improve the security of key files

Feature Requests
1

Problem/Justification
Any pool, including where the system dataset is, should be allowed to be encrypted, using a passphrase. Right now the only way to encrypt the pool where the system dataset is stored is by using key files.

I tried poking around a bit but couldn’t determine if the key files are encrypted and protected by a users password or not. Based on the way auto mounting is described it seems like its not and the keys are just in plain text on the drive.

Right now if you encrypt your pool with key files, its like you have a safe with the keys just laying on the top. It doesn’t really offer you much security. As currently, it looks like key files for encryption are stored in plain text on the disk(s).

Using a passphrase solves this issue as its not stored anywhere but memory, once the computer is turned off, loses power the key is gone. Now you could store key files in memory as well which would allow you to have the same or greater security as a passphrase depending on how the key in the file is generated.

So, this begs the questions why are key files stored on the disk in the first place? The answer to that is auto unlocking. With the keys only being stored in memory any time the computer restarts the key needs to be reentered. Auto unlocking will always be more insecure then entering a key on boot. However, with that being said the current way of storing key files is not the correct way of doing it. The proper way of implementing auto unlock is by storing the keys in a secure element. Pretty much all modern computers have this, on most PCs its referred to as the TPM.

Why is storing the keys in the TPM ok but not on the disk ? TPMs are specifically designed to store keys, hard drives are not. While it is possible to extract the keys from either it is harder to extract keys from a TPM. If you want to be as secure as possible a key entered at boot is the way to go.

Wouldn’t that mean, I cant move to a new pool or I can no longer mount my drives outside the system containing the TPM? No, when setting up encryption you would be given a key to keep safe. This key will allow you to move / mount your drives out side the system where it was initially setup. Lose the key though and your out of luck.

Why is a passphrase still needed?
Despite pretty much all modern computers coming with a TPM. Some older computers don’t have one but more importantly is that storing the key on a TPM is a lot less secure then the passphrase entered on boot. [1][2]

What about self encrypting drives? These work a lot like the TPM does so its better then key files but in the end you need to trust the vender to implement stuff properly. Additionally like TPM depending on the implementation you can extract the keys from SEDs. [3][4][5]

One reason Opensource is more secure is anyone can audit the implementation. You don’t get that choice with TPMs or SEDs so your completely depending on the people making them knowing what their doing. Even then mistakes happen. See footnotes.

Impact
Implementing these changes would result in better security with minimal downsides to the user.

User Story

My thought on implementing, would be to implement this in a way that you can still unlock the drives using the TrueNas WebUI.

If the user enables passphrase encryption on the root dataset, here is how I envision this working.

The boot drive should only contain the OS and no other information, with some exceptions see below. the ix-apps, system, etc… datasets should be stored in a dataset that is encrypted.

This way the OS and the TrueNas web UI can start and prompt the user for the password to unlock the drives. For user accounts passwords should be stored using a strong hashing algorithm like Argon2ID. These can be placed on the boot drive since they’re hashed. Ideally you would store them encrypted not on the boot drive but this complicates implementation if you want the user to be logged in before entering the password to decrypt the drives. You could also, on top of strongly hashing the passwords, encrypt them with the TPM.

If you don’t care about having the user be logged in first then just make unlocking the drives a prompt before any users sign in.

As for TPM replacing the current implementation of key files, this wouldn’t really wouldn’t be a visible change as it would work pretty much the same as key files just more secure. You could / should also tie in user passwords with the TPM for better security then the TPM alone.

  1. Forensic method for decrypting TPM-protected BitLocker volumes using Intel DCI - ScienceDirect ↩︎

  2. Extracting BitLocker keys from a TPM ↩︎

  3. Flaws in self-encrypting SSDs let attackers bypass disk encryption | ZDNET ↩︎

  4. VU#395981 - Self-encrypting hard drives do not adequately protect data ↩︎

  5. Self-Encrypting Deception: Weaknesses in the Encryption of Solid State Drives | IEEE Conference Publication | IEEE Xplore ↩︎

1 Like
2

Indeed. If an attacker gets access to the system, they can access everything.

Personally, I am of the opinion that an encryption scheme where both the encrypted data and the keys to access that data are on the same system isn’t encryption, but rather security theater.

1 Like
3

I am also interested in this topic. I come from openmediavault where I use luks to encrypt my system which is auto unlocked by usb drive. Till now I havent seen a default solution with native zfs encryption on boot-pool. The only solution I know so far is to use zfs on luks.

4

Auto unlock is insecure no matter what. If your only concerned about someone grabbing a single harddrive from your system and not grabbing the whole system truenas existing encryption will somewhat work just as well as auto unlock using a flashdrive. Just keep the unencrypted stuff on a drive inside the chassis. If you want protection against the whole system being snatched then you should not use autounlock using a flash drive or truenas and should look for a different solution.

I really wanted to use truenas but the encryption implmentation is just not good. Also the defaults for security are not good either. Like by default the boot console is just logged in by default, no password needed or anything. You have to turn on a password prompt in the settings smh.

So I went with Unraid instead, it has its own issues, one user(basically root) for everything, but it uses standard full disk luks and within that I have a full zfs pool.

5

Well, it depends on what you try to accomplish. The usb stick in my case is a quick way to make sure the data is not readable next start while still making sure the system always comes back after unexpected power off. But as I have pikvm now, it would also work with passphrase, vpn and ssh on boot.

6

No, it doesn’t encrypt ix-app or ix-virt datasets, even if you’ve enabled encryption for the pool they reside in.

7

Yeah that’s why I said somewhat and to keep the unencrypted data inside the chasis, like using an nvme ssd that’s screwed into the motherboard. But yeah its very sad that more and more stuff is getting unencrypted and less secure in truenas. TrueNas really needs proper full disk encryption. Which seems like it wouldn’t be too much work either since they can just use luks.

It also depend on the chassis. But yeah provided someone doesn’t also grab the flash drive. Since its FDE that method is more secure.

Should have been more clear about what I meant by in the chassis since most harddrives usually are inside the chasis.

Also depends where you put the flash drive. If you have a hotswap chassis with no lock for the hotswap drives and the flashdrive chilling in the front port then yeah that’s pretty bad and I think the TrueNas encryption with all of the unencrypted stuff, including the encryption keys, being on a nvme fastened to the motherboard inside the case would be more secure.

8

I still think best would be full disk encryption with passphrase, ssh and vpn. As said there are many features a home lab would need. Physical theft is very unluckely, but if drives are thrown to garbage or for warrenty, you always want the data to be encrypted. A usb stick or passphrase for full disk encryption could help here. As said, usb stick is helping to make sure the system always comes up/back after failure.

I guess I will try out custom partitioning and full disk encryption with luks. Other datasets will use then a key for encryption residing in unlocked boot-pool.

Update: Just to mention…using luks on a zfs mirror, you would have to unlock two drives which is again…more comfort using auto unlock with usb stick…

Update: coming from openmediavault…you can prepare a debian installation according your needs and then install omv on top which is an advantage here. Thinking outside the box…

9

It may be unlikely, but if it did happen, the thieves would most likely skedaddle with the entire computer – any USB-sticks included – than bothering to open it up and ripping just the drives from it.

I’ve set up my TrueNAS devices to obtain the passphrases for any encrypted datasets via SSH from a local, hidden source at boot and unlocking the datasets with them and as such, if any of them were stolen, the thieves wouldn’t have any way of unlocking my datasets.

10

You can use the same key for multiple drives and unlock them all at the same time. For example in my Unraid server I have several pools, a couple of mirrors and a raidz2 pool. I just enter the password once and it unlocks everything. Also, I can unlock it remotely as I can enter the password through the Unraid Web UI.

1 Like