How to keep your data encrypted and still be able to securely search over it, without constraining the app architecture? In data security, we say “you should try searchable encryption!” Let’s shine a new light on it here!

Here’s an example. You store valuable encrypted data (like PII and fin data) in a database. Some app backend interacts with a database, reads/writes data and some client app uses the data. The task is to allow the client app to find requested data without decrypting it neither on the database side nor on the app backend side. 

You can have several ways to go.

• For example, you can download your (huge) database, decrypt it locally, and search for results. That’s a basic, non-practical, and insecure way. And, technically, it’s not a “search through encrypted data”. What’s next?

• When your database uses data-at-rest encryption, it stores data encrypted on a disk but decrypted in memory. So once an application reads the data from the database, the data response is in plaintext (although the database might send it back to the app using TLS). Again, “not a search through encrypted data”. Next.

• Let’s talk about field-level encryption when data fields are encrypted before storing in the database and stored in encrypted form. Typically, encrypted data is binary data. If strong encryption is used, encrypted data looks like gibberish and it’s almost impossible to guess the original plaintext data. This approach is used when the application (backend or mobile) is responsible for data encryption/decryption, and called “application-level encryption”.

• Anyway, you can implement searchable encryption, e. g. store your data encrypted in the database, yet be able to run simple queries on encrypted fields without decrypting them. Never let database server and app backend see decrypted data? – sounds great! 

How to make data encrypted but searchable? Using special encryption ciphers or a combination of them. You might know about FHE, which is one of emerging techniques, but most experts say that it’s not ready for production usage yet. 

Another approach is to use a “blind index”. This idea is based on using strong, industry-proven ciphers, like AES-GCM, to encrypt the datafields, but to calculate a “searchable hash” (aka blind index) first from the original field. The database stores hash and encrypted value of the field. When search is required, the backend application also calculates a blind index of the search query and then runs a database command to compare indexes. This approach works especially well when the data is stored and processed in SQL databases.

Is it a silver bullet?

We always emphasize that in security there is no one-size-fits-all solution. Searchable encryption is definitely possible but whether it will be a good fit for your system depends on its risks & threats profile. Sometimes encrypted data should remain just encrypted. 

To decide whether you should use searchable encryption in fintech, make choices depending on your situation. For example, take into account specific demands towards performance efficiency and affordable speed of secure search schemes work.

---

This blog post is written by Pavlo Farb, a Security Engineer at Cossack Labs. We help companies to protect their sensitive and valuable data.