Wenn niemand dazwischen ist
Die Verschlüsselung dessen, was über einen Server läuft, schützt den Inhalt. Keinen Server dazwischen zu haben, erübrigt die Frage. Beides ist nicht dasselbe.
Zwei Personen, ein Gespräch
Wenn zwei Personen in einem Raum von Angesicht zu Angesicht sprechen, muss niemand sonst versprechen, dass er nichts gehört hat. Er hat nichts gehört, weil er nicht da war. Wenn sich zwei Personen einen Zettel von einer Hand in die andere geben, muss niemand in der Mitte schwören, dass er ihn nicht gelesen hat. Es ist niemand in der Mitte.
Die meisten Dinge im Alltag funktionieren so. Wir unterzeichnen keine Vertraulichkeitsvereinbarungen mit der Luft, die unsere Stimme überträgt, oder mit dem Papier, das wir halten. Die Privatsphäre des Gesprächs beruht nicht auf dem Versprechen eines Vermittlers, denn es gibt keinen Vermittler. Das ist eine der stärksten Formen von Privatsphäre: nicht weil sich etwas oder jemand gut verhält, sondern weil es dieses Etwas oder diesen Jemand gar nicht gibt.
Wenn das Gespräch in einen digitalen Kanal verlagert wird, ändert sich dies standardmäßig. Das übliche Modell ist folgendes: Zwei Personen verbinden sich mit einem Server, der Server empfängt die Nachricht, verschlüsselt sie oder speichert sie verschlüsselt und stellt sie dem Empfänger zu. Das Server ist dazwischen. Der Server kann ehrlich sein. Er kann auditiert sein. Er kann in einer günstigen Gerichtsbarkeit und unter einer strengen Datenschutzrichtlinie betrieben werden. All das kann wahr sein. Aber der Server ist dazwischen.
Der Unterschied zwischen Verschlüsseln und Nicht-Erheben (zweiter Teil)
In einem früheren Artikel derselben Serie haben wir dargelegt, dass die Verschlüsselung von Inhalten und das Nicht-Erheben von Metadaten nicht dasselbe sind. Es gibt einen weiteren Schritt, den man klar formulieren sollte: Verschlüsseln, was über einen Server läuft, und gar keinen Server zu haben, sind ebenfalls nicht dasselbe.
Das erste Modell – Server in der Mitte, verschlüsselter Inhalt – schützt den Inhalt vor dem Betreiber des Servers, vor seinem Wartungspersonal, vor einem externen Angreifer, der das System kompromittiert. Und das ist wichtig. Aber es eliminiert den Server nicht: Er ist immer noch da, verarbeitet Metadaten, ist einer gerichtlichen Anforderung, einem rechtlichen Eingriff, politischem Druck oder einer Sicherheitslücke ausgesetzt. Es bleibt letztendlich ein Punkt, an dem man jemandem Vertrauen entgegenbringen muss.
Das zweite Modell, ohne Server zwischen den beiden Enden, schützt den verschlüsselten Inhalt nicht besser: Wenn die Kryptographie solide ist, ist der Inhalt in beiden Fällen geschützt. Was sich ändert, ist die Frage selbst: „Was ist mit dem Server?“ wird gegenstandslos, weil es keinen Server gibt, nach dem man fragen könnte.
Vertrauen, Abwesenheit und der Unterschied zwischen beiden
Vertrauen kann gut investiert sein. Ehrliche Unternehmen existieren. Strenge Auditoren existieren. Nutzerfreundliche Gesetze existieren. Seriöse Dienste, die all das Genannte gewissenhaft erfüllen, existieren. Vertrauen ist, wenn es einem Betreiber geschenkt wird, der es verdient, keine schlechte Lösung.
Aber Vertrauen, so solide es auch sein mag, bleibt Vertrauen. Es ist eine soziale Lösung, keine technische. Ein Unternehmen kann den Besitzer wechseln, eine Gerichtsbarkeit kann die Regierung wechseln, ein Gerichtsbeschluss kann morgen eintreffen, eine neue Schwachstelle kann nächsten Monat entdeckt werden. Nichts davon geschieht aus böser Absicht: Es geschieht, weil der Betreiber existiert, und alles, was existiert, den Kontingenzen der Welt unterliegt.
Die Abwesenheit eines Betreibers ist diesen Unwägbarkeiten nicht unterworfen. Ein Gerichtsbeschluss kann keine Daten von einem Server verlangen, den es nicht gibt. Ein Angreifer kann keinen Server kompromittieren, den es nicht gibt. Eine Änderung der Unternehmensrichtlinien kann keine Daten betreffen, die das Unternehmen nie hatte. Der Schlüsselsatz ist einfach: Daten, die nicht existieren, können nicht verloren gehen.
Über das legitime Argument der Serverseite
Wer einen professionellen Messaging-Dienst mit Server dazwischen anbietet, führt meist drei vollkommen gültige Argumente an. Erstens, dass der Server notwendig ist, um die Zustellung zu garantieren, wenn der Empfänger offline ist. Zweitens, dass die Inhaltsverschlüsselung robust ist und der Betreiber sie daher nicht lesen kann. Drittens, dass der Dienst die europäische Gesetzgebung erfüllt und die Daten gesetzlich geschützt sind.
Alle drei Argumente sind wahr. Keines ändert das Wesen der Sache. Es stimmt, dass ein Server das Speichern von Nachrichten zur zeitversetzten Zustellung ermöglicht; es stimmt aber auch, dass zeitversetzte Zustellung anders gelöst werden kann, nämlich über Protokolle zur direkten Kommunikation zwischen Geräten, die seit Jahrzehnten verfeinert wurden und heute einsatzbereit sind. Es stimmt, dass die Verschlüsselung von Inhalten bei der Übertragung bei seriösen Diensten robust ist. Und es stimmt, dass die europäische Gesetzgebung Nutzer besser schützt als in vielen anderen Regionen.
Die Frage ist nicht, ob Dienste mit Server dazwischen legal sind, oder ob sie sicher sind, oder ob sie den Inhalt schützen. Sie können es sein, sie sind legal und meist sicher. Die Frage ist, dass ein Server dazwischen eine architektonische Entscheidung ist, keine technische Notwendigkeit. Und jede Entscheidung hat Konsequenzen. Eine Architektur mit Server dazwischen erzeugt zwangsläufig einen Akteur, dem man vertrauen muss. Eine Architektur ohne Server dazwischen nicht.
Was das Gesetz sagt und what die Architektur tut
Die DSGVO schreibt kein bestimmtes Architekturmodell vor. Sie verlangt Ergebnisse: Datenminimierung, Zweckbindung, Schutz durch Technikgestaltung und durch datenschutzfreundliche voreinstellungen, Nachweisbarkeit der Einhaltung. Ein Dienst mit Server dazwischen kann all diese Anforderungen erfüllen. Ein Dienst ohne Server dazwischen erfüllt mehrere davon bereits durch seine Konstruktion, nicht erst durch eine Erklärung. Absolute Minimierung — nichts zu erheben, was nicht zwingend für die Zustellung der Nachricht erforderlich ist — ist trivial, wenn kein Server existiert, der etwas erheben könnte.
Für alltägliche, nicht sensible Nutzungen ist eine Server-Architektur vollkommen vernünftig, und das Vertrauen in einen seriösen Betreiber eine gültige Lösung. Für andere Nutzungen — solche, die einem geregelten Berufsgeheimnis unterliegen, die deontologische Verantwortung mit sich bringen, die besonders sensible Informationen betreffen — ist das Fehlen eines Vertrauenspunktes kein Luxus, sondern ein struktureller Vorteil.
Der unnötige Zeuge
Die Rückkehr in den Raum vom Anfang hilft, den Gedanken zu festigen. Dass niemand das Gespräch mitgehört hat, hängt nicht davon ab, dass sich der Zeuge gut benommen hat: Es hängt davon ab, dass kein Zeuge da war. Ein dazwischengeschalteter Server kann ehrlich und geprüft sein, jeden Artikel der DSGVO erfüllen und dennoch genau das bleiben: ein Zeuge. Für jemanden, der mit dem Berufsgeheimnis umgeht, ist die wirklich entscheidende Frage nicht, ob dieser Zeuge Vertrauen verdient: sondern ob es nötig war, dass er im Raum ist.
Die Antwort lautet bei den meisten professionellen Messaging-Diensten, die es heute gibt, dass es nicht nötig war — und er trotzdem da war.
Dieser Artikel schließt den ersten Zyklus der Cuadernos Lacre ab. Nach Verschlüsselung, Metadaten und Berufsgeheimnis vervollständigen wir das architektonische Bild: Den Inhalt zu verschlüsseln und keinen Server dazwischen zu haben, sind zwei verschiedene Dinge. Beides kann legal sein; nur eines eliminiert den Vertrauenspunkt.
Quellen und weiterführende Literatur
- Saltzer, J. H.; Reed, D. P.; Clark, D. D. — End-to-end arguments in system design, ACM TOCS, 1984. Grundlagentext des Prinzips, nach dem die Garantien eines Systems an den Endpunkten implementiert werden sollten, nicht im dazwischenliegenden Kanal.
- Verordnung (EU) 2016/679, Art. 25 — Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen.
- Verordnung (EU) 2016/679, Art. 5.1.c — Grundsatz der Datenminimierung.
- Schneier, B. — Data and Goliath: the hidden battles to collect your data and control your world (2015), W. W. Norton. Kapitel über Architekturen, die die Datenerhebung durch ihre Konstruktion minimieren.