La protection démarre avant le téléchargement
Le contenu des fichiers, les noms de fichiers, les types MIME, les vignettes, les noms de coffre-fort ainsi que les noms et la structure des dossiers sont cryptés sur votre appareil avant d'être téléchargés. Le service stocke le texte chiffré et les clés encapsulées. Un intrus qui obtient uniquement ces enregistrements stockés n'obtient pas la clé du coffre-fort en texte brut, le secret de l'appareil ou votre clé de récupération.
Cela suppose que le navigateur, le système d'exploitation, le code d'application fourni et le générateur de nombres aléatoires sont dignes de confiance lorsque vous créez ou déverrouillez un coffre-fort. Le chiffrement au repos ne peut pas protéger un coffre-fort déverrouillé contre le code malveillant exécuté sur votre appareil.
Clés indépendantes pour chaque coffre-fort
Chaque coffre-fort commence par une clé principale AES de 256 bits générée aléatoirement. La clé est générée par le générateur de nombres aléatoires cryptographiques du navigateur, plutôt que d’être dérivée directement de votre geste. Des clés de coffre-fort distinctes limitent l’effet de la divulgation d’une seule clé de coffre-fort.
Un modèle de périphérique combine la séquence de points ordonnée avec un secret de périphérique aléatoire de 256 bits. PBKDF2 avec HMAC-SHA-256, un nouveau sel de 128 bits et 600 000 itérations dérivent une clé d'encapsulation de 256 bits. AES-256-GCM chiffre ensuite la clé principale sous cette clé d'encapsulation. Le service reçoit le wrapper chiffré, son sel et les paramètres de dérivation publics. Le secret de l’appareil reste dans la base de données IndexedDB locale de ce navigateur.
Les modèles utilisent uniquement une grille 5 × 5 et au moins six points distincts. Les formats de modèles précédents ne sont pas pris en charge. Les coffres-forts existants ont besoin de leurs clés de récupération pour inscrire un nouveau modèle. La taille de la grille n'est pas une promesse de force du mot de passe : les gestes prévisibles sont encore plus faciles à deviner. Le secret de l'appareil ajoute une protection contre quelqu'un qui ne dispose que des enregistrements du serveur, mais il ne s'agit pas d'une clé matérielle. Quelqu'un qui copie à la fois le secret local et le wrapper peut tenter de deviner un modèle hors ligne.
Les clés d'accès authentifient votre compte à l'aide de réponses de défi à clé publique. L'authentification du compte ne dérive pas de clé de coffre-fort et ne décrypte pas vos fichiers. Une session de compte valide et un déverrouillage réussi du coffre-fort sont des exigences distinctes dans le flux normal de candidature.
| But | Construction |
|---|---|
| Clé principale du coffre-fort | Clé AES aléatoire de 256 bits |
| Emballage des clés | PBKDF2-HMAC-SHA-256 · 600 000 itérations · Sel 128 bits → AES-256-GCM |
| Métadonnées et vignettes | AES-256-GCM · nom occasionnel aléatoire de 96 bits · étiquette d'authentification de 128 bits |
| Dérivation de clé de fichier | HKDF-SHA-256 · sel aléatoire 256 bits par fichier · sortie AES 256 bits |
| Secret de récupération | 192 bits aléatoires, affichés sous forme de six groupes de caractères hexadécimaux |
Confidentialité et détection d'altération
Les métadonnées du coffre-fort, les métadonnées de fichiers, les miniatures et les clés encapsulées utilisent AES-256-GCM avec des balises d'authentification de 128 bits. Chaque cryptage indépendant utilise un nouveau nom occasionnel aléatoire de 96 bits. Le déchiffrement vérifie la balise avant de renvoyer le texte en clair ; un texte chiffré modifié ou une clé erronée entraîne l'échec de l'authentification.
Des données authentifiées supplémentaires lient chaque objet chiffré à sa version de format, son identifiant de coffre-fort, son identifiant d'objet et son objectif. Par exemple, un enregistrement de métadonnées de miniature et de fichier utilise des contextes différents. Le déplacement d'un objet chiffré vers un autre coffre-fort ou son remplacement par un autre objet modifie le contexte authentifié et échoue la vérification.
Le contexte authentifié ne cache pas les identifiants et ne prouve pas la fraîcheur. Un enregistrement plus ancien et valide peut toujours avoir une balise valide. Les contrôles de révision des applications détectent les mises à jour simultanées ordinaires, mais il ne s'agit pas d'une défense cryptographique contre un service malveillant reproduisant un état entièrement antérieur.
Les fichiers volumineux utilisent des segments authentifiés
Le contenu du fichier utilise la construction de streaming AES-256-GCM-HKDF-SHA-256 décrite par Tink, implémentée à l'aide des primitives cryptographiques du navigateur. Chaque nouveau flux de fichiers possède un en-tête de 40 octets contenant son marqueur de longueur, un sel aléatoire de 32 octets et un préfixe occasionnel aléatoire de 7 octets.
HKDF dérive une clé de chiffrement de fichier distincte de la clé principale du coffre-fort. Son contexte inclut les identifiants du coffre-fort et des fichiers, la longueur des octets du texte en clair et la taille des segments configurés. Le nom occasionnel de 12 octets de chaque segment combine le préfixe aléatoire, un compteur de segment de quatre octets et un indicateur de segment final. Les segments portent des balises GCM de 128 bits.
L'application traite les fichiers dans des segments délimités d'environ 5 Mio. Les positions des segments, l'indicateur de segment final et les longueurs d'octets attendues font échouer la vérification des segments échangés, modifiés ou tronqués. Les téléchargements authentifient chaque segment avant de le publier ; une erreur tardive dans un flux peut laisser un téléchargement incomplet, la réussite est donc importante. Les tentatives de téléchargement réutilisent les octets déjà chiffrés plutôt que de chiffrer le nouveau contenu avec le même segment occasionnel.
La construction suit le Spécification de streaming Tink AES-GCM-HKDF. La mise en œuvre de Revault et la configuration des segments n'ont pas été auditées ou certifiées de manière indépendante par Tink.
La récupération est un deuxième chemin vers la même clé
Un secret de récupération est généré à partir de 24 octets aléatoires, donnant 192 bits d'entrée aléatoire. Il dérive indépendamment une clé d'encapsulation à l'aide de PBKDF2-HMAC-SHA-256 et de son propre sel, et chiffre la même clé principale du coffre-fort avec AES-256-GCM. Toute personne obtenant le secret de récupération et une copie du coffre-fort chiffré peut déchiffrer ce coffre-fort.
Le secret de récupération est affiché lors de l'installation et n'est pas stocké par le service en texte brut. Conservez-le séparément de vos fichiers cryptés. La suppression des données du navigateur supprime le secret de l'appareil ; la récupération de l'accès nécessite la copie cloud cryptée de votre compte et la clé de récupération, ou une sauvegarde cryptée exportée et sa clé de récupération. Il n’existe aucune clé principale de déchiffrement détenue par le fournisseur.
Un kit de récupération contient un secret et des wrappers de clé, mais aucun contenu de fichier. Une sauvegarde chiffrée contient un inventaire authentifié et des segments de fichiers chiffrés, sans le secret de l'appareil du navigateur. L'importation vérifie les données chiffrées et crée un nouveau coffre-fort avec de nouveaux identifiants et clés.
La modification d’un modèle remplace le wrapper de cet appareil. Il n'effectue pas de rotation de la clé principale du coffre-fort, ne révoque pas un autre appareil, n'invalide pas les anciennes sauvegardes et ne modifie pas un secret de récupération existant. Si une clé de coffre-fort ou un secret de récupération est compromis, déplacez les données vers un nouveau coffre-fort avec de nouvelles clés.
Les partages natifs utilisent un cryptage indépendant
Par défaut, les partages mobiles enveloppent les clés des versions sélectionnées avec une nouvelle clé de partage et réutilisent les fichiers chiffrés. L’isolation supplémentaire facultative les chiffre à nouveau. Les clés du coffre source restent privées. Un contenu chiffré identique permet de corréler les partages ; aucun mode ne peut rappeler une copie conservée par le destinataire.
iOS peut placer ce texte chiffré dans une hiérarchie d'enregistrements CloudKit distincte avec une invitation privée en lecture seule. Il ne partage pas la zone de synchronisation du coffre-fort. Les partages natifs multiplateformes utilisent des parties de serveur limitées avec des sommes de contrôle SHA-256. Les capacités indépendantes de lecture et de gestion aléatoires de 256 bits sont stockées sous forme de hachages sur le serveur. Le secret de décryptage est transmis séparément et jamais téléchargé. Les actions contrôlées expirent à l’heure choisie par l’expéditeur, dans un délai de 30 jours. Le service compte atomiquement les sessions d'accès et applique le maximum, l'expiration et la révocation choisis. Une session de téléchargement dure au maximum 15 minutes et ne dépasse jamais l'expiration du partage.
Les destinataires authentifient chaque segment chiffré et ouvrent un coffre-fort partagé isolé avec le secret distinct de l'expéditeur. Aucun compte, coffre-fort personnel ou modèle n'est requis. Les coffres-forts personnels restent verrouillés. Lorsque l'exportation est autorisée, les destinataires peuvent enregistrer une copie cryptée .qvault qui s'ouvre avec ce secret de partage. Sinon, les contrôles à l’exportation sont absents. La session temporaire valide l'accès continu. Il s'agit de contrôles d'application : les captures d'écran, les clients modifiés et les copies conservées ne peuvent pas être empêchés cryptographiquement. Les partages sont des instantanés sans mises à jour continues des sources. Les invitations CloudKit sans restriction n'imposent pas de décompte d'accès ni d'expiration automatique ; l'accès dure jusqu'à ce que le propriétaire arrête le partage. La suppression d'un original ne révoque pas sa part distincte, et aucune révocation ne peut rappeler une copie déjà conservée.
Activité de coffre-fort facultative
Les journaux d'audit natifs sont désactivés par défaut et configurés par coffre-fort sur chaque appareil. Les 500 derniers événements locaux sont chiffrés avec la clé principale du coffre-fort et un contexte authentifié dédié. Ils excluent les clés, les modèles, le contenu des fichiers et les données d'autres coffres-forts, ne sont pas synchronisés et peuvent être effacés ou désactivés. Ce ne sont pas des preuves infalsifiables. Les déverrouillages échoués ne sont pas attribués à un coffre-fort.
Les nouveaux partages contrôlés créés avec la journalisation activée conservent jusqu'à 100 horodatages de session d'accès sur le service de partage. Seule la capacité de gestion peut les récupérer ; le journal ne contient aucune identité du destinataire ni secret de déchiffrement. La désactivation de la journalisation locale affecte les partages futurs. Les journaux de partage existants conservent leurs paramètres d'origine jusqu'à leur révocation ou leur expiration et leur nettoyage.
Photos d'effraction cryptées en option
Les propriétaires peuvent activer les alertes d'effraction séparément pour chaque coffre-fort sur chaque appareil. Après trois modèles inégalés, l'application de premier plan peut capturer une photo de la caméra frontale, sous réserve d'autorisation, de disponibilité de la caméra et d'un temps de recharge d'une minute. Les indicateurs de la caméra système restent visibles. Les dix dernières alertes sont stockées localement et ne sont jamais ajoutées aux photos ni téléchargées. Un modèle sans correspondance n'identifie pas un coffre-fort cible, donc chaque coffre-fort activé reçoit un enregistrement de tentative d'appareil chiffré séparément.
Une clé publique RSA-3072 dédiée enveloppe une nouvelle clé AES-GCM de 256 bits pour chaque alerte utilisant OAEP avec SHA-256 et MGF1-SHA-256. Cela permet le cryptage pendant que le coffre-fort est verrouillé. La clé privée correspondante est elle-même chiffrée sous la clé principale de ce coffre-fort avec un contexte authentifié dédié. Seul le déverrouillage de ce coffre-fort peut décrypter ses photos. Les alertes apparaissent dans sa vue d'audit indépendamment de la journalisation des activités ordinaires et peuvent être effacées dans les paramètres des alertes d'effraction. Ce ne sont pas des preuves infalsifiables.
Téléchargements chiffrés vers votre propre bucket
Les paramètres de stockage d'un coffre-fort peuvent connecter ce navigateur directement à un point de terminaison HTTPS compatible S3 spécifié par l'utilisateur. Les fichiers de périphérique sélectionnés sont chiffrés localement en utilisant la même construction de fichier. Chacun devient un objet .qvault distinct et portable contenant un inventaire chiffré authentifié et des clés de coffre-fort encapsulées. Les noms d'objets aléatoires évitent d'exposer les noms de fichiers d'origine. La restauration nécessite l'objet téléchargé et la clé de récupération du coffre-fort.
La configuration et les informations d'identification du point de terminaison sont chiffrées sous la clé principale du coffre-fort avec un contexte authentifié dédié et conservées dans le IndexedDB de cet appareil. Ils ne sont pas synchronisés ni envoyés à l'API de Revault. La signature des requêtes utilise AWS Signature Version 4, HMAC-SHA-256 et un hachage de chaque corps de requête limité. Les parties multiparts de huit Mio transportent les octets déjà chiffrés directement vers le fournisseur de stockage. L’accès au compartiment reste régi par les autorisations de ce fournisseur et la politique CORS.
Le fournisseur peut voir les identifiants de clé d'accès, les chemins d'objet, les tailles d'octets, les temps de téléchargement et les informations de connexion. Gardez le compartiment privé et ses informations d'identification limitées aux opérations requises. Les objets téléchargés sont indépendants de la synchronisation et du partage cloud Revault. Tentatives de verrouillage ou d'annulation pour abandonner les téléchargements inachevés ; la fermeture d'un onglet ou la perte de connectivité peuvent laisser des pièces orphelines, alors configurez une règle de cycle de vie de téléchargement incomplet. Safe Exit supprime les informations d'identification de stockage local des autres coffres-forts, mais ne supprime pas les objets de leurs compartiments.
Safe Exit supprime l'accès local
Vous pouvez désigner un coffre-fort dans ce navigateur comme coffre-fort Safe Exit. La saisie du modèle de ce coffre-fort l’ouvre normalement, sans confirmation de déclenchement ni avis d’achèvement. Les instantanés locaux, les fragments chiffrés, les secrets de périphérique et les modifications mises en file d'attente d'autres coffres-forts sont supprimés. Les données non synchronisées peuvent être perdues.
Une limite locale persistante empêche ces coffres-forts d'être automatiquement répertoriés ou restaurés via la synchronisation sur ce navigateur. Leurs copies cloud cryptées et leurs copies sur d'autres appareils restent inchangées. La récupération est explicite, un coffre-fort à la fois, et nécessite la clé de récupération de ce coffre-fort avant qu'un nouveau modèle d'appareil puisse être inscrit.
Il s’agit d’une suppression d’accès local, sans garantie d’effacement physique ni de dissimulation médico-légale. Les profils de navigateur, les instantanés du système de fichiers, les téléchargements antérieurs, les captures d'écran, les enregistrements de service et un autre appareil peuvent conserver des preuves. La suppression des données locales de ce navigateur efface également la limite d'isolement local ; une nouvelle installation peut à nouveau répertorier les coffres-forts cloud du compte après authentification.
Ce qui reste visible
Le cryptage protège le contenu, mais pas tous les faits concernant le stockage. Le service peut observer les associations de comptes, les identifiants d'objets aléatoires, le nombre d'objets, la taille des octets, les révisions, les horodatages, les wrappers chiffrés, les en-têtes de flux et l'activité des demandes. Les enregistrements réseau et opérationnels peuvent révéler des informations de connexion. Il ne s'agit pas d'un système d'anonymat et n'offre pas de résistance à l'analyse du trafic.
Le chiffrement du transport protège les requêtes en transit lorsque l'application est servie via HTTPS. Ceci est distinct du cryptage côté client qui maintient le contenu des fichiers stockés crypté au niveau du service.
Où s'arrête la protection
La navigation privée supprime généralement le stockage local à la fin de la session privée. Une demande de stockage persistant ne rend pas une session de navigation privée permanente. Les copies cloud synchronisées sont conservées, mais les modèles locaux, les modifications non synchronisées, les fichiers mis en cache et les paramètres Safe Exit peuvent être perdus. Une nouvelle session privée nécessite un accès au compte et votre clé de récupération pour enregistrer un nouveau modèle.
L'application supprime sa référence de clé de coffre-fort en mémoire et révoque les URL d'aperçu privées lorsqu'elles sont verrouillées. Il se verrouille automatiquement lorsqu'il est masqué ou après cinq minutes d'inactivité. Les applications natives se verrouillent également lorsqu'elles sont en arrière-plan, suppriment les aperçus temporaires et effacent les tampons de clés détenus une fois les opérations terminées. La gestion de la mémoire du navigateur, de Swift et de la JVM ne peut pas garantir l'effacement immédiat de chaque copie de clé ou tampon multimédia décodé.
Un logiciel malveillant, une extension dangereuse, un code d'application compromis ou une personne visualisant un écran déverrouillé peuvent capturer du texte brut et des secrets. Le chiffrement ne peut pas empêcher le déni de service d'un compte, la suppression d'objets cloud, les ransomwares, la perte d'un secret de récupération ou la rétention de données par un service. Conservez une sauvegarde cryptée distincte et protégez l’appareil lui-même.
Revault n'a pas fait l'objet d'un audit de sécurité indépendant. Il s’agit de descriptions de la conception cryptographique mise en œuvre, et non d’une certification ou d’une garantie contre toute intrusion.