Encryption at Rest: Whose Threat Model Is It Anyway?

I&#x27;ve read the article and the entire comment thread and nobody is talking about <i>the cloud provider itself</i> ... ?<p>When someone borgs[1] up their data to store at rsync.net we just assume that <i>we are the threat</i>. Of course I don&#x27;t believe that but it&#x27;s perfectly rational and we encourage people to <i>think of rsync.net as a threat</i> as they design their backups.<p>Comments in this thread are actually discounting the threat of Amazon personnel, GCS personnel, etc., as if that threat was zero.<p>Not only is it non-zero, I would go further: if you&#x27;re storing the data on AWS and generating your keys on AWS and managing your keys with AWS ... you&#x27;re doing it wrong.<p>[1] <a href="https:&#x2F;&#x2F;www.borgbackup.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.borgbackup.org&#x2F;</a>

This article is so narrow-minded ..<p>I&#x27;ve work with physical servers in many compagnies. Every time, storage devices have a lifecycle : they are bought new, then plugged (and some data are written), then some times then move in another physical location, then they &quot;die&quot; (= put to the trash, either because they broke or for other reasons).<p>Encryption at rest is an efficient way to secure data for the latter cases.<p>The workers stole a hard disk ? No data is stolen.<p>A hard disk is lost during transit, somehow ? No data is stolen.<p>The device which is broken is retrieved by someone, opened-up, and being read-at directly ? No data is stolen.<p>Your old device, put to the bin for some reasons, that could still be read if plugged on the proper hardware ? No data is stolen.<p>All of that with little performance impact, and no software modification, few engineering overhead, very little work to do. It eases the lifecycle of storage devices, because storage devices are now worthless per-se (except for their physical cost, indeed). They carry virtually no data, no worth.<p>Can you propose any other way to protect against those thread models ? Rewrite every software, so that every programs handle their own private keys ? Yeah, that&#x27;s a nightmare, not gonna happen. And even if it did .. how would you encrypt your rootfs ? Ha yes : encryption at rest :)

In my experience, a lot of the motivating factors for large enterprises mandating encryption at rest aren&#x27;t about specific security controls. They will often hand wave in that direction, but as as the OP says in their post, without being able to describe a coherent threat model.<p>Instead a lot of motivating factors I&#x27;ve seen are about preventing various paths for &quot;legitimate&quot; data disclosure to third parties. For example, when data at rest is combined with additional requirements like &quot;bring your own key&quot; it means a subpoena or NSL needs to be served on the _first party who owns the data_ (as they need to provide the keys) and can&#x27;t be served on just the cloud provider without the first party having at least visibility of it.

Salesforce has an addon product called &quot;Shield&quot; that cost 30-50% of your overall license cost. It allows for encryption at rest at the field level (not all fields are supported and introduces query limitations). Companies purchase this add on thinking it makes them more secure, but it essentially does nothing to protect your data from exfiltration. If Salesforce&#x27;s raw, multi-tenant data stores are leaked it seems unlikely that your company is going to be the ones taking heat for it. The only reason to go through this trouble is to check the regulatory box. Also it seems like Salesforce should be encrypting the entire disk at rest. Instead they created this feature to charge a premium to those with regulatory requires and try to shift the liability.

I&#x27;m a huge fan of MSSQL&#x27;s transparent data encryption in situations where we have more than 1 client per database engine, and we want to separate the data physically.<p>I worked on a project where separate databases (a la Postgres) tied to separate clients wasn&#x27;t enough. Postgres still can read across the databases.<p>With TDE we tie the key to the individual clients meaning even if the engine messes up, since the connection isn&#x27;t made with the right key, you still can&#x27;t read the contents.<p>We still did encryption at rest as that comes for free these days, for reasons mentioned here in the comments.<p>I just wish Postgres would come with TDE. Paying for software is fine, but the cost of MSSQL is way more than $0. In fact, it&#x27;s usually cheaper to set up a Postgres instance per client. That way, when the engine messes up, well, there is only data of that client.<p>And I know a database is unlikely to mess up. I&#x27;m more likely the culprit, and as such I prefer to have my guardrails.

Funny I always considered the impetus of Encryption at Rest to be the &quot;left my laptop in the airport scenario&quot;. Or, maybe, &quot;Where&#x27;d that CD with all of the medical records go?&quot;<p>Originally, I never felt that the EAR issue was that germane at data centers, since you&#x27;re mostly protecting against someone backing through the loading door with a truck and stealing trays of drives.<p>The disposal issue is valid, that was just something we were diligent with using a secure disposal service.<p>Key management has always been an issue. Since no one wanted to be there when the machines spooled up after a glitch at 3am to type in a password to open the volumes. Everything else is basically locking the file cabinet drawers and taping the key to the back of it.<p>Nowadays, it&#x27;s different. Its more ubiquitous. Encrypting a laptop is a mouse click, and painless after that. Cloud providers have the infrastructure to manage it at their level.<p>I&#x27;m still now sure what the solution is for a &quot;self hosted&quot; infrastructure. Hardware key modules are still pretty expensive. I haven&#x27;t (not that I&#x27;ve looked at all recently) seen a writeup of how best to set of encryption on those 4 Dells my friend has racked across the country in Georgia (though even modern machines have some level of volume encryption I think).

