Arquitetura de Segurança: A Pilha Técnica Completa

O Vaultaire usa AES-256-GCM para criptografia autenticada em índices de cofre, chaves encapsuladas, cabeçalhos de arquivos, conteúdo, miniaturas e metadados. O PBKDF2-HMAC-SHA512 deriva uma chave de cofre local a partir do padrão e de um sal do Keychain válido para todo o dispositivo. Essa chave do cofre encapsula uma chave mestra aleatória separada, de 256 bits, que executa a criptografia dos arquivos por meio do CryptoKit no processo do aplicativo.

A Pilha Criptográfica

O Vaultaire usa vários mecanismos criptográficos trabalhando em conjunto, cada um escolhido para uma tarefa específica. O PBKDF2 transforma uma credencial humana em uma chave de cofre ou de recuperação. O AES-256-GCM protege índices, invólucros de chave, metadados, miniaturas e conteúdo de arquivos. Uma chave mestra aleatória separa a criptografia de longa duração dos arquivos de um padrão que pode ser alterado. O Keychain e a Proteção de Dados do iOS protegem o sal e os registros de recuperação vinculados ao dispositivo enquanto ele está bloqueado. Nenhuma chave de descriptografia mantida pelo provedor dá ao desenvolvedor acesso rotineiro ao texto simples do cofre.

Isso não é complexidade por si só. Cada camada cobre uma superfície de ataque diferente. AES-256-GCM combina confidencialidade com autenticação, de modo que o texto cifrado modificado falha na verificação. PBKDF2 aumenta o custo de testar cada padrão ou frase. A chave mestra aleatória significa que uma mudança de padrão pode reencapsular uma chave em vez de criptografar novamente todos os arquivos. Proteção de dados do Keychain protege os registros locais de sal e recuperação, enquanto o aplicativo ainda reconhece que a criptografia simétrica ocorre na memória do processo.

Juntas, essas camadas formam uma arquitetura de defesa profunda, mas nem todas são barreiras independentes. Um padrão adivinhado pode ser verificado em relação ao nome do arquivo de índice e à autenticação AES-GCM, e um dispositivo desbloqueado comprometido pode observar chaves ou texto simples no processo do aplicativo. A arquitetura, portanto, depende da entropia das credenciais, do custo do PBKDF2, da proteção do dispositivo pelo iOS e do manuseio correto da criptografia autenticada, bem como da força do próprio AES.

AES-256-GCM: Criptografia de Arquivos

Cada foto, vídeo e documento armazenado no Vaultaire é criptografado com AES-256-GCM — o Advanced Encryption Standard com uma chave de 256 bits em Modo Galois/Contador. O Vaultaire também usa AES-GCM para índices de cofre, cabeçalhos de arquivos, miniaturas e envelopes de chaves. O algoritmo e o tamanho da chave são padronizados; a segurança do Vaultaire ainda depende do tratamento de nonce, do gerenciamento de chaves, da força das credenciais e da correção da implementação.

O “256” no AES-256 refere-se ao comprimento da chave em bits. Uma chave de 256 bits tem 2²⁵⁶ valores possíveis. Para contextualizar esse número: há aproximadamente 10⁸⁰ átomos no universo observável. Se cada átomo fosse um supercomputador testando um bilhão de chaves por segundo, funcionando desde o Big Bang, teriam explorado menos que um trilionésimo de trilionésimo de um por cento do espaço de chaves. AES-256 não vai ser quebrado por força bruta. Não hoje. Não neste século. Não antes das estrelas se apagarem.

Por Que o Modo GCM Importa

O AES é uma cifra de bloco — ele criptografa dados em pedaços de 128 bits. O “modo” determina como esses pedaços são combinados. O GCM (Galois/Counter Mode) oferece duas coisas que modos mais simples como o CBC não oferecem: criptografia paralelizada e autenticação integrada.

