O que é cifração de conhecimento zero? Guia simples
Cifração de conhecimento zero significa que o fornecedor não pode aceder aos seus dados.
A cifração de conhecimento zero é uma arquitetura limitada pelo fornecedor, na qual o serviço não detém a chave necessária para decifrar o conteúdo armazenado do utilizador. Ao contrário da cifração padrão na nuvem, em que o fornecedor controla a chave de conteúdo, a cifração do lado do cliente pode manter essa capacidade nos dispositivos dos utilizadores. Um pedido legal, uma violação ou uma ameaça interna podem ainda expor texto cifrado, registos de conta, dados de tráfego ou outros metadados que o fornecedor guarda. As orientações do NIST sobre gestão de chaves tornam a custódia das chaves central para o acesso, mas a aplicação cliente, o sistema operativo e o dispositivo desbloqueado continuam a fazer parte do limite de confiança.
Como funciona a cifração de conhecimento zero
A analogia mais simples: um cofre de hotel onde só o hóspede define a combinação e o hotel nunca a fica a saber. Se se esquecer da combinação, o hotel não abre o cofre por si. Isso não é uma falha de design. É o objetivo do design.
Em termos técnicos, a cifração de conhecimento zero funciona em três passos:
Derivação de chave no dispositivo. O utilizador fornece uma credencial, como uma palavra-passe, uma frase secreta ou um padrão. Uma função de derivação de chaves baseada em palavra-passe combina-a com um salt para produzir uma chave no dispositivo do utilizador. Um design bem separado pode usar essa chave para desbloquear uma chave aleatória de cifração de conteúdo, em vez de cifrar cada ficheiro diretamente com a credencial humana.
Cifração antes da transmissão. Todos os dados são cifrados no dispositivo com a chave derivada antes de saírem do dispositivo para armazenamento na nuvem ou cópia de segurança. O resultado cifrado (texto cifrado) é o que é carregado.
O fornecedor não recebe nenhuma chave de conteúdo em texto simples. As chaves de conteúdo existem necessariamente na memória do cliente durante a utilização e também podem ser guardadas local ou remotamente dentro de envelopes cifrados autenticados. O fornecedor pode guardar texto cifrado e chaves envolvidas sem deter o segredo do utilizador necessário para as abrir. Os metadados de conta, tráfego, tamanho dos registos e tempo podem continuar visíveis.
A restrição crítica: se o utilizador perder todas as credenciais e caminhos de recuperação válidos, o conteúdo cifrado torna-se inacessível. A recuperação pode continuar a existir, mas a custódia da respetiva chave deve ser explicada. Se uma simples reposição por e-mail restaurar o conteúdo legível sem a aprovação de um dispositivo antigo, uma frase de recuperação, uma chave de recuperação ou um segredo equivalente na posse do utilizador, o fornecedor manteve uma via eficaz de regresso ao texto simples.
Cifração de conhecimento zero vs. outros tipos de cifração
O termo "cifração" aparece nos materiais de marketing de quase todos os serviços na nuvem. As diferenças entre tipos são significativas.
| Tipo | Quem detém a chave | O fornecedor pode ler os dados | Sobrevive a uma violação do fornecedor | Exemplo |
|---|---|---|---|---|
| Sem cifração | Nenhum | Sim | Não | Dropbox (nível padrão) |
| Cifração em trânsito (TLS) | Fornecedor | Sim (em repouso nos servidores) | Não | Google Fotos |
| Cifração em repouso no servidor | Fornecedor | Sim (detém a chave de decifração) | Parcialmente (depende do âmbito da violação) | iCloud (padrão) |
| Cifração ponta a ponta da plataforma | Dispositivos clientes e sistema de recuperação de conta | Não através do caminho de serviço normal | Depende do cliente, da recuperação e da exposição de metadados | iCloud com proteção avançada de dados |
| Cifração do lado do cliente, cega para o fornecedor | Caminho de recuperação controlado pelo cliente e pelo utilizador | Nenhuma chave de conteúdo em texto simples na posse do fornecedor | O conteúdo pode continuar cifrado; metadados e texto cifrado podem ainda ser expostos | Cofre cifrado e sistemas de cópia de segurança |
A distinção entre "cifração em repouso" e "cifração de conhecimento zero" é a mais confundida com frequência. Com cifração em repouso, o fornecedor cifra os seus dados nos seus servidores usando chaves que controla. Isso protege contra roubo físico do hardware do servidor. Não protege contra o fornecedor ler os seus dados, intimações governamentais para dados e chaves, ou ameaças internas. O fornecedor tem capacidade de decifração.
Com a cifração do lado do cliente cega para o fornecedor, o serviço não recebe a chave de conteúdo em texto simples através do protocolo documentado. O texto cifrado armazenado pode continuar opaco para esse fornecedor, enquanto o software cliente, o caminho de recuperação, os metadados da conta e o canal de distribuição de software continuam a exigir confiança e revisão.
Por que a cifração de conhecimento zero importa
As violações de dados afetam milhares de milhões de registos todos os anos
O Identity Theft Resource Center registou 3.205 comprometimentos de dados nos Estados Unidos em 2023, que afetaram aproximadamente 353 milhões de pessoas. Quando um fornecedor detém as chaves de conteúdo, uma violação pode expor os dados armazenados e um caminho para os decifrar. A cifração cega para o fornecedor separa esses ativos: uma violação do servidor pode ainda expor texto cifrado e metadados, mas não uma chave de conteúdo em texto simples na posse do fornecedor. A adivinhação de credenciais e o comprometimento do cliente continuam a ser riscos separados.
A coação legal é uma ameaça real
Os fornecedores podem ser obrigados a divulgar os dados que guardam. Um design cego para o fornecedor pode limitar essa resposta ao texto cifrado e aos metadados de conta, tráfego, faturação ou serviço disponíveis, porque o fornecedor não possui a chave de conteúdo em texto simples. Saber se outra parte consegue obter uma credencial do utilizador, explorar um cliente ou forçar a divulgação é uma questão separada. A Apple introduziu a Proteção Avançada de Dados no iOS 16.2 como uma extensão opcional da cifração ponta a ponta aos dados do iCloud.
"Confie em nós" não é uma arquitetura de segurança
A cifração do lado do servidor depende de chaves e políticas controladas pelo fornecedor. A cifração cega para o fornecedor altera a custódia da chave, de modo que o caminho de serviço documentado não possui uma chave de conteúdo em texto simples. É um limite arquitetónico mais forte, mas a sua solidez depende ainda de código cliente correto, de distribuição de software autenticada, de uma recuperação bem concebida, de dispositivos seguros e de uma implementação que corresponda à especificação.
A norma NIST por detrás da cifração
O AES-GCM foi normalizado pelo National Institute of Standards and Technology na SP800-38D (2007). O próprio AES foi selecionado pelo NIST através de um concurso público em 2001. O "256" em AES-256 refere-se a uma chave de 256 bits. A pesquisa exaustiva sobre uma chave uniformemente aleatória é computacionalmente inviável, mas uma palavra-passe ou um padrão humano pode fornecer muito menos entropia, mesmo quando uma função de derivação de chaves produz 256 bits.
GCM (Galois/Counter Mode) acrescenta cifração autenticada, o que significa que o processo de decifração revela qualquer adulteração do texto cifrado. Se um único bit dos dados cifrados for alterado, a decifração falha em vez de produzir um resultado corrompido. Isso impede os atacantes de manipularem dados cifrados sem deteção.
O PBKDF2 (Password-Based Key Derivation Function 2, função de derivação de chaves baseada em palavra-passe), especificado no RFC 8018, converte uma credencial fornecida por uma pessoa em material de chave de comprimento fixo através de chamadas repetidas a uma função pseudoaleatória. Mais iterações aumentam o custo de cada tentativa. Não acrescentam entropia a um padrão ou a uma palavra-passe previsível, por isso a escolha da credencial e a verificação offline continuam a ser importantes.
Como o Vaultaire implementa a separação entre fornecedor e chave
O Vaultaire é um cofre com cifração do lado do cliente para iPhone. Em linguagem de produto, é muitas vezes apresentado como de “conhecimento zero”, mas a sua afirmação documentada mais restrita é que a Wraxle não recebe o conteúdo do cofre em texto simples nem as chaves necessárias para o decifrar. Veja como funcionam a implementação e os limites de confiança restantes em cada camada.
Derivação de chave. O utilizador desenha um padrão numa grelha 5x5 de 25 pontos. O PBKDF2-HMAC-SHA512 combina essa sequência com um salt do dispositivo guardado no Keychain, ao longo de 600.000 iterações, para derivar uma chave de cofre de 256 bits. A chave do cofre autentica o índice cifrado e envolve uma chave mestra aleatória separada de 256 bits. As informações de recuperação, incluindo o padrão, ficam guardadas numa base de dados do Keychain cifrada com AES-GCM, e não em ficheiros de texto simples ou numa conta Vaultaire.
Cifração de ficheiros. Cada ficheiro importado é cifrado com AES-256-GCM sob a chave mestra aleatória. O CryptoKit cria caixas seladas autenticadas com nonces novos, e o formato de streaming deriva um nonce distinto para cada bloco ordenado.
Cifração de metadados. Nomes de ficheiros, tipos MIME, datas, registos de índice e dados de miniaturas também são protegidos com AES-256-GCM. O Vaultaire não usa ChaCha20 para os metadados do cofre.
Gestão de chaves. O Vaultaire guarda a base de dados de recuperação cifrada e o salt do dispositivo como itens normais de palavra-passe genérica do Keychain do iOS, protegidos com a classe de acessibilidade WhenUnlockedThisDeviceOnly. As chaves de cofre derivadas do padrão e as chaves mestras aleatórias são processadas na memória da aplicação através do CryptoKit. O bloqueio elimina o estado das chaves ativas, mas o Swift e o iOS não garantem que todas as cópias transitórias sejam substituídas.
Descoberta do cofre. A interface normal não mostra uma lista de cofres. As páginas de todos os cofres ficam numa pasta partilhada com nomes aleatórios, por isso os nomes dos ficheiros não mostram a que cofre pertence cada ficheiro e não revelam padrões, nomes ou conteúdos em texto simples. Alguém com acesso ao contentor da aplicação consegue, ainda assim, estimar quantos cofres tem, porque o número de arenas de armazenamento o limita. Veja a arquitetura de segurança completa e a explicação da cifração por padrão.
Como saber se uma aplicação usa mesmo cifração de conhecimento zero
Comece com três testes rápidos e depois verifique a arquitetura publicada:
O teste da palavra-passe esquecida. Se uma reposição por e-mail, por si só, restaurar dados legíveis, pergunte que mecanismo na posse do fornecedor recuperou a chave de conteúdo efetiva. Frases de recuperação na posse do utilizador, aprovação por dispositivos antigos e reposições controladas pelo fornecedor são designs diferentes.
O teste do novo dispositivo. Se um novo dispositivo restaurar conteúdo legível, identifique o segredo ou o dispositivo de confiança que o autorizou. O início de sessão na conta, por si só, sugere um caminho de recuperação controlado pelo fornecedor; uma frase de recuperação mais registos de cópia de segurança cifrados podem preservar a separação entre fornecedor e chave.
O teste da conta. Um endereço de e-mail ou número de telefone liga a identidade aos metadados do serviço, mas por si só não prova que o fornecedor consegue decifrar o conteúdo. Inspecione a hierarquia de chaves, o design de recuperação, o código do cliente ou a auditoria, a política de metadados e se o texto cifrado autenticado permite verificações de credenciais offline.
Estes testes são filtros, não uma prova de segurança. Uma especificação coerente deve nomear a chave de conteúdo, a chave de desbloqueio, os salts, os parâmetros de derivação, o formato de cifração autenticada, as regras de nonce, os envelopes de recuperação, o armazenamento local de segredos, os metadados na nuvem e o ponto onde existem chaves em texto simples. Uma revisão independente é uma prova mais forte do que o rótulo de um produto.
Perguntas frequentes
Cifração de conhecimento zero é o mesmo que cifração ponta a ponta?
Sobrepõem-se, mas não são idênticas. Cifração ponta a ponta (E2EE) significa que os dados são cifrados no dispositivo do remetente e só decifrados no dispositivo do destinatário. Cifração de conhecimento zero significa que o fornecedor não pode aceder aos dados. Um serviço pode ter E2EE sem ser de conhecimento zero se o fornecedor gerou ou acedeu às chaves em algum momento. Conhecimento zero é o padrão mais rigoroso.
O que acontece se perder a palavra-passe com cifração de conhecimento zero?
Os seus dados ficarão permanentemente inacessíveis se todas as credenciais válidas e envelopes de recuperação forem perdidos. Uma reposição ou chave mestra controlada pelo fornecedor enfraqueceria os limites do fornecedor, por isso a recuperação deve ser concebida em separado. O Vaultaire gera uma frase personalizada com 9 palavras separadas, cuja chave de recuperação derivada abre um envelope cifrado com a chave do cofre. A frase não regenera nem codifica a chave, e o restauro num novo dispositivo também requer os registos CloudKit cifrados correspondentes.
A polícia pode aceder a dados cifrados com conhecimento zero?
Um fornecedor pode ter de divulgar o texto cifrado armazenado e os metadados de conta, tráfego, faturação ou serviço que guarda. Sem uma chave de conteúdo em texto simples na posse do fornecedor, esse fornecedor não pode usar o seu caminho de serviço normal para decifrar o conteúdo. A exploração de dispositivos, a descoberta de credenciais, as cópias de recuperação e a divulgação forçada são vias separadas, cuja legalidade e eficácia variam consoante a jurisdição e os factos.
A cifração de conhecimento zero é mais lenta que a cifração normal?
O desempenho do AES-256-GCM não depende de quem detém a chave. A derivação baseada em palavra-passe acrescenta trabalho durante o desbloqueio, e a sua duração depende do algoritmo, do número de iterações, do dispositivo e da implementação. As aplicações devem medir esse custo no hardware suportado e equilibrar a rapidez de resposta com o custo imposto a cada tentativa offline.
Conhecimento zero significa que a aplicação não recolhe dados?
Não necessariamente. O termo aborda o limite da chave de conteúdo do fornecedor, e não todo o fluxo de dados. Uma aplicação pode ainda processar dados de conta, análises, relatórios de falhas, endereços IP, tamanhos de registos, tempo ou outros metadados de serviço. O Vaultaire não requer uma conta de identidade. A análise da aplicação e o diagnóstico de avarias estão ativados por defeito e podem ser desativados com “Partilhar erros anonimamente” em Definições. A política de eventos documentada exclui conteúdos, padrões, frases e chaves de desencriptação do cofre; a política de privacidade descreve as regras atuais de recolha e retenção.
Como difere a cifração de conhecimento zero da Proteção de Dados Avançada da Apple?
A Proteção Avançada de Dados (ADP) da Apple, introduzida no iOS 16.2, estende a cifração ponta a ponta a mais categorias do iCloud e usa o modelo de recuperação da conta Apple. O Vaultaire mantém o conteúdo do cofre local por predefinição e não requer nenhuma conta de identidade do Vaultaire; a cópia de segurança, ativada por predefinição, e a sincronização e a partilha opcionais usam registos CloudKit com cifração do lado do cliente na conta Apple do utilizador. O Vaultaire também oferece acesso a cofres separados por padrões e um modo de coação (Pro), com os limites de armazenamento e recuperação descritos na respetiva documentação de negação plausível.
Resumo
A cifração de conhecimento zero é mais bem entendida como uma afirmação de separação entre o fornecedor e a chave: o serviço não detém a chave em texto simples necessária para decifrar o conteúdo armazenado. Isso é mais forte do que a cifração do lado do servidor com chaves controladas pelo fornecedor, mas não significa que as chaves existam apenas na memória, que os metadados desapareçam ou que todos os comprometimentos de clientes e dispositivos fiquem anulados. Avalie o produto pela sua hierarquia de chaves, design de recuperação, implementação e revisão independente.