Encryption Explanation - Hardening

TrueNAS General
,
1

Hello,

I have some questions regarding encryption and I hope to find the right answer here, I am reading the tutorial and looking for youtube videos for truenas scale.

  1. Wenn I encrypt the whole pool with keys, what am I protecting in detail?
    The encryption-sign is never locked and I didn’t see any button to lock the pool.

This is the picture after reboot

image
image1251×181 13.6 KB

Dataset is locked with pw.

  1. The manual of
    truenas says " " If you have only one pool on your system, do not select the Encryption option for this pool."
    Why such a statement??

  2. What is the difference between “encrypted pool and keyphrase encrypted dataset” and “non encrypted pool with keyphrase encrypted dataset”
    Perhaps you have a robbery-scenario or something, that would help me.

  3. Why does the root have no pw but the admin, when I do the recommended installation?

  4. Would you recommend 2FA if you have a long (>64 characters) pw?

Thank you for your answers
Fantomas41

2

You don’t encrypt pools. Encryption is a dataset property. (Yes, even the “root dataset” is a dataset, which happens to share the same name as the pool.)

This is TrueNAS-specific. The GUI/middleware prohibits you from locking datasets that use a keystring/keyfile. For reasons of “Apps” and the “System Dataset”, you are not allowed to use a passphrase for the root dataset of a pool that contains “must be available at boot” datasets, such as the two named examples.

With vanilla ZFS, you can use the load-key and unload-key commands for any encrypted dataset, whether it uses a passprhase or keystring. (Do not try this on your TrueNAS system.)

The child dataset is locked with a passphrase. Its parent (“PoolSixGB2”) is also a dataset. The pool is named the same (“PoolSixGB2”). This is where confusions arise.

It’s not clearly explained. I think the reason for that is if you only have a single pool, it’s assumed that this is where your System Dataset (and “Apps”) will reside. The “Apps” dataset(s) are explicitly unencrypted.[1] Therefor, you cannot (“should not”) encrypt the pool’s root dataset, since it will have an unencrypted child (“Apps”) underneath.

Again, this is TrueNAS-specific; not a limit of vanilla ZFS.

There’s no such thing as a pool being encrypted or non-encrypted. Replace references of “pool” with “root dataset”, and then things start to make more sense.

  1. Not sure if this has changed? ↩︎

1 Like
3

I feel that the question you are asking is what risks will encryption protect against.

I have good general encryption knowledge but only theoretical TN Scale encryption knowledge, so these are my personal guesses about this…

Key File Encryption
As I understand it, with Key File Encryption, a dataset and any sub-datasets which don’t have their own passphrase encryption are unlocked at NAS boot based on the encryption key stored within TrueNAS itself. Once booted, the encryption doesn’t protect your data, so this can only be about protecting your data at rest.

Since these datasets are unlocked automatically, they can only protect the data stored within when the pool is mounted by a configuration that does NOT contain the key. If your pool drives are stolen along with the drives holding the encryption key, then simply booting the system will give access to the data. You are really on protecting against the pool drives being stolen without the drive holding the keys.

Clearly Key file encryption has a purpose (otherwise why would it exist), but the use case for this is unclear to me.

Passphrase encryption
With passphrase encryption, datasets are only unlocked when the passphrase is provided by a user, and they can be locked again when access is no longer needed - but during that time, the data is available to anyone with appropriate ACL access.

The datasets are protected at rest because the key is not stored in the system, and also protected when locked.

Other risks
Losing the key or passphrase is absolutely equivalent to losing the data. This is another level of complexity and risk that you need to manage. Therefore, IMO you should only encrypt if you understand the risks and how to manage them.

Performance
Encryption will have some impact on performance. I suspect the degree will depend on the encryption algorithm you choose and the types of access (for example sequential access of large files with read-ahead vs. random access to blocks).

Personal anecdote
I have in the past encrypted my windows drives with Bitlocker, and I took the appropriate actions to ensure that I could have access to the key again if I needed to reset anything (i.e. a paper copy locked in a physical safe, and an electronic copy held on a flash drive in a physical safe). Whilst I never lost access to my data, on two occasions I did need to refer back to the backup copies of the keys. In the end I decided that encryption was an unnecessary additional risk, and unnecessary performance hit, and I removed the encryption.

3 Likes
4

The datset can be replicated offsite… without supplying the key.

Its an active sortof “at rest” because the offsite replication can be updated. And restored from. But is still encrypted.

I think.

I have similar reasons for not having much experience with encryption these days.

It’s like anti-backup :wink:

1 Like
5

Another reason Key file encryption exists, is for warranty returns of disks. Unless you return all the pool disks AND the key, PLUS the destination has a clue on how OpenZFS works, you can consider the encrypted data as being secure.

Of course, just returning 1 disk out of a ZFS pool for warranty replacement is generally meaningless to the vendor. Or anyone. ZFS will generally stripe the data across multiple disks so random partial blocks are generally not useful. (Worse, if the ZFS Dataset has compression enabled… which makes any normal file magic number signature invisible.)

Even just using ZFS on a single disk generally blocks the casual script kiddie thief or hacker. They probably can’t even spell ZFS. In that case, they will probably just use or sell your stolen ZFS pool disks.

However, if you are trying to prevent government or law enforcement from accessing, then the old hammer rules apply. Hit the person with the password or key until they give you the password or key.

2 Likes
6

And good for end of life disposal too.

Often you can’t wipe a failed disk.

2 Likes
7

Thanks you for the numerous feedback

8

End-of-life disposal of a failed disk is easy - hit it repeatedly with a sledge-hammer until it is fairly flat or heavily dented. Almost no possibility of recovering the data from dented or shattered platters.

