Threema is a Swiss encrypted messaging application. It has more than 10 million users and more than 7000 on-premise customers. Prominent users of Threema include the Swiss Government and the Swiss Army, as well as the current Chancellor of Germany, Olaf Scholz. Threema has been widely advertised as a secure alternative to other messengers.
In our work, we present seven attacks against the cryptographic protocols used by Threema, in three distinct threat models. All the attacks are accompanied by proof-of-concept implementations that demonstrate their feasibility in practice.
Background
Secure messaging applications have the basic goal of allowing pairs and groups of users to communicate securely. Desirable properties include confidentiality, integrity, origin authentication, and prevention of message reordering, replay, insertion and deletion attacks.
State-of-the-art applications should also offer forward security and post-compromise security. Roughly speaking, forward security means that data exchanged prior to a compromise remains secure, while post-compromise security means that security can be recovered after an attack has taken place (provided the adversary does not always remain active in the communication exchanges).
All of this should be done in an end-to-end (E2E) secure manner, meaning that only the intended recipients should be able to read and send messages. Achieving E2E security minimises the trust required in the server that is typically used by such applications to store and forward messages.
Even prior to our work, it was known that Threema features neither forward security nor post-compromise security. We show that several of the other desirable security properties also fail to hold. Our work highlights some of the difficulties faced by developers in creating secure messaging systems. In addition, we draw lessons for developers of secure protocols more generally.
Our results
We uncover seven attacks, across three different threat models:
Network Attacker threat model: The standard attacker for secure network protocols. The adversary has control of the communication channels between parties (including the users and the server).
Compromised Server threat model: A model in which the server has been compromised and is acting maliciously. This is in accordance with the possibility of a security agency or advanced hacking group trying to obtain access to a large and concentrated amount of sensitive data. We expect a messaging application that claims to provide end-to-end security to be able to protect against this kind of attacker.
Compelled access threat model: A model in which the adversary has access to the device of the victim. Security against this kind of attacker is relevant in the case of border searches, when protesters are detained by police forces and searched for incriminating evidence, or in the setting of intimate partner violence. We assume that the attacker has managed to convince the user to unlock their phone. Even in this setting, we expect some degree of security to be achieved.
Attack 1 (Network Attacker)
Ephemeral Key Compromise Impersonation
Ephemeral keys are used by the Threema clients and server to create fresh keys for usage in Threema's bespoke client-to-server (C2S) protocol. In theory, this should make different sessions independent from each other (i.e. compromising one session should not influence the security of past or future sessions).
In contrast, we show that compromising a single client ephemeral key allows an attacker to impersonate that client to the server forever. Furthermore, we uncover improper reuse of ephemeral keys in the C2S protocol both on the client and on the server, with significant security impacts.
Attack 2 (Network Attacker)
Vouch Box Forgery
The Threema C2S protocol uses a special value called a vouch box in order to authenticate the user to the server. The vouch box is created by encrypting the user's ephemeral key with its long-term key (combined with the server's long-term key), binding them together.
By using a cross-protocol interaction between the C2S protocol and Threema's end-to-end (E2E) protocol, we show that the attacker can trick a user into creating a valid vouch box and sending it to the attacker. This allows the attacker to impersonate the client to the server forever.
This attack means that, under some circumstances, a user might compromise his or her own account by simply sending a message to another user.
Attack 3 (Compromised Server)
Message Reordering and Deletion
The Threema E2E protocol does not provide any way for a recipient to check the order in which messages were sent, nor for a sender to check whether a message has been delivered. Even though a timestamp is attached to each message, it is not integrity-protected and a malicious server can overwrite the timestamp with a fake one. The Threema application simply displays messages to a user in the order in which they were received.
Taken in combination, these features allow a malicious server to forward messages from one user to another in any desired order and to not deliver messages of its choice, all without being detected.
The impact of this attack is that the semantics of the conversation between two users can be altered by an attacker, despite it not being able to read the end-to-end encrypted messages.
Attack 4 (Compromised Server)
Replay and Reflection Attacks
Threema has an explicit mechanism to prevent replay and reflection attacks, based on remembering which messages were sent and received. Each message has a unique value associated with it, called the nonce, which is used as part of the encryption process. If a particular nonce is seen twice, the application simply discards the message.
In terms of performance, this approach requires additional storage to remember the nonces. Furthermore, it creates a problem when transferring an account between devices.
This is an issue on the Android version of the application, since there is no user-friendly way to transfer the nonce database to the new device. When reinstalling the application, the nonce database is also deleted. This makes the user vulnerable to having old messages replayed and reflected against them.
Attack 5 (Compromised Server)
Kompromat Attack
The following attack was patched in a previous version of the application. We choose to include it as it highlights fundamental weaknesses of the protocol: while the individual issue can be mitigated, a new protocol is required to tackle the problem at its root.
A malicious server can trick the client into using the same key while talking to the server during the initial registration protocol and while talking to other users in the E2E protocol.
By doing so, the server can fool any user Alice into unwittingly encrypting a message of the server's choosing that can be delivered to a different user Bob. Such a message could contain compromising material ('Kompromat'), e.g. libellous content or a false confession to a crime.
This is a second instance of a cross-protocol attack, this time between the registration protocol and the E2E protocol.
Attack 6 (Compelled Access)
Cloning via Threema ID Export
Threema provides a mechanism that allows the user to transfer their account to other devices, by copying over the user's long-term private key. The key is encrypted by using a password chosen on the spot.
While convenient for users, this opens up the possibility for an attacker to clone the account of a victim user in a matter of a few seconds, assuming that the victim's device is left unlocked. Since the security of the entire application relies on maintaining the secrecy of users' long-term private keys, this feature completely breaks security in the compelled access setting. Furthermore, an astute attacker can mount this attack undetectably, so the victim would have no way to notice that their account has been cloned and that their messages are being read.
Attack 7 (Compelled Access)
Compression Side-Channel
In addition to the key export feature, Threema provides its own cloud-based backup system in the form of Threema Safe. The user chooses a password and a key is derived from it. The user data is first compressed and then encrypted using the derived key. The backup includes, among other things, the user's long-term private key and the usernames of the user's contacts.
As showcased in the CRIME attack on TLS, this compress-then-encrypt paradigm is vulnerable to attack if the attacker has partial control of the data being protected. In the context of Threema, an attacker can control their own username, and we show that this is sufficient to make it possible to extract the victim user's long-term key. The attack requires the ability to force many backups to be done. On Android, a new backup attempt is made whenever the application is restarted and the last backup failed; this means that it suffices for an attacker to use the debugging tools to restart the application repeatedly. This enables the extraction of the victim user's private key in a few hours.
Disclosure and Mitigations
We disclosed our findings to the Threema development team on the 3rd of October 2022, including possible mitigations for the attacks. Soon after, we met with Threema representatives to discuss our work and its public disclosure. On that occasion, we agreed on an initial batch of mitigations to be released in Q4 of 2022, followed by the public disclosure and final mitigations to be released in Q1 of 2023. In December 2022, we agreed on the 9th of January 2023 as the date of public disclosure.
On the 29th of November 2022, Threema released a new protocol, Ibex, in order to further mitigate our attacks. The Ibex protocol aims to provide forward security for the E2E layer in Threema. We have not audited this new protocol.
Lessons Learned
We believe that all of the vulnerabilities we discovered have been mitigated by Threema's recent patches. This means that, at this time, the security issues we found no longer pose any threat to Threema customers, including OnPrem instances that have been kept up-to-date. On the other hand, some of the vulnerabilities we discovered may have been present in Threema for a long time.
There are several broader lessons to take away from our analysis of Threema.
Our work shows that it's not easy to assess the security claims made by developers of applications that rely on bespoke cryptographic protocols. Notably, previous independent audits of Threema did not review the cryptographic core of the application. Such an analysis should be a minimum requirement for any secure messenger, especially one being used in sensitive environments. Ideally, any application using novel cryptographic protocols should come with its own formal security analyses (in the form of security proofs) in order to provide strong security assurances. Such an analysis can help to reduce uncertainty about whether further serious cryptographic vulnerabilities still exist in Threema.
Our analysis also shows that there are some principles well-known in the research community which have not fully made their way into the community of developers using cryptography. We thus draw three lessons, which we think may be useful for such developers:
Using modern, secure libraries for cryptographic primitives does not, on its own, lead to a secure protocol design: libraries such as NaCl or libsignal can be misused while building more complex protocols and developers must be wary not to be lulled into a false sense of security. While the mantra don't roll your own crypto is now widely known, it should be extended to don't roll your own cryptographic protocol (assuming one already exists that meets the developer's requirements). In the case of Threema, the bespoke C2S protocol could be replaced by TLS.
Beware of cross-protocol interactions: even if a protocol on its own is considered secure, there is no a priori guarantee that it will be secure when composed with other protocols. Cross-protocol interactions can undermine the original security guarantees, as we have shown with the vouch box forgery and Kompromat attacks. Such bad interactions can be prevented by following the key separation principle which states that a system should use different keys for different purposes.
Proactive, not reactive security: our inability to find an attack on a protocol does not imply it is secure. New attacks could be found at any moment and known attacks only get stronger over time if left unaddressed. Often, secure systems and protocols follow a design-release-break-patch process (a reactive approach). This is inconvenient for users and often requires the maintenance of backwards compatibility. Developers should instead adopt a proactive approach, where the system or protocol is formally analyzed during the design stage.
