Archiv für das Monat: November, 2016

Wrong signal (Das falsche Signal [engl])

27. November 2016/in Allgemein, English /von IT-Kollektiv

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
↩

Das falsche Signal

26. November 2016/in Allgemein /von IT-Kollektiv

In der näheren Vergangenheit wurde in datenschutz-sensiblen und aktivistischen Kreisen vermehrt zur Nutzung der App Signal von Open Whisper Systems (OWS) aufgerufen. So machten nach der Wahl des rechtsradikalen Trump zum US-Präsidenten bei Twitter Aufrufe die Runde, man solle seine Festplatten verschlüsseln und auf Signal umsteigen. [1] Auch auf dem aktivistischen Nachrichtenportal Linksunten-Indymedia findet sich ein Artikel, der die Nutzung der App nahelegt und vor den Konkurenten Threema und Telegram warnt. [2] Wir sehen hier einen Diskurs, sich sowohl politisch in die falsche Richtung entwickeln, als auch Menschen und Strukturen in erhöhte Repressionsgefahr bringen, weshalb wir zu dem Thema einen Debattenbeitrag veröffentlichen.

Wir wollen nicht die große Leistung schmälern, die die technischen Entwicklungen von OWS der kryptographisch gesicherten Kommunikation erbracht hat. Das Signal-Protokoll (ehemals Axolotl) hat Kryptographie im Gegensatz zu Konzepten wie Pretty Good Privacy (PGP) auf eine von Normalsterblichen nutzbare Ebene gehoben, ohne dabei in der Sicherheit Abstriche zu machen. [3] Im Gegenteil gewährleistet es Perfect Forward Secrecy, verschlüsselte Offline-Nachrichten und Dateiübertragung. Alles Features, die von Nutzer*innen erwartet werden und die durch Konzepte aus dem Bereich von Open Source Software (OSS) wie PGP oder Off The Record (OTR) nicht zusammen bereitgestellt werden. Darüber hinaus wurde es nicht, wie so oft im Open-Source-Bereich, bei der Entwicklung der Hintergrund-Bibliotheken belassen, sondern ein Graphical User Interface (GUI) geschaffen, das es in seiner einfachen User Experience (UX) mit kommerziellen Konkurrenten wie WhatsApp aufnehmen kann. Dies setzt andere Anbieter unter Druck, Verschlüsselungstechnologien zu implementieren und entsprechenden Code zu veröffentlichen.

Besucht man die Homepage von Signal, vermittelt sie vor allem eines: „Wir sind Profis, installiere unsere Software und deine Kommunikation ist sicher und einfach zu handhaben. Mehr willst und musst du nicht wissen.“ Nutzer*innen von IT-Technologien sollten auf derartige Aussagen zu Sicherheit mit äußerster Skepsis reagieren. Absolute Sicherheit gibt es ebenso wenig wie das Medikament gegen sämtliches Leiden und es führt kein Weg daran vorbei, sich die Frage zu stellen, wogegen man Schutz sucht. Will man sich gegen „kriminelle“ Hacker schützen, gegen kommerzielle Großunternehmen/Anbieter von Kommunikationsdiensten oder gegen staatliche Institutionen? Will man verhindern, dass Nachrichteninhalte mitgelesen werden, Metadaten analysiert werden, die Identität des Gegenübers gefälscht oder die Kommunikation blockiert werden kann? Dabei ist die Sicherheit nur so gut, wie das schwächste Glied im System. Etwa bringt mir die beste Verschlüsselungstechnologie meiner Nachrichten zwischen den Geräten nichts, wenn sich an meiner Tastatur ein Keylogger befindet oder ich alle Texteingaben an einen Onlinedienst weiterleite. Das Gerede von abstrakter Sicherheit führt nämlich jenseits von tatsächlich erhöhtem Schutz gegen Überwachung vor allem dazu, dass Menschen blind ihren technischen Gerätschaften Dinge anvertrauen, die sie ihnen besser nicht anvertrauen sollten.

