Logo

Artigo sobre segurança e privacidade (visão geral)Capítulo 5

Capítulo 5 Criptografia e gerenciamento de chaves

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

5.0 Resumo

  • O sistema NÃO DEVE receber, armazenar ou registrar chaves de descriptografia (CEK). O material CEK é transportado apenas no fragmento de URL (# parte), que não é enviado ao servidor em solicitações HTTP.
  • Usos de criptografia AES-128-GCM (AEAD). Cada arquivo usa um CEK independente (16 bytes). O tamanho do bloco é fixo (por exemplo, 16 MB).
  • construção v1 IV: IV = noncePrefix(8B) || uint32_be(chunkIndex)(4B). AAD binds transferId, fileIde chunkIndex para evitar troca e repetição de contexto.
  • 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

  • Evite espionagem e adulteração de links de upload/download/API.
  • Proteja tokens e texto cifrado em trânsito.

5.1.2 Política de segurança

  • O sistema MUST servir todas as páginas e APIs somente por HTTPS.
  • O sistema SHOULD prefira TLS 1.3 e suporte TLS 1.2 conforme necessário; protocolos/cifras fracos DEVEM ser desabilitados.
  • O sistema MUST habilitar HSTS com um razoável max-age.

5.2 Criptografia de blocos (AES-128-GCM)

5.2.1 Notas de projeto

  • Os arquivos são divididos em pedaços de tamanho fixo; cada pedaço é criptografado de forma independente para suportar transferência paralela e capacidade de recuperação.
  • A autenticação AEAD protege a integridade; qualquer falha de autenticação DEVE falhar no fechamento.

5.2.2 Política de segurança

  • Cada arquivo DEVE usar um CEK distinto (16 bytes).
  • IV DEVE ser exclusivo por (arquivo, chunkIndex). v1 usa noncePrefix + chunkIndex encoding.
  • 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 Principais restrições

  • CEK (ou material de derivação) DEVE ser transportado apenas no fragmento de URL e NÃO DEVE ser incluído em parâmetros de consulta ou cabeçalhos.
  • O servidor NÃO DEVE registrar fragmentos; os logs DEVEM ser higienizados para evitar captura acidental.
  • A política de referência DEVE evitar o vazamento de fragmentos por meio da navegação de saída (ver Capítulo 9).

5.4 Geração e manuseio de chaves

  • As chaves DEVEM ser geradas usando um RNG criptograficamente seguro (WebCrypto).
  • As chaves DEVEM ser mantidas apenas na memória e apagadas quando não forem mais necessárias.
  • Os clientes NÃO DEVEM persistir CEK em locais visíveis ao servidor (por exemplo, cookies, parâmetros de consulta).

5.5 Codificação e parâmetros

  • cryptoVersion=v1 identifica conjunto de algoritmos e regras IV/AAD.
  • O manifesto DEVE incluir parâmetros públicos obrigatórios (tamanho/contagem do bloco, noncePrefix, mapeamento de fileId), mas NÃO DEVE incluir CEK.

5.6 Modos de falha (falha fechada)

  • Em caso de falha de descriptografia ou falha de autenticação AEAD, os clientes DEVEM abortar e NÃO DEVEM gerar texto simples parcial.
  • Na incompatibilidade de parâmetros (transferId/fileId/chunkIndex), os clientes DEVEM falhar no fechamento e DEVEM relatar um erro acionável.

5.7 IDs de reivindicações relacionadas