A forma mais simples de imaginar um cofre de fotos

Imagine colocar uma fotografia dentro de um cofre.

A analogia tem um limite importante. Um cofre físico contém um objeto. Um telefone pode conter muitas cópias: o original no Photos ou na Galeria, uma cópia importada no cofre, uma miniatura, uma versão editada, um anexo de mensagem, uma cópia na nuvem e uma exportação. Criptografar uma cópia não protege nem exclui automaticamente as outras.

Um cofre protege os dados que gerencia enquanto está bloqueado. As cópias de origem, o texto simples exibido e as exportações pertencem a limites de segurança diferentes.

  • A foto é o texto simples: a informação original legível.
  • A chave do cofre é a chave de criptografia: um segredo longo e aleatório usado pelo algoritmo de criptografia.
  • O cofre bloqueado é o texto cifrado: dados que devem parecer sem sentido sem a chave.
  • Sua senha, PIN ou padrão prova que o aplicativo pode usar a chave. Não deve ser a chave usada para criptografar diretamente cada arquivo.

O que acontece quando você importa uma foto

Um fluxo de importação bem projetado geralmente segue quatro etapas gerais:

Muitos cofres modernos usam AES-GCM. AES é a cifra de blocos padronizada no NIST FIPS 197, e GCM é um modo de criptografia autenticada especificado no NIST SP 800-38D.

Essa linhagem de padrões importa, mas o nome de um algoritmo sozinho não prova que um aplicativo seja seguro. A geração de chaves, o tratamento de nonces, os metadados, os backups, o tratamento de erros e o tempo de vida do texto simples também importam.

  • O aplicativo lê o arquivo selecionado. Neste momento, a foto de origem ainda pode existir na biblioteca de fotos do sistema.
  • O aplicativo cria ou recupera uma chave de cofre aleatória. Aplicativos seguros usam os geradores de números aleatórios criptográficos do sistema operacional em vez de uma palavra memorável ou um valor previsível.
  • O aplicativo criptografa e autentica a foto. A saída é o texto cifrado mais as informações necessárias para verificar que ela não foi alterada.
  • O aplicativo armazena o resultado selado. Quando o cofre está bloqueado, o acesso comum do aplicativo à chave de descriptografia é removido.

Por que sua senha não deve ser a chave do arquivo

As pessoas escolhem senhas, PINs e padrões que conseguem lembrar. As chaves criptográficas devem ser longas, aleatórias e impraticáveis de adivinhar. São tarefas diferentes.

Um design sólido separa a credencial da chave aleatória que protege o cofre:

O Argon2id é uma escolha moderna de derivação de chaves. A RFC 9106 descreve o Argon2 como uma função com uso intensivo de memória e inclui o Argon2id como sua variante principal. O processamento com uso intensivo de memória torna cada tentativa mais cara, especialmente em grande escala. Ele não transforma 1234, um quadrado curto ou uma senha reutilizada em um segredo forte.

Esse modelo em camadas também torna as mudanças de senha mais práticas. O aplicativo pode mudar como o acesso à chave estável do cofre é encapsulado, em vez de descriptografar e recriptografar cada foto. A OWASP descreve a mesma separação geral como uma chave de criptografia de dados protegida por uma chave de criptografia de chaves separada em seu Cryptographic Storage Cheat Sheet.

  • Você insere uma senha, um PIN ou um padrão.
  • Uma função de derivação de chaves a processa com um salt exclusivo e consome deliberadamente recursos de computação.
  • O resultado desbloqueia ou desencapsula uma chave de cofre aleatória.
  • A chave do cofre ancora chaves separadas para conteúdo, metadados ou arquivos individuais.

Por que a criptografia autenticada importa

A criptografia responde a uma pergunta: «Alguém consegue entender estes dados sem a chave?»

A autenticação responde a outra: «Estes dados criptografados foram alterados?»

O AES-GCM combina as duas tarefas. Quando um aplicativo sela um arquivo, ele também produz uma etiqueta de autenticação. Se o texto cifrado ou seu contexto protegido for alterado, a verificação deve falhar e o aplicativo deve se recusar a liberar o texto simples. O NIST chama isso de criptografia autenticada com dados associados no SP 800-38D.

Os dados associados podem vincular um registro criptografado a fatos que não deveriam ser intercambiáveis, por exemplo seu cofre, arquivo, tipo de registro ou posição do bloco. Isso ajuda a impedir que um bloco criptografado válido seja movido silenciosamente para o contexto errado.

