Arquitetura de conhecimento zero: o servidor não vê os seus ficheiros

A arquitetura de conhecimento zero significa que o fornecedor do serviço não tem capacidade técnica de ler os seus ficheiros — as chaves de encriptação nunca chegam aos seus servidores, e não existe chave mestra, porta traseira, nem qualquer "confie em nós" necessário. O seu navegador encripta os ficheiros com AES-256-GCM antes do carregamento usando uma chave gerada localmente, e essa chave chega ao destinatário apenas através do fragmento de URL após o #, que os navegadores nunca transmitem aos servidores. Mesmo perante um mandado válido, o fornecedor só consegue produzir texto cifrado. Este é o modelo usado pelo Tresorit, pelo Proton, pelo SwissTransfer e pelo HexaTransfer, e é matematicamente diferente de "encriptado em repouso".

A prova está no que o servidor consegue produzir

O teste mais claro de conhecimento zero: o que é que a empresa poderia entregar se fosse obrigada? No armazenamento na nuvem tradicional (Google Drive, Dropbox, OneDrive), a resposta é: os seus ficheiros, em texto simples. O relatório de transparência de 2023 do Google mostra que cumpriram 83% dos pedidos de dados do governo norte-americano, produzindo conteúdo de utilizadores quando legalmente obrigados. Não é uma falha de segurança do Google — é assim que a arquitetura funciona.

Com conhecimento zero, a empresa pode produzir:

Blobs de ficheiros encriptados (inúteis sem a chave)
Metadados de conta (e-mail, IP de registo)
Endereços IP de carregamento e descarregamento, timestamps
Informações de pagamento, se aplicável

Não consegue produzir nomes de ficheiros, conteúdo, identidade do destinatário, nem chaves de desencriptação. Não porque recuse — porque simplesmente não os tem.

O truque do fragmento de URL, explicado com precisão

O movimento técnico central é usar o fragmento do URL como canal secreto para a chave. Quando um navegador pede https://hexatransfer.com/d/xyz789#k=BASE64KEY, envia apenas GET /d/xyz789 ao servidor. O fragmento permanece na barra de endereços do navegador. O JavaScript lê então window.location.hash para obter a chave e passa-a para crypto.subtle.decrypt().

Esta abordagem foi pioneiramente implementada pelo Mega.nz por volta de 2013 e aperfeiçoada pelo Firefox Send antes de a Mozilla o encerrar em 2020. O padrão é agora normalizado. Os registos do lado do servidor, incluindo os registos de acesso do nginx ou do Caddy, nunca capturam o fragmento porque o RFC 3986 do HTTP o define como sendo apenas do lado do cliente.

Um fornecedor poderia teoricamente registar o fragmento via JavaScript do lado do cliente, razão pela qual os serviços de conhecimento zero publicam o seu código de cliente para inspeção e frequentemente o disponibilizam como assets estáticos assinados servidos a partir de uma origem separada.

Por que isto difere de "encriptado em repouso"

Todos os fornecedores de nuvem encriptam os ficheiros em repouso — é o mínimo esperado e geralmente obrigatório para certificações SOC 2 Type II e ISO 27001. Mas "encriptado em repouso" com chaves detidas pelo fornecedor significa que a encriptação é invisível para atacantes com discos roubados e invisível para si no sentido em que o fornecedor desencripta automaticamente a pedido.

O conhecimento zero inverte a custódia das chaves: você detém a chave, o fornecedor detém o texto cifrado. O fornecedor nada ganha ao desencriptar porque não consegue. Isto é relevante em três ameaças específicas:

Funcionários desonestos. Um funcionário do fornecedor com acesso à base de dados vê apenas texto cifrado.
Pedidos governamentais. Os pedidos ao abrigo do Artigo 48.º do RGPD e do US CLOUD Act podem obrigar à divulgação, mas não se pode divulgar o que não se tem.
Violações de servidor. A violação do LastPass em 2021 expôs cofres encriptados; as palavras-passe mestras fracas foram de alguma forma quebradas, mas o design de conhecimento zero impediu a exposição massiva de texto simples.

O que está encriptado e o que são metadados

Uma implementação ingénua encripta o conteúdo dos ficheiros mas deixa visíveis os nomes, tamanhos e estrutura de pastas. O verdadeiro conhecimento zero encripta também o nome do ficheiro, tipicamente ao antepor um cabeçalho JSON como {"name": "Q4-financials.pdf", "type": "application/pdf"} aos bytes do ficheiro antes da encriptação AES-GCM.

Metadados difíceis de ocultar:

