Arquitetura Zero-Knowledge
A arquitetura de conhecimento zero do CriptEnv garante que o servidor nunca tenha acesso aos seus segredos em texto claro. Toda criptografia e descriptografia acontece exclusivamente no navegador do usuário, usando a senha mestra que nunca é transmitida.
Info
O Que É Conhecimento Zero?
No contexto do CriptEnv, "conhecimento zero" significa que o servidor pode confirmar que você tem a senha correta (através do vault proof) sem jamais saber qual é essa senha ou ter acesso às chaves derivadas dela.
Isso é diferente de sistemas tradicionais onde o servidor armazena hashes de senha e os dados — no CriptEnv, os dados criptografados são inúteis mesmo para quem controla o servidor.
Como Funciona a Criptografia do Lado do Cliente
Todo o processo de criptografia acontece no navegador usando a Web Crypto API:
┌──────────────────────────────────────────────────────────────┐
│ NAVEGADOR DO USUÁRIO │
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌────────────────┐ │
│ │ Senha │───▶│ PBKDF2 │───▶│ Chave Mestra │ │
│ │ Mestra │ │ (100k iter) │ │ (256-bit) │ │
│ └─────────────┘ └──────────────┘ └───────┬────────┘ │
│ │ │
│ ┌─────────────┐ ┌──────────────┐ │ │
│ │ Segredo │───▶│ AES-256-GCM │◀───────────┘ │
│ │ (plaintext)│ │ │ + HKDF(env_id) │
│ └─────────────┘ └──────┬───────┘ │
│ │ │
│ Ciphertext │
│ (IV + data + tag) │
└────────────────────────┼─────────────────────────────────────┘
│
▼ Apenas ciphertext é enviado
┌──────────────────────────────────────────────────────────────┐
│ SERVIDOR │
│ │
│ Armazena: ciphertext (inútil sem a chave) │
│ Recebe: vault proof (para verificação) │
│ Nunca vê: senha, chaves, plaintext │
└──────────────────────────────────────────────────────────────┘O Que o Servidor Vê vs. Não Vê
✓ Ciphertext (dados criptografados em AES-256-GCM)
✓ IVs (vetores de inicialização — não são secretos)
✓ Auth Tags (tags de autenticação GCM)
✓ Salt do PBKDF2 (gerado no registro, público por design)
✓ Vault Proof (hash derivado para autenticação)
✓ IDs de ambientes e projetos (metadados não-secretos)
✓ Timestamps de criação e modificação
✓ Estrutura organizacional (projetos, ambientes)Mecanismo do Vault Proof
O vault proof permite que o servidor verifique se o usuário conhece a senha correta sem que a senha ou as chaves de criptografia sejam transmitidas.
Geração do Vault Proof:
━━━━━━━━━━━━━━━━━━━━━
Senha Mestra + "proof_salt" (constante)
│
▼
PBKDF2-HMAC-SHA256 (100.000 iterações)
│
▼
Vault Proof (256-bit hash)
│
▼
Enviado ao servidor para verificação
O servidor armazena apenas o hash do proof.
Na autenticação, compara o proof enviado com o armazenado.
Se coincidir → acesso autorizado.
Se não coincidir → acesso negado.
Importante: o vault proof é derivado da mesma senha mestra,
mas com salt diferente ("proof_salt"), garantindo que:
• O proof não pode ser usado para derivar a chave de criptografia
• A chave de criptografia não pode gerar o proof
• São dois caminhos criptográficos independentesInfo
Implicações Práticas
🔑 Esqueceu a senha?
Não há mecanismo de recuperação. Como o servidor nunca teve acesso à sua senha ou chaves, não é possível recuperar dados sem ela. Isso é uma feature, não um bug — garante que ninguém além de você pode acessar seus segredos.
🏢 Segurança para Equipes
Em ambientes compartilhados, cada membro da equipe mantém sua própria chave mestra. Os segredos são re-criptografados com a chave de cada membro autorizado, garantindo isolamento criptográfico completo.
🔍 Auditoria
O servidor pode registrar eventos de acesso (timestamps, IPs, IDs de ambiente) sem nunca ter acesso ao conteúdo dos segredos. Isso permite auditoria de segurança sem comprometer a arquitetura zero-knowledge.