Ende-zu-Ende-Verschlüsselung, einfach erklärt

Ein Treuhandbüro in Chur verschickt einmal im Jahr dasselbe Formular: Angaben zu Einkommen, Liegenschaften, Kindern, Abzügen. Beim Formular-Werkzeug steht «verschlüsselt». Der Satz beruhigt — er sagt aber nicht, wer die Antworten am Ende im Klartext vor sich hat.

Das Wort steht heute auf fast jeder Produktseite, und je nach Stelle bedeutet es etwas anderes. Der Unterschied ist keine Feinheit für Fachleute. Er entscheidet darüber, wer den Inhalt lesen kann. Und er hat eine Kehrseite, die in Erklärungen selten vorkommt: Was gibt man auf, wenn ausser der empfangenden Person niemand lesen kann? Dieser zweite Teil ist der interessantere.

Drei Bedeutungen von «verschlüsselt»

Begriff	Was geschützt ist	Wer entschlüsseln kann
Auf dem Transportweg (in transit)	Der Weg zwischen Gerät und Server	Beide Endpunkte: der Browser und der Server des Anbieters
Im Speicher (at rest)	Die Datenträger, auf denen die Daten ruhen	Der Dienst, der den Schlüssel verwaltet
Ende zu Ende	Der Inhalt selbst, von der Eingabe bis zum Lesen	Nur, wer den Schlüssel hat

Auf dem Transportweg ist heute der Normalfall: Das Schloss in der Adresszeile steht für TLS. Die Spezifikation von TLS 1.3 beschreibt die Eigenschaft unmissverständlich — Daten, die nach dem Verbindungsaufbau über den Kanal gehen, sind nur für die Endpunkte sichtbar. Genau das ist der Punkt: Der Server ist einer dieser Endpunkte. Dort liegt der Inhalt wieder im Klartext vor, bevor irgendetwas mit ihm geschieht.

Im Speicher heisst, dass die Daten auf den Festplatten nicht als lesbarer Text liegen. Der Schlüssel dazu wird vom Dienst verwaltet, der die Daten ausliefert. Das schützt gegen einen entwendeten oder ausgemusterten Datenträger. Gegen die Software, die den Schlüssel ohnehin benutzt, schützt es nicht.

Ende zu Ende verschiebt einen einzigen Punkt: den Ort, an dem verschlüsselt wird. Nicht auf dem Server, sondern auf dem Gerät der Person, die etwas eingibt — und entschlüsselt wird erst wieder auf dem Gerät der Person, die es lesen darf. Dazwischen liegt der Inhalt nirgends im Klartext.

Wo verschlüsselt wird — und wer den Schlüssel hält

Browser können das heute von Haus aus. Die Web Cryptography API ist seit dem 26. Januar 2017 eine W3C-Empfehlung; sie beschreibt eine JavaScript-Schnittstelle für grundlegende kryptografische Operationen — Hashing, Signaturen, Ver- und Entschlüsseln — samt der Verwaltung des dafür nötigen Schlüsselmaterials. Für die Verschlüsselung selbst wird meist AES verwendet, festgelegt in der US-Norm FIPS 197 in den Varianten AES-128, AES-192 und AES-256, wobei die Zahl die Länge des Schlüssels angibt.

In einer üblichen Bauweise gibt es zwei zusammengehörige Schlüssel. Der eine ist öffentlich und steckt im Formular; mit ihm verschlüsselt der Browser der antwortenden Person ihre Eingaben. Der andere ist privat, bleibt bei der empfangenden Person und ist der einzige, mit dem sich das Ergebnis wieder lesbar machen lässt.

Damit verschiebt sich die Vertrauensfrage. Ob ein Anbieter mitliest, ist dann keine Zusage mehr, sondern eine Frage der Bauweise: Er hat den privaten Schlüssel nicht, weil er ihn nie bekommen hat. Das ist ein Unterschied — aber keine Garantie. Wer den Schlüssel hält, liest; wer ihn verliert, liest nicht mehr; und die Software, die im Browser verschlüsselt, kommt weiterhin vom Anbieter. Deshalb legen Anbieter, die so bauen, üblicherweise offen, wie sie es tun.

