Does Real Queryable Encryption mean there is a Fake Queryable Encryption?

TLDR

There is no “fake” queryable encryption, but a certain NoSQL database provider has coined the term “Queryable Encryption”, and Baffle has something to say about that.

Background

To understand real queryable encryption, we must first understand the encryption offerings that already exist.

The first encryption offerings to examine are database-side operations. As the name implies, the data is encrypted in the database. The two most common are transparent data encryption (TDE), where the database software encrypts the data before it is saved to disk, and full disk encryption (FDE), where the underlying operating system does the encryption before it is saved to disk. As far as anyone who can access the database is concerned, both are “transparent” because it happens automatically and without the user’s knowledge. These approaches to encryption were introduced decades ago when physical theft of hard drives was the primary concern. If somebody steals the encrypted drives and inserted them into their own computers, the data is protected. While physical theft is still a concern today, it is responsible for only 8% of data leaks. Hackers gaining remote access are responsible for 80% of data leaks with malicious insiders coming in at 6%.¹ Despite the convenience of database-side encryption, it clearly falls short for security.

The next encryption offerings to investigate are client-side operations. Again, as implied, the encryption is done on any application before writing to the database. Assuming the application implements access controls of its own, direct attacks on the database are completely protected. However, there are several downfalls. The first is that the application must be written to either do the encryption itself or connect to an external service (API), but in either case, this requires code changes. This may be very difficult for older applications and impossible if using a third-party application. The second issue is that the application is responsible for key management as well as the encryption itself, which can be an entire additional layer of effort to implement and manage going forward. Yet another issue with client-side encryption is a lack of centralized control. Imagine managing many applications across an enterprise, all separately determining what data to encrypt with what algorithms, and key mapping. The final issue with client-side encryption is that only equality matches (i.e. find or select a social security number) are possible when querying the database. Any operations that the database used to be able to do – such as sort, search, or math – are only possible if the application pulls all the relevant data and then performs these operations. This is potentially much more coding, very inefficient from a computing perspective and a security risk while the application handles all this data.
Our NoSQL friends have offered a client-side encryption approach for quite some time and, while it has been successful, has realized the shortcomings.

Queryable Encryption

For Queryable encryption, the existing client-side offering was used as the foundation, but additional modifications were done when writing records to the database. In a very simplified explanation, cryptographic metadata is added to the documents (being NoSQL) that enables additional search functionality. They also call this “Structured Encryption.” The industry might refer to this as “Privacy Enhanced Computation.”

The additional database-side operations this enables includes:

1. Range (find all dates after X and before Y, or find all transactions equal or greater than X$, etc.)
2. Prefix (return the first X characters of an entry)
3. Suffix (return the last X characters of an entry)
4. Substring (return the records with “dent”, which would include “Accident”)

This is a fantastic step forward for NoSQL database security, but that is the entire list of operations as of today. They also note that queryable encryption potentially increases storage needs by up to 5X.

Real Queryable Encryption

Baffle’s Real Queryable Encryption is with respect to SQL databases, so that is the most important thing to point out here. SQL and NoSQL databases are best for different applications, data, and use cases. But if a SQL database (like PostgresSQL or MySQL) is the correct solution, the entire point of SQL is to provide a standardized set of queries and functions that make a structured database so powerful.

Baffle implements a reverse proxy that operates at the SQL session layer between the application and database. At the highest level, the proxy encrypts when data is written to the database and decrypts when data is read. No application code changes are required. The proxy implements two-tier key encryption and manages all the key-data mapping. If Baffle stopped there, we would provide client-side security without the downfalls of application code changes and key management. But we didn’t stop there.

Baffle additionally adds user-defined functions (UDF) to the database that can communicate to the reverse proxy. When the proxy gets a SQL query, it breaks that query down. Operations on unencrypted data are simply passed on. Exact matches on sensitive data are encrypted/decrypted as required. However, database side operations are pulled out, modified, and sent to the UDF. The UDF decrypts the necessary data, performs the operations, and sends the results back to the proxy.

This approach enables a complete set of database-side operations including indexing, sorting, searching, and mathematical operations. Direct attacks on the database are neutralized. Even the DBA can’t access the data, and this includes any cloud infrastructure admins if the database is in the cloud. There is a minimal impact on performance and the storage requirements are contained to any difference in ciphertext vs plaintext (if any).

Conclusion

Baffle is the easiest way to encrypt SQL databases. The Baffle architecture provides the security of client-side encryption with the convenience and power of database-side encryption. No code changes or key management to worry about while still enabling highly performant database-side operations. All while protecting against remote and physical attacks on the database.

Request a Baffle Demo for Data Protection Solutions

¹IBM Cost of Data Breach Report 2023