The Riverbed Blog (testing)

A blog in search of a tagline

Staying secure in the cloud

Posted by riverbedtest on June 16, 2011

Last month I wrote about assessing security risks and tradeoffs and described an alternate approach to measuring security and control in the cloud. This month I’d like to explore one aspect a bit more—encryption.

Cryptex Recently a colleague asked whether encrypting data with AES-256 on our Whitewater cloud storage gateway actually matters to customers hesitant to use the cloud because of security concerns. Does encryption help overcome worries about losing control of the physical infrastructure? If encrypted data is intercepted, does that matter? Are current algorithms good enough? My colleague’s neighbor is a former VP of storage at an ISP. The gentleman insists that it’s meaningless to discuss encryption “security” without having some kind of key management strategy and plan for regular key rotation. Is he perhaps just stoking fear?

Let’s deconstruct this, beginning by separating technology from process.

AES—or, specifically, Rijndael, the algorithm that AES uses—has withstood several years of cryptographic analysis. Since its introduction in 2001, a number of attacks have been postulated. Success has been demonstrated against weakened versions of AES, where the number of cryptographic rounds was intentionally reduced. These attacks fail when attempted against AES with the full set of required rounds.

The strength of an algorithm is orthogonal to an organization’s key management approach. If you operate under the assumption that an attacker has no access to the keys—which is a perfectly acceptable stance—then your choice of algorithm derives from a number of considerations:

  • How long does your data need to remain confidential? (guides selection based on strength)
  • What quantity of data do you need to encrypt? (guides selection based on speed)
  • Are there sufficient products that support the algorithm? (guides selection based on availability)
  • Are there regulatory guidelines that narrow your range of options?

We chose AES-256 because it’s fast, it’s well tested, and it meets Federal standards (probably the same reasons everyone else chooses it, too!). A Whitewater appliance generates a unique key during installation. Whitewater uses this key to encrypt all data as it enters. Data that’s moved to a cloud bucket is thus already encrypted. Furthermore, it even flows over an encrypted channel—we use SSL to authenticate the cloud endpoint and mitigate attempted man-in-the-middle attacks.

Keys At the cloud provider, the (encrypted) data is stored under the context of a customer account. The cloud provider doesn’t have the key, and also has no mechanism to obtain the key. So encryption eliminates the risk of clear-text interception by the provider. Furthermore, the provider’s access control mechanism makes it difficult for other customers to obtain the data. However, should that access control be breached and the data obtained nefariously, the attacker still has no access to the key, so the data is again useless.

The fundamental reason for encrypting a thing is that you have little control over how that thing is distributed or used. Thus, if the thing falls into the hands of an attacker, by encrypting it you’ve rendered it useless. Now, if an attacker somehow obtains access to your key, then even the strongest algorithm in the world can’t protect you. This should be an obvious statement. Poor key management doesn’t alter the strength of an algorithm.

So that covers the technology. What about process? Rotation of authentication keys is common because these keys are easily shared, both accidentally and maliciously. It’s quite uncommon to rotate encryption keys, though. The logistical challenges for this are rather high: you’d have to read every encrypted object, decrypt it, provably delete the object you just read, re-encrypt it with your new key, and then store it. Very time-consuming, as you can imagine. So yes, good key management is important to reduce the likelihood of the key falling into the hands of an attacker. But no, rotation isn’t part of that.

Ciphertext A Whitewater encryption key is tied to a customer and to a particular cloud storage bucket. Whitewater never stores the key in the cloud: so even in the worst case, if a provider experienced some kind of rare breach, an attacker would have access only to encrypted data. Without the key, such data is useless. The key itself is stored only in the appliance. Good key management discipline becomes important here, because if an appliance loses its key, the key can’t be recovered. For example, store two copies of the key at separate physical locations in locked vaults. Regularly check the integrity of the backup key copies. Also, audit each and every time a vault is opened and its key is checked or used. For even greater diversity of protection, consider escrowing the key with an independent third party.

This might seem rather simple, given the complexity of some key management processes. But how would a more detailed process be an improvement? Remember, complexity is the enemy of security. Having too many processes often invites attempts at circumvention, even by the most well minded of folks.

Encryption exists so that you can obtain a measure of confidentiality and privacy when you need to transmit and store information using systems that themselves can’t offer such assurances. So yes, encrypting data is the obvious and correct procedure to follow when using cloud storage. It’s difficult for me to understand why people would question this anymore.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: