Researchers who developed a set of attacks against encryption schemes in CryptDB—a technology seen by many as key in creating secure cloud-based database applications—faced a rebuttal from one of the technology’s developers last week, who essentially claimed they were testing it the wrong way. In a series of e-mails to Ars, both the research team and CryptDB’s original lead developer have further responded to each other’s claims. And one of the researchers responded at length to the rebuttal in a blog post on Monday, further pressing his case.

As Ars reported last week, CryptDB is central to many efforts to easily add strong security to existing Structured Query Language-based applications—and to move some of those applications safely into private and public cloud database services.

“The awesome thing about CryptDB is that you can store your data in encrypted form without rewriting your apps,” said Charles Wright of Portland State University, one of the authors of the paper, in an e-mail to Ars. “That's what makes CryptDB such an exciting system, and why so many other groups have taken up the idea and run with it.”

Further Reading MS researchers claim to crack encrypted database with old simple trick

The technology, developed at MIT and first presented in a paper in 2011 (PDF), is intended to solve the problem developers face in keeping data secure not only while traveling over the wire, but at rest in the database on a server they may have no control over. It allows some SQL queries to be performed against encrypted data without the server—or even the application—having to have a key to decrypt its contents.

“The only thing that makes this magic possible (without special hardware) is property-preserving encryption,” Wright said—that it is possible to perform SQL queries against the data without decrypting it. While they conceal the actual data they encrypt, they preserve some aspect of the underlying data’s nature to allow queries to fetch, sort, and otherwise organize data without acting on the data itself.

The concern that the researchers (Microsoft Research scientist Seny Kamara, Muhammad Naveed of the University of Illinois-Urbana Champaign, and Wright) were focused on was that these schemes were too weak to protect sensitive data in some applications that might be used to perform queries. Two types of property preserving encryption were targeted by the Microsoft researchers: Order Preserving Encryption (OPE) and Deterministic Encryption (DET or DTE). These types of encryption are part of an “onion” encryption scheme used in CryptDB, providing a lower level of protection for ostensibly less sensitive columns of data in a database to allow calculations to be performed against them without having knowledge of their actual values.

The Microsoft Research team used various forms of statistical analysis to defeat that encryption in a sample CryptDB application—one based on real-world medical data stored in OpenEMR, an open source electronic medical records application. As a result of their attacks, they retrieved large chunks of data from database columns, as detailed in a paper to be presented at next month’s ACM Conference on Computer and Communications Security.

But Raluca Ada Popa, one of the original developers of CryptDB, told Forbes last week that the researchers hadn’t proven anything, because they were essentially using the weaker encryption schemes in the wrong way. She contacted Ars to explain further, saying in an e-mail:

I do not believe the findings prove CryptDB weak because the weak encryption schemes are not used to handle sensitive information. In CryptDB, database administrators can specify which data fields are sensitive, and CryptDB ensures those fields are encrypted with strong schemes that do not permit such attacks, and not encrypted with the weaker schemes. Admins are warned the vulnerable modes are only suitable for non-sensitive data fields such as non-sensitive timestamps (these additionally have 'high entropy' and are less vulnerable to leakage). Database administrators should therefore be careful how they use CryptDB for certain kinds of information.

However, Wright pointed out that the team had performed their test using an example application directly taken from the CryptDB team’s own paper. “If you look at her original paper where they describe the CryptDB system,” he noted, “our analysis is based on one of their own example applications. In Figure 9 in that paper, you'll see that in their analysis, OpenEMR has 12 database columns encrypted with deterministic encryption and 19 columns with OPE. That's because the application needs this information revealed in order to do its job. For example, to do any sort of triage, a medical records app would need the ability to sort patient records by disease severity. That column would then need OPE. The alternative is to spend a lot of time and effort rewriting the application.”

In his blog post, Kamara reiterated that the team had followed the pattern that any electronic medical record system would have followed—or else be rendered essentially useless, since using the higher level of encryption provided for by CryptDB would have made queries against the system impossible. “We believe it is fair to say that any reasonable EMR system would need to query these attributes,” he wrote. “We even confirmed that the OpenEMR system (which is used as motivation in [the original CryptDB paper]) queries sex, race, age, admission month patient died and primary payer. So the claim that we are using these systems in a way they were not intended to is completely unfounded.”

The methods used to extract data from these database columns didn’t “break” the encryption, Kamara noted, as the key used to perform the encryption wasn’t extracted, and not all of the data could be retrieved by the statistical analysis performed.

“But in our opinion, this is not a meaningful question anyways due to the way these PPE-based encrypted database (EDB) systems and their underlying cryptography phrase their security claims… For example, PPE-based EDB systems are typically claimed to be secure if a database administrator labels all “sensitive” fields (for some undefined notion of sensitivity) so that they are encrypted with standard encryption schemes. But of course, this also means that these fields then cannot be queried at all—ever. So this leaves us with an EDB system that only works over non-sensitive data. If it’s non-sensitive, one could ask how much value we are getting from encrypting it at all. Is this really the point of an encrypted DB system? To do SQL over encrypted non-sensitive data? Is this really consistent with how these systems are motivated and understood?”

In his e-mail to Ars, Wright added, “Using DET and OPE, but only when it's necessary for the app, is the killer feature of CryptDB. So I think it's quite a stretch to say that nobody would ever use that killer feature.”

Popa has obvious motivations to defend the PPE encryption schemes in CryptDB—including that she’s involved in a startup, called Prevail, that is applying some of the same development done for CryptDB to web applications using another project she worked on at MIT, called Mylar. Just how vulnerable data protected by PPE is, and how widely it can be used safely, will have a major bearing on whether CryptDB and Mylar can succeed going forward. In his blog post, Kamara said that he believed that secure encrypted database systems are still possible, but that, “More generally, our work does suggest that PPE-based EDB systems (i.e., based on deterministic and order-preserving encryption) might not be the way to go.”

“Clearly our team disagrees with Raluca on some of the finer points of encrypted database security," Wright said in his e-mail to Ars, “but ultimately these little disagreements are how science moves forward. Hopefully in 3-5 years we'll all be working on faster, more secure systems as a result.”