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?

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.

and three reasons for mistrusting them

Calling 256-bit AES "military grade encryption".

Having unencrypted access to user data.

Not providing source code.

and declare that ZumoDrive have successfully rolled a "hard six" reasons
why security-conscious users should avoid their service.

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.