Criptografia do lado do servidor vs. do lado do cliente: em qual modelo você deve confiar?

A criptografia do lado do servidor criptografa os dados no servidor depois de receber o texto puro, o que exige confiar no provedor do serviço. A criptografia do lado do cliente criptografa os dados no seu navegador antes de enviá-los, de modo que o servidor nunca vê o texto puro. Para compartilhar segredos, a criptografia do lado do cliente é mais segura porque elimina o serviço como ponto de confiança: até mesmo um servidor comprometido não consegue ler seus dados.

Este post compara as duas abordagens: como elas funcionam, o que cada uma pede que você confie e onde estão as verdadeiras compensações. Não é um argumento a favor de um dos lados: é uma estrutura para avaliar qual modelo se ajusta ao seu modelo de ameaças.

Para um resumo rápido de por que a criptografia do lado do cliente importa, veja nosso post anterior. Para uma análise detalhada da implementação específica do Vaulted, veja nossa análise aprofundada sobre conhecimento zero.

Como funciona a criptografia do lado do servidor

No modelo do lado do servidor, o serviço cuida da criptografia em seu nome. O fluxo típico:

Você digita um segredo no navegador
Seu navegador envia o texto puro ao servidor por TLS
O servidor criptografa os dados usando uma chave que ele gerencia
O texto cifrado é armazenado no banco de dados
Quando o destinatário solicita o segredo, o servidor o descriptografa e retorna o texto puro

A chave de criptografia nunca sai do servidor. Ela pode residir em um módulo de segurança de hardware (HSM), em um serviço de gerenciamento de chaves na nuvem (KMS) ou em um arquivo de configuração, mas o servidor a controla por completo.

O modelo de confiança do lado do servidor

Com a criptografia do lado do servidor, você está confiando em:

O operador do serviço para que não leia seus dados (ele tem a chave e o texto puro na memória durante a criptografia/descriptografia)
A infraestrutura para que não seja violada (um servidor comprometido expõe tanto as chaves quanto os dados)
Os funcionários do operador para que não abusem do acesso (qualquer pessoa com acesso ao servidor pode, potencialmente, ler segredos)
A jurisdição legal para que não obrigue a divulgação (o operador pode ser forçado a entregar os dados porque possui as chaves)
Os logs e o monitoramento do servidor para que não capturem texto puro (frameworks de log podem registrar dados sensíveis de forma inadvertida)

Este não é necessariamente um modelo ruim. Muitos serviços o usam com sucesso: o armazenamento na nuvem, os provedores de e-mail e os serviços de banco de dados se apoiam na criptografia do lado do servidor. A questão é se a compensação se ajusta ao seu caso de uso.

Como funciona a criptografia do lado do cliente

No modelo do lado do cliente, a criptografia acontece no navegador antes que qualquer dado chegue ao servidor. O fluxo é diferente:

Você digita um segredo no navegador
O navegador gera uma chave de criptografia e criptografa os dados localmente
Apenas o texto cifrado é enviado ao servidor
A chave de criptografia é entregue ao destinatário por um canal separado (normalmente o fragmento da URL)
O navegador do destinatário descriptografa o texto cifrado localmente

O servidor nunca vê o texto puro e nunca possui a chave de criptografia. Ele armazena e recupera blocos cifrados, nada mais.

