Arquitetura de segurança: a pilha técnica completa

O Vaultaire usa AES-256-GCM para encriptação autenticada nos índices dos cofres, chaves envolvidas, cabeçalhos de ficheiros, conteúdo, miniaturas e metadados. O PBKDF2-HMAC-SHA512 deriva uma chave local do cofre a partir do padrão e de um salt do Keychain comum a todo o dispositivo. Essa chave do cofre envolve uma chave mestra aleatória separada de 256 bits, que faz a encriptação dos ficheiros através do CryptoKit no processo da aplicação.

A pilha criptográfica

O Vaultaire usa vários mecanismos criptográficos em conjunto, cada um escolhido para uma função específica. O PBKDF2 transforma uma credencial humana numa chave do cofre ou de recuperação. O AES-256-GCM protege índices, invólucros de chaves, metadados, miniaturas e conteúdo dos ficheiros. Uma chave mestra aleatória separa a encriptação duradoura dos ficheiros de um padrão que pode mudar. O Keychain e a Proteção de Dados do iOS protegem o salt ligado ao dispositivo e os registos de recuperação enquanto o dispositivo está bloqueado. Nenhuma chave de desencriptação na posse do fornecedor dá ao programador acesso rotineiro ao conteúdo legível dos cofres.

Não se trata de complexidade gratuita. Cada camada responde a uma superfície de ataque diferente. O AES-256-GCM junta confidencialidade e autenticação, pelo que um texto cifrado modificado falha a verificação. O PBKDF2 aumenta o custo de testar cada padrão ou frase. A chave mestra aleatória permite que uma mudança de padrão volte a envolver uma única chave em vez de encriptar de novo todos os ficheiros. A proteção de dados do Keychain guarda o salt local e os registos de recuperação, e a aplicação continua a reconhecer que a encriptação simétrica acontece na memória do processo.

Em conjunto, estas camadas formam uma arquitetura de defesa em profundidade, mas nem todas são barreiras independentes. Um padrão adivinhado pode ser verificado contra o nome do ficheiro do índice e a autenticação AES-GCM, e um dispositivo desbloqueado e comprometido pode observar chaves ou conteúdo legível no processo da aplicação. Por isso, a arquitetura depende da entropia da credencial, do custo do PBKDF2, da proteção do dispositivo iOS e do tratamento correto da encriptação autenticada, além da força do próprio AES.

AES-256-GCM: Encriptação de ficheiros

Cada fotografia, vídeo e documento guardado no Vaultaire é encriptado com AES-256-GCM, o Advanced Encryption Standard com uma chave de 256 bits em modo Galois/Counter. O Vaultaire também usa AES-GCM para os índices dos cofres, cabeçalhos de ficheiros, miniaturas e envelopes de chaves. O algoritmo e o tamanho da chave são normalizados; a segurança do Vaultaire continua a depender do tratamento dos nonces, da gestão das chaves, da força das credenciais e da correção da implementação.

O número “256” em AES-256 refere-se ao comprimento da chave em bits. Uma chave de 256 bits tem 2²⁵⁶ valores possíveis. Para enquadrar: há aproximadamente 10⁸⁰ átomos no universo observável. Se cada átomo fosse um supercomputador a testar mil milhões de chaves por segundo e tivesse estado a funcionar desde o Big Bang, teriam explorado menos de um bilionésimo de bilionésimo de um por cento do espaço de chaves. O AES-256 não será quebrado por força bruta. Não hoje. Não neste século. Não antes de as estrelas se apagarem.

Porque é que o modo GCM é importante

O AES é uma cifra de bloco: encripta dados em blocos de 128 bits. O “modo” determina como esses blocos são combinados. O GCM (Galois/Counter Mode) fornece duas coisas que modos mais simples como o CBC não fornecem: encriptação paralelizada e autenticação incorporada.

A parte de autenticação é crítica. O GCM gera uma etiqueta criptográfica para cada ficheiro encriptado. Esta etiqueta funciona como um selo à prova de adulteração. Se um único bit do texto cifrado for modificado, seja por um agente malicioso ou por um setor de disco corrompido, a etiqueta de autenticação não corresponderá e a desencriptação falhará. Não obtém dados corrompidos. Obtém um sinal claro de que algo está errado. Esta propriedade chama-se encriptação autenticada e previne toda uma classe de ataques onde um adversário modifica dados encriptados para manipular a saída desencriptada.

PBKDF2: Derivação de chaves

O Vaultaire deriva chaves diferentes para funções diferentes. O padrão e um salt do Keychain comum a todo o dispositivo passam pelo PBKDF2-HMAC-SHA512 durante 600.000 iterações para produzir a chave local do cofre. Uma derivação determinística do padrão produz a chave separada da cópia de segurança na nuvem. A frase de recuperação normalizada passa por 800.000 iterações do PBKDF2 para produzir a chave de um envelope de recuperação. Nenhuma destas derivações transforma uma credencial humana em 256 bits de entropia só porque o resultado tem 256 bits.

