TL;DR: Zengo was invited to present research on multiple security issues in the world’s most popular Instant Messaging (IM) apps, including WhatsApp, at the prestigious USENIX conference. Watch the full presentation, below. Technical blogpost follows, and the detailed USENIX paper can be found here.
Introduction: IM apps and Crypto Wallets
Smart engineers know the best way to get results is to look for comparibles and not reinvent the wheel. This is especially true for security engineering in which acquiring the robustness of existing and battle tested solutions is highly advantageous.
As we continue to develop the world’s pioneering MPC crypto wallet, the Zengo X Research Team is looking into its closest-living relative, the Instant Messaging (IM) apps domain. As a result of this research we were able to identify and report important privacy issues in IM’s most popular app, WhatsApp. Our research, first acknowledged by popular media outlets like TechCrunch, has now been discussed by academia as an invitation to present our findings at the prestigious USENIX WOOT conference.
IM and MPC Wallets: Brother from another mother
There are a few reasons why IMs are the closest living relative to wallets, but most predominantly it is due to the fact that financial transactions are just another form of communication. In the same manner that IM expanded from merely sending text messages to every possible means of digital communications (audio, video, file, etc.) it will naturally expand to digital money in the form of cryptocurrency. Zengo was the first to support Meta’s crypto initiative and we are closely monitoring current attempts in this field, most notably by Telegram’s TON. On the other hand, financial crypto transactions deeply need social context and conversation between transacting parties .Therefore, we strongly believe that in the long run, IM and crypto wallets will converge!
Additionally, IM is arguably the most popular mobile-first consumer app, therefore when we need to take inspiration for new features, we look into IMs design. A recent example is Zengo’s newly-launched web interface, where we implemented a QR-based pairing process with the Zengo mobile wallet that should be familiar to IM users.
Another similarity is IM use of public key cryptography: When IMs implement End-to-End Encryption (E2EE) the IM user is now assigned with a private key and published its public key, very much like a blockchain user. IMs must deal with securing the private key, its backup and recovery. (Although the issue of loss is far less grave compared to crypto wallets securing assets). One of Zengo’s greatest challenges and accomplishments is the unique way we protect our customers’ secrets, battle-tested by millions of users over the span of five years and multiple bug bounty challenges.
A final point of similarity which specifically relates to MPC wallets: Like MPC wallets, IM users with E2EE have a more mature trust model: While they do not blindly trust their IM server with the privacy of their conversation and apply End-to-End Encryption (E2EE) to them, they are willing to somewhat trust the IM server with their privacy as they allow it to observe some conversation metadata to receive its security and convenience benefits. With Zengo wallet MPC users need to put some trust into Zengo’s server, but not fully as Zengo cannot spend on your behalf. This is a much more mature security model, compared to the naive and self-sentralized “Trust no one but yourself” which is by definition highly prone to user errors.
These similarities are highly relevant to our research. In fact, the combination of the aforementioned E2EE with the aforementioned IM migration from a mobile only app to multiple device support is in the heart of the privacy issues we discovered.
Mo’ parties, less problems: See vires-in-numeris
Instant Messaging E2EE: The postal service analogy
E2EE is commonly defined as: “ a type of messaging that keeps messages private from everyone, including the messaging service. When E2EE is used, a message only appears in decrypted form for the person sending the message and the person receiving the message. The sender is one “end” of the conversation and the recipient is the other “end”; hence the name “end-to-end.” (source: cloudflare)
To better understand E2EE and its threat model we can use the postal service analogy:
Prior to E2EE, senders sent their letter in an envelope, but the envelope was not sealed. As part of its service, the post office opens the envelope and then puts it in another envelope and delivers it to the intended recipient.
This scheme has a major drawback: Postal service employees are exposed to the contents of the letters and can leak them. The practical reasons for such leakage can vary: The service may act in negligence and mishandle user data, sell the data to advertisers for financial gain, be hacked by attackers, fail to restrict rogue employee access to private customer data, or even be served with a subpoena by the government.
Seinfeld said it best Source
To address this issue, E2EE was introduced. With E2EE, users send their message in locked boxes within the envelopes. Users provide their locks to the service when they join, but keep the keys themselves. When senders want to send a letter to a recipient they get the relevant padlock from the service and send their letter in a locked box within the envelope. As before, the post office opens the envelope and then puts it in another envelope and delivers it to the intended recipient. However, due to the locked box, the postal service personnel can no longer see the contents of the letter.
In reality, many IMs (e.g. WhatsApp) are using the Signal protocol to implement E2EE’s “postal service locked boxes” with public key cryptography. Users create their private and public key pair on their device when they join the IM service, and provide their public keys to the IM service, which maintains the directory of the user’s public keys. When parties wish to converse, the IM server provides them with their counterparty’s public keys.
It should be noted, as discussed above, that the newly added E2EE public key creates a new public identifier for the user known to all other users. When users lose their device, they must issue a new pair of keys for the service. Aware attackers might leverage this information to infer changes on the user side and leverage them to facilitate attacks. But that small privacy leak seems like a worthy price to pay compared to the security benefits of E2EE.
IMs E2EE and Multiple Devices: The privacy leak
As mentioned above, as IM apps’ popularity grew, users expected IM apps to be present on every screen they use, not just mobile. IM apps now need to implement a Multi-device solution. However there was a problem: In the pre-E2EE era, the multi-device support requirements were trivial to solve. Since the IM server had access to the contents of the message, senders could just send their message once to the server, totally unaware of the receiver’s device setup and the IM server would handle its distribution to all of the receiver’s devices and sender’s other devices (so that their history would be up to date). However once E2EE is applied, the IM server cannot read the contents of the message and thus can no longer distribute them to all of the devices.
To solve it, Signal developed the Sesame protocol. Under this protocol each of the user’s devices is assigned with a public key which is available to any user to query. WhatsApp and many other IM apps adopted the Sesame protocol.
One of the drawbacks of this solution is that it multiplies the aforementioned small privacy leak: Now attackers can learn the exact number of their target IM installed devices. In addition, attackers can monitor changes to user’s devices’ setup and infer on real-world events based on that. It should be noted that even non-sophisticated attackers, such as a jealous spouse, can abuse such information leakage in itself (new device was bought) or leverage this information (IM app is now accessible on the computer) to get access to the IM app content.
Privacy Issue demonstrated in Meta’s WhatsApp
As we revealed on X earlier this year, the way for attackers to obtain WhatsApp users’ device information is by leveraging WhatsApp web client. This client is using the browser’s local storage to store the devices’ identity key.
The browser’s developer tools provide an easy way to view the contents of this table (“Signal-storage.identity-store”) as depicted below.
The identity store table: All contacts’ devices and their Identity Keys
This table is storing all of the user’s contacts and their corresponding identity keys. Primary devices are identified by the phone number and the ‘.0’ suffix, while companion devices have a ‘:<n>.0’ suffix (e.g. ‘:16.0’).
By sampling a few instances, we had verified that this table’s data indeed corresponds to the actual user devices.
For example this user (“User X”) have 1 primary device and 3 companion devices:
WhatsApp’s linked devices screen of user X
User X’s corresponding entries in the identity store table matched this information perfectly
User X’s corresponding entries in the identity store table
We have responsibly disclosed this issue to Meta, but they decided not to solve it.
Conclusions and Further Reading
Zengo research continues to be at the forefront of cyber-security and cryptography research in order to derive relevant insights to secure Zengo users.
To learn more technical details about this research you can check our conference paper and video once they get published or read our technical blogpost about it. In addition you can check another technical blogpost about the integrity issues created by Sesame protocol and our sketch for a solution.
