End-to-End-Verschlüsselung ohne Kompromisse

Hinweis: Dieser Artikel beschreibt die Architektur und das Design von Mandraki. Einige besprochene Funktionen werden schrittweise ausgerollt und sind möglicherweise noch nicht in allen Plänen verfügbar.

End-to-End-Verschlüsselung ist eines jener Merkmale, das leicht zu versprechen und schwierig, korrekt zu liefern ist. Viele Kollaborationsplattformen behaupten, E2EE anzubieten, aber die Details ihrer Implementierungen variieren enorm — und die Details sind, wo Sicherheit lebt oder stirbt.

Dieser Beitrag erklärt, wie Mandraki End-to-End-Verschlüsselung implementiert, die Protokoll-Wahlen, die wir trafen, und die Kompromisse, die wir transparent sind.

Was End-to-End-Verschlüsselung tatsächlich bedeutet

In einem System mit End-to-End-Verschlüsselung werden Nachrichten und Medien auf dem Sender-Gerät verschlüsselt und können nur auf den Empfänger-Geräten entschlüsselt werden. Der Server, der die Daten weiterleitet, sieht nur Chiffre. Es kann den Inhalt nicht lesen, auch wenn es gezwungen wird, dies durch einen Gerichtsbeschluss, einen rogue Angestellten oder eine Sicherheitsverletzung zu tun.

Dies ist grundlegend anders als Transport-Verschlüsselung (TLS), die Daten in Transit zwischen einem Client und einem Server schützt, aber den Server mit Zugriff auf Klartext lässt. Es ist auch anders als At-Rest-Verschlüsselung, die Daten auf der Festplatte schützt, aber die Anwendungs-Schicht mit Zugriff auf Klartext während der Verarbeitung lässt.

Wirkliche E2EE bedeutet, der Server ist von Design nicht vertraut. Es ist ein Relay, kein Leser.

Das MLS-Protokoll für Messaging

Für verschlüsseltes Messaging nutzen wir das Messaging-Layer-Security-Protokoll (MLS), standardisiert als RFC 9420 durch die IETF. MLS wurde speziell für Gruppen-Messaging-Szenarien entworfen und bietet mehrere Vorteile über ältere Ansätze.

MLS nutzt eine baum-basierte Schlüssel-Vereinbarungs-Struktur namens TreeKEM, die einer Gruppe von Teilnehmern erlaubt, ein gemeinsames Geheimnis effizient zu etablieren. Wenn ein Mitglied eine Gruppe beitritt oder verlässt, wird das Schlüsselmaterial durch eine Commit-Nachricht aktualisiert, die die Gruppe-Epoche vorbringt. Dies bietet Forward Secrecy — ein Mitglied-Schlüssel zu einem bestimmten Zeitpunkt zu kompromittieren, offenbart nicht Nachrichten von früheren Epochen — und Post-Compromise Security — die Gruppe erholt sich nach einem Kompromiss als bald das betroffene Mitglied-Schlüsselmaterial rotiert wird.

Jedes Benutzer-Gerät lädt MLS-Schlüssel-Pakete zum Server hoch. Das sind einmalige Verwendungs-Kryptografie-Bundles, die anderen Geräten erlauben, sie zu einer Gruppe hinzuzufügen, ohne dass das Gerät zum Moment online sein muss. Wenn ein Schlüssel-Paket verbraucht wird, muss das Gerät frische hochladen. Der Server speichert und verteilt diese Pakete, hat aber nie Zugriff auf das Private-Schlüssel-Material, das sie enthalten.

MLS-Gruppen in Mandraki bilden auf Kanäle und Direktnachrichten-Threads ab. Wenn Sie eine Nachricht in einem verschlüsselten Kanal senden, verschlüsselt Ihr Client sie mit dem aktuellen Epoche-Schlüssel der Gruppe. Der Server empfängt Chiffre, speichert es und verteilt es zu Gruppen-Mitgliedern. Ihre Clients entschlüsseln es lokal.

SFrame für Media-Verschlüsselung

Echtzeit-Medien zu verschlüsseln — Audio und Video in einem Gruppen-Anruf — präsentiert unterschiedliche Herausforderungen von Messaging. Latenz-Toleranz ist in Millisekunden gemessen, nicht Sekunden. Die Daten-Raten sind um Größen höher. Und die Medien durchlaufen einen Selective Forwarding Unit (SFU), der Pakete zu den richtigen Teilnehmern routen muss, ohne den Inhalt sehen zu können.

