ZFS passwords on USB "keys"

Feature Requests
1

Problem/Justification
It’s fairly easy to set up ZFS encryption with TrueNAS.
There are two things I’d love to be able to do:

  1. pick my own password, such that if things go bonkers, I at least can mount the pools elsewhere…
  2. have the keys/password stored on an USB stick, rather than in the config file.

This way one can, if need be, simply pull the USB stick and shut the system down, and the data is secured.
If one’s particularly paranoid, one could insert the USB stick only for booting, and then remove it, locking it away, thus rendering the pools unusable shoud anyone try to steal the device without having access to the USB key.

Impact
It should not impact users who want to use the system as it currently functions at all.
However, users who want to have an “electronic lock” on the system, can do so.

1 Like
2

Seconded!

Seriously, if your threat model is concerned with data at rest, but you want the system booting up automatically, then using a key based encryption and placing the key on a removable medium is the way to fly.

Please consider this proposal. Bugged me since TrueNAS CORE days.

2 Likes
3

I think I understand but I need to ask because sometimes I misunderstand what is written.

  1. The TrueNAS system would require a key be inserted into the machine in order to mount the pool(s).
  2. Removing the key would make the pool(s) inaccessible to anyone, even on the console. I’m not sure how that would be accomplished but I’m sure it is possible.
  3. Reinserting the key would bring the pool(s) back online.
  4. If you lost the key or it was destroyed and you did not have another, you could unlock the system using a password. Maybe 2FA is an option?
  5. And this is all optional, to be turned on if a user selects so. But then again the user would also need encrypted pools as well.

If this is true, I like it quite a bit. It isn’t something I would use however I can see that it would be a great security selling point, and many people would use it.

1 Like
4

The master encryption key is held in RAM once its successfully loaded. You’ll only need the USB stick again the next time the system is powered on or if you intentionally lock the datasets.

Not possible with ZFS. Please see this feature request from 2017.

1 Like
5

The threat model of this request is whatever authority comes to your home to confiscate “the servers” and you have the awareness and time to just pull that USB drive.

They will take the server pulling power and your data is safe now because they do not have the key.

Also you should just pull the USB drive every time the system has booted to full operation. The key will be in memory then.

And this would not only benefit individuals concerned about their respective country’s authorities, but also companies with specific privacy requirements.

Scenario:

You need a “physical key” to boot the system. Then it will operate as expected. If anybody breaks in or by state authorisation seizes your NAS, it’s worthless without the “key”.

1 Like
6

@pmh speaks from personal experience. :wink:

4 Likes
7

This is all quite interesting.

8

Yes, optionally.

No, that would’t be the case, as the key is in RAM when loaded.
The idea is more theft protection: if someone walks away with the computer, they usually need to unplug it, and at that point system shuts down, key gets lost from RAM.

I mean, theoretically one could implement your thing, too: have a daemon watch the USB key, and when a device removal event comes, automatically issue the required commands to take the zpools off line and unload the key.

But while that may also be useful in some cases, having the key plugged in all the time, begs for it to be stolen along with the system. So my use case is more like: stick the key in, power the system up, and once it’s booted, remove the key. Things continue to run, until next reboot, at which point you’ll need to insert the key again.

See above, not the proposed use case, but if one implements the above mentioned daemon, it could likely be added too, although it would add additional complexities, while the use case I propose is a lot simpler to implement.

That would depend on the implementation details. If one simply dumps the master key on the USB stick, then that would not work. On the other hand, if the masterkey remains on the disk, but is itself encrypted by a password which is stored on the USB key, then one could enter the password manually instead of sticking the key into the USB slot, or theoretically use a variety of different methods. That would essentially mean putting the masterkey in one more more keyvaults that are encrypted by one or more alternative methods.
That would actually my preferred scenario. If done right, then the masterkey can be encrypted by multiple passphrases, so a few trusted users could each have their own passwords without the need to share them, while the encrypted masterkey stays put, and only the passphrases travel. This has also the advantage that one can easily change passwords without actually affecting the pool itself.
The USB key is just more convenient than typing passwords on a headless system, which would require some KVM setup or ssh etc. which is a PITA.
But I’d be already quite happy with just the masterkey on a USB stick. Can always make a couple of backup copies and lock them away, or dump the master key and save it e.g. in some safe place e.g. one of the many keychain apps, so it can be recovered if the USB stick gets lost or damaged.

Exactly.

9

Not quite.

10

Don’t forget about this last-ditch failsafe. It can work with any implementation and gives you at least one last chance to prevent being locked out of your own data.

That’s the reason for the feature request from 8 years ago that I linked in post 4. LUKS already does this. Shame that ZFS is way behind. The lead developer for native encryption in ZFS had since left the project. :confused:

