8 ms·

Three lessons from Threema: Analysis of a secure messenger

145 points by thijser 4y ago

mattwilsonn888 4y ago
I would be very interested to know what overlap any of these attack surfaces may have with Signal, or other prominent applications. What issues are fixable, which are more endemic to the classical architectures?
- tptacek 4y ago
  The paper discusses this. The issues here are all idiosyncratic to Threema's design. I don't know what "classical architectures" refers to here, but one of Paterson's research areas is formal modeling of cryptography protocols, and a recurring complaint in this paper is that Threema is at turns either so simplistic or so weird that it is hard to apply the formal models the field has already built to it.
spacebeer 4y ago
I haven't read all, but Attack no. 6 requires access to unlocked phone. IMO, if that is the case, I wouldn't consider this as an attack, at least not as something that would stop me using the service
- woodruffw 4y ago
  From the paper, my reading is that it's meant to highlight a larger weakness in Threema's design (the decision to rely heavily on a long-lived private key, which then needs to be exported with a potentially attacker-controllable password in order to transfer identity). Edit: notably, this wouldn't be a problem if (1) Threema required a preconfigured password to encrypt the private key with, or (2) used an identity transfer scheme that was detectable on the target device. But since they're just copying a key, it's entirely undetectable.
upofadown 4y ago
Threema has responded: https://threema.ch/en/blog/posts/news-alleged-weaknesses-statement https://threema.ch/en/blog/posts/news-alleged-weaknesses-sta... New Paper on Old Threema Protocol
- tptacek 4y ago
  As Kenny Paterson points out, on behalf of the research group, the's "the old Threema protocol" in large part because of the work they did, which makes the "old protocol" thing pretty hollow.
  - rainsford 4y ago
    Also bragging in 2023 that your shiny new protocol has PFS really emphasizes that this is not a great PR strategy. Being dismissive of security research because you finally got around to implementing some cryptography principles that have been considered table stakes for a while now, especially if the research was part of what motivated your changes, is incredibly not confidence inspiring.
- rainsford 4y ago
  The baffling part of that response is that they could easily have conveyed the same basic message in a much less defensive way instead of making me glad I don't rely on Threema for my messaging security. "Good research, and here's how we've addressed those issues and proactively enhanced our security even further" is a decent story to be able to tell about how you're constantly trying to make your customers safer. Being defensive and dismissive sends the exact opposite message...image is more important than security.
  - collaborative 4y ago
    I can empathize with how stressful these reviews can be though
  - pgeorgi 4y ago
    > image is more important than security It's the company that's promoting its product with "Trust us, we're Swiss", even though it's a stupid argument after Crypto AG (and a few other, similar exploits): https://en.wikipedia.org/wiki/Crypto_AG https://en.wikipedia.org/wiki/Crypto_AG
dewey 4y ago
Not directly related to the topic but how is it that Threema is the only popular secure messenger where you have a random ID to give to people to communicate with and not a phone number (Signal) or have your name show up across all your contacts / groups (Telegram)?
- grammers 4y ago
  Not sure, but it seems like from a usability perspective it's easier for apps to 'just connect' people in your contacts via the phone number. From a privacy perspective, though, it's much better what Threema does. That's also why I use Tutanota, one of the very few mail providers that you can use without a phone number.
  - lxgr 4y ago
    > [...] 'just connect' people in your contacts via the phone number [...] Threema also allows that. I think they really nailed that aspect: Tie the primary identity to a key, not a phone number, and then add a discovery layer on top of that.
  - godelski 4y ago
    I agree here, but I think there is a simple and obvious middle ground. Allow for contacts to be connected through the address book (one time or continuous) but ALSO allow for contacts to be added without phone numbers. This could be through usernames or one time codes (like a QR or temp username). But importantly, there needs to be chat level handle specification. I don't want all my contacts to know I'm Godelski and I don't want all my contacts to know I'm [redacted]. I might also have other handles. It shouldn't be a difficult challenge to handle chat level handles (with a default option). It seems like just such an obvious solution. But I'm not a security person so maybe someone can tell me why I'm being naive.
