Stellungnahme zu ETH-Findings

Finding 1 (C2S Ephemeral Key Compromise)

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.

• Current app versions (Threema ≥5.0 for Android and Threema ≥4.8.5 for iOS) replace the legacy chat server authentication procedure (which was modelled after CurveCP) with a new protocol that solves this issue (along with finding 2). Ephemeral key caching has also been completely removed.

Finding 2 (Vouch Box Forgery)

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.

• Both variants are not reproducible in practice as Threema’s chat server verifies the validity of public keys before accepting them. Current app versions (Threema ≥5.0 for Android and Threema ≥4.8.5 for iOS) replace the legacy chat server authentication procedure with a new protocol that resolves the root issue with both variants (along with finding 1).

Finding 2a (Vouch Box Forgery – Threema Gateway)

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:

• Apply and pay for a Threema Gateway ID with a public key equivalent (for ECDH purposes) to the current chat server public key.
• Spend the computing power of about 8,000 CPU cores for one week to find a Curve25519 private key whose corresponding public key has a certain form that allows it to be expressed in a text message.
• Convince the targeted user to send this specially crafted “garbage” text message to the adversary’s Threema Gateway ID on average about 200 times for the exploit to work with adequate probability.

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.

Finding 2b (Vouch Box Forgery – Android data backup)

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:

• Obtain read and write access to the ZIP data backup created by a user of the Android version of the Threema app.
• Know where in the encrypted and compressed contact list backup inside the ZIP file his public key is stored. It could be anywhere in a range of typically several thousand bytes; the adversary needs to guess blindly, must hit the exact byte offset and typically only gets one chance (see below).
• Overwrite the location thus found/guessed, XORing in the difference between their own (compressed) public key and the server’s public key (as ZIP encryption uses AES-CTR). The fact that the backup data is compressed further complicates the exploit to the point where the adversary would essentially need to know the entire exact backup contents in advance.
• Wait for (or entice) the user to restore their Threema app data from the tampered backup ZIP. If the offset guessed in the second step is wrong, then the exploit will not work.
• Convince the targeted user to send a specially crafted “garbage” text message to the adversary’s Threema ID on average about 200 times for the exploit to work with adequate probability.

Finding 3 (Message Reordering and Omission)

A compromised Threema server could reorder or omit messages while they are in transit.

• Perfect Forward Secrecy (PFS) has been introduced last year with our new Ibex protocol. The paper describes the situation prior to Ibex. With PFS, reordered or missing messages are detected, and the user is warned.

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).

Finding 4 (Replay and Reflection)

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.

• Perfect Forward Secrecy (PFS) has been introduced last year with our new Ibex protocol. The paper describes the situation prior to Ibex. With PFS, replayed/reflected messages are detected and dropped even if the user has lost the nonce database.

Finding 5 (Kompromat)

A compromised Threema directory server could theoretically trick a client into encrypting an arbitrary message to another user.

• This is an old finding discovered by another researcher (Jonathan Krebs) and already addressed by Threema in 2021 (as the author of this paper was aware of). Furthermore, in current app versions (Threema ≥5.0 for Android and Threema ≥4.8.5 for iOS), the legacy directory server authentication procedure has been replaced.

Finding 6 (Cloning via Threema ID Export)

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).

• To ensure that the user will be informed even if a private key has been compromised due to careless actions by the user, we have further improved the detection method that will alert the user if there has been any connection using their Threema ID from another device since the last time that they used the app.

Finding 7 (Private Key Recovery through Compression Side-Channel)

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.

• Threema Safe compression is disabled in current app versions (Threema ≥5.0 for Android and Threema ≥4.8.5 for iOS), thus resolving this issue.