The author used the term &quot;unknown unknowns&quot;. This is a variant of the way I talk about this state: &quot;you don&#x27;t know what you don&#x27;t know&quot;.<p>There are two audiences for this articles then, the ones who know what they don&#x27;t know (or know it all), and those like me who are ignored-squared.<p>I found it extremely helpful to help me &quot;know what I don&#x27;t know&quot;. If you have no idea what &quot;encryption at rest&quot; is or why it is important, then this is very useful and helpful.<p>As the author clearly states it does not cover other things you don&#x27;t know, like why and how to use full disk encryption.<p>That said, it would be helpful for us i² [i squared] folks to have some of the more basic terms explained. Although &quot;encryption at rest&quot; is somewhat understandable, it would be pleasant to have it explained. For example what are the other kinds of encryption that are not &quot;at rest&quot;?<p>There are a bunch of diligent amateurs out here, ones who know we don&#x27;t know what we don&#x27;t know and are attempting to build cryptographic things. We learn not to create our own implementations for example, but articles that specifically address us are good.<p>[edit for clarity]

I think reason is simple &quot;encryption at rest&quot; == &quot;it is going to be encrypted in backup&quot;.<p>People asking about &quot;encryption at rest&quot; are really asking if backups of your web application data are encrypted.<p>Earlier I think it was quite a plague when just un-encrypted backup files were leaking out because someone exposed them on some open FTP to &quot;quick and dirty&quot; copy backups to new environment or to some test environment - and forgot to close it down or remove the files.<p>Other threat would be developers exposing database server directly to the internet because someone from marketing wants to connect &quot;new shiny super business intelligence&quot; and developers not knowing better than &quot;allow all&quot; on firewall, then someone might steal raw db files but might not really have access to web application and encryption keys.<p>For the reasons mentioned by author I can see how it seems like security theater. But I think my reasons are quite valid and on topic.

I wonder if OP works in healthcare, after HIPAA passed encryption at rest was the buzz word of the decade as it was one of the primary requirement of HIPAA.<p>The problem of course being, most health care breaches are on applications that aren&#x27;t at rest so all the data was being stolen anyway.<p>From 2012-2021 I worked in health tech and on many calls with large customers and security questionnaires were on whether we were actually storing their data encrypted at rest. We even had to get audited for Aetna to validate encryption at rest (amongst other things). To me this seemed like such a joke of a requirement because all our data was in AWS, and breaches were far more likely from other avenues.<p>So to me this reads as a jaded SWE or CISSP who has dealt with how much attention this one attack vector is paid, but ultimately it is kind of a given now in modern cloud infra.

This might sound like a stupid question, but I&#x27;ll ask anyway:<p>What benefit does encryption at rest solve for something which is never intended to actually rest?<p>For example, a MySQL database powering a web application is expected to be alive and responding to requests 24&#x2F;7. It&#x27;s never really intended to be at rest.<p>So what benefit does encryption at rest bring? Won&#x27;t a hacker be attempting to take data when it&#x27;s online (and therefore not resting)?

Encryption at rest is nice for when a device has to get retired. Without the key, the drive is indistinguishable from random noise. No longer do you need to run DBAN for hours, put the drive through a degausser, or drill holes in it. No worrying about plaintext data hiding due to relocated sectors or wear-leveling. Just purge the keys and you’re done. Then the drive even has a chance at getting responsibly reused.

&gt; The first question to answer when data is being encrypted is, “How are the keys being managed?” This is a very deep rabbit hole of complexity, but one good answer for a centralized service is, “Cloud-based key management service with audit logging”; i.e. AWS KMS, Google CloudKMS, etc.<p>This is of course the beef. What&#x27;s the best practice in managing user data keys so that data is available only when there&#x27;s an authenticated user around? There are ways to derive keys from the secret exchange involved in user authentication.

