Apple has gotten a lot of kudos in the security community lately about their approach to end-to-end encryption. WhatsApp and Signal have gotten headlines in years past. Tozny offers end-to-end encryption toolkits for developers, and we often get asked why you should end-to-end encrypt data when HTTPS is pretty secure. We’ve written about this in the past, but decided that it’s time to update this discussion a bit.
Rest assured, we think HTTPS is great, and now-a-days you can get it for free, but it’s only a small piece of the crypto puzzle. Ask yourself these not-so-simple questions:
- How many times does data get decrypted and re-encrypted in its journey from your user to your system?
- How many systems get access to the unencrypted data along the way?
- And how many different administrators or departments are responsible for all the steps in this elaborate journey?
Many organizations use HTTPS for data in transit and find another approach for data at rest. We call this “point-to-point” encryption as opposed to “end-to-end” encryption. It’s important and you should do that, but read on for some ways to think about improving your security beyond point-to-point.
The Reality of HTTPS – encryption of data in transit (DIT)
Let’s start simple. Here’s a picture of how HTTPS makes us feel like we’re doing a good job of encrypting data. Red typically stands for unencrypted (plain text) data, and black stands for encrypted data:
Simple, right? Data is secure on your user’s mobile phone, it’s secure in transit, and it’s secure on your server… Although this makes it look like data is always encrypted, it’s a bit too simple actually.
The reality of encryption in transit leaves out encryption of data at rest, which impacts the security of both ends of the transmission. It also completely ignores what happens to the data after HTTPS termination, which may be further out on the edge of your network than you know; at your load balancer for instance:
This leaves you open to attack at 3 points of processing (the app, the load balancer, the server), two points of storage (mobile, server), and one point of transmission (“Internal” traffic). And that’s the simple version. If your “server” is the endpoint of your web API, but you have different services for processing, analyzing, sharing, and backing-up your data, this just gets worse. You may be using HTTPS, but you can’t really say that you’re encrypting data. On the other hand, with end-to-end encryption, it’s secure at each point of the process.
Encryption of data inside the network (DIT) and data at rest (DAR)
So what about encryption at other points in the application? If you’re doing an above-average job of crypto, you’ve written robust, well-tested code in your app to encrypt data at rest, you’ve used HTTPS and IPSec on your network, and you’ve enabled transparent database crypto:
Now only the various network processing points have access to the plain text, where data gets decrypted and re-encrypted for the next step. That’s better, but still results in a large attack surface, and you have to ask yourself, “why the heck do these services need the data in plain text anyway?” They probably don’t.
When everyone is accountable, no one is accountable
These security gaps happen because different individuals or departments are accountable for security at these various points.
- On the mobile side, your development team or vendor had to write some code (or at least implement HTTPS right). Or your Mobile Device Management (MDM) system encapsulates the data, or maybe you’re relying on the user to check the “encrypt phone” box and the OS vendor to do something sensible there.
- In the network, IT or DevOps is accountable for provisioning certificates and ensuring that HTTPS is well configured, which isn’t always that easy.
- On your server, you’re counting on IT and DevOps to secure internal access to your systems, and you’re counting on the cloud provider and database vendor to implement “transparent” database crypto.
Each one of these solutions uses different ciphers, libraries, and key sizes. You’re counting on a lot of people to get a lot of things right. That’s a problem.
Attacks, Insider Threat, and liability
On top of this, transparent database encryption on your server is not robust against a wide variety of attacks. Any attack that targets an authorized server (“your server” in the picture above) can trick the database into decrypting data for the attacker. Even endpoint attacks like SQL injection will leak unencrypted data.
Standard “point to point” encryption doesn’t protect your data from your insiders like employees and vendors. They might intentionally misuse data or unintentionally leak it. Unless they really need to access this data, it’s best to use encryption in a way that prevents them from accessing it.
Furthermore, any data that you can decrypt is a legal and compliance liability. Similar to PCI compliance for credit cards, which discourages direct storage of the card number. If you don’t need access to the data directly, you can eliminate that liability using good encryption approaches.
End-to-end encryption for consolidation and control
So what is end-to-end encryption? It means encrypting the data at the point of creation and only decrypting it at the point of use.
The two “ends” can be whatever they need to be:
- End-to-end encrypt data between an app and your data processing server, like we’ve been discussing.
- End-to-end encrypt data between two users, from one app to another. This is what apps like Signal and WhatsApp are doing for chat and ProtonMail for email. This type of encryption is particularly powerful because two people can communicate without 3rd parties having access to their communications. It makes it much harder to hack into those communications because an attacker must target specific individuals on either end of the discussion, instead of targeting the infrastructure (e.g. the server) that could get everyone’s communications.
- End-to-end encrypt data from the same user on multiple devices. They can see their data in plain text wherever they go, but it’s encrypted in the interim. This is what some password managers do, and what Apple has gotten a lot of kuddos for. For instance, your phone data is backed up to iCloud, but Apple can’t access the backup, only you can.
If you’re a developer interested in this type of data flow, our TozStore product supports each of these use cases.
End-to-end encryption for data security, not infrastructure security
This data-centric approach is vastly more secure. The data owner is in cryptographic control of the data at all times, it’s never decrypted and re-encrypted, and it reduces the attack surface. Put simply, each step in the chain handles an encrypted data object instead of the data itself:
Now each point in the infrastructure is secure in relation to the data because the data itself is secure from the point of origination. The code itself enforces security. If the unencrypted systems are ever hit by an attacker, they can only acquire the encrypted data object. No one wants to get breached, but end-to-end encryption significantly reduces the exposure of a data breach:
What to do next
Ask your team the question we started with: How many times does data get decrypted and re-encrypted in its journey from your user to your system?
If you’re a developer, consider integrating end-to-end encryption into your system. If you’re an IT purchaser, you should start asking this of your vendors.
We never like to just point out problems without solutions, so we created TozStore, our end-to-end encrypted data storage solution. It’s free to integrate and try out. It’s completely self-service, so check it out to see if it will meet your needs. Drop us a line if you have any questions.