Zentral verwaltet oder dezentral verteilt?

In der Informationssicherheit gibt es drei Schutzziele:
Die Vertraulichkeit (englisch: confidentiality), Integrität (englisch: integrity) und Verfügbarkeit (englisch: availability) von Systemen. Ein System ist dann vertraulich, wenn man sich darauf verlassen kann, dass meine Information genau bei dem Ziel ankommt, für das sie bestimmt war. In der Praxis sorgen Authentifizierung und Verschlüsselung gemeinsam für Vertraulichkeit. Integrität wird durch digitale Signaturen sichergestellt, die versichern können, dass ein Absender auch genau der ist, der er vorgibt zu sein. Die Verfügbarkeit eines Systems hingegen ist abstrakter und hängt mit dem Design des gesamten Systems zusammen.

Sequoia PGP basiert auf der OpenPGP-Norm, die beispielsweise ein dezentrales Design aufweist. Das bedeutet, dass mehrere Anwendungen auf dem Standard OpenPGP aufbauen können und Nutzer*innen nicht denselben Anbieter nutzen müssen, um Nachrichten oder Dateien auszutauschen. Das macht das System als ganzes ausfallsicher und steigert damit die Verfügbarkeit, da das System erst dann gänzlich ausfällt, wenn alle Anbieter gleichzeitig ausfallen. Da OpenPGP eine Norm ist, kann es auch verschiedene Implementierungen davon geben. Und davon gibt es einige. Eine Sicherheitslücke oder ein Ausfall, der alle Implementierungen gleichzeitig betrifft, wird unwahrscheinlicher, je mehr es gibt.

Diese Eigenschaften - ein dezentrales Design und Interoperabilität - können also zu einem robusteren System führen und somit eine höhere Verfügbarkeit gewährleisten als ein geschlossenes, zentrales System. Dieser Vorteil kommt jedoch nicht ohne einen oft erwähnten Nachteil: Es wird mehr Zeit benötigt, um das Protokoll zu aktualisieren und alte Funktionalität abzuschalten. Wir sind jedoch der Überzeugung, dass dieser Nachteil gar nicht so schlimm ist, wie es auf den ersten Blick scheint.

In den letzten Wochen wurde vielen Internetnutzer*innen dreimal vor Augen geführt, was es bedeutet, wenn die Verfügbarkeit eingeschränkt ist. Ein Fehler in einem von Amazons Datenzentren führte dazu, dass Dienste, die Amazons Cloud nutzten, nicht erreichbar waren. Da etwa 30 % der Cloud-Anwendungen Amazons Datenzentren nutzen, sind das viele. Als Nächstes hatte Microsofts Cloud Azure Probleme, mit ähnlichen Folgen. Zuletzt war Cloudflare nicht erreichbar. Cloudflare ist ein Dienst, den fast jede zweite Webseite nutzt, um ihre Verfügbarkeit zu sichern. Die Probleme reichten von nicht erreichbaren Banken und überhitzten Betten bis hin zu nicht spielbaren Spielen und Chat-Apps wie dem Ende-zu-Ende-verschlüsselten Messenger Signal, die keine Nachrichten ausliefern konnten.

Das Problem war nicht nur, dass Amazon, Microsoft und Cloudflare Probleme hatten. Die Anwendungen sind alle zentralisiert, d. h., ohne ihren Dienstanbieter funktionieren sie nicht. Soweit ich weiß, ist dieses Mal nichts Schlimmes passiert. Aber man kann sich vorstellen, dass es nur eine Frage der Zeit ist, bis ein*e Angreifer*in diese Schwachstelle ausnutzt, um noch größere Probleme zu verursachen.

Das zweite Problem ist die Interoperabilität. Betrachten wir den bereits erwähnten Instant Messenger Signal als Beispiel, da er ähnliche Ziele verfolgt wie Sequoia. Zwar ist Signal freie Software, deren Quellcode jede*r mit entsprechenden Fähigkeiten ändern kann, doch das Signal-Netzwerk selbst ist geschlossen. Das heißt, dass man als Signal-Nutzer*in nur mit anderen Nutzer*innen kommunizieren kann, die dasselbe Signal-Netzwerk nutzen. Ein Vorteil dieser Architektur ist, dass der Betreiber den Dienst ohne großen Abstimmungsaufwand weiterentwickeln kann. Ein Nachteil ist jedoch, dass der Betreiber eine Schwachstelle darstellt: Wenn dieser kompromittiert ist oder ausfällt, ist das gesamte Netzwerk betroffen.