Allerdings spricht dieses zweifelhafte Marketing von OWS nicht gegen eine Nutzung von Signal. Dafür ist die Frage zu stellen, welche tatsächlichen Probleme im Sicherheitsversprechen der App liegen.
Signal wickelt seine Kommunikation über einen Server unter der Kontrolle von OWS ab. Zwar können andere Organisationen einen Server dank dessen offenen Quellcodes betreiben, allerdings ergibt das keinen Sinn, da OWS eine Kommunikation zwischen den Servern (Federation) strikt ablehnt. Somit legen die Nutzer*innen auch hier ihre Kommunikation in die Hand eines einzelnen Unternehmens, welches jederzeit die Nutzungskonditionen ändern kann. Außerdem können alle Metadaten abgefangen werden, die aufgrund der Nutzung der Telefonnummern als Benutzeridentität äußerst aufschlussreich sind. Und darüber hinaus ist es für offizielle Stellen ein Leichtes, bei gegebenem Anlass die Kommunikation zu den OWS-Servern einfach zu unterbinden. Dieses Szenario ist nicht hypothetisch, sondern Regierungen wie die türkische haben derartige Methoden bei den großen Kommunikationsanbietern wie Twitter und Facebook unlängst unter Beweis gestellt. Und in Anbetracht der politischen Entwicklungen in Staaten des „demokratischen Westens“ beschränkt sich diese Problematik nicht mehr nur auf Gebiete wie die Türkei oder China.
Ein weiterer Punkt wurde oben bereits angerissen. Signal nutzt zwangsweise die Telefonnummern der Nutzer*innen als Identifikation in ihrem Service. Und diese Telefonnummern dürften nur in seltenen Fällen anonym sein. Dies gilt auch für anonym registrierte Simkarten, über die normal telefoniert wird. Über ihre Position im sozialen Netz sowie das Standortprofil sind sie einfach zu deanonymisieren. Fälle staatlicher Repression, z. B. über den §129 auch hierzulande, haben gezeigt, dass es oft genügt, zu wissen, wer mit wem im Kontakt steht. Zwar werden die Metadaten zwischen Server und Client verschlüsselt (SSL), aber sowohl OWS als auch den unzähligen Zertifizierungsstellen muss vertraut werden. Außerdem kann ein befreundeter Client unter Kontrolle eines Überwachungsdienstes gelangen und dessen Kontaktliste weißt zweifelsohne eine nicht abstreitbare Verbindung nach.
Ein dritter Punkt liegt im Bereich des Schutzes des Kommunikationsgerätes gegen sog. Quellen-TKÜ. Nicht nur ist vielen Nutzer*innen unbekannt, dass über den Google Play Store etwa unauthorisiert Apps (z. B. Staatliche Trojaner) nachinstalliert werden können [4]. Von anderen Sicherheitslücken von Android-Geräten soll gar nicht die Rede sein. Eine Problematik, die OWS nicht nur verschweigt, sondern auch aktiv verhindert, dass Nutzer*innen versuchen, ihre Geräte gegen Zugriff Dritter abzusichern. So benutzt Signal im Gegensatz zu allen anderen Messengern mit Fokus auf Sicherheit zwangsweise das sogenannte Google Cloud Messaging (GCM) und dieser proprietäre Service bedarf zwangsläufig der Google Play Services mit oben genannter Problematik. Die Community entwickelte darauf hin Code, der ohne die Google-Abhängigkeit auskommt, aber OWS verweigerte die Übernahme in Signal und verbot zusätzlich einer unabhängigen Version der App „LibreSignal“ die Mitnutzung ihres Servers [5] sowie die Führung von „Signal“ im Namen. [6] Signal verhindert also erhöhte Sicherheit aus Gründen, über die sich bloß mutmaßen lässt.
Als letztes wäre anzuführen, dass OWS Signal allein über den Google Play Store vertreibt und unabhängige Versionen zu verhindern sucht. Sei nun der Code quelloffen oder nicht – am Ende müssen wir mit einer Binärdatei leben, die durch die Hände von OWS und Google gegangen ist. Dies eröffnet das Thema potentiellen Missbrauchs durch Paketbetreuer, dass kaum zu lösen ist. Aber warum sollten die Nutzer*innen nicht entscheiden, wem sie in dieser Rolle vertrauen?

