Testing End-to-End Encryption Claims

What is end-to-end encryption?

We’ve been seeing quite a few claims of end-to-end encryption from major applications. Unfortunately those claims are frequently misleading.

Traditionally, the term end-to-end encryption (E2EE) meant that data was encrypted where it was created (the user’s client), sent and stored encrypted, and decrypted only by an authorized user’s client. It is the gold standard in security. The user controls the encryption keys, and the company’s servers can’t decrypt the user’s data even if they want to or are compromised.

Deceptive companies

Some companies have been touting their applications and services as E2EE, even though they fall short of that definition. These companies are deceptively moving the goalposts of what the term means in a few different ways:

The most common change is redefining the “ends” of end-to-end encryption as the user’s client and their server. This allows them to claim the completely industry standard TLS/SSL/HTTPS, which encrypts all messages from client to server, as E2EE. HTTPS is great and protects against a lot of threats but it isn’t E2EE. The company still has complete access to the unencrypted data, as does anyone who accesses the company servers.
Next up is transparent disk encryption. That’s when the storage disks for a server or database are encrypted with a key. When the server starts up it decrypts the storage. When the server is shut down or if someone steals the physical disks, the data is fully protected. However, this does nothing to protect against the company itself or anyone with unauthorized access to the running server from compromising the data. This approach is also an industry standard security practice, but like TLS, it just isn’t E2EE.
Least common is implementing full E2EE from client to client, but with the company holding the encryption keys. This negates most of the benefit of E2EE because the company (and anyone that compromises its servers) still has the ability to decrypt any of the data it wants to.

Check for yourself

So how can you tell if an application is actually end-to-end encrypted without relying on what a company is telling you? The best way is to make sure that the data sent from your client is random, the data received from the server is the same random data, and the key never leaves your client. The process to ensure that differs per application, but we’ll walk you through the steps for a web application, using our own IronCore Labs Configuration Broker as an example. Our Configuration Broker allows for E2EE storage of cryptographic key management service (KMS) credentials, which are used in our SaaS Shield platform.

Since the Configuration Broker (CB) is a web application, we’ll be making extensive use of the Network Developer Tool. The shortcut for most browsers to open Developer Tools is Ctrl+Shift+J. After opening them, click on the “Network” tab. This is where we can view and inspect requests the web application makes and responses it gets from servers. Make sure to check the option to preserve logs so page changes don’t wipe information. Filter to “XHR/Fetch” requests so we only see requests/responses to servers.

Log in to the web application.
Navigate to a page involving data that is claimed to be end-to-end encrypted. In the CB we’ll navigate to “KMS Configurations”.
Clear the logs and create a piece of data. I’m creating an AWS KMS config with example data, since I don’t trust that this is E2EE yet. I want to see what is sent to the server.
Look through the network requests triggered by creating the data for any suspicious information. In particular, you’re looking for a request with a “Payload” containing the data you just input. If the payload contains the information you entered in plaintext (meaning unencrypted data), the server gets to see it in plaintext. In this example case, there are requests to groups and documents that send identity information and get back cryptographic public key information. There’s also a request to configs that sends an encryptedConfig field along with plaintext information that we’ve created a kmsType of AWS. We can see that the information sent isn’t the plaintext credentials we input, but we don’t trust that encryptedConfig is actually encrypted just because the application says it is.
To gain confidence that the data is actually encrypted, you can copy any possibly encrypted data and determine if it’s random, which encrypted data would be. We’ll use a tool called CyberChef to make this easy.
- First we’ll use the “Magic” tool to detect the format of the data; in this case, it’s base64.
- We’ll use the “From Base64” tool to extract the data. In the output we can see that there’s a header of some sort on the data, but that it doesn’t contain the information we input. We’ll remove that header.
- Now use the “Entropy tool” to measure the randomness of the result. Completely random data on this scale is an 8, where normal English text is usually between 3.5 and 5, and encrypted data is usually around 7.5. The result here is around 7, which indicates there still may be some structure to some of the data, but we can reasonably assume it’s encrypted. As an example, a JSON object of the data we had input into the application turned into binary then measured for randomness scored a 1.38.
- Navigate to a page that retrieves that same data and make sure that it’s still encrypted when it comes back to your client. In the CB the “KMS Configuration” also retrieves the same data in a configs request, and we can see that the encryptedConfig comes back unmodified. If any of the responses included information you had input that was originally sent encrypted but was now plaintext, that would indicate that the server (and company) is holding a key that can decrypt your data.

Conclusion

Building secure E2EE applications from scratch is difficult, but the privacy benefits are worth it. IronCore has made many of the difficult parts easy with our Data Control Platform, which we use ourselves to bring E2EE to our own applications.

This analysis doesn’t prove whether or not the E2EE is actually well implemented (we have 3rd-party expert audits for that), but it can show whether or not data is being encrypted before it’s being sent.

Follow these steps any time someone tells you that they have E2EE and you can verify the claim. Feel free to verify our claims yourself, too. Should you find a service that’s misrepresenting its security by falsely claiming to use E2EE, we encourage you to shout it from the rooftops to caution others. If you let us know, we’ll help amplify your warning because these sorts of claims are easy and tempting to make. Luckily, they’re not too hard to verify.