ZFS Limitations of ZFS disk encryption

Dear community,

I am in a situation where a friend of mine allows me to use his proxmox server to create VM's. Furthermore my friend created a zfs pool I can use to store my VM's data.

1. Now, for privacy reasons I want private data not be accessible to my friend.
2. Hence, I created an encrypted ZFS pool with a passphrase keytype inside my ubuntu VM mounted to the virtual zfspool.

The question: Is there any way for my friend to obtain my private data stored on the encrypted zfs pool inside my VM ? Snapshots, Clones, Migrations, Memory dumps ????

I read this on the internet

1. As long as an attacker controls the hardware he can simply watch you typing in the passphrase the next time your system boots up: Is this true ? and then how ?
2. The encryption key is stored securely, either as a binary key or as the result of PBKDF2 iterations on a user-provided passphrase. This ensures that even if an attacker obtains a memory dump, they won’t be able to extract the decryption key without significant computational resources.

Hence, I am bit confused of the truth here. Maybe you guys have an answer to this problem

Cheers!! ;);)
 
Welcome to the FreeBSD forums! ?‍♂️
[…] an encrypted ZFS pool […]
Datasets are encrypted, not pools, zfsconcepts(7). ?‍♀️ Sure the pool needs the encryption zpool-features(7) enabled, but this doesn’t make the pool encrypted.​
[…] disk encryption
[…] Furthermore my friend created a zfs pool I can use to store my VM's data. […] 2. Hence, I created a[…] ZFS pool […]
So F created a pool and you created a pool? Or datasets… But this is disk encryption? ? Maybe it’s best you show us the sequence of commands F and you issued. And indicate the hosts.​
Limitations of ZFS […] encryption
[…] Is there any way for my friend to obtain my private data stored on the encrypted zfs pool inside my VM ? […]
Yeah, it’s not so much a limitation of ZFS encryption in and of itself, but the fact that everything builds on top of each other in a hierarchical fashion, hardware → OS → VM → software in VM. ? If any underlying layer is compromised, you cannot establish trustworthiness at the upper layers anymore.​
[…] As long as an attacker controls the hardware he can simply watch you typing in the passphrase the next time your system boots up: Is this true ? and then how ? […]
Ask yourself: Where is decryption performed, where’s the decrypted data processed? Do I fully trust this entity? ?​
[…] Now, for privacy reasons I want private data not be accessible to my friend. […]
Well, then just don’t store them there? Harvest now, decrypt later. ?‍♀️ Encryption is a tool, not some invincible magic.​
[…] inside my ubuntu VM […]
Note these forums focus on using a FreeBSD system. ? There are some minute differences between using OpenZFS on Linux vs. on a FreeBSD system, but as far as I know none of them relate to ZFS encryption. Keep that in mind for future posts.​
 
The only solution here is to use the new AMD VM scheme where the host cannot read the VM's memory. I don't know how far that is developed and what hypervisor can use it, if any yet.

In case you don't realize, obviously your friend can just access your encrypted data when your have it mounted. No reason to sniff the keyphrase first. The system does not have a barrier restricting access to the mounted filesystem to your login session.

The private key can be obtained from memory, but not from storage. And as you say, it is being made a little hard.
 
If you want to store data at an untrusted location, it needs to be encrypted before it leaves your trusted machines.

You can do this with encrypted ZFS,(send the raw encrypted stream, but never the key) but you won’t be able to ever decrypt it in the untrusted zone with any confidence that it is unavailable to the attacker.

You can also do this with any number of other tools. But I wouldn’t decrypt it on the attacker-hosted VMs.
 
Back
Top