A proteção começa antes do upload
O conteúdo dos arquivos, nomes de arquivos, tipos MIME, miniaturas, nomes de vaults e nomes e estruturas de pastas são criptografados em seu dispositivo antes de serem carregados. O serviço armazena texto cifrado e chaves agrupadas. Um invasor que obtém apenas esses registros armazenados não obtém a chave do cofre em texto simples, o segredo do dispositivo ou a chave de recuperação.
Isso pressupõe que o navegador, o sistema operacional, o código do aplicativo entregue e o gerador de números aleatórios sejam confiáveis quando você cria ou desbloqueia um cofre. A criptografia em repouso não pode proteger um cofre desbloqueado contra códigos maliciosos em execução no seu dispositivo.
Chaves independentes para cada cofre
Cada cofre começa com uma chave mestra de 256 bits AES gerada aleatoriamente. A chave é gerada pelo gerador criptográfico de números aleatórios do navegador, em vez de ser derivada diretamente do seu gesto. Chaves de cofre separadas limitam o efeito da divulgação de uma única chave de cofre.
Um padrão de dispositivo combina a sequência ordenada de pontos com um segredo de dispositivo aleatório de 256 bits. PBKDF2 com HMAC-SHA-256, um novo salt de 128 bits e 600.000 iterações deriva uma chave de encapsulamento de 256 bits. AES-256-GCM então criptografa a chave mestra sob essa chave de encapsulamento. O serviço recebe o wrapper criptografado, seu sal e parâmetros de derivação pública. O segredo do dispositivo permanece no banco de dados local IndexedDB deste navegador.
Os padrões usam apenas uma grade 5 × 5 e pelo menos seis pontos distintos. Os formatos de padrão anteriores não são suportados. Os cofres existentes precisam das chaves de recuperação para registrar um novo padrão. O tamanho da grade não é uma promessa de força da senha: gestos previsíveis ainda são mais fáceis de adivinhar. O segredo do dispositivo adiciona proteção contra alguém que possui apenas os registros do servidor, mas não é uma chave apoiada por hardware. Alguém que copia o segredo local e o wrapper pode tentar adivinhar padrões offline.
As chaves de acesso autenticam sua conta usando respostas de desafio de chave pública. A autenticação da conta não deriva uma chave do cofre nem descriptografa seus arquivos. Uma sessão de conta válida e um desbloqueio bem-sucedido do cofre são requisitos separados no fluxo normal do aplicativo.
| 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 | 192 bits aleatórios, exibidos como seis grupos de caracteres hexadecimais |
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
O conteúdo do arquivo usa a construção de streaming AES-256-GCM-HKDF-SHA-256 descrita por Tink, implementada usando primitivas criptográficas do navegador. Cada novo fluxo de arquivo possui 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 7 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.
O aplicativo processa arquivos em segmentos limitados de aproximadamente 5 MiB. As posições dos segmentos, o sinalizador do segmento final e os comprimentos de bytes esperados fazem com que os segmentos trocados, alterados ou truncados falhem na verificação. Os downloads autenticam cada segmento antes de liberá-lo; um erro no final de um fluxo pode deixar um download incompleto, portanto, a conclusão bem-sucedida é importante. As novas tentativas de upload reutilizam bytes já criptografados em vez de criptografar novo conteúdo com o mesmo segmento nonce.
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.
A recuperação é um segundo caminho para a mesma chave
Um segredo de recuperação é gerado a partir de 24 bytes aleatórios, fornecendo 192 bits de entrada aleatória. Ele deriva independentemente uma chave de encapsulamento usando PBKDF2-HMAC-SHA-256 e seu próprio salt, e criptografa a mesma chave mestra do vault com AES-256-GCM. Qualquer pessoa que obtiver o segredo de recuperação e uma cópia do cofre criptografado poderá descriptografá-lo.
O segredo de recuperação é exibido durante a configuração e não é armazenado pelo serviço em texto simples. Mantenha-o separado dos seus arquivos criptografados. A limpeza dos dados do navegador remove o segredo do dispositivo; a recuperação do acesso requer a cópia criptografada na nuvem da sua conta e a chave de recuperação, ou um backup criptografado exportado e sua chave de recuperação. Não há chave mestra de descriptografia mantida pelo provedor.
Um kit de recuperação contém um segredo e um wrapper de chave, mas nenhum conteúdo de arquivo. Um backup criptografado contém um inventário autenticado e segmentos de arquivos criptografados, sem o segredo do dispositivo do navegador. A importação verifica os dados criptografados e cria um novo cofre com novos identificadores e chaves.
A alteração de um padrão substitui o invólucro deste dispositivo. Ele não gira a chave mestra do cofre, não revoga outro dispositivo, invalida backups antigos ou altera um segredo de recuperação existente. Se uma chave do cofre ou um segredo de recuperação for comprometido, mova os dados para um novo cofre com chaves novas.
Os compartilhamentos nativos usam criptografia independente
Por predefinição, as partilhas móveis protegem as chaves das versões selecionadas com uma nova chave de partilha e reutilizam os ficheiros encriptados. O isolamento adicional opcional volta a encriptá-los. As chaves do cofre original permanecem privadas. Cifras idênticas permitem correlacionar partilhas; nenhum modo recupera uma cópia guardada pelo destinatário.
iOS pode colocar este texto cifrado em uma hierarquia de registros CloudKit separada com um convite privado somente leitura. Não compartilha a zona de sincronização do cofre. Os compartilhamentos nativos de plataforma cruzada usam partes de servidor limitadas com somas de verificação SHA-256. Capacidades independentes de leitura e gerenciamento aleatórios de 256 bits são armazenadas como hashes no servidor. O segredo de descriptografia é passado separadamente e nunca carregado. As ações controladas expiram no horário escolhido pelo remetente, em até 30 dias. O serviço conta atomicamente as sessões de acesso e impõe o máximo, a expiração e a revogação escolhidos. Uma sessão de download dura no máximo 15 minutos e nunca ultrapassa a expiração do compartilhamento.
Os receptores autenticam cada segmento criptografado e abrem um cofre compartilhado isolado com o segredo separado do remetente. Nenhuma conta, cofre pessoal ou padrão é necessário. Os cofres pessoais permanecem bloqueados. Quando a exportação é permitida, os destinatários podem salvar uma cópia criptografada .qvault que abre com esse segredo de compartilhamento. Caso contrário, os controlos de exportação estão ausentes. A sessão temporária valida o acesso contínuo. Estes são controles de aplicativos: capturas de tela, clientes modificados e cópias retidas não podem ser evitados criptograficamente. Os compartilhamentos são instantâneos sem atualizações contínuas de origem. Convites irrestritos CloudKit não impõem contagens de acesso ou expiração automática; o acesso dura até que o proprietário pare de compartilhar. A remoção de um original não revoga seu compartilhamento separado e nenhuma revogação pode recuperar uma cópia já retida.
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.
Uploads criptografados para seu próprio bucket
As configurações de armazenamento de um cofre podem conectar este navegador diretamente a um endpoint HTTPS compatível com S3 especificado pelo usuário. Os arquivos do dispositivo selecionado são criptografados localmente usando a mesma construção de arquivo. Cada um se torna um objeto separado e portátil .qvault contendo um inventário criptografado autenticado e chaves de cofre agrupadas. Nomes de objetos aleatórios evitam expor os nomes de arquivos originais. A restauração requer o objeto baixado e a chave de recuperação do cofre.
A configuração e as credenciais do endpoint são criptografadas na chave mestra do cofre com um contexto autenticado dedicado e mantidas no IndexedDB deste dispositivo. Eles não são sincronizados ou enviados para a API de Revault. A assinatura de solicitação usa AWS Signature versão 4, HMAC-SHA-256 e um hash de cada corpo de solicitação limitado. As partes multipartes de oito MiB transportam bytes já criptografados diretamente para o provedor de armazenamento. O acesso ao bucket permanece regido pelas permissões desse provedor e pela política CORS.
O provedor pode ver identificadores de chave de acesso, caminhos de objetos, tamanhos de bytes, tempos de upload e informações de conexão. Mantenha o bucket privado e suas credenciais com escopo definido para as operações necessárias. Os objetos carregados são independentes de Revault sincronização e compartilhamento na nuvem. Bloqueio ou cancelamento de tentativas de abortar uploads inacabados; o fechamento da guia ou a perda de conectividade podem deixar partes órfãs, portanto, configure uma regra de ciclo de vida de upload incompleto. Safe Exit remove as credenciais de armazenamento local de outros cofres, mas não exclui objetos de seus buckets.
Safe Exit remove o acesso local
Você pode designar um vault neste navegador como um vault Safe Exit. Entrar no padrão desse cofre abre-o normalmente, sem confirmação de gatilho ou aviso de conclusão. Os snapshots locais, os pedaços criptografados, os segredos do dispositivo e as alterações na fila de outros cofres são removidos. Os dados não sincronizados podem ser perdidos.
Um limite local persistente impede que esses cofres sejam listados ou restaurados automaticamente por meio de sincronização neste navegador. Suas cópias criptografadas na nuvem e cópias em outros dispositivos permanecem inalteradas. A recuperação é explícita, um cofre de cada vez, e requer a chave de recuperação desse cofre antes que um novo padrão de dispositivo possa ser registrado.
Trata-se de remoção de acesso local, não de apagamento físico garantido ou ocultação forense. Perfis de navegador, instantâneos do sistema de arquivos, downloads anteriores, capturas de tela, registros de serviço e outro dispositivo podem reter evidências. Limpar os dados locais deste navegador também limpa o limite de isolamento local; uma nova instalação pode listar os cofres na nuvem da conta novamente após a autenticação.
O que permanece visível
A criptografia protege o conteúdo, não todos os fatos sobre armazenamento. O serviço pode observar associações de contas, identificadores aleatórios de objetos, contagens de objetos, tamanhos de bytes, revisões, carimbos de data/hora, wrappers criptografados, cabeçalhos de fluxo e atividades de solicitação. Os registros operacionais e de rede podem revelar informações de conexão. Este não é um sistema de anonimato e não oferece resistência à análise de tráfego.
A criptografia de transporte protege as solicitações em trânsito quando o aplicativo é servido por HTTPS. Isso é separado da criptografia do lado do cliente, que mantém o conteúdo dos arquivos armazenados criptografado no serviço.
Onde termina a proteção
A navegação privada geralmente exclui o armazenamento local quando a sessão privada termina. Uma solicitação de armazenamento persistente não torna uma sessão anônima permanente. As cópias sincronizadas na nuvem permanecem, mas padrões locais, alterações não sincronizadas, arquivos em cache e configurações Safe Exit podem ser perdidos. Uma nova sessão privada precisa de acesso à conta e da sua chave de recuperação para registrar um novo padrão.
O aplicativo descarta a referência de chave do cofre na memória e revoga URLs de visualização privados quando bloqueado. Ele bloqueia automaticamente quando está oculto ou após cinco minutos de inatividade. Os aplicativos nativos também são bloqueados quando estão em segundo plano, removem visualizações temporárias e limpam buffers de chaves de propriedade quando as operações são concluídas. O gerenciamento de memória do navegador, Swift e JVM não pode garantir o apagamento imediato de cada cópia de chave ou buffer de mídia decodificado.
Malware, uma extensão insegura, código de aplicativo comprometido ou alguém visualizando uma tela desbloqueada podem capturar texto simples e segredos. A criptografia não pode impedir a negação de serviço da conta, a exclusão de objetos na nuvem, o ransomware, a perda de um segredo de recuperação ou a retenção de dados por um serviço. Mantenha um backup criptografado separado e proteja o próprio dispositivo.
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.