Most of the systems we use today have some type of access control. This is enforced by software products based on a set of rules or policy, but increasingly, organizations are using cryptographic access control in addition to policy-based systems to truly enforce access control.

This article is part of our Security Guide series – Encryption for Developers. Read more in that series of in-depth technical articles on getting encryption right in your application.

Encrypting at the Application Level in Addition to the Infrastructure Level for Deeper Protection and Control

In some organizations, encryption is not the realm of developers. Instead it is in the realm of the IT or DevOps departments. These organizations think of encryption as something to implement on the infrastructure – the network or the database. HTTPS, VPNs, and transparent database encryption are all valuable, but they don’t go far enough. In a typical conversation between a client and server, data will be decrypted at every step of the process. 1) storage to app 2) app to Internet, 3) Internet to internal network 4) network to application logic, and 5) application logic to database. Each point where your data lives unencrypted is a point of attack; a weakness.

Furthermore, protocols like HTTPS are ubiquitous and (supposedly) easy to implement in part because you outsource key security concerns to a third party certificate authority (CA). The CA’s job is to say which public keys, including yours, can be trusted. This is very convenient, and in some cases completely vital for bootstrapping trust.

However, this convenience has a number of drawbacks. The company that your user works for may modify the list of CAs in order to man-in-the-middle their employees’ traffic. Perhaps this is their right, but it undermines the security of your application. Furthermore, this setup makes it significantly easier to reverse-engineer your application’s network protocol since users can swap out your encryption certificate with one of their own. That’s unavoidable delivering HTTPS to a browser, but application-level encryption can build a deeper system of data privacy and control than HTTPS allows.

Use Cryptography to Enforce the Principle of Least Privilege (POLP)

Application-level encryption gives you more control and security because the application itself can secure data as soon as it’s created, and can use custom rules for different types of data. For instance, perhaps most of your data is completely innocuous but you are required to collect emergency medical information. Application-level encryption can treat this medical information with a deeper level of security, perhaps locking it away from your servers, algorithms, and even IT staff unless certain conditions hold (such as a medical emergency). This type of control isn’t possible with a generic protocol like HTTPS.

If you have a background in security, you may recognize this as the “Principle of Least Privilege”. POLP is a security idea that says that systems and people should only get access to the data that they need to do their job. When followed, this principle reduces the possibility of data leaks and hacks because fewer systems have access to less data. It massively reduces the attack surface.

When implemented badly, POLP can get in the way of legitimate data processing. When implemented well, your systems and organization will never miss that data they don’t need. For instance, an algorithm that processes student test scores will never need student medical information. That algorithm will never know or care that it doesn’t have access. On the other hand, a system that handles all the data with the same security controls and in the same database is asking for trouble. An attacker will exploit your test scoring algorithm to get to the valuable medical information, which they can use for fraud and identity theft.

Cryptography for Access Control

In this section, we’re advocating for enforcing POLP with cryptography rather than just implementing it with access control rules. Worse, keeping all of your data in one place, open to all of the systems or people that handle it. When enforced with cryptography, the systems that require the data get a cryptographic key to decrypt that data. This is robust against strong attackers.

The downside, and it is significant, is that this increases the work to decide which keys to use to encrypt data and increases the work to share keys among the right entities. There are not many tools or patterns available to implement this well, which is why Tozny offers tools like TozStore, our end-to-end encrypted database. As a result of this historical lack of tools, not many organizations implement the POLP with cryptography, and perhaps not at all.

This lack of tool support isn’t just about the principle of least privilege; very few effective cryptographic tools are available for developers, which is one of the major challenges we explore in another article in our series.