Whitepaper de Segurança

Análise técnica detalhada de como o RocketShare protege seus arquivos com criptografia de conhecimento zero

Este documento fornece uma visão técnica abrangente de como o RocketShare protege seus dados. É destinado a profissionais de segurança, diretores de conformidade e qualquer pessoa que queira entender exatamente como nossa criptografia funciona.

1. Resumo executivo

O RocketShare é uma plataforma de compartilhamento de arquivos com criptografia de conhecimento zero. Os arquivos são criptografados no lado do cliente usando AES-256-GCM antes do upload, e a chave de criptografia é incorporada exclusivamente no fragmento da URL—uma parte da URL que os navegadores nunca transmitem aos servidores. Essa arquitetura significa que os operadores do RocketShare não podem acessar, ler ou descriptografar arquivos de usuários em nenhuma circunstância, incluindo solicitações de interceptação legal.

Propriedades principais:

  • Arquitetura de conhecimento zero — o servidor nunca possui chaves de descriptografia
  • Criptografia ponta a ponta — os arquivos são criptografados antes de sair do dispositivo do remetente e descriptografados apenas no dispositivo do destinatário
  • Sem armazenamento de chaves no servidor — as chaves existem apenas no fragmento da URL do link de compartilhamento
  • Expiração e exclusão automáticas — os arquivos são excluídos permanentemente após a expiração

2. Modelo de ameaças

Contra o que protegemos

  • Comprometimento do servidor — mesmo que um invasor obtenha acesso total aos nossos servidores, os arquivos armazenados permanecem criptografados e ilegíveis sem a chave por transferência
  • Interceptação de rede — TLS 1.3 protege dados em trânsito; chaves de criptografia em fragmentos de URL nunca são enviadas pela rede
  • Ameaças internas — operadores do RocketShare têm zero acesso ao conteúdo dos arquivos por design, não por política
  • Interceptação legal — não podemos atender solicitações de descriptografia porque não possuímos as chaves; só podemos fornecer blobs criptografados e metadados

O que está fora do nosso modelo de ameaças

  • Dispositivo comprometido do remetente ou destinatário — se um malware tiver acesso ao navegador do usuário, pode interceptar chaves ou arquivos em texto simples
  • Interceptação do link de compartilhamento — qualquer pessoa que obtenha o link completo (incluindo o fragmento da URL) pode descriptografar os arquivos; os usuários devem compartilhar links de forma segura
  • Vulnerabilidades do navegador — dependemos da Web Crypto API fornecida pelo navegador; explorações no nível do navegador estão fora do nosso controle

3. Implementação da criptografia

Algoritmo

Toda criptografia de arquivo usa AES-256-GCM (Galois/Counter Mode), um algoritmo de criptografia autenticada simétrica. O GCM fornece confidencialidade e integridade, o que significa que qualquer adulteração do texto cifrado é detectada durante a descriptografia.

Geração de chaves

As chaves de criptografia são geradas no lado do cliente usando a Web Crypto API do navegador (crypto.subtle.generateKey), que é suportada pelo gerador de números pseudoaleatórios criptograficamente seguro (CSPRNG) do sistema operacional.

  • Tamanho da chave: 256 bits
  • Fonte: Web Crypto API (crypto.subtle.generateKey), suportada por CSPRNG no nível do sistema operacional
  • Escopo: uma chave única por transferência (arquivo ou pacote)