Como o PBKDF2 protege o seu padrão

A ideia central do PBKDF2 é o trabalho deliberado. Pega no padrão serializado ou na frase normalizada e executa centenas de milhares de iterações de HMAC-SHA512. Um utilizador legítimo paga esse custo uma vez em cada tentativa de desbloqueio ou de recuperação. Um atacante paga-o por cada candidato, embora o hardware paralelo e as escolhas de implementação determinem o ritmo real das tentativas.

O Vaultaire configura o PBKDF2 com 600.000 iterações para as chaves derivadas do padrão. Isso torna cada tentativa mais cara, mas uma estimativa de ataque responsável tem de indicar um tempo medido por candidato e os pressupostos de hardware. A exatamente um milissegundo por candidato, mil milhões de tentativas em série demoram cerca de 11,6 dias, não anos. O resultado de 256 bits não aumenta a entropia de um padrão previsível.

A derivação local do padrão usa um único salt criptograficamente aleatório para o dispositivo, guardado como item do Keychain WhenUnlockedThisDeviceOnly. O salt não é secreto e é partilhado pelos cofres desse dispositivo. Impede que uma tabela construída para um dispositivo se aplique diretamente a outro dispositivo com um salt diferente, mas não obriga um atacante a recomeçar para cada cofre do mesmo dispositivo.

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

Encriptar o conteúdo dos ficheiros não é suficiente. Nomes de ficheiros, datas de criação, dimensões de miniaturas e estrutura do cofre são metadados, e os metadados podem ser tão reveladores quanto os próprios dados. Um ficheiro chamado “declaracao-irs-2025.pdf” diz ao atacante exatamente o que está dentro, mesmo que o conteúdo esteja encriptado. Um carimbo de data/hora mostra quando usou o cofre. O tamanho da miniatura revela se algo é uma fotografia ou um vídeo.

O Vaultaire protege estes metadados com AES-256-GCM, não com ChaCha20. Os nomes dos ficheiros e os tipos MIME são codificados em cabeçalhos de ficheiro encriptados. O índice encriptado do cofre contém os registos dos ficheiros, datas, informação de tamanho, disposição do armazenamento e a chave mestra envolvida. Os dados das miniaturas também são encriptados com a chave mestra aleatória.

Porquê encriptação autenticada para os metadados?

Os metadados precisam de integridade, além de confidencialidade. O AES-GCM produz uma etiqueta de autenticação para cada valor encriptado, para que o Vaultaire possa rejeitar um cabeçalho, índice, miniatura ou envelope modificado em vez de aceitar conteúdo controlado por um atacante. O design usa deliberadamente uma única construção de encriptação autenticada em todos estes formatos de armazenamento, em vez de alegar uma diversidade criptográfica que a implementação não oferece.

Usar a mesma cifra não significa reutilizar às cegas a mesma chave ou o mesmo nonce. A chave do cofre protege o índice e envolve a chave mestra aleatória; a chave mestra protege o material dos ficheiros. O CryptoKit cria caixas seladas autenticadas com nonces novos, e 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 de nonces e da autenticação, não de uma segunda cifra para metadados.

Arquitetura de conhecimento zero

Vale a pena fazer esta pergunta sobre qualquer aplicação de segurança: o que acontece se a empresa por trás dela for atacada por piratas informáticos, intimada ou simplesmente mudar de lado?

Para a maioria das aplicações, a resposta é desconfortável. Elas guardam os seus dados, as suas chaves, ou ambos. Uma ordem judicial obriga-as a entregá-los. Uma violação de dados expõe-nos. Um funcionário desonesto acede a eles. A segurança da aplicação é tão forte quanto a segurança operacional da empresa, e a história mostra que as empresas são comprometidas regularmente.

O Vaultaire não opera nenhum serviço de contas ou de armazenamento que receba o seu padrão, a frase secreta, as chaves de desencriptação ou o conteúdo legível do cofre. A encriptação e a desencriptação acontecem no processo da aplicação, no seu dispositivo. Com a cópia de segurança iCloud ativa, a aplicação envia texto cifrado autenticado para a sua base de dados privada do CloudKit, e não para um serviço de cofres controlado pelo Vaultaire.

O que a arquitetura de conhecimento zero significa na prática

Se uma autoridade policial entregar ao Vaultaire uma intimação a exigir o conteúdo legível de um cofre, a empresa não tem o padrão, a frase de recuperação, a chave do cofre, a chave da cópia de segurança nem a chave mestra necessários para o desencriptar. Os registos encriptados do iCloud ficam na base de dados privada do CloudKit do utilizador. No dispositivo, porém, o material de recuperação fica numa base de dados encriptada do Keychain, e as chaves simétricas existem na memória da aplicação enquanto o CryptoKit encripta ou desencripta um cofre aberto.