Tamanho do ficheiro — o comprimento do texto cifrado aproxima o comprimento do texto simples. O preenchimento para intervalos fixos (1 MB, 10 MB, 100 MB, 1 GB) obscurece isto mas desperdiça largura de banda.
Timing de carregamento — a correlação de timestamps com outros dados ainda pode revelar informação.
Endereços IP — o fornecedor vê quem carregou e quem descarregou. Combine com Tor ou uma VPN de confiança se isto for relevante.

O Proton e o Tresorit publicam matrizes detalhadas de exposição de metadados. O SwissTransfer e o HexaTransfer adotam uma abordagem mais simples: metadados mínimos, retenção curta (24 horas a 7 dias) e sem ligação a contas para transferências gratuitas.

O problema de autenticação

O conhecimento zero cria um desafio: se o servidor não consegue desencriptar os seus ficheiros, como autentica os utilizadores para evitar que estranhos descarreguem? Três padrões comuns:

Autenticação baseada em ligação. A posse do URL (e do fragmento) é a autorização. Usado pelo SwissTransfer, HexaTransfer e Tresorit Send. Simples, funciona sem contas.
Ligações protegidas por palavra-passe. O fragmento do URL contém um salt; a chave real é derivada com PBKDF2 a partir da palavra-passe. O servidor guarda um verificador (hash da chave) para rejeitar rapidamente as tentativas erradas.
Conhecimento zero ligado a conta. O Proton e o Tresorit derivam a sua chave mestra a partir da palavra-passe de início de sessão via Argon2id, usando-a depois para desbloquear as chaves por ficheiro armazenadas encriptadas no servidor.

Cada um tem compromissos. A autenticação baseada em ligação é a mais simples mas expõe a chave a quem obtiver o URL. A proteção por palavra-passe acrescenta um segundo fator. A ligação a conta requer confiar que o código do cliente não exfiltra a chave mestra.

Armadilhas de implementação que quebram o conhecimento zero

Algumas falhas do mundo real que vale a pena conhecer:

Pré-visualizações de ficheiros do lado do servidor. Se o fornecedor gera miniaturas ou extrai texto para pesquisa, precisa de texto simples. Os serviços de conhecimento zero não conseguem oferecer estas funcionalidades em conteúdo encriptado.
Resolução de conflitos de sincronização. Comparar o conteúdo de ficheiros entre dispositivos normalmente requer texto simples. O Syncthing e o Cryptomator tratam disto com diferenças do lado do cliente.
SDKs de análise. Scripts de terceiros do Google Analytics ou Segment podem ler window.location.hash no código do cliente. Os serviços de conhecimento zero ou hospedam as suas próprias análises ou bloqueiam o acesso ao fragmento.
Reposição de palavra-passe. Se o fornecedor consegue repor a palavra-passe e ainda dar acesso aos ficheiros antigos, tem de deter uma chave de recuperação — o que quebra o conhecimento zero. O Proton avisa explicitamente que a reposição da palavra-passe implica perder os dados encriptados.

Quem oferece realmente conhecimento zero

Uma lista curta de serviços com alegações credíveis de conhecimento zero, verificadas por auditorias de terceiros (Cure53, NCC Group, Trail of Bits):

Tresorit — suíço, SOC 2 Type II, sincronização de ficheiros e Tresorit Send com conhecimento zero.
Proton Drive — suíço, baseado no modelo criptográfico do Proton Mail.
SwissTransfer — nível gratuito com E2EE opcional, gerido pela Infomaniak.
Mega.nz — Nova Zelândia, whitepaper de criptografia publicado.
HexaTransfer — baseado em navegador, sem conta, até 10 GB por transferência.

Serviços que são encriptados mas não têm conhecimento zero: Google Drive, Dropbox, OneDrive, Box, iCloud (exceto o nível Advanced Data Protection), e o nível padrão do WeTransfer.

Colocar em prática

Antes de confiar a um serviço os seus ficheiros sensíveis, use esta lista de verificação:

A política de privacidade afirma que o fornecedor não consegue ler os seus ficheiros?
Existe um whitepaper de segurança publicado que nomeia o AES-256-GCM e a KDF?
O URL de partilha contém um fragmento (texto após o #)?
Existem relatórios de auditoria de terceiros dos últimos 24 meses?
O código do cliente é código aberto ou pelo menos auditável?

Quatro respostas afirmativas significam que encontrou um serviço de conhecimento zero. Três ou menos significa que o fornecedor consegue ver os seus ficheiros.

Experimente em hexatransfer.com — gratuito, sem conta, até 10 GB.