Processo de criptografia

  1. O usuário seleciona arquivos para upload
  2. Uma chave AES de 256 bits é gerada usando crypto.subtle.generateKey()
  3. Um vetor de inicialização (IV) único de 96 bits é gerado por operação de criptografia
  4. Os arquivos são criptografados no navegador usando AES-256-GCM via Web Crypto API
  5. O texto cifrado criptografado é enviado ao servidor
  6. O material bruto da chave é codificado em Base64url e colocado no fragmento da URL (#<base64url-key>)

Criptografia em streaming

Para arquivos grandes, o RocketShare usa uma abordagem de criptografia em streaming. Os arquivos são processados em blocos para minimizar o uso de memória, permitindo a criptografia e o upload de arquivos que excedem a RAM disponível.

Cada bloco é criptografado com seu próprio IV de 96 bits gerado aleatoriamente (crypto.getRandomValues), garantindo texto cifrado único para cada bloco, mesmo que o conteúdo do arquivo se repita.

4. Gerenciamento de chaves

Abordagem do fragmento de URL

A chave de descriptografia é incorporada no fragmento da URL (a porção após #). Esta é a propriedade de segurança crítica do sistema:

  • Navegadores nunca transmitem fragmentos de URL aos servidores em requisições HTTP (RFC 3986, Seção 3.5)
  • O fragmento permanece inteiramente no lado do cliente — na barra de endereços do navegador, no histórico e quando compartilhado pelo usuário
  • O servidor recebe apenas o caminho e os parâmetros de consulta, nunca a porção da chave #...

Ciclo de vida da chave

  1. Geração — criada no navegador do remetente usando CSPRNG
  2. Uso — usada imediatamente para criptografia no lado do cliente
  3. Incorporação — colocada no fragmento da URL do link de compartilhamento
  4. Transmissão — o usuário compartilha o link via seu canal seguro preferido (e-mail, mensageiro, etc.)
  5. Descriptografia — o navegador do destinatário lê o fragmento e descriptografa o arquivo
  6. Sem armazenamento — as chaves nunca são armazenadas no servidor; elas existem apenas no link de compartilhamento

O que o servidor armazena

O servidor armazena apenas:

  • Blobs de arquivos criptografados (texto cifrado)
  • Metadados da transferência: nome do arquivo, tamanho do arquivo, tipo MIME, data de expiração
  • Configurações da transferência: limite de downloads, hash de proteção por senha (se ativado)
  • Dados no nível da conta: e-mail, tokens de autenticação (não relacionados à criptografia de arquivos)

O servidor nunca armazena: chaves de criptografia, conteúdo de arquivos em texto simples ou quaisquer dados que possam ser usados para derivar a chave.

5. Ciclo de vida do arquivo

Upload

  1. Usuário seleciona arquivos → chave de criptografia gerada no lado do cliente
  2. Arquivos criptografados com AES-256-GCM no navegador
  3. Blobs criptografados enviados ao servidor via TLS 1.3
  4. Servidor armazena texto cifrado + metadados, retorna ID da transferência
  5. Link de compartilhamento construído: https://rocketshare.app/d/{id}#{base64url-key}

Armazenamento

  • Arquivos criptografados são armazenados em armazenamento de objetos compatível com S3 hospedado na UE (Amsterdã)
  • Arquivos são armazenados como blobs criptografados opacos — o provedor de armazenamento não pode lê-los
  • Metadados são armazenados em PostgreSQL com criptografia em repouso no volume do banco de dados

Download

  1. Destinatário abre o link de compartilhamento
  2. Navegador extrai a chave do fragmento da URL (nunca enviado ao servidor)
  3. Blob criptografado é baixado do servidor
  4. Descriptografia acontece inteiramente no navegador do destinatário
  5. Arquivo em texto simples é apresentado ao usuário para download

Expiração e exclusão

  • Transferências têm uma expiração configurável (3 dias a 90 dias, dependendo do plano)
  • Após a expiração, uma tarefa de limpeza agendada exclui permanentemente os blobs criptografados do armazenamento de objetos e os registros de arquivo do banco de dados
  • O registro de metadados da transferência (nomes de arquivos, tamanhos, carimbos de data/hora) é retido em um estado expirado para fins de contabilidade e auditoria, mas todos os dados de arquivo criptografados são removidos de forma irreversível
  • Nenhum backup é mantido de dados de arquivo expirados

6. Infraestrutura

Hospedagem

  • Aplicação: implantada em Cloudflare Workers (computação na borda)
  • Banco de dados: PostgreSQL, hospedado na UE
  • Armazenamento de objetos: compatível com S3, região UE (Amsterdã)
  • Cache: Cloudflare KV (armazenamento chave-valor), apenas para dados de sessão e limitação de taxa — nunca usado para conteúdo de arquivo
  • CDN: rede global Cloudflare para ativos estáticos e roteamento de borda

Residência de dados

Todos os servidores de armazenamento de arquivos e banco de dados estão localizados dentro da União Europeia. Não replicamos dados de arquivo fora da UE.

Segurança de rede

  • TLS 1.3 aplicado em todas as conexões (HTTP e banco de dados)
  • HSTS com pré-carregamento — navegadores são instruídos a sempre usar HTTPS
  • Cabeçalhos de segurança HTTP — CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
  • Sem conteúdo misto — todos os recursos carregados via HTTPS

7. Autenticação e controle de acesso

Autenticação de usuário

  • E-mail/senha — senhas com hash usando scrypt (N=16384, r=16, p=1), comprimento mínimo de 8 caracteres aplicado
  • OAuth — SSO do Google e Microsoft via OAuth 2.0 / OpenID Connect padrão da indústria
  • Gerenciamento de sessão — cookies HTTP-only seguros com atributos SameSite adequados

Controles de acesso à transferência

  • Acesso baseado em link — qualquer pessoa com o link de compartilhamento completo pode descriptografar (a chave está na URL)
  • Proteção por senha opcional — transferências podem exigir uma senha adicional; o hash da senha é verificado no lado do servidor antes de entregar o blob criptografado
  • Limites de download — número máximo configurável de downloads antes que o link seja desativado
  • Expiração — expiração automática baseada em tempo, após a qual os dados de arquivo criptografados são excluídos permanentemente

8. Minimização e retenção de dados

Princípio de menos dados

Coletamos apenas o necessário para operar o serviço:

  • Dados da conta: endereço de e-mail, nome (se fornecido via OAuth), senha com hash
  • Metadados da transferência: nomes de arquivos, tamanhos, tipos MIME, carimbos de data/hora, datas de expiração
  • Dados de uso: contagens de transferência e armazenamento usado (para aplicação do plano)
  • Análises: padrões de uso anonimizados via PostHog (hospedado na UE, configuração focada em privacidade)

O que não coletamos

  • Conteúdo dos arquivos (não podemos acessar blobs criptografados)
  • Chaves de criptografia
  • Endereços IP em armazenamento de longo prazo (logs de acesso são efêmeros)
  • Histórico de navegação ou dados de rastreamento entre sites

Retenção

  • Transferências: dados de arquivo criptografados excluídos automaticamente na expiração; metadados da transferência retidos em estado expirado
  • Dados da conta: retidos enquanto a conta está ativa; excluídos mediante solicitação de exclusão de conta
  • Logs de acesso: efêmeros, não persistidos além do ciclo de vida da requisição

9. Resposta a incidentes

No caso de um incidente de segurança:

  1. Contenção — isolar sistemas afetados imediatamente
  2. Avaliação — determinar escopo e impacto; graças à arquitetura de conhecimento zero, uma violação do servidor não expõe o conteúdo dos arquivos
  3. Notificação — usuários afetados são notificados dentro de 72 horas, conforme exigido pelo GDPR
  4. Remediação — corrigir causa raiz, melhorar defesas
  5. Divulgação — divulgação pública do incidente e nossa resposta

Questões de segurança podem ser relatadas a nós por meio de nossa política de Divulgação Responsável.

10. Limitações e transparência

Acreditamos em ser transparentes sobre o que nossa arquitetura de segurança protege e não protege:

  • Não podemos recuperar links perdidos — se um usuário perder o link de compartilhamento (incluindo o fragmento da URL), os arquivos criptografados não podem ser descriptografados. Não temos a chave.
  • A segurança do link é responsabilidade do usuário — o link de compartilhamento é a única credencial de acesso. Se for interceptado (por exemplo, enviado por um canal inseguro), o interceptador pode descriptografar os arquivos.
  • CSP com política de script baseada em nonce — usamos Content Security Policy com strict-dynamic e fontes de script baseadas em nonce, que é a abordagem recomendada para aplicações SSR. Estilos inline ainda requerem unsafe-inline devido ao Tailwind CSS.
  • Confiança no navegador — nossa criptografia depende da Web Crypto API. Se o navegador estiver comprometido, todas as apostas estão canceladas.
  • Visibilidade de metadados — embora o conteúdo dos arquivos seja criptografado, nomes de arquivos, tamanhos e carimbos de data/hora são visíveis ao servidor para fins operacionais.

Este whitepaper está atualizado a partir de fevereiro de 2026. Atualizamos este documento quando nossa arquitetura de segurança muda. Para perguntas, entre em contato conosco.