Logo

Whitepaper de segurança e privacidade (visão geral)Capítulo 5

Capítulo 5 Criptografia e gerenciamento de chaves

Este capítulo descreve a criptografia de ponta a ponta (E2EE) do FileBolt e o limite de conhecimento zero, e especifica os parâmetros de cryptoVersion=v1, as regras de codificação, os modos de falha e as restrições do cliente. As chaves são geradas e usadas no cliente; o servidor e o armazenamento de objetos lidam apenas com blocos de texto cifrado e os metadados necessários.

5.0 Resumo

  • O sistema NÃO DEVE receber, armazenar nem registrar em log as chaves de descriptografia (CEK). O material da CEK é transportado apenas no fragmento da URL (a parte após o #), que não é enviado ao servidor nas requisições HTTP.
  • A criptografia usa AES-128-GCM (AEAD). Cada arquivo usa uma CEK independente (16 bytes). O tamanho do bloco é fixo (por exemplo, 16 MB).
  • Construção do IV na v1: IV = noncePrefix(8B) || uint32_be(chunkIndex)(4B). O AAD vincula transferId, fileId e chunkIndex para impedir a troca de contexto e o replay.
  • Os tokens do servidor controlam apenas o acesso ao texto cifrado e expiram; eles não concedem capacidade de descriptografia.

5.1 Criptografia de transporte (TLS)

5.1.1 Objetivo de segurança

  • Impedir espionagem e adulteração nas conexões de upload, download e API.
  • Proteger tokens e texto cifrado em trânsito.

5.1.2 Política de segurança

  • O sistema DEVE servir todas as páginas e APIs somente por HTTPS.
  • O sistema DEVERIA dar preferência ao TLS 1.3 e oferecer suporte ao TLS 1.2 quando necessário; protocolos e cifras fracos DEVEM ser desativados.
  • O sistema DEVE ativar o HSTS com um valor razoável de max-age.

5.2 Criptografia de blocos (AES-128-GCM)

5.2.1 Notas de projeto

  • Os arquivos são divididos em blocos de tamanho fixo; cada bloco é criptografado de forma independente para permitir transferência paralela e retomada.
  • A autenticação AEAD protege a integridade; qualquer falha de autenticação DEVE resultar em falha fechada (fail closed).

5.2.2 Política de segurança

  • Cada arquivo DEVE usar uma CEK distinta (16 bytes).
  • O IV DEVE ser único por (arquivo, chunkIndex). A v1 usa a codificação noncePrefix + chunkIndex.
  • O AAD DEVE incluir (transferId, fileId, chunkIndex) para vincular o texto cifrado ao seu contexto.

5.3 Modelo de link de conhecimento zero

5.3.1 Restrições principais

  • A CEK (ou o material de derivação) DEVE ser transportada apenas no fragmento da URL e NÃO DEVE ser incluída em parâmetros de consulta nem em cabeçalhos.
  • O servidor NÃO DEVE registrar fragmentos em log; os logs DEVEM ser higienizados para evitar captura acidental.
  • A política de referenciador DEVERIA impedir o vazamento do fragmento em navegações de saída (ver Capítulo 9).

5.4 Geração e tratamento de chaves

  • As chaves DEVEM ser geradas com um gerador de números aleatórios criptograficamente seguro (WebCrypto).
  • As chaves DEVERIAM ser mantidas apenas na memória e apagadas quando não forem mais necessárias.
  • Os clientes NÃO DEVEM manter a CEK de forma persistente em locais visíveis ao servidor (por exemplo, cookies, parâmetros de consulta).

5.5 Codificação e parâmetros

  • cryptoVersion=v1 identifica o conjunto de algoritmos e as regras de IV/AAD.
  • O manifesto DEVE incluir os parâmetros públicos necessários (tamanho/quantidade de blocos, noncePrefix, mapeamento de fileId), mas NÃO DEVE incluir a CEK.

5.6 Modos de falha (falha fechada)

  • Em caso de falha de descriptografia ou de autenticação AEAD, os clientes DEVEM abortar e NÃO DEVEM gerar texto simples parcial.
  • Em caso de divergência de parâmetros (transferId/fileId/chunkIndex), os clientes DEVEM falhar de forma fechada e DEVERIAM informar um erro acionável.

5.7 IDs de afirmação relacionados