Welcome!

Security Authors: Elizabeth White, Sharon Barkai, Lori MacVittie, Pat Romanski, Michael Shaulov

Related Topics: Cloud Expo, Java, SOA & WOA, Virtualization, Security, Big Data Journal

Cloud Expo: Article

Encryption in Use Deep Dive

What you need to know to secure and control your data

Encryption in Use – Fact and Fiction
Risk-conscious enterprises across the globe have been reluctant to embrace the public cloud model. For many, compliance requirements are the source of the reluctance. For others, concerns about ceding control of their data to a cloud service provider, without the cloud service provider accepting liability for customer data, is the major hurdle. Conforming to data residency regulations, when implementing a distributed services model, present a further complication. Even as these challenges to adoption loom large, the economics and productivity benefits of cloud-based services remain compelling. For these organizations to make the transition to the cloud, a range of elements must be in place, including continuous monitoring of the cloud service provider’s data center, enforcement of appropriate service level agreements, data classification and definition of internal processes to manage cloud-based services.  Encryption in use is a critical piece of this puzzle, since it provides a mechanism for the enterprise to extend their boundary of control to their data stored and processed within the cloud service provider's environment. However, not all encryption in use is created equally, secure, and a generic. A one size fits all approach is likely to fall short in providing a balance between security and functionality.

The Case for Encryption in Use
For almost as long as the field of information security has been in existence, encryption of data at rest and encryption of data in transit have served as cornerstone technologies to prevent access to sensitive, proprietary, confidential or regulated data. Both forms of encryption operate through exchange and presentation of a combination of public and private keys that unlock the encrypted data. The great step forward for modern cryptography was the idea that the key that you use to encrypt your data could be made public while the key that is used to decrypt your data could be kept private. The purpose of both is to ensure that only users or systems with access to the key could access the data.

Encryption in use provides functionality that is almost counter-intuitive to the purpose behind modern encryption for data at rest and data in transit, working to ensure that the data remains in an encrypted state, even as users interact with the data, performing operations like search or sort, for example. However, just like encryption for other states of data, encryption in use serves a clear need. Without encryption in use, organizations cannot retain ownership and control of their data stored and processed in a cloud-based service – whether control is required to address security, compliance, data residency, privacy or governance needs. Encryption in use is similar to format preserving encryption in that it is applied in real time, but allows for a far broader range of cloud service functionality and feature support.

Encryption in use enables enterprises to independently secure their data stored and processed at cloud service providers – while holding on to the encryption keys. The ongoing revelations of government surveillance that are supported by laws compelling cloud service providers to hand over customer data, highlight the challenge that end users face of meeting their obligations to retain direct control of their cloud data.  The recent set of recommendations from the Review Group on Intelligence and Communications Technologies appointed by the White House focused on implementing better privacy steps is only the first step in revisiting policies.

Because encryption in use is an emerging area, the technology can be easily misunderstood, or even easily misrepresented. Typically, encryption in use entails the use of a gateway, or proxy, architecture. The user accesses the application via the gateway – whether the application server is in the cloud or on premise.  The key to decrypt the data resides in the gateway (or in an integrated HSM), ensuring that data stored and processed at the server is persistently encrypted, even as the encryption is entirely transparent to the user. Were the user to access the server directly, bypassing the gateway, the data would simply appear as a string of encrypted gibberish.  As long as the gateway remains under the data owner’s control, only authorized users can gain access to the data stored and processed at the cloud service provider, or other third party.

In the event that the cloud service provider is required to hand over customer data in response to a government subpoena, they must their meet their legal obligation. However, if encryption in use has been implemented, the service provider can only hand over encrypted gibberish. The request for data must then be directed to the entity that holds the encryption keys. Likewise, a rogue administrator, a hacker or government entity would only be able view unintelligible gibberish if they gained access to the user account.

Not Some Kind of Magic
In order to deliver on the promise of encryption in use, the gateway must deliver on a robust set of functionality requirements: comprehensive service functionality and water-tight security based on a strong encryption scheme. What this means in practical terms is that the entirety of the service’s functional elements and behavior must be mapped, and that the encryption scheme must allow for preserving functionality without compromising security. This is because the gateway must recreate the session for the cloud-facing leg, and transpose encrypted data into the flow without disrupting functionality like search, sort and index.  Otherwise, the user experience is degraded, and the value proposition of the cloud-based service of improving productivity is undermined.

