Arquitectura de segurança: Base técnica completa

A base de segurança do Vaultaire usa AES-256-GCM para encriptação de ficheiros, PBKDF2 com 600 000 iterações para derivação de chaves, ChaCha20 para protecção de metadados e o Secure Enclave da Apple para gestão de chaves por hardware. Cada ficheiro recebe o seu próprio vector de inicialização, cada cofre o seu próprio salt, e as chaves são limpas da memória quando a aplicação bloqueia.

A base criptográfica

A maioria das aplicações de segurança escolhe um algoritmo de encriptação e fica por aí. O Vaultaire usa seis mecanismos criptográficos diferentes a funcionar em simultâneo, cada um escolhido para um modelo de ameaça específico. O conteúdo dos ficheiros é encriptado com uma cifra. Os metadados são encriptados com outra. As chaves são derivadas por uma função computacionalmente dispendiosa. O hardware de segurança armazena o resultado. E a arquitectura de conhecimento zero garante que nem as pessoas que criaram o Vaultaire têm acesso aos seus dados.

Isto não é complexidade pela complexidade. Cada camada aborda uma superfície de ataque diferente. O AES-256-GCM garante a encriptação em massa de ficheiros porque é rápido e acelerado por hardware nos chips Apple. O ChaCha20 protege os metadados porque tem tempo constante e é resistente a ataques de temporização de cache. O PBKDF2 deriva chaves através de centenas de milhares de iterações, tornando os ataques de força bruta computacionalmente dispendiosos. O Secure Enclave armazena material de chave porque a protecção apenas por software não é suficiente se alguém tiver acesso físico ao seu dispositivo.

Estas camadas juntas formam uma arquitectura de defesa em profundidade. Um atacante teria de quebrar múltiplos primitivos criptográficos independentes em simultâneo, um cenário firmemente ancorado no domínio do matematicamente impossível.

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

Cada fotografia, vídeo e documento armazenado no Vaultaire é encriptado com AES-256-GCM, Advanced Encryption Standard com chave de 256 bits no Galois/Counter Mode. É a mesma cifra que o governo dos EUA usa para informação classificada de alto secreto. Esta não é uma comparação de marketing. É literalmente o mesmo algoritmo, o mesmo comprimento de chave e o mesmo modo operacional.

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.

Por 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 sector 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

A sua chave de encriptação não surge do nada. É derivada do seu padrão (ou frase secreta) através de uma função de derivação de chaves, um algoritmo especificamente concebido para transformar a entrada humana numa chave criptográfica. O Vaultaire usa PBKDF2 (Password-Based Key Derivation Function 2) com HMAC-SHA512, um padrão recomendado pelo NIST usado em todo o mundo em sistemas governamentais e financeiros.

Como o PBKDF2 protege o seu padrão

A ideia fundamental por trás do PBKDF2 é a lentidão deliberada. Pega no seu padrão e passa-o através de centenas de milhares de rondas de hashing criptográfico. Cada ronda leva uma fracção minúscula de segundo. Para si, desenhar o padrão e aguardar a desencriptação é quase instantâneo. Para um atacante a tentar padrões por força bruta, essa fracção de segundo multiplica-se por cada tentativa individual.

O Vaultaire configura o PBKDF2 com um número elevado de iterações especificamente calibrado para hardware moderno. Com estes parâmetros, cada tentativa de derivação de chave requer trabalho computacional significativo. Um atacante a tentar mil milhões de padrões precisaria de anos de computação contínua por cofre. E isso assumindo que conhece o salt, que é único para cada cofre e armazenado no seu dispositivo.

Cada cofre recebe o seu próprio salt criptograficamente aleatório. Isso significa que dois utilizadores que por acaso desenhem o mesmo padrão criam chaves de encriptação completamente diferentes. Tabelas de pesquisa pré-computadas (tabelas arco-íris) são inutilizáveis porque o salt torna a derivação de chave de cada cofre única. Um atacante tem de começar do zero para cada cofre que visa.

ChaCha20: Protecçã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 exactamente 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 encripta todos os metadados com ChaCha20, uma cifra de fluxo concebida por Daniel J. Bernstein. O ChaCha20 é usado ao lado do AES, não em vez dele, por uma razão específica: diversidade criptográfica.

Por que uma cifra separada para metadados?

Usar o mesmo algoritmo para o conteúdo dos ficheiros e os metadados significaria que uma ruptura teórica contra esse algoritmo revelaria tudo de uma vez. Ao usar AES-256-GCM para o conteúdo dos ficheiros e ChaCha20 para os metadados, o Vaultaire garante que mesmo no caso extremamente improvável de uma cifra ser comprometida, a outra camada permanece intacta.

O ChaCha20 também tem vantagens práticas para metadados. É uma cifra puramente em software, não depende de instruções de hardware AES, garantindo desempenho perfeitamente constante independentemente dos dados encriptados. Isso elimina canais laterais de temporização de cache, uma classe de ataques onde um adversário mede os tempos de encriptação para inferir informações sobre a chave ou o texto simples. Para dados estruturados pequenos como metadados, esta propriedade de tempo constante é particularmente importante.