- sundbry 4y ago
  It's not, there's also Session https://getsession.org/ https://getsession.org/
some_furry 4y ago
One of the key takeaways here that I think might be under-emphasized (although Kenny Paterson did say as much): Even if you use good cryptographic building blocks, and good libraries that implement the building blocks, you can still make horrible mistakes with protocol design. The best mechanism we have for preventing weak cryptographic protocols is to use formal methods (proofs, checked by a computer). https://twitter.com/kennyog/status/1612337097247002624 https://twitter.com/kennyog/status/1612337097247002624
deleted 4y ago
[deleted]
tptacek 4y ago
The attacks in this paper are much less damaging than the attacks in the Nebuchadnezzar paper were against Matrix. But somehow, Threema comes out looking even worse: * Threema's end-to-end inner protocol, the one used to exchange messages between actual humans, is based on a single X25519 key, used bidirectionally. It has no forward secrecy. Worse, to prevent otherwise-trivial replay attacks made possible by the simplistic structure of the protocol, both sides have to cache every nonce they've seen used to encrypt a message. This breaks down when users change devices, which, due to the structure of the protocol, is trivially detectable. * The Threema E2E protocol includes enough metadata to ostensibly enforce message ordering, but they don't authenticate it, so attackers can (1) strip the metadata off and (2) hold back and/or reorder messages at their luxury. * Threema has the hello-world of E2E protocols, but for reasons not made clear has chosen to build their own transport protocol for client-server transactions (ie, login), rather than using TLS or NoiseIK. The C2S handshake has the raw material to do an authenticated DH key exchange, ala 3DH (both sides have long-term and ephemeral secrets), but they freelanced it instead and come up with a proof-of-identity round trip that is trivially replayable, and which destroys the forward secrecy of the C2S protocol. * One form of Threema backup uses encrypted ZIPs, which reveal the names of files, which files apparently (according to the paper) reveal the identity of counterparties you've been talking to. Also: the ZIP library the client uses didn't verify MACs, and while Threema fixed that, the maintainer of the ZIP library Threema chose hasn't responded, which is :grimace-emoji:. * You can "lock" your Threema app, but it does so much background processing that attackers can extract your private key if they have access to the device (or, maybe, all its traffic?) --- to wit, Threema does automated backups, the backups are compressed-then-encrypted, Threema processes messages in the background even when locked, one of those messages runs an automatic contact discovery protocol, and attackers can inject contact-discovery messages to do a byte-by-byte CRIME-style recovery of the private key, which is embedded in the same JSON document(!) as contact information in the backup system. There is a very funny bit in the middle of the paper where they reconstitute the C2S proof-of-identity replay attack, this time minting a new identity proof rather than replaying it. To pull this off, they bounce the C2S protocol off of the E2E protocol: because, and I cannot believe I am saying this, Threema uses PKCS7 padding (ie, "I'm 3 bytes short of my block size, so I'll pad with 03h 03h 03h"), you can trick a Threema client into sending a message which, once encrypted, will have the 01h-delimited format of the identity proof (because 1/254 validly padded messages will happen to end in 01h). I didn't read closely enough to figure out if there was any reason you would go to the trouble of executing this attack variant, and it is entirely possible that they are just showing off. But: that's why you read these kinds of papers! For the stunt cryptography! A bit of advice: read these papers for the cryptographic design and pitfall ideas, not for verdicts on which messaging systems to use. Maybe there are very good reasons to use Threema besides its flimsy protocol design; the point is: we know how to design better protocols that don't have these problems, and so (1) here are some more examples for the textbooks on why you should domain-separate your keys (for instance, to make it impossible to bounce the C2S protocol off the E2E protocol in the first place), and (2) Threema could drastically improve their system simply by adopting a known-good protocol rather than freelancing their own. Great stuff. [1] https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/
marosgrego 4y ago
Threema messages of Marian Kočner, a contorversial Slovak businessman who allegedly ordered a murder of a local journalist, were somehow obtained with the help of Europol. [0] The part of his trial where a security expert explained how the police got the messages was purposely not made public. [0] https://spectator.sme.sk/c/22216551/threema-saga-kocner-reportedly-referred-to-fico-as-the-boss.html https://spectator.sme.sk/c/22216551/threema-saga-kocner-repo...
- guerrilla 4y ago
  Is there some reason that's interesting? What they do here is just hack the phones, so get access to all the texting apps from the client side... Was there some implication they did otherwise in that case?
  - godelski 4y ago
    There is always some trust with private communication apps. No way one can get a completely trustless system. Signal tries to build trust by being open source and by publishing the same documents it sends in subpoenas[0] (i.e. transparency in how they respond to government requests). The lack of understanding how the information was obtained is worthy of increased suspicion albeit not abandonment. There is added suspicion in that I cannot find an official response by the Threema team. We do not know if the encryption was broken or if there was access (physical or remote) to the phone. Do note that Threema is open sourced[1]. But there can still be concern if access to the phone was gained through other means and then access to the app was gained. There's a brush off of "if physical access is gained, not our problem" but that's not nearly enough (it still shouldn't be trivial). Assuming user error first is not a good methodology in response to these types of attacks (which there is some brushing off in this manner in Threema's response to this thread's link). People are still probing a black box at the end of the day. [0] https://signal.org/bigbrother/ https://signal.org/bigbrother/ [1] https://threema.ch/en/open-source https://threema.ch/en/open-source
    - tptacek 4y ago
      The Threema server isn't open source, is it?
karlkloss 4y ago
The problem with messengers: The more secure and privacy centered they are, the less likely it is that any of your friends and relatives use them.
- Krasnol 4y ago
  WhatsApp is pretty secure compared to most of the other messengers out there and it's quite popular in some countries. So that's not it. It's marketing and/or being at the right place at the right time.

145 points by thijser 4y ago

I would be very interested to know what overlap any of these attack surfaces may have with Signal, or other prominent applications. What issues are fixable, which are more endemic to the classical architectures?

tptacek 4y ago
The paper discusses this. The issues here are all idiosyncratic to Threema's design. I don't know what "classical architectures" refers to here, but one of Paterson's research areas is formal modeling of cryptography protocols, and a recurring complaint in this paper is that Threema is at turns either so simplistic or so weird that it is hard to apply the formal models the field has already built to it.

spacebeer 4y ago

I haven't read all, but Attack no. 6 requires access to unlocked phone. IMO, if that is the case, I wouldn't consider this as an attack, at least not as something that would stop me using the service

woodruffw 4y ago
From the paper, my reading is that it's meant to highlight a larger weakness in Threema's design (the decision to rely heavily on a long-lived private key, which then needs to be exported with a potentially attacker-controllable password in order to transfer identity). Edit: notably, this wouldn't be a problem if (1) Threema required a preconfigured password to encrypt the private key with, or (2) used an identity transfer scheme that was detectable on the target device. But since they're just copying a key, it's entirely undetectable.

upofadown 4y ago

Threema has responded: https://threema.ch/en/blog/posts/news-alleged-weaknesses-statement https://threema.ch/en/blog/posts/news-alleged-weaknesses-sta... New Paper on Old Threema Protocol

tptacek 4y ago
As Kenny Paterson points out, on behalf of the research group, the's "the old Threema protocol" in large part because of the work they did, which makes the "old protocol" thing pretty hollow.
- rainsford 4y ago
  Also bragging in 2023 that your shiny new protocol has PFS really emphasizes that this is not a great PR strategy. Being dismissive of security research because you finally got around to implementing some cryptography principles that have been considered table stakes for a while now, especially if the research was part of what motivated your changes, is incredibly not confidence inspiring.
rainsford 4y ago
The baffling part of that response is that they could easily have conveyed the same basic message in a much less defensive way instead of making me glad I don't rely on Threema for my messaging security. "Good research, and here's how we've addressed those issues and proactively enhanced our security even further" is a decent story to be able to tell about how you're constantly trying to make your customers safer. Being defensive and dismissive sends the exact opposite message...image is more important than security.
- collaborative 4y ago
  I can empathize with how stressful these reviews can be though
- pgeorgi 4y ago
  > image is more important than security It's the company that's promoting its product with "Trust us, we're Swiss", even though it's a stupid argument after Crypto AG (and a few other, similar exploits): https://en.wikipedia.org/wiki/Crypto_AG https://en.wikipedia.org/wiki/Crypto_AG

dewey 4y ago

Not directly related to the topic but how is it that Threema is the only popular secure messenger where you have a random ID to give to people to communicate with and not a phone number (Signal) or have your name show up across all your contacts / groups (Telegram)?

grammers 4y ago
Not sure, but it seems like from a usability perspective it's easier for apps to 'just connect' people in your contacts via the phone number. From a privacy perspective, though, it's much better what Threema does. That's also why I use Tutanota, one of the very few mail providers that you can use without a phone number.
- lxgr 4y ago
  > [...] 'just connect' people in your contacts via the phone number [...] Threema also allows that. I think they really nailed that aspect: Tie the primary identity to a key, not a phone number, and then add a discovery layer on top of that.
- godelski 4y ago
  I agree here, but I think there is a simple and obvious middle ground. Allow for contacts to be connected through the address book (one time or continuous) but ALSO allow for contacts to be added without phone numbers. This could be through usernames or one time codes (like a QR or temp username). But importantly, there needs to be chat level handle specification. I don't want all my contacts to know I'm Godelski and I don't want all my contacts to know I'm [redacted]. I might also have other handles. It shouldn't be a difficult challenge to handle chat level handles (with a default option). It seems like just such an obvious solution. But I'm not a security person so maybe someone can tell me why I'm being naive.
sundbry 4y ago
It's not, there's also Session https://getsession.org/ https://getsession.org/

some_furry 4y ago

One of the key takeaways here that I think might be under-emphasized (although Kenny Paterson did say as much): Even if you use good cryptographic building blocks, and good libraries that implement the building blocks, you can still make horrible mistakes with protocol design. The best mechanism we have for preventing weak cryptographic protocols is to use formal methods (proofs, checked by a computer). https://twitter.com/kennyog/status/1612337097247002624 https://twitter.com/kennyog/status/1612337097247002624

deleted 4y ago

[deleted]

tptacek 4y ago

The attacks in this paper are much less damaging than the attacks in the Nebuchadnezzar paper were against Matrix. But somehow, Threema comes out looking even worse: * Threema's end-to-end inner protocol, the one used to exchange messages between actual humans, is based on a single X25519 key, used bidirectionally. It has no forward secrecy. Worse, to prevent otherwise-trivial replay attacks made possible by the simplistic structure of the protocol, both sides have to cache every nonce they've seen used to encrypt a message. This breaks down when users change devices, which, due to the structure of the protocol, is trivially detectable. * The Threema E2E protocol includes enough metadata to ostensibly enforce message ordering, but they don't authenticate it, so attackers can (1) strip the metadata off and (2) hold back and/or reorder messages at their luxury. * Threema has the hello-world of E2E protocols, but for reasons not made clear has chosen to build their own transport protocol for client-server transactions (ie, login), rather than using TLS or NoiseIK. The C2S handshake has the raw material to do an authenticated DH key exchange, ala 3DH (both sides have long-term and ephemeral secrets), but they freelanced it instead and come up with a proof-of-identity round trip that is trivially replayable, and which destroys the forward secrecy of the C2S protocol. * One form of Threema backup uses encrypted ZIPs, which reveal the names of files, which files apparently (according to the paper) reveal the identity of counterparties you've been talking to. Also: the ZIP library the client uses didn't verify MACs, and while Threema fixed that, the maintainer of the ZIP library Threema chose hasn't responded, which is :grimace-emoji:. * You can "lock" your Threema app, but it does so much background processing that attackers can extract your private key if they have access to the device (or, maybe, all its traffic?) --- to wit, Threema does automated backups, the backups are compressed-then-encrypted, Threema processes messages in the background even when locked, one of those messages runs an automatic contact discovery protocol, and attackers can inject contact-discovery messages to do a byte-by-byte CRIME-style recovery of the private key, which is embedded in the same JSON document(!) as contact information in the backup system. There is a very funny bit in the middle of the paper where they reconstitute the C2S proof-of-identity replay attack, this time minting a new identity proof rather than replaying it. To pull this off, they bounce the C2S protocol off of the E2E protocol: because, and I cannot believe I am saying this, Threema uses PKCS7 padding (ie, "I'm 3 bytes short of my block size, so I'll pad with 03h 03h 03h"), you can trick a Threema client into sending a message which, once encrypted, will have the 01h-delimited format of the identity proof (because 1/254 validly padded messages will happen to end in 01h). I didn't read closely enough to figure out if there was any reason you would go to the trouble of executing this attack variant, and it is entirely possible that they are just showing off. But: that's why you read these kinds of papers! For the stunt cryptography! A bit of advice: read these papers for the cryptographic design and pitfall ideas, not for verdicts on which messaging systems to use. Maybe there are very good reasons to use Threema besides its flimsy protocol design; the point is: we know how to design better protocols that don't have these problems, and so (1) here are some more examples for the textbooks on why you should domain-separate your keys (for instance, to make it impossible to bounce the C2S protocol off the E2E protocol in the first place), and (2) Threema could drastically improve their system simply by adopting a known-good protocol rather than freelancing their own. Great stuff. [1] https://nebuchadnezzar-megolm.github.io/ https://nebuchadnezzar-megolm.github.io/

marosgrego 4y ago

Threema messages of Marian Kočner, a contorversial Slovak businessman who allegedly ordered a murder of a local journalist, were somehow obtained with the help of Europol. [0] The part of his trial where a security expert explained how the police got the messages was purposely not made public. [0] https://spectator.sme.sk/c/22216551/threema-saga-kocner-reportedly-referred-to-fico-as-the-boss.html https://spectator.sme.sk/c/22216551/threema-saga-kocner-repo...

guerrilla 4y ago
Is there some reason that's interesting? What they do here is just hack the phones, so get access to all the texting apps from the client side... Was there some implication they did otherwise in that case?
- godelski 4y ago
  There is always some trust with private communication apps. No way one can get a completely trustless system. Signal tries to build trust by being open source and by publishing the same documents it sends in subpoenas[0] (i.e. transparency in how they respond to government requests). The lack of understanding how the information was obtained is worthy of increased suspicion albeit not abandonment. There is added suspicion in that I cannot find an official response by the Threema team. We do not know if the encryption was broken or if there was access (physical or remote) to the phone. Do note that Threema is open sourced[1]. But there can still be concern if access to the phone was gained through other means and then access to the app was gained. There's a brush off of "if physical access is gained, not our problem" but that's not nearly enough (it still shouldn't be trivial). Assuming user error first is not a good methodology in response to these types of attacks (which there is some brushing off in this manner in Threema's response to this thread's link). People are still probing a black box at the end of the day. [0] https://signal.org/bigbrother/ https://signal.org/bigbrother/ [1] https://threema.ch/en/open-source https://threema.ch/en/open-source
  - tptacek 4y ago
    The Threema server isn't open source, is it?

karlkloss 4y ago

The problem with messengers: The more secure and privacy centered they are, the less likely it is that any of your friends and relatives use them.

Krasnol 4y ago
WhatsApp is pretty secure compared to most of the other messengers out there and it's quite popular in some countries. So that's not it. It's marketing and/or being at the right place at the right time.