Falhar de forma segura tem um custo: o texto cifrado danificado ou modificado pode ficar indisponível. Isso é mais seguro do que exibir uma saída não verificada, mas também é por isso que arquivos insubstituíveis precisam de um backup testado.

Uma foto é mais do que seus pixels em tamanho real

A mídia privada pode deixar pistas mesmo quando o arquivo original está criptografado. Um design completo de cofre deve considerar:

Se um cofre criptografa a foto em tamanho real mas deixa uma miniatura legível ou um nome de arquivo descritivo no disco, a informação mais sensível ainda pode ficar exposta. Uma boa documentação de produto deve declarar se seu limite protegido inclui conteúdo, metadados, miniaturas e arquivos temporários.

  • nomes de arquivo e rótulos do usuário;
  • datas, localizações e outros metadados;
  • miniaturas e pré-visualizações;
  • edições e versões otimizadas;
  • recursos de Live Photo ou vídeo emparelhado;
  • associação a álbuns e índices de busca;
  • arquivos temporários criados durante a visualização ou a exportação.

O que «bloqueado» realmente significa

Quando um cofre está bloqueado, o aplicativo não deve mais ter acesso comum às chaves de texto simples ativas de que precisa para exibir arquivos. Os arquivos criptografados podem permanecer no armazenamento; sem a chave necessária, esses arquivos não devem ser legíveis de forma significativa.

O desbloqueio muda a situação. Para exibir uma imagem, o aplicativo deve descriptografar dados suficientes para que o sistema operacional a renderize. O texto simples então existe na memória e no caminho de exibição. O bloqueio baseado no ciclo de vida do aplicativo, os tempos de vida curtos das chaves e o armazenamento temporário protegido podem reduzir a exposição, mas não conseguem tornar invisível o texto simples visível.

No Android, o Android Keystore pode manter o material de chave elegível não exportável e vinculá-lo a hardware seguro em dispositivos suportados. A proteção de dados do Keychain da Apple fornece de forma semelhante classes de proteção e controles de acesso impostos pelo Secure Enclave para itens sensíveis.

Esses recursos da plataforma são valiosos, mas não tornam seguro um telefone já comprometido e desbloqueado. Um software malicioso que controla o aplicativo ou o sistema operacional pode conseguir solicitar operações de chave ou observar o texto simples enquanto o usuário o visualiza, mesmo quando a própria chave não pode ser exportada.

Álbum oculto, criptografia de dispositivo e um cofre criptografado são coisas diferentes

Essas proteções podem funcionar em conjunto, mas resolvem problemas diferentes.

«Criptografado», portanto, não é uma resposta completa. Pergunte qual cópia, contra quem, com o dispositivo em que estado e quem pode obter a chave.

  • Proteção — O que ela protege principalmente — Autoridade de desbloqueio — Limite importante
  • Álbum oculto ou ocultamento na galeria — Descoberta acidental dentro de um aplicativo de fotos — Geralmente o bloqueio do dispositivo ou do aplicativo de fotos — O item pode permanecer na mesma biblioteca de fotos e no modelo de sincronização na nuvem
  • Criptografia do armazenamento do telefone — Dados em um dispositivo bloqueado ou desligado — Código do dispositivo e chaves da plataforma — Uma vez que o dispositivo é desbloqueado, os aplicativos autorizados podem usar seus dados permitidos
  • Cofre de fotos criptografado — A cópia gerenciada pelo aplicativo enquanto o cofre está bloqueado — Credencial do cofre mais o design de chaves do aplicativo — Originais, exportações, telas e outras cópias permanecem separados
  • Cópia na nuvem criptografada de ponta a ponta — Conteúdo entre endpoints autorizados — Chaves disponíveis aos dispositivos autorizados — O provedor ainda pode processar metadados de conta, tempo, tamanho e tráfego

O que significa criptografia de conhecimento zero

A criptografia de conhecimento zero é comumente usada para uma arquitetura de serviço em que o provedor armazena dados criptografados mas não possui as chaves necessárias para descriptografar o conteúdo do usuário. A criptografia acontece antes de os dados chegarem ao provedor, e a descriptografia acontece em um dispositivo de usuário autorizado.

Uma analogia simples é um hotel que aluga um cofre para você mas nunca recebe a combinação. O hotel pode guardar e mover o cofre. Ele pode ver que um cofre existe e qual é o seu tamanho. Ele não pode abrir o cofre para você se você esquecer a combinação.

Para um cofre na nuvem, as perguntas centrais são:

Conhecimento zero não significa que o serviço não aprende literalmente nada. Descreve o acesso ao conteúdo criptografado, não a ausência de todos os metadados do serviço. Também não protege um endpoint desbloqueado: um telefone comprometido pode observar uma foto após a descriptografia legítima.

