Skip to content

What Is ALE, and Why?

What Is ALE, and Why Do We Still Need It?

Application Level Encryption (ALE) means your application code encrypts and decrypts specific pieces of confidential data itself, before that data is written to (or after it is read from) storage. Correctly integrated, the database and its backups store ciphertext rather than those fields' plaintext.

This is a deliberate contrast with encryption that happens underneath your application, at the infrastructure layer.

ALE versus TDE / disk encryption

Transparent Data Encryption (TDE) and disk/volume encryption protect data at rest — the bytes sitting on a physical or virtual disk. They're valuable, but they solve a narrow problem: someone stealing a disk, a decommissioned drive, or an unencrypted backup file. The moment there's an authenticated connection to the database — a valid DB credential, a live query, a DBA doing routine maintenance — TDE decrypts everything transparently and hands back plaintext. That's the point of the "T" in TDE.

ALE can reduce the impact of direct access to a database or backup, because the protected plaintext does not need to reach the database layer:

  • A leaked or overly broad database credential
  • A SQL injection vulnerability
  • A well-meaning DBA (or a compromised one) running an ad hoc query
  • A backup or replica that ends up somewhere it shouldn't
  • An application bug that logs a raw query

For these cases, an attacker who obtains only the ciphertext still needs access to the relevant decryption capability and keys. This is an important boundary, not a blanket guarantee: ALE does not by itself protect against an attacker who can run application code, call a decryption path, obtain key-management access, or read plaintext from application logs, caches, traces, or responses. TDE and ALE are complementary controls; many production systems use both.

Where ALE sits in the application stack

ALE lives in the application/service layer, as close as possible to the boundary where data crosses from your business logic into persistence:

Client → API → Business logic → ALE (encrypt/decrypt) → ORM / Repository → Database

Your business logic still works with plaintext values — a cardNumber, an email — because that's what your domain rules, validation, and application behavior actually need. The encryption step sits right before that value is handed off to be persisted, and the reverse (decryption) happens right after a record is loaded back. From the database's point of view, nothing has changed: it's still storing strings and blobs. It just never has the key, and never sees the plaintext.

Key terms: tenant, key, ciphertext, IV, HMAC

A handful of terms come up constantly when discussing ALE — worth having a shared, precise vocabulary before going further:

Tenant
A logical isolation boundary for a distinct customer or client entity in your system, each with its own encryption/HMAC keys — so a data breach or key compromise affecting one tenant can't expose another's data. If your application doesn't have the concept of multiple customers, you can just think of your whole application as "the tenant."
Key
The secret material (and its associated metadata — identity, purpose, which provider or mechanism should handle it) used to perform an encryption or HMAC operation. How a key is represented in code has a big effect on how easily an application can later change how encryption is performed (a different KMS, a different algorithm, a different provider) — more on this in Key Aliases & Key Configs.
Ciphertext
The encrypted output. It can be decrypted only with the appropriate decryption key or capability.
IV (Initialization Vector) / nonce
Per-operation input used by an encryption scheme. Depending on the scheme, it must be random, unique, or both; it is normally stored with the ciphertext and is not secret. Correct nonce handling prevents repeated encryptions of the same value from revealing an avoidable pattern. With the usual randomized or nonce-based encryption schemes, you therefore cannot find a record by encrypting a search term and comparing ciphertext.
HMAC

A hash computed using a secret key. Unlike encryption, a HMAC is deterministic: the same input with the same key always produces the same output. That property is exactly what makes HMACs — not encrypted values — the thing you actually search and enforce uniqueness on, and it's exactly the gap left open by the IV above.

Why you need it: the IV is what makes an encryption scheme non-deterministic in the first place, encrypting the same plaintext twice, with two different IVs, produces two different ciphertexts. That's the point of the IV (it stops an attacker from spotting repeated values by comparing ciphertext), but it also means equality search and unique constraints can't run against the ciphertext column: the value you'd compute for a search term will practically never match what's already stored, even for an identical plaintext. A HMAC (or any keyed hash with the same determinism property) sidesteps that entirely, since it isn't per-operation and doesn't use an IV, hashing the same plaintext with the same key always produces the same output, so it's what you actually search and enforce uniqueness on instead of the ciphertext. More on the specific strategies for storing and rotating them in a later chapter.

Why do we still need it?

Encrypting things is extra engineering effort, so it's fair to ask why it's worth doing. The short answer: because most real-world data breaches don't involve anyone stealing a physical disk — they involve someone getting access to a live, running system, and the database sitting right there in plaintext.

Regulatory and compliance drivers

Regulations and standards often make encryption an important option, but they do not universally prescribe ALE. PCI DSS requires stored PAN to be rendered unreadable and allows several approved approaches; HIPAA requires a documented, risk-based decision on addressable encryption specifications; and GDPR Article 32 names encryption as one possible appropriate technical measure. Whether ALE is appropriate depends on the data, threat model, architecture, and applicable legal or contractual obligations. Treat this workshop as technical guidance, not compliance or legal advice.

Reducing blast radius when a database or backup leaks

Every additional place plaintext data exists is another place it can leak from. With ALE, a leaked database dump, exposed backup, misconfigured replica, or stolen snapshot can contain ciphertext rather than plaintext. If the keys and decryption services remain protected, that can substantially reduce the value of the leaked data. It does not remove incident-response, notification, or key-compromise obligations.

Tenant / customer data segregation requirements

If your application serves multiple distinct customers or organizations, each one is a tenant, and it can be useful to cryptographically isolate one tenant's data from another's. Per-tenant keys can reduce the scope of a key compromise and can help implement contractual or operational isolation requirements. They do not, on their own, satisfy legal data-access or deletion obligations; those still require the relevant data-governance and retention processes.

Why "encryption at rest" alone isn't enough

As covered above under ALE versus TDE / disk encryption, TDE only protects against someone stealing the physical media, not against the much more common case of an authenticated connection being misused. ALE is the layer that still holds even when the database itself is fully compromised, because the database was never trusted with the plaintext in the first place.

Confidentiality is not the whole security property

Encryption protects confidentiality; it does not automatically establish that ciphertext has not been altered. Production encryption delegates should normally use authenticated encryption (for example, an AEAD mode) or an equally robust integrity design, and should store the authentication data required for verification. The HMACs discussed later in this talk are deterministic search and uniqueness indexes. They are not, by themselves, authentication tags for the ciphertext and must not be treated as a substitute for ciphertext integrity.

The application also owns the boundaries around the crypto operation. Review ORM and serializer mappings, API responses, logs, error reporting, metrics, tracing, caches, queues, and debug tooling so that plaintext does not escape through a path outside the encrypted persistence model. Test those boundaries as part of integration and incident-response exercises.

From concepts to practice

The rest of this talk works through the concepts above — key aliases, structured ciphertext, key rotation, HMAC strategies, rekeying — one at a time, on their own terms, independent of any particular library or language. They're general ALE design problems that any application implementing this pattern has to solve somehow, whether it rolls its own solution or reaches for an existing framework.

The hands-on workshop that follows this talk puts these same concepts into practice using mango4j-crypto, a Java framework built around exactly this set of ideas — a key-driven design, pluggable providers, a choice of HMAC strategies, and built-in support for rotation and rekeying. Where the talk stays conceptual, the workshop is where you'll see one concrete implementation of it.