As architectures become more complex, hackers become more sophisticated and security becomes more important — and so data protection must evolve to meet the challenge. In the beginning, it may have been enough to encrypt just the disk, database or use application level encryption. But now, if you’re dealing with PII or other sensitive data, that’s just not safe enough. Even recent “crypto anchoring” strategies fall short during more-sophisticated attacks.
This is why I’m introducing a new concept, “Identity-Aware Encryption.” It’s a platform that requires the user’s authentication in order to decrypt data at rest.
But first, let’s look at some current industry standards.
Application-Level Encryption and Crypto Anchoring
Legacy encryption methods do not meet current industry standards. Examples of legacy encryption methods include disk-level encryption, which protects against a physical hard drive being stolen, and database-level encryption, which ensures the data is protected from unauthorized viewers.
Companies more concerned with security will use application-level encryption with external key-management platforms like Google/Amazon KMS and HSM (hardware security module) that are responsible for encryption/decryption.
These platforms store encryption keys and perform encryption/decryption operations without exposing the keys. This means that an application becomes dependent on them, ensuring that if the application is compromised, data can not be immediately decrypted — or at least not in an untraceable way. This concept is called “crypto anchoring.”
Application-level encryption with crypto anchoring
Is crypto anchoring enough?
Crypto anchoring prevents mass attacks of data exfiltration by limiting and detecting an attack once an abnormal amount of data is being decrypted. With that said it lacks the ability to block more-sophisticated attacks that use low-latency attacks and slowly exfiltrate data, so instead of being able to exfiltrate data in seconds they will be able to do it in hours or days without being detected.
Next-Gen Identity-Aware Encryption
Identity-aware encryption allows us to extend the functionality of crypto-anchoring platforms like KMS and HSM to make them aware of internal users’ identities.
Adding the identity-aware functionality protects users’ data and requires the user’s active authorization or authentication token in order to decrypt the data. So if the user is not logged in, their data can’t be decrypted.
How does it work?
Identity-aware encryption is deployed in front of the encryption module (HSM/KMS).
In this diagram, a service sends the user’s authorization token as part of the payload to allow the identity-aware encryption platform to verify the user and permit or deny the operation.
Key Features
Here are some key features of the identity-aware encryption platform.
- Metadata and policy enforcement
- Envelope encryption
- Encrypting/decrypting
- Traceability
- User-level encryption (optional)
Metadata and policy enforcement
Adding metadata to the encrypted data can enable a policy-enforcement engine to support controls like…
- Limiting access only to the user that owns the data
- Allowing specific service or member support agent on behalf of the user
- Requiring a higher level of trust from the user like using a known device
- Generically logging access to specific data (sensitive information, PII, SSN, etc.)
Envelope encryption
Using envelope encryption allows us to scale, as the input is always the same size (the size of the encryption key), regardless of the data. It also eliminates the need for this service to be exposed to sensitive data.
A service calling the identity-aware encryption platform will only send the data-encrypting key, or DEK, rather than the data itself.
For more information, you can read about envelope encryption here.
Encrypting/decrypting
By default this service will defer the encryption and decryption to your encryption module/KMS and will use the metadata, policy engine and user token to restrict access.
Traceability
As all other services depend on traceability, we can log all access to user data in this central service. It provides information on what type of data was accessed and by whom, leaving a detailed audit trail for highly-sensitive data like Social Security Numbers.
User-level encryption (optional)
It’s possible to add user-level encryption keys, which allow every user in the platform to have a unique encryption key that is encrypted with the remote module like HSM/KMS.
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.
Identity-Aware Encryption at Credit Karma
At Credit Karma we wanted to ensure the highest protection of our members’ data, so we built the identity-aware encryption platform with per-user encryption keys (+100M different keys) to enable access to data only when the user is logged in.
This service is responsible for our advanced encryption operations. Our microservices are required to provide the user’s authorization token in order to decrypt their data. This protects the microservice from exposing user data from members who are not logged in.
By adding user-level encryption, we gained benefits that are beyond encryption — in some cases we encrypted non sensitive data. Here are some of the benefits:
- User-level encryption — Each user has their own encryption key, combining that with envelope encryption makes rainbow tables or reverse engineering the data near impossible
- Simplified key rotation policy — Rotate the key encrypting the user key’s
- Traceability — See which user’s data is being accessed
- GDPR ready — This relates to a user’s right to be forgotten by simply deleting the user’s key, we can no longer access the data encrypted by the user’s key
Summary
We have gone through several methods of encryption, which depend on the importance and sensitivity of the data and the risk versus complexity of encryption.
We learned about different methods and what they protect against. Here is a quick summary.
I recommend enterprises and startups use at minimum application-level encryption with crypto anchoring; this could help limit the magnitude and impact of a breach and could have done so for many well-known recent breaches.
For those companies that would like to go a step further, implementing identity-aware encryption can ensure the security and accessibility of their user data.
