How is this Identity aware encryption description different from simple authorized access?

Question

I was reading this article by Credit Karma (An American fintech). They mention that this system of "identity-aware encryption" helps them better protect the data of their users and to keep it private.

This block diagram tries to explain how the process works:

• A user makes a request to the application to get some data
• Since the data is encrypted, the application needs to make a request to HSM/KMS to fetch the key. So, the application forwards the user's auth token to HSM/KMS system.
• After verifying the auth token, the HSM/KMS returns the key to the application
• Application then uses the key to decrypt the data that it gets from the database.

My question is, how does this system become more secure than a simple authorization check done using the auth tokens and user's identity?

When a user makes a request to the application, the application can check if the request came from an authorized user and then go look for the key that user.

This particular paragraph makes me doubt the system's efficiency even more:

What About Background Processing?
At a certain point, we need some of the data to be available for offline processing. This means that data needs to be decrypted without the user being present. To do this right, we’ll perform it in a more secure and isolated zone that is not accessible by our users and give this ability only to specific services.

Clearly there is a way for the system to access the data by itself when it needs to. So essentially, all it is doing is verifying whether the requesting user has access to the key or not.

Answer 1

This does sound kind of smoke-and-mirrors (you'll find that all over the place in infosec, sadly). They could have been adding some meaningful security if the app couldn't decrypt user data without the user logging in - that would mean somebody walking off with the whole system still would have had no access; they'd need to do an online attack against each user as the sign in, which takes longer, risks detection, and doesn't work if you do something like steal a backup.

Mind you, the "steal a backup" case - which does happen - is an example where encrypting the data using a key that the server (much less the DB) doesn't store does help. But as you point out, adding per-user encryption really doesn't add much there; if the attacker can get any key out of the HSM, they can presumably get them all. I guess one possible advantage of per-user keys is that, if an attacker gets write access to the DB, they can't overwrite data in one part with data from another part (depending on the cipher and the way it uses IVs/nonces, and how granular or holistic the integrity checks are, this might otherwise be possible).

EDIT: I suppose it could be useful as a second layer of authorization check. If somebody finds an authz bypass in the app then normal access controls wouldn't stop them from accessing another user's data. However, if each user's data is encrypted with per-user keys, then an authz bypass might not actually let you access somebody else's data anyhow. So yeah, it might be a defense-in-depth thing.

---

Tech companies in general, and especially fintech companies, love to make extravagant claims about their security. Most of them are meaningless, though, or at best are addressing some tiny threat when the most likely attack vector by far is simply spearphishing or similar. I think this is likely to be one of them. But... hey, at least they use encryption at rest and store the keys in an HSM? That's better than a shocking number of companies (though those facts alone don't guarantee any added security, depending on how those systems are used).