Problem/Justification
(What is the problem you are trying to solve with this feature/improvement or why should it be considered?)
Encryption keys for datasets are stored effectively in plaintext on disk. I am aware of /data/pwenc_secret, but as it sits unencrypted on disk, everything it protects is also effectively unencrypted.
Physical access to the machine running TrueNAS means attackers can trivially extract all data in datasets that are protected by TrueNAS encryption keys (instead of passphrases). This includes everything else that /data/pwenc_secret protects, like cloud credentials for off-site backup.
I understand why: the goal is for TrueNAS to automatically unlock datasets that use encryption keys on reboot. But there’s a more secure way to achieve that goal, and it’s TPM encryption. Using the TPM to encrypt /data/pwenc_secret would require extracting secrets from the TPM and that’s MUCH harder than just reading the contents the boot drive and would still allow opening all encryption key datasets automatically on reboot.
Coupled with:
Show Text Console without Password Prompt: disabledin TrueNAS Advanced Settings- SecureBoot support
- TPM enrollment with PCRs, probably 7, 9 and 11 (see
systemd-cryptenrollman page)
And the system would be significantly more secure against physical access to the host machine. Attackers could not load a malicious kernel to access data (due to TPM PCRs and SecureBoot). The web interface and physical console access are protected by the user’s login password. SSH access is protected by SSH keys. NFS shares are protected by Kerberos (if set up), etc.
The only way to access the data in the secure partition would be through either:
- Extraction of secrets stored in the TPM. Only NSA-level attackers posses that capability which is outside of most people’s threat model.
- Extraction of decrypted data from the RAM modules after reboot while the system is running. This requires significant electrical engineering expertise and equipment; same thing as above, attackers that can overcome this are outside of most people’s threat model.
- Zero-day exploits in TrueNAS network services, but that’s par-for-the-course.
Why not just use dataset encryption passphrases?
Two reasons:
- You have to provide it after every TrueNAS reboot (power loss events).
- Does not protect cloud credentials stored in TrueNAS.
Impact
(How is this feature going to impact all TrueNAS users? What are the benefits and advantages? Are there disadvantages?)
Every TrueNAS user would benefit from significantly more secure data. Datasets encrypted with encryption keys and cloud credentials would be reasonably secure from physical access to the host.
Users using passphrases to encrypt datasets could switch to using encryption keys and benefit from automatic unlock after power loss.
User Story
(Please give a short description on how you envision some user taking advantage of this feature, what are the steps a user will follow to accomplish it)
The user installs TrueNAS. The installer detects a TPM is available (modern Intel and AMD CPUs have a TPM on-die) and creates a secure partition (see Implementation Overview below) to store /data/pwenc_secret. On Debian, cryptsetup and cryptsetup-initramfs (or systemd-cryptsetup) automatically unlock the partition by reading /etc/crypttab during the initramfs stage.
The user’s datasets that use encryption keys and any cloud credentials provided to TrueNAS are kept reasonably secure from physical access to the host.
Implementation Overview
Since TrueNAS is based on Debian, this is reasonably simple to implement. systemd-cryptenroll natively supports TPM2 key enrollment (with --tpm2-device=auto). systemd-repart—if configured and called during the TrueNAS install process—can even call it automatically.
Here’s a high-level implementation overview:
- During TrueNAS installation, the installer would create a small partition on the boot drive to store
/data/pwenc_secretand any other sensitive OS (non-user) data. That partition would be LUKS encrypted.
Example of a systemd-repart config file for that partition:
Label=keystorage
Type=linux-generic
# Small, 10 MB partition for just keys. Could be much smaller.
SizeMinBytes=10M
SizeMaxBytes=10M
# Automatically calls `systemd-cryptenroll --tpm2-device=auto`
Encrypt=tpm2
# This causes systemd-repart to write out an /etc/crypttab;
# use `--generate-crypttab=`
EncryptedVolume=keystorage:none:luks,discard
# Specify where this partition gets mounted;
# use `--generate-fstab=`
MountPoint=/keystorage
Install cryptsetup and cryptsetup-initramfs Debian packages to get unlock during the initramfs stage.
Relevant man pages
After installing the necessary packages, I recommend reading the following man pages:
man systemd-cryptenrollman systemd-repartman repart.dman crypttabman cryptsetupman systemd-cryptsetupman systemd-cryptsetup-generator
.
In 