SOLVED How to find and save the 'enryption keys'?

[NumberSix]

Unfortunately, it appears the only time the keys can be exported is when the encrypted dataset is first created.

How extraordinary! - that you are only given one chance and one chance only to save the keys. Gulp. Well thank you for all your research in investigating that.

This thread has raised an interesting point. Grab your keys at creation time because you won't get a second chance! Quite worrying, I would have thought.

In my case I chose a pass phrase which, it seems, negates the need to access keys at all, and as long as you remember it, circumvents the 'one time encryption key access' limitation.

Thank you, all. Much appreciated.

 

[kiriak]

I'm new in this,
but if I understand it, the keys are stored in the boot pool and auto unlock the datasets at boot.
Then you can export the key or make new keys.

or am I wrong ?

 

[NumberSix]

the keys are stored in the boot pool and auto unlock the datasets at boot.
Then you can export the key or make new keys.

or am I wrong ?

I consider myself a noob so I can say nothing definitive here. That said, I use, a passphrase on one of my two pools. The locked pool doesn't unlock at boot time, nor ever, until I ask & give the password.

If I used keys (an experience I've never had) and the locked pool was to auto unlock simply at boot time as you suggest, where's the security in that?

I imagine you're wrong, but like I say, that's inference, not knowledge talking.

 

[Samuel Tai]

@kiriak, you're thinking of GELI encryption, where the keys are stored in /data/geli on the boot pool. This doesn't apply to ZFS dataset encryption.

 

[kiriak]

I have a test TrueNAS setup with TN 12.

I have a couple of datasets encrypted with passphrase, which I have to enter at GUI after each boot for the datasets to be unlocked.

I have another dataset encrypted with keys. This one is unlocked at boot.
I also have the option to export the keys again or make new keys.

Am I missing something here?

 

[Q00]

When encrypting data with ZFS encryption and a key in TrueNAS Scale, the key is stored on root disk in sqlite db in an encrypted form.
During boot the key is extracted and then loaded automatically. It means that is someone gets hold of your boot disk and data disks they will be able to access youre data easily. The main protection here the encryption offers is that if you replace your data disk(s) (due to failure or expansion) your data is protected so you don't necessarilly have to dispose of the disk(s) in a secure manner. The OS/root disks is a different story though.

To make it more secure you would need to store the key externally - either in KMIP server or provide a key on each boot (this is essentially what pasphrase is).

Notice that the key is not an encryption key really - it is a wrapping key. ZFS stores encryption keys in a pool itself which are encrypted with the wrapping key. This allows you to easily change the wrapping key and/or passphrase without having to re-encrypt your data. ZFS also allows you to change the encryption key itself in which case newly written data will be encrypted with a new key (the old key(s) will be kept as long as there is data using it).

The BUI does allow you to export the wrapping key at anytime - go to Storage, click on Pool Operations icon and select Export Dataset Keys from the menu.

If you want to extract the wrapping key manually, bypassing the BUI, see my blog entry: https://milek.blogspot.com/2022/02/truenas-scale-zfs-wrapping-key.html

 

[blaasdf]

This thread is one of the top search results and I was quite confused after reading it so I thought I would post my findings here, in case anyone else comes across this.

== GELI vs ZFS native encryption
FreeNAS supported only GELI encryption. TrueNAS only supports ZFS encryption.

== TrueNAS encryption vs ZFS native encryption
TrueNAS doesn't implement it's own encryption. It uses ZFS native encryption under the hood (it just automates things that you can do on the cli).

== ZFS encryption
ZFS native encryption uses a "data encryption key". When creating an encrypted pool/dataset you select the length of this key. This key is what's actually being used for encrypting/decrypting data on disk. This key is stored in the pool/dataset metadata (e.g. on the same drive where the pool/dataset sits).

The "data encryption key" is encrypted using a "wrapping key". The wrapping key is derived from one of these two:
- password
- keyfile

You cannot access the "data encryption key" without having the "wrapping key". In other words, you cannot read the data on disk without knowing the password or having the keyfile.

This approach creates "a layer of abstraction" needed for a number of things. For example, if your password or keyfile were used for encrypting the drive (rather than the "data encryption key"), you wouldn't be able to change your password without re-encrypting the whole pool/dataset.

== How to use ZFS native encryption in TrueNAS
ZFS native encryption is the only option. You create an encrypted pool/dataset using the web UI.

== Default TrueNAS set up for encryption
When you create an encrypted pool/dataset in TrueNAS, it defaults to using the "wrapping" keyfile. Up to my best knowledge, it's not possible to create an encrypted pool/dataset using a password. You can create an encrypted pool (which will use a "wrapping keyfile") and then change to using a password.

The "wrapping keyfile" created by TrueNAS is stored in an sqlite file on the boot pool. The sqlite file is unencrypted. The values in sqlite are encrypted using a "master key" which is stored on the boot pool under `/data/pwenc_secret`.

So in total, when you use the TrueNAS UI to create an encrypted pool/dataset, there are 3 keys involved:
- zfs "data encryption key", stored in zfs metadata
- "wrapping" keyfile , which is used to decrypt the zfs "data encryption key", stored in sqlite on boot pool
- "master key" , which is used to decrypt the "wrapping key", stored in sqlite on boot pool

When the TrueNAS system boots, it uses the "master key" to decrypt the "wrapping" keyfile, which then is used to decrypt the zfs "data encryption key". There is no password involved here, that's why it can auto mount. In other words, if someone physically steals your machine, they will be able to access your data.

== TrueNAS exporting the wrapping keyfile
If you use the default TrueNAS "wrapping" keyfile, the key can be exported at creation of the pool/dataset (you will get a pop up in the web UI) or afterwards in the dataset options.

However, if you switch to using a password, the wrapping key will be switched from using a keyfile to using a password and in the process, the keyfile will be removed from sqlite. If the key is gone, it's not possible to export it. That's why the UI won't show an option to export the key once you switched to a password based "wrapping key".

== TrueNAS How to switch from using a keyfile to using a password
You can switch the wrapping key from being derived from a keyfile to being derived from a password (and the other way as well). Once you switch to a password, there will be two keys involved:
- zfs "data encryption key", stored in zfs metadata
- "wrapping" key, derived from password, used to encrypt the zfs "data encryption key", not stored anywhere (ideally you should use a password manager!)

- Storage -> Pools -> in the dataset options -> Encryption Options -> Encryption Type -> change from key to passphrase

Once you switch to password, you will have an option to lock your dataset:
- Storage -> Pools -> in the dataset options -> Encryption Actions -> Lock