2 Likes
11

AIUI, it’s not gonna happen (in the foreseeable future). And @winnielinnie explained why.

You already can do it. At least with a passphrase unlocking.

Do you want to encrypt the boot pool? Because you don’t need KVM/BMC for the encrypted data pool unlocking.

All in all, I think you can already implement it with some cron jobs (especially assuming that your usb stick is mounted to the same path every time).
While this article is about proxmox, I think it can be somewhat useful. The difference is that you will store your key not on the pool itself but on a usb drive.

12

Not saying they will do it, but we don’t need ZFS to support it.
We could take any old key vault to store the master key, and unless that vault can be en/decrypted by multiple passwords and/or methods to retrieve the master key, there’s zero cooperation from the side of ZFS required. It would have to be implemented by the TrueNAS OS however, which would be considerably more involved than dumping the master key on a USB stick.

Again, I’d already be happy with the latter, or with a ZFS password on the USB stick, but that would require that TrueNAS would allow me to create a pool that’s password protected, which I have not found a way to do, although ZFS itself supports that.

13

It’s not the pool that gets encrypted, but the root dataset.[1] To use a passphrase for the root dataset, you cannot have the System Dataset or apps on the pool.

That would require a lot of involved work from iX. At that point, they might as well submit a PR to the OpenZFS GitHub so we can finally fulfill the multi keyslots request from 2017.

  1. TrueNAS might incorrectly refer to this as “pool encryption” when you go to create a new pool. ↩︎

1 Like
14

This kinda sounds a bit like how Microsoft BitLocker does it. It would be interesting to see if some inspiration could be drawn there.

15

Back in 2017, I, (known as Lady Galadriel on GitHub), submitted something similar to the above request:

Basically a simple USB flash drive that has the ZFS passkey installed on it. May allow partitions, so that multiple passkeys can be used for different pools or different servers.

Using a simple USB drive, (or better yet, a proper USB SSD), allows for multiple copies of the USB drive to be made. Thus, one in a remote lock box. One local to the server that you could destroy if you get a pounding on the door. And perhaps one stored with distant family or friends that you trust.

Of course, hammers win encryption every time when we talk oppressive governments. (Hammers used on people who hold the passwords or know where the passkeys are located.)

One last comment. Regardless if using password or passkey for ZFS native dataset encryption, you can print out / write out the information. In the case of passkey, it would be in Hexadecimal. Might be a pain to re-install after loosing the electronic version. But, better that, then lost encryption keys causing data loss.

3 Likes
16
3 Likes
17

I employ the USB encryption key method, my keys are encrypted on the usb device so they cannot be read in plaintext. This is a cruical step should your usb device fall into the wrong hands. I have a post-init script that reads a specific USB UUID, decrypts the password using a key stored on the host, then unlocks the datasets. If the usb device is not present, datasets are not unlocked.

How to set up encryption to be physically theft-proof? - TrueNAS General - TrueNAS Community Forums

3 Likes
18

A basic memory stick would be a much cheaper option compared to something like a yubikey.

1 Like
19

Yes.

Even though it may contain a binary encryption key, if the methodology was reasonably well designed, it is possible that someone might over look it’s use as a security dongle.

For example:

  • Get several USB drives, could be different makes & sizes
  • Create at least 2 partitions on the USB drives:
    • First partition would be tiny, like 1MB, perhaps labeled as BIOS boot
    • Next partition for simple FAT32 for the rest of the USB drive, that you populate with misc. files
  • Create a 32 byte RAW encryption key.
  • Create an encrypted ZFS dataset / zvol using that key
  • Drop the encryption, which un-mounts the encrypted ZFS dataset
  • Copy the encryption key, in binary, (like with dd), to the USB key partition on all your USB drives
  • Use something like below to test
  • Repeat by dropping encryption on the ZFS dataset /zvol and then test using another of the USB drives
  • Possible print out the encryption key, in hexadecimal and put in a safe place

Here is how to test:

mkfifo /tmp/myfifo
dd if=/dev/sdX1 bs=32 count=1 of=/tmp/myfifo &
zfs load-key -L file:///tmp/myfifo MY_POOL/encrypt_test
zfs mount MY_POOL/encrypt_test
rm /tmp/myfifo
eject /dev/sdX

Perhaps we need a resource clarifying how this can be done, in more detail.

20

When I set up a local certificate authority on my LAN, I encoded the private keys into QR codes, printed them off, and locked them in my safe. Still machine-readable, but impervious to most of the dangers that would affect magnetic media or ICs. Might be overkill for a 32-byte key though.

1 Like