I have written about the fuzzy mud puddle test before. It turns out it is misleading. Even a cloud storage provider that fails this test may still be able to decrypt your files without your explicit cooperation.
The problem is that many cloud storage providers, including more secure ones like SpiderOak and Wuala that implement client-side encryption, offer the option to share access to a file using a URL. Anyone with the URL can access the file over the web. From a usability point of view this is great: there is no need to install client side software. You simply (securely!) email the URL to your friends, and that's it. Unfortunately, it's also a security risk.
The URL sharing method works as follows. The URL typically starts with the server name of the cloud service provider. It is the cloud service provider itself that handles the request to give your friend access to the contents of the file. The URL also contains an access key to the file, that allow its contents to be decrypted. The web server of the cloud provider uses this key to decrypt the file.
And this is where the problem lies. By sharing a URL with a friend, the cloud service provider learns the access key as soon as your friend clicks the URL. This is against the 'zero-knowledge' (really a horrible abuse of a technical term by the marketing department of SpiderOak BTW...) pledge of the cloud service provider and totally defeats the point of applying client side encryption: the cloud service provider should never learn the encryption key. And with this U-turn, it does!
(Update: the extent of the compromise depends on the exact way the cloud service provider implements encryption and how it enables access using the access key. In some cases, the access key may only provide the decryption key for the file being shared, and no other files. In other cases it may reveal the decryption key for all files in the same folder where the shared file resides.)
Sure, the cloud service provider will claim they never store the key, and don't log the URLs their servers receive. But the problem is this: they may at some point be forced to do so, regardless of their promise. Like the US government did with major US web companies, telcos and Lavabit (the secure email provider Snowden used).
Conclusion: if you really want a secure cloud service, use one that doesn't offer the option to share access by passing around URLs. The browser is not a safe place to access sensitive files to begin with. And even though they (probably) mean well, the cloud service provider really cannot guarantee that they will not, at some point, store the access key and hand it over to the government. After all, they have to comply with the law...
Update (28-10-2013, 15:49 CET): The URL could contain the access key after a # sign in the URL. In that case the access key is not sent to the web server. However, malicious javascript code served by the webserver of the cloud service provider (CSP) still has access to this part of the URL (and thus the access key) and can upload it to the CSP regardless. As commented below, this is also possible if you use client side software provided by the CSP. But in that case you have more control, in that you can refuse to install updates. Better still: use a cloud provider who provides an open API and allows any open source client to connect to your data over that API.
Even if your provider has client-side security and offers no “convenient” means of giving them a key in order to get the plaintext of a file, as long as they ship you the software that does the client-side encryption, they could still be forced by a government or other blackmailer (or insider…) to leak your keys: by shipping you an “update” to the client-side software that leaks your keys.
So, don’t accept binary downloads (or even in-browser Javascript apps, which can change without you realising) from your storage provider, either. Download your choice of open-source encryption software through a trusted path!alaricsp:
That is exactly the approach that we offer to our customers. Our customers use Free and Open Source software, and we recommend that they get their binaries from a distribution maintainer such as Debian, Ubuntu, or pkgsrc, or else that they build it themselves from PGP-signed source code.
The question in my mind is: are there enough people who are willing to pay for this service? Is this a sustainable business model which provides more and more value to people, so that some of that newly created value will get reinvested in improving the service?
So, by all means please head over to https://LeastAuthority.com and sign up right now and let us know what your experience is. It will help us improve our product, and it will give you valuable experience in the practical realities of the security paradigm that you advocate. Also, you can back-up and share your files this way. ☺
Regards,
Zooko
[…] explained earlier that for web-based sharing with others, many secure cloud services effectively provide a backdoor. But this is even worse because apparently SpiderOak can provide the content of a file solely based […]
Dear Jaap-Henk:
You are precisely right, and this is an important caveat to the end-to-end security of a service like SpiderOak.
The end-to-end secure cloud storage service that my company provides — https://LeastAuthority.com — does not offer web access for precisely this reason. This is a heavy cost because it prevents us from offering a feature that would be very valuable to users. We’re trying to find a way to add it without compromising our security-first principles. In some sense, it is primarily a problem of communicating to the user about what the actual security properties are. It is interesting how many unsolved security problems boil down to UI/UX/documentation/communication problems.
As an aside, I disagree with this sentence: “The browser is not a safe place to access sensitive files to begin with.”.
Regards,
Zooko
Would love to hear why you think the browser is a safe place to access sensitive files.
Well, why do you think the browser isn’t a safe tool for accessing valuable files?
I guess what I see happening is this disconnect between groups of people, where one group is saying “That’ll never work.”, and the other group is saying, “Well… that’s what we’re doing!”. But the two groups are not really aware of each other.
That’s the situation today with a lot of cryptographers and security experts saying that the web is hopeless for security, at the same time that almost the entire population of the earth is rapidly moving to use the web exclusively for all of their most precious data and their most valuable interactions!
Here’s a post I wrote a couple of years ago contrasting Tahoe-LAFS with Freenet. One difference is that LAFS is web-compatible, and Freenet is anti-web, on security grounds.
https://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006560.html