Die Regierung des Landes, in dem Signal seinen Sitz hat - die US-Regierung - kann versuchen, Signal zu zwingen, das Netzwerk zu schwächen, indem sie beispielsweise eine Hintertür einbauen lässt. Das ist keine Fantasie: Die US-Regierung hat so etwas bereits gemacht. Im Jahr 2013 versuchte sie, bei Lavabit eine Hintertür einzubauen, um an die E-Mails von Edward Snowden zu gelangen. Und vor ein paar Monaten hat Microsoft auf Anordnung der US-Regierung das Microsoft-Konto des Chefanklägers des Internationalen Strafgerichtshofs blockiert. Dieser hatte Haftbefehle gegen den israelischen Premierminister Benjamin Netanjahu und andere erlassen. Dadurch konnte der Chefankläger nicht mehr auf seine E-Mails zugreifen und seine Arbeit wurde behindert.

Auch bei einem dezentralen Netzwerk kann ein Betreiber eine Hintertür einbauen oder ein Konto sperren. In solchen Fällen haben die Nutzer*innen allerdings die Möglichkeit, zu einem anderen Anbieter zu wechseln, ohne dabei die meisten ihrer Kontakte zu verlieren.

Die OpenPGP-Norm ist sogar netzwerkunabhängig: Das heißt, dass man eine OpenPGP-Nachricht über WhatsApp, Facebook oder sogar per Amateurfunk verschlüsselt verschicken kann. Die meisten machen das aber nicht, da OpenPGP nicht oder nur schlecht integriert ist und sich daher umständlich verwenden lässt. Endnutzer*innen nutzen OpenPGP hauptsächlich über einige E-Mail-Clients, vor allem im Free- und Open-Source-Bereich, die OpenPGP unterstützen. Es gibt aber auch Plug-ins für viele Jabber-Clients. Leider sind diese immer noch nicht so reibungslos zu nutzen wie Signal.

Sowohl E-Mail als auch Jabber sind dezentrale Dienste. Das heißt, wenn ein Anbieter nicht verfügbar ist, können die anderen Anbieter weiterhin genutzt werden. Wenn ein Anbieter über einen längeren Zeitraum nicht verfügbar ist, können die Nutzer*innen ohne Verlust ihrer Kontakte zu einem anderen Anbieter wechseln. Dabei können sich die Anbieter auch in unterschiedlichen Hoheitsbereichen befinden. Das kann digitale Souveränität schaffen. Dienste wie Signal sind dagegen nicht so robust gestaltet.

Die Nachteile eines dezentralen Designs ergeben sich direkt aus dessen Struktur: Weil es keine zentrale Stelle gibt, kann auch keine zentrale Stelle Entscheidungen treffen. Stattdessen müssen alle Interessensträger*innen einen Konsens finden. Das führt dazu, dass Änderungen oft viel Zeit in Anspruch nehmen. Dies sind jedoch die Kosten einer Demokratie im Vergleich zu einer Diktatur.

Seit acht Jahren arbeiten wir an Sequoia PGP. In dieser Zeit haben wir vor allem im Bereich der Infrastruktur einiges erreicht. Der Beweis dafür ist die Vielzahl an Projekten, die sich für Sequoia entschieden haben. So nutzen die Software-Paketverwaltungssysteme RPM und APT Sequoia, um die Integrität von Software-Updates zu überprüfen, die Whistleblower-Plattform SecureDrop nutzt Sequoia, um Nachrichten von Quellen zu verschlüsseln, und die Schweizer Regierung nutzt Sequoia, um Patient*innendaten zu schützen. In den kommenden Jahren hoffen wir, mehr Endnutzer*inen-Anwendungen zu erreichen. Denn am Ende bringt das sicherste System, dass niemand benutzt, auch niemandem etwas.

Eine Hürde dabei: Kryptographie richtig zu implementieren, ist aufwendig. Fehler in kryptographischen Implementierungen sind schwer zu entdecken und oft fatal. Sequoia PGP kümmert sich um diesen wichtigen Unterbau und ermöglicht es Entwickler*innen somit, ihre Kernkomponenten für ihre Nutzer*innen weiterzuentwickeln, ohne sich ständig den Kopf über Kryptographie zerbrechen zu müssen. Aktuell ist unser Ziel, eine es, eine leicht zu nutzende API für Sequoia zu entwickeln, die keine besonderen Kryptographischen und nur wenige OpenPGP-Kenntnisse voraussetzt. Wir sind guter Dinge, dass eine einfach aber sicher verwendbare API dazu führt, dass mehr Entwickler*innen OpenPGP in ihre Applikationen integrieren und Endanwender*innen von einem verbesserten Schutz ihrer Daten profitieren.