A parte de autenticação é crítica. O GCM gera uma etiqueta criptográfica para cada arquivo criptografado. Essa etiqueta funciona como um selo inviolável. Se um único bit do texto cifrado for modificado — seja por um agente malicioso ou um setor de disco corrompido — a etiqueta de autenticação não corresponderá e a descriptografia falhará. Você não recebe dados corrompidos. Você recebe um sinal claro de que algo está errado. Essa propriedade é chamada de criptografia autenticada e previne toda uma classe de ataques onde um adversário modifica dados criptografados para manipular a saída descriptografada.

PBKDF2: Derivação de Chaves

O Vaultaire deriva chaves diferentes para tarefas diferentes. O padrão e um sal do Keychain válido para todo o dispositivo alimentam o PBKDF2-HMAC-SHA512 por 600.000 iterações para produzir a chave local do cofre. Uma derivação determinística do padrão produz a chave separada de backup na nuvem. A frase de recuperação normalizada passa por 800.000 iterações de PBKDF2 para produzir a chave de um envelope de recuperação. Nenhuma dessas derivações transforma uma credencial humana em 256 bits de entropia simplesmente porque a saída tem 256 bits.

Como o PBKDF2 Protege seu Padrão

A ideia central por trás do PBKDF2 é o trabalho deliberado. Ele pega o padrão serializado ou a frase normalizada e executa centenas de milhares de iterações de HMAC-SHA512. Um usuário legítimo paga esse custo uma vez, durante uma tentativa de desbloqueio ou de recuperação. Um invasor paga esse custo por cada candidato, embora o hardware paralelo e as escolhas de implementação determinem a taxa real de tentativas.

O Vaultaire configura o PBKDF2 com 600.000 iterações para chaves derivadas do padrão. Isso torna cada tentativa mais cara, mas uma estimativa de ataque responsável deve informar um tempo medido por candidato e as premissas de hardware. A exatamente 1 ms por candidato, 1.000.000.000 de tentativas em série levam cerca de 11,6 dias, não anos. O resultado de 256 bits não expande a entropia de um padrão previsível.

A derivação local do padrão usa um único sal criptograficamente aleatório para o dispositivo, armazenado como um item do Keychain WhenUnlockedThisDeviceOnly. O sal não é secreto e é compartilhado pelos cofres desse dispositivo. Ele evita que uma tabela criada para um dispositivo seja aplicada diretamente a outro dispositivo com um sal diferente, mas não força um invasor a recomeçar para cada cofre no mesmo dispositivo.

AES-256-GCM: Proteção de metadados

Criptografar o conteúdo dos arquivos não é suficiente. Nomes de arquivos, datas de criação, dimensões de miniaturas e estrutura do cofre são todos metadados — e os metadados podem ser tão reveladores quanto os dados em si. Um arquivo chamado “declaracao-ir-2025.pdf” diz a um atacante exatamente o que está dentro, mesmo que o conteúdo seja criptografado. Um timestamp mostra quando você usou o cofre. O tamanho de uma miniatura revela se algo é uma foto ou um vídeo.

Vaultaire protege esses metadados com AES-256-GCM, não ChaCha20. Nomes de arquivos e tipos MIME são codificados em cabeçalhos de arquivos criptografados. O índice criptografado do cofre contém registros de arquivos, datas, informações de tamanho, layout de armazenamento e a chave mestra encapsulada. Os dados das miniaturas também são criptografados com a chave mestra aleatória.

Por que criptografia autenticada para metadados?

Os metadados precisam de integridade e também de confidencialidade. O AES-GCM produz uma tag de autenticação para cada valor criptografado, para que o Vaultaire possa rejeitar um cabeçalho, índice, miniatura ou envelope modificado em vez de aceitar texto simples controlado pelo invasor. O design usa deliberadamente uma construção de criptografia autenticada nesses formatos de armazenamento, em vez de alegar uma diversidade criptográfica que a implementação não oferece.