(SSDs - take them apart, pry the chips off the board, dispose of the chips in separate places.)

9

So, explain this statement to me. You come into my house and steal my machine. So, drives and all. You take it home, boot, and, you are greeted with a login prompt. Yes, my drives are unlocked, but how do you access the data? And no, you do not have cli access from the console.

10

Just off the top of my head (and I am not a professional white-hat security tester, so this is just based on what I have read)…

  1. Using a network share
  2. Mount the boot drive on another system (it is unencrypted), grab a copy of the password file and crack it.
  3. Perhaps grab the security key file off the boot drive.

But yes, you are right, I can’t just mount in on a Linux system where I have root privileges and read the data straight off.

11

And the password for my network share(s) is…?

Grabbing the security key off the boot drive is not the same as “simply booting the system will give access to the data”. You have to know how to do that for a platform that few people in the US even heard of.

I am not the slightest bit worried about a thief stealing the hardware AND having the skills to extract the keys. As long as you disable cli from the console via the settings (important step else it is easy to steal), then, the risk is close to zero. Good enough for me! Could I do it, yes, but I am not the typical guy stealing things either.

I’ve seen it repeated here on the forums a few times that you simply need to boot it but I don’t think that is the case. If it is, I truly want to understand how so I can re-evaluate.

12

Don’t even need to boot into TrueNAS. You can boot into a Linux ISO (Ubuntu, Debian, etc), and grab the files pwenc_secret and freenas-v1.db from the plain, unencrypted boot-pool.

Now you have access to the entire config file, as well as the encryption keys for the datasets that are encrypted with a keystring. (Obviously, passphrase-protected are still safe.)

2 Likes
13

Yes, but that was not the comment I was responding to! Again, I realize you can do that, but a thief? Not worried.

The specific comment I replied to was:

“simply booting the system will give access to the data”

That is not the same as a thief who probably has about zero chance of even knowing what Truenas is extracting stuff, and that assumes they even want to try. The risk of this is close to zero. It is vastly overstated here. And obviously if you are one who somehow believes this is a real risk, then as you mentioned, enter them manually. I just don’t see it.

14

Cost, risk, it’s all a matter of context.

Let’s ignore the (TrueNAS) restrictions of using passphrase-protected encryption for your dataset(s).

The “inconvenience” of having to manually unlock your dataset after booting the system seems like an insignificant cost to me, if it means that there is no keyfile that is accessible[1] to the unlikely “ZFS savvy” thief.

So yes, I favor using a passphrase over an “auto-unlock” keyfile when given the choice.

The “cost” of using passphrase-protection that requires manual intervention is so minor to me, even if it’s super rare for a thief or malicious “friend” to know the basics of ZFS.

EDIT: Not related to the topic, but should be noted, is that you can’t “lose” a passphrase if you have it memorized. Whereas, you can lose a keyfile. You lose the keyfile, your data is gone forever. This is another advantage of passphrases over keyfiles.

  1. Not just “accessible”, but included with the stolen hardware, even if I have a secure copy of it somewhere, such as on a USB stick in a safe box. ↩︎

15

I am not disagreeing that the cost of manual entry is low at all! I was merely responding to the boot comment which was incorrect, that’s it! You have changed the discussion to something else. One has to evaluate their own risks and convenience. For example, you are on a trip and lost power, machine shut down. Yes, with ipmi you can fix it when the power comes back if you have ipmi. But what happened in the meantime (maybe you were on a long flight) and what does that mean to you, so many scenarios.

To add some additional context… I live in a very storm prone area and power loss is quite common, often for hours. I don’t want to lose nightly backups and all sorts of things like recordings off antenna on my server when the power comes back. None of that will happen until I am awake or around and enter the keys. For me, that minor inconvenience is more than minor and I evaluate the risk of what you are proposing as pretty much zero so for me, manual entry is a hardship. But I am not saying one shouldn’t use manual keys! You evaluate your own risks.

Like ix Morgan likes to say here, we are not the normal users!

1 Like
16

Speak for yourself! :angry:

I had to fight off three, yes three ZFS Ninjas just this past month. Had they escaped my house with the server, I would have been in deep trouble.

It happens more often than you realize. The most common time is around 3am or 4am, but I know someone who had to deal with them during lunch time.

1 Like
17

And for me, step 1 is finding my house, good luck with that! Quite off the beaten path.

You are right for sure, no one thinks I am normal.

1 Like
18

Stop! So if I encrypt Pool and each Dataset with a passphrase I am not secure if someone steals my server?

19

You don’t (cannot) encrypt pools. Only datasets. The root dataset (which shares the same name as the pool) is still a dataset.

If a dataset is passphrase-protected, then a thief has no access to its contents, since it has no “key” on the same server’s unencrypted boot device. Even if they can access your root dataset (with a saved keyfile), your passphrase-protected datasets are still safe.

EDIT: Furthermore, datasets are individual filesystems with individual properties. The way TrueNAS (and ZFS) presents them gives the illusion that they are permanently tethered together. But they’re not. You can replicate a dataset elsewhere (without its parent), even if it is currently “inheriting” properties. On this new pool, it preserves everything, including its properties that it no longer inherits from its former parent.

You can even get really silly and granular by nesting unencrypted datasets “below” encrypted ones. If the parent remains “locked”, the datasets underneath are still accessible and mountable. (TrueNAS does not allow this, to prevent a user from accidentally mounting this in the wrong order, which can cause a host of other issues. ZFS itself has no such limitation.)

1 Like
20

If you have created encryption keys and then boot into the initial install boot environment (or one before encryption) I wonder what happens…