Cloud
1/26/2017
10:30 AM
50%
50%

There's No One Perfect Method For Encryption In The Cloud

The problem with encryption is that it affects performance, especially in the cloud. Know the different methods so you can pick the type that best suits your needs.

Security teams are torn between the quest to encrypt everything and the technical feasibility of doing so. The advantage of encryption is that it obscures data, even after a breach, and satisfies privacy regulations. But it can also obstruct application performance, especially when applied to data in cloud services. 

Concerns over government inspection of data, service provider breaches, and insufficient access controls all drive interest in encryption in the cloud. Many companies have internal policies or regulatory compliance standards that require data to be encrypted, with keys managed by the company (rather than the cloud provider) before it leaves their control. Security teams look for encryption schemes with the strongest possible data protection capabilities. Business and application owners want to preserve the functionality of underlying cloud applications. So what's the "best" type of encryption?

The Functionality vs. Security Trade-off
A scheme's security is always at odds with functionality in the cloud. No encryption scheme offers full cloud application functionality and performance with unmatched crypto strength. When implementing the strongest security, critical features of SaaS applications may fail. For example, search, document preview, graphically rendered data, and logical operations may break when data is encrypted. In other words, it's possible to secure data to the point where it's no longer useful. 

Teams charged with evaluating encryption in the cloud should take a three-step approach: 

  • Understand their company's functionality and security requirements 
  • Understand the best security level an encryption type can achieve
  • Select the type of encryption that balances all goals for their intended uses

Let's examine the relative strengths and weaknesses of various encryption approaches. 

Regular (Unstructured) Encryption
The primary goals of regular symmetric key encryption are data confidentiality, data integrity, and sender authenticity. 

The strongest schemes hide all useful information about the data: the key, the message, any bit of the message, and any function of the message. Schemes can also provide data integrity and sender authenticity, meaning an attacker can't create a valid ciphertext or modify a legitimate ciphertext without the user noticing. Regular encryption should be used for any data that requires the highest security, even at the price of losing search and other functionality.

Selective Encryption
Selective encryption only encrypts noncompliant substrings of a larger piece of data. This category of scheme might be used to encrypt sensitive data to ensure regulatory compliance while leaving other data unencrypted to preserve as much functionality as possible. This method is commonly used to encrypt data within collaborative content-sharing cloud applications, intranets, or extranets where personnel may be working jointly on a project. 

Sensitive data fields such as a Social Security number can be encrypted with regular encryption. Assuming one's inspection and identification policy catches all references to the sensitive value, its security ends up fully protected. At the same time, end users may lose search functionality on this data.

Format-Preserving Encryption
Format-preserving encryption (FPE) retains the format of the original text. Using FPE, a company may take a credit card number and encrypt it so that the resulting ciphertext is a 16-digit number — helpful when an application requires a specific format. Typical scenarios requiring format preservation involve protection of credit card numbers and Social Security numbers. With FPE, the application field validation rules still function correctly while the underlying data remains encrypted. FPE leaks equality between plaintexts — that is, patterns between plaintexts and ciphertexts — and fails to provide data integrity and sender authenticity. Equality leakage allows some forms of statistical attacks, which take advantage of frequency information observed in large sets of ciphertexts to make guesses about plaintexts. So, if attackers know that the most frequent plaintext was "cat," they can look for the ciphertext that arises most frequently in the database and infer that its plaintext is "cat." Email addresses are a typical application of FPE. 

Searchable Encryption
Regular encryption hides data so well that search becomes impossible. But searching on encrypted data is possible if one sacrifices some security. This category of encryption leaks the equality of keywords, enabling certain statistical attacks similar to the frequency attacks discussed above. Different types of searchable encryption result in different extents of leakage, exposing data to varying levels of risk. 

Order-Preserving Encryption
Order-preserving encryption (OPE) is a searchable encryption method by which ciphertexts preserve the order of plaintexts. The ability to index, search, and sort encrypted data in external servers gives enterprises flexibility in their use of cloud services. Using OPE, an organization can protect numeric or alphanumeric fields while preserving functionality such as sorting and range queries.

Practitioners should realize that leaking order means other related information is leaked. A worst case for security arises when all possible plaintexts are encrypted: an attacker can sort the ciphertexts and know that the first ciphertext encrypts the first plaintext, the second encrypts the second plaintext, and so on. Even when smaller amounts of data are encrypted, some specific OPE algorithms have even been shown to leak up to half of the plaintext. One should tread carefully when considering using it to protect high-value data. 

Data Tokenization
Tokenization creates tokens for each plaintext, stores data and tokens locally, and then passes the tokens to the cloud application. This approach preserves a great deal of application functionality, such as searching for keywords. 

This method works well for satisfying compliance rules for data residency. The security drawbacks are similar to those of searchable encryption. Local storage of data and corresponding tokens should be protected. Users must have access to the tokenization database, potentially causing issues for remote or mobile users. 

Fully Homomorphic Encryption
In theory, fully homomorphic encryption (FHE) lets the client ask the server to search encrypted data for any function of the plaintexts or to compute, say, the average of all encrypted numbers in a database field; the server won't learn anything about the data. While the theory is appealing, higher-level operations and real-world functionality are many years away. Even when FHE becomes feasible to use, linear search times are likely to be unacceptable for large databases.

Security teams need to communicate the trade-offs that come with technology decisions, and that road leads to encryption. While security suggests use of regular encryption for as much data as possible, functionality and legacy constraints may impede this. Newer approaches such as OPE and searchable encryption can potentially satisfy requirements when data can't be left in the clear. In the end, practitioners must weigh the trade-offs between security and functionality to arrive at the best implementation for their needs. 

Related Content:

Thomas Ristenpart is on the Skyhigh Networks Cryptography Advisory Board and is a professor in the Department of Computer Sciences at the University of Wisconsin. His research spans a wide range of computer security topics, most recently focusing on new threats to, and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Cloud Security's Shared Responsibility Is Foggy
Ben Johnson, Co-founder and CTO, Obsidian Security,  9/14/2017
To Be Ready for the Security Future, Pay Attention to the Security Past
Liz Maida, Co-founder, CEO & CTO, Uplevel Security,  9/18/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Security Vulnerabilities: The Next Wave
Just when you thought it was safe, researchers have unveiled a new round of IT security flaws. Is your enterprise ready?
Flash Poll
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
[Strategic Security Report] How Enterprises Are Attacking the IT Security Problem
Enterprises are spending more of their IT budgets on cybersecurity technology. How do your organization's security plans and strategies compare to what others are doing? Here's an in-depth look.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.