Capítulo 2 Modelo de ameaças e limites de confiança

Metadados do documento

Versão do whitepaper

v1.0

Última atualização

2026-01-14

2.1 Inventário de ativos

• Confidencialidade do conteúdo: os bytes em texto simples dos arquivos e as chaves de descriptografia (CEK) DEVEM ser protegidos.
• Integridade do conteúdo: o texto cifrado e os metadados DEVEM ser invioláveis (autenticação AEAD).
• Controle de acesso: tokens de acesso de curta duração, tokens de login do remetente e estado de revogação.
• Disponibilidade: capacidade de fazer upload, download e retomar transferências em condições comuns de rede.

2.2 Modelo de atacante

• Invasor de rede: pode observar, atrasar, descartar e reproduzir tráfego; não pode quebrar a criptografia TLS/AEAD moderna.
• Invasor da Web: pode criar links maliciosos, tentar XSS/CSRF e tentar injeção de UI/injeção de prompt.
• Ator de abuso: pode automatizar uploads/downloads para esgotar cotas, extrair conteúdo ou amplificar o tráfego.
• Presume-se que o adversário do lado do servidor não tenha a CEK; se a CEK vazar (por exemplo, com o compartilhamento do link), a confidencialidade é perdida por design.

2.3 Pressupostos de segurança

• Os clientes executam código confiável (sem extensões maliciosas nem malware); caso contrário, o conhecimento zero não pode proteger o endpoint.
• Fragmentos de URL (#...) não são transmitidos ao servidor por meio de solicitações HTTP no comportamento padrão do navegador.
• As primitivas criptográficas (AES-GCM, SHA-256, TLS) são usadas corretamente e não estão quebradas.

2.4 Limites de confiança

• Limite do cliente: criptografia/descriptografia e o gerenciamento da CEK acontecem apenas no cliente.
• Limite de borda/API: o servidor valida tokens e fornece texto cifrado/manifesto; NÃO DEVE conhecer a CEK.
• Limite de armazenamento de objetos: armazena pedaços e manifestos de texto cifrado; tratados como não confiáveis para fins de confidencialidade.

2.5 Princípio de fail-closed (falha segura)

• Em caso de falha de token, incompatibilidade de parâmetros ou falha de autenticação AEAD, o sistema DEVE falhar de forma segura (fail-closed).
• NÃO DEVE gerar texto simples parcial quando as verificações de integridade falharem.
• É recomendável que as mensagens de erro e os logs minimizem dados confidenciais; eles NÃO DEVEM incluir fragmentos de URL, a CEK ou materiais deriváveis.