A mesma cifra não significa que a mesma chave ou nonce seja reutilizada cegamente. A chave do cofre protege o índice e encapsula a chave mestra aleatória; a chave mestra protege o material dos arquivos. O CryptoKit cria caixas seladas autenticadas com nonces novos, enquanto o formato de streaming do Vaultaire deriva um nonce distinto para cada bloco ordenado. As garantias relevantes vêm da separação de chaves, da disciplina no uso de nonces e da autenticação, e não de uma segunda cifra de metadados.

Arquitetura de Conhecimento Zero

Aqui está uma pergunta que vale a pena fazer sobre qualquer app de segurança: o que acontece se a empresa por trás dele for hackeada, intimada ou simplesmente se tornar maliciosa?

Com a maioria dos apps, a resposta é desconfortável. Eles guardam seus dados, suas chaves, ou ambos. Uma ordem judicial os obriga a entregá-los. Uma violação de dados os expõe. Um funcionário desonesto os acessa. A segurança do app é apenas tão forte quanto a segurança operacional da empresa — e a história mostra que empresas são comprometidas regularmente.

O Vaultaire não opera uma conta nem um serviço de armazenamento que receba seu padrão, sua frase secreta, suas chaves de descriptografia ou o conteúdo legível do cofre. A criptografia e a descriptografia acontecem no processo do aplicativo, no seu dispositivo. Quando o backup no iCloud está ativado, o aplicativo envia texto cifrado autenticado para o seu banco de dados privado do CloudKit, e não para um serviço de cofre controlado pelo Vaultaire.

O Que Conhecimento Zero Significa na Prática

Se um órgão de aplicação da lei enviar ao Vaultaire uma intimação exigindo o texto simples do cofre, a empresa não possui o padrão, a frase de recuperação, a chave do cofre, a chave de backup ou a chave mestra necessária para descriptografá-lo. Os registros criptografados do iCloud ficam no banco de dados privado do CloudKit do usuário. No dispositivo, porém, o material de recuperação fica em um banco de dados criptografado do Keychain, e chaves simétricas existem na memória do aplicativo enquanto o CryptoKit criptografa ou descriptografa um cofre aberto.

Esse limite do provedor é uma propriedade arquitetônica e não uma promessa de que todas as partes do ambiente do cliente estão fora do modelo de confiança. O Vaultaire não possui uma chave de descriptografia do lado do servidor que possa ser entregue para recuperação de rotina do cofre. O aplicativo distribuído, o iOS, o dispositivo desbloqueado e a implementação criptográfica ainda podem processar dados legíveis, e a confiança neles deve levar isso em conta.

O Keychain e o limite do processo do aplicativo

O Secure Enclave da Apple pode proteger chaves privadas compatíveis e participa de partes da arquitetura de segurança da plataforma, mas suas APIs públicas não aceitam uma chave simétrica arbitrária derivada por PBKDF2 nem executam as operações AES-GCM de arquivos do Vaultaire dentro do coprocessador. Por isso, o Vaultaire não descreve sua cifra de cofre como AES do Secure Enclave.

O Vaultaire usa itens comuns de senha genérica do Keychain do iOS para o sal aleatório do dispositivo, o banco de dados de recuperação criptografado e a chave aleatória que protege esse banco de dados. Esses itens usam a classe de acessibilidade WhenUnlockedThisDeviceOnly. O Keychain e a Proteção de Dados criam um limite significativo no dispositivo, especialmente enquanto o telefone está bloqueado, mas essa arquitetura é diferente de uma chave não exportável do Secure Enclave.

Quando você desenha o padrão, o CommonCrypto deriva a chave do cofre no processo do aplicativo. Em seguida, o CryptoKit e o CryptoEngine do Vaultaire usam bytes de chave simétrica nesse processo para autenticar e descriptografar o índice, abrir a chave mestra e processar arquivos. O aplicativo limpa o estado ativo quando é bloqueado, mas um invasor com privilégios suficientes que observe uma sessão desbloqueada tem uma oportunidade diferente da de um examinador que tem apenas o texto cifrado de um dispositivo bloqueado.