Eines leistet Ende-zu-Ende-Verschlüsselung ausdrücklich nicht: Sie schützt den Inhalt, nicht die Umstände. Dass ein Formular ausgefüllt wurde, wann, wie oft und wie gross ein Anhang war, fällt weiterhin an. Wer diese Angaben für unerheblich hält, sollte sie sich einmal aufschreiben — bei einem Meldeformular für Mitarbeitende etwa ist schon der Zeitpunkt eine Aussage.

Ein Anmeldeformular, Schritt für Schritt

Eine Musikschule in Thun nimmt Anmeldungen entgegen: Name des Kindes, Adresse, Instrument, Angaben zu einer allfälligen Ermässigung. So sieht der Weg aus, wenn Ende zu Ende verschlüsselt wird.

1. Die Schule erstellt das Formular. Dabei entsteht ein Schlüsselpaar. Der öffentliche Teil gehört zum Formular, der private Teil gehört der Schule.
2. Ein Vater ruft den Link auf. Sein Browser lädt das Formular samt öffentlichem Schlüssel.
3. Er füllt aus und sendet ab. Vor dem Absenden verschlüsselt sein Browser die Antworten. Was die Leitung verlässt, ist kein lesbarer Text mehr.
4. Der Server nimmt das Ergebnis entgegen und speichert es. Er kann ablegen, zählen, mit einem Datum versehen — den Inhalt sieht er nicht.
5. Die Sekretärin der Musikschule öffnet die Übersicht. Ihr Browser holt die gespeicherten Einträge und entschlüsselt sie lokal mit dem privaten Schlüssel.
6. Auf ihrem Bildschirm steht die Anmeldung. Sie war seit Schritt 3 nirgends sonst lesbar.

Für den Vater ändert sich an der Bedienung nichts. Für die Sekretärin ändert sich einiges — und das führt zum eigentlichen Thema.

Was Sie dafür aufgeben

Der verlorene Schlüssel bleibt verloren. In einem solchen System ist das Passwort nicht dasselbe wie der Schlüssel, und ein Zurücksetzen des Passworts stellt den Zugang zu den Daten nicht her. Proton beschreibt das für das eigene Konto offen: Nach einem Passwort-Zurücksetzen braucht es eine vorher eingerichtete Wiederherstellungsmöglichkeit — eine Wiederherstellungsphrase, eine Wiederherstellungsdatei, ein Gerätebackup oder das alte Passwort —, sonst riskiert man den dauerhaften Verlust des Zugriffs auf Konto und Daten. Der Anbieter kann das nicht abnehmen; genau darin besteht ja der Aufbau.

Der Server kann nicht durchsuchen, sortieren, vorschauen. Alles, was sonst serverseitig über den Inhalt läuft, fällt weg oder wandert in den Browser. Google beschreibt das für die eigene clientseitige Verschlüsselung in Workspace ausdrücklich: Der Inhalt solcher Dateien lässt sich nicht durchsuchen, nicht nach Dateityp filtern und in der Vorschau nicht anzeigen; Prüfungen zur Verhinderung von Datenabfluss haben keinen Zugriff auf den Inhalt; und clientseitig verschlüsselte Dateien und E-Mails werden nicht auf Phishing und Schadsoftware geprüft, weil die Server den Inhalt nicht sehen. Das ist keine Eigenheit eines Anbieters, sondern die logische Folge der Bauweise.

Die Benachrichtigungs-E-Mail enthält keinen Inhalt. «Neue Anmeldung eingegangen» — mehr kann darin nicht stehen, denn der Versand läuft über einen Server, der die Antwort nicht lesen kann. Wer gewohnt ist, den Inhalt direkt im Posteingang zu überfliegen, arbeitet anders.

