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 criptografia de conhecimento zero é uma arquitetura limitada pelo provedor na qual o serviço não contém a chave necessária para descriptografar o conteúdo armazenado do usuário. Ao contrário da criptografia padrão na nuvem, em que o provedor controla a chave de conteúdo, a criptografia do lado do cliente pode manter esse recurso nos dispositivos dos usuários. Uma solicitação legal, violação ou informação privilegiada ainda pode expor texto cifrado, registros de conta, dados de tráfego ou outros metadados que o provedor retém. A orientação de gerenciamento de chaves do NIST torna a custódia de chaves central para o acesso, mas o aplicativo cliente, o sistema operacional e o dispositivo desbloqueado permanecem parte do limite de confiança.
Como funciona a cifração de conhecimento zero
A analogia mais simples: um cofre de hotel onde só você 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 usuário fornece uma credencial, como senha, frase secreta ou padrão. Uma função de derivação de chave baseada em senha combina-a com um salt para produzir uma chave no dispositivo do usuário. Um design bem separado pode usar essa chave para desbloquear uma chave aleatória de criptografia de conteúdo em vez de criptografar cada arquivo 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 provedor não recebe nenhuma chave de conteúdo de texto simples. As chaves de conteúdo necessariamente existem na memória do cliente durante o uso e também podem ser armazenadas local ou remotamente dentro de envelopes criptografados autenticados. O provedor pode armazenar texto cifrado e chaves agrupadas sem manter o segredo do usuário necessário para abri-los. Os metadados de conta, tráfego, tamanho de registro e tempo ainda podem permanecer visíveis.
A restrição crítica: se o usuário perder todas as credenciais e caminhos de recuperação válidos, o conteúdo criptografado se tornará inacessível. A recuperação ainda pode existir, mas a sua custódia chave deve ser explicada. Se apenas uma redefinição de e-mail restaurar o conteúdo legível sem uma aprovação de dispositivo antigo, frase de recuperação, chave de recuperação ou segredo equivalente mantido pelo usuário, o provedor manteve uma rota eficaz de volta 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) |
| Criptografia 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 |
| Criptografia do lado do cliente cega ao provedor | Caminho de recuperação controlado pelo cliente e pelo usuário | Nenhuma chave de conteúdo de texto simples mantida pelo provedor | O conteúdo pode permanecer criptografado; metadados e texto cifrado ainda podem vazar | Cofre criptografado e sistemas de backup |
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 criptografia do lado do cliente cega ao provedor, o serviço não recebe a chave de conteúdo de texto simples por meio do protocolo documentado. O texto cifrado armazenado pode permanecer opaco para esse provedor, enquanto o software cliente, o caminho de recuperação, os metadados da conta e o canal de entrega de software ainda exigem 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 relatou 3.205 comprometimentos de dados nos Estados Unidos em 2023, afetando aproximadamente 353 milhões de indivíduos. Quando um provedor detém chaves de conteúdo, uma violação pode expor os dados armazenados e um caminho para descriptografá-los. A criptografia cega ao provedor separa esses ativos: uma violação do servidor ainda pode expor texto cifrado e metadados, mas não uma chave de conteúdo de texto simples mantida pelo provedor. A adivinhação de credenciais e o comprometimento do cliente permanecem riscos separados.
A coação legal é uma ameaça real
Os provedores podem ser obrigados a divulgar os dados que retêm. Um design cego ao provedor pode limitar essa resposta ao texto cifrado e aos metadados de conta, tráfego, cobrança ou serviço disponíveis, porque o provedor não possui a chave de conteúdo de texto simples. Se outra parte pode obter uma credencial de usuário, explorar um cliente ou obrigar a divulgação é uma questão separada. A Apple introduziu a Proteção Avançada de Dados em iOS 16.2 como uma expansão opcional da criptografia ponta a ponta para iCloud dados.
"Confie em nós" não é uma arquitetura de segurança
A criptografia do lado do servidor depende de chaves e políticas controladas pelo provedor. A criptografia cega ao provedor altera a custódia da chave, de modo que o caminho de serviço documentado não possui uma chave de conteúdo de texto simples. Esse é um limite arquitetônico mais forte, mas sua força ainda depende do código do cliente correto, da entrega de software autenticado, da recuperação de som, dos dispositivos seguros e de uma implementação que corresponda à especificação.
O padrão NIST por detrás da criptografia
AES-GCM foi padronizado pelo Instituto Nacional de Padrões e Tecnologia em SP800-38D (2007). A própria AES foi selecionada pelo NIST por meio de 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 senha ou padrão humano pode fornecer muito menos entropia, mesmo quando uma função de derivação de chave 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.
PBKDF2 (Função 2 de derivação de chave baseada em senha), especificada em RFC 8018, converte uma credencial fornecida por humanos em material de chave de comprimento fixo por meio de chamadas repetidas de função pseudoaleatória. Mais iterações aumentam o custo de cada estimativa. Eles não adicionam entropia a um padrão ou senha previsível, portanto, a escolha de credenciais e a verificação offline ainda são importantes.
Como o Vaultaire implementa a separação entre provedor e chave
Cofre é um cofre criptografado do lado do cliente para iPhone. No sentido do produto, muitas vezes comercializado como “conhecimento zero”, sua afirmação documentada mais restrita é que o Wraxle não recebe o conteúdo do cofre em texto simples ou as chaves necessárias para descriptografá-lo. Veja como a implementação e os limites de confiança restantes funcionam em cada camada.
Derivação de chave. O usuário desenha um padrão em uma grade 5x5 de 25 pontos. PBKDF2-HMAC-SHA512 combina essa sequência com um dispositivo em todo o dispositivo Keychain salt para 600.000 iterações para derivar uma chave de cofre de 256 bits. A chave do cofre autentica o índice criptografado e agrupa uma chave mestra aleatória separada de 256 bits. As informações de recuperação, incluindo o padrão, são armazenadas em um AES-GCM criptografado Keychain banco de dados em vez de arquivos de texto simples ou uma conta Vaultaire.
Criptografia de arquivos. Cada arquivo importado é criptografado com AES-256-GCM sob a chave mestra aleatória. CryptoKit cria caixas seladas autenticadas com novos nonces, e o formato de streaming deriva um nonce distinto para cada pedaço ordenado.
Criptografia de metadados. Nomes de arquivos, MIME tipos, datas, registros de índice e dados de miniatura também são protegidos com AES-256-GCM. Vaultaire não usa ChaCha20 para metadados do vault.
Gerenciamento de chaves. Vaultaire armazena seu banco de dados de recuperação criptografado e salt do dispositivo normalmente iOS Keychain itens de senha genérica protegidos com o WhenUnlockedThisDeviceOnly aula de acessibilidade. As chaves do cofre derivadas do padrão e as chaves mestras aleatórias são processadas na memória do aplicativo por meio de CryptoKit. O bloqueio elimina o estado da chave ativa, mas Swift e iOS não oferecem garantia de que todas as cópias transitórias sejam substituídas.
Descoberta do cofre. A interface normal não mostra uma lista de cofres. O formato local armazena exatamente 1 arquivo de índice criptografado para cada vault, e o código de manutenção pode enumerar esses arquivos. Alguém com acesso ao contêiner de aplicativo pode, portanto, contar índices criptografados, embora os nomes dos arquivos não revelem padrões, nomes ou conteúdos de texto simples. Veja o completo arquitetura de segurança e explicação de criptografia 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 de esquecimento de senha. Se a redefinição de email por si só restaurar dados legíveis, pergunte qual mecanismo mantido pelo provedor recuperou a chave de conteúdo efetiva. Frases de recuperação mantidas pelo usuário, aprovação de dispositivos antigos e redefinições controladas pelo provedor são designs diferentes.
O teste do novo dispositivo. Se um novo dispositivo restaurar conteúdo legível, identifique o dispositivo secreto ou confiável que o autorizou. O login da conta por si só sugere um caminho de recuperação controlado pelo provedor; uma frase de recuperação mais registros de backup criptografados podem preservar a separação entre provedor e chave.
O teste da conta. Um endereço de e-mail ou número de telefone vincula a identidade aos metadados do serviço, mas por si só não prova que o provedor pode descriptografar o conteúdo. Inspecione a hierarquia de chaves, o design de recuperação, o código do cliente ou auditoria, a política de metadados e se o texto cifrado autenticado permite verificações de credenciais offline.
Esses testes são filtros, não uma prova de segurança. Uma especificação coerente deve nomear a chave de conteúdo, chave de desbloqueio, sais, parâmetros de derivação, formato de criptografia autenticada, regras nonce, envelopes de recuperação, armazenamento local de segredos, metadados em nuvem e o ponto onde existem chaves de texto simples. A revisão independente é uma evidência 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?
Seus dados ficarão permanentemente inacessíveis se todas as credenciais válidas e envelopes de recuperação forem perdidos. Uma redefinição ou chave mestra controlada pelo provedor enfraqueceria os limites do provedor, portanto a recuperação deve ser projetada separadamente. Cofre gera uma frase personalizada contendo 9 palavras separadas cuja chave de recuperação derivada abre um envelope de chave de cofre criptografado. A frase não regenera ou codifica a chave, e a restauração do novo dispositivo também requer a correspondência criptografada CloudKit registros.
A polícia pode aceder a dados cifrados com conhecimento zero?
Um provedor pode ter que divulgar o texto cifrado armazenado e os metadados de conta, tráfego, cobrança ou serviço que ele retém. Sem uma chave de conteúdo de texto simples mantida pelo provedor, esse provedor não pode usar seu caminho de serviço normal para descriptografar o conteúdo. A exploração de dispositivos, descoberta de credenciais, cópias de recuperação e divulgação forçada são rotas separadas cuja legalidade e eficácia variam de acordo com a jurisdição e os fatos.
A cifração de conhecimento zero é mais lenta que a cifração normal?
AES-256-GCM o desempenho não depende de quem detém a chave. A derivação baseada em senha adiciona trabalho durante o desbloqueio e sua duração depende do algoritmo, contagem de iterações, dispositivo e implementação. Os aplicativos devem medir esse custo no hardware suportado e equilibrar a capacidade de resposta em relação ao custo imposto a cada estimativa off-line.
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 provedor, não todo fluxo de dados. Um aplicativo ainda pode processar dados de conta, análises, relatórios de falhas, endereços IP, tamanhos de registros, tempo ou outros metadados de serviço. Vaultaire não requer conta de identidade e afirma que suas análises baseadas em consentimento excluem conteúdos, padrões, frases e chaves de descriptografia do cofre; é política de privacidade descreve as regras atuais de coleta 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 em iOS 16.2, estende a criptografia ponta a ponta para mais iCloud categorias e usa o modelo de recuperação de conta Apple. O Vaultaire mantém o conteúdo do cofre local por padrão e não requer nenhuma conta de identidade do Vaultaire; backup, sincronização e compartilhamento opcionais usam criptografia do lado do cliente CloudKit registros na conta Apple do usuário. Vaultaire também oferece acesso ao cofre separado por padrões e modo de coação, com os limites de armazenamento e recuperação descritos em seu documentação de negação plausível.
Resumo
A criptografia de conhecimento zero é melhor tratada como uma reivindicação de separação de chave do provedor: o serviço não contém a chave de texto simples necessária para descriptografar o conteúdo armazenado. Isso é mais forte do que a criptografia do lado do servidor sob chaves controladas pelo provedor, mas não é uma afirmação de que as chaves existam apenas na memória, que os metadados desapareçam ou que todos os comprometimentos de clientes e dispositivos sejam anulados. Julgue o produto pela sua hierarquia principal, design de recuperação, implementação e revisão independente.