Arquitectura 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 hackeada, 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 é construído sobre uma arquitectura de conhecimento zero. Isso significa que a empresa que faz o Vaultaire nunca tem acesso às suas chaves de encriptação, ao seu padrão, à sua frase secreta, nem aos seus dados não encriptados. Não durante a sincronização. Não durante a cópia de segurança. Nunca. As operações criptográficas ocorrem exclusivamente no seu dispositivo. O que sai do seu dispositivo, se é que sai alguma coisa, já está encriptado com chaves que apenas você possui.

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

Se uma autoridade policial entregar ao Vaultaire uma intimação a exigir os seus dados, a empresa pode cumprir completamente e entregar exactamente nada utilizável. Não há chaves a entregar. Não há palavra-passe mestra. Não há portas traseiras. Os blobs encriptados armazenados no iCloud são matematicamente indistinguíveis de ruído aleatório sem a sua chave, e a sua chave existe apenas na sua cabeça (como padrão) e temporariamente no Secure Enclave do seu dispositivo (enquanto a aplicação está aberta).

Esta não é uma decisão de política. É uma decisão de arquitectura. O Vaultaire não pode aceder aos seus dados, independentemente da intenção, incentivo ou pressão legal. O sistema está concebido de forma a que essa capacidade não exista.

Integração do Secure Enclave

A segurança apenas por software tem um limite. Independentemente de quão cuidadosamente uma aplicação gere as chaves de encriptação na memória, o sistema operativo, outras aplicações ou ferramentas de acesso físico poderiam teoricamente ler essa memória. O Secure Enclave da Apple elimina esta vulnerabilidade fornecendo um ambiente isolado por hardware para operações de chave.

O Secure Enclave é um co-processador dedicado incorporado em cada iPhone moderno. Tem a sua própria memória encriptada, o seu próprio processo de arranque e a sua própria fronteira de segurança. As chaves armazenadas no Secure Enclave nunca saem dele, nem o processador principal as consegue ler. Em vez disso, a aplicação envia dados para o Secure Enclave, que executa operações criptográficas internamente e devolve apenas o resultado.

O Vaultaire usa o Secure Enclave para gestão de chaves. Quando desenha o padrão e a função de derivação de chaves cria uma chave de encriptação, essa chave é entregue ao Secure Enclave. Todas as operações de encriptação e desencriptação subsequentes são delegadas ao hardware. A chave nunca existe no espaço de memória da aplicação de uma forma que um depurador, ferramenta de jailbreak ou sistema de imagem forense pudesse extrair.

Isso significa que mesmo que um atacante tivesse acesso root ao seu iPhone, um cenário que requer um jailbreak sofisticado, as chaves de encriptação permanecem inacessíveis. O Secure Enclave é um chip separado com o seu próprio silício. Comprometer o iOS não significa comprometer o enclave.

Vectores de inicialização por ficheiro

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

O Vaultaire elimina isso gerando um vector de inicialização (IV) único, criptograficamente aleatório, para cada ficheiro individual. O IV é combinado com a chave de encriptação na operação AES-256-GCM, garantindo que mesmo ficheiros byte-a-byte idênticos produzem texto cifrado completamente diferente. Duas cópias da mesma fotografia, encriptadas com a mesma chave, parecerão dados aleatórios completamente não relacionados.

Os IVs são armazenados ao lado dos ficheiros encriptados, mas não são secretos: a sua segurança deriva da unicidade, não da confidencialidade. Cada IV é gerado usando o gerador de números aleatórios criptográficos do dispositivo, que extrai entropia de fontes de ruído de hardware. A probabilidade de gerar o mesmo IV duas vezes é astronomicamente pequena: aproximadamente 1 em 2⁹⁶ para IVs GCM de 96 bits.

Gestão de memória: Chaves que se autodestroem

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, senhas 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 aborda a gestão de memória de forma agressiva. Quando fecha a aplicação ou bloqueia o cofre, ocorre imediatamente por ordem:

• As chaves de encriptação são sobrescritas. As localizações de memória que guardam material de chave são preenchidas com zeros, depois dados aleatórios, depois zeros de novo. Não é simples desalocação: a memória é activamente apagada para prevenir a recuperação.
• O material de chave derivado é removido. Os valores intermédios do cálculo PBKDF2, os buffers temporários e todo o cache de dados desencriptados são zerados.
• As chaves do Secure Enclave são invalidadas. As referências de chaves no Secure Enclave são marcadas para destruição, garantindo que não podem ser reutilizadas sem nova derivação a partir do padrão.
• As miniaturas e pré-visualizações desencriptadas são apagadas. Todo o cache de dados de imagem na memória é sobrescrito antes do fecho completo da aplicação.

Na próxima abertura do Vaultaire, começa do zero. Desenha o seu padrão, a chave é derivada de fresco e o Secure Enclave recebe uma nova referência de chave. Não há token de sessão, não há credenciais em cache, não há atalhos. Cada abertura da aplicação é criptograficamente independente da anterior.