Kern · jeder Tarif
Enclessa verschlüsselt Direktnachrichten Ende-zu-Ende mit MLS, dem als RFC 9420 standardisierten Messaging-Layer-Security-Protokoll, umgesetzt mit der auditierten Bibliothek OpenMLS. Jedes Gerät hält seinen eigenen Schlüssel, die Gruppe wird neu verschlüsselt, wenn Mitglieder und Geräte hinzukommen oder gehen, und der Server betreibt nur den Zustelldienst — er hält nie einen Schlüssel, mit dem sich eine Nachricht entschlüsseln ließe. Das ergibt Forward Secrecy, sodass ein heute kompromittierter Schlüssel das Gestern nicht öffnet, und Post-Compromise Security, sodass sich die Gruppe erholt, sobald das kompromittierte Gerät entfernt ist.
Aktualisiert
- Protokoll
- MLS, RFC 9420
- Implementierung
- OpenMLS, einmal in Rust kompiliert
- Schlüsselumfang
- Ein Schlüssel pro Gerät, nicht pro Konto
- Rolle des Servers
- Nur Zustelldienst, hält keine Schlüssel
- Eigenschaften
- Forward Secrecy und Post-Compromise Security
- Verifizierung
- Sicherheitsnummern und gegenseitig signierte Geräte
Warum MLS statt eines eigenen Verschlüsselungsverfahrens?
Weil ein selbst entworfenes Protokoll der zuverlässigste Weg ist, genau das falsch zu machen. MLS ist ein IETF-Standard mit veröffentlichter Sicherheitsanalyse und für genau den Fall gebaut, den ein Arbeitsplatz hat und ein Chat zu zweit nicht: Gruppen, deren Mitglieder und Geräte sich ständig ändern, mit Neuverschlüsselung in logarithmischer statt linearer Zeit. Enclessa verwendet OpenMLS, aus einem einzigen Rust-Crate nach WebAssembly für den Browser und über UniFFI für native Clients kompiliert, sodass jede Plattform denselben kryptografischen Code ausführt.
- Eine Implementierung, einmal kompiliert, geteilt von Web und Desktop
- Der Server stellt den Zustelldienst bereit und führt keine MLS-Kryptografie aus
- Schlüsselmaterial verlässt nie das Gerät, das es erzeugt hat
Was weiß der Server tatsächlich über eine verschlüsselte Unterhaltung?
Den Chiffretext, die Gruppenkennung, die Epochennummer, welches Gerät gesendet hat und wann. Nicht den Text, nicht die Anhänge, nicht die Linkvorschauen — die erzeugt der sendende Client und verschlüsselt sie mit der Nachricht. Metadaten, die für die Zustellung existieren müssen, existieren; darüber hinaus nichts.
- Chiffretext, Gruppenkennung, Epoche, sendendes Gerät, Zeitstempel
- Kein Klartext, keine Anhangsinhalte, keine Vorschaubilder
- Push-Benachrichtigungen enthalten bei Verschlüsselung keinen Nachrichteninhalt
Woher weiß ich, dass ich mit der richtigen Person spreche?
Jedes Gerät, das einer Unterhaltung beitritt, ist ein eigenes Blatt in der MLS-Gruppe, und das Hinzufügen ist für alle darin sichtbar. Geräte werden von einem Gerät aus gegenseitig signiert, dem Sie bereits vertrauen, und mit Sicherheitsnummern können zwei Personen auf einem anderen Weg bestätigen, dass kein Dritter zwischen ihnen sitzt.
- Ein neues Gerät wird in der Unterhaltung angekündigt, nie stillschweigend hinzugefügt
- Gegenseitiges Signieren von einem bereits vertrauenswürdigen Gerät aus
- Sicherheitsnummern zur Überprüfung auf einem zweiten Weg
- Verschlüsselte Schlüsselsicherung, damit ein verlorenes Gerät kein verlorener Verlauf ist
Wie funktioniert Compliance, wenn der Server nichts lesen kann?
Ehrlich und sichtbar. In einem verschlüsselten Raum lässt sich eine Aufbewahrungs- oder Offenlegungspflicht nur über einen Compliance-Empfänger erfüllen, dessen Schlüssel für alle sichtbar im Raum sitzt — nie über eine stille Kopie auf dem Server. Eine Organisation mit einer pauschalen Aufbewahrungspflicht führt diese Unterhaltungen stattdessen in verwalteten Kanälen, wo der Server lesen und deshalb aufbewahren, exportieren und sperren kann.
- Keine stille Schlüsselhinterlegung, niemals
- Verwaltete Kanäle tragen Aufbewahrung, Export und Audit
- Die Wahl ist eine Richtlinie, die die Organisation festlegt, keine versteckte Voreinstellung
Was es nicht tut
Hier gesagt, statt nach der Anmeldung entdeckt.
- Die Verschlüsselung umfasst Direktnachrichten und Gruppen-Direktnachrichten. Verwaltete Kanäle sind für den Server lesbar, damit Suche, Aufbewahrung und Compliance-Export funktionieren.
- Aufzeichnung und Telefoneinwahl gibt es in Ende-zu-Ende-verschlüsselten Anrufen nicht, weil beides die Medien an einer Stelle entschlüsseln müsste, die Sie nicht sehen.
- Post-Quanten-Schlüsselaustausch und Föderation sind architektonisch offengehalten, aber nicht umgesetzt.
Verwandte Funktionen
Wo das im Einsatz ist
Fragen
- Enclessa verwendet MLS, das von der IETF als RFC 9420 standardisierte Messaging-Layer-Security-Protokoll, umgesetzt mit der Bibliothek OpenMLS. Jedes Gerät hält seinen eigenen Schlüssel, der Server keinen.
- Nein. In Ende-zu-Ende-verschlüsselten Unterhaltungen speichert der Server nur Chiffretext, die Gruppenkennung, die Epoche, das sendende Gerät und einen Zeitstempel. Er hat keinen Schlüssel, der den Inhalt entschlüsseln kann — weder Enclessa noch ein Hosting-Anbieter noch jemand, der eine Herausgabeanordnung für den Server erhält, kann also den Klartext vorlegen.
- Forward Secrecy bedeutet, dass ein heute kompromittierter Schlüssel keine Nachrichten offenlegt, die davor gesendet wurden. Enclessa hat das, und dazu Post-Compromise Security: Die Unterhaltung wird wieder sicher, sobald ein kompromittiertes Gerät entfernt ist und die Gruppe neu verschlüsselt. Beide Eigenschaften stammen aus MLS.
- Sie entfernen es aus Ihrer Geräteliste. Damit wird sein Blatt aus jeder MLS-Gruppe entfernt, in der Sie sind, und eine Neuverschlüsselung ausgelöst, sodass das verlorene Gerät nichts mehr entschlüsseln kann, was danach gesendet wird. Eine verschlüsselte Schlüsselsicherung stellt Ihren Verlauf auf einem neuen Gerät wieder her.
Legen Sie in ein paar Minuten einen Workspace an. Er gehört Ihnen, erreichbar unter your-team.enclessa.app, betrieben in der Europäischen Union, mit Ende-zu-Ende-verschlüsselten Direktnachrichten ab der ersten.