Ende-zu-Ende-Verschlüsselung (E2EE)

Was ist Ende-zu-Ende-Verschlüsselung (E2EE)?

Bei der Ende-zu-Ende-Verschlüsselung (E2EE) werden Daten auf dem Gerät des Senders verschlüsselt und nur auf dem Gerät des Empfängers entschlüsselt. Der Dienst dazwischen, etwa ein Messaging-Server, verarbeitet nur Geheimtext, weil er die Schlüssel nie besitzt. Die Electronic Frontier Foundation beschreibt es so: Eine Nachricht wird vom ursprünglichen Absender in eine geheime Nachricht verwandelt und nur vom letzten Empfänger entschlüsselt.

Wie E2EE funktioniert

• Jedes Gerät erzeugt ein Schlüsselpaar. Der öffentliche Schlüssel wird über den Dienst geteilt, der private verlässt das Gerät nie.
• Der Sender verschlüsselt mit Schlüsseln, die aus dem öffentlichen Schlüsselmaterial des Empfängers abgeleitet sind, und schickt den Geheimtext über den Server.
• Der Server speichert und leitet den Geheimtext weiter, ohne ihn lesen zu können.
• Das Gerät des Empfängers entschlüsselt ihn mit dem privaten Schlüssel.

Moderne Messenger setzen ein Schlüsselaktualisierungsverfahren darauf. Der Double-Ratchet-Algorithmus von Signal gibt jeder Nachricht einen eigenen Schlüssel, sodass ein später verlorener Schlüssel frühere Nachrichten nicht offenlegt (Forward Secrecy), und neue Diffie-Hellman-Austausche lassen eine Unterhaltung nach einer kurzen Kompromittierung wieder sicher werden. Der Double Ratchet braucht ein separates Protokoll wie PQXDH, um das erste gemeinsame Geheimnis zu vereinbaren. Für Gruppen hat die IETF Messaging Layer Security in RFC 9420 standardisiert, das Gruppen von zwei bis zu tausenden Mitgliedern unterstützt und Forward Secrecy sowie Post-Compromise Security bietet.

E2EE im Vergleich zu Verschlüsselung bei der Übertragung und im Ruhezustand

TLS, das Protokoll hinter HTTPS, schützt Daten zwischen Client und Server, sodass nur diese beiden Endpunkte sie lesen können (RFC 8446). Das ist Verschlüsselung bei der Übertragung. Der Server sieht dabei aber den Klartext. Verschlüsselung im Ruhezustand schützt gespeicherte Daten, doch die Schlüssel hat meist der Dienst. Bei E2EE hat der Dienst die Schlüssel nie, sodass selbst seine Mitarbeiter oder ein Angreifer, der in seine Server eindringt, Nachrichteninhalte nicht lesen können. Kann ein Server einen großen Teil der Nachrichten entschlüsseln, ist das System nicht Ende-zu-Ende-verschlüsselt. Die meisten E2EE-Produkte nutzen zusätzlich TLS, weil beide gegen unterschiedliche Bedrohungen helfen.

Beispiel

Sie senden ein Foto in einem Messenger. Ihr Handy verschlüsselt es, die App lädt die verschlüsselte Datei hoch, und der Server stellt sie Ihrer Freundin zu. Ihr Handy entschlüsselt und zeigt das Bild. Der Server sah einen Klumpen Bytes, dessen Größe und den Zeitpunkt der Ankunft.

Wovor E2EE nicht schützt

• Ein kompromittiertes Gerät. Schadsoftware auf dem Handy von Sender oder Empfänger sieht die Nachricht nach der Entschlüsselung.
• Metadaten. Wer wann mit wem schreibt, bleibt für den Dienst oft sichtbar, so wie ein Umschlag Absender, Empfänger und Ziel zeigt, auch wenn der Brief versiegelt ist (ein Vergleich aus dem EFF-Leitfaden zu Metadaten).
• Backups. Wird ein Chat unverschlüsselt oder mit einem Schlüssel des Anbieters gesichert, endet der Schutz dort.
• Menschen. Ein Empfänger kann kopieren oder abfotografieren, was Sie senden, und ein Nutzer kann dazu gebracht werden, einem falschen Schlüssel zu vertrauen.

E2EE ersetzt auch nicht die übrige Sicherheitsarbeit. Konten, Sitzungen und Gerätevertrauen brauchen weiterhin Identity and Access Management, die APIs, die den Geheimtext transportieren, brauchen API-Sicherheit, und gespeicherte Metadaten brauchen Datenbanksicherheit. Lesen Sie auch die gängigen Cyber-Bedrohungen, gegen die E2EE nichts ausrichtet.

Häufige Fehler

• HTTPS als Ende-zu-Ende-Verschlüsselung bezeichnen. HTTPS endet am Server.
• Den Server Schlüssel sehen lassen. Ein Key-Escrow oder eine serverseitige „Wiederherstellungs“-Kopie kann E2EE unbemerkt zu gewöhnlicher Verschlüsselung machen.
• Die Schlüsselprüfung weglassen. Ohne Möglichkeit, Sicherheitsnummern oder Fingerabdrücke zu vergleichen, könnte ein Server einen Schlüssel austauschen und sich dazwischenschalten.
• Eigene Kryptografie schreiben. Nutzen Sie ein geprüftes Protokoll und eine geprüfte Bibliothek.

E2EE, Lasttests und Monitoring

LoadFocus bietet keine Verschlüsselungsprodukte an, und ein Lasttest kann E2EE-Inhalte nicht lesen, genau das ist der Sinn. Testen kann er aber das Backend, das sie transportiert. Der Server muss weiterhin Uploads von Geheimtext annehmen, öffentliche Schlüssel ausliefern, Nachrichten speichern und sie schnell an viele Geräte gleichzeitig zustellen. Nutzen Sie Lasttests mit synthetischen Testkonten und undurchsichtigen Payloads realistischer Größe, um zu sehen, wie sich diese Endpunkte bei wachsender Zahl virtueller Nutzer verhalten, und API-Monitoring, um sie nach Zeitplan zu prüfen. Verwenden Sie niemals echte Nutzerdaten. Mehr dazu im (englischen) Beitrag Cloud testing security best practices.

Häufige Fragen zu Ende-zu-Ende-Verschlüsselung

Ist Ende-zu-Ende-Verschlüsselung dasselbe wie HTTPS?

Nein. HTTPS (TLS) schützt die Verbindung zwischen Ihrem Gerät und einem Server, aber der Server kann die Daten lesen. Ende-zu-Ende-Verschlüsselung hält die Daten auch für den Server unlesbar.

Kann das Unternehmen hinter dem Dienst meine E2EE-Nachrichten lesen?

Den Inhalt nicht, sofern das System wirklich Ende-zu-Ende-verschlüsselt ist, denn das Unternehmen besitzt die Schlüssel nicht. Metadaten wie wer wen wann kontaktiert hat, kann es trotzdem sehen.

Was ist Forward Secrecy?

Ein später geleakter Schlüssel kann vergangene Nachrichten nicht entschlüsseln. Der Double Ratchet von Signal gibt dafür jeder Nachricht einen eigenen Schlüssel.

Funktioniert E2EE auch in Gruppenchats?

Ja. Messaging Layer Security (RFC 9420) ist ein IETF-Standard für Gruppenschlüsselvereinbarung und unterstützt Gruppen von zwei bis zu tausenden Mitgliedern.

Macht Ende-zu-Ende-Verschlüsselung eine App immun gegen Angriffe?

Nein. Sie schützt Nachrichteninhalte bei der Übertragung und auf dem Server, aber nicht vor einem kompromittierten Gerät, unverschlüsselten Backups oder schwacher Kontosicherheit.