Ilhas e Múltiplas Identidades em um Único Dispositivo: Como Tornamos a Privacidade Parte da Arquitetura

Quando se desenvolve um mensageiro privado, inevitavelmente surge uma questão incômoda: o que exatamente protege o usuário, suas promessas ou sua arquitetura? Promessas não podem ser verificadas externamente. Portanto, na RCQ, nos esforçamos para que a privacidade seja mantida no dispositivo e na estrutura de dados, e não apenas porque somos pessoas boas.

Neste artigo, analisaremos duas coisas que surgiram disso: ilhas (seu próprio servidor) e multilicidade (várias contas criptografadas independentes em um único telefone). E separadamente, sem embelezamento, contaremos onde estão os limites dessa abordagem.

1. Fundamento: Um servidor que sabe pouco

Primeiro, brevemente sobre a base, caso contrário, não ficará claro mais adiante.

• Identificador: É um UIN, apenas um número. Sem número de telefone, sem upload da lista de contatos. A conta não está vinculada a uma identidade, pode ser apagada e criada uma nova em segundos.
• Sealed sender: O remetente é selado dentro de um envelope criptografado, e não está no cabeçalho. No nível de transporte, o servidor vê "para quem entregar", mas não "de quem". Quem entende isso, vê imediatamente que o grafo de comunicação não é coletado no servidor.
• O conteúdo é criptografado end-to-end: X25519 efêmero por mensagem, HKDF, ChaCha20-Poly1305. O servidor encaminha o texto cifrado, ele não tem chaves.

A ideia é simples: o servidor é basicamente um tubo burro para texto cifrado. Sem telefones, sem grafo, sem conteúdo. Isso é importante para tudo o que se segue.

2. Ilhas: Seu próprio servidor em vez do nosso

Como o servidor é um tubo burro, ele pode ser movido para qualquer lugar. Qualquer organização (redação, escritório de advocacia, equipe, ONG) levanta sua própria instância RCQ, sua própria ilha, e se comunica dentro dela: seu próprio servidor, seus próprios UINs, sua própria história, seus próprios grupos, separadamente da rede pública.

O que isso dá na prática:

• Não há um grande alvo. A rede pública é um único ponto de interesse. Cem ilhas separadas são cem alvos separados, e a comprometimento de um não afeta os outros.
• Metadados (o pouco que existe) permanecem com o proprietário da ilha, e não conosco.
• A questão de "e se você for pressionado" é removida. Se o servidor é seu, você precisa ser pressionado, e não nós, e você decide o que é armazenado nele. E, lembre-se, quase não há nada para armazenar.

Tecnicamente, o cliente não está preso ao nosso domínio: o endereço do servidor é um parâmetro. Você pode se conectar à ilha diretamente durante o registro ou adicionar uma conta nela mais tarde. O que nos leva à segunda parte.

3. Multilicidade: Várias pessoas em um telefone

A tarefa era a seguinte: dar em um dispositivo um conjunto de identidades totalmente independentes. Não temas de design, mas contas diferentes: cada uma com seu próprio servidor, seu próprio UIN, suas próprias chaves, seus próprios contatos e sua própria história. Trabalhando em uma ilha corporativa, pessoal na rede pública, outra para algo diferente. E a troca entre elas é instantânea, sem relogins e sem reiniciar o aplicativo.

A principal dificuldade aqui não é na interface do usuário, mas em garantir que as identidades realmente não vazem umas para as outras. Se você fizer isso de forma descuidada, os dados de um aparecerão em outro, e toda a empreitada será sem sentido. Portanto, o isolamento vai até o fundo, e a chave de tudo isso é o UUID local da conta:

• O registro de contas armazena apenas metadados de roteamento: este UUID, endereço do servidor, rótulo. Não há segredos nele.
• Os segredos de cada conta (UIN, token, chaves privadas) estão em um armazenamento criptografado sob o prefixo de seu UUID. O arquivo é fisicamente único, mas os slots não se cruzam.
• O banco de dados de mensagens de cada conta é próprio, um arquivo separado com um UUID no nome. As threads não são misturadas no nível do sistema de arquivos.
• Favoritos, arquivo, contadores não lidos também são distribuídos por este prefixo.

A troca é uma remontagem a quente: interrompemos a conexão atual, redirecionamos todos os armazenamentos para o UUID de outra conta, relemos seu banco de dados, levantamos o socket novamente. Externamente, parece uma mudança instantânea de identidade, internamente é uma substituição cuidadosa dos dados que o processo em execução está observando.

Houve uma confusão separada com a atualização de instalações antigas. Quem já tinha uma conta com o esquema antigo (sem prefixos), na primeira inicialização, é silenciosamente envolvido na primeira conta do registro: geramos um UUID, transferimos chaves para ele, renomeamos o arquivo de banco de dados. Do lado do usuário, nada acontece, e isso é correto, a atualização não deve derrubar nada.

4. Honestamente: Do que isso NÃO protege

Esta parte geralmente é omitida com vergonha. Acreditamos que, sem ela, o texto sobre segurança é uma mentira, então está aqui.

• Isso não protege contra um dispositivo infectado. Se o Pegasus ou um implante semelhante em nível de kernel chegar ao telefone, ele lê tudo após a descriptografia, diretamente da tela e da memória. Nenhum mensageiro, nem Signal, nem nós, protege disso. End-to-end protege os dados da rede e do servidor, mas não de quem já possui seu telefone. Qualquer pessoa que prometa imunidade ao Pegasus não está dizendo a verdade.
• Forward secrecy em nossas plataformas, e isso precisa ser dito diretamente. No iOS, as sessões estabelecidas usam Double Ratchet, ou seja, forward secrecy completo já está presente. No Android, há atualmente um esquema v=1 mais simples sem forward secrecy: se a chave de longo prazo vazar, a correspondência anterior a ela é revelada. Transferir o Double Ratchet para o Android é nossa tarefa criptográfica mais imediata.
• Não há auditoria independente ainda. Os primitivos são padrão e comprovados, mas "escrevemos com cuidado" não é o mesmo que "foi verificado externamente". A auditoria está nos planos, estamos procurando financiamento para ela. Antes disso, não dizemos "seguro comprovado", e não aconselhamos que você acredite naqueles que dizem.

Um mensageiro privado que não declara seus limites é mais perigoso do que um honesto: ele cria uma falsa sensação de segurança.

Onde tudo isso está

Ilhas e multilicidade já estão funcionando, esta é a parte que concluímos. Forward secrecy no Android e verificação de impressões digitais de chaves (para fechar a substituição de chaves no lado do servidor) nos planos imediatos, auditoria mais adiante.

O código do cliente é aberto, os links estão abaixo do artigo. Se você é daqueles que olham para o código-fonte antes de confiar, somos a favor.