Application level encryption solutions
Many security risks cannot be mitigated with encryption at-rest or TLS, and require encrypting the data inside the applications. Application level encryption (ALE) is relevant for software products that store or process sensitive data. ALE makes implementing regulatory compliance requirements easier, as sensitive data is processed as an encrypted blob until used.
Application level encryption can come in different forms, depending on the use case: client-side encryption, server-side encryption, end-to-end encryption (no secrets and keys are available for the intermediate servers), field level encryption (only certain fields are encrypted), and their combinations. The main concept is that data is encrypted inside the application, independent of data-in-motion and data-at-rest encryption.
Challenges that require
application level encryption
Zero trust infrastructures
Application level encryption protects data through all underlying layers, including databases, analytics engines, caches, logs, and transit. It significantly reduces potential attack vectors on sensitive data, as neither misconfigured databases nor expired TLS certificates lead to data leaks.
Insiders risks
Sensitive information stored in databases should be protected from internal developers, DBAs, BI teams, cloud provider employees and adversaries with elevated privileges. Using application level encryption of sensitive fields wins over anonymization, as the data stays in plaintext for a minimum amount of time.
Defence in depth
Application level encryption adds another layer of security if other data-related controls (access control, DLP, disk encryption, OS sandbox) fail somewhere. Some applications benefit from end-to-end encryption, while others from a combination of client-side and server-side encryption.
Developer satisfaction and compliance
Application level encryption allows protecting selected fields strictly enumerated in the application, like PII and PHI. It simplifies compliance and makes implementing regulatory requirements actually understandable to developers.
Modern application level encryption solutions
Data encryption proxy
Deploying encryption proxy between applications and datastores. The proxy will detect sensitive fields, encrypt/decrypt the data and have access to the keys. The proxy can be transparent for the apps, like Acra, or DAO-like service that provides encryption and decryption API.
Client-side encryption SDK
Adding encryption to the client app as close to the data generation as possible allows creating point-to-point and end-to-end encryption flows. A client app should have access to encryption keys and should protect them with additional authentication (password, pin code, biometry, etc).
Encryption-as-a-service
Encryption-as-a-service is best for stateless architectures, but requires certain code changes. Application performs API calls to the service and receives processed data – encrypted, decrypted, masked, tokenized, etc. Encryption service could be deployed in a separate, extra protected environment.
Our offerings
// Relevant products
Acra
A DATABASE SECURITY SUITE
Themis
A CROSS PLATFORM CRYPTO LIBRARY
// Custom design and implementation
Searchable encrypted fields
Custom application encryption schemes
Custom data security engines
// Consulting
Security engineering
Security advisory
SSDLC
Application level encryption
in use
#
Application level encryption becomes a security boundary for data, shifting from "protect the data where it's stored" to "protect the data whenever it exists". Sensitive data fields are encrypted before stored in the database, and decrypted on read. Let's look at the example of the user model with and without field level encryption.
Additional relevant materials
These conference slides explain more business and engineering details about application level encryption.
Have a question? Get a human to answer it!
How we make a difference
Reduce business risks with consulting
We advise and assist in building a security solution for your unique use case with application level encryption design and flow, key management schemes, integration in your existing infrastructure and security controls. See our security engineering and strategic advisory services.
Fast time to solution
During the last 8 years we have created and maintained developer-friendly security tools that are easy to integrate, easy to deploy, easy to configure and use. Ready-made tools allow to integrate the application level encryption quickly without spending years on development of home-brewed solutions.
Support of regulations and procedures
Every company has different technical, security and compliance needs. We design and implement security solutions with the suitable features adhering to the internal and external procedures and specific regulations.
Flexible key management
“Encryption is easy, key management is hard,” – key management flow affects the system’s security, usability and maintainability. We suggest key management schemes based on pragmatic risks and threats – some systems benefit from lightweight procedures, while others should follow NIST SP 800-57.
Frequently Asked Questions
What’s the difference between application level encryption and network encryption?
Network encryption, or transport encryption, protects data in transit between one point to another – for example, between mobile application and its backend, between website and web server. Examples of transport encryption protocols are TLS, IPSec, SSH. Transport encryption only works during transmission.
Application level encryption works on a different level – the data is encrypted within the application, such encryption depends on a context. Often, ALE requires extra work – encryption code should be added to the application, developers should define when to encrypt and when to decrypt the data. ALE protects from more risks than transport encryption, but at the cost of tradeoffs.
Application level encryption vs database encryption?
What regulations require application level encryption?
Data privacy regulations and industry regulation don’t precisely say “implement encryption at the application level”, but often say “sensitive data should be encrypted”. Using application level encryption simplifies the compliance process. Sensitive data includes PII, PHI, payment data, and any kind of business-essential data.
Check out the “PII encryption requirements. Checklist” and GDPR for software developers: implementing rights and security demands.
For innovators, by innovators
We've started Cossack Labs to develop new tools and methods for protecting the data and enabling novel solutions to emerging problems — so that at the edge of your innovation, you’ve already got fitting tools handy.
Contact us
There are many ways we can help: with our products, bespoke solutions, and engineering services. Leave your contact information to connect with our team:
Relevant blogposts
PII Encryption Requirements. Cheatsheet
What data is sensitive and needs to be encrypted according to data privacy regulations like CCPA, GDPR, HIPAA, etc.? Our cheatsheet addresses this question
Cryptographic failures in RF encryption allow stealing robotic devices
Stunned by losing their robotic devices, [REDACTED] learnt that they were hijacked by attackers even with communication being encrypted. Having researched its firmware and found numerous cryptographic failures, we've crafted a few demos on how cryptography goes wrong in real life.
Implementing End-to-End encryption in Bear App
Helping Bear app implement note encryption for their vast existing user base. Balancing usability, security, and mobile platforms' restrictions.