How TrueNAS protects the encryption password of Cloud Sync Tasks ?

[Vallevert]

I would like to know how TrueNAS protects the encryption password and the salt of my Cloud Sync Tasks.

The problem is clearly explained in the second paragraph of this post: https://www.truenas.com/community/t...nc-encryption-password-and-credentials.96928/

Does TrueNAS protect my password and its salt by encrypting it (or something else)?
Can someone who steals boot-pool get this info?
If so, can I have the path to this file?

 

[winnielinnie]

As far as I understand, everything is stored in /data/freenas-v1.db

It uses /data/pwenc_secret to encrypt/decrypt sensitive data within.

As you note, however, if someone physically steals your server or boot drive(s), then they essentially have access to both files. If they know what to do with those files, they can uncover your cloud credentials, dataset encryption keystrings (not if you use passphrases), and rclone encryption passphrase.

I suppose if such physical theft happens, you can immediately change the passphrases and keys; sort of like deactivating a stolen credit card.

 

[Vallevert]

If they know what to do with those files, they can uncover your cloud credentials, dataset encryption keystrings (not if you use passphrases), and rclone encryption passphrase.

That's my problem
I use passphrase for pool and dataset encryption.

I found this in /data/freenas-v1.db:

Your are right. The password and salt are stored here.
I think there is no way to prevent stealers to recover my encryption password and salt, a way like the prompt to unlock dataset/pool.
Or by encrypting my boot-pool, but how ? I don't have SED

Thanks for your help

 

[winnielinnie]

I think there is no way to prevent stealers to recover my encryption password and salt, a way like the prompt to unlock dataset/pool.

Automatic cloud syncing would not be possible. Perhaps a feature request to provide an alternative "manual only" cloud sync, in which case it will prompt you to authenticate every time and forgo storing the passphrase and salt? (I doubt such a feature request will be accepted.)

Or by encrypting my boot-pool, but how ? I don't have SED

This goes back to the same principle of "automatic". You would lose the ability to seamlessly reboot the system without intervention on your part to continue the boot process. (Those who use SED drives for their boot-pool might be able to chime in with some better information, and tips on thwarting data exposure, even if the entire physical server is stolen.)


By the way, "censored lmao" is a weak passphrase. I highly recommend you change it to something cryptographically stronger.

 

[winnielinnie]

I use passphrase for pool and dataset encryption.

You might have misunderstood my caveat:

dataset encryption keystrings (not if you use passphrases)

I wrote it to mean that this is not an issue if your dataset encryption uses a passphrase. (The issue only applies if your dataset encryption uses a keystring.)

This is because unlocking encrypted datasets using a passphrase must be done manually. (It will prompt you.) However, if you use a keystring, it is unlocked automatically when you reboot, since the keystring is stored on the boot-pool.


These implementations and limitations are purely due to TrueNAS's design. They are not the fault of ZFS. In vanilla ZFS, you can manually lock/unlock an encrypted dataset, even if it uses a keystring or keyfile. TrueNAS prevents this because they don't want you to break your live system by willy nilly locking a root dataset, which might have the System Dataset nested underneath. (Among other reasons.)

 

[winnielinnie]

I think there is no way to prevent stealers to recover my encryption password and salt

You can use this method that works for laptops. With a few adjustments, you can modify it to work with a NAS server.

I've tested it myself. It works as advertised.

 

[Vallevert]

You might have misunderstood my caveat:


I wrote it to mean that this is not an issue if your dataset encryption uses a passphrase. (The issue only applies if your dataset encryption uses a keystring.)

This is because unlocking encrypted datasets using a passphrase must be done manually. (It will prompt you.) However, if you use a keystring, it is unlocked automatically when you reboot, since the keystring is stored on the boot-pool.


These implementations and limitations are purely due to TrueNAS's design. They are not the fault of ZFS. In vanilla ZFS, you can manually lock/unlock an encrypted dataset, even if it uses a keystring or keyfile. TrueNAS prevents this because they don't want you to break your live system by willy nilly locking a root dataset, which might have the System Dataset nested underneath. (Among other reasons.)

I understood what you said. I just want to say that at every restart, I need to enter my encryption password for pool/dataset.

By the way, "censored lmao" is a weak passphrase. I highly recommend you change it to something cryptographically stronger.

This is not my passphrase. I will never send any hint of my true passphrase.

in which case it will prompt you to authenticate every time and forgo storing the passphrase and salt?

Not at every sync, just after the NAS boot (exactly like for encryption in dataset)

This goes back to the same principle of "automatic". You would lose the ability to seamlessly reboot the system without intervention on your part to continue the boot process.

That's not a problem to me.

 

[Vallevert]

You can use this method that works for laptops.

lmao
good job

thanks for your help

 

[winnielinnie]

Not at every sync, just after the NAS boot (exactly like for encryption in dataset)

You can submit a feature request for this. But I still doubt it will be accepted for Core, and even so still unlikely for SCALE.

That's not a problem to me.

This might be your best option if that's the case. But then I defer you to those who actually (successfully) use SEDs for their boot-pool. They will be able to recommend which drives to purchase, and the best way to configure everything.

understood what you said. I just want to say that at every restart, I need to enter my encryption password for pool/dataset.

It was the way the two sentences were in proximity to each other that threw me off. "That's my problem" followed by the next line.

That's my problem
I use passphrase for pool and dataset encryption.

This is not my passphrase. I will never send any hint of my true passphrase.

Yes, I know.

 

[Vallevert]

You can submit a feature request for this. But I still doubt it will be accepted for Core, and even so still unlikely for SCALE.

Sad for me



Do you think there is a way to remove all password at each restart with "Init/Shutdown Script" ?
If possible, any link to help me to use the TrueNAS API ?

 

[winnielinnie]

Do you think there is a way to remove all password at each restart with "Init/Shutdown Script" ?
If possible, any link to help me to use the TrueNAS API ?

Way out of my wheelhouse. That might even result with unforeseen problems, since the middleware isn't expecting a Cloud Sync Task to have its salt or passphrase removed from under its feet by an external script.

 

[winnielinnie]

If this helps put your risk into a realistic perspective, all of the following must be true:

• You are a victim of theft, and...
• The burglar physically removes and steals your NAS server, and...
• They are more interested in the data stored on your drives and cloud, rather than the value of the hardware itself, and...
• The burglar, their friends, or their clients (whom they sell or give the parts to) have intermediary knowledge about TrueNAS or ZFS, and...
• They know how to view the contents of a database file, let alone know the location of said file, let alone know what tables to look for, and...
• By this time you haven't already taken other measures to protect your cloud account

To be honest, thieves and burglars look for "small and high resale value". Large and bulky, with too much variability in its potential value, isn't worth it.

Quick, easy to swipe, easy to leave with, high predictable value.

 

[Vallevert]

I don't fight thieves.
I'm not afraid of thieves for all the reasons you mentioned earlier.

But privacy is extremely important to me.
So if (for whatever reason) the police get hold of my NAS, they'll have resources, technicians, experts, and a great desire to decrypt my data.

 

[winnielinnie]

So if (for whatever reason) the police get hold of my NAS, they'll have resources, technicians, experts, and a great desire to decrypt my data.

See the above linked video.

Or go the route of a boot-pool comprised of SEDs. (Can't help you here, as I have never tried it myself, nor do I know which brands or models are recommended.)