Este limite do fornecedor é uma propriedade da arquitetura, 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 guarda nenhuma chave de desencriptação no servidor que possa entregar para a recuperação rotineira de cofres. A aplicação distribuída, o iOS, o dispositivo desbloqueado e a implementação criptográfica continuam a poder processar dados legíveis e merecem a confiança correspondente.

Keychain e o limite do processo de aplicação

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

O Vaultaire usa itens comuns de palavra-passe genérica do Keychain do iOS para o salt aleatório do dispositivo, a base de dados de recuperação encriptada e a chave aleatória que protege essa base de dados. Estes itens usam a classe de acessibilidade WhenUnlockedThisDeviceOnly. O Keychain e a Proteção de Dados criam um limite relevante no dispositivo, sobretudo com o telemóvel bloqueado, mas esta arquitetura é diferente de uma chave não exportável do Secure Enclave.

Quando desenha o padrão, o CommonCrypto deriva a chave do cofre no processo da aplicação. O CryptoKit e o CryptoEngine do Vaultaire usam depois os bytes da chave simétrica nesse processo para autenticar e desencriptar o índice, desembrulhar a chave mestra e processar os ficheiros. A aplicação limpa o estado ativo quando bloqueia, mas um atacante com privilégios suficientes a observar uma sessão desbloqueada tem uma oportunidade diferente da de um examinador que só tem o texto cifrado de um dispositivo bloqueado.

Um sistema operativo com jailbreak ou comprometido de outra forma pode visar a introdução do padrão, a memória da aplicação, as pré-visualizações desencriptadas, as exportações ou o ecrã. 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. Não afirma que um comprometimento ao nível de root deixa inacessíveis as chaves simétricas de um cofre aberto.

Vetores de inicialização por ficheiro

Quando encripta dois ficheiros idênticos com a mesma chave, uma implementação ingénua produziria texto cifrado idêntico. Isso é um problema. Um atacante que veja dois blocos encriptados idênticos sabe, sem desencriptar nada, que os dois ficheiros originais são iguais. Num cofre cheio de fotografias, este tipo de análise de padrões pode revelar informação mesmo através da encriptação.

O Vaultaire evita texto cifrado determinístico ao gerar um nonce criptográfico novo para cada operação de selagem AES-256-GCM. Os cabeçalhos e o conteúdo dos ficheiros são selados separadamente, e os ficheiros grandes usam um formato de streaming autenticado com um nonce base aleatório e um nonce distinto para cada bloco ordenado. Por isso, duas cópias da mesma fotografia não produzem a mesma representação encriptada.

Os nonces são guardados com o texto cifrado e não são secretos; o requisito de segurança é serem únicos para uma dada chave. O Vaultaire pede nonces de 96 bits ao gerador aleatório criptográfico da Apple para a encriptação de operação única e regista o nonce base no cabeçalho de streaming. O risco de colisão depende do número de encriptações feitas com uma chave, por isso a implementação gera um valor novo em vez de apresentar o tamanho de 96 bits como uma garantia vitalícia fixa de uma probabilidade em 2⁹⁶.

Gestão de memória: limpar o estado das chaves ativas

Um erro comum no software de segurança é deixar dados sensíveis na memória por mais tempo do que o necessário. Chaves de encriptação, palavras-passe derivadas e dados desencriptados podem persistir na RAM muito depois de a aplicação ter deixado de os usar. Ferramentas forenses podem fazer dump da memória do dispositivo e procurar estes resíduos, uma técnica conhecida como ataque cold-boot ou análise de dump de memória.

O Vaultaire limita o tempo durante o qual o estado das chaves ativas e os dados desencriptados da interface ficam disponíveis. Quando a aplicação bloqueia ou a sessão é encerrada, o código segue vários caminhos de limpeza:

• O estado do cofre ativo é descartado. A aplicação remove a sessão atual da chave do cofre e exige novo desbloqueio antes de mostrar o conteúdo do cofre.
• Os invólucros de chaves limpam os buffers que lhes pertencem. Os contentores de bytes seguros do Vaultaire sobrescrevem os buffers que lhes pertencem quando esses contentores são desalocados.
• O estado da chave mestra em cache é invalidado. A chave mestra desencriptada mantida para o índice aberto é descartada nos caminhos relevantes de bloqueio e de reposição da cache.
• As caches desencriptadas da interface são limpas onde o Vaultaire as controla. A limpeza de miniaturas e pré-visualizações reduz o estado residual da aplicação, sem alegar controlo sobre cada cópia feita pelo Swift, pelo iOS ou por outro processo.

Da próxima vez que o Vaultaire abrir em estado bloqueado, desenha o padrão e a aplicação volta a derivar a chave do cofre antes de poder autenticar o índice e desembrulhar a chave mestra. Trata-se de limpeza de sessão, não de uma afirmação de que cada cópia transitória em memória foi apagada de forma comprovável com várias passagens ou de que uma referência de chave do Secure Enclave foi destruída. Uma falha faz com que o iOS recupere o processo, mas o código de limpeza não consegue correr depois de cada encerramento abrupto.