O Vaulted usa esse modelo. Cada segredo recebe uma chave AES-256-GCM nova. A chave é colocada no fragmento da URL (#), que os navegadores nunca incluem nas requisições HTTP, conforme a RFC 3986. O servidor recebe o texto cifrado e um IV aleatório de 12 bytes para armazenamento, mas a chave permanece inteiramente no link compartilhado entre o remetente e o destinatário.

O modelo de confiança do lado do cliente

Com a criptografia do lado do cliente, você está confiando em:

O navegador para que implemente a criptografia corretamente (a Web Crypto API delega a motores criptográficos nativos como BoringSSL ou NSS)
O código da aplicação para que realmente realize a criptografia do lado do cliente (você pode verificar isso inspecionando as requisições de rede)
O canal de entrega do link para que seja seguro (qualquer pessoa que tenha a URL completa, incluindo o fragmento, pode descriptografar o segredo)
O dispositivo do destinatário para que não esteja comprometido (após a descriptografia, malware ou captura de tela podem acessar o texto puro)

Você não está confiando no servidor, no operador do serviço, em seus funcionários nem em sua jurisdição legal. O servidor é um relé de armazenamento para dados cifrados que ele não consegue ler.

Comparando as compensações

Nenhum modelo é universalmente melhor. Cada um faz compensações diferentes entre segurança, usabilidade e riqueza de recursos.

Propriedades de segurança

Propriedade	Lado do servidor	Lado do cliente
Exposição em uma violação do servidor	Chaves + texto cifrado expostos	Apenas o texto cifrado exposto (inútil sem as chaves)
O operador pode ler os dados	Sim (possui as chaves)	Não (nunca tem as chaves)
Risco de coação legal	O operador pode cumprir (tem acesso)	O operador não pode cumprir (não tem acesso)
Risco de interceptação do link	Não se aplica (sem chave no link)	URL completa = acesso completo (mitigado pela frase-senha)
Ataque man-in-the-middle	O TLS protege o trânsito; o servidor vê o texto puro	O TLS protege o texto cifrado; a chave no fragmento nunca é enviada

Propriedades de usabilidade

Propriedade	Lado do servidor	Lado do cliente
Carga de gerenciamento de chaves	Nenhuma para o usuário (o servidor cuida disso)	O usuário deve compartilhar o link de forma segura
Recuperação de senha	Possível (o servidor possui as chaves)	Não é possível (as chaves só estão no link)
Busca e indexação	O servidor pode buscar o texto puro	Não é possível sem descriptografar
Flexibilidade para compartilhar	O servidor pode recriptografar para novos destinatários	Requer um link novo por destinatário
Acesso offline	Requer conexão com o servidor para descriptografar	Possível se o texto cifrado e a chave estiverem armazenados localmente

Compensações de recursos

Recurso	Lado do servidor	Lado do cliente
Registro de auditoria do conteúdo	Possível	Não é possível (o servidor não consegue ler o conteúdo)
Políticas baseadas no conteúdo	Possível (DLP, varredura de conformidade)	Não é possível sem descriptografar
Rotação de chaves	O servidor pode recriptografar com chaves novas	Requer regerar e recompartilhar os links
Controle de acesso multipartes	O servidor pode gerenciar chaves por usuário	Cada destinatário precisa da chave diretamente
Garantia de conhecimento zero	Não	Sim

Quando a criptografia do lado do servidor é aceitável

A criptografia do lado do servidor é uma escolha razoável quando:

Você confia no operador do serviço e em suas práticas de segurança
Você precisa de recursos que exigem acesso do servidor aos dados (busca, compartilhamento, varredura de conformidade)
A sensibilidade dos dados não justifica o custo de usabilidade da criptografia do lado do cliente
Você opera em um ambiente regulado onde as certificações de conformidade do operador importam mais do que as garantias de conhecimento zero
A complexidade do gerenciamento de chaves precisa ser tratada pelo serviço, e não pelo usuário

Os serviços de armazenamento na nuvem, o e-mail corporativo e a criptografia de bancos de dados gerenciados usam esse modelo de forma eficaz.

Quando a criptografia do lado do cliente é necessária

A criptografia do lado do cliente se torna necessária quando:

Você não pode ou não deveria confiar seus dados ao operador do serviço
Os dados são sensíveis o suficiente para que uma violação do servidor não possa expor o texto puro
Você precisa de uma garantia de conhecimento zero: uma prova matemática de que o servidor não consegue ler seus dados
Requisitos legais ou de conformidade exigem que o operador do serviço não tenha acesso ao conteúdo
Você quer proteção contra ameaças internas no provedor do serviço

Compartilhar segredos é um dos casos de uso mais sólidos para a criptografia do lado do cliente. Os dados são inerentemente sensíveis (senhas, chaves de API, credenciais), o compartilhamento é transitório (com limite de visualizações e limite de tempo) e a relação de confiança é mínima (você pode não conhecer nem confiar no operador do serviço).

Como o Vaulted aborda isso

O Vaulted usa exclusivamente a criptografia do lado do cliente. Cada segredo é criptografado no navegador com uma chave AES-GCM nova antes que qualquer dado chegue ao servidor. A chave viaja apenas no fragmento da URL, e a proteção opcional com frase-senha adiciona uma segunda camada por meio da derivação de chave PBKDF2 e do encapsulamento de chave AES-KW.

O servidor armazena o texto cifrado com um tempo de vida e um contador de visualizações. Ele não consegue descriptografar, buscar nem inspecionar o conteúdo. Uma violação completa do banco de dados produz apenas blocos cifrados, computacionalmente inúteis sem as chaves que existem unicamente nos links compartilhados.

Para os detalhes criptográficos completos — geração de chaves, manipulação do IV, encapsulamento com frase-senha e as chamadas exatas à Web Crypto API —, veja nossa análise aprofundada da criptografia de conhecimento zero.

Como tomar sua decisão

O modelo de criptografia adequado depende do que você está protegendo e em quem você está disposto a confiar.

Se você precisa de recursos como busca, recuperação ou gerenciamento centralizado de chaves, a criptografia do lado do servidor é a escolha prática. Se você precisa de uma garantia de que ninguém — nem o serviço, nem seus funcionários, nem uma ordem judicial — consiga ler seus dados, a criptografia do lado do cliente é o único modelo que a oferece.

Para compartilhar segredos, a resposta é simples: os dados são sensíveis, a interação é breve e, quanto menos partes puderem acessar o texto puro, melhor.

Pronto para compartilhar um segredo com criptografia de conhecimento zero? Crie um segredo no Vaulted: seus dados nunca saem do seu navegador sem criptografia.

Relacionados

Por que a criptografia do lado do cliente importa: o argumento a favor de criptografar no navegador
Criptografia de conhecimento zero: como o Vaulted mantém seus segredos privados: análise aprofundada da implementação criptográfica
Segurança no Vaulted: resumo do nosso modelo de segurança