Encfs + Dropbox: How to keep your cloud files secure?!

[mara.k...@gmail.com]

Hi,

I just installed Qubes OS and I feel its freakin awesome!

I am trying to set it up the way I want and one thing on my list is having a dropbox vm that provides simply just the cloud storage... I would like to run the actual encryption on a different qube because I dont at all trust dropbox.

How would I setup a qube that runs dropbox and exposes its filesystem securely to another qube that runs encfs which in turn can then be used to safely store & view cloud files via qubes OS standard file sharing capabilities?!

My idea was to run NFS on dropbox qube and connect to NFS with the encfs qube, but that's in several unfortunate.

1) I don't trust NFS
2) NFS is unreliable in combination with EncFS

I want to get rid of the network connection...

How would you solve this?

Thanks a bunch!

[Chris Laprise]

The operative word here is 'expose'... There is probably no secure way
to share something as complex as a filesystem, which is why Qubes has no
built-in file sharing capabilities.

You could use qvm-copy-to-vm or the equivalent in the context menu of
the file browser... but that copies whole files between vms.

You could also create one disk image per vm on dropbox, and somehow set
them up as loopback devices in the dropbox vm. This allows you to
'share' data to client vms as disk blocks using qvm-block, which is far
less risky than sharing filesystems. You would also have to encrypt the
disk images in each client vm to make this truly secure.

Chris

[Drew White]

"Encfs + Dropbox: How to keep your cloud files secure?!"

The answer to the question is "You can't"
There is NO WAY to secure files in DropBox or any other third party cloud system that can be accessed by the entire world.

Create your own cloud on your own servers behind your own firewall in your own office/house, and then secure it, then you will have a "cloud" system that isn't really a cloud (because you know where it is and also where your data is) that is relatively secure.

[mara.k...@gmail.com]

@Chris

Thanks I will think about this block-level approach.

@Drew

I don't agree... Storing encrypted files on dropbox IS secure in the sense that nobody in the world will be able to decrypt them (as long as the encryption step is not exposed to the dropbox process, which might be compromised). Of course dropbox can delete all your files instantly, but that is another matter. I use dropbox as cloud backup and if they delete everything it doesn't really matter, unless I lose all my own backups at the same time.

[mara.k...@gmail.com]

What do you think about this:

Encfs-Qube contains plaintext & encrypted files and has a cron job that runs like every hour. This job will SSH into dropbox-qube and run Rsync to project all the changes onto the dropbox-qube (but ignores all the changes inside dropbox, which would also be nice in case dropbox deletes everything or modifies encrypted files etc.)

Dropbox-Qube just contains the public SSH key and see only encrypted files...

Is SSH + Rsync reasonably safe? Or do I have to assume an attacker could easily break into the encfs domain once he compromises dropbox? Remember that Rsync will not promote any changes in the dropbox domain back to the encfs domain... It will discard all the changes inside dropbox instead.

[mara.k...@gmail.com]

PS: SSH alone is of course not very ideal, because this could mean I am running rsync of the dropbox qube. Instead I could use SSHFS to mount the dropbox qube's folder in encfs and then use the rsync of the encfs qube to sync the files via SSHFS. This is like super indirect, but probably safer?!

[Raphael Susewind]

IMHO the safest option is indeed to use a split-dm kind of approach, as
suggested before: create a loopback file in the dropbox VM, expose this
via qvm-block to your working VM where you then do all the encryption
(using standard LUKS) and can either mount the thing right there or -
for extra security - expose to yet another VM, again using qvm-block:

dropbox VM: loopback file -> /dev/loop0 -> exposed with qvm-block to
crypto VM: /dev/xvdX -> dm-crypt -> /dev/mapper/plain -> exposed to
work VM: /dev/xvdX -> mounted somewhere and used as usual...

The only caveat is how Dropbox behaves if you have a file in it that
serves as backdrop for a loopback device - any thoughts on this?

Raphael

[Drew White]

If they can get access, whether encrypted or not, it means it's insecure.

[Drew White]

If they can get access, whether encrypted or not, it means it's insecure.

Encryption just takes time to break.

If you have encrypted files, encrypted with a STRONG password THEN a 2048 bit cypher, THEN it will probably take about 6 months to decypher it and get the data out.

[mara.k...@gmail.com]

I think you need to educate yourself a bit on the topic of encryption. Encryption is secure if you use it correctly. Too secure actually, it's much more straightforward to simply torture the information out of someone...

And unless there is a backdoor in AES-256 (which why ideally you would always use a combination of several ciphers), it is technically and theoretically unbreakable if you used a 256-bit random key. It's much more likely that someone will social engineer his way to the data. Matters are entirely different with current public key algorithms, which may very well be broken via quantum computers, so I wouldn't bet my money on that horse... On the other hand those are not the algorithms you use for backup anyway.

[mara.k...@gmail.com]

