The raised awareness of both state and commercial Internet surveillance has given rise to a growing demand for end-to-end encrypted (E2EE) messaging systems. However, does E2EE really live up to its expectations?
The answer to this question has two sides: How does the protection of E2EE against surveillance work? And how effective are implementations of E2EE in practice?
Encrypting connections vs E2EE
Before answering these questions it’s important to understand the difference between encrypting connections and E2EE.
When encrypting connections, the data is decrypted and re-encrypted at the servers, so it resides for some period of time at the server as a plain text message.
With E2EE, encryption and decryption only takes place at the endpoints, on users’ device. So the server doesn’t see any plain text messages.
In both cases, however, the servers takes care of routing the messages, and as such, need metadata to perform this task.
State surveillance typically starts with creating social graphs of people: What groups do they belong to? Who are they frequently communicating with? Are there ‘suspect nodes’ in the social graph? When this reconnaissance marks somebody as ‘interesting’ the State has several options to intensify the surveillance: observe that person in real life, wiretap their communications or hack their device(s).
E2EE only hinders the possibility of wiretapping the communication; it doesn’t help against observation and hacking devices. Hacking a device reveals much more than a wiretap and it is often easier to perform.
A recent survey by Europol showed that in 80% of its investigations, metadata (both from-to information and subscriber data) provided the most important information for investigators; in only 15% of cases was the content of the communication the most important. So E2EE only hinders State surveillance marginally and exposes users to an increased risk of being hacked by the State.
Commercial surveillance also starts with creating a social graph, which it uses to provided tailored advertisements. So commercial surveillance doesn’t rely on the content of the message at all and E2EE does not offer any protection.
E2EE is not effective against surveillance if it is not accompanied with metadata protection.
Other practical problems with E2EE you should be aware of
Modern schemes for E2EE try to offer ‘forward secrecy’ and ‘post compromise recovery’ — when secret keys are leaked at some moment in time, then it should not result in decryption of all past or future communications. This relies on ‘ephemeral keys’ — encryption keys that live only for a short period of time and are rotated after that. Once rotated, it is impossible to decrypt messages.
But many functions in instant messaging rely on messages that are decryptable for a longer period of time; first there is the storage and forwarding of messages when the receiving end is temporarily offline. This results in a direct trade-off between security and reliability.
An even bigger issue here are message archives and audit trails. In many settings, like healthcare, finance and legal, it is mandatory to create an audit trail and message archives. E2EE forces the creation of these to the endpoints, where they can be tampered with or can be compromised more easily than at the server. And though it is, in theory, possible to create a tamper-resistant archive at the endpoints, or to create an archive at the server without decrypting it, there are currently no cryptographic systems that do so.
E2EE also is an issue when one message has to be sent to many endpoints, for example, in a group chat or when one user wants to receive a message on multiple devices. Sharing one secret decryption key across multiple users or devices is a big security risk.
Encrypting a message to each receiver results in huge performance and scalability issues too, certainly on mobile devices. The upcoming ‘Message Level Security’ (MLS) standard of the IETF provides a facility for ‘proxy re-encryption’ at the server: having the server re-encrypt the message to all receivers without decrypting it. But that standard is still experimental and is not audited sufficiently yet.
The biggest practical problem though, is verifying that the key used to send the message really belongs to the intended user. If there is a failure here, an attacker can impersonate the intended receiver (man-in-the-middle attack).
The safest way to avoid this is by verification in person, for example, by scanning a QR code on the other device. However, this is not scalable.
A ‘web of trust’, where you trust verification by others, is more scalable, but it only needs one false verification to lose its value.
Verification by a trusted third party is another, somewhat cumbersome, option. But this third party has potentially the same issues as the messaging server you didn’t want to trust in the first place.
So, most instant messaging apps resort to a ‘leap of faith’: the first time you see somebody’s key, you assume it is the correct one. This is not as bad as it sounds: usually there is only a limited (and expected) window of time where you expect someone to contact you. But it still leaves a big hole open.
Ian Goldberg, one of the authors of the Off-the-Record (OTR) encryption standard for instant messaging stated:
“Bad encryption is better then no encryption”
I have to disagree with him here. The issues with instant messaging are so hairy that it’s safe to say: “Bad encryption is a false sense of security”.
If you would like to know more about metadata analysis resistant instant messaging, I suggest checking out the following projects:
- Briar: https://briarproject.org/
- Katzenpost: https://katzenpost.mixnetworks.org/
- Cwtch: https://cwtch.im/
Winfried Tilanus is privacy strategist. He has 20 years of experience with instant messaging systems in healthcare and is member of the XMPP Standards Foundation.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.