Vendors face another set of choices: take shortcuts to cover as much ground to provide a superficial sense of security, or invest in extensive R&D work to deliver the optimal balance between functionality and strong security. For instance, vendors can opt to provide encryption for a just a few data fields, out of hundreds or even a few thousand, to encompass a specific subset of the enterprise’s information. Equally, they can choose to implement a cloud data encryption scheme that preserves features relying on referential integrity such as sort, search and index that is easily reversible by attackers.

By way of illustration, if the scheme involves deterministically encrypting words into very short AES blocks, the encoding pattern is consistent enough for common attacks to yield clear text from what might appear to be encrypted text. There are a variety of iterative attacks such as chosen plaintext attacks that will yield clear text if the encryption relies on a simplistic and consistent encoding pattern. So while the data may appear to be encrypted, and less engineering resources are required to support application features and functionality, the data protection in place is barely skin deep.

Encryption in use is not a kind of magic – it requires dedicated engineering expertise, with collaboration between infrastructure, information security and encryption experts. And, the encryption scheme must be tailored to a specific application or service to deliver on the appropriate balance of security and functionality.

Another significant consideration is evaluating encryption in use in the context of a specific application or service. From the customer’s perspective, it is appealing to use a single encryption platform for multiple applications. No customer wants to have to manage multiple appliances, management interfaces and vendors. The reality, however, is that to strike an acceptable balance for any risk conscious organization between security and functionality requires deep application knowledge and encryption-in-use expertise. Dig a little deeper on degree of support, or risk a gamble on production readiness. The degree of support is as critical as the extent of support.

Evaluating Encryption in Use Claims
Can enterprises rely on a standard validation for encryption in use? Precisely because encryption in use is a new area, third-party validation is a critical requirement before it is implemented in production environments. Unfortunately, the current set of standard validation and certification tests have limited applicability.

The most frequently cited third-party validation by vendors in the space is FIPS 140-2 validation. As critical as 140-2 validation is as an evaluation benchmark, and specifically required under some federal procurement mandates, it has some limitations for encryption in use.

Taking a step backward, its important to note the scope of FIPS validation. The process essentially verifies that the algorithms are implemented according to defined specifications. However, it does not provide any validation about how the platform would use the cryptographic module in order to support encryption in use.

For instance, the FIPS validation doesn't outline a set of best practices on how to use the cryptographic module. Instead, it verifies that whenever the system invokes AES encryption, the module performs AES encryption according to the standard specification.  FIPS validation is limited to the cryptographic modules used, not the overall integrity of the platform, or the encryption scheme used in production environments. While FIPS validation is an important consideration, enterprises should be aware of its limitations as the sole third party validation for encryption. In an outside world example, validation would demonstrate that a $500 bicycle lock is impervious to any lock picking attempts, but when used to lock a bike to a fire hydrant, it does nothing to protect the bike from a thief simply lifting the bike up and driving away.

Hopefully this has been useful in helping you to determine the right approach your organization can take to secure and maintain control of your data. I look forward to hearing any further points I might have missed.

More Stories By Elad Yoran

Elad is Chairman and CEO of cloud encryption company, Vaultive. His nearly 20 years in the cyber security industry spans experience as an executive, consultant, investor, investment banker and a several-time successful entrepreneur. Elad’s entrepreneurial experience includes Riptech, the pioneering provider of managed security services to governments and Fortune 500 corporations around the world, acquired by Symantec Corporation, Sentrigo, a leading provider of database security recently acquired by McAfee, and MediaSentry, a provider of anti-piracy technology solutions to the motion picture, music and software industries, acquired by SafeNet. Elad has also served as Vice President, Global Business Development at Symantec and as Vice President at Broadview International (acquired by Jeffries), an investment bank focusing on mergers and acquisitions in the technology industry, where he led the firm’s information security practice. Elad has been recognized as “Entrepreneur of the Year” by Ernst & Young.