This is an interesting and important point that you raised.
> if you're storing the data on AWS and generating your keys on AWS and managing your keys with AWS ... you're doing it wrong.
This is a reasonable thing to do if you've decided that you trust AWS and expect any violations of this trust to be dealt with by the legal department.
It's less reasonable if you're concerned about AWS employees going rogue and somehow breaking the security of KMS without anyone else knowing.
It's even less reasonable to do this if you're concerned about AWS credentials being leaked or compromised, which in turn grants an attacker access to KMS (i.e., a government would be more successful by compelling IAM to grant access than they would trying to subpoena KMS for raw keys).
(Sure, you can audit access via CloudTrail, but that's a forensics tool, not a prevention tool.)
But that's kind of the point I wrote in the article, no? You need to know your threat model. You've stated yours succinctly, and I think it's a commendable one, but many enterprises are a bit more relaxed.
> It's less reasonable if you're concerned about AWS employees going rogue and somehow breaking the security of KMS without anyone else knowing.
That's the least of the concerns. Remember AWS is subject to court orders of all types (legitimate ones and NSLs). Even if nobody goes rogue, any data that AWS (or any cloud/SaaS provide) could access, must be assumed to be compromised.
> What's the best practice in managing user data keys so that data is available only when there's an authenticated user around?
What does it mean for an authenticated user to be "around"?
If you want a human to manually approve the decryption operations of the machine, but it can still store/encrypt new records, you can use HPKE so that only the person possessing the corresponding secret key can decipher the data.
At least, you can until a quantum computer is built.
A working definition for some apps could be: The user's data should not be available to the system if there isn't an active user session, such that the user's privacy interests are cryptographically protected in event of a breach or data leak occurring when the user is not actively using the system.
I wasn't thinking of manual approval of any cryptographic steps. Just that when you log in to work on your data stored in the system, the system can only then decrypt the data, and when you log out, the system forgets the keys until next time.
Okay, this sounds vaguely like a problem that may be solved by "HPKE where the secret key is reconstructed from a threshold secret sharing scheme" (>=2 of N shares needed, 1 held by the service and 1 held by the employee's hardware device, where 1 additional share is held in cold storage for break-glass reasons).
I would need to actually sit down and walk through the architecture, threat model, etc. to recommend anything specific. I'm not going to do that on a message board comment, because I probably am missing something.
> Obvious limitations is that you can't use the fields for sorting in queries (ORDER BY), and depending if deterministic encryption is not enabled, you can't use it in filters (WHERE) either. Same applies for any T-SQL logic on the data fields - because the encrypted blob is opaque to SQL Server - it is decrypted client-side. There is no workaround, except for pulling the data locally and sorting client-side.
The thing that's security theater isn't encrypting at rest in general.
The thing that's security theater is encrypting insecurely, or failing to authenticate your access patterns, such that an attacker with privileged access to your database hardware can realistically get all the plaintext records they want.
>> The thing that's security theater isn't encrypting at rest in general
> The thing that's security theater is encrypting insecurely
Security theater should be defined as:
Doing things that outwardly appear to improve security but have de minimus or less effect on actual security.
The 93 section questionnaire from bigco's IT department is security theater. Filling it out does zero to improve security for bigco or myco or my users.
IDK, I have multiple times seen significant practical security improvements as a direct consequence of some "93 section questionnaire" because the very first section had a few questions "Are you doing this simple, well-known best practice thing?", which they were not, because it took some time, effort and/or money and they just didn't care.
But once the questionnaire mattered, they started doing it just so they could legally answer "yes" to that question. Things like finally changing the default admin passwords on that service they installed a year ago, and testing backup recovery to find out that it actually can't be done due to a bug in the backup script skipping some key data.
> Doing things that outwardly appear to improve security but have de minimus or less effect on actual security.
Right. And that's exactly the situation the article describes.
The accusation of "security theater" was only levied when IT departments reached for the "full disk encryption" potion to mitigate the ailment of "attacker has active, online access to our database via SQL injection", when that's not at all what it's designed to prevent.
They can insist that they're "encrypting their database", but does it actually matter for the threats they're worried about? No. Thus, security theater.
The same is true of insecure client-side encryption.
When I joined Amazon, the team I was hired on was called AWS Crypto Tools (which owned the AWS Encryption SDK, among other developer tools), while another team was called Transport Libraries (which owned S2N).
When I left in 2023, they started adopting more of the "Encryption At Rest" lingo for what was previously called Crypto Tools. I don't know if they landed on different verbage since then.
> after HIPAA passed encryption at rest was the buzz word of the decade as it was one of the primary requirement of HIPAA.
Andy Jassy decided that it was time to Return To Office.
I was hired in 2019 as a fully remote employee. This means my options in 2023 were a) move to Seattle or b) walk. I chose to walk.
The leadership of the Cryptography org fought tooth and nail to get an exception for me, but were unable to do so. I still hold everyone in AWS Cryptography in high regard.
> The main threat to encrypting health information is actually dishonest cryptographers.
Wow, okay, you have me hooked.
> 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
The protocol you loosely described here could be either totally fine or horrendously broken depending on the implementation details and architecture of the application. Not to mention the universal cryptography concerns; i.e., key management.
> and then tell your regulators and the public that the foreign jurisdiction research assistants hired from fiverr don't have access to your health information because everything is encrypted and we only compare hashes.
You've said "hashes" twice now, so I have to ask:
1. Are they only hashing, or are they using a keyed hash (e.g., HMAC)?
2. Are they doing something ridiculous like using MD5?
If you're familiar with cryptography at all, passing around MD5(data) is vastly different from truncating HMAC-SHA384(data, staticKey) to a few bits and protecting staticKey with an HSM.
Without more detail, I can't tell if your assertion that cryptographers are being dishonest is warranted. It's sort of like simplifying RSA encryption to "multiplying integers". Yes, that's what's happening on some level, but some essential information was omitted.
in your hmac example you have a separate key to manage, whereas in my example, it's implied it's sha256 or a variant that provides a layer of obfuscation in the lookup, and may even implement a "standard" to fool regulators. most regulations and standards say what tools to use (key bits, algos, etc) , and not that the implementations need to be approved by a professional.
my example is that the scheme uses tools in a way that is meaningless because I can just take a phone book, hash the names, and check to see if they are in the cancer database as though it were an cleartext database. to say the data subject's data is private in this case because it is hashed (or often, inaccurately, "encrypted") is to mislead people who make decisions about it. I'm saying the designers of such systems represent themselves as cryptography and security experts who build weakened systems like this to mislead regulators on behalf of their bosses and users who just want the cleartext data.
most protocols are a shell game where if you don't know where the root of trust secret is managed you're the sucker at the table. my experience has been that working cryptographers (protocol designers) in government, health, and financial institutions in general are a very refined class of bullshitters who pound the table whenever you ask them about details, and that one should not be intimidated by their theatrics. Hence in PHI management, dishonest cryptographers working on behalf of anti-privacy interests are the main threat.
Thanks for clarifying, and confirming at least one of my suspicions.
All I can say here is, "Yikes."
If you (or, well, anyone) ever need an honest third party to audit a cryptography design--whether it's because you suspect bullshit or just want assurance that it's actually a good design--talk to the Crypto team at Trail of Bits.
There is a book about that, "Malicious Cryptography" by Adam Young and Moti Yung. Not about dishonest cryptographers per se, but about various sneaky tricks that could be used in crypto systems.
Anyway I'm sure you remember the notorious Dual EC DRBG.
> That said, it would be helpful for us i² [i squared] folks to have some of the more basic terms explained. Although "encryption at rest" is somewhat understandable, it would be pleasant to have it explained.
That's helpful feedback, actually. What terms seemed opaque or misleading to you as you read it? I'm always happy to fix mistakes in blog posts to improve clarity.
> For example what are the other kinds?
I contrast "encryption at rest" with "encryption in transit" (i.e., TLS) and "end-to-end encryption" (E2EE for short; i.e., what Signal gives you).
As writing advice, it went from very understandable and approachable to stuff like:
"You can get this property by stapling HKDF onto your protocol (once for key derivation, again for commitment). See also: PASETO v3 and v4, or Version 2 of the AWS Encryption SDK.
It may be tempting to build a committing AEAD scheme out of, e.g., AES-CTR and HMAC, but take care that you don’t introduce canonicalization risks in your MAC."
I would almost suggest breaking stuff like this into two articles, one which is very technical and correct, and one that conveys the high-level message. The high-level one can link to the technically correct one whenever the urge would come to explain something more fully.
Thanks for the reply. It is an interesting question, because the truth is that I don't know. At one point, very long ago, (VLG) I knew nothing about computers at all but would by "Byte" magazine (I told you VLG) and read it. It was complete gibberish. Then after some time (six months?) I could suddenly understand.
I actually did learn quite a bit from your article. The use of tech terms like HDKF & AEAD was helpful rather than a hindrance. For example the phrase "stapling HKDF onto your protocol" is surprisingly helpful. I looked up HKDF, and the use of "stapling" gives me a concept of how it is used. So good.
Going back over it, I believe the real problem is that your previous post, "Lucid Multi-Key Deputies Require Commitment" is required to reading (or knowledge) for this post. Once I read that much of this was easier. You hid that reference is in the "why should you believe me" and yet to my reading the this article builds on that one. You define the terms and provide a context that is missing.
So concrete suggestions (easy to come up with after the fact!):
- ask yourself if this is a continuation of a thought, topic, etc and give refs if so.
- in addition to "why you should believe" maybe add a section "for i²" readers :-)
Cool things are ones where you never see the world the same. Just to reiterate, I don't see the world of cryptography the same after reading your article, despite the quibbles, so thanks.
You're the author? Cool, I liked the article a lot. You do use a lot of terms that won't make sense to non-crypto nerds, like OAED, IND-CCA secure, etc. A lot of posters here are fixating too much on the "stolen hard disk" picture which I think the article addressed by declaring it out of scope. So the real points aren't getting through.
> A lot of posters here are fixating too much on the "stolen hard disk" picture which I think the article addressed by declaring it out of scope. So the real points aren't getting through.
This is a crypto nerd blog post though. The whole point is to talk about cryptographic library design!
> I’d say the author is being so restrictive in the scope of threats that it isn’t very useful.
Loss of control of the hard disks may have many different ways it can manifest in the real world, but from a cryptography and software development perspective, is congruent to other flavors of the same underlying problem.
That's not being "restrictive", it's recognizing the common denominator.
The problem is that after that common denominator is recognized, the post implies that it is outside the threat model of "web applications and/or cloud services", when it is not.
It doesn't need in-depth discussion, and the way data is still highly exposed despite disk encryption is very important, but that implication is not great.
It sounds to me like you read a different article than I wrote.
The point of my article was not "Encryption-At-Rest Is Bad" as you seem to have taken it to mean.
Rather, the point is that other techniques, when you sit down and actually think them through, do not provide any significant value over just phoning it in with Full Disk Encryption.
How you get from "software libraries that encrypt-at-rest routinely fail to provide value on top of full disk encryption" to "Scott says FDE is bad" is unclear.
Additionally: From a software perspective, the risks you all outlined are morally equivalent to the hard drives grew legs and walked because they are the same risk; namely, loss of control of the actual hard drives.
The article in question is focused on threats when those drives are plugged in and the keys are being used to encrypt/decrypt data. As several others have pointed out already, I explicitly state this, repeatedly. I don't know how to make it more clear.
> if you're storing the data on AWS and generating your keys on AWS and managing your keys with AWS ... you're doing it wrong.
This is a reasonable thing to do if you've decided that you trust AWS and expect any violations of this trust to be dealt with by the legal department.
It's less reasonable if you're concerned about AWS employees going rogue and somehow breaking the security of KMS without anyone else knowing.
It's even less reasonable to do this if you're concerned about AWS credentials being leaked or compromised, which in turn grants an attacker access to KMS (i.e., a government would be more successful by compelling IAM to grant access than they would trying to subpoena KMS for raw keys).
(Sure, you can audit access via CloudTrail, but that's a forensics tool, not a prevention tool.)
But that's kind of the point I wrote in the article, no? You need to know your threat model. You've stated yours succinctly, and I think it's a commendable one, but many enterprises are a bit more relaxed.