ZumoDrive rolls a hard six
I haven't had much time for blogging recently, but sometimes things come up which just beg for a response; case in point: A recent post to the ZumoDrive blog entitled "Sometimes you have to roll a hard six" about the security of the ZumoDrive cloud storage / backup service. I have to give credit to ZumoDrive for one thing: Unlike most online backup services, they published the reasons why they think their service is secure. Sadly, the credit goes no further.[EDIT 2010-03-11 18:00 I mention this below, but to place my conflict up front: I'm the author of the Tarsnap secure online backup service, which is in some ways a competitor to ZumoDrive.]
To quote from the blog post,
The file being uploaded is transferred to the ZumoDrive server which is hosted by Amazon's EC2 (Elastic Compute Cloud). It is done via 256-bit SSL encryption.Here's their first mistake: Trusting their security to SSL. There is one, and only one, good reason to use SSL for anything: It takes care of key management for you. When you're only talking to yourself -- or, as in this case, if you wrote both the client and the server code -- you can pre-distribute keys, and all of the complexities of SSL certificate handling (plus the question of whether or not you should trust the Chinese government) go away.
Next up we have this bit:
The EC2 is the workhorse. It's the liaison between the client on your computer and the ZumoDrive datacenter (which is hosted by Amazon S3; more on this below). It also services the ZumoDrive website.Even leaving aside the questionable subject "The EC2" -- I assume they meant "The ZumoDrive server hosted on EC2" -- this also raised my eyebrows. One of the keys to security is to keep separate things, well, separate -- that way, you reduce the potential for a vulnerability in one area to affect others. This is why qmail has five daemons (qmail-send, qmail-lspawn, qmail-rspawn, qmail-clean, qmail-smtpd) where other mail transfer agents have only one. Why should the security of your backups depend on whether someone can find a vulnerability in a web server?
A few lines further down, we have this classic goof:
[The ZumoDrive server, running on EC2] encrypts your actual file via 256-bit AES encryption and stores it on S3 (Simple Storage Service). AES is military grade encryption.As Bruce Schneier wrote in his famous list of signs of cryptographic snake oil, "Some companies claim 'military-grade' security. This is a meaningless term. There's no such standard." Many things have changed in the past decade, but this is not one of them: There is still no such thing as "military grade encryption". There are US standards covering the use of encryption to protect CONFIDENTIAL, SECRET, and TOP SECRET information; but merely using 256-bit AES is nowhere near enough: The entire encryption system needs to be approved (including block cipher modes, key management, vulnerability to side channel attacks, et cetera), not merely the choice of block encryption algorithm.
As it happens, there's an even worse problem: ZumoDrive is trying to keep your data safe on S3 by encrypting it on EC2. Stop and think for a moment: Who does this actually protect you from? The people who have out-of-band access to data on S3 -- Amazon employees, law enforcement, and the courts -- all have access to data on EC2; so if they want your data, all this does is force them to fish the decryption key out of ZumoDrive's EC2 instance.
ZumoDrive's security has another major flaw, too: ZumoDrive themselves. Data is uploaded not-very-securely to their not-very-secure server, which then encrypts it completely-and-utterly-brokenly (but with bogus buzzwords) prior to storing it on S3... during that process, the data is on the ZumoDrive server completely unencrypted. Anyone with access to that server -- which I'm guessing is most or all of the people who work at ZumoDrive, plus anyone who can steal their credentials (or install a trojan which steals their credentials) -- can access ZumoDrive data. Thanks to their automatic indexing of file metadata, they would even know where to find my_world_domination_plans.doc.
Finally, while I have to give ZumoDrive credit for admitting their faults (albeit unknowingly) on their blog, it's really not enough to see what they claim ZumoDrive does. As a FreeBSD developer (and Security Officer), I have to speak in favour of open source software -- not from the perspective of licensing, but simply because without seeing the source code (or doing a huge amount of work to disassemble and reverse-engineer a binary) there's no way to confirm that ZumoDrive correctly translated design into code.
The title of ZumoDrive's blog post -- sometimes you have to roll a hard six -- is a quote from Battlestar Galactica, but refers to the game of Craps where a "hard six" involves rolling a 3 on each of a pair of six-sided dice. In that vein, and taking a bit of poetic license, I'd say that ZumoDrive has rolled three security mistakes
- Relying on SSL for security when keys could be distributed out-of-band.
- Hosting their service on the same systems as their website.
- Encrypting data in EC2 and expecting that to protect it on S3.
- Calling 256-bit AES "military grade encryption".
- Having unencrypted access to user data.
- Not providing source code.
But who am I to speak? I'm just the author of a competing service -- Tarsnap. An online backup service which does not rely on SSL for its security; has its website hosted entirely separately from the backup service; encrypts data using keys held only by the user before uploading it; doesn't allow me to look at user data (because I don't have the necessary decryption keys); and provides source code for the client utility, so that you can see exactly what it is doing. In short, a backup service which does security right.