Um sistema operacional com jailbreak ou comprometido de outra forma pode ter como alvo a entrada do padrão, a memória do aplicativo, as pré-visualizações descriptografadas, as exportações ou a tela. O Vaultaire recomenda um iPhone atualizado e sem jailbreak porque o design depende do isolamento de processos do iOS, do Keychain e da Proteção de Dados. Ele não afirma que um comprometimento no nível raiz deixe inacessíveis as chaves simétricas de um cofre aberto.

Vetores de Inicialização por Arquivo

Quando você criptografa dois arquivos idênticos com a mesma chave, uma implementação ingênua produziria texto cifrado idêntico. Isso é um problema. Um atacante que vê dois blobs criptografados idênticos sabe — sem descriptografar nada — que os dois arquivos originais são iguais. Em um cofre cheio de fotos, esse tipo de análise de padrão pode revelar informações mesmo através da criptografia.

O Vaultaire evita texto cifrado determinístico gerando um novo nonce criptográfico para cada operação de selagem AES-256-GCM. Os cabeçalhos e o conteúdo dos arquivos são lacrados separadamente, e arquivos grandes usam um formato de streaming autenticado com um nonce de base aleatório e um nonce distinto para cada parte ordenada. Duas cópias da mesma foto, portanto, não produzem a mesma representação criptografada.

Os nonces são armazenados com o texto cifrado e não são secretos; seu requisito de segurança é a exclusividade sob uma determinada chave. O Vaultaire solicita nonces de 96 bits do gerador aleatório criptográfico da Apple para criptografia de disparo único e registra o nonce base no cabeçalho de streaming. O risco de colisão é governado pelo número de criptografias sob uma chave, de modo que a implementação gera um novo valor em vez de apresentar o tamanho de 96 bits como uma garantia vitalícia fixa de uma chance em 2⁹⁶.

Gerenciamento de memória: limpando o estado da chave ativa

Uma falha comum em softwares de segurança é deixar dados sensíveis na memória após não serem mais necessários. Chaves de criptografia, senhas derivadas e dados descriptografados podem persistir na RAM muito depois de o app ter terminado de usá-los. Ferramentas forenses podem despejar a memória do dispositivo e buscar por esses remanescentes — uma técnica conhecida como ataque de inicialização a frio ou análise de despejo de memória.

O Vaultaire limita por quanto tempo o estado da chave ativa e os dados de IU descriptografados permanecem disponíveis. Quando o aplicativo é bloqueado ou a sessão é interrompida, seu código segue vários caminhos de limpeza:

• O estado ativo do cofre é descartado. O aplicativo remove a sessão atual da chave do cofre e requer outro desbloqueio antes de apresentar o conteúdo do cofre.
• Os invólucros de chaves zeram os buffers que possuem. Os contêineres de bytes seguros do Vaultaire substituem os buffers que possuem quando esses contêineres são desalocados.
• O estado da chave mestra armazenada em cache é invalidado. A chave mestra descriptografada mantida para o índice aberto é descartada nos caminhos relevantes de bloqueio e redefinição de cache.
• Os caches de IU descriptografados são limpos quando controlados pelo Vaultaire. A limpeza de miniaturas e visualizações reduz o estado residual do aplicativo, sem alegar controle sobre cada cópia feita pelo Swift, pelo iOS ou por outro processo.

Na próxima vez que o Vaultaire for aberto em estado bloqueado, você desenha o padrão e o aplicativo deriva a chave do cofre novamente antes de poder autenticar o índice e abrir a chave mestra. Esta é uma limpeza de sessão, não uma afirmação de que cada cópia de memória transitória recebeu uma limpeza de múltiplas passagens comprovável ou de que uma referência de chave do Secure Enclave foi destruída. Uma falha faz o iOS recuperar o processo, mas o código de limpeza não consegue ser executado após todo encerramento abrupto.