In der heutigen Zeit, in der Datenschutz und digitale Autonomie immer stärker in den Vordergrund rücken, wächst das Interesse an Systemen, die nicht nur Sicherheit und Effizienz gewährleisten, sondern auch die Kontrolle über persönliche und gemeinschaftliche Daten zurück in die Hände der Nutzer legen. Ein herausragendes Beispiel dafür ist BeeKEM, ein von Ink & Switch entwickeltes Key-Encapsulation-Verfahren (KEM), das speziell für dezentrale, capabilities-basierte Systeme zur Steuerung von Zugriffen und Verschlüsselung in Gruppen entwickelt wurde. Dieses Protokoll bietet nicht nur einen neuartigen Ansatz zur Verwaltung von Schlüsseln und Berechtigungen, sondern ist auch auf die besonderen Anforderungen von verteilten, kollaborativen Anwendungen ausgelegt, die auf lokalen Daten und starker Kryptografie basieren. Um BeeKEM und seine Bedeutung besser zu verstehen, ist es wichtig, die Grundlagen der sicheren Nachrichtenübermittlung zu betrachten. Seit der Einführung des Signal-Protokolls, auch bekannt als Double Ratchet Algorithmus, gilt es als Maßstab für Ende-zu-Ende verschlüsselte Zwei-Personen-Kommunikation.
Signal ermöglicht es zwei Parteien, Nachrichten so zu verschlüsseln, dass nur Sender und Empfänger diese entschlüsseln können. Dies geschieht über raffinierte kryptografische Techniken, darunter den Diffie-Hellman-Schlüsselaustausch sowie sogenannte Key-Derivation-Funktionen, die für jede Nachricht individuelle Schlüssel generieren. Die Herausforderung bei der Nutzung dieses Protokolls in Gruppen besteht darin, dass der Aufwand exponentiell mit der Anzahl der Teilnehmer ansteigt, weil Nachrichten individuell für jedes Mitglied verschlüsselt und entschlüsselt werden müssen. An dieser Stelle setzen moderne Konzepte für Secure Group Messaging (SGM) an. Bevor das Messaging Layer Security (MLS)-Protokoll mit seiner innovativen TreeKEM-Subprotokoll veröffentlicht wurde, griffen Dienste wie WhatsApp und Signal auf sogenannte Sender Keys zurück.
Dabei sendet jedes Mitglied der Gruppe an alle anderen jeweils einen symmetrischen Schlüssel, der für die Nachrichtenverschlüsselung verwendet wird. Dies vereinfachte die Verwendung auf Anwendungsebene, führte im Hinblick auf Gruppenverwaltung und Mitgliederwechsel jedoch immer noch zu erheblichen Effizienzproblemen, vor allem bei der Handhabung der Schlüssel. Das MLS-Protokoll und das darin enthaltene TreeKEM bieten eine deutlich effizientere Methode, um Gruppen-Schlüssel zu verwalten, indem sie die Kommunikation auf einer spezifischen Baumstruktur basieren lassen. In TreeKEM werden neue Mitglieder in einem linksbalancierten Binärbaum eingetragen, wodurch für jede Operation nur eine klar definierte Position und ein einfacher Pfad zum Wurzelknoten vorgegeben sind. Jeder Knoten dieses Baums besitzt ein Schlüsselpaar, dessen geheimer Schlüssel von den Mitgliedern auf dem Pfad mit Hilfe von Diffie-Hellman-Schlüsselaustausch hergeleitet wird.
Das ermöglicht die Berechnung gemeinsamer Gruppenschlüssel, ohne dass alle Teilnehmer jede einzelne Schlüsselposition kennen müssen. Obwohl TreeKEM bereits eine enorme Fortschritt darstellt, stößt es bei Szenarien mit parallelen oder konkurrierenden Änderungen an seine Grenzen. Das dominierende Konzept ist hier die totale Reihenfolge der Gruppenstatus-Updates, die als sogenannte Epochen bezeichnet werden. Konkurrente Änderungen müssen in einer linearen Reihenfolge abgearbeitet werden, was zu Konflikten und möglichen Rollbacks führt. Das ist weniger ideal für Systeme, die auf lokale Kopien und asynchrone Synchronisation setzen, wie es bei sogenannten CRDTs (Conflict-Free Replicated Data Types) der Fall ist, die Strong Eventual Consistency ohne zentralen Koordinator gewährleisten wollen.
Hier kommt BeeKEM ins Spiel. Dieses Protokoll, das im Rahmen des Keyhive-Projekts von Ink & Switch entwickelt wurde, verfolgt einen anderen Ansatz: Anstatt eine zentrale Autorität für die Auflösung von Konflikten und die Festlegung einer einzigen, linearen Gruppenstatusfolge zu verwenden, erlaubt BeeKEM parallele Gruppenzustände. Das bedeutet, dass die Mitglieder mehrere miteinander konkurrierende Versionszweige (Epochs) eines Gruppenbaums verwalten und diese Konflikte erst bei der nächsten Aktualisierung auflösen. Ein zentrales Feature von BeeKEM ist die Behandlung von Konflikten in Form von sogenannten „konfliktierten Knoten“ – Stellen im Gruppenschlüsselbaum, an denen mehrere Schlüssel gleichzeitig vorliegen, weil unterschiedliche Gruppenmitglieder unabhängig voneinander Updates gemacht haben. Anstatt solche Konflikte sofort zu blockieren oder zu annulieren, hält das Protokoll alle Optionen offen, indem es alle Schlüssel parallel speichert.
Das erlaubt allen Teilnehmern weiterhin, Nachrichten in den konkurrierenden Gruppenzuständen zu entschlüsseln, auch wenn diese bereits voneinander abweichen. Um die Sicherheit und Konsistenz zu wahren, müssen die Gruppenmitglieder bei der nächsten Aktualisierung der Schlüssel die konfliktreichen Pfade in ihrem Baum als „leer“ betrachten und neu erstellen. Das bedeutet, dass sie die Mehrdeutigkeiten auflösen, indem sie neue Schlüsselketten erzeugen, die die vorherigen Konflikte überbrücken. Besonders beeindruckend ist dabei die Fähigkeit von BeeKEM, die Schlüsselverwaltung und -aktualisierung sowohl offline als auch asynchron zu gestalten. So kann ein Mitglied, das temporär offline ist, unter Umständen Änderungen vornehmen und diese nach dem Wiederverbinden mit der Gruppe erfolgreich integrieren, ohne dass komplett neu synchronisiert werden muss.
Die Praxis zeigt, dass BeeKEM insbesondere in Local-First-Anwendungen, wie bei Muni Towns Roomy, einen enormen Vorteil bringt. Während herkömmliche Ansätze auf zentralisierte Server angewiesen sind, die Entscheidungen über den Status der Gruppe treffen und den Zugriff kontrollieren, bietet BeeKEM die Möglichkeit, dezentrale Autorisierungsstrukturen aufzubauen. Diese sind „capabilities-based“, was bedeutet, dass Zugriffsrechte nicht zentral verwaltet, sondern über kryptografisch abgesicherte Delegationsketten verteilt werden, für die jedes Mitglied genau definierte Rollen und Rechte besitzt. Ein weiteres technisches Highlight von BeeKEM ist die Verwendung von „Sedimentree“. Dies ist ein Mechanismus, der zunächst kryptografisch aktualisierte CRDT-Datenströme basierend auf einer probabilistischen Kompression optimiert.
Die Methode nutzt die Struktur eines gerichteten azyklischen Graphen (DAG) und dessen Tiefe als Annäherung für die Wahrscheinlichkeit konkurrierender Updates. So wird eine effiziente und gleichzeitig sichere Multicast-Übertragung von Gruppeninhalten möglich, ohne die oftmals sehr hohen Metadatenkosten konventioneller Synchronisationsverfahren. Gleichzeitig ist BeeKEM darauf ausgelegt, nach Kompromittierung einzelner Schlüssel durch Post-Compromise Security (PCS) die Schlüsselketten automatisch und effektiv zu aktualisieren. Mitglieder können sicherstellen, dass selbst nach einer möglichen Sicherheitslücke die neuen Schlüssel weder von dem kompromittierten Mitglied noch von Dritten entschlüsselt werden können. Dabei steht im Vordergrund, dass auch bei partiellen Offlinesituationen und konkurrierenden Änderungen die Sicherheit nie verloren geht.
Die Frage der Forward Secrecy, also die Unmöglichkeit, vergangene Nachrichten mit zukünftigen kompromittierten Schlüsseln rückwirkend zu entschlüsseln, stellt BeeKEM vor besondere Herausforderungen. Aufgrund der Notwendigkeit, vergangene Updates stets verfügbar zu halten, und der Natur von CRDTs, die vollständige Verlaufsinformation zur Replikation benötigen, ist Forward Secrecy hier eingeschränkt. Dennoch wird ein sinnvolles beschränktes Forward Secrecy-Niveau durch die kontinuierliche Schlüsselrotation und das Halten paralleler Schlüssel für konkurrierende Gruppenzustände erreicht. Diese Kompromisse sind pragmatisch und reflektieren die Bedürfnisse der Anwendungsfälle. Aus gesellschaftlicher und politischer Perspektive ist die Entwicklung von BeeKEM und des Keyhive-Projekts zudem ein Beitrag zur Stärkung von Datenschutz, Selbstbestimmung und digitaler Souveränität.
