Apple gets a lot of kudos in the security community about their approach to end-to-end encryption. WhatsApp and Signal made headlines in years past. Tozny develops encrypted data lifecycle management solutions providing encryption backed identity management, privileged access management, and end-to-end encryption and storage as well as providing easy to use end-to-end encryption toolkits for developers.
Customers ask regularly why end-to-end encryption is necessary when HTTPS is pretty secure.
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.
Learn more about Tozny’s encrypted
data lifecycle management and IAM solutions!
Identity and Access
|
End-to-End
|
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 encryption puzzle. Ask yourself these not-so-simple questions:
- How many times does data get encrypted and decrypted on 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? And did they get it right?
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 do that, but read on for some ways to think about improving your security beyond point-to-point to reduce the impact of data breaches.
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:
HTTPS alone looks secure
Simple, right? Data is secure on your user’s mobile phone, it’s secure in transit, and it’s secure on your server…so it appears that data is always encrypted, but that is a bit of a simplification.
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:
With just HTTPS, there are many points of attack
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:
Even above-average crypto has a big attack surface
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.
Without end-to-end crypto, accountability is spread across departments
- 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, provisioning certificates and ensuring that HTTPS is well configured is the responsibility of IT or DevOps . That isn’t 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
Additionally, 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.
End-to-end encrypt at origination, decrypt at 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. That makes it much harder to hack 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. Users can see their data in plain text wherever they go. If you are not an authorized user. This is what some password managers do, and what Apple has gotten a lot of kuddos for. Apple cannot access phone data stored on it’s own iCloud.
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:
Encrypted Data Object
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 unencrypted systems are hit by an attacker, they can acquire only the encrypted data object. No one wants a breach. End-to-end encryption significantly reduces the exposure of a data breach:
The data is encrypted at all points
What to do next
Ask your team the question we started with: How many times does data get encrypted and decrypted 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.
Combining TozStore with our Identity and Access Management solution, TozID, provides a powerful solution to manage access to your data and infrastructure using end-to-end encryption. Do you have self-hosting requirements- whether on-premises on cloud based? Tozny solutions have flexible deployment options. Contact us for details!