A proteção começa antes do upload
Os cofres nativos funcionam localmente sem uma conta Revault. O conteúdo dos arquivos, nomes de arquivos, tipos MIME, miniaturas, nomes de cofres, pastas, tags e favoritos são criptografados no dispositivo. O uso local não carrega arquivos do Vault para Revault. A sincronização e o compartilhamento nativos da nuvem são operações opcionais e separadas.
O modelo pressupõe um sistema operacional confiável, aplicativo instalado e fonte criptográfica aleatória quando um cofre é criado ou desbloqueado. Alguém com apenas arquivos criptografados e wrappers de chaves não pode descriptografá-los sem o segredo necessário. Malware ou um aplicativo comprometido em execução enquanto um cofre está aberto pode capturar texto simples e chaves.
Chaves independentes para cada cofre
Cada cofre começa com uma chave mestra aleatória de 256 bits AES, gerada usando a fonte criptográfica aleatória do sistema operacional. O gesto não determina diretamente esta chave. Cada cofre possui material de chave mestra independente, portanto, a divulgação de uma chave do cofre não resulta em outra.
Um padrão de dispositivo combina sua sequência ordenada de pontos com um segredo de dispositivo aleatório de 256 bits. A entrada resultante é normalizada com NFKC e passada para PBKDF2-HMAC-SHA-256 com um novo salt de 128 bits e 600.000 iterações. A chave derivada de 256 bits envolve a chave mestra usando AES-256-GCM. O aplicativo não salva um padrão de texto simples ou uma impressão digital de padrão separada.
Os padrões usam uma grade 5 × 5 com seis a 25 pontos distintos e devem ser exclusivos entre os vaults registrados no mesmo dispositivo. Um padrão correspondente abre apenas seu cofre; outros nomes e conteúdos do vault permanecem ocultos. Gestos previsíveis são ainda mais fáceis de adivinhar. Uma pessoa que obtém o segredo do dispositivo e seu wrapper criptografado pode tentar adivinhar padrões offline.
A abertura de um cofre nativo requer seu padrão local ou um fluxo de recuperação explícito, não uma conta ou chave de acesso Revault. A sincronização opcional na nuvem usa a autorização Apple ou Google da plataforma, e as compras na loja usam a conta de cobrança da plataforma. Nem a autorização na nuvem nem a compra fornecem uma chave de descriptografia do cofre.
| Propósito | Construção |
|---|---|
| Chave mestra do cofre | Chave AES aleatória de 256 bits |
| Envolvimento de chave | PBKDF2-HMAC-SHA-256 · 600.000 iterações · Sal de 128 bits → AES-256-GCM |
| Metadados e miniaturas | AES-256-GCM · nonce aleatório de 96 bits · etiqueta de autenticação de 128 bits |
| Derivação de chave de arquivo | HKDF-SHA-256 · sal aleatório de 256 bits por arquivo · saída de 256 bits AES |
| Segredo de recuperação | Gerado: 18 palavras aleatórias (198 bits); personalizado: pelo menos 6 palavras distintas e 32–512 caracteres |
Proteção de chave somente para dispositivo
Em iOS, o bloqueio do dispositivo é armazenado como um item não sincronizado Keychain usando proteção WhenUnlockedThisDeviceOnly. É acessível apenas enquanto o dispositivo está desbloqueado e não migra através da Keychain sincronização. O segredo armazenado não é uma chave Secure Enclave.
Em Android, o bloqueio do dispositivo é criptografado usando AES-256-GCM sob uma chave não exportável Android Keystore que requer um dispositivo desbloqueado. O arquivo de bloqueio criptografado reside no diretório sem backup do aplicativo. Keystore o suporte de hardware depende do dispositivo; o aplicativo não promete que todos os dispositivos usem chaves baseadas em hardware.
Os segredos de desbloqueio local são excluídos da sincronização nativa na nuvem e dos backups de cofres portáteis. A posse de uma conta Apple ou Google não recria esses segredos nem desbloqueia automaticamente um cofre restaurado. Um novo dispositivo deve verificar o segredo de recuperação independente e registrar seu próprio padrão.
Confidencialidade e detecção de adulteração
Metadados do Vault, metadados de arquivo, miniaturas e chaves agrupadas usam AES-256-GCM com tags de autenticação de 128 bits. Cada criptografia independente usa um novo nonce aleatório de 96 bits. A descriptografia verifica a tag antes de retornar o texto simples; o texto cifrado modificado ou uma chave errada faz com que a autenticação falhe.
Dados autenticados adicionais vinculam cada objeto criptografado à sua versão de formato, identificador de cofre, identificador de objeto e finalidade. Por exemplo, uma miniatura e um registro de metadados de arquivo usam contextos diferentes. Mover um objeto criptografado para um cofre diferente ou substituí-lo por outro objeto altera o contexto autenticado e falha na verificação.
O contexto autenticado não esconde identificadores e não prova frescura. Um registro mais antigo válido ainda pode ter uma tag válida. As verificações de revisão de aplicativos detectam atualizações simultâneas comuns, mas isso não é uma defesa criptográfica contra um serviço malicioso que reproduz um estado completamente antigo.
Arquivos grandes usam segmentos autenticados
A criptografia de arquivo nativa usa a construção de streaming AES-256-GCM-HKDF-SHA-256 descrita por Tink. iOS usa CryptoKit para AES-GCM e HKDF; Android usa primitivas criptográficas de plataforma. Cada novo fluxo tem um cabeçalho de 40 bytes contendo seu marcador de comprimento, um salt aleatório de 32 bytes e um prefixo nonce aleatório de sete bytes.
HKDF deriva uma chave de criptografia de arquivo separada da chave mestra do vault. Seu contexto inclui os identificadores de vault e arquivo, comprimento de bytes de texto simples e tamanho de segmento configurado. O nonce de 12 bytes de cada segmento combina o prefixo aleatório, um contador de segmento de quatro bytes e um sinalizador de segmento final. Os segmentos carregam tags GCM de 128 bits.
Os aplicativos nativos processam arquivos em segmentos limitados de aproximadamente 5 MiB. Os contadores de segmento, o sinalizador do segmento final e os comprimentos de bytes esperados detectam segmentos alterados, reordenados ou truncados. Cada segmento é autenticado antes do uso, e uma visualização privada é publicada somente após o arquivo ser descriptografado. A saída incompleta é descartada em caso de falha; novas tentativas transferem os bytes criptografados existentes.
A construção segue o Especificação de streaming Tink AES-GCM-HKDF. A implementação e configuração do segmento de Revault não foram auditadas ou certificadas de forma independente pela Tink.
Armazenamento privado, importações e visualizações
Os arquivos criptografados do vault ficam no armazenamento privado do aplicativo. Nomes de arquivos, tipos MIME, pastas, tags, favoritos e miniaturas são registros criptografados autenticados. A filtragem de pesquisa e tags opera nos metadados descriptografados do cofre ativo após o desbloqueio; não há índice de pesquisa de servidor de texto simples.
As importações de fotos, vídeos e arquivos podem usar teste temporário privado antes da criptografia. A captura da câmera no cofre não salva automaticamente uma cópia na galeria. A importação do Photos ou de outro provedor deixa o original desse provedor intacto. A otimização de mídia opcional acontece localmente antes da criptografia e altera apenas mídias recém-importadas.
As visualizações privadas exigem texto simples temporário enquanto estão abertas. Os aplicativos removem suas visualizações temporárias ao fechar, bloquear e subsequente inicialização; iOS aplica proteção completa aos arquivos de visualização descriptografados. Os arquivos exportados explicitamente para outro aplicativo saem da proteção do cofre. A exclusão temporária de arquivos não é uma garantia de apagamento forense.
Sincronização de nuvem nativa opcional
A sincronização está desativada por padrão e ativada separadamente para cada cofre em cada dispositivo. iOS armazena registros criptografados e segmentos de arquivo no banco de dados privado do usuário CloudKit em iCloud. Android usa Google Drive privado appDataFolder. Nenhum dos transportes requer uma conta Revault ou carrega dados de sincronização nativos para a nuvem da web de Revault.
A nuvem recebe metadados criptografados, segmentos de arquivos e wrappers de chaves, e não uma chave mestra de cofre em texto simples, segredo de dispositivo local ou segredo de recuperação. Outro dispositivo na mesma plataforma precisa da mesma conta de nuvem nativa e da chave de recuperação do cofre para registrar seu próprio padrão local. As autorizações Apple e Google controlam o acesso aos registros criptografados, não sua descriptografia.
Desativar a sincronização interrompe futuras transferências para esse cofre a partir do dispositivo atual; as cópias criptografadas existentes na nuvem permanecem. As alterações e exclusões de sincronização podem se propagar e as edições simultâneas podem exigir revisão de conflitos. iCloud e Google Drive são lojas separadas, sem ponte automática entre plataformas. Use uma transferência telefônica criptografada para mover entre o iPhone e Android.
A recuperação é um segundo caminho para a mesma chave
Revault gera uma frase de recuperação contendo 18 palavras escolhidas independentemente de uma lista agrupada de 2.048 palavras, fornecendo 198 bits de aleatoriedade. A criação não oferece frases personalizadas ou regeneração. A frase deriva independentemente uma chave de encapsulamento usando PBKDF2-HMAC-SHA-256 e um sal fresco e, em seguida, encapsula a chave mestra do vault com AES-256-GCM. Qualquer pessoa com a frase e o cofre criptografado pode descriptografá-la. As frases personalizadas e as chaves de recuperação hexadecimais existentes permanecem compatíveis com seus cofres originais.
O segredo de recuperação é mostrado durante a configuração e não é mantido no armazenamento nativo do aplicativo nem carregado no armazenamento nativo em nuvem. Mantenha-o separado dos arquivos criptografados. O registro de outro dispositivo requer o cofre criptografado da conta original da nuvem nativa ou um backup criptografado, além da chave de recuperação. Um segredo não pode restaurar dados de arquivo ausentes e Revault não possui chave de redefinição mantida pelo provedor.
Um backup portátil .qvault contém wrappers de chaves criptografadas, um inventário criptografado autenticado e segmentos de arquivos criptografados. Exclui o segredo de desbloqueio do dispositivo local. A importação verifica o inventário, os metadados e todos os segmentos antes de restaurar em um cofre com novos identificadores, chave mestra, chaves de arquivo e um novo padrão de dispositivo. Salve a nova chave de recuperação após a restauração.
Novas frases de recuperação preservam maiúsculas e minúsculas, normalizam Unicode com NFKC e reduzem espaços em branco extras. As chaves hexadecimais legadas permanecem suportadas. Você pode substituir a frase de recuperação de um cofre em suas configurações depois de salvar a nova frase. Isto substitui o wrapper de recuperação atual; backups antigos e dispositivos que não foram sincronizados ainda podem conter o wrapper antigo. A alteração de um padrão ou frase de recuperação não rotaciona a chave mestra do vault nem revoga cópias. Se o material da chave estiver comprometido, mova os arquivos para um novo cofre com chaves novas.
Migração criptografada de telefone para telefone
A transferência telefônica cria uma cópia criptografada portátil com novos identificadores de cofre, chave mestra, chaves de arquivo e cabeçalhos de fluxo. Seu segredo de transferência independente não pode desbloquear o cofre de origem, e o segredo de recuperação de origem e o segredo de desbloqueio do dispositivo não estão incluídos. O pacote criptografado e o segredo de transferência devem ser entregues separadamente.
O aplicativo receptor autentica o pacote e seus segmentos de arquivo e, em seguida, restaura em um novo cofre com um novo padrão local e chave de recuperação. Isso funciona entre iOS e Android sem conectar suas contas na nuvem. O original permanece no dispositivo antigo; confirme o conteúdo restaurado e salve a nova chave de recuperação antes de excluí-la.
Bloqueio e limpeza de sessão
Os aplicativos móveis são bloqueados imediatamente quando em segundo plano e após 60 segundos de inatividade por padrão. Cada cofre pode selecionar 30 segundos, 1 minuto, 2 minutos, 5 minutos ou 10 minutos. Um cofre compartilhado usa o padrão de 60 segundos. Sair retorna à tela padrão e encerra a sessão descriptografada.
O bloqueio cancela o trabalho da sessão, limpa os metadados descriptografados e o estado de pesquisa, fecha as visualizações, remove arquivos temporários e substitui os buffers de chave de propriedade antes de liberá-los. As chaves de derivação temporária também são apagadas após o uso. Swift e JVM gerenciamento de memória, bibliotecas criptográficas e decodificadores de mídia podem criar cópias; o apagamento imediato de todas as cópias não pode ser garantido.
iOS cobre instantâneos de alternadores de aplicativos com um escudo de privacidade. Android usa o sinalizador de janela segura para restringir capturas de tela e visualizações recentes de aplicativos. Essas proteções da plataforma não impedem que alguém fotografe uma tela desbloqueada e não retraem arquivos exportados anteriormente para outro aplicativo.
Revault Cloud
Revault Cloud é um provedor de armazenamento Pro opcional para sincronização entre plataformas. Segmentos criptografados e metadados de arquivos criptografados são vinculados a uma instalação de cobrança com pseudônimo. O serviço pode observar identificadores de armazenamento, tamanhos, somas de verificação, revisões e atividades de transferência, mas não recebe nenhuma chave de cofre desembrulhada ou frase de recuperação. Um código de conexão aleatório separado autoriza o acesso ao armazenamento; conectar outro dispositivo também requer a frase de recuperação. Os dados existentes na nuvem permanecem legíveis para recuperação após a expiração do Pro.
Transportes de compartilhamento nativo e controles de acesso
Em iOS, um convite privado e somente leitura CloudKit coloca o instantâneo criptografado em uma hierarquia de registros de compartilhamento separada, fora da zona de sincronização pessoal. Apple controla o acesso a convites; o destinatário ainda precisa do segredo de descriptografia separado. CloudKit os convites não impõem a contagem de sessões de acesso do servidor, expiração fixa ou temporizador de destruição. O proprietário pode impedir o acesso futuro CloudKit.
Os compartilhamentos entre plataformas carregam partes criptografadas para o serviço de compartilhamento de Revault. Capacidades independentes de leitura e gerenciamento aleatórios de 256 bits são armazenadas como SHA-256 hashes. O link do site carrega a capacidade de leitura em seu fragmento, não o segredo de descriptografia. Abri-lo cria links diretos para um cofre compartilhado e solicita o segredo do remetente; nenhum padrão pessoal ou cofre existente é necessário. Os cofres pessoais permanecem bloqueados.
Os compartilhamentos de servidor controlados impõem sessões de acesso máximo do remetente, expiração fixa em 30 dias, revogação e permissão de exportação opcional. A sessão é concedida de forma atômica e tem duração máxima de 15 minutos, delimitada pelos prazos da ação. Um acesso conta quando a sessão é concedida, mesmo se o download ou a descriptografia falhar. O visualizador verifica o acesso contínuo e fecha no prazo.
SHA-256 somas de verificação verificam as partes transferidas, enquanto a criptografia autenticada verifica seu conteúdo. Quando a exportação é permitida, o visualizador pode salvar uma cópia criptografada .qvault que abre com o segredo do compartilhamento. Desabilitar a exportação remove essa ação do aplicativo; ele não pode impedir criptograficamente capturas de tela ou um cliente modificado retendo texto simples. A exclusão de um arquivo de origem não revoga um compartilhamento criado de forma independente.
Atividade opcional do vault
Os logs de auditoria nativos estão desativados por padrão e configurados por cofre em cada dispositivo. Os últimos 500 eventos locais são criptografados com a chave mestra do cofre e um contexto autenticado dedicado. Eles excluem chaves, padrões, conteúdo de arquivos e dados de outros cofres, não são sincronizados e podem ser apagados ou desativados. Eles não são evidências infalsificáveis. Os desbloqueios com falha não são atribuídos a um cofre.
Novos compartilhamentos controlados criados com o registro em log habilitado retêm até 100 carimbos de data/hora da sessão de acesso no serviço de compartilhamento. Somente a capacidade de gerenciamento pode recuperá-los; o log não contém identidade do destinatário ou segredo de descriptografia. Desabilitar o log local afeta compartilhamentos futuros. Os logs de compartilhamento existentes mantêm suas configurações originais até a revogação ou expiração e limpeza.
Fotos de invasão criptografadas opcionais
Os proprietários podem ativar alertas de invasão separadamente para cada cofre em cada dispositivo. Após três padrões incomparáveis, o aplicativo em primeiro plano pode capturar uma foto da câmera frontal, sujeito à permissão, disponibilidade da câmera e tempo de espera de um minuto. Os indicadores da câmera do sistema permanecem visíveis. Os últimos dez alertas são armazenados localmente e nunca adicionados às Fotos ou carregados. Um padrão sem correspondência não identifica um cofre de destino, portanto, cada cofre ativado recebe um registro de tentativa de dispositivo criptografado separadamente.
Uma chave pública RSA-3072 dedicada envolve uma nova chave AES-GCM de 256 bits para cada alerta usando OAEP com SHA-256 e MGF1-SHA-256. Isso permite a criptografia enquanto o cofre está bloqueado. A chave privada correspondente é criptografada na chave mestra do cofre com um contexto autenticado dedicado. Somente desbloquear esse cofre pode descriptografar suas fotos. Os alertas aparecem na visualização de auditoria independentemente do registro de atividades normais e podem ser apagados nas configurações de Alertas de invasão. Eles não são evidências infalsificáveis.
Safe Exit remove o acesso local
Um cofre em um dispositivo pode ser designado para Safe Exit. Inserir seu padrão o abre normalmente enquanto remove outros registros do cofre local, pedaços criptografados, material de desbloqueio de dispositivo e alterações na fila. O aplicativo mantém uma lista de permissões local persistente para que a sincronização não possa preencher novamente os cofres excluídos silenciosamente. As transferências criptografadas em voo ainda podem terminar.
As cópias nativas da nuvem e as cópias em outros dispositivos permanecem. A recuperação explícita requer a chave de recuperação do cofre excluído antes que um novo padrão local seja registrado. Um cofre somente offline sem um backup separado pode ser perdido. Esta configuração se aplica à instalação atual, não a todos os dispositivos que usam a mesma conta na nuvem.
Safe Exit não é garantido o apagamento ou ocultação forense. Armazenamento flash, caches do sistema operacional, backups e exportações anteriores podem reter rastros. A remoção de dados do aplicativo ou a reinstalação pode remover o limite de isolamento local; os registros na nuvem podem então ser descobertos novamente por meio da conta da nuvem nativa. Somente o segredo de recuperação pode desbloquear esses registros.
O que permanece visível
A criptografia oculta o conteúdo, não todas as informações operacionais. Os registros locais e os provedores de nuvem podem observar identificadores, relacionamentos de registros, contagens de objetos, tamanhos, revisões, carimbos de data/hora, wrappers de chaves criptografadas e cabeçalhos de fluxo. Os identificadores usam UUIDv7 e incluem informações de tempo de criação; eles não são segredos. Apple ou Google podem associar a atividade de sincronização nativa à conta da plataforma.
O serviço de compartilhamento controlado do Revault pode observar tamanhos de pacotes criptografados, somas de verificação de peças, configurações de expiração, contagens de sessões de acesso e carimbos de data e hora de sessão opcionais, mas não o segredo de descriptografia entregue separadamente. O compartilhamento CloudKit expõe o convite e as informações do participante para Apple. Os registros operacionais e de rede podem expor informações de conexão. Revault não fornece anonimato ou resistência à análise de tráfego.
HTTPS protege solicitações de rede em trânsito. A criptografia autenticada no dispositivo protege separadamente o conteúdo do cofre armazenado localmente e na nuvem. Nem a criptografia de transporte nem o texto cifrado escondem todos os fatos sobre quando, onde ou quantos dados são transferidos.
Onde termina a proteção
Um cofre desbloqueado necessariamente expõe informações descriptografadas à sessão do aplicativo. Malware, um sistema operacional ou aplicativo comprometido, alguém visualizando a tela ou um destinatário não confiável podem capturá-lo. O armazenamento de chaves somente no dispositivo é um limite adicional e não uma garantia contra um dispositivo totalmente comprometido. Um padrão previsível não é seguro quando seu segredo local é comprometido.
A criptografia não impede a exclusão da nuvem, o ransomware, a perda de um segredo de recuperação, a retenção de registros por um provedor ou a reversão de todo um estado criptografado anteriormente válido. Mantenha backups criptografados independentes e verifique a recuperação antes de remover um dispositivo antigo. A revogação não pode recuperar capturas de tela, exportações ou cópias já retidas por outra pessoa.
Revault não passou por uma auditoria de segurança independente. Estas são descrições do design criptográfico implementado, não uma certificação ou garantia contra qualquer intrusão.
Referências criptográficas
NIST SP 800-38D — GCM criptografia autenticadaRFC 8018 — PBKDF2RFC 5869 – HKDFCofres de navegador existentes
Esta referência descreve os aplicativos nativos. Os cofres do navegador existentes têm uma conta separada, armazenamento de dispositivo e modelo de nuvem da web. Os uploads S3 específicos do navegador e os links de compartilhamento do navegador não são sincronizados nativamente na nuvem. A conta do navegador não conecta você aos aplicativos móveis; use um backup criptografado e sua chave de recuperação para mover os dados existentes do navegador para um cofre nativo.