Um sistema pode usar ambas as descrições, mas os leitores devem procurar um design documentado de chaves e recuperação em vez de confiar apenas em qualquer um dos rótulos.

Isso cria um compromisso real: uma separação mais forte do provedor coloca mais responsabilidade sobre o usuário. Perder cada dispositivo autorizado e cada segredo de recuperação pode tornar os dados permanentemente inacessíveis.

  • As chaves de criptografia são criadas ou derivadas no dispositivo do usuário?
  • O provedor alguma vez recebe a chave ou a credencial em texto simples?
  • O suporte da conta pode redefinir o acesso e revelar os arquivos antigos?
  • Um novo dispositivo precisa de um segredo de recuperação ou da aprovação de um dispositivo existente?
  • Quais metadados de conta, tempo, dispositivo, tamanho de armazenamento e rede permanecem visíveis?
  • Conhecimento zero vs criptografia de ponta a ponta — As ideias se sobrepõem, mas a ênfase é diferente.
  • A criptografia de ponta a ponta descreve um caminho: somente os endpoints autorizados devem descriptografar o conteúdo enquanto ele se move ou sincroniza através de um serviço.
  • A criptografia de conhecimento zero enfatiza o acesso do provedor: o provedor não deve possuir a autoridade necessária para descriptografar o conteúdo do usuário armazenado.
  • O compromisso da recuperação — Se o provedor realmente não tem autoridade de descriptografia, ele não pode simplesmente enviar por e-mail um link de redefinição que restaura o acesso ao conteúdo criptografado antigo. A recuperação precisa de outra fonte de autoridade, como uma frase de recuperação, uma chave de recuperação, a aprovação de um dispositivo existente ou uma chave exportada previamente.

Sete perguntas para fazer antes de confiar em qualquer aplicativo de cofre

  • 1. O que exatamente é criptografado? — Procure uma declaração explícita sobre o conteúdo original, as miniaturas, os nomes de arquivo, os metadados, as notas e os arquivos temporários. O nome de uma cifra por si só não basta.
  • 2. De onde vêm as chaves? — O aplicativo deve usar aleatoriedade criptograficamente segura para as chaves de conteúdo. Uma senha ou padrão deve passar por um design documentado de derivação de chaves em vez de se tornar diretamente uma chave de arquivo.
  • 3. Ele detecta adulteração? — Procure criptografia autenticada como AES-GCM ou ChaCha20-Poly1305, ou outra construção bem documentada de criptografar-depois-autenticar. A OWASP recomenda modos autenticados quando disponíveis.
  • 4. O que acontece com o original? — Importação e exclusão são operações separadas. Verifique o Photos ou a Galeria, os Excluídos Recentemente ou a Lixeira, o Files, as bibliotecas na nuvem, as mensagens, os álbuns compartilhados e outros dispositivos.
  • 5. O que acontece se o telefone for perdido? — Um cofre criptografado sem cópia recuperável protege a privacidade, mas não a disponibilidade. Entenda se a recuperação precisa do dispositivo original, de um arquivo de backup criptografado, de uma frase, de uma conta ou de alguma combinação.
  • 6. O provedor pode redefinir o acesso e revelar os dados antigos? — Se sim, o provedor ou o sistema de recuperação tem algum caminho para a autoridade de descriptografia. Isso pode ser uma conveniência intencional, mas deve ser divulgado com clareza.
  • 7. As limitações estão por escrito? — Uma documentação confiável deve discutir dispositivos comprometidos, credenciais fracas, exportações, limites de exclusão, backups e dados irrecuperáveis, não apenas nomes de cifras.

Um exemplo fictício

Neste cenário fictício, Maya importa uma digitalização de passaporte para um cofre e confirma que a cópia em resolução total abre após o bloqueio e o desbloqueio. Ela então cria e testa o backup criptografado documentado. Somente após ambas as verificações ela examina o Photos, os Excluídos Recentemente, o Files, as Mensagens e sua biblioteca de fotos na nuvem em busca de cópias de origem indesejadas.

O cofre protege sua cópia gerenciada enquanto está bloqueado. O backup protege contra a perda do dispositivo. Remover outras cópias reduz a exposição fora do cofre. Estas são três tarefas separadas, e pular qualquer uma delas muda o resultado.

A credencial memorável autoriza o acesso a uma chave aleatória; a criptografia autenticada transforma a foto gerenciada em texto cifrado selado.

O que a criptografia não pode proteger

Um cofre de fotos criptografado não pode:

O modelo mental certo é simples: a criptografia é poderosa dentro do seu limite declarado. Uma boa privacidade vem de entender esse limite e gerenciar cada cópia que o atravessa.

  • remover automaticamente originais, exportações, mensagens, backups ou cópias de destinatários;
  • impedir que outra câmera fotografe uma tela desbloqueada;
  • tornar não adivinhável uma senha ou padrão fraco ou observado;
  • proteger o texto simples de um sistema operacional comprometido durante o desbloqueio;
  • garantir o apagamento físico da memória flash, dos snapshots ou dos backups antigos;
  • recuperar dados quando cada cópia válida de texto cifrado ou o segredo de recuperação necessário é perdido;
  • esconder qualquer evidência de que o aplicativo ou o armazenamento criptografado existe.

Perguntas frequentes

  • Alguém pode ler um cofre copiando seus arquivos? — Um design sólido visa tornar o texto cifrado copiado ilegível sem o material de chave necessário. Isso descreve uma cópia offline. Alguém que controla o dispositivo original enquanto o cofre está desbloqueado enfrenta uma superfície de ataque diferente, e muito mais fácil.
  • O AES-256 basta para provar que um aplicativo é seguro? — Não. O AES-256 é uma cifra padronizada, mas o design ao seu redor determina se ela é usada com segurança. A geração de chaves, o modo autenticado, os nonces exclusivos, os metadados, os arquivos temporários, os backups e o tratamento de erros importam todos.
  • As miniaturas também são criptografadas? — Elas devem estar dentro do limite protegido do cofre se revelarem conteúdo privado. Outros aplicativos ou o sistema operacional ainda podem ter pré-visualizações criadas antes da importação ou depois da exportação.
  • Mudar uma senha recriptografa cada foto? — Não necessariamente. Em um design em camadas, a senha controla o acesso a uma chave de cofre aleatória e estável. O aplicativo pode reencapsular o acesso a essa chave sem recriptografar cada objeto de conteúdo apenas porque a credencial mudou.
  • O que acontece se os dados criptografados forem danificados? — A descriptografia autenticada deve falhar quando o texto cifrado ou seu contexto protegido não verifica. Isso impede a aceitação silenciosa de dados alterados, mas pode tornar um arquivo danificado indisponível. Mantenha um backup testado para qualquer coisa insubstituível.
  • Um backup criptografado é automaticamente privado e recuperável? — Não. A privacidade depende de quem tem as chaves; a recuperação depende de manter tanto a autoridade necessária quanto uma cópia criptografada válida. Uma frase de recuperação não pode recriar um arquivo de backup ausente.

Fontes primárias e leitura adicional

Para a implementação específica do produto NullVault, consulte a arquitetura de segurança e os limites de segurança separados.

Guia revisado: 30 de agosto de 2026.

  • NIST FIPS 197: especificação do Advanced Encryption Standard (AES)
  • NIST SP 800-38D: modo Galois/Counter (GCM) e GMAC
  • RFC 9106: a função Argon2 com uso intensivo de memória
  • OWASP Cheat Sheet sobre armazenamento criptográfico
  • Android Developers: o sistema Android Keystore
  • Android Developers: criptografia
  • Apple Platform Security: proteção de dados do Keychain
  • Apple Platform Security: visão geral de criptografia e proteção de dados

Eli começa com um teste não sensível: «começa com um item não sensível ao avaliar como funcionam os cofres de fotos criptografados». Em seguida, Eli segue a segunda verificação: «bloqueia o aplicativo ou dispositivo relevante e então confirma o resultado a partir de uma nova sessão». Este cenário fictício ilustra o processo de decisão; não é um relato de testes de produto.

  • O resultado descrito por como funcionam os cofres de fotos criptografados não cobre automaticamente cópias exportadas, compartilhadas, em cache ou sincronizadas na nuvem.
  • Uma credencial perdida, um contêiner de aplicativo excluído, um dispositivo redefinido ou um backup não testado podem tornar os dados protegidos indisponíveis.

O que um cofre realmente protege?

Ele protege sua própria cópia gerenciada enquanto essa cópia está bloqueada em repouso. Ele não protege uma foto que ainda está no rolo da câmera, já exportada ou visível em uma tela desbloqueada.

Quem detém a chave de um cofre criptografado?

Em um design local-first, a chave é derivada no seu dispositivo a partir da sua credencial e do material de chave da plataforma, e é por isso que uma credencial esquecida e um caminho de recuperação não testado podem tornar o conteúdo permanentemente indisponível.

Fontes principais deste guia