Buddy Backup and Encryption

[TheGlitch]

So I noticed that HexOS requires encryption at the folder-creation stage for future offsite backups. Since Buddy Backup isn't out yet, how will the migration path look for users who have already populated large unencrypted datasets?

Specifically:

1. Will there be a built-in 'Migrate to Encrypted' tool to move data into a new encrypted dataset for Buddy Backup?

2. Will Buddy Backup support 'Replication-level encryption' (encrypting the stream during transit/at rest on the destination) without requiring the source folder on my local NAS to be encrypted?

3. What about application data folders that are already not encrypted, how would those be handled?

[PsychoWards]

As much as I like the idea of encrypted datasets (i'm using them myself), I fear that it will cause a not insignificant amount of headaches and data loss.

Seeing how many users currently are just reinstalling Hexos if something is not working as they expect, currently, they just nees to mount the pools again and no harm no foul.

But with encrypted datasets, where they didn't save the keys or have the keys saved on the encrypted dataset themselves it's bye bye data. 

So if we go done the path of encrypted datasets, we need to have a way to easily manage the decryption keys. Maybe there will be an option to store them on the Hexos Server and use them from there if anything ever goes wrong with a server. If not, a lot of people are not going to remember where they put those keys X years ago, which are now standing between them and their data.

Don't get me wrong, I think those are definitely valid points, but such a crucial part requires a basically fool proof setup to not cause any harm. 🙂 

[Todd Miller]

Would that key store on the HexOS server mean I would need to connect to the mothership and would not be able to perform any of these actions only using the local UI dashboard?  That would seem to be another bump in the road.  A philosophical bump, but a bump nonetheless.

[TheGlitch]

I agree with @PsychoWards and @Todd Miller -  we are having a conversation that plagues  IT Security engineers all the time.... finding the middle ground of high security and protection but ease of use. Make things to easy and its not good protection. Make the protection as solid as possible and the user won't use it. The general standard dictates the data MUST be encrypted before it leaves the machine.

The standard practice is you encrypt the data, and you store the keys in a Vault (like Bitwarden, 1Password, or a physical safe). HexOS is marketed to "prosumers" who want things to "just work." If HexOS forces encryption and the user deletes their OS without backing up the keys, the data is mathematically unrecoverable.

Should we be storing keys on the HexOS servers? From a security standpoint, this COULD be a huge issue. The risk comes down to the possibility of HexOS getting hacked, the hackers then have the keys to everyone's backup. Buddy Backup aims to be a "zero-knowledge" system, and that should mean only the users have the keys. HexOS server can assist in the facilitation of passing the keys to each user because seeing part of the key isn't the actual key. 

They could use an identity-based key derivation like Steve Gibson's SQRL. If HexOS generated a Master Identity Key for each user, the system could automatically derive unique encryption keys for each Buddy Backup target. This would allow for 'Zero-Knowledge' offsite backups without forcing users to manually manage individual encryption keys for every dataset. We get the security of ZFS encryption with the ease of a single Master Password. In a SQRL-style system, if you reinstall the OS, you must have your Master Key backed up. If HexOS doesn't force you to save that master key (or the 24-digit Rescue Code) during setup, then a reinstall would mean the end of your data.

[PsychoWards]

Just to clear things up, I was only talking about encrypting local datasets and not buddy backup. 🙂

58 minutes ago, Todd Miller said:

Would that key store on the HexOS server mean I would need to connect to the mothership and would not be able to perform any of these actions only using the local UI dashboard?  That would seem to be another bump in the road. 

No, you only need to have the keys once, when mounting the dataset to a new server or fresh install, afterwards you can save them in the OS and don't need them anymore. This will not be a problem with local UI dashboard. It might be that it's just stored in a Vault on the Hexos Server and you can retrieve them from there, or that during the setup, which requires an Internet connection anyway, they are automagically fetched from there or sth similar. Or the Eshtek team is not going to store the keys at all for us, I mean we are only talking possibilities and dreams at the moment 🙂 But, as @TheGlitch already mentioned, if you have them in a vault and that vault is an app in Hexos as part of the encrypted dataset, you are out of luck. 

Also, in case where the Hexos Server gets compromised, and the keys leaked, for local datasets this should be less of a concern, because typically, they shouldn't even be accessible from the outside in the first place and 2nd you can easily change them. 

And you can even make the storage of the keys optional. 

[TheGlitch]

16 minutes ago, PsychoWards said:

Just to clear things up, I was only talking about encrypting local datasets and not buddy backup. 🙂

Oh that makes more sense. lol

I think the only way to solve this is too not bother encrypting things... lets just keep everything OPEN.