Auswertungen entstehen im Browser. Eine Statistik über 4000 Antworten wird nicht auf dem Server gerechnet, sondern nach dem Entschlüsseln auf dem eigenen Gerät. Bei einer Handvoll Anmeldungen merkt man nichts. Bei sehr vielen Einträgen wird es spürbar.

Zugriff für mehrere Personen ist eine eigene Aufgabe. Wenn drei Personen im Sekretariat Antworten lesen sollen, müssen alle drei an den Schlüssel kommen. Das ist lösbar, aber es ist ein Schritt mehr als das Anlegen eines Kontos — und beim Austritt einer Mitarbeiterin ist es ebenfalls ein Schritt mehr.

Wann das der falsche Aufwand ist

Nicht jedes Formular gewinnt dadurch. Eine öffentliche Umfrage zum Mittagsangebot einer Kantine, anonym und ohne Personendaten, bezahlt den Preis, ohne etwas dafür zu bekommen. Ein Bestellformular, dessen Angaben automatisch in die Buchhaltung oder an einen Versanddienst fliessen sollen, braucht an irgendeiner Stelle eine Software, die den Inhalt lesen kann — dann ist die Kette ohnehin unterbrochen. Und wo Antworten im Notfall auch dann erreichbar sein müssen, wenn die eine Person mit dem Schlüssel gerade nicht verfügbar ist, ist die Schlüsselverwaltung die eigentliche Arbeit, nicht die Verschlüsselung.

Umgekehrt ändert sich die Rechnung, sobald in den Antworten Dinge stehen, die niemanden ausserhalb betreffen: Anamnesebögen, Bewerbungen, interne Meldungen, Steuerunterlagen.

Was das Schweizer Recht dazu sagt

Das Datenschutzgesetz schreibt keine Technik vor. Es verlangt, dass Verantwortliche und Auftragsbearbeiter durch geeignete technische und organisatorische Massnahmen eine dem Risiko angemessene Datensicherheit gewährleisten, und überlässt die Mindestanforderungen dem Bundesrat (Art. 8 DSG). Die Datenschutzverordnung nennt dann Ziele statt Werkzeuge: Die bearbeiteten Daten sollen ihrem Schutzbedarf entsprechend nur Berechtigten zugänglich sein (Vertraulichkeit), verfügbar sein, wenn sie benötigt werden (Verfügbarkeit), nicht unberechtigt verändert werden (Integrität) und nachvollziehbar bearbeitet werden (Nachvollziehbarkeit) (Art. 2 DSV). Bei der Wahl der Massnahmen sind unter anderem der Stand der Technik und die Implementierungskosten zu berücksichtigen (Art. 1 Abs. 4 DSV).

Das Wort «Verschlüsselung» kommt in diesen Bestimmungen nicht vor. Aufschlussreich ist vielmehr, dass Vertraulichkeit und Verfügbarkeit dort nebeneinanderstehen — und dass die Verordnung ausdrücklich auch verlangt, dass sich der Zugang zu den Daten nach einem Zwischenfall rasch wiederherstellen lässt (Art. 3 Abs. 2 Bst. d DSV). Genau zwischen diesen beiden Zielen liegt die Entscheidung, um die es in diesem Beitrag geht.

Worauf es hinausläuft

«Verschlüsselt» ist keine Eigenschaft, sondern eine Frage nach zwei Dingen: An welcher Stelle wird verschlüsselt, und wer hält den Schlüssel? Beides steht in der Dokumentation eines Anbieters oder es steht nirgends. Ende zu Ende ist die Antwort mit dem engsten Leserkreis — und mit den meisten Einschränkungen im Alltag. Beides gehört zusammen; wer nur das Erste erzählt, erzählt die Hälfte.

Wir entwickeln mit Formulare eine App, in der die Antworten im Browser der antwortenden Person verschlüsselt werden und der private Schlüssel bei der empfangenden Seite bleibt. Die App ist geplant und noch nicht verfügbar; wie die Verschlüsselung im Einzelnen aufgebaut ist und was sie im Betrieb bedeutet, werden wir vor dem Start offenlegen.