1. Objetivo da arquitetura
O objetivo principal é impedir que uma cópia do banco de dados, do armazenamento de objetos ou dos backups revele chaves e arquivos cadastrados. As senhas mestres e as operações de abertura permanecem no navegador do usuário.
O modelo considera ameaças como vazamento de banco, adulteração de registros, reutilização de requisições, tentativas de senha, roubo de sessão, abuso administrativo e falhas de integração. Os controles reduzem riscos, mas não criam invulnerabilidade.
2. Camadas criptográficas
- Argon2id: deriva uma chave de 32 bytes a partir da senha mestre, com salt aleatório e parâmetros versionados.
- XChaCha20-Poly1305: cifra e autentica as chaves privadas e o conteúdo de cada registro.
- X25519: sela a chave aleatória de cada registro para o par de chaves do cofre.
- Ed25519: assina os envelopes para detectar adulteração ou troca de registros.
Nome do dispositivo, tipo, identificador, chave, notas e etiquetas são reunidos e cifrados. Cada registro usa chave e nonce aleatórios. As versões criptográficas ficam identificadas para permitir migrações controladas.
Arquivos CMXD1
O Pendrive possui chaves X25519 e Ed25519 próprias. Cada versão de arquivo recebe uma chave aleatória e é dividida em blocos de 4 MiB, cifrados de forma independente com XChaCha20-Poly1305. Um manifesto assinado vincula ordem, hashes, tamanhos, arquivo, versão e conta, permitindo detectar troca, truncamento, repetição ou adulteração.
3. O que o servidor conhece — e o que não conhece
O servidor armazena
Identificadores opacos, envelopes criptografados, nonces, assinaturas, versões, relações opacas entre pastas, datas operacionais, tamanho e quantidade de registros ou blocos. Também mantém dados separados de conta e cobrança necessários para operar o serviço.
O servidor não recebe
Senhas mestres, chave de recuperação em texto aberto, nomes legíveis de dispositivos ou arquivos, notas abertas, conteúdo de arquivos ou chaves privadas desprotegidas.
Metadados mínimos continuam visíveis. “Zero-knowledge” descreve o conteúdo criptografado do cofre, não significa que a operação da conta seja anônima.
4. Controles além da criptografia
- senha de acesso separada e autenticação multifator disponível;
- bloqueio local por inatividade, aba oculta ou logout;
- cookies seguros, proteção CSRF, CORS restrito e limites de requisição;
- CSP e Trusted Types sem scripts externos no app; o reCAPTCHA fica em frame isolado, fora do domínio que manipula o cofre;
- isolamento entre sites, processos, banco e segredos operacionais;
- auditoria administrativa que exclui corpo de requisição e segredos;
- backup cifrado, restauração testada e menor privilégio.
Para reduzir automação e força bruta, ações sensíveis exigem um token novo do reCAPTCHA Enterprise. O JavaScript do Google roda somente em cripto-max.com/captcha/; o app valida origem, janela emissora, nonce e ação antes de aceitar o token. A senha mestre e os campos dos formulários nunca são enviados ao frame.
5. Limites e riscos residuais
Comprometimento do dispositivo: malware, captura de teclado, extensão maliciosa ou navegador comprometido podem observar a senha e o conteúdo enquanto o cofre estiver aberto.
Comprometimento privilegiado do servidor: acesso root ao ambiente de hospedagem poderia alterar o JavaScript entregue e tentar capturar a senha em um acesso futuro. Isolamento, integridade de deploy, revisão e monitoramento reduzem esse risco, mas ele não desaparece em uma aplicação web.
Senha mestre fraca: uma cópia dos envelopes permite tentativas offline contra a senha. Argon2id aumenta o custo, mas não compensa uma senha previsível ou reutilizada.
Disponibilidade: zero-knowledge protege confidencialidade, não garante acesso ininterrupto. Por isso oferecemos exportação cifrada para backup próprio.
Arquivos maliciosos: como o servidor não possui o plaintext, não consegue executar antivírus ou moderação sobre o conteúdo do Pendrive. Previews ativos de HTML e SVG são bloqueados, mas o usuário deve verificar a procedência antes de executar arquivos baixados.
Rollback: assinaturas detectam adulteração, mas um servidor totalmente comprometido ainda pode tentar apresentar uma versão antiga validamente assinada a um dispositivo sem estado anterior confiável.
6. Como o usuário reduz riscos
- use a senha mestre gerada pelo produto ou uma frase longa e exclusiva;
- guarde uma cópia física da senha mestre em local separado e protegido;
- ative autenticação multifator e revise sessões abertas;
- mantenha sistema, navegador e antivírus atualizados;
- instale apenas extensões indispensáveis e confiáveis;
- faça uma exportação cifrada e teste o desbloqueio antes de depender dela;
- nunca envie senha mestre ou chave completa ao suporte.
7. Divulgação responsável
Pesquisadores podem relatar vulnerabilidades em [email protected]. Inclua passos reproduzíveis, impacto estimado e um canal seguro de retorno. Não acesse dados de terceiros, não interrompa o serviço e não execute engenharia social.
Confirmaremos o recebimento e priorizaremos correções conforme risco. O arquivo canônico de contato está em /.well-known/security.txt.