3.6 KiB
| title | date | draft | tags | author | hidemeta | ShowReadingTime | ShowPostNavLinks | showtoc | cover | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Threema: analysis of a secure messenger | 2023-01-09T14:41:00+01:00 | false |
|
9x0rg | false | true | true | false |
|
[EDIT: 09.01.2023]: Threema has reacted to the publication in bold terms:
The [research] paper is based on an old protocol that is no longer in use. The presented findings do not apply to Threema’s current communication protocol “Ibex” or have already been addressed. None of them ever had any considerable real-world impact.
See how the story develops.
Threema is a Swiss encrypted messaging application which has been widely advertised as a secure alternative to Signal, WhatsApp or Wire. Threema claims It has more than 10 million users and more than 7,000 on-premise customers. Prominent users of Threema include the Swiss Government, the Swiss Army and the current Chancellor of Germany, Olaf Scholz.
A group of academic researchers from the Applied Cryptography Group at ETH Zurich (Swiss Federal Institute of Technology) presents seven attacks against the cryptographic protocols used by Threema in three distinct threat models.
Seems the researchers were quite happy with the outcome as they claim that all the attacks are accompanied by proof-of-concept implementations that demonstrate their feasibility in practice.
"Don't roll your own crypto" is already a classic - except for Telegram maybe. This mantra should be extended "don't roll your own cryptographic protocol" they write.
Key Takeaway
There are some principles well-known in the research community which have not fully made their way into the community of developers using cryptography.
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.
Report: Three Lessons from Threema (.pdf) by Prof. Kenneth G. Paterson, Matteo Scarlata, Kien Tuong Truong