Open kfjahnke opened 1 year ago
mhogomchungu
commented
1 year ago Sorry for a late reply.
Your usecase is safe and it is subject to security of sshfs since clear text data from your encrypted volume will be going though the network.
I can not seem to be able to reproduce the problem using zuluCrypt along so maybe the problem is with sshfs side.
unlock your volume using zuluCrypt and then suspend and see if the volume is still unusable without going through sshfs
kfjahnke
commented
1 year ago Your usecase is safe and it is subject to security of sshfs since clear text data from your encrypted volume will be going though the network.
I'm not sure what you mean. If this use case is safe - as I assume it is - it's safe because no clear text goes over the ssh connection. The sshfs mount can't know what the local system does with the ciphertext, in fact it should be perfectly unaware of the nature of the data. During transport - i.e. over the internet - the data should even be doubly encrypted: once because the container is encrypted with LUKS, and once because ssh uses transport encryption for all traffic.
What I was wondering about is attacks which can monitor ciphertext over time (on the remote system), but I suppose this is more of a LUKS question than a zulucrypt issue, so you're probably the wrong person to ask about that.
I can not seem to be able to reproduce the problem using zuluCrypt along so maybe the problem is with sshfs side.
Okay, I'll see if I can solve the problem in some other way. Thanks for your reply!
mhogomchungu
commented
1 year ago Yes, in your use case, there is no way any person who has access to the remote computer can gain access to the contents on your encrypted volume. I misunderstood your use case the first time i read it.
cryptsetup 2.0.0 introduced "Authenticated disk (sector) encryption" and you can use this feature to guard against tampering of your encrypted volume. Go to below link and read the "Authenticated disk (sector) encryption" section to learn more.
https://fossies.org/linux/cryptsetup/docs/v2.0.0-ReleaseNotes
I have found an interesting use case for zulucrypt: I use a LUKS container on a remote machine which I mount via sshfs. Subsequently I use zulucrypt to open the sshfs-mounted container on my local machine. This works well so far, both with remote machines in my LAN and with remote machines accessed via the internet. In a way, this is a 'native' way of providing secure storage on remote systems, without need for external software. The solution is 'intelligent' enough to only update deltas, so writing to the zulucrypt-mounted file system only produces traffic reflecting the modifications.
Now I have one annoying hiccough with my solution: I keep a persistent sshfs mount of a remote system which I access frequently. The persistence is mediated by specific sshfs parameters:
'-o allow_other,password_stdin,reconnect,ServerAliveInterval=15,ServerAliveCountMax=3'
The 'allow_other' seems to be necessary for work with zulucrypt (I can't get zulucrypt to create or work with the container otherwise) and requires uncommenting the allow_other line in /etc/fuse.conf. The remaining parameters reconnect the shhfs mount if the connection goes down - I send my own system into hibernation when I don't use it and the remote system reconnects every 24 hours with a new IP - I access it via a dyndns service.
The problem occurs when I try and access the zulucrypt-mounted file system after the reconnect (like, the next morning). The sshfs mount reconnects as intended, but the zulucrypt mount of the sshfs-mounted container becomes unusable, producing i/o errors when I attempt to access files. I can reestablish the zulucrypt mount by unmounting and then remounting the conatiner. I suspect that the reconnected sshfs mount (to a different IP address) doesn't play well with zulucrypt - this may be due to zulucrypt itself or due to the underlying software (LUKS, fuse etc). Do you have any helpful hints regarding this issue?
And, while I'm at it, what do you think of this use case security-wise? I suspect that it may be vulnerable to attacks which can monitor the ciphertext over time, but apart from that I'm quite confident it's safe: the connection via ssh(fs) protects the traffic, and on top of that, de/encryption is done on the local machine only, so no unencrypted data are transmitted. Of course I'm not a security expert, so I'd be happy to see a more informed opinion on the subject!