Erklärt · Verschlüsselung
Was ist MLS-Verschlüsselung? MLS vs. Signal-Protokoll vs. Matrix Megolm
MLS, Messaging Layer Security, ist der IETF-Standard für Ende-zu-Ende-verschlüsselte Gruppenkommunikation, im Juli 2023 als RFC 9420 veröffentlicht. Er gibt allen Mitgliedern einer Gruppe für jede Version der Gruppe dasselbe Geheimnis, abgeleitet aus einem Baum von Schlüsseln, sodass das Hinzufügen oder Entfernen eines Mitglieds einen Aufwand kostet, der ungefähr mit dem Logarithmus der Gruppengröße wächst. Anders als das Signal-Protokoll ist MLS von Anfang an für Gruppen entworfen; anders als Megolm von Matrix bietet es neben Forward Secrecy auch Post-Compromise Security.
Aktualisiert
- Standard
- RFC 9420, IETF, Juli 2023
- Löst
- Gruppenschlüsselvereinbarung für Ende-zu-Ende-Verschlüsselung
- Schlüsselstruktur
- Ein Ratchet-Baum aus Schlüsseln (TreeKEM)
- Sicherheitseigenschaften
- Forward Secrecy und Post-Compromise Security
- Einheit der Mitgliedschaft
- Ein Gerät, keine Person
- In Enclessa
- Direkt- und Gruppen-Direktnachrichten, über OpenMLS
Welches Problem löst MLS?
Ende-zu-Ende-Verschlüsselung zwischen zwei Geräten ist ein gelöstes Problem, in einer Gruppe ist sie es nicht. Jedes Mitglied einer verschlüsselten Gruppe braucht denselben Schlüssel, niemand sonst darf ihn haben, und er muss sich ändern, sobald jemand beitritt oder die Gruppe verlässt – sonst könnte ein entferntes Mitglied weiterlesen. Der ältere Ansatz verschlüsselt jede Nachricht einzeln für jedes empfangende Gerät oder verteilt einen Schlüssel über Eins-zu-eins-Kanäle an jedes Gerät. Beides funktioniert, und bei beidem kostet jede Änderung der Mitgliedschaft Arbeit im Verhältnis zur Zahl der Geräte. MLS, von der IETF als RFC 9420 standardisiert, ersetzt das durch eine Gruppenschlüsselvereinbarung: Die Mitglieder einigen sich für jede Version der Gruppe, Epoche genannt, auf ein gemeinsames Geheimnis, und jeder Beitritt, jede Entfernung und jede Schlüsselaktualisierung bringt die ganze Gruppe gemeinsam in eine neue Epoche. Alle Mitglieder sind sich auch einig, wer zur Gruppe gehört – ein Server kann also nicht verschiedenen Mitgliedern unbemerkt verschiedene Listen zeigen.
Wie macht TreeKEM große Gruppen praktikabel?
MLS ordnet die Schlüssel der Gruppe als Binärbaum an, den Ratchet-Baum; das Verfahren heißt TreeKEM. Jedes Gerät hält ein Blatt, und jeder Knoten darüber hält ein Schlüsselpaar, das nur die Mitglieder darunter kennen. Um das Gruppengeheimnis zu ändern, erzeugt ein Mitglied neue Schlüssel entlang des Pfads von seinem Blatt zur Wurzel und verschlüsselt jedes neue Geheimnis an den benachbarten Zweig dieses Pfads statt an jedes Gerät einzeln. In einem gut gefüllten Baum ist dieser Pfad proportional zum Logarithmus der Gruppengröße lang: Eine Gruppe aus tausend Geräten braucht für eine Aktualisierung etwa zehn Verschlüsselungen statt tausend. Entfernungen können leere Knoten hinterlassen, die eine spätere Aktualisierung verteuern, bis der Baum wieder gefüllt ist – logarithmisch ist also der typische Aufwand, keine Garantie. Diese Konstruktion erlaubt es MLS, Gruppen mit Tausenden von Mitgliedern anzustreben.
Was bedeuten Forward Secrecy und Post-Compromise Security bei MLS?
Forward Secrecy bedeutet, dass ein heute gestohlener Schlüssel keine Nachrichten entschlüsselt, die vor dem Diebstahl gesendet wurden. MLS erreicht das, indem es die Schlüssel jeder Nachricht nur in eine Richtung aus dem Epochengeheimnis ableitet und sie nach Gebrauch löscht, sodass ein Angreifer mit dem aktuellen Zustand nicht rückwärts gehen kann. Post-Compromise Security ist die Gegenrichtung: Sobald ein kompromittiertes Gerät entfernt wird oder schlicht seine Schlüssel aktualisiert, fließt frischer Zufall in das Gruppengeheimnis, und der Angreifer mit dem alten Zustand ist von neuen Nachrichten ausgeschlossen. Der Double Ratchet des Signal-Protokolls bietet beide Eigenschaften zwischen zwei Parteien; MLS bietet beide für eine ganze Gruppe. Beide Eigenschaften hängen von echtem Verhalten ab: Alte Schlüssel müssen auf dem Gerät tatsächlich gelöscht werden, und ein kompromittiertes Gerät muss erkannt und entfernt werden oder sich aktualisieren. Deshalb behandelt MLS jedes Gerät und nicht jedes Konto als eigenes Mitglied der Gruppe.
Wie unterscheidet sich MLS vom Signal-Protokoll?
Das Signal-Protokoll ist die Familie von Spezifikationen, die Signal veröffentlicht, vor allem eine anfängliche Schlüsselvereinbarung – X3DH und sein Post-Quanten-Nachfolger PQXDH – und danach der Double Ratchet. Es wurde für zwei Parteien entworfen und bietet zwischen ihnen Forward Secrecy und Post-Compromise Security. Gruppen werden auf diesen paarweisen Sitzungen aufgebaut: Ein Absender verschlüsselt jede Nachricht entweder für jedes Mitgliedsgerät oder verteilt einen Absenderschlüssel über die paarweisen Kanäle an jedes von ihnen, und in beiden Fällen wächst der Aufwand einer Mitgliedschaftsänderung mit der Zahl der Geräte. MLS geht von der Gruppe aus. Seine Baumstruktur hält Änderungen günstig, und jedes Mitglied prüft in jeder Epoche denselben Gruppenzustand. Das Signal-Protokoll ist kein IETF-Standard, MLS schon. Beide sind gründlich analysiert und weit verbreitet; die Wahl zwischen ihnen zählt vor allem bei großen Gruppen und für Teams, die einen offenen Standard wollen.
Wie unterscheidet sich MLS von Megolm bei Matrix?
Megolm ist der Algorithmus für Gruppenverschlüsselung in der Matrix-Spezifikation. Jeder Absender führt für einen Raum eine eigene Ratchet-Sitzung und teilt sie über Olm, den Eins-zu-eins-Kanal von Matrix, mit jedem empfangenden Gerät. Das passt zu einem föderierten Netz und macht das Teilen des Verlaufs einfach: Ein Gerät, das die Sitzung ab einem bestimmten Punkt erhält, kann alles lesen, was danach gesendet wurde. Die Matrix-Spezifikation benennt offen, was das kostet. Megolm bietet nur teilweise Forward Secrecy, weil ein gespeicherter Sitzungszustand Nachrichten ab seiner Position entschlüsseln kann, und innerhalb einer Sitzung keine Backward Secrecy: Wer einen Sitzungszustand erlangt, kann jede spätere Nachricht darin lesen, bis der Absender eine neue Sitzung beginnt. Clients mildern das, indem sie Sitzungen regelmäßig und bei Mitgliedschaftsänderungen erneuern. MLS gibt der ganzen Gruppe stattdessen ein sich fortentwickelndes Geheimnis, mit Forward Secrecy und Post-Compromise Security im Protokoll selbst.
Wie nutzt Enclessa MLS?
Enclessa verschlüsselt Direkt- und Gruppen-Direktnachrichten Ende zu Ende mit MLS, über OpenMLS, eine quelloffene Rust-Implementierung von RFC 9420. Derselbe kompilierte Code läuft in jedem Client, im Web-Client als WebAssembly. Jedes Gerät ist ein eigenes Mitglied mit eigenem Schlüssel: Ein neues Gerät ist in der Unterhaltung sichtbar, und wird eines widerrufen, erhält die Unterhaltung neue Schlüssel. Geräte werden gegenseitig signiert, und Sicherheitsnummern lassen zwei Personen außerhalb der App prüfen, dass sie mit den echten Geräten des anderen sprechen. Der Server implementiert nur den MLS-Zustelldienst: Er ordnet Handshake-Nachrichten, leitet sie weiter und hält keinen Schlüssel, der eine Nachricht öffnet. Kanäle sind bewusst anders: verwaltete Räume, die der Server lesen kann, damit Suche, Aufbewahrung und Export funktionieren, und jeder Raum zeigt, welcher Art er ist. OpenMLS wurde extern geprüft; die eigene Integration von Enclessa hat noch kein Audit durch Dritte durchlaufen.
Wovor schützt MLS nicht?
MLS schützt den Inhalt von Nachrichten zwischen den Geräten einer Gruppe. Metadaten verbirgt es nicht von selbst: Der Zustelldienst sieht weiterhin, welche Geräte in welcher Gruppe sind, wann Nachrichten gesendet werden und wie groß sie sind. Es schützt kein Gerät, das kompromittiert ist, während es Mitglied ist; Post-Compromise Security hilft erst, wenn dieses Gerät entfernt wird oder seine Schlüssel aktualisiert. Es schützt nicht, was ein Empfänger kopiert, weiterleitet, abfotografiert oder im Klartext sichert, und es kann ein berechtigtes Mitglied nicht daran hindern, Gelesenes weiterzugeben. Es entscheidet auch nicht, wer in die Gruppe gehört: Das Protokoll authentifiziert Berechtigungsnachweise, und welchen davon man vertraut, entscheidet die Anwendung – deshalb zählt die Geräteverifizierung. Schließlich ist MLS eine Spezifikation. Seine Zusagen gelten nur in einer Implementierung, die ihr korrekt folgt; deshalb werden Implementierungen geprüft, und deshalb ist eine gemeinsam genutzte, geprüfte Bibliothek sicherer als eine neue.
MLS, Signal-Protokoll und Megolm nebeneinander
Jede Zeile stammt aus der Spezifikation des jeweiligen Protokolls, unten verlinkt. Die Signal-Spalte beschreibt das paarweise Protokoll und die üblichen Wege, darauf Gruppen zu bauen.
| MLS im Vergleich mit dem Signal-Protokoll und Matrix Megolm | MLS | Signal-Protokoll | Megolm (Matrix) |
|---|---|---|---|
| Spezifiziert von | IETF, RFC 9420 (2023) | Veröffentlichte Spezifikationen von Signal (X3DH, PQXDH, Double Ratchet) | Die Matrix-Spezifikation |
| Entworfen für | Gruppen, von zwei Mitgliedern bis zu Tausenden | Zwei Parteien; Gruppen darauf aufgebaut | Gruppenräume in einem föderierten Netz |
| Wie die Gruppe Schlüssel teilt | Ein Gruppengeheimnis pro Epoche, aus einem Ratchet-Baum | Paarweise Sitzungen, über die Nachrichten oder Absenderschlüssel verteilt werden | Die Sitzung jedes Absenders, über Olm mit jedem Gerät geteilt |
| Aufwand einer Mitgliedschaftsänderung | Typischerweise logarithmisch in der Gruppengröße | Wächst mit der Zahl der Mitgliedsgeräte | Eine neue Sitzung, mit jedem Gerät geteilt |
| Forward Secrecy | Ja | Ja, zwischen zwei Parteien | Teilweise, nach Angabe der Spezifikation selbst |
| Post-Compromise Security | Ja, nach einer Aktualisierung oder Entfernung | Ja, zwischen zwei Parteien | Nicht innerhalb einer Sitzung; Sitzungen werden erneuert |
| Alle Mitglieder einig über den Gruppenzustand | Ja, in jeder Epoche geprüft | Der Anwendung überlassen | Dem Raumzustand auf den Servern überlassen |
Wo sind diese Protokolle spezifiziert?
Die Primärquellen hinter jeder Aussage dieser Seite (auf Englisch). Lesen Sie die Spezifikation statt einer Zusammenfassung – auch statt dieser.
Weiterlesen
Fragen
MLS-Verschlüsselung: häufige Fragen
- Keines ist einfach besser. Das Signal-Protokoll ist ein ausgereiftes, gründlich analysiertes Verfahren für zwei Parteien, auf dessen paarweisen Sitzungen Gruppen aufgebaut werden. MLS ist ein IETF-Standard, der von Anfang an für Gruppen entworfen ist: Mitgliedschaftsänderungen bleiben auch in wachsenden Gruppen günstig, und alle Mitglieder sind sich über den Gruppenzustand einig. Bei großen Gruppen und für einen offenen Standard ist MLS im Vorteil.
- Die Ende-zu-Ende-Verschlüsselung von Matrix ist mit Olm für Eins-zu-eins-Kanäle und Megolm für Räume spezifiziert. Die Matrix-Spezifikation beschreibt Megolm als nur teilweise vorwärtssicher und ohne Backward Secrecy innerhalb einer Sitzung, gemildert durch das Erneuern von Sitzungen. Den Stand etwaiger MLS-Arbeiten nennt die aktuelle Matrix-Spezifikation.
- MLS ist um Cipher Suites herum gebaut, seine Sicherheit hängt also von den Algorithmen ab, die eine Installation wählt. Die in RFC 9420 definierten Cipher Suites nutzen klassische Elliptische-Kurven-Kryptografie; Post-Quanten-Suites sind Sache von Erweiterungen und neueren Arbeiten, nicht des ursprünglichen RFC.
- Direktnachrichten und Gruppen-Direktnachrichten. Kanäle sind verwaltete Räume, die der Server lesen kann, damit Suche, Aufbewahrung und Export funktionieren, und jeder Raum zeigt seinen Modus an. Ein Raum lässt sich nicht von einem Modus in den anderen umwandeln.
Verschlüsselte Zusammenarbeit, gehostet in Europa.
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.