Untangling the encryption chain
Encryption can protect your data, but it can also play havoc with other storage applications.
Encryption would seem to be a critical technology in today's world of embarrassing data losses, but studies reveal that it's rarely used. So why is data that should be encrypted left alone, even as numerous products target this exact problem? Simply put, encryption is a chain, not just a single link, and unless each point in the data path includes encryption and decryption, other desirable functions are lost. Users have opted to leave their data unencrypted, relying on access control to keep data safe. But recent industry moves may change that practice.
From the top down
The first decision point in investigating encryption technologies is where to encrypt. If we think of the stack from application through operating system, network and storage device, we can see that encrypting data near the top (at the application or OS level) will protect it all the way down to the storage device. We protect data in motion (across the storage network) as well as data at rest (once it's stored).
But if you encrypt it at the application, only data from that app is protected. And how many applications truly stand alone without any supporting infrastructure or outside data?
The same problem applies to server-side encryption, often using an encrypting file-system driver like the one included in Microsoft Windows. If we encrypt at that level, all data from the server is protected through the network and on disk, but this would have to be enabled on all of the file systems and servers to have complete coverage.
Some vendors have begun supplying network-based encryption devices. These sit in-band in the Fibre Channel or IP network and encrypt all the packets they see. This eases management because everything flowing across the network is encrypted without having to install or configure software on a large number of servers. These devices are often deployed at the edge of a network where the perceived level of vulnerability increases.
If this type of device is located right next to the disk or tape, it becomes more of a tool to protect data at rest. This is especially useful when the storage media is tape cartridges, as they have a tendency to end up where they don't belong.
These appliances also relieve servers of encryption duties, often using specialized hardware such as custom chips designed to handle a particular encryption algorithm.
Why not encrypt?
So far, everything sounds rosy. We pick a location for encryption, plug in a device and our data is protected. But it's not quite that easy. Encryption is only as good as the access control around it, and you can wind up locking yourself out as easily as the bad guys.
First, it's easy to lock the doors and open the windows. By encrypting data "down the stack," we create a new vulnerability. An encrypting file system won't protect data from an intruder logged into the server--they could see unencrypted data as long as they're logged into the right account. Many exploits use a trusted application to enter a system; if your Web server software can see your data, so can any worm that infects it.
We also need to make sure that we don't lock ourselves out of the house. You can easily do this if you have too many locks that need their own keys. On the flip side, too few keys can be a problem, as well. Remember the legend of there being only eight Volkswagen Beetle keys? Supposedly, owners were often able to get into the wrong car and start it up. We therefore need to make sure that each data domain is encrypted with a separate key without having to deal with thousands of keys.
The trick is key management, an area on which more vendors are focusing their efforts. NeoScale, a leading maker of encryption appliances, recently introduced a specialized key management appliance called CryptoStor KeyVault (see "How to manage encryption keys"). This device manages encryption keys in a secure fashion, allowing a company to have as many keys as needed without worrying about not having the right key when it's needed. It's an especially interesting move, as appliances like this one might remove key management as a critical roadblock to encryption.
There's one big problem with encrypting data through a network, however. Encryption protects data from all types of examination, including the kind done by all of the other hot storage networking products. Want to do compression, deduplication, virtualization, advanced routing or archiving? Each of these features requires inspection of the data, and encryption can prevent them from functioning.
Let's start with compression. Lots of folks want to encrypt backup tapes, but many more are currently compressing that data. Compression generally works by replacing repeating patterns in the data with smaller placeholders. But encryption, by design, eliminates these commonalities. Run your backup stream through an encryption appliance and the result is uncompressible. In fact, it might even expand a little, according to one vendor I spoke with.
The same holds true for other technologies. Deduplication will find no duplication. Thin provisioning might think all the space is used. Anything that tries to examine the data stream will simply fail. The choices at this point are to have encryption of data in movement and no other features, to limit encryption to data at rest (after the others have had their say with the data) or to skip encryption entirely. Combine this headache with key management challenges, and most users decide to just skip it. In fact, a recent survey of GlassHouse customers revealed that just 20% of them encrypt backup data and even fewer encrypt storage on disk.
Building the chain
How can we break up this logjam? Let's look at another arena where encryption is actively being pursued--digital television. Without endorsing encrypted television signals (which I'm opposed to), we can still learn a lesson about how to approach encryption. The "end-to-end" encryption of digital television would still permit decryption and re-encryption at authorized points to allow advanced functions. For example, a future TiVo would receive an encrypted stream, decrypt it, perhaps re-encode or process it, store it and re-encrypt it before sending it to the television.
Let's apply this to storage. If we developed a system that allowed a deduplication engine or storage router to decrypt the data coming in and re-encrypt it after processing, we could enable encryption everywhere in the network. We'd be building a chain of encrypted segments.
Every device in the chain would have to understand the encryption scheme used and share keys to make this work. This would require an advanced key management system and open API to allow different combinations of equipment to interoperate. This last bit sounds like a job for the Storage Networking Industry Association (SNIA), but I don't see it happening yet. Maybe a vendor-specific API like NeoScale's will be adopted as a de facto standard.
Of course, there's another possibility. A vendor could engineer its own end-to-end infrastructure with completely integrated encryption at every point. Of course, it would need to have its products everywhere along the chain: software installed on the servers managing the storage, intelligent switches, virtualization appliances and arrays. It would also need some serious encryption and key management expertise.
When EMC bought RSA Security this past summer, many observers were left scratching their heads wondering where the fit was. Some suggested it was simply an opportunistic acquisition, others thought it was a defensive move to keep the company away from Symantec, while a few just threw up their hands and said EMC was crazy. I say the company was crazy like a fox! If anyone could pull off an end-to-end, single-vendor encrypted infrastructure like the one I just described, it would be the combination of EMC and RSA. Maybe encryption will happen after all.