Keyhive - Controle de acesso local-first

• Keyhive é um projeto de pesquisa para construir um sistema de controle de acesso local-first que funciona offline e sem servidor central, numa tentativa de aplicar segurança no nível do Signal à colaboração em documentos
• Por meio de um modelo de delegação de permissões (Capability Model) sincronizável mesmo em ambientes distribuídos, de um CRDT de gerenciamento de grupos e de E2EE baseada em causalidade (Causal Keys), viabiliza controle seguro de acesso a dados mesmo durante a colaboração
• O protocolo criptográfico central BeeKEM garante Forward Secrecy (sigilo futuro) e Post-Compromise Security (segurança após comprometimento) sem servidor central, com suporte a grupos de milhares de pessoas
• A camada de sincronização Beelay do Keyhive usa sincronização de conjuntos baseada em RIBLT e o método de compressão Sedimentree para melhorar a velocidade de sincronização de documentos locais em grande escala
• Com este projeto, a Ink & Switch apresenta a tecnologia-base para plataformas seguras de colaboração sem dependência de servidor, com o objetivo de expandir o ecossistema de software offline-first

---

Visão geral do Keyhive

• Keyhive é uma pesquisa para implementar controle de acesso a dados colaborativos em um ambiente local-first sem usar servidores em nuvem
  • A autenticação tradicional em nuvem (como OAuth) depende da verificação de permissões por um servidor central, mas no modelo local-first os dados e as permissões precisam se mover juntos
  • Para isso, o Keyhive adota um design baseado em delegação de permissões (capability) e constrói uma camada distribuída de autenticação e criptografia
• O objetivo é implementar segurança de colaboração totalmente descentralizada mantendo uma experiência amigável ao usuário como a do Google Docs e do GitHub

Filosofia de design e composição

• O Keyhive foi projetado com base no princípio de que a camada de controle de acesso deve existir antes da camada de dados
  • Por isso, a estrutura de armazenamento e sincronização também precisa seguir o modelo de criptografia e gerenciamento de permissões
• Três componentes principais:
  1. Convergent Capabilities: um novo modelo de permissões adequado para CRDTs, no qual a delegação entre entidades pode ser comprovada criptograficamente
  2. Group Management CRDT: realiza adição e remoção de grupos e revogação de permissões sem servidor central
  3. E2EE with Causal Keys: gerencia chaves de acordo com a estrutura causal do documento para implementar criptografia eficiente

Convergent Capabilities

• Um modelo que combina as vantagens de permissões por objeto (Object-capability) e permissões baseadas em certificado (Certificate-capability)
  • Ao incluir o estado do CRDT, mantém a consistência (convergence) mesmo offline
• Por meio de um sistema de delegação baseado em chave pública, usuários, grupos e documentos podem ser tratados como entidades equivalentes
  • Exemplo: um usuário pode formar um grupo de dispositivos, e um documento pode compor uma unidade de equipe para conceder permissões de acesso

BeeKEM: protocolo de acordo de chaves em grupo

• BeeKEM é um protocolo de CGKA (acordo contínuo de chaves em grupo) que funciona sem servidor central
  • Herda a estrutura do TreeKEM, mas foi aprimorado para operar apenas com ordem causal (Causal Order)
  • Foi projetado com base em criptografia padrão, usando apenas troca de chaves Diffie-Hellman e a função hash BLAKE3
• Principais características:
  • Processa em estado distribuído todas as operações, como adição e remoção de membros do grupo, resolução de conflitos de atualizações simultâneas e restauração de nós vazios
  • Em conflitos de concorrência, mantém a segurança por meio do algoritmo de mesclagem de “Conflict Key”
  • Desempenho logarítmico no caso geral e linear no pior caso

Beelay: protocolo de sincronização com confiança minimizada

• Beelay é um protocolo baseado em RPC que sincroniza os dados e as permissões do Keyhive, enquanto o servidor apenas retransmite dados criptografados
  • As mensagens são autenticadas com assinaturas Ed25519 e incluem proteção contra ataques de retransmissão e ataques man-in-the-middle persistentes (PITM)
• Procedimentos principais:
  • Usa RIBLT (Rateless Invertible Bloom Lookup Table) para calcular diferenças entre conjuntos e permitir sincronização rápida de grandes volumes de dados
  • Sincroniza em sequência o grafo de associação (relações entre grupos e documentos), o estado da coleção de documentos e o corpo dos documentos
• Com a estrutura Sedimentree, comprime e mescla o grafo de commits do Automerge, reduzindo o uso de banda na sincronização de documentos em grande escala

Fluxo de sincronização

1. Sincronização do grafo de associação: sincroniza grupos e relações de permissão
2. Sincronização da coleção de documentos: identifica documentos alterados
3. Sincronização do CGKA: mescla operações do BeeKEM
4. Sincronização do corpo do documento: transmissão comprimida com base em Sedimentree

• Em um caso comum com 1 alteração, toda a sincronização é concluída com apenas 2 rodadas de requisição e resposta

Planos futuros

• O Keyhive está atualmente em versão pre-alpha pública, com implementação em Rust e bindings para WASM/TypeScript
  • keyhive_core: sistema de assinatura, criptografia e delegação
  • beelay-core: motor de sincronização baseado em dados criptografados
  • keyhive_wasm: wrapper para suporte no navegador
• No futuro, estão previstos a divulgação de verificações de segurança e de artigos de desempenho, com o objetivo de estabelecer um modelo padrão de segurança para sistemas de colaboração local-first