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

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

A Pilha Criptográfica

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

Isso não é complexidade por si só. Cada camada aborda 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 reempacotar uma chave em vez de criptografar novamente todos os arquivos. Keychain proteção de dados 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 AES-GCM autenticação, e um dispositivo desbloqueado comprometido pode observar chaves ou texto simples no processo do aplicativo. A arquitetura, portanto, depende da entropia de credenciais, PBKDF2 custo, iOS proteção do dispositivo e manuseio correto da criptografia autenticada, bem como a 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. Vaultaire também usa AES-GCM para índices de vault, 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

Vaultaire deriva chaves diferentes para trabalhos diferentes. O padrão e todo o dispositivo Keychain alimentação com sal PBKDF2-HMAC-SHA512 por 600.000 iterações para produzir a chave do cofre local. Uma derivação de padrão determinístico produz a chave de backup em nuvem separada. A frase de recuperação normalizada abrange 800.000 PBKDF2 iterações para produzir a chave para 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 PBKDF2 é um trabalho deliberado. Ele pega o padrão serializado ou frase normalizada e executa centenas de milhares de HMAC-SHA512 iterações. Um usuário legítimo paga esse custo uma vez durante uma tentativa de desbloqueio ou recuperação. Um invasor paga por cada candidato, embora as escolhas paralelas de hardware e implementação determinem a taxa real de adivinhação.

Configurações do Vaultaire PBKDF2 com 600.000 iterações para chaves derivadas de padrões. Isso torna cada suposição mais cara, mas uma estimativa de ataque responsável deve indicar um tempo medido por candidato e suposições de hardware. Exatamente 1 ms por candidato, 1.000.000.000 de suposições seriais 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 de padrão local usa um salt criptograficamente aleatório para o dispositivo, armazenado como WhenUnlockedThisDeviceOnly Keychain item. 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 salt 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 MIME tipos são codificados em cabeçalhos de arquivos criptografados. O índice do vault criptografado contém registros de arquivos, datas, informações de tamanho, layout de armazenamento e a chave mestra agrupada. Os dados em miniatura 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. 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 reivindicar a 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 agrupa a chave mestra aleatória; a chave mestra protege o material do arquivo. CryptoKit cria caixas seladas autenticadas com novos nonces, enquanto o formato de streaming do Vaultaire deriva um nonce distinto para cada pedaço ordenado. As garantias relevantes vêm da separação de chaves, da disciplina de uso único 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.

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

O Que Conhecimento Zero Significa na Prática

Se uma agência de aplicação da lei enviar à Vaultaire uma intimação exigindo 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. Criptografado iCloud registros residem no usuário CloudKit banco de dados privado. No dispositivo, entretanto, o material de recuperação é mantido de forma criptografada. Keychain banco de dados e chaves simétricas existem na memória do aplicativo enquanto 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 enviado, iOS, o dispositivo desbloqueado e a implementação criptográfica ainda podem processar dados legíveis e devem ser confiáveis adequadamente.

Keychain e o limite do processo de aplicativo

da Apple Secure Enclave pode proteger chaves privadas suportadas e participa de partes da arquitetura de segurança da plataforma, mas suas APIs públicas não aceitam uma autorização arbitrária PBKDF2-chave simétrica derivada e executar Vaultaire AES-GCM operações de arquivo dentro do coprocessador. Vaultaire, portanto, não descreve sua cifra de cofre como Secure Enclave AES.

Vaultaire usa comum iOS Keychain itens de senha genérica para o salt do dispositivo aleatório, 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. Keychain e a proteção de dados criam um limite significativo para o dispositivo, especialmente quando o telefone está bloqueado, mas essa arquitetura é diferente de uma arquitetura não exportável Secure Enclave chave.

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

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

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.

Vaultaire evita texto cifrado determinístico gerando um novo nonce criptográfico para cada AES-256-GCM operação de vedação. 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. 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 um valor fixo de um em 2.⁹⁶ garantia vitalícia.

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 do vault ativo foi 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 wrappers de chaves limpam os buffers de propriedade. 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 reivindicar controle sobre cada cópia feita pelo Swift, iOSou 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 vault novamente antes de poder autenticar o índice e desembrulhar 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 que um Secure Enclave referência chave foi destruída. Um acidente causa iOS para recuperar o processo, mas o código de limpeza não pode ser executado após cada encerramento abrupto.