Updated 2023-01-10, 20:53 CET (Added TL;DR box, clarified lead)
Last year, a student at the Department of Computer Science at ETH Zurich wrote his master’s thesis on Threema’s communication protocol. ETH Zurich has now published his work as a paper/preprint. The presented findings have been addressed or no longer apply to Threema’s current communication protocol “Ibex.” None of them ever had any considerable real-world impact.
For bringing the findings to our attention and for spending several months analyzing Threema’s cryptography, we would like to thank Kien Tuong Truong and his supervisors, Prof. Kenny Paterson and Matteo Scarlata of the Applied Cryptography Group at ETH Zurich.
While some of the findings presented in the paper may be interesting from a theoretical standpoint, none of them ever had any considerable real-world impact. Most assume extensive and unrealistic prerequisites that would have far greater consequences than the respective finding itself.
One such prerequisite is, for example, physical access to an unlocked Android device over a period of about twelve hours (with no passphrase set in Threema). In a scenario like this, the entire device must be considered compromised, and it follows a fortiori that Threema must also be considered compromised. For any app can only ever be as secure as the device/OS it runs on.
Despite the theoretical nature of these findings and as part of our continued commitment to maintain our strict standards of integrity and security, we have implemented appropriate measures to address those findings that were not already rendered irrelevant by the Ibex protocol (see Technical Details).
To learn more about Threema’s cryptographic communication protocol “Ibex,” which was developed over the course of 1.5 years and supports Perfect Forward Secrecy on the end-to-end layer, please refer to this blog post.
Before we discuss each finding in detail, here’s a summary:
The Threema apps are open source, and security researchers can subject them to independent reviews at any time. A bug bounty of up to CHF 10,000 awaits those who come up with a relevant security finding. In addition to that, external experts are regularly commissioned to conduct systematic security audits.
This theoretical finding would have allowed an adversary who has somehow managed to obtain an ephemeral private key used for connecting to the chat server, as well as a session transcript, to impersonate the user towards the chat server and thus view metadata of received messages and prevent selected messages from being delivered.
In practice, in order to obtain the ephemeral private key, the adversary would have needed the ability to read app memory contents or influence the device’s random number generator – at which point the adversary would have many other options to intercept any information processed by the user’s device in any app.
Thus, there is no practicability at all. No way of obtaining an ephemeral private key was found, even with physical access to the targeted user’s unlocked device.
This finding is described in two variants, both relying on social engineering, requiring extensive cooperation by the targeted user, and theoretically giving an adversary the opportunity to view metadata for incoming messages and prevent selected messages from being delivered.
This variant exploits a payload confusion issue in the legacy chat server authentication procedure combined with the use of a Threema Gateway ID with a specifically chosen public key.
An adversary would have needed to do all of the following:
As this variant requires the purchase of a Threema Gateway ID with a specifically chosen public key, we can confirm that no such Gateway IDs exist, other than those created by the paper’s author. Therefore, there has never been an attempt to create such a Gateway ID in the wild. We have blocked the creation of new Gateway IDs with such public keys, rendering exploitation impossible.
Note that the adversary could not send any messages from their Threema Gateway ID (as they do not have the corresponding private key) and thus would have needed to use another channel or another Threema ID to communicate with the targeted user.
Threema OnPrem is not affected by this theoretical issue, as it requires administrative access to the on-premises server instance for the creation of Gateway IDs.
This variant exploits a bug in a common ZIP library for Java (Zip4j). However, the prerequisites for this variant are so numerous and difficult to meet that a successful exploit would be extremely unlikely. Specifically, an adversary would need to do all of the following:
A compromised Threema server could reorder or omit messages while they are in transit.
Note that even in 1:1 chats without PFS, omissions would be apparent to the sender anyway as they will not receive a delivery receipt. Also, reordering is only possible while a bundle of messages is in transit (typically messages are delivered/pushed immediately and individually as soon as they have been transmitted).
A compromised Threema server could replay or reflect messages to a user who has lost their nonce database due to reinstalling the app. Only messages received prior to reinstallation could be replayed or reflected.
A compromised Threema directory server could theoretically trick a client into encrypting an arbitrary message to another user.
If a targeted user handed a completely unprotected and unlocked device to the adversary and the app had no PIN or biometric protection set, the adversary could, by design, clone the user’s Threema ID by means of the ID export feature. However, had the adversary connected to the Threema server at the same time as the targeted user, the latter would have been notified.
The ID export feature is designed to let users take control of their private key so they can move their Threema ID to another device without losing it when they switch to a new device. As Threema does intentionally not have traditional accounts tied to a username/password or a phone number, the app assumes that whoever has the unlocked device and also knows the app PIN (if set) is authorized to export the ID.
Users can easily guard against this issue by setting an app PIN or enabling biometric protection. Threema
Work and OnPrem admins also have fine-grained control over their users’ backup/export capability via MDM
parameters (th_disable_id_export and others).
This finding exploits a compression oracle in the generation of Threema Safe backup data to recover the private key of the Threema ID. It would have required physical access to an unlocked device for an extended period of time (in the order of twelve hours) and would have only worked in the Android version of the app (due to implementation details) and also only if no passphrase was set in the app.