Full disk encryption or similarly transparent data encryption at the database allows you to continue to use the database as a full database.<p>Decrypting on the &quot;client&quot; (app server) means you can&#x27;t really use its native query language (SQL) effectively on the encrypted columns.<p>Not sure what the state the art is in searchable encryption for db indexes, but just trying to do stuff that requires a scan becomes untenable due to having to read and decrypt on the client to find it or aggregate it.<p>The security sandbox becomes app server memory instead of db server memory preventing effective use of the locality on the db server. I didn&#x27;t see the article address this.<p>Can make sense to encrypt specific sensitive columns that are not used for searches or aggregations later, but many systems the reason you have discrete data columns is to query them later not just retrieve a single record to decrypt and view on screen vs just storing a single document and encrypting &#x2F; decrypting.<p>Disk encryption is easy to use without reducing the functionality of the DB, client encryption specifically and purposely handicaps the functionality of the DB so its use case is very narrow IMO.<p>I tend to treat both the app server and db ram as unencrypted so they require good access controls to use them (don&#x27;t let Bob run sql queries against all the data unless he is authorized to do so).

I once reviewed a php library (don&#x27;t remember which one but it was extremely popular) using `mb_strlen($string)` to get bytes to encrypt&#x2F;decrypt. It was just waiting for someone to come along and en&#x2F;decrypt with a non-english language.

An issue that wasn’t mentioned: protecting an encryption-at-rest <i>key</i> is not so easy, and the solutions I’ve heard of that are easy to deploy are barely effective against an attacker with physical access to the datacenter.

The article has some great points but has an unfortunate title that has lead to an argument the author isn&#x27;t making.<p>The cryptographic details about preventing confused deputy are excellent and worth studying.

This blog post is a lot of words to say encryption != authentication.

Encryption at Rest makes it easy to reason about data hygiene, since access to the data is gated through access to the keys.<p>You want to delete data? Toss the keys. You want to confidentially process data? Make the keys available to a TEE or such. You want to prevent yourself from having constant access to the data? Let the client provide the keys. And of course, you want to protect the keys? Use an HSM.

In the context of cloud, it&#x27;s cargo cult security. Something somewhere says &quot;you must have encryption at rest.&quot; I find it very hard to believe Amazon&#x27;s or Google&#x27;s servers do not already have full disk encryption. So what are you protecting again? If you&#x27;re storing the decryption keys in KMS in the same cloud, you&#x27;re not hiding anything from the cloud provider. The only rationale I can think of for doing this is defense-in-depth, but seeing how many companies struggle to even get IAM right I doubt this would help much.<p>Security compliance and real world security are a universe apart. You have encryption at rest with mandated AES-GCM&#x2F;SHA512? Cool story bro, some teenagers just broke into your network with a bit of social engineering and a 6 year old CVE.

On the subject of Encryption ar Rest:<p>On AWS RDS, you can&#x27;t turn off encryption once you turn it on.<p>The encryption secret keys always stay with AWS and all you can download are the public keys.<p>So I&#x27;m not so sure what&#x27;s the point of encryption at rest in AWS except just to tick off a compliance and regulatory checklist.<p>The private key is with them anyway, just don&#x27;t encrypt and save few milliwatts of power.

Real life case study: We armed our servers (VPSes) to the teeth. Then an attacker gained access to our hosting provider&#x27;s administration panel. They used that to download our hard disk content.<p>Encryption at rest protects against this.

&gt; Then, if your server’s hard drive grows legs and walks out of the data center, your users’ most sensitive data will remain confidential.<p>&gt; Unfortunately, for the server-side encryption at rest use case, that’s basically all that Disk Encryption protects against.<p>If you aren&#x27;t able to self host, then encryption at rest is a real use case and the next best thing to actually controlling your data. That being said, obviously self hosting with FDE@Rest is the best.<p>Or you can end up like the people who lost their data [1][2].<p>[1] <a href="https:&#x2F;&#x2F;spectrum.ieee.org&#x2F;thousands-of-bitcoins-stolen-in-a-hack-on-linode" rel="nofollow">https:&#x2F;&#x2F;spectrum.ieee.org&#x2F;thousands-of-bitcoins-stolen-in-a-...</a><p>[2] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=g_JyDvBbZ6Q" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=g_JyDvBbZ6Q</a>

Encryption at rest is something your cloud provider does to pass SOC audits. End of sentence. If you have stronger security concerns, then you need to turn to other tools in your toolbox.

The main threat to encrypting health information is actually dishonest cryptographers.<p>The quality of healthcare privacy reasoning is like, instead of searching for user Michael Knight in a database of cancer patients, you hash the name, use a bloom filter to determine if the hash exists in the protected data set or not, and then tell your regulators and the public that the foreign jurisdiction research assistants hired from fiverr don&#x27;t have access to your health information because everything is encrypted and we only compare hashes. it&#x27;s like that &quot;sudo make me a sandwich,&quot; cartoon but, &quot;cryptographically disclose your health information.&quot;

Encryption at rest is misleading. It is often used to describe an insecure situation consisting of disk encryption only instead of encrypted data store values.