Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

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
Threaded  |  Newest First  |  Oldest First
Navigating Security in the Cloud
Diya Jolly, Chief Product Officer, Okta,  12/4/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19551
PUBLISHED: 2019-12-06
In userman 13.0.76.43 through 15.0.20 in Sangoma FreePBX, XSS exists in the User Management screen of the Administrator web site. An attacker with access to the User Control Panel application can submit malicious values in some of the time/date formatting and time-zone fields. These fields are not b...
CVE-2019-19552
PUBLISHED: 2019-12-06
In userman 13.0.76.43 through 15.0.20 in Sangoma FreePBX, XSS exists in the user management screen of the Administrator web site, i.e., the/admin/config.php?display=userman URI. An attacker with sufficient privileges can edit the Display Name of a user and embed malicious XSS code. When another user...
CVE-2019-19620
PUBLISHED: 2019-12-06
In SecureWorks Red Cloak Windows Agent before 2.0.7.9, a local user can bypass the generation of telemetry alerts by removing NT AUTHORITY\SYSTEM permissions from a malicious file.
CVE-2019-19625
PUBLISHED: 2019-12-06
SROS 2 0.8.1 (which provides the tools that generate and distribute keys for Robot Operating System 2 and uses the underlying security plugins of DDS from ROS 2) leaks node information due to a leaky default configuration as indicated in the policy/defaults/dds/governance.xml document.
CVE-2019-19627
PUBLISHED: 2019-12-06
SROS 2 0.8.1 (after CVE-2019-19625 is mitigated) leaks ROS 2 node-related information regardless of the rtps_protection_kind configuration. (SROS2 provides the tools to generate and distribute keys for Robot Operating System 2 and uses the underlying security plugins of DDS from ROS 2.)