I dont have any references at hand, but back then when I decided to go with EncFS, I also looked at the block-device method. IIRC, Dropbox theoretically does handle giant files very well (actually it's pretty irrelevant what you store), but there were problems with syncing obviously (try accessing this device on multiple machines) and also with write-through and general integrity. It just had a lot of quirky corner cases and while EncFS + Dropbox isn't perfect for syncing either, it has worked flawlessly for over two years now (with daily use)...

So for me, EncFS seems the way to go, unless you unmount the file system and flush it before activating dropbox but that is kinda unstable from a human error perspective...

[Chris Laprise]

Ssh may add some security against things like MITM attacks, but you have
to trust who you're connecting to as well. From a Qubes standpoint it
matters because the non-crypto parts add a bit more complexity, and
adding rsync adds substantially more. SSHFS is probably more complex and
attackable than both of those together. That, along with TCP/IP itself,
is attack surface.

The way you're describing it makes it seem like any successful attack on
one of those components in the dropbox vm could be repeated against the
encfs vm. I think most Qubes users would consider that too risky for
handling sensitive info, or interfacing with highly trusted vms. It also
means you need to keep extra copies on your drive.

What I described involves no extra copies, and if the dropbox vm becomes
compromised then there is very little it can do to attack your other vms
that are using the data. Ssh between the dropbox vm and dropbox is still
a good idea in this case, and you might even want to use SSHFS or
whatever else would allow you to map disk images in that vm. The dropbox
vm could be considered 'red' and your client vms (which encrypt and use
the data as mounted disk image) could be 'blue' or whatever. I think
this is worth a try because its more secure and probably less complex
than what you're suggesting.

Of course, with Qubes its up to the user to weigh the risks and make the
decicions. Good luck...

Chris

[mara.k...@gmail.com]

I don't disagree with you...

But your approach has several usability downsides. Although I am reconsidering this, since in the end I might be able to live with a "once per hour" dropbox sync which would open many doors for options like the ones you described.

Thanks :) I will think about it and try it out.

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Please take a look at this previous discussion on the topic
(including some warnings I gave that also apply to your case):

https://groups.google.com/d/topic/qubes-users/DkaVGj5pL2I/discussion

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJX3FtGAAoJENtN07w5UDAwWE0P/3hsgaWqvXTdgnRLwtNSIkVk
0cEAzWrRkFs92QnpsI77jswwbi/7kxXKxef8j67WKnklAVL9zrOvJ9vL4sJ9KspT
qdXB5vdHu0tFtytlKmXOqhYxkB8h9YmPknWGTtYtBtUo4GoE1EuR+ycQJQAjBq6R
R8no1yP2pBCCBTnKNvvkMQgOezMXKGoTIlr8dnq0S1N+jzUqovtxgzmr6bfPCHpP
9Aq8bTBi7fzGPv9/adZuda10VQ+qCR2ovxetI3XqLUsw6w9Ltm5sCY666AmzosK4
89i41uy77Xvv6cTuvWofIvfjVes6sc0AIEPrhcrc8A/HTeCeQ2sjlTOU/RHx9dUH
Y6v0u7hv5RwVLzVVGuBYGtjWfmW95uJKhvphBMCh+NXKAVFTrqPc8QRNGQXBrnE8
IgITBCZhQZ2ZsRC+N1puE54Re/2YJoPpep5DTNGI/X6kt3T1CXRfa4muJ/CqA9Z9
uqC22+enpX32ijhCNW9O1CgrM/+gMxUjpmlYLFDIdYFUDu5Tkyt3cjSQIH9uSG/Z
0I8FPPnz7oBocMmsET2JzOgIe3ZyKs8Fd39/PEpkw4orKDk51MAS9HDoRlPWC2/2
9sP+MUMS+8HItT3VUsA0Qn4l56S7pE5ujpUIZiqdXw9aZ2gGcqp8zDiaJNlh6y2r
SHOYZi1/PEwgnykWyM4o
=l4tX
-----END PGP SIGNATURE-----

[rac...@gmail.com]

> So for me, EncFS seems the way to go

I looked into using EncFS with Dropbox, but from what reading I did it seemed that EncFS was (1) old and not well maintained and (2) insecure whenever an attacker can see more than one version of the same file (that is, see the same file before and after a modification). Version 1.8 supposedly fixed some of the issues but this issue about being able to learn about a file's contents when it changes remains (as far as I can tell from reading around). Since Dropbox can always see files before and after modification (that's kind of the point of it), EncFS seems like an insecure choice to use with Dropbox.

So I'm still looking for a good solution for encrypting a single folder that will be synced.

Of course, Dropbox itself would be considered a security risk by many who are interested in Qubes. Myself, I'd put up with it if I could localize it to a dedicated AppVM.

[mara.k...@gmail.com]

Okay I have now installed Qubes OS on my work PC which also supports VT-d :), so I had a chance to look into this more deeply.

I see that EncFS is old and maybe not fully secure. Unfortunately there don't seem to be good alternatives. Also the vulnerability primarily focuses on manipulation, not decryption. Since I only push to Dropbox, but dont fetch anything, this is unlikely to be a problem. Also the data I am pushing is not that important. It's personal but I am not a dissendent or something, so I don't "really" have anything to hide. I don't think EncFS is a security hole, unless some state sponsored actor really takes a liking to you... They would also need to have access to dropbox in the first place, which isn't easy. I actually trust Dropbox enough that I don't believe they will go trough the trouble of breaking my EncFS encryption ^^. Like... What for? I doubt I am on any NSA list yet... Well on the list you get on for googling Snowden and downloading Qubes OS, okay, but that's probably a list with millions of entries ;).

I tried the block-device approach, it doesn't work. Dropbox can sync only the "changed" blocks, yes, but for that it needs to scan the entire 200 GB file for changed blocks which is a freaking nightmare, power-consumption wise...

So my current setup is:

1) Dropbox VM: Runs dropbox and keeps a local copy of 200 GB EncFS files (only encrypted)
2) Vault VM: No internet connection. Has a plaintext copy of the 200GB EncFS files.

Now I just mount the Vault VM's loopback device with the encrypted EncFS files inside the dropbox VM and issue an rsync command to update the dropbox VM's local copy. Then dropbox will updated the changed files...

Not exactly as smooth as I expected but I guess that's the price you have to pay for maximum security ;)