Brilliant, funny, lame and unmentionable: Data Security Challenge Update

Last week we announced the first in our series of Cloud Storage Challenges. We focused this first challenge on security and specifically data encryption because we have repeatedly heard from customers that they are concerned with putting sensitive data in the cloud where it may be leaked.

Plenty of people fear that when they put their data in the cloud it may be vulnerable. And because they feel vulnerable, it almost doesn’t matter when we talk about the layer of encryption on their data, they still worry that even the strongest encryption could be compromised in the cloud. Our first demonstration was meant to change that perception. Cloud storage is unique among the cloud offerings in that the data can stay encrypted once it leaves a customer’s data center. Modern encryption -- if implemented correctly, as part of a fully secure design -- offers complete practical data security. The ‘if’ is of paramount importance and it is where the conversation needs to happen.

The commentary that came in response to our challenge ranged from “brilliant,” “funny,” “lame,” and even a few unmentionable things.  We expected some flack from the security community, of course, as the “challenge” we posed is fundamentally unwinnable.   The Nasuni Filer uses OpenPGP to encrypt all data and metadata before sending it to the cloud, and OpenPGP is effectively unbreakable. We picked an encryption scheme that, as one commenter noted, “has stood the test of time and hackers.”

So, what’s the point? Why offer an unwinnable challenge?

We wanted to open a discussion about the security of data at rest in the cloud.  What are the inherent weaknesses?  How can they best be addressed in a product while still keeping that product usable for as many people as possible?  To help that conversation along, we have published a security white paper to document our security design in detail.  Merely using OpenPGP is not enough, and the white paper gives the full story of the design.

So now that the conversation has started, let’s talk about some of the comments we received.

One individual made the point that encryption is actually the least likely place to fail in a secure system.  This is true.  Smart attackers look elsewhere for weaknesses, because in reality, most attacks don’t succeed directly against encrypted data.  The Nasuni Filer maximizes the time that data spends encrypted, in this “least likely place to fail” state, by encrypting at the edge, before data even leaves the customer's site.  The key to this data remains in the control of the customer, who is the only person who can be truly trusted with it.

Another commenter wrote: “The key to the problem, literally, is the recipient key... How is this recipient key stored securely in the cloud?”

Our security paper addresses this very issue; describing how our customer always holds the key - it is never stored in the cloud. We don’t ask our customers to trust the cloud to store these keys securely. We don’t ask our customers to trust us, either, so we do not have a copy of a customer’s key unless the customer chooses to give it to us. And even in that case, we have several measures in place to secure the key at our premises.

Someone else mentioned the possibility of performing traffic analysis of our read/write patterns.  For the attack to work, traffic analysis assumes that an attacker can snoop on the network at the customer site, at the network at the cloud site, or the network connecting the two – a feat that is not always trivial to achieve.  Even so, we have some countermeasures for this that we also discuss in the security paper, but briefly, all of our objects are below a certain size, and we batch our writes to the cloud so there isn't a very close correlation between a client write and a Filer write to the cloud. Fundamentally, though, any system can be traffic analyzed with varying levels of success.  The question is how useful is the data that can be learned - for example, it wouldn't be very surprising to an attacker to discover that a company does most of its writes between 9am-5pm on weekdays. On the other hand, a lot of traffic at non-business hours combined with a rumor that the company was about to merge with another one... well, the analyst would suspect something was up.  The famous (though surely apocryphal) example is that the local pizza delivery places around the Pentagon can tell when some large military operation is being planned because they get a lot of late night delivery requests.

Finally, getting back to the unwinnable contest, we support the Free Software Foundation, the umbrella organization behind GnuPG, an implementation of OpenPGP. When no one wins the challenge, we’ll donate the $5,000 prize to the FSF. The award amount we chose was really more of a donation – knowing that no one would win, we calculated a reasonable amount of cash we could hand over to the foundation. Sure, we could have just written the FSF a check from the start. But where’s the fun in that?