We are thrilled to share Series Editor Rolf Oppliger’s insights into E2EE and their role in messaging and conferencing security:
Does E2EE Provide Messaging and Conferencing Security?
Since the triumphant advance of Internet messaging in general, and the revelations of Edward Snowden in particular, people have talked a lot about end-to-end encryption (E2EE) and why it is needed on the Internet. More recently, and also due to the COVID-19 pandemic and worldwide coronavirus crisis, a similar discussion has evolved in the realm of voice and video conferencing. The bottom line is that more and more messaging and conferencing apps provide support for E2EE or are about to do so soon.
As of this writing, the predominant technology to provide E2EE for messaging and conferencing is the Signal protocol that is used in the messenger of the same name, as well as many other E2EE messengers, including WhatsApp, Facebook Messenger, and Google Messages (cf. Rolf Oppliger, End-to-End Encrypted Messaging, Artech House, ISBN 978-1-63081-732-9). With its Extended Triple Diffie-Hellman (X3DH) key agreement protocol and Double Ratchet mechanism, the Signal protocol is able to constantly rekey itself, and hence to provide (perfect) forward secrecy and post-compromise security (PCS). As such, it clearly marks the state of the art in E2EE messaging and conferencing on the Internet today.
But the Signal protocol only targets the two-party setting. It can be extended to a few more participants, but it doesn’t scale to many participants and very large groups. There is an IETF Messaging Layer Security (MLS) WG[1] tasked to develop technologies that scale well, and the respective results look promising. In fact, the MLS protocol uses hash trees to allow groups to be rekeyed within a logarithmic number of messages (instead of a linear number). This enables the key management of even very large groups. It is only a question of time when the MLS protocol will be implemented in conferencing solutions for the mass market, such as Microsoft Teams or Zoom.
Having protocols like Signal and MLS available, one may wonder whether E2EE is sufficient to provide messaging and conferencing security in the long term. Alternatively speaking: Are all security problems solved, if only E2EE is deployed? The short answer is “no”, but we want to be more precise here. Whenever we talk about E2EE messaging, we simultaneously also mean E2EE conferencing. There are only a few and subtle differences.
First, we note that E2EE is just a technology acronym that stands for Signal, MLS, or a similar protocol. In contrast, messaging security is a goal that may go far beyond encryption. In fact, there are many other issues to consider when it comes to secure messaging. For example, one may ask about metadata that is generated with each and every message. What type of metadata is generated and who has access to it? Even if a message is end-to-end encrypted, it may still be the case that a service provider learns who sends a message and who receives it, how long it is, and when exactly it was sent and received. This type of information may be valuable to construct social graph. Another issue is the secure storage of messages on the end devices, such as smartphones. In a typical setting, such messages are end-to-end encrypted in transit but locally stored in the clear (in so-called “chats”). This means that whoever has access to an end device and its chats, can also read the messages. This may lead to funny situations, such as the one experienced in the famous Apple vs. FBI case a few years ago. Contrary to what was claimed by the FBI, it is reasonable to assume that the manufacturer of such a device can also decrypt and read a user’s messages, even if they are end-to-end encrypted in transit. This should be kept in mind when people argue about the cryptographic strength of E2EE in messaging: The messages are locally stored on either side of the message transmission in chats, and these chats are accessible to whoever is able to authenticate himself or herself as the legitimate user. There is a remedy for this situation though: One can activate a feature called “disappearing messages” that locally deletes messages after a certain amount of time or number of visual inspections. A somehow similar line of argumentation applies to chats that are stored in the cloud (e.g., for backup purposes). Again, it is reasonable to assume that there may be alternative ways to access the backups than the ones that are officially documented by the cloud providers.
To meaningfully argue about the security of a messenger, it is not sufficient to look at the protocol and its cryptographic strength. Instead, one has to make some complementary considerations that are sometimes subtle. Most importantly, one may be concerned about the possibility of losing messages forever, or about someone else being able to read them. The Electronic Frontier Foundation (EFF) has therefore coined the “Puddle Test” and the “Hammer Test”:[2]
- If you accidentally dropped your phone in a puddle and ruined it, would your messages be lost forever? Would you be able to recover them (maybe with the help of a service provider)?
- If you intentionally took a hammer to destroy your phone or otherwise tried to delete all of your messages, would they really be deleted? Would someone else be able to recover them? Is there maybe even a publicly available tool to do so?
In general, there is a tension between accidentally losing your messages, and intentionally deleting them. Is it more important to you that your messages are easy to recover if you accidentally lose them, or difficult to recover if you intentionally delete them? If you were security-minded and went for a highly secure messaging solution, then you would definitively favor the hammer test and go for forward secrecy and PCS. But in this case, the flip side is the availability and restorability of messages. If these properties match your preferences, then the puddle test is more appropriate for you. In either case, messaging security is a subtle topic that requires people to clearly specify their goals and expectations. In either case, it is more than implementing a cryptographic protocol, even if it is a cryptographically strong one.
[1] https://datatracker.ietf.org/wg/mls/about/
[2] https://www.eff.org/de/deeplinks/2018/03/thinking-about-what-you-need-secure-messenger
