You’ve Encrypted Your Data in the Cloud, but are Your Keys Safe?

If putting unencrypted data up in a public cloud is like leaving your house unlocked, keeping encrypted data and the encryption keys in the same cloud could be akin to leaving a copy of your housekey under your doormat.

That, in a nutshell, is one of the mistakes that led to the Capital One breach last summer. A former Amazon Web Services employee found encryption keys where the data owners had hid them and made off with credit card application information of more than 100 million customers.

You can get all the ugly technical detail of the hack here.

But keeping the keys far from the data has its own problems.

Key Management Nightmares

Companies don't have just one encryption key. They have thousands – or sometimes millions. They need to guard access to these keys, rotate the keys, delete old keys, and have adequate backups for the keys, so they don't lock themselves out of all their data.

Companies typically opt for key management systems: hardware security modules or their software equivalents. They can run the modules themselves or sign up for key management as a service from a trusted provider. They can keep their key management systems in one cloud and their data in another.

For less mission-critical data, enterprises may use key management solutions by the same cloud providers that store their data and hope that they do a good job protecting their keys.

Storing the keys in a separate cloud can add some comfortable distance between them and the data. External key management can also help an enterprise manage multi-cloud environments.

AWS and Microsoft Azure have long offered key management systems that store keys in hardware modules in a secured area in a data center. They also offer the option to use external, third-party key management systems, said Chris Kennedy, chief information security officer and VP of customer success at AttackIQ. In December, Google caught up to the rivals, releasing its own solution for this, the Cloud External Key Manager, now in beta.

"Microsoft and Amazon have really stepped up to their target of being enterprise-grade," Kennedy said. "Now Google has recognized that to be a true enterprise app development type of environment,” this type of functionality is necessary.

Google’s external key manager allows Google Compute Engine Persistent Disk and BigQuery users to keep their data in the cloud and the keys elsewhere, Il-Sung Lee, senior product manager for Google Cloud, told us.

The system currently supports connections to five popular third-party key management solutions, he said: by Equinix, Fortanix, Ionic, Thales, and Unbound.

"Leveraging and managing a third-party key management system may introduce additional administration," he added. "But we’ve heard early feedback from customers that this is a worthwhile tradeoff for enterprises that otherwise would not be able to bring highly sensitive data into the cloud."

The system protects data at rest, he said, and is especially valuable in highly-regulated industries. "This capability is the highest level of encryption-based control that we offer to Google Cloud customers to date," he said.

Bringing It All Together

So, now you have your data and applications in one place, and your keys in another. How do you apply the former to the latter?

"I could keep the application on-prem" and bring the keys stored remotely to it when necessary, Ameesh Divatia, CEO at Baffle, a Santa Clara, California-based data security vendor, said. "But that's not a high-performance solution."

There’s also something called privacy-preserving analytics. That’s when data doesn’t get decrypted, and the application works with it in encrypted form. But not all functions can be done this way, several experts told us, and this approach can sometimes require significant rewrites of the applications, slow down performance, and weaken the encryption. (Divatia claims that's not the case with Baffle's technology, which, according to him, "supports all functions" and "does not require rewrites.")

Most often, companies go with the first option, bringing the keys to the application, temporarily. There two approaches to this, according to Peter Galvin, chief strategy officer at nCipher Security, an encryption technology vendor.

The "bring your own key" approach is when the application holds on to the key for a set period (an hour or a week), or until the key is revoked. The "host your own key" approach is when the application has access to the key only while it’s using it to decrypt or sign something. The key is never pushed into the cloud.

The application doesn't normally need to be rewritten or rearchitected to do this, Galvin said. "Usually you're just doing some type of pointer to go fetch the key. It's more of a configuration."

nCipher’s service takes this approach, and so does Equinix’s SmartKey, which can store keys for cloud storage, cloud applications, and even SaaS environments.

"You can run the application in the cloud and be able to main control of the keys," Lance Weaver, Equinix’s VP of product research and incubation, told us.

Salesforce, for example, stores and works on its clients’ most sensitive data: their customer data. An Equinix integration with Salesforce allows customers to keep their Salesforce data encrypted and use SmartKey to store the encryption keys in an Equinix data center, separate from Salesforce’s cloud.

"I would log into my Salesforce environment," Weaver said. "Then they would make a request to SmartKey for the keys. The keys would be cached but not stored anywhere inside Salesforce's infrastructure."

If that’s still too much risk – maybe someone is eavesdropping on the applications — then, using SmartKey, you can bring the application and the data to where the keys are. The application decrypts and works with the data inside a secure vault. This way, unencrypted data is never exposed to outside hackers, or to malicious insiders peeking into an applications' operational memory.

Equinix has a plugin that can run a customer's code inside the SmartKey service, inside the protected Intel SGX secure processing enclave. SGX (Software Guard Extensions) are instruction codes built into some Intel CPUs.

More on secure enclaves here: Azure’s Hardware Security Feature Takes Cues from Xbox One

Equinix’s isn't the only service that uses Intel’s SGX technology.

According to Faiyaz Shahpurwala, chief product and strategy officer at Fortanix – the vendor behind Equinix’s key-management offerings – Azure, IBM, Alibaba, and OVH all offer cloud servers that use Intel SGX.

"Google has announced that they will have it in the coming year," he added. "And I'm sure Amazon will also have it soon. When Intel comes out with their new chip, Ice Lake, hopefully everyone will have it."

Intel SGX, and other chip vendors’ secure-enclave technology, allow for runtime encryption, Shahpurwala said. "Even if hackers stole the box, they still wouldn't have access to that data."

Eventually, many SaaS providers may be running their applications inside secure enclaves. "We are still early in this journey," he said.

Secure Enclaves vs Dedicated Hardware

Interxion, Equinix’s biggest rival in Europe – that’s in the process of being taken over by its biggest rival globally, Digital Realty Trust – offers dedicated hardware security modules inside its colocation facilities. Additionally, it has partnerships with third-party providers that specialize in security services, Patrick Lastennet, director of enterprise at Interxion, told DCK.

At least for now Interxion has opted for dedicated security hardware over secure enclaves like Intel SGX. "There are some significant flaws and security risks attached to the enclaves, and there's been a series of vulnerabilities outlined," Lastennet said.

Traditional encryption technology is highly secure, confirmed Aanand Krishnan, CEO at Tala Security. "It is difficult to defeat if done right," he said. But running separate hardware security modules is costly and difficult to integrate with modern cloud environments. "If crypto engines are baked into the main processor chips – as with SGX – it's like maintaining another x86-class cluster. No separate appliances or HSMs are needed."