Keyhive – Local-first Access Control

• Keyhive ist ein Forschungsprojekt zum Aufbau eines Local-first-Access-Control-Systems, das auch offline ohne zentralen Server funktioniert, und ein Versuch, Sicherheit auf Signal-Niveau auf die Zusammenarbeit an Dokumenten anzuwenden
• Durch ein auch in verteilten Umgebungen synchronisierbares Capability Model, ein Group Management CRDT und kausalitätsbasiertes E2EE (Causal Keys) wird eine sichere Zugriffskontrolle auf Daten auch während der Zusammenarbeit ermöglicht
• Das zentrale kryptografische Protokoll BeeKEM gewährleistet auch ohne zentralen Server Forward Secrecy und Post-Compromise Security und ist für Gruppen mit Tausenden von Mitgliedern ausgelegt
• Die Synchronisationsschicht Beelay von Keyhive verbessert mithilfe von RIBLT-basierter Set-Synchronisation und dem Sedimentree-Kompressionsverfahren die Geschwindigkeit der Synchronisation großer lokaler Dokumente
• Ink & Switch präsentiert mit diesem Projekt Basistechnologien für eine sichere Kollaborationsplattform ohne Serverabhängigkeit und zielt auf den Ausbau des Offline-first-Software-Ökosystems ab

---

Überblick über Keyhive

• Keyhive ist eine Forschung zur Umsetzung von Zugriffskontrolle auf kollaborative Daten in einer Local-first-Umgebung, ohne Cloud-Server zu verwenden
  • Traditionelle Cloud-Authentifizierung (OAuth usw.) hängt von der Rechteprüfung über einen zentralen Server ab, im Local-first-Modell müssen jedoch Daten und Berechtigungen gemeinsam bewegt werden
  • Dafür setzt Keyhive auf ein Capability-basiertes Design und baut eine verteilte Authentifizierungs- und Verschlüsselungsschicht auf
• Ziel ist es, wie bei Google Docs oder GitHub eine benutzerfreundliche Erfahrung beizubehalten und zugleich vollständig dezentrale Sicherheit für Zusammenarbeit zu realisieren

Designphilosophie und Aufbau

• Keyhive wurde nach dem Prinzip entworfen, dass die Zugriffskontrollschicht vor der Datenschicht existieren muss
  • Dadurch müssen sich auch Storage- und Synchronisationsstrukturen an der Art der Verschlüsselung und Rechteverwaltung orientieren
• Drei Hauptkomponenten:
  1. Convergent Capabilities: Ein neues, für CRDTs geeignetes Berechtigungsmodell, bei dem Delegation zwischen Objekten kryptografisch nachweisbar ist
  2. Group Management CRDT: Führt das Hinzufügen und Entfernen von Gruppen sowie den Entzug von Rechten ohne zentralen Server aus
  3. E2EE with Causal Keys: Verwaltet Schlüssel entlang der kausalen Struktur eines Dokuments und ermöglicht so effiziente Verschlüsselung

Convergent Capabilities

• Ein Modell, das die Vorteile bestehender Object-capabilities und zertifikatsbasierter Berechtigungen (Certificate-capability) kombiniert
  • Durch Einbeziehung des CRDT-Zustands bleibt Konsistenz (Convergence) auch im Offline-Zustand erhalten
• Über ein öffentlich-schlüsselbasiertes Delegationssystem können Nutzer, Gruppen und Dokumente als gleichwertige Objekte behandelt werden
  • Beispiel: Nutzer bilden eine Device-Gruppe, Dokumente bilden eine Team-Einheit zur Vergabe von Zugriffsrechten

BeeKEM: Protokoll zur Gruppenschlüsselvereinbarung

• BeeKEM ist ein CGKA-Protokoll (Continuous Group Key Agreement), das ohne zentralen Server funktioniert
  • Es übernimmt die Struktur von TreeKEM, wurde aber so verbessert, dass es allein mit Causal Order arbeiten kann
  • Es verwendet nur Diffie-Hellman-Schlüsselaustausch und die BLAKE3-Hashfunktion und ist damit auf Basis standardisierter Kryptografie entworfen
• Wichtige Merkmale:
  • Gruppenmitglieder hinzufügen oder entfernen, Konflikte bei gleichzeitigen Updates auflösen und leere Knoten wiederherstellen – all das wird in einem verteilten Zustand verarbeitet
  • Bei Nebenläufigkeitskonflikten bleibt die Sicherheit durch einen „Conflict Key“ Merge-Algorithmus erhalten
  • Im Normalfall logarithmische Performance, im schlechtesten Fall lineare Performance

Beelay: Protokoll zur Synchronisation mit minimalem Vertrauen

• Beelay ist ein RPC-basiertes Protokoll zur Synchronisation von Daten und Berechtigungsinformationen in Keyhive; der Server leitet nur verschlüsselte Daten weiter
  • Nachrichten werden mit Ed25519-Signaturen authentifiziert, Schutz vor Replay-Angriffen und Man-in-the-Middle-Angriffen (PITM) ist integriert
• Zentrale Abläufe:
  • Durch die Berechnung von Mengendifferenzen mit RIBLT (Rateless Invertible Bloom Lookup Table) wird eine schnelle Synchronisation großer Datenmengen erreicht
  • Mitgliedschaftsgraphen (Gruppen-/Dokumentbeziehungen), Zustände von Dokumentkollektionen und Dokumentinhalte werden nacheinander synchronisiert
• Über die Sedimentree-Struktur werden Automerge-Commit-Graphen komprimiert und zusammengeführt, was bei der Synchronisation großer Dokumente Bandbreite spart

Synchronisationsablauf

1. Synchronisation des Membership-Graphen: Synchronisation von Gruppen- und Berechtigungsbeziehungen
2. Synchronisation der Dokumentkollektion: Identifikation geänderter Dokumente
3. CGKA-Synchronisation: Zusammenführung von BeeKEM-Operationen
4. Synchronisation des Dokumentinhalts: Komprimierte Übertragung auf Basis von Sedimentree

• Bei einer einzelnen typischen Änderung ist die vollständige Synchronisation mit nur zwei Request-Response-Roundtrips abgeschlossen

Weitere Pläne

• Keyhive ist derzeit als pre-alpha-Version veröffentlicht und bietet eine Rust-basierte Implementierung sowie WASM-/TypeScript-Bindings
  • keyhive_core: Signatur-, Verschlüsselungs- und Delegationssystem
  • beelay-core: Synchronisations-Engine auf Basis verschlüsselter Daten
  • keyhive_wasm: Wrapper für Browser-Support
• Geplant sind außerdem die Veröffentlichung von Sicherheitsprüfungen und Performance-Papers; Ziel ist die Etablierung eines standardisierten Sicherheitsmodells für Local-first-Kollaborationssysteme