[HN Gopher] Three lessons from Threema: Analysis of a secure mes...
___________________________________________________________________
Three lessons from Threema: Analysis of a secure messenger
Author : thijser
Score : 66 points
Date : 2023-01-09 19:04 UTC (3 hours ago)
(HTM) web link (breakingthe3ma.app)
(TXT) w3m dump (breakingthe3ma.app)
| [deleted]
| spacebeer wrote:
| 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 wrote:
| 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 wrote:
| Threema has responded:
|
| https://threema.ch/en/blog/posts/news-alleged-weaknesses-sta...
| New Paper on Old Threema Protocol
| tptacek wrote:
| 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.
| marosgrego wrote:
| Threema messages of Marian Kocner, 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-
| repo...
| guerrilla wrote:
| 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?
| some_furry wrote:
| 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
| mattwilsonn888 wrote:
| 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 wrote:
| 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.
| tptacek wrote:
| 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/
| dewey wrote:
| 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 wrote:
| 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 wrote:
| > [...] '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 wrote:
| 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.
| tptacek wrote:
| You're right; this isn't directly related to the topic. It's a
| recapitulation of every thread we have ever had about Signal,
| on a story that has very little to do with Signal and that
| unveils new cryptography research.
|
| Unfortunately, this is a big dynamic on HN, not just on
| cryptography threads, but especially on threads rooted in
| stories with intense technical details. It's time consuming to
| bring yourself up to speed with what the paper says, but it's
| easy to have something to say about, say, Signal phone numbers.
| Which means comments here will be heavily biased towards
| superficial and tangential stuff.
| badrabbit wrote:
| To be fair, they also mentioned telegram and the subject of
| the comment was a really good feature of threema.
| dewey wrote:
| I get your point but this is not a thread about Signal.
| Threema is a lot less common of a topic on HN than Signal and
| the only reason I'm using it and am familiar with it is this
| feature so I don't think it's such an off topic question to
| ask.
| TechBro8615 wrote:
| Telegram is an obvious law enforcement honeypot. Trust me bro,
| just upload all your contacts to our servers bro, we won't
| share them with anyone, promise...
|
| Hey, me and the guys are planning a riot at the Capitol. Wanna
| come? Join my telegram group and we can talk about it in secret
| thanks to end-to-end encryption! Here's the public link...
| godelski wrote:
| I think Signal takes its community temperature from their
| forums rather than other places that people normally talk on
| the internet like HN, Reddit, or Twitter. It is rather odd and
| those forums are pretty trash if I'm to be honest. There are a
| lot of people that fight tooth an nail on there to make Signal
| as static as possible, meaning no new features or anything
| else. A particularly interesting one I saw was a user saying
| Signal has pretty much solved the E2EE part and needs to focus
| more on privacy and anonymity[0] and a user just said that's
| not what Signal is about. I've seen users argue about deletion
| as "well you can't guarantee message wasn't seen, so don't
| 'trick users'" and argue that data sent to you is unequivocally
| yours and no one else's (even saying if someone accidentally
| sends you a nude that this is justification to not delete.
| Because they want the nude). So I've stopped going there
| because the environment is toxic at best. But on the other
| hand, I think places like Reddit/Twitter (and even HN) are
| critical on Signal in ways that don't make sense. Just creates
| too much noise (Twitter threads are just full of users asking
| about usernames no matter the topic. Come on people. I'm
| frustrated too, but you're just noise).
|
| I love Signal and think it is a great problem. I think it is
| too slow (e.g. username rollouts...) -- especially with Moxie's
| famous fuck decentralization speech -- and needs to actually
| adapt to the moving ecosystem, but people complain about it in
| weird ways. For better or for worse, right now it is the best
| game in town simply because messaging apps require networks.
| We'll see if they last though, because they aren't adapting
| fast enough. I think this would be a shame. But it is also a
| shame that Signal is failing so hard.
|
| [0] https://community.signalusers.org/t/signal-needs-to-shift-
| to...
| sundbry wrote:
| It's not, there's also Session https://getsession.org/
| alibert wrote:
| There is also https://www.olvid.io
|
| Tech paper for anyone interested:
| https://www.olvid.io/assets/documents/2020-12-15_Olvid-speci...
___________________________________________________________________
(page generated 2023-01-09 23:00 UTC)