Application-Layer Encryption Defined

Let's Not Overcomplicate It

Definition: Application-layer Encryption (ALE) is when you encrypt data before sending it to a data store. There are many variations, but at its core, that's it.

Variations

There are three main ways in which implementations may differ:

1. Code vs. Service: In some implementations, the encryption/decryption truly happens inside the application, which calls encrypt() or decrypt() routines. In others, an intermediate service or proxy essentially does that for you.
2. Client vs. Server: Some systems are strict about only encrypting and decrypting data in the client, which brings zero-trust data systems using end-to-end encryption (E2EE). E2EE is a subset of application-layer encryption. But encryption/decryption may alternately happen on the server. For server-side application-layer encryption and SaaS, the most secure option is customer-held keys where each customer keeps their master KEKs in their own KMS. We've also seen hybrid models where some data is end-to-end encrypted and other data is server-side encrypted.
3. Key Management: This is where systems differ the most. Ideally, each piece of data gets its own key, called a document encryption key (DEK), and that DEK is wrapped by a master key or key encryption key (KEK). This is called envelope encryption. When done right, the KEK is held in a Key Management Server (KMS) where it can't be exported and is backed by a Hardware Security Module (HSM). There can be multiple different KEKs at a per-row, per-field, or per-tenant basis, and the KEKs should rotate regularly so the number of KEKs increases over time. But while that's a strong application-layer encryption approach, plenty of implementations reuse keys to encrypt everything the same way and store keys in insecure places.

Don't Fall for the B.S.

There's a pattern repeated by security solution vendors: as soon as some term starts catching on, the whole industry puts it on their website and says that's what they do. They expand and stretch the definition and muddy the waters until the original meaning is essentially lost. It can be frustrating.

For example, the term "zero-trust" is now prominent industry-wide, but few deserve the label. If you're curious, we break down trust definitions in our trust models blog.

"Homomorphic encryption" is another example. It has a very specific definition that's based on a mathematical abstraction called a homomorphism. But security vendors have stretched the definition to mean pretty much anything that involves the use of encrypted data. We used to get excited when we saw someone claiming homomorphic encryption. Now we mostly roll our eyes and move on. 🙄

The latest casualty is "application-layer encryption", aka application-level encryption, aka ALE. Which is what spurred us to write this blog.

But this is an easy one to check.

A Simple Test

Next time someone says they're using application-layer encryption, apply this simple test: if you had (possibly stolen) credentials and network access that let you query a data store, and you use that to fetch data, is any of that data encrypted when you get it back? It should be.

An alternate test: if your infrastructure provider gets a law enforcement warrant for your data, and they make the query, will they get back meaningful data? Or will it be garbled?

More concretely, if you've turned on encryption for your databases, key-value stores, or object storage in AWS, GCP, or Azure, that's great, but that isn't application-layer encryption. It doesn't matter if the KMS only accepts requests from certain applications. If the data is transparently encrypted at the storage level, it's not application-layer encryption.

Why It Matters

We've recently seen flaws in Azure that caused large numbers of Cosmos DB instances to be publicly accessible. Those impacted companies would have had much less to fear if their exposed data was non-transparently encrypted.

Another reason it matters is that it's surprisingly easy to accidentally expose data in complex cloud environments. One in five data breaches is due to cloud misconfigurations (per Ponemon). The classic example is when much of the Fortune 500 was found to have open AWS buckets. These issues would have been mitigated by non-transparent encryption.

As a final example, we have the latest T-mobile breach. A hacker got a foothold inside their network and then ferreted out their saved database credentials. Querying the database gave back unencrypted data including social security numbers.

Remember, transparent encryption is useful, but it mostly protects against stolen hard drive attacks and it doesn't help at all in these scenarios.

Application-layer encryption brings an important layer of protection that means extra hurdles and challenges for attackers. It completely foils many common attacks.

From Here to There

Application-layer encryption isn't a silver bullet, but it's critically important. And while the definition is simple, implementing application-layer encryption can be complicated and full of pitfalls. We've seen application-layer encryption schemes where people put unwrapped encryption keys directly in the database. We've seen a single key get used and reused for all values. We've seen designs where keys can never rotate. And that's the tip of the iceberg.

At IronCore, we've worked hard to make it straight-forward for anyone to add application-layer encryption to their app, even if it's multi-tenant SaaS. We've made it developer-proof so no one can accidentally do the wrong thing. If you'd like to understand how we might help you accelerate and supercharge your data security, let's talk.