How many times you felt protected by the new end to end encryption solution of your preferred mobile chat application?
I recently participated to a work-group on data security in Brussels. The work group was organized by the Brussels Privacy Hub together with ICRC (international Committee of the red cross). It was about data security in the cloud and the possible security/privacy implications of Messaging applications usage.
The work group was an excellent opportunity for all the attendees to discuss these topics applied to popular cloud services and, in addition to this, the security implications of the top players in the instant messaging market. Particular attention was given to the legal aspects involved with their usage and the applicability of the immunity and privileges of humanitarian and United Nations organizations.
I expected to be in a technical work group. Instead, I ended up to discuss the aforementioned topics from totally different standpoints, the legal standpoint and all the implications toward beneficiaries and core entities in our business. It has been an incredibly good opportunity for me, very well spent time.
During the workshop days, I noticed that the concept of end to end encryption might be a misleading topic for most of the non technical people around.
On one side, people tend to not understand some basic concepts about keys exchange, it is normal, not everyone in this world has a background on data encryption techniques. On the other side, the concept itself creates a lot of expectations and false certainty of data security and protection. For instance, the general perception is that now, since Whatsapp has end to end encryption, the system is 100% secure.
While end to end encryption is surely an excellent mechanism for data exchange protection, it does not cover some aspects that I do believe are of paramount importance in this area.
Security of the end point devices
Since the keys are generated by the endpoints and exchanged between the two of them, people generally consider the keys to be safe. All in all, the provider does not have the keys and no one else in this world can have the secret keys. This is an extremely wrong consideration. This because the endpoints, are actually the weak point of this mechanism. If an endpoint (i.e. mobile device) is compromised, the keys can be (are) compromised as well. Keys must be stored somewhere (either on storage or in memory) and must be loaded from the SW in order to be used. What if your mobile phone, running Whatsapp, has a malware program running on top of it that silently snoops your encryption keys? I bet the concept is easy to be understood, the system is somehow secure only if we can guarantee the security of the underlying components. If the device, the OS, the HW is compromised, there is very little you can do to protect the operated application.
Man in the middle
This kind of security weakness is related to the fact that, a eavesdropper can potentially impersonate the recipient you intend to communicate with. In this case, the situation is rather simple to be explained. Let’s consider two valid endpoints, A and B. Now, let’s consider a third endpoint, I call it endpoint C, C is the bad guy. This attack consists in having C playing the role of one of the two real actors, for simplicity let’s consider that C impersonates B.
So, in this case, since C is pretending to be B, the exchange of the key occurs between A and C (remember that handshaking occurs between the 2 devices without any ruling entity and therefore a real identity verification cannot happen).
In this situation, C intercepts the messages and establishes a forward handshaking with the actual B endpoint.
In simple words, A talks to C which forwards to B. The very same happens to the other way around.
The flow will look normal to both A and B and they are not aware that, in the middle, there is an invisible man. C is silently listening.
How difficult is to accomplish this? It is rather difficult, it is not easy. Is it impossible?” No, it is not. Is it probable? I think it is very much probable. It all depends if the exchanged information are relevant to skilled malicious hackers.
Software vulnerabilities and backdoor
We always tend to consider the Software we use as bug free components.
At the same time, we always tend to have trust in the most popular SW. This because millions (billions?) of people are already using them. I do believe we suffer, somehow of the behavior of gnu packs while they need to cross the rivers infested by crocodiles. They do it because they need to do it, driven by their instincts. Even if we evolved, we still have the same behavior. I need to use a SW even if I know it has drawbacks. At the same time, we feel reassured by the fact that millions of people are giving the same trust to the SW manufacturer. The point becomes, there are millions doing it, why me?
Guess what, no SW is perfect. More importantly, we cannot be 100% sure that a SW does not contain potential backdoor. I am saying this, not to bring you paranoia or to start the useless discussion about how “NSA can access a system if they want”. It is just a professional consideration on what, a software, can potentially cause. Either by mistake (backdoor bug) or by intention (backdoor).
What if the SW has a way that a malicious attacker can leverage on, to obtain your encryption keys? In this case we would not even notice the vulnerability.
How can you protect from this? No one can do anything about it, we just need to be aware of this potential problem.
Are we all doomed? No, we are not, just try to not be too overconfident on the security certain services.
To conclude, I strongly believe that it is quite safe to use nowadays instant messaging software for personal usage.
All in all, no 3rd world war will happen if our conversations are sniffed. It all depends on how important is the message we are exchanging.
At the same time, the false reassurance given by end to end encryption can be misleading.
Having said this, I wouldn’t use an instant messaging SW to communicate sensitive information. Information like bank account’s information or any other item that can jeopardize my security or, the security of my organization.