Am I invisible to you? 
1 Like
Part of the method I describe, allows using a detachable USB flash drive. Something you can remove after loading the ZFS encryption key into memory.
This means if someone steals your server, if they don’t have the USB flash drive, and know how to use it, the ZFS encrypted data remains secure.
Ideally, a pre-mount script would be run to un-lock any ZFS encrypted datasets at boot, if the USB flash drive is available.
1 Like
Even better than the key on a USB stick: The booting NAS system could retrieve it from a server on the internet, which would refuse to release it if the request comes from an unknown IP address or if something else looks suspicious. This way, the data would be well protected if the NAS is stolen or confiscated.
I’m probably not the first to think this – does anyone know if there are any working open-source solutions?
1 Like
It would probably require a static IP address then. Not very practical for home use.
To me that doesn’t sound better at all.
It sounds like a different use-case all-together.
It would make your system dependant on internet connectivity, your ISP never changing anything, and that the offsite key server isn’t compromised.
I’m not saying there’s no scenario where it could be useful, just that it’s highly specialised and vastly different from the scope of this thread. With that said, I’m sure someone would love to sell you that with a SaaS subscription model. Heck, the I bet the “if something else looks suspicious” could be solved with AI!!!11eleven /s
That is EXACTLY why the USB key approach works: you use a complicated password, which you cannot possibly remember, and you lose/destroy the USB key.
Even if someone finds the key, unless you’re silly enough to put a tag on it, people have no idea what it’s for or what system it belongs to.
Hammers don’t work when there’s nothing to remember. Besides, even if you say everything, you still get hammered, since they never know if you said everything, and thus will continue to break you, until they are sufficiently certain you’re not hiding anything anymore, or you’re dead, whichever comes first.
Thus, password you can’t remember on an unlabeled stick that can be destroyed or disappeared in a pinch.
How about using the file system’s UUID as encryption key? Then one simply must know that a particular USB stick will happen to work, and only a direct clone with dd that replicates the file system UUID would work as a backup. The USB stick could still be used for other useful things, like have memtest or a recovery boot on it, but nothing that points to it serving double duty.
Exactly that was the point of my feature request. Lots of other interesting ideas in this thread, too; but that’s the central and most likely relatively easily implementable part.
@rcfa - There is some differences between passphrases and passkeys. One is that you can’t switch between the 2 after encrypted dataset creation. OpenZFS likely supports piping passphrases into the load key command. That lends its self to automation better.
But, the complicated method I show using a named pipe / FIFO allows automation for passkeys.
Ideally something would be done at the OpenZFS level, like my suggested limit of 32 bytes for RAW key reading. That, combined with other details like detecting device presence, (from UDev), would make unlocking encrypted datasets easier.
Thus, the feature should be more “ZFS encryption credentials on USB drives”.
re keys in RAM … law enforcement frequently hot wires servers to a portable UPS before unplugging them. that keeps them up and running, whooops.
I do believe that countries where enforcers use this fancy UPS-technique won’t tolerate thermorectal cryptanalysis hammer brute force. I can be wrong.
Frankly I couldn’t care less. Most law enforcement are bumbling fools, and also this isn’t about protection from law enforcement, but theft protection.
Show me the hoodlum who shows up at a burglary with a UPS that allows hot clamping into the supply wire 
Also, the idea that a security measure has to be covering 100% of all imaginable cases to be worth implementing is nonsense. Otherwise, knowing that there will always be zero day exploits, we might just do away with encryption and passwords, etc. altogether.
A key that’s just in RAM is leaps and bounds better than a key in tge boot configuration, that basically only protects data if you remove the drives from the system
Frankly, who cares if someone knows it’s a security dongle? If I lose my keys, people also know they are keys. They still don’t know what doors or items the keys are for. 
If the thumb drive has e.g. a Clonezilla or SystemRescue distribution on it, two file system UUIDs from two partitions would also yield a 32 byte encryption key. There would be no need to even store a key. The logic to convert file system UUIDs into an encryption key would be on the TrueNAS system. All that’s needed to give the system a USB stick and say: “use this USB stick’s file systems UUIDs to encrypt!”
Not like that’s what my original suggestion is about. But maybe one could have a script with a standard name in a standard location which outputs the key, that way one could write arbitrary scripts and store the encryption keys in arbitrary ways, transparent to the rest of TrueNAS: it would simply store a script file as part of the config, and user can modify that script any way they want. The standard script may just read an encryption key from a file, and if users want to do something else, it’s up to them.
@rcfa - Interesting point of using a file system’s UUID as the encryption key.
However, I just checked, and for EXT4, (probably EXT2 & 3 as well), the UUID is 16 bytes. Still usable because you could either use 2 EXT4 file system UUIDs. Or combine the UUID with the EXT4 “Directory Hash Seed” which is also 16 bytes. Neither would change during normal operation of the file system.
Of course other file systems may use larger UUIDs. I did check Linux swap space and it uses a 16 byte UUID. So a small swap space combined with a Linux EXT4 file system on a single USB flash drive might work out good.
Plus, the idea of allowing a script to get the encryption key makes sense. The “stock” script would perform the task as is done today. But, a customized script could do something else. Now because of the customization of this script, during any normal configuration save, the script would have to be included. Otherwise, some people would not remember or know what was done before.
I do think these problems are solvable. But, to make something robust, and potentially usable in the Enterprise, more fleshing out of the idea needs to occur. My original idea of using an USB flash drive with a partition containing a binary key was better than nothing. But, we do need to more forward.
One thing that absolutely needs consideration, and using the UUID of a file system might very well not be suitable, is that multiple USB keys with the same data need to be supported. I envision Enterprises to have at least 2 keys pre-made and the encryption key data saved elsewhere. Perhaps even printed out and put in a secure, file proof safe.
People in the Enterprise Data Center support environment loose their jobs, (and any potential retirement benefits), when serious mistakes are made. Loosing data encryption keys is one.
So, if the suggestion is purely for home use, then we may not need a feature request for it. If it’s is for both, Enterprise and free user use, then we need the feature request to be rock stable and redundant.
I just thought of something that may be suitable for the Enterprise users, (and a few of use free users).
Many IPMI remote console software / firmware implementations support attaching a file as a disk to the system. This is done routinely for OS load or recovery. Even VMWare and probably other VM managers likely support such.
So, for such a server, (Enterprise or not), standard reboot procedure would include getting on the console and attaching the encryption file. Not having to go to the physical server of the NAS, twice, would be nice.
Now to be clear that where this encryption file comes from, on the user’s PC, could be multiple sources:
- Simple file that is backed up elsewhere but not to the NAS
- SMB share from a different NAS
- An USB flash drive
For the last, Enterprises could have a checkout and check back in protocol. The USB flash drive key could then be stored in a cabinet, locked box or fire proof safe. With a second copy in the manager’s office or another, local building. (With additional copies stored elsewhere, perhaps like at a disaster recovery site.)
Cloning a disk/UBS stick with dd or BalenaEtcher or some equivalent tool, will retain the UUIDs intact.
Having e.g. a rootfs and home partition will yield two 16byte UUIDs.
A disk image can safely be stored to burn another copy of the key, if need be.
Again, that was just an idea for people paranoid about keys recognizable as such being on some USB stick that’s not directly associated with a particular system.
If TrueNAS were moving towards a script based approach to retrieve the keys, as long as the script is user modifiable and stored as part of the configuration, then there would be no end to what users can do modifying a standard script.
Maybe that’s the easiest: a simple, well tested standard script is provided along with a script editing UI as advanced setting. And there people can put in whatever they want (Yubi Keys, Steganographic approaches, etc.)