Die soeben nachgezeichnete Policy von OWS bezüglich ihres Vertriebes von Signal lässt Rückschlüsse auf ihre grundsätzlichen politischen Positionen zu, die sich von weiten Teilen der Open-Source-Community unterscheiden. Offenbar geht es OWS darum, eine Marke zu schaffen, die den Hype um Snowden und die NSA Enthüllungen nutzt, um sich als Held für Bürgerinteressen zu inszenieren. Die Forderung der Community nach einem dezentralen Internet unter der Kontrolle der Nutzer*innen oder von ihnen frei gewählten Expert*innen erscheint in diesem Kontext hinderlich. Kooperationspartner für OWS sind nicht in erster Linie Projekte aus der OS-Community sondern kommerzielle Player wie insbesondere Google, die motiviert werden sollen, Kryptographie in ihre Produkte zu integrieren – etwa dem neuen Messenger Allo. Um wirkliche umfassende Sicherheit geht es dabei natürlich nicht, sondern eine Privacy-Marktlücke wird bedient, ohne damit den Zugriff der kommerziellen Anbieter auf ihr Kapital, das Kommunikationsverhalten der Nutzer*innen, wirklich einzuschränken. So haben wir eine großartige Verschlüsselung auf dem Übertragungsweg, aber keinen Schutz der mobilen Endgeräte und keine Anonymisierung der Metadaten. Dazu kommt eine Zentralisierung der Kommunikation, die es Autoritäten ermöglicht, bei Bedarf den Stecker zu ziehen, sei es wörtlich, sei durch den Kooperationszwang der Provider nach dem Patriot Act.

Der Erfolg von OWS ist aber auch elitären und bürokratischen Positionen im Open-Source-Umfeld anzulasten. Der Standardisierungsprozess von XMPP verläuft zäh und es ist über viele Jahre nicht gelungen, einen nativen Kryptographie-Standard zu entwickeln. Entwicklungen wie OTR waren Notlösungen außerhalb des Protokolls, die in vielen Szenarien nicht sauber funktionieren. Deshalb weigerten sich Projekte wie Pidgin, sie als Standard zu implementieren. Allgemein scheint bei vielen OSS-Projekten das Interesse zu schwinden, wenn es darum geht, grafische Oberflächen mit intuitiver UX für die „Noobs“ zu entwickeln oder gar eine Benutzerdokumentation zu schreiben und zu pflegen. Oft kommt eine Misanthropie in dem Gegensatzpaar Entwickler*in vs. Nutzer*in zum Ausdruck. Der Mensch wird zum notwendigen, unkalkulierbaren Übel im Protokoll-Stack, zum Layer 8 [7] Problem.

Die Nutzung von Signal für eine komfortable, abgesicherte Kommunikation inklusive Gruppen und Bildversand ist dabei nicht alternativlos. Das Signal-Protokoll wurde für die Nutzung mit Jabber/XMPP portiert und eine normierte Integration in das XMPP-Protokoll (XEP) angefragt. Dieses Protokoll, das die Vorteile von Signal und Jabber zusammenbringt, heißt OMEMO. Obwohl die Übernahme in die XMPP-Standards wohl noch etwas Zeit in Anspruch nehmen wird, kann es bereits heute stabil genutzt werden. Etwa mit dem Messenger „Conversations“ auf Android-Smartphones [8] oder Gajim [9, 10] auf dem Desktop. Conversations zum Laufen zu bringen, sollte so einfach sein wie Signal. Gajim braucht noch etwas Gefrickel, aber es existieren einige Anleitungen für Linux und Windows. IOS-Benutzer*innen müssen sich aus Lizenzgründen noch etwas gedulden. Zusätzlich kann bei dieser Lösung der Account über Tor anonymisiert genutzt werden. Nutzer*innen sollten auch bedenken, dass diese Technologien ohne große Kooperationspartner*innen aus der Industrie entwickelt werden und ihre Erwartungen daran anpassen. Überzogene Kritik an der Stelle gleicht in etwa, ein selbstorganisiertes Nachbarschaftszentrum für den fehlenden Treppenaufzug zu kritisieren, der bei der Staatsoper lange Standard ist. Im Zweifel muss man im Umkreis fragen, ob einem nicht Leute helfen können. Diese Solidarität untereinander ist die Stärke derer, die heute Unten stehen und kann weder durch Technik noch elitäre Krypto-Helden ersetzt werden.