-
Important Announcement for The TrueNAS Community.
The TrueNAS Community has now been moved. This forum will now become READ-ONLY for historical purposes. Please feel free to join us on the new TrueNAS Community Forums
Dataset encryption
- Thread starter Ckone
- Start date
- Joined
- Nov 12, 2015
- Messages
- 1,471
Its pretty straight-forward, create a dataset, enable a password for dataset to enable encryption. Then you can lock/unlock the dataset at will.
Docs are forthcoming for it, expect to see them land on https://www.truenas.com/docs/ in the coming months.
Docs are forthcoming for it, expect to see them land on https://www.truenas.com/docs/ in the coming months.
- Joined
- Jan 1, 2016
- Messages
- 9,703
Transparently... shares won't care if they share data from an encrypted or unencrypted dataset... if the share is offering data from an encrypted dataset and it is locked, "no share for you", otherwise, the share works as normal.
Hi both, thx. I depth i´m not very familiar with that.
It works. But maybe i have a wrong expectation.
I thought if i copy a file from an encrypted dataset/share to my desktop it stays encrypted. But it does not per my test. On my desktop it‘s completely readable.
So for me the plus of dataset encryption would be to prevent a usable data leak by encryption of the data and redtricting the data usage to thise who know the key.
But it seems not wo work like that.
christian
It works. But maybe i have a wrong expectation.
I thought if i copy a file from an encrypted dataset/share to my desktop it stays encrypted. But it does not per my test. On my desktop it‘s completely readable.
So for me the plus of dataset encryption would be to prevent a usable data leak by encryption of the data and redtricting the data usage to thise who know the key.
But it seems not wo work like that.
christian
- Joined
- Aug 19, 2017
- Messages
- 1,556
No, that is not the way it works. Data in an encrypted dataset is available just like any other dataset if it’s unlocked. Lock the dataset ant it’s not available for anyone. ZFS is a filesystem, it cannot encrypt individual files, only blocks of data. To encrypt files, take a look at GPG
Kevin Horton
Guru
- Joined
- Dec 2, 2015
- Messages
- 730
What happens if you have a dataset with encryption enabled, but it is currently unlocked. Someone pulls the power and walks away with the server, or just grabs the disks. Is the data in that dataset on those disks encrypted?
- Joined
- Jan 1, 2016
- Messages
- 9,703
As I understand it, the unlock status survives a reboot, so they have the data in the clear if they can mess with the console or break into it via network.
The OS with the keys isn't there, so no access to the data for them. Data is encrypted on the disk and the decryption key is not on those disks.
Kevin Horton
Guru
- Joined
- Dec 2, 2015
- Messages
- 730
Could the key and/or passphrase be required during boot, so that even if they had the complete server they still didn't have access to the data? I only reboot to update, generally speaking, so a bit of inconvenience during reboot is worth it to improve security.
When someone dies, their keys might go with them and their family can't find all their important records. If you do want that behaviour option, it's worth making a "suggestion" in the bug database and we can see whether other people want it. (I'm also worried that my system might reboot in 2 years and i've forgotten my passphrase// agh!)
ornias
Wizard
- Joined
- Mar 6, 2020
- Messages
- 1,458
Wait, so what do we use encryption for then?
Because encryption doesn't work for digital threats, just for snooping people, thiefs (governmental or not)...
So we now have encryption that isn't able to prevent anything?
A solution to this could be the storage of the keys on a USB stick, as can be done in Synology.
I have my shares encrypted and the keys stored in an old 1 Gb USB stick nailed behind the bookshelf and connected with a usb cable to the NAS.
I reboot everyday (NAS is turned off at night) and the encrypted shares are auto unlocked.
If someone pull the cables (power, ethernet, usb backup and usb keys cables), he will walk away without the keys and the shares encrypted.
There are many uses for the encryption.. I'm just pointing out that it has to be used very carefully to avoid data loss... especially in a home environment.
I'll be interested to see how many people want "passphrase on boot".
I notice that Kiriak has an "automated" approach, but it reliant on a USB key that doesn't fail and a physical cable that the thief has to ignore. If we standardized on that model, the the thief may learn.
I'll be interested to see how many people want "passphrase on boot".
I notice that Kiriak has an "automated" approach, but it reliant on a USB key that doesn't fail and a physical cable that the thief has to ignore. If we standardized on that model, the the thief may learn.
Even if the thief does not ignore the cable (unlikely to happen), he has to move the big bookshelf to gain access to the usb stick.
You are right, if it will be a standardized method, thieves may be aware.
But one can also bury or glue the stick inside the wall or the floor if his data can be the target of a more sophisticated attack.
Also encryption adds one more risk factor to lose data. Backups (with a different method of encryption or no encryption) are even more important in this case.
You are right, if it will be a standardized method, thieves may be aware.
But one can also bury or glue the stick inside the wall or the floor if his data can be the target of a more sophisticated attack.
Also encryption adds one more risk factor to lose data. Backups (with a different method of encryption or no encryption) are even more important in this case.
I use a usb key to auto unlock my encrypted linux machines too (several colleagues do the same). It's tiny and easy to hide or keep with me on my keyring. It's a convenience vs security trade off, but since the key is never left unattended with machines that are powered down (or running for that matter), it's one that meets my needs (theft and disk re-purposing. People with large wrenches (or legal options) are not a threat factor)
I also have a password in another luks slot, so if I lose the key or the usb stick is damaged or otherwise become unable to unlock via it, I can just plug a keyboard in and enter the password on boot. Anyone worried about family access to data after they are gone, add another password slot and give them that password to store in their safe. That's with luks anyway that allows up to 8 slots with combinations of pass only, passwordless key, passworded key etc (obviously freenas is limited due to geli here, which doesn't seem to have the same features as luks).
As for encrypted datasets, I see multiple use cases and for some, surviving reboot when not explicitly locked could make sense, however I would not expect that to be the default mode of operation. It seems counter to how most would expect encryption to function and indeed how it functions in most other implementations (even your phone is locked when power is lost and/or it reboots).
I would find encryption that survives a reboot quite surprising as a default and hope this is explicitly called out in documentation if it's left as this.
If this is achieved by un-encrypted keys been kept on the boot drive and only erased when a dataset is locked, how confident are you in the key erase? Given that some may be relying on the security of this and expecting unencrypted keys to be kept in locked memory pages only, even if they religiously unlock then re-lock their dataset, if you're writing the key to disk unencrypted behind their back then wiping it when the dataset is locked, it may be exposing them to a risk that shouldn't exist.
imo surviving reboot should be an option, but it should not be the default. If it IS the default, the user should have the option to change this and be warned clearly that this is the default.
I also have a password in another luks slot, so if I lose the key or the usb stick is damaged or otherwise become unable to unlock via it, I can just plug a keyboard in and enter the password on boot. Anyone worried about family access to data after they are gone, add another password slot and give them that password to store in their safe. That's with luks anyway that allows up to 8 slots with combinations of pass only, passwordless key, passworded key etc (obviously freenas is limited due to geli here, which doesn't seem to have the same features as luks).
As for encrypted datasets, I see multiple use cases and for some, surviving reboot when not explicitly locked could make sense, however I would not expect that to be the default mode of operation. It seems counter to how most would expect encryption to function and indeed how it functions in most other implementations (even your phone is locked when power is lost and/or it reboots).
I would find encryption that survives a reboot quite surprising as a default and hope this is explicitly called out in documentation if it's left as this.
If this is achieved by un-encrypted keys been kept on the boot drive and only erased when a dataset is locked, how confident are you in the key erase? Given that some may be relying on the security of this and expecting unencrypted keys to be kept in locked memory pages only, even if they religiously unlock then re-lock their dataset, if you're writing the key to disk unencrypted behind their back then wiping it when the dataset is locked, it may be exposing them to a risk that shouldn't exist.
imo surviving reboot should be an option, but it should not be the default. If it IS the default, the user should have the option to change this and be warned clearly that this is the default.
Last edited:
Kevin Horton
Guru
- Joined
- Dec 2, 2015
- Messages
- 730
What happens to the encryption lock status if the dataset is periodically replicated to another server? In some use cases (off site backup servers), you may want the replicated dataset to be locked. In other use cases, you may want it to mirror the lock status of the source. Can this behavior be specified via settings?
Replication does not decrypt the data... so the other "backup" system has encrypted data and no key. To access and decrypt the data, the key has to be entered in the backup system.
I think this is improperly interpreted.
The replication cannot work if the source volume is encrypted and locked.
Replication doesn't care if remote system is encrypted o not.
There are two encryption types you can select: key or passphrase. If you select key, the encryption key is stored on the boot drive, the dataset will automatically unlock on boot, and you can't manually lock the dataset. In contrast, a passphrase is not stored and you can lock/unlock the dataset at will.
No, it's one of the major benefits of native ZFS encryption. You can replicate an encrypted dataset without either side having the encryption key.
