Kids, don't try this at home! That is, don't take it upon yourself to discuss your company's business without management approval. It will often get you fired. On the other hand, this post makes the company look good, as far as I can tell, so the author is probably safe.
This is a very interesting and well written post, thanks for sharing. Even if you don't care about Threema it's a nice history lesson of how secure messengers evolved and in general how it's easy to critisize something while assuming you know all the external constraints.
> And then there was TextSecure, made by Twitter [...] Open Whisper Systems was founded in 2013, and until 2014 TextSecure had no support for group chats. (Today, the codebases of TextSecure and RedPhone have evolved into Signal.)
I totally forgot about the Twitter - Signal connection.
I don't understand why Threema stakeholders are responding so defensively to this. It doesn't work. They're not gaining anything by doing this. There is a smart way to handle academic findings against your protocol: by making the argument that formal analysis is making your system stronger, which it is.
Instead, what we seem to be getting is a bunch of mitigating handwaving that suggests the opposite thing: that when the vendor screws up their cryptosystem, they're going to do an internal assessment about whether the practical details are a big enough to deal to merit taking them seriously.
To start with: this isn't a paper "by a master student at ETH"; it's a research paper by Kien Tuong Truong and Matteo Scarlata, both grad students at ETH Applied Cryptography, and Kenny Paterson, who is one of the best known academic cryptographers on the Internet.
Then: it's true that Threema predates a lot of modern messaging cryptography --- it predates the Signal Protocol double ratchet, for instance. It does not, on the other hand, predate authenticated key exchanges. As the Threema paper points out and cites, OTR had a similar AKE vulnerability long before Threema; the 2005 OTR paper gives the desired property, missing in Threema, a name: "session independence".
But, more importantly, it's entirely besides the point whether Threema predates best practices in messaging cryptography. The point is: they're best practices for a reason. You don't get points for effort; your system either works or it doesn't. Secure messaging is a ruthlessly difficult domain to work in, and it should be: these systems are asking people to entrust life-or-death secrets to them (Threema is the official secure messenger of the Swiss military).
The vulnerabilities here simply are what they are:
1. Because the client/server protocol in Threema uses a hacked-up authenticated key exchange, rather than something from the literature, the loss of an ephemeral key destroys its security; it perhaps mightn't not have had ephemeral keys at all, since they weaken the security of the protocol.
2. Because there isn't any key separation between the protocols in the basic Threema protocol, you can encrypt end-to-end (person-to-person) messages and play them back in the client/server protocol to bypass authentication.
3. Because the end-to-end protocol didn't authenticate metadata, attackers can reorder and drop messages.
4. In part because the end-to-end protocol is simplistic (it has no forward security, let alone post-compromise security!), it has to do a gross nonce-tracking hack to prevent message replay, which means that Threema clients had to defensively save state to protect themselves from attackers, to which they would be susceptible if they ever reinstalled.
5. Again because of a lack of key separation, you could bounce the Threema registration protocol off of the end-to-end protocol and forge authenticated messages from users.
6. Because they designed a backup system for user comfort instead of resilience against attackers, an unlocked phone could be used for full account compromise.
Threema insists on spelling out all the reasons these attacks are difficult to carry out in practice. Who cares? The point is: don't have these problems. This is academic cryptography research, the point of which is to inform future generations of implementers and researchers about what does and doesn't work in protocol design. Taking potshots at the number of cores required to get the Threema E2E protocol to spoof a client/server login is a waste of time. It shouldn't be possible to carry out that attack with any number of cores, and the protocol change required to make that attack impossible is simple.
Everybody, most especially Threema, should be going out of their way to extract lessons from research like this, rather than throwing up smokescreens about it.
(We've got a podcast episode with this research team going...
the blog post is well written and underlines the fact that Paterson and students tend to oversell the magnitude of the bugs they find and patch in messengers, always with quite the publicity involved and often overstating the rarity of the circumstances occurring that lead to the bugs
No, they don't, and the "rarity of the circumstances" thing is irrelevant. These are academic cryptography researchers doing academic cryptography research, and this blog post engages with it as if it was a hostile Consumer Reports review.
The point of this research isn't to make a decision about what messenger you use. The point is to help inform the designers of future, better messaging protocols about what does and doesn't work. Threema's design is littered with stuff that didn't work; it's an important cautionary tale.
You can, according to the paper, send a classic Threema protocol user a message that, if repeated or forwarded, allows someone else to log in as them. That's a distinctively weird and bad problem for a protocol to have. As I said in a comment elsewhere: the Matrix vulnerabilities were much more damaging to Matrix, but the Threema vulnerabilities were much worse as cryptographic flaws. There is more to learn from Threema's failures than from Matrix's.
I agree with the need for the research in the area. they are a big team and the yearly bug they identify in messenger services benefit the public.
I lament the dissemination by that group, always through a PR wave trying to place shocking headlines amplified by the school PR. that was the same in their past discoveries.
You've accused the researchers twice now of exaggerating the importance of the vulnerabilities they found. This comment is almost entirely unresponsive to the comment you're replying to, which states:
> You can, according to the paper, send a classic Threema protocol user a message that, if repeated or forwarded, allows someone else to log in as them. That's a distinctively weird and bad problem for a protocol to have.
Can you be precise about what specific claims they made and how the claims were deceptive?
A highly motivated nation state actor can (sometimes) turn a rare circumstance into a reliable exploit. Or some other researcher with a different mindset.
Image if they tried to downplay the heartbeat or speculative execution bugs with arguments like “but you’d need access to the server and what can you do with a small chunk of memory anyway?”
IMHO just take your swat on the nose and fix your shit without going into defensive mode is the way to handle these things.
> To start with: this isn't a paper "by a master student at ETH"; it's a research paper by Kien Tuong Truong and Matteo Scarlata, both grad students at ETH Applied Cryptography, and Kenny Paterson, who is one of the best known academic cryptographers on the Internet.
This misunderstanding has been cleared up thanks to an e-mail from Matteo / Kenny (it's a separate research paper that is _based_ on the thesis) and I just fixed the wording in the blogpost by using terminology "research team" and "research paper". There was no intent to misrepresent the authorship of the paper, I apologize.
> Threema insists on spelling out all the reasons these attacks are difficult to carry out in practice. Who cares?
A lot of people who used or use Threema do care. I fully understand your argument from an academic standpoint. But if there's a website accopmanying the paper that summarizes the attacks in simplified terms, then I assume that the target group of that website are non-academics (otherwise folks could simply read the paper), and then the risk analysis / impact is an important aspect.
> Everybody, most especially Threema, should be going out of their way to extract lessons from research like this
I can ensure you that we do :) (Including lessons on communication.)
This is exactly what you should not be doing. There have been much less severe issues in protocols that have led to everyone going away from it. What may be difficult to exploit practically now, will be easy to exploit in a bit of time. And probably peanuts for gov actors with a lot of resources.
Why can't you appreciate the research that has been done here?
18 comments
[ 2.0 ms ] story [ 58.0 ms ] thread> And then there was TextSecure, made by Twitter [...] Open Whisper Systems was founded in 2013, and until 2014 TextSecure had no support for group chats. (Today, the codebases of TextSecure and RedPhone have evolved into Signal.)
I totally forgot about the Twitter - Signal connection.
Instead, what we seem to be getting is a bunch of mitigating handwaving that suggests the opposite thing: that when the vendor screws up their cryptosystem, they're going to do an internal assessment about whether the practical details are a big enough to deal to merit taking them seriously.
To start with: this isn't a paper "by a master student at ETH"; it's a research paper by Kien Tuong Truong and Matteo Scarlata, both grad students at ETH Applied Cryptography, and Kenny Paterson, who is one of the best known academic cryptographers on the Internet.
Then: it's true that Threema predates a lot of modern messaging cryptography --- it predates the Signal Protocol double ratchet, for instance. It does not, on the other hand, predate authenticated key exchanges. As the Threema paper points out and cites, OTR had a similar AKE vulnerability long before Threema; the 2005 OTR paper gives the desired property, missing in Threema, a name: "session independence".
But, more importantly, it's entirely besides the point whether Threema predates best practices in messaging cryptography. The point is: they're best practices for a reason. You don't get points for effort; your system either works or it doesn't. Secure messaging is a ruthlessly difficult domain to work in, and it should be: these systems are asking people to entrust life-or-death secrets to them (Threema is the official secure messenger of the Swiss military).
The vulnerabilities here simply are what they are:
1. Because the client/server protocol in Threema uses a hacked-up authenticated key exchange, rather than something from the literature, the loss of an ephemeral key destroys its security; it perhaps mightn't not have had ephemeral keys at all, since they weaken the security of the protocol.
2. Because there isn't any key separation between the protocols in the basic Threema protocol, you can encrypt end-to-end (person-to-person) messages and play them back in the client/server protocol to bypass authentication.
3. Because the end-to-end protocol didn't authenticate metadata, attackers can reorder and drop messages.
4. In part because the end-to-end protocol is simplistic (it has no forward security, let alone post-compromise security!), it has to do a gross nonce-tracking hack to prevent message replay, which means that Threema clients had to defensively save state to protect themselves from attackers, to which they would be susceptible if they ever reinstalled.
5. Again because of a lack of key separation, you could bounce the Threema registration protocol off of the end-to-end protocol and forge authenticated messages from users.
6. Because they designed a backup system for user comfort instead of resilience against attackers, an unlocked phone could be used for full account compromise.
Threema insists on spelling out all the reasons these attacks are difficult to carry out in practice. Who cares? The point is: don't have these problems. This is academic cryptography research, the point of which is to inform future generations of implementers and researchers about what does and doesn't work in protocol design. Taking potshots at the number of cores required to get the Threema E2E protocol to spoof a client/server login is a waste of time. It shouldn't be possible to carry out that attack with any number of cores, and the protocol change required to make that attack impossible is simple.
Everybody, most especially Threema, should be going out of their way to extract lessons from research like this, rather than throwing up smokescreens about it.
(We've got a podcast episode with this research team going...
The point of this research isn't to make a decision about what messenger you use. The point is to help inform the designers of future, better messaging protocols about what does and doesn't work. Threema's design is littered with stuff that didn't work; it's an important cautionary tale.
You can, according to the paper, send a classic Threema protocol user a message that, if repeated or forwarded, allows someone else to log in as them. That's a distinctively weird and bad problem for a protocol to have. As I said in a comment elsewhere: the Matrix vulnerabilities were much more damaging to Matrix, but the Threema vulnerabilities were much worse as cryptographic flaws. There is more to learn from Threema's failures than from Matrix's.
I lament the dissemination by that group, always through a PR wave trying to place shocking headlines amplified by the school PR. that was the same in their past discoveries.
> You can, according to the paper, send a classic Threema protocol user a message that, if repeated or forwarded, allows someone else to log in as them. That's a distinctively weird and bad problem for a protocol to have.
Can you be precise about what specific claims they made and how the claims were deceptive?
Image if they tried to downplay the heartbeat or speculative execution bugs with arguments like “but you’d need access to the server and what can you do with a small chunk of memory anyway?”
IMHO just take your swat on the nose and fix your shit without going into defensive mode is the way to handle these things.
https://news.ycombinator.com/newsguidelines.html
That was actually a misunderstanding. Because the paper was listed at https://appliedcrypto.ethz.ch/education/student-projects/mas... (under the heading "Master Theses") I was under the impression that this paper was Kien's master thesis.
This misunderstanding has been cleared up thanks to an e-mail from Matteo / Kenny (it's a separate research paper that is _based_ on the thesis) and I just fixed the wording in the blogpost by using terminology "research team" and "research paper". There was no intent to misrepresent the authorship of the paper, I apologize.
> Threema insists on spelling out all the reasons these attacks are difficult to carry out in practice. Who cares?
A lot of people who used or use Threema do care. I fully understand your argument from an academic standpoint. But if there's a website accopmanying the paper that summarizes the attacks in simplified terms, then I assume that the target group of that website are non-academics (otherwise folks could simply read the paper), and then the risk analysis / impact is an important aspect.
> Everybody, most especially Threema, should be going out of their way to extract lessons from research like this
I can ensure you that we do :) (Including lessons on communication.)
Why can't you appreciate the research that has been done here?