Keyhive - contrôle d’accès local-first

• Keyhive est un projet de recherche visant à construire un système de contrôle d’accès local-first capable de fonctionner hors ligne sans serveur central, avec l’ambition d’appliquer à la collaboration documentaire un niveau de sécurité équivalent à Signal
• Grâce à un modèle de délégation d’autorisations (capability model) synchronisable dans un environnement distribué, à un CRDT de gestion de groupe et au chiffrement E2EE fondé sur les relations causales (Causal Keys), le projet permet un contrôle d’accès sûr aux données même en situation de collaboration
• Son protocole cryptographique central, BeeKEM, garantit la Forward Secrecy et la Post-Compromise Security sans serveur central, tout en prenant en charge des groupes de plusieurs milliers de personnes
• La couche de synchronisation Beelay de Keyhive améliore la vitesse de synchronisation de grands documents locaux grâce à une synchronisation d’ensembles basée sur RIBLT et à la méthode de compression Sedimentree
• Avec ce projet, Ink & Switch présente les technologies de base d’une plateforme de collaboration sécurisée sans dépendance à un serveur, avec pour objectif d’élargir l’écosystème des logiciels offline-first

---

Vue d’ensemble de Keyhive

• Keyhive est une recherche visant à implémenter, sans recourir à des serveurs cloud, un contrôle d’accès aux données collaboratives dans un environnement local-first
  • Les mécanismes traditionnels d’authentification cloud (comme OAuth) reposent sur une validation des autorisations via un serveur central, alors que dans un modèle local-first, les données et les autorisations doivent se déplacer ensemble
  • Pour cela, Keyhive adopte une conception fondée sur les capabilities et met en place une couche distribuée d’authentification et de chiffrement
• L’objectif est d’offrir, comme Google Docs ou GitHub, une expérience conviviale tout en assurant une sécurité collaborative totalement décentralisée

Philosophie de conception et architecture

• Keyhive est conçu selon le principe selon lequel la couche de contrôle d’accès doit exister avant la couche de données
  • En conséquence, le stockage comme la structure de synchronisation doivent eux aussi suivre le mode de chiffrement et de gestion des autorisations
• Trois composants principaux :
  1. Convergent Capabilities : un nouveau modèle d’autorisations adapté aux CRDT, permettant de prouver cryptographiquement la délégation entre entités
  2. Group Management CRDT : permet d’ajouter ou de retirer des groupes et de révoquer des autorisations sans serveur central
  3. E2EE with Causal Keys : gère les clés selon la structure causale du document afin de mettre en œuvre un chiffrement efficace

Convergent Capabilities

• Un modèle qui combine les avantages des object-capabilities traditionnelles et des certificate-capabilities
  • En y intégrant l’état du CRDT, il maintient la convergence même hors ligne
• Grâce à un schéma de délégation fondé sur des clés publiques, il devient possible de traiter utilisateurs, groupes et documents comme des entités de même niveau
  • Exemple : un utilisateur peut former un groupe d’appareils, et un document peut constituer une unité d’équipe à laquelle on accorde des droits d’accès

BeeKEM : protocole d’accord de clés de groupe

• BeeKEM est un protocole CGKA (Continuous Group Key Agreement) fonctionnant sans serveur central
  • Il reprend la structure de TreeKEM tout en l’améliorant pour fonctionner uniquement avec l’ordre causal (Causal Order)
  • Il repose exclusivement sur l’échange de clés Diffie-Hellman et sur la fonction de hachage BLAKE3, dans une conception bâtie sur des briques cryptographiques standard
• Principales caractéristiques :
  • Ajout et suppression de membres du groupe, résolution des conflits de mises à jour simultanées, restauration de nœuds vides : toutes ces opérations sont gérées dans un état distribué
  • En cas de conflit de concurrence, la sécurité est préservée grâce à un algorithme de fusion de “Conflict Key”
  • Performances logarithmiques dans le cas général, linéaires dans le pire des cas

Beelay : protocole de synchronisation à confiance minimale

• Beelay est un protocole basé sur RPC qui synchronise les données et informations d’autorisation de Keyhive, le serveur ne faisant que relayer des données chiffrées
  • Les messages sont authentifiés par des signatures Ed25519, avec une protection intégrée contre les attaques par rejeu et les attaques de l’homme du milieu (PITM)
• Fonctionnement principal :
  • Utilisation de RIBLT (Rateless Invertible Bloom Lookup Table) pour calculer les différences entre ensembles et permettre une synchronisation rapide de grands volumes de données
  • Synchronisation séquentielle du graphe d’appartenance (relations groupes-documents), de l’état des collections de documents, puis du contenu des documents
• Grâce à la structure Sedimentree, le graphe de commits d’Automerge est compressé et fusionné, ce qui réduit la bande passante lors de la synchronisation de documents volumineux

Flux de synchronisation

1. Synchronisation du graphe d’appartenance : synchronisation des groupes et des relations d’autorisation
2. Synchronisation des collections de documents : identification des documents modifiés
3. Synchronisation CGKA : fusion des opérations BeeKEM
4. Synchronisation du contenu des documents : transmission compressée fondée sur Sedimentree

• Dans le cas d’un changement ordinaire, deux allers-retours de requêtes suffisent pour achever la synchronisation complète

Feuille de route

• Keyhive est actuellement disponible en version pre-alpha, avec une implémentation en Rust et des bindings WASM/TypeScript
  • keyhive_core : système de signature, de chiffrement et de délégation
  • beelay-core : moteur de synchronisation fondé sur des données chiffrées
  • keyhive_wasm : wrapper pour la prise en charge du navigateur
• Des validations de sécurité et des publications sur les performances sont prévues par la suite, avec pour objectif d’établir un modèle standard de sécurité pour les systèmes collaboratifs local-first