Encryption in use with PostgreSQL

"I've never found it hard to hack most people. If you listen to them, watch them, their vulnerabilities are like a neon sign screwed into their heads" - Elliot Alderson | Mr Robot

If you've ever seen Mr. Robot, you know that infiltrating systems starts by compromising the individual. Honestly, the show does a pretty damn good job at demonstrating how easy it is to gain access to systems by taking advantage of people. It also highlights how important data is to businesses and their ability to provide value to their customers. So in this post I'll cover some data security practices for a very popular database, Postgres. I'm focused on data security in Postgres, but the principals can really be applied to any systems that stores information.

To start, a lot of people are using managed Postgres services. Managed Postgres is valuable, and there are quite a few services in the market today. Crunchy Data, Supabase, AWS RDS, Azure, Digital Ocean — all these solutions are great. Data backups, disaster recovery, high availability, connection scaling, and day two operations ready. What more could you want from a database as a service solution? Coming from an ops background, these are certainly all the features I'd be looking for in a partner / platform.

What about security? Well, they certainly have you covered with encryption at rest and in transit, give you the ability to apply row level security policies, and manage most of the network security controls. But what if you're looking to take your data security posture beyond these capabilities? Say you have a customer that applies some extra pressure on your ability to ensure their data is handled with the utmost care, or you want to protect your organization from the steep financial fines incurred from a data breach.

That's where encryption in use comes into play.

Encryption in use

First off, what even is encryption in use? Most people are familiar with encryption at rest and encryption in transit. Encryption at rest protects you from bad actors infiltrating the physical on-premises and ripping the hard drive right out of the server rack. Let's be real — is that really even a threat these days? Not really, because encryption at rest has become such a standard that every single managed database solution enables it by default, and good luck getting into those facilities on foot. Encryption in transit is similar, in that that TLS is standard for essentially all internet traffic especially for database connections.

With both of those solutions, the moment the database software accesses the data from the disk, the data becomes decrypted. With encryption in use, that is not the case, the data stays encrypted even when in use (now you see where the name came from).

But why should you care?

Well if the data is encrypted at rest on the disk, in use by the applications (including the database software), and in transit over the public internet, then no person or program (malicious or not) would be able to see the plaintext data.

Security.

But there are quite a few obvious issues if you are simply keeping the data encrypted at all time. Firstly, the plaintext data is what brings value to your business so it needs to be readable by authorized individuals. Second, your applications need to maintain functionality by manipulating and querying the data. We can solve those problems with access control to provide authorized individuals the ability to decrypt the data, and apply encryption techniques that allow applications to query and manipulate encrypted data without accessing the plaintext data directly.

Searchable encryption

To address the ability to query and manipulate data, we can look to a solution in searchable encryption. There are a few different kinds of searchable encryption and the most popular being homomorphic encryption. Homomorphic encryption, functionally, works great, but in practice it simply can't keep up with applications query throughput. In short, performance is so bad it renders even basic web applications unusable.

Luckily for us, there have been advancements in the cryptography field that address this issue. There is an encryption scheme called Order Revealing Encryption which, when implemented properly, gives you the ability to perform querying operations over encrypted data with very little performance impact. If you want to read the academic whitepaper, here is the link, but I won't get into any of the particulars in this post.

Access control

Apply access control to a layer of your architecture that will decrypt the data if the individual initiating the query is authorized. Sounds easy enough, but this also presents its own challenges that I'll dive into in a future post.

Conclusion

If you are handling highly sensitive data, want to improve your data security posture, or comply with data privacy regulations this approach is definitely worth looking into.

I work at CipherStash as the Head of Solutions, and we make it easy to implement encryption in use for any Postgres database. We believe that everyone should be taking the step towards I put together a playground environment to demonstrate it in practice if you want to give it a go. Cheers!