Logo

Capítulo 3 Arquitetura do sistema e fluxo de dados

Este capítulo descreve os componentes de alto nível do sistema e o fluxo de dados de ponta a ponta no upload, no download e no gerenciamento pelo remetente. O foco está no que é criptografado, em quais metadados são necessários e em como o controle de acesso e a revogação são aplicados.

Metadados do documento

Versão do whitepaper
v1.0
Última atualização
2026-01-14

3.1 Componentes

  • Cliente: divide os arquivos em blocos, criptografa/descriptografa e gerencia a CEK no fragmento da URL.
  • API/Edge: emite e valida tokens com escopo definido; serve o manifesto e os blocos de texto cifrado.
  • Armazenamento de objetos: armazena blocos e manifestos criptografados; tratado como não confiável quanto à confidencialidade do texto simples.
  • Armazenamento de estado: rastreia o estado da transferência (progresso do upload, expiração, revogação) com metadados mínimos.

3.2 Objetos de dados

  • Manifesto: parâmetros públicos necessários para buscar e montar os blocos (cryptoVersion, tamanho/quantidade de blocos, mapeamento); NÃO DEVE conter a CEK.
  • Bloco: parte criptografada do arquivo (texto cifrado) mais metadados mínimos (tamanho/etag), endereçada por (transferId, fileId, chunkIndex).
  • Estado: registro do lado do servidor para autorização, TTL, revogação e retomada.

3.3 Fluxo de upload

  1. O cliente cria uma transferência e recebe um token de upload de curta duração, com escopo definido e vinculado a transferId.
  2. O cliente gera localmente uma CEK por arquivo, divide os arquivos em blocos de tamanho fixo e criptografa cada bloco com AEAD.
  3. O cliente envia os blocos de texto cifrado em paralelo; as novas tentativas são idempotentes por bloco.
  4. O cliente envia o manifesto (apenas parâmetros públicos). O servidor marca a transferência como READY quando as partes necessárias estão presentes.

3.4 Fluxo de download

  1. O destinatário abre o link de compartilhamento. O fragmento da URL (material da CEK) permanece no navegador e não é enviado ao servidor.
  2. O cliente busca o manifesto usando um token de download com escopo definido e determina o plano de blocos.
  3. O cliente baixa os blocos de texto cifrado (opcionalmente em paralelo), verifica a autenticação AEAD e depois monta o arquivo em texto simples.
  4. Em caso de falhas, o cliente retoma solicitando apenas os blocos ausentes; falhas de integridade DEVEM resultar em falha fechada (fail closed).

3.5 Gerenciamento pelo remetente e fluxo de auditoria

  • Os remetentes se autenticam com um token de login de longa duração (armazenado no cliente) para as operações de gerenciamento.
  • As APIs de gerenciamento permitem listar transferências, consultar as evidências de entrega e revogar/excluir transferências.
  • Os dados de auditoria foram projetados para ficar visíveis apenas ao remetente; por padrão, não são expostos aos destinatários.

3.6 Visibilidade e minimização

  • O servidor e o armazenamento lidam apenas com texto cifrado e com os parâmetros públicos necessários; eles não conseguem descriptografar o conteúdo sem a CEK.
  • Logs e análises DEVERIAM ser minimizados e NÃO DEVEM incluir fragmentos de URL nem material da CEK.
  • A coleta de metadados DEVERIA ser limitada por finalidade (evidências de entrega, prevenção de abuso e confiabilidade operacional).