In recent months, privacy and civil rights activists have increasingly recommended the use of Signal [1], an instant messenger app developed by Open Whisper Systems (OWS). After Donald Trump’s victory in the US presidential election in particular, many tweets recommended using hard disk encryption and the ostensibly secure messenger app Signal while discouraging the use of competitor apps Threema and Telegram. On the German news portal linksunten (part of indymedia, frequented by left activists) an article of the same tenor appeared. [2] We believe this discussion took a wrong turn at one point. Furthermore, we see a risk of unnecessarily increasing exposure of activists and organizations to repression. For this reason we wish to contribute to the debate with the following article.
We do not want to diminish the incredible service OWS has done for the instant messaging world. The Signal protocol (formally known as Axolotl) combines cryptographically secure communication with ease of use. [3] The latter in particular is something which other means of secure communication like PGP have so far failed to provide to any comparable degree, effectively preventing non-technically-inclined people to participate in cryptographically secured communication without security trade-offs.
The Signal protocol implements Perfect Forward Secrecy, encrypted off-line messaging, and file transfers, which are features expected by users today, but which have not been provided in this combination by other open source technologies like the aforementioned PGP or Off the Record (OTR) messaging. And OWS did not just provide an open source library, but also the Signal client as a reference implementation. By doing so they put pressure on other messaging client vendors to implement encryption – today many instant messaging apps are employing the Signal protocol under the hood, the most prominent example being WhatsApp – and to publish their source code.
Signal’s web page suggests professionalism and transports the message ‚Install our software and your communication will be easy & secure. There is nothing more you will need to know.‘ Users of IT systems should be critical of any kind of universal security claim. There is no perfect security just as there is no universal cure for all diseases in the world. When thinking about secure communication, it is crucial to ask oneself what kind of security is desired over all.
There are many things users can and maybe should be concerned about: Hackers, providers, promoters, crooks, spooks, shareholders or maybe the person on the next seat in the bus. Do they want to prevent their data from being used for other purposes than communication itself? Maybe they want their messages to be tamper-evident, or perhaps they want plausible deniability or immunity against eavesdropping? What is the use of end-to-end encryption when there could be a key logger or a rootkit on their device, transmitting everything they do to a remote entity?
Encouraging users to believe in a general sense that Signal makes their communication safe, will tend to promote a false sense of once-and-for-all security (regardless of the indisputable and substantial increase in end-to-end encryption). It is very important to remember that even though encryption will increase security, some information should not be stored in IT systems at all – and especially not if they are provided by a third party.
However this is no argument against the use of the Signal messenger or protocol itself. We instead want to think about the problems created or supported by OWS‘ promise of security.
Signal uses servers controlled by OWS. Other organizations could conceivably operate their own servers because OWS open sources the software, but because OWS strictly opposes federation (meaning the interconnection of independently operated servers which the XMPP protocol (jabber) or e-mail allows), only the users connected to the OWS-run server can communicate with each other. There is no way to communicate with users of hypothetical, independent servers running the Signal software but not under control of OWS. So in the end users are forced to turn over their data to a single third party, OWS in this case, risking later changes in the terms of service, intervention by the state and analysis of their metadata. Because Signal uses phone numbers to identify users, metadata is abundantly available here. If a government does not approve of the use of Signal, it can simply block a single server farm, solving the problem for the state actor, and resulting in total loss of service to the users. This is no hypothetical scenario. For example in Turkey the government is notorious for blocking web services like Twitter, YouTube or Facebook. And when looking at the recent development in the ‚democratic west‘, we realize this problem will not be limited to Turkey or China.
As we mentioned before, Signal relies on using phone numbers as a user’s unique identifier. Phone numbers are usually not anonymous, even when using burner phones or throwaway SIM cards, they always give away more information than necessary. And using phone location and call logs it is only a matter of time before users are de-anonymized. In Germany, several cases of state oppression in connection to §129 StGB (Establishment of a criminal organization) have shown that knowing who knows whom is often enough for de-anonymization and conviction. In Signal, metadata is encrypted using transport layer security (SSL) but this still requires trust in both OWS as well as the trust center as issuing entity of the encryption certificates. Another possible threat is a client compromised by government entities, revealing at least the contact list.
A third attack vector would be what German prosecutors call Quellen-TKÜ (source wiretapping) where unknown to many users state entities can legally have platform providers like Google remotely and covertly install software on mobile devices, or even slipstreaming surveillance payload into computers via known exploits. [4] Android is also notorious for countless exploits and security vulnerabilities. These problems are not just known by OWS, they are amplified by them. Signal is unique among messengers with an emphasis on security in that it relies on the Google Cloud Messaging (GCM) platform used to distribute push notifications to the client devices. GCM unfortunately requires use of Google Play Services.
The community reacted to this by developing a version that does not rely on GCM, however, OWS refused to merge the changes into the Signal code. When the project was forked, they prevented the newly established LibreSignal project [5] from connecting to Signal’s servers and prohibited the use of the term “Signal” in their name. [6] The reason for this decision can only be speculated upon.
The final point of criticism is that OWS distributes the Signal app exclusively via Google Play while actively preventing the distribution of independent builds. Even though the source code is open and available for everyone, we still have to deal with binaries built by OWS and handled by Google. The threat of potentially malicious acts by the package maintainer or distributor will remain unless independent distribution channels are allowed, enabling users to choose whom to trust.
The distribution channel policy of OWS outlined above may allow conclusions regarding the political positions of OWS, which are partially disjunct from other parts of the open source community. It seems like OWS is trying to establish a brand using the Snowden hype after his NSA surveillance revelations and to stage themselves as heroes and protectors of citizens rights. The community’s demands for decentralized web services controlled by the users themselves, or by designated professionals elected by the users, seems like a burden to them.
OWS does not primarily enter into cooperations with other open source projects, but rather corporate players like Google, who want to employ the Signal cryptography in their proprietary products, for example the new messenger app Allo. Pervasive security is not the main aim but rather a means to enter the privacy-aware niche market in order to prevent users from switching out of their ecosystem. This allows corporate players to keep monitoring users and to harvest their metadata, a primary asset. So now we have high-level encryption of the messages between the sender and the recipient, but little protection of the mobile platform clients, and no protection of the metadata. On top of this, we have centralization of communication infrastructure, allowing authorities to extort cooperation from the providers by threat of law such as the U.S. Patriot Act, or even to literally pull the plug when convenient.
The success of OWS can also be attributed to elitist and bureaucratic positions in the open source community. The standardization of XMPP is slow, and has not yet specified a single preferred native encryption standard. Workarounds like OTR were developed outside of the protocol and fail to satisfy the users in many situations. Open source projects like the Pidgin instant messenger refused to implement and include OTR in the standard distribution of their software. Often there seems to be a lack of enthusiasm when it comes to building graphical user interfaces with a great user experience for the ’noobs‘ – or else to writing and maintaining documentation. In this elitist world view, the user is seen as the developer’s opponent and embodies the necessary, unpredictable evil in the protocol stack; the layer 8 [7] problem.
It is not the case that there is no alternative to Signal when it comes to comfortable and secure communication with individuals and groups, as well as image transfer. The Signal protocol was recently ported to XMPP (jabber) and the standardization process is pending, following the XEP (XMPP Extension Protocol) process. The drafted protocol is called OMEMO and combines the advantages of jabber and Signal. Even though the XEP Process will still take some time, the protocol is stable and can already be used today. On Android devices, users have the ‚Conversations‘ client [8], which offers an experience comparable to Signal, and on the desktop there is a plugin for ‚Gajim‘ [9, 10] under active development, which still has room for user experience improvements. Using one of the readily available tutorials, it is possible today to get started on Linux and Windows. iOS users will have to wait some time due to license issues.
When using the software, users should be aware that these technologies were developed outside of the corporate sphere and without industrial cooperation. It is advisable to adjust expectations accordingly. Overcriticising would be like complaining about a missing elevator in the neighbor-operated community center around the corner because the subsidized opera house has had one for years. When in doubt, users should ask a friend for help with setting things up. Grassroots solidarity can never be replaced by technology or elitist attitudes of lone crypto-heroism.
[1] security tips for protesters (EFF, 16.11.2016) https://www.eff.org/deeplinks/2016/11/digital-security-tips-for-protesters
[2] Empfehlung für Signal: „Zur Benutzung ’sicherer‘ Messenger“ (indymedia, 4.11.2016) https://linksunten.indymedia.org/de/node/195943
[3] Kryptoverfahren (Heise, 24.11.2016) https://www.heise.de/newsticker/meldung/Entwickler-dokumentieren-Krypto-Verfahren-des-Messengers-Signal-3501150.html
[4] Update Section in Legal Information of Play Services https://play.google.com/about/play-terms.html
[5] Kommentar Moxie Marlinspike (17.06.) https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-226646872
[6] Kommentar Moxie Marlinspike zur Verwendung des Namens in LibreSignal (5.5.) https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165
[7] https://en.wikipedia.org/wiki/Layer_8
[8] Android XMPP Messenger App Converstions https://conversations.im/
[9] Cross-Plattform XMPP Client Gajim https://gajim.org/
[10] OMEMO Plugin für Gajim https://github.com/omemo/gajim-omemo