I found a potential security issue with the cache mechanism of the iOS version of Cryptomator (version 2.0), when the iPhone has automatic iCloud backup enabled.
When I unlocked a vault and viewed some files earlier, a 2GB cache was generated within the Cryptomator app, and it persisted after locking the vault. Some time later, my iPhone started the automatic iCloud backup (this, by default, included all the data within the Cryptomator app). Luckily, my iCloud account went out of storage space and a warning was displayed.
If there was enough storage space in my iCloud account, then the 2GB of cache files would have been uploaded to iCloud without me knowing it. As we all know, iCloud backups are NOT end-to-end encrypted.
Therefore, I want to ask: is the cache itself protected by encryption? If there is no encryption, this loophole would completely defeat the purpose (security target) of the app, which is to prevent untrusted cloud storage providers from viewing users’ files.
If it is really the case, I strongly suggest Cryptomator’s developers to add a warning message reminding users to change their iCloud backup settings to exclude the Cryptomator app; otherwise they should clear the cache every time immediately after locking their vault.
Edit: To answer your question, the cache is indeed not encrypted (and it has technical reasons for it, which is a bummer). It was a complete oversight from us since none of us is using iCloud Backup for exactly this reason (that it’s not encrypted) and unfortunately it didn’t come up during our beta phase.
Clear Cryptomator cache in settings every time you stop working with a vault or latest before going to sleep as the backups are usually done at this time.
FYI: fixed with App 2.0.4 (out now).
If you want to check and have a look into the size of the app backup, please be patient and wait until iOS has completed the calculation of the next backup size. Then the showed values for each app are updated (I wasn’t and was confused why it still showed several GB despite having the app updated)
It’s like copying both ciphertext and (invisible) plaintext to iCloud.
Funny indeed!
Why don’t developers think about such obvious errors?
Like, I am supposed to ever store user’s data on disk only in encrypted form. But hey, I am decrypting user’s data and storing it on hard disk in plaintext next to ciphertext, which 1) I am not supposed to do 2) and may leak anywhere, including to the same remote.
I apologize for this error and I’m glad that we have a vivid community that detects mistakes like this at the earliest. That’s why I love open-source projects. I would argue that this error wasn’t obvious since it didn’t come up during our long development and beta phase with several thousand testers.
There are technical reasons why the cache is stored in cleartext, which is not an error or oversight. In a nutshell, we are bound (and limited) by the File Provider Extension API. There are certain mechanisms at play that force us to have cleartext data readily available. (At some point, you need to have cleartext data, otherwise you can’t work with them.) We are convinced that this is acceptable because of the app’s sandbox and Cryptomator’s security target, which is not the device itself.
However, the security issue definitely violated Cryptomator’s security target and we fixed it as soon as we knew about it. And we’ll keep improving the app. E.g., clearing the cache after the vault has been locked in combination with auto-lock can certainly be helpful if you’d like to tighten the longevity of the cache.
