Chuck Willis
October 25, 2022
Cryptography Data Security DevSecOps Encryption Key Management

Data at Rest Encryption: A False Sense of Security

When lay people think about computer security… well, they don’t frankly. But if you ask them about computer security, their first thoughts will likely be about data encryption. This makes sense – cryptography was practiced for millennia before the invention of computers and early computers were created to break encryption. More recently, users have been trained and conditioned to look for the padlock in web browsers to indicate that the connection is “secure” / “encrypted”.

Cryptography was also one of the original and fundamental mechanisms for computer security. Since those early days, many brilliant minds have worked to create secure cryptographic algorithms, modes, and protocols. This work has paid off, as well. Modern cryptography is exceptionally strong against direct attacks. Techniques like layered encryption and quantum resistant algorithms allow for even more security where desired – the only limitation is performance.

“Cryptography turns hard security problems into hard key management problems”

Attributed to Colin Percival @cperciva by

Complexity in modern cryptography comes down to key management. Cryptographic algorithms and protocols are designed to be open, so the only secrets are the keys used. If the keys are accidentally exposed to unintended parties, then the protected data is also exposed. If the keys are lost, then the data is also lost.

There are two predominant use cases for encryption: protecting data in transit (as it is communicated over a network link) and protecting data at rest (as it is stored, such as on disk, tape, or sometimes in memory). Thanks to TLS and its predecessor SSL, protection of data in transit is largely a “solved problem”. Because most keys in TLS do not need to be stored, encryption key management is much simpler. Asymmetric encryption and signing can be used to authenticate one or both parties in the communication. The parties can then securely derive session keys that only need to be available while the communication is occurring.

Data at rest, however, is a more complicated matter. Stored data generally needs to be protected and available for an extended period of time, so the associated keys must also be stored (or be reproducible). In fact, many data at rest encryption solutions are ineffective in protecting against modern threats. This because they are built upon the flawed Central Implicit Trust Model rather than based upon modern approaches such as the Zero Trust Model.

Central Implicit Trust Model

The crux of the Central Implicit Trust Model is that key system processes and users have access to plaintext data in order to perform their respective “jobs”. This includes entities such as the database administrators, system administrators, database servers, hypervisor hosts, cloud administrators, and cloud providers. Therefore, all of those trusted entities are targets for attack and potential exploitation.

Insider threats, supply chain attacks, Advanced Persistent Threat (APT) groups, and others will devote considerable effort into compromising highly trusted accounts and systems. Applications that use sensitive data are also trusted, so application-level vulnerabilities such as access control issues, authentication bypass, or injection can also provide attackers with access to plaintext data.

Case Study: Marriott Data Breach

In 2018, Marriott revealed a “massive database breach, affecting up to 500 million guests” resulting from “unauthorized access” to a database holding hotel guest records.” “Marriott did encrypt this information using Advanced Encryption Standard encryption (AES-128), but the company notes both components needed to decrypt payment card numbers may have been stolen.”

When trust is centralized, many encryption solutions are not effective because the encryption controls also honor the trusted entities. Full-disk encryption, transparent disk encryption, database encryption, server-side cloud encryption (such as S3 encryption and Blob encryption), file share encryption, and others are simply operating at a level in the system where they do not have the ability to discriminate between legitimate access and illegitimate access.

The storage encryption solutions mentioned above can be effective against one attack — physical theft of data storage devices. That threat is a legitimate concern for some devices like mobile phones, laptops, and removable media. However, in today’s cloud and data center environments, physical theft is very difficult and unlikely. In fairness, they do provide another benefit as well — they will often help with passing compliance audits.

Up Next

We hope this blog helped shed light on the problems with most data at rest encryption solutions in use today. Stay tuned for our next blog post where we’ll describe more effective approaches to at rest encryption, that incorporates zero trust security and DevSecOps principles.

Get radically effective data-level protection. Get Ubiq.