Data Storage: Who's Got the Encryption Key?
Encryption is a very basic security measure. But there are some serious issues swirling around encryption, especially if you have handed off your data to a cloud provider.
Encrypting data in-transit is standard and many service providers (SP) will give you the option of encrypting data at-rest. Don’t take at-rest encryption for granted because there is another step you must take. Ask yourself: when I direct my SP to encrypt my stored data, who decrypts? Who holds the keys to the kingdom?
It may be your cloud provider who holds your encryption key. Most of them will do their best to protect your data and keys. But it’s an uncertain world out there. Online thieves can steal the key, NSA can subpoena it, determined hackers can break it, and failing cloud businesses can take it down with them.
Let’s take a closer look at these very real threats to encrypted online data storage.
Hackers. A well-organized hacking group attacked an ecommerce website, stealing customer information including credit card numbers. The website owner admitted the data loss but thought that customer data was safe because it was encrypted. Sadly for the company, it had stored encryption keys on the same server that held customer data. The sophisticated hackers stole the keys right along with the information and promptly decrypted and posted the data.
Government. The NSA regularly taps large service providers for customer data and if you store your data with them you are vulnerable. Even if your data is encrypted, if the SP has the key they can decrypt your data. And if they are threatened by a subpoena, they probably will.
You may decide to turn your data over to the NSA if they subpoena you, but the point is that this should be your choice. Not the NSA’s and certainly not your service provider’s. Or what about the scenario where the NSA does subpoena you, you decide to decrypt and turn over your data to them – and you don’t have the encryption key. Imagine NSA’s sense of humor at that response.
Internal intrusion. Never assume that your data is kept private from the service provider employees. Most of them are honest to a fault -- but not all of them are and your data is at risk if they control your encryption keys. And while you’re at it, check to see that your provider carefully screens their employees and tracks their activities while at work. A tad big-brother-ish perhaps, but remember Edward Snowden? No matter what your opinion is on his activities, you probably do not want a Snowden of your very own.
Going Out of Business. Many online backup service providers operate on razor-thin profit margins and are close to failing or are actively looking to be acquired. If they have your encryption key you may or may not be able to get your data back when you need it. If they are the ones who own your encryption key, they may take your key – and your encrypted data – down with their ship.
Service providers are well aware of these issues around encryption keys. One common solution is storing their customers’ encryption keys separately from data, in a different physical server system or a different partition. This does work against outside intrusion but does not help much against internal employee mistakes or malice.
Many of them would frankly rather not be in charge of the encryption key at all, and prefer that you keep the key software for your own encrypted data. Some of the approaches require you to purchase and maintain an on-premise encryption key server. This does give you an additional layer of security by keeping the keys behind your corporate firewall, but defeats the purpose of cloud storage to reduce complexity and equipment purchases.
The Case for Two-Factor Authentication
Securing your own encryption keys is a significant part of securing your data. We recommend that you consider adopting two-factor authentication (2FA) for managing your encryption keys.
2FA is not limited to encryption but applies to any number of security processes. Its general definition is a two-part user authentication process consisting of two components. A bank card is an example: the physical token, the bank card, requires an additional security component to work -- a user-generated PIN. Another example of 2FA for physical security is a password code or keycard plus a biometrics scan.
2FA for encrypted data in an online data center works on the same principle: two authentication items are necessary to decrypt protected data. The technology differs in how vendors accomplish this. Some service providers offer two-factor encryption keys with the SP holding one of the factors and the customer holding the other. This secures your data against accidental or malicious decryption but still makes you vulnerable to SP failure or data loss.
Cloud provider SpiderOak offers a more sophisticated approach that requires access to a user’s mobile device. When a user logs in with an authenticated name and password, SpiderOak issues a temporary token to that user’s cell phone of record. The token is good for a single 12-hour period.
Some online backup providers offer their own encryption keys and do not depend on the SP at all. For example, Druva’s inSync software generates a unique encryption key for each remote user session. The user’s authenticated identity is the decryption key for that session only; at session end the key is immediately deleted.
Don’t Give the Bad Guys a Chance
No encryption technology is foolproof. IT must consistently practice good security throughout the storage stack with secure encryption at-flight and at-rest, highly secure user access control, and strong data center security. This applies to you whether you are the lone IT guy at a small business, generalist IT at a mid-sized firm, or an eagle-eyed InfoSec. When you encrypt your data online you need to take charge of the encryption key. Why give the bad guys a fighting chance?
Christine Taylor is a well-known technology writer and industry-watcher.
Photo courtesy of Shutterstock.