Logo

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

Este capítulo estabelece um modelo de ameaça compartilhado e um vocabulário de limites de confiança: quais ativos protegemos, o que os invasores podem fazer, quais suposições devem ser mantidas e como o sistema DEVE falhar ao fechar na autenticação ou incompatibilidade de parâmetros.

Metadados do documento

Versão do artigo técnico
v1.0
Última atualização
2026-01-14

2.1 Inventário de ativos

  • Confidencialidade do conteúdo: bytes de arquivo de texto simples e 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.
  • Availability: 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 o CEK; se o CEK vazar (por exemplo, link compartilhado), a confidencialidade será perdida intencionalmente.

2.3 Pressupostos de segurança

  • Os clientes executam código confiável (sem extensões/malware maliciosos); caso contrário, o conhecimento zero não poderá proteger o terminal.
  • 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 gerenciamento CEK acontecem apenas no cliente.
  • Limite de borda/API: o servidor valida tokens e fornece texto cifrado/manifesto; NÃO DEVE aprender 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 falha fechada

  • Em caso de falha de token, incompatibilidade de parâmetros ou falha de autenticação AEAD, o sistema DEVE falhar ao fechar.
  • NÃO DEVE gerar texto simples parcial quando as verificações de integridade falharem.
  • Mensagens de erro e logs DEVEM minimizar dados confidenciais e NÃO DEVEM incluir fragmentos de URL, CEK ou materiais deriváveis.