Wir nutzen SFrame (RFC 9605) für Media-Verschlüsselung, angewendet via die WebRTC-Encoded-Transform-API. Diese API erlaubt JavaScript-Code, codierte Media-Frames nach Codierung aber vor Packetisierung zu unterbrechen, sie zu verschlüsseln und die Chiffre zur Transport-Schicht zu übergeben. Am Empfänger-Ende werden die Frames nach Wiederversammlung aber vor Decodierung entschlüsselt.

Der Schlüssel-Vorteil von SFrame in einer SFU-Architektur ist, dass der SFU immer noch seine Routing-Funktion durchführen kann — Pakete von einem Teilnehmer zu anderen weiterleiten, Bandbreiten-adaptive Entscheidungen über welche Schichten zu leiten — ohne je Zugriff auf die Klartext-Medien zu haben. Der SFU sieht verschlüsselte Frames und leitet sie als opaque Blobs weiter.

Die Kompromisse, die wir ehrlich sind

End-to-End-Verschlüsselung ist nicht frei. Sie führt echte Constraints ein, die wir glauben, würdig zu erkennen.

Server-seitige Suche ist auf E2EE-Inhalt nicht möglich. Wenn Nachrichten mit Schlüsseln verschlüsselt sind, die der Server nicht hält, kann der Server sie für Suche nicht indexieren. Mandraki adressiert dies durch die Aufrechterhaltung eines lokalen verschlüsselten Such-Index auf dem Client mit IndexedDB. Dies bietet Pro-Gerät-Suche, aber unterstützt keine Cross-Device-Such-Historie für Nachrichten, die vor einem Gerät empfangen wurden, das zu der Gruppe hinzugefügt wurde.

Server-seitige KI-Funktionen sind gegenseitig ausschließend mit E2EE. Unsere KI-Transkriptions- und Zusammenfassungs-Funktionen erfordern Server-seitigen Zugriff auf Klartext-Audio. Ein Anruf oder Kanal kann nicht beide E2EE und KI-Funktionen aktiviert gleichzeitig haben. Das ist architektonisch durchgesetzt, nicht nur durch Policy. Organisationen wählen auf Anruf- oder Kanal-Ebene, welches Modell sie bevorzugen.

Neue Geräte sehen Nachrichten nur von Beitritt-Punkt vorwärts. Wenn Sie ein neues Gerät zu Ihrem Konto hinzufügen, kann es Nachrichten von dem Moment entschlüsseln, an dem es der MLS-Gruppe beitritt. Historische Nachrichten, die unter vorherigen Epochen verschlüsselt wurden, sind auf dem neuen Gerät nicht erreichbar. Das ist eine grundlegende Eigenschaft von Forward Secrecy. Wir erforschen sichere Sicherungs-Mechanismen, die Benutzern erlauben würden, verschlüsselte Nachrichten-Historie zu einem neuen Gerät zu exportieren, aber das bleibt eine Arbeit in Fortschritt.

Schlüssel-Verwaltung fügt Komplexität hinzu. Jedes Gerät muss Schlüssel-Material erhalten, frische Schlüssel-Pakete hochladen und Gruppen-Status-Aktualisierungen verarbeiten. Wir investieren signifikante Engineering-Bemühung, dies für Benutzer unsichtbar zu machen. Das Ziel ist, dass Verschlüsselung nicht etwas ist, das Sie konfigurieren oder über nachdenken — es passiert einfach.

E2EE und serverseitige Verschlüsselung koexistieren

Es ist erwähnenswert, dass Mandraki’s E2EE-Schicht und unsere serverseitige Umschlag-Verschlüsselung (die dreischichtige Schlüssel-Hierarchie, die in unserer Sicherheitsarchitektur beschrieben wird) komplementäre Zwecke erfüllen. Serverseitige Verschlüsselung schützt Daten im Ruhezustand auf unserer Infrastruktur — wenn eine Festplatte gestohlen wird oder ein Datenbank-Backup kompromittiert wird, sind die Daten ohne die Verschlüsselungs-Schlüssel unlesbar. E2EE geht weiter, indem es sicherstellt, dass der Server nie Klartext in der ersten Stelle sieht.

Für Organisationen, die E2EE aktivieren, sind beide Schichten gleichzeitig aktiv. Daten werden von den Clients End-zu-End verschlüsselt und auch im Ruhezustand auf dem Server verschlüsselt. Hosengürtel und Hosenträger.

Wir glauben, dass End-to-End-Verschlüsselung die Voreinstellung für sensible Kommunikationen sein sollte, nicht ein Premium-Add-on oder ein Kästchen, das die meisten Benutzer nie finden. Mandraki macht es einfach zu aktivieren, transparent in seinen Einschränkungen und robust in seiner Implementierung.