More and more people and businesses are now becoming aware of the importance of securing their internet communications. Whether you are sharing corporate secrets, medical information or private photos, you want this data to stay private. The big question is: How do I do that? You must have heard of end-to-end encryption. A lot of applications now proudly feature end-to-end encryption and assure their users that it prevents everyone but their correspondents from reading their messages. That users don’t need to trust the service providers because even if they wanted to read the messages, they could not. Is this only marketing or reality? In this short article, we will explain why end-to-end encryption is necessary but not sufficient for your privacy. And, that by using iMessage, WhatsApp and some other apps, you still need to trust these service providers to respect your privacy.
Encryption and “end-to-end encryption”
First, let’s start with what encryption and end-to-end encryption actually do. Encryption, in general, is the process of transforming data into an unintelligible form, that, can only be reverted back to its original form using a decryption key. When something is encrypted properly, it is safe to share it through the internet. Without the decryption key, no one will be able to know what the original data was. “Ends” in end-to-end encryption, refer to who encrypts and who can decrypt the data. Technically, encryption is always end-to-end: there is always a side that encrypts the data and a side that can decrypt it, but this term is used to convey a special meaning.
When it comes to messaging, most protocols will not make a user send a message directly to another user. Instead, a user would send their messages to servers, and servers will relay the messages to the intended recipient. This is not necessarily a bad thing. Imagine your correspondent is offline, if you send the message directly to him, he will not be able to get it. Always-online servers allow you to send your message to an offline contact and that contact will still receive it when he comes back online. Even if the original sender is not anymore. So you can have a conversation without being online at the same time.
In such a setting, service providers can provide encryption in two ways. First, encryption is applied between the sender and the server, and, between the server and the receiver. That way someone wiretapping any internet connection always sees the message encrypted and cannot read the original message. However, the service provider (whom usually owns the server) can read all the messages. Because it is one “end” in the encryption processes. The sender encrypts the message, the service provider receives it encrypted, decrypts it, stores it. Then, when the message needs to be delivered, the service provider encrypts it, sends it to the intended recipient and the recipient decrypts it. In such a way, encryption is applied, but not very useful, because the service provider is in the middle and has access to all data, unencrypted.
What is called end-to-end encryption is encryption used in a different way. A way in which the “ends”: the one that encrypts the message is the sender and the one that can decrypt it is the intended final recipient. Servers can still be used in the middle, to facilitate delivery but cannot read the messages because they don’t have a decryption key.
But how senders and recipients can agree on the keys to use? They can’t just use symmetric encryption (the same key encrypts and decrypts the message) and send the key via the internet. Anyone that could intercept the communication would catch the key. This is why, end- to-end encryption usually goes in pair with asymmetric cryptography. Every user generates a key pair. These two keys have a special relationship. One will be used to encrypt messages and the other one to decrypt messages. The one used to encrypt messages can be shared publicly and the other one should be kept secret. So it’s easy to share keys because it can be done over an insecure channel (the internet).
Now you might be thinking: “Yes, I’ve read it before, I understand it and it makes such apps secure. What’s your point?”. Something that you may not have thought about and that most applications don’t talk about is: How do you get the public key of your correspondent? Have you ever entered a public key manually? No, so how does your favourite end-to-end encrypted messaging application get that key? Can you actually trust that key to be the one of the person you want to send a message to? If it is shared over an insecure channel, how do you make sure it has not been tampered with? This is the problem of key distribution and authentication. It might look like a small detail, but take a moment to think about it. Because this little detail, that not many take the time to figure out, can ruin all your encryption efforts and make an end-to-end encrypted messaging application simply not secure.
Key distribution and authentication
In most messaging applications that use end-to-end encryption, users don’t have to do anything to get the public key of their contacts (the key for encrypting messages). They generate their own key pair and send their public key to the service provider along with an identifier like their phone number. Then, when a user wants to message another user, they ask the service provider for their public key. The service provider looks at its database and returns the requested public key for the phone number or identifier the user provided. This is how iMessage, WhatsApp and many others work.
Let’s take the example of iMessage. When you send an iMessage, you need the public key that the recipient generated to encrypt the message. How does iMessage get that key? It asks Apple. Now you say “Wait, what?”. Yes, it simply asks Apple. So, how do you know Apple gave you the right key? How do you know you are not encrypting the message using a public key for which Apple has the corresponding private key? This is where you need authentication.
Authentication is simply the process of verifying the identity of someone or something. In our case, the public key of your correspondent. Why is this crucial for end-to-end encryption? Because you are going to use this key to secure your data. If you don’t know who generated the key, you don’t know who can read your messages.
You might think “but if that’s the case, my correspondent would not be able to read the message and we will figure out that the service provider sent a different key, no?”. When the service provider is the intermediary between the sender and the correspondent, no. This is a type of attack called a man-in-the-middle attack, the service provider can lie to both parties and send keys it generated. When you send a message using the wrong public key, the server will decrypt it, and then, encrypt it again using the right public key of the recipient. For the recipient the message looks like it was encrypted for him and for the sender, there is no way to verify the message sent was the one delivered if the server is in the middle of all traffic.
So, you really need to verify that public key. How do you do this? With iMessage you can’t. You need to trust Apple. So Apple can tell you “no need to trust me with not reading your messages, they are end-to-end encrypted”, if Apple provided you an illegitimate key that they generated, this statement would be false. And of course, you need to trust them to provide you the right key. Now ask yourself, is this really better than Skype that doesn’t use end-to-end encryption between the sender and the receiver? What’s the difference between a service provider that doesn’t use end-to-end encryption and promises not to read your messages, and, a service provider that uses end-to-end encryption and promises you to give you the right keys? In practice that doesn’t make a big difference, you still need to trust the service provider.
Some apps like WhatsApp do things a bit differently. They actually allow you to check the public key of your contacts. This functionality is usually deeply hidden within the application and it would be interesting to find one person that verified the keys of all their contacts. Did you? Moreover, if the source code of the app is not public, there is no way to know the key that you have on screen is the key you encrypt messages with. But even if you are careful and you trust the source code, how do you verify the key? You need a secure channel: not the internet. How do you do this if your contact is not in your city, country or continent?
This is not the end of privacy!
Some messaging applications were never made with your privacy in mind. Some were. Blackwave is one of the second category. Blackwave uses end-to-end encryption (between the sender and the receiver). But not only, it also gives an answer to the key distribution and authentication problem.
In order to remove the need to trust the service provider to give the right keys, Blackwave doesn’t use phone numbers or user names as identifiers. Blackwave identifiers (addresses) are 9 characters long and are generated using the public keys of the users. That’s how you know the public keys you get match the identifiers of your contacts. By adding a contact with a Blackwave address, you don’t need to manually verify their public keys, because the address itself is used to verify the public keys.
Regarding key distribution, Blackwave simply removes the service provider’s directory database (that links identifiers to public keys) from the service architecture. Blackwave uses the Ethereum blockchain for making a decentralized directory of users. Allowing for a more decentralized and resilient network.
But Blackwave goes even further than protecting the content of messages and providing a strong authenticity mechanism. Blackwave was engineered from the start to provide maximum security and privacy. This means that Blackwave is built to protect the content of messages, the metadata, provide strong authenticity, network resilience, anonymity and transparency while at the same time providing users with modern messaging application functionalities like sending messages to offline contacts, supporting multiple devices, and cloud storage of messages. At Blackwave we think that these 6 security features are needed to make an app truly private and secure. To learn more about these 6 technical criteria for a secure and private messaging application, you can read Blackwave’s white paper here.
You can learn more about Blackwave by visiting our website here.
☞ Don’t forget to follow Blackwave on Twitter.
