Modèle de sécurité

La protection démarre avant le téléchargement

Les coffres-forts natifs fonctionnent localement sans compte Revault. Le contenu des fichiers, les noms de fichiers, les types MIME, les vignettes, les noms de coffre-fort, les dossiers, les balises et les favoris sont cryptés sur l'appareil. L'utilisation locale ne télécharge pas les fichiers du coffre-fort vers Revault. La synchronisation et le partage cloud natifs sont des opérations facultatives et distinctes.

Le modèle suppose un système d'exploitation fiable, une application installée et une source aléatoire cryptographique lorsqu'un coffre-fort est créé ou déverrouillé. Une personne disposant uniquement de fichiers cryptés et de wrappers de clés ne peut pas les déchiffrer sans le secret requis. Les logiciels malveillants ou les applications compromises exécutés alors qu'un coffre-fort est ouvert peuvent capturer du texte brut et des clés.

Clés indépendantes pour chaque coffre-fort

Chaque coffre-fort commence par une clé principale aléatoire AES de 256 bits, générée à l'aide de la source aléatoire cryptographique du système d'exploitation. Le geste ne détermine pas directement cette clé. Chaque coffre-fort dispose d'un matériel de clé principale indépendant, de sorte que la divulgation d'une clé de coffre-fort n'en dérive pas une autre.

Un modèle de périphérique combine sa séquence de points ordonnée avec un secret de périphérique aléatoire de 256 bits. L'entrée résultante est normalisée avec NFKC et transmise à PBKDF2-HMAC-SHA-256 avec un nouveau sel de 128 bits et 600 000 itérations. La clé dérivée de 256 bits encapsule la clé principale à l'aide de AES-256-GCM. L'application n'enregistre pas de motif en texte brut ni d'empreinte digitale de motif distinct.

Les modèles utilisent une grille 5 × 5 avec six à 25 points distincts et doivent être uniques parmi tous les coffres-forts inscrits sur le même appareil. Un modèle correspondant ouvre uniquement son coffre-fort ; les autres noms et contenus du coffre-fort restent masqués. Les gestes prévisibles sont encore plus faciles à deviner. Une personne qui obtient à la fois un secret d’appareil et son enveloppe chiffrée peut tenter de deviner un modèle hors ligne.

L'ouverture d'un coffre-fort natif nécessite son modèle local ou un flux de récupération explicite, et non un compte Revault ou un mot de passe. La synchronisation cloud facultative utilise l'autorisation Apple ou Google de la plateforme, et les achats en magasin utilisent le compte de facturation de la plateforme. Ni l'autorisation cloud ni un achat ne fournissent de clé de déchiffrement du coffre-fort.

Protection des clés de l'appareil uniquement

Sur iOS, le verrouillage de l'appareil est stocké en tant qu'élément Keychain non synchronisé utilisant la protection WhenUnlockedThisDeviceOnly. Il n'est accessible que lorsque l'appareil est déverrouillé et ne migre pas via la synchronisation Keychain. Le secret stocké n'est pas une clé Secure Enclave.

Le Android, le verrouillage de l'appareil est chiffré à l'aide de AES-256-GCM sous une clé Android Keystore non exportable qui nécessite un appareil déverrouillé. Le fichier de verrouillage crypté se trouve dans le répertoire sans sauvegarde de l'application. Keystore la sauvegarde matérielle dépend du périphérique ; l'application ne promet pas que chaque appareil utilise des clés matérielles.

Les secrets de déverrouillage locaux sont exclus de la synchronisation cloud native et des sauvegardes de coffre-fort portables. La possession d'un compte Apple ou Google ne recrée pas ces secrets et ne déverrouille pas automatiquement un coffre-fort restauré. Un nouvel appareil doit vérifier le secret de récupération indépendant et inscrire son propre modèle.

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 chiffrement natif des fichiers utilise la construction de streaming AES-256-GCM-HKDF-SHA-256 décrite par Tink. iOS utilise CryptoKit pour AES-GCM et HKDF ; Android utilise les primitives cryptographiques de la plateforme. Chaque nouveau flux 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 sept 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.

Les applications natives traitent les fichiers dans des segments délimités d'environ 5 Mio. Les compteurs de segments, l'indicateur de segment final et les longueurs d'octets attendues détectent les segments modifiés, réorganisés ou tronqués. Chaque segment est authentifié avant utilisation et un aperçu privé n'est publié qu'une fois le décryptage de son fichier terminé. La sortie incomplète est rejetée en cas d'échec ; les nouvelles tentatives transfèrent les octets chiffrés existants.

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.

Stockage privé, importations et aperçus

Les fichiers du coffre-fort cryptés résident dans le stockage d'applications privé. Les noms de fichiers, les types MIME, les dossiers, les balises, les favoris et les vignettes sont des enregistrements cryptés authentifiés. La recherche et le filtrage des balises fonctionnent sur les métadonnées déchiffrées du coffre-fort actif après le déverrouillage ; il n'y a pas d'index de recherche de serveur en texte brut.

Les importations de photos, de vidéos et de fichiers peuvent utiliser une mise en scène temporaire privée avant le cryptage. La capture de la caméra dans le coffre-fort n'enregistre pas automatiquement une copie dans la galerie. L’importation à partir de Photos ou d’un autre fournisseur laisse intact l’original de ce fournisseur. L'optimisation facultative des médias se produit localement avant le chiffrement et modifie uniquement les médias nouvellement importés.

Les aperçus privés nécessitent un texte brut temporaire lorsqu'ils sont ouverts. Les applications suppriment leurs aperçus temporaires à la fermeture, au verrouillage et au démarrage ultérieur ; iOS applique une protection complète des fichiers aux fichiers d'aperçu déchiffrés. Les fichiers explicitement exportés vers une autre application quittent la protection du coffre-fort. La suppression temporaire d’un fichier ne constitue pas une garantie d’effacement médico-légal.

Synchronisation cloud native en option

La synchronisation est désactivée par défaut et activée séparément pour chaque coffre-fort sur chaque appareil. iOS stocke les enregistrements cryptés et les segments de fichiers dans la base de données privée CloudKit de l'utilisateur dans iCloud. Android utilise le appDataFolder privé de Google Drive. Aucun des deux transports ne nécessite un compte Revault ni ne télécharge des données de synchronisation natives sur le cloud Web de Revault.

Le cloud reçoit des métadonnées chiffrées, des segments de fichiers et des wrappers de clés, et non une clé principale de coffre-fort en texte brut, un secret de périphérique local ou un secret de récupération. Un autre appareil sur la même plate-forme a besoin du même compte cloud natif et de la clé de récupération du coffre-fort pour inscrire son propre modèle local. Les autorisations Apple et Google contrôlent l'accès aux enregistrements chiffrés, et non leur déchiffrement.

La désactivation de la synchronisation arrête les transferts ultérieurs pour ce coffre-fort à partir de l'appareil actuel ; les copies cloud cryptées existantes restent. Les modifications et suppressions de synchronisation peuvent se propager et les modifications simultanées peuvent nécessiter un examen des conflits. iCloud et Google Drive sont des magasins distincts, sans pont multiplateforme automatique. Utilisez un transfert téléphonique crypté pour vous déplacer entre l'iPhone et Android.

La récupération est un deuxième chemin vers la même clé

Revault génère une phrase de récupération contenant 18 mots choisis indépendamment dans une liste groupée de 2 048 mots, fournissant 198 bits aléatoires. La création ne propose pas de phrases personnalisées ni de régénération. La phrase dérive indépendamment une clé d'encapsulation en utilisant PBKDF2-HMAC-SHA-256 et un nouveau sel, puis encapsule la clé principale du coffre-fort avec AES-256-GCM. Toute personne possédant la phrase et le coffre-fort chiffré peut la déchiffrer. Les phrases personnalisées existantes et les clés de récupération hexadécimales restent compatibles avec leurs coffres-forts d'origine.

Le secret de récupération est affiché lors de la configuration et n'est pas conservé dans le stockage d'application natif ni téléchargé sur le stockage cloud natif. Conservez-le séparément des fichiers cryptés. L'inscription d'un autre appareil nécessite le coffre-fort chiffré du compte cloud natif d'origine ou une sauvegarde chiffrée, ainsi que la clé de récupération. Un secret ne peut pas restaurer les données de fichier manquantes et Revault ne possède aucune clé de réinitialisation détenue par le fournisseur.

Une sauvegarde portable .qvault contient des wrappers de clés chiffrés, un inventaire chiffré authentifié et des segments de fichiers chiffrés. Il exclut le secret de déverrouillage du périphérique local. L'importation vérifie l'inventaire, les métadonnées et chaque segment avant de restaurer dans un coffre-fort avec de nouveaux identifiants, une clé principale, des clés de fichier et un nouveau modèle de périphérique. Enregistrez la nouvelle clé de récupération après la restauration.

Les nouvelles phrases de récupération préservent la casse, normalisent Unicode avec NFKC et réduisent les espaces supplémentaires. Les anciennes clés hexadécimales restent prises en charge. Vous pouvez remplacer la phrase de récupération d'un coffre-fort dans ses paramètres après avoir enregistré la nouvelle phrase. Cela remplace le wrapper de récupération actuel ; les anciennes sauvegardes et les appareils qui n'ont pas été synchronisés peuvent toujours contenir l'ancien wrapper. La modification d'un modèle ou d'une phrase de récupération n'entraîne pas de rotation de la clé principale du coffre-fort ni de révocation des copies. Si les éléments de clé sont compromis, déplacez les fichiers vers un nouveau coffre-fort avec de nouvelles clés.

Migration de téléphone à téléphone cryptée

Le transfert téléphonique crée une copie cryptée portable avec de nouveaux identifiants de coffre-fort, une clé principale, des clés de fichier et des en-têtes de flux. Son secret de transfert indépendant ne peut pas déverrouiller le coffre-fort source, et le secret de récupération source et le secret de déverrouillage du périphérique ne sont pas inclus. Le package crypté et le secret de transfert doivent être livrés séparément.

L'application réceptrice authentifie le package et ses segments de fichiers, puis restaure dans un nouveau coffre-fort avec un nouveau modèle local et une nouvelle clé de récupération. Cela fonctionne entre iOS et Android sans ponter leurs comptes cloud. L'original reste sur l'ancien appareil ; confirmez le contenu restauré et enregistrez la nouvelle clé de récupération avant de la supprimer.

Verrouillage et nettoyage de session

Les applications mobiles se verrouillent immédiatement en arrière-plan et après 60 secondes d'inactivité par défaut. Chaque coffre-fort peut sélectionner 30 secondes, 1 minute, 2 minutes, 5 minutes ou 10 minutes. Un coffre-fort partagé utilise la valeur par défaut de 60 secondes. Quitter revient à l’écran du modèle et met fin à la session déchiffrée.

Le verrouillage annule le travail de session, efface les métadonnées déchiffrées et l'état de recherche, ferme les aperçus, supprime les fichiers temporaires et écrase les tampons de clés détenus avant de les libérer. Les clés de dérivation temporaires sont également effacées après utilisation. La gestion de la mémoire Swift et JVM, les bibliothèques cryptographiques et les décodeurs multimédias peuvent créer des copies ; l’effacement immédiat de chaque copie ne peut être garanti.

iOS couvre les instantanés du commutateur d'application avec un bouclier de confidentialité. Android utilise l'indicateur de fenêtre sécurisée pour restreindre les captures d'écran et les aperçus d'applications récentes. Ces protections de plateforme n’empêchent pas quelqu’un de photographier un écran déverrouillé et ne retirent pas les fichiers précédemment exportés vers une autre application.

Revault Cloud

Revault Cloud est un fournisseur de stockage Pro en option pour la synchronisation multiplateforme. Les segments chiffrés et les métadonnées des fichiers chiffrés sont liés à une installation de facturation pseudonyme. Le service peut observer les identifiants de stockage, les tailles, les sommes de contrôle, les révisions et l'activité de transfert, mais ne reçoit aucune clé de coffre-fort ou phrase de récupération non enveloppée. Un code de connexion aléatoire distinct autorise l'accès au stockage ; la connexion d'un autre appareil nécessite également la phrase de récupération. Les données cloud existantes restent lisibles pour la récupération après l'expiration de Pro.

Clés indépendantes pour chaque partage

Un partage natif est un instantané des fichiers sélectionnés, et non un accès au coffre-fort personnel du propriétaire. Par défaut, l'application dérive les clés de version de fichier sélectionnées et les enveloppe avec AES-256-GCM sous une nouvelle clé principale de partage. Il réutilise les octets du fichier chiffré, tout en rechiffrant les métadonnées et les vignettes du partage. Les clés du coffre-fort source, son secret de récupération, la structure des dossiers, les balises et les favoris sont exclus.

Le partage possède sa propre phrase de décryptage de 18 mots et son propre wrapper de récupération générés indépendamment. L'expéditeur transmet ce secret en privé, séparément du lien d'invitation. Le serveur reçoit des données cryptées, jamais la clé de partage en clair ou le secret de déchiffrement. Le destinataire ne peut pas dériver les clés de fichiers non partagées ou la clé principale du coffre-fort source à partir des clés de fichiers sélectionnées.

Le paramètre d’isolation supplémentaire facultatif rechiffre le contenu du fichier avec de nouvelles clés et en-têtes de flux. La valeur par défaut est plus rapide car elle évite de réécrire chaque fichier ; Un texte chiffré répété peut corréler des copies de la même version de fichier. Les deux modes créent un instantané distinct et aucun ne peut retirer le texte chiffré et les clés déjà conservées par un destinataire.

Transports de partage natifs et contrôles d'accès

Le iOS, une invitation privée en lecture seule CloudKit place l'instantané chiffré dans une hiérarchie d'enregistrements de partage distincte, en dehors de la zone de synchronisation personnelle. Apple contrôle l'accès aux invitations ; le destinataire a toujours besoin du secret de déchiffrement distinct. Les invitations CloudKit n'appliquent pas le nombre de sessions d'accès du serveur, ni le délai d'expiration ou de destruction fixe. Le propriétaire peut arrêter tout accès futur CloudKit.

Les partages multiplateformes téléchargent des parties chiffrées vers le service de partage de Revault. Les capacités indépendantes de lecture et de gestion aléatoires de 256 bits sont stockées sous forme de hachages SHA-256. Le lien du site Web contient la capacité de lecture dans son fragment, et non le secret de décryptage. L'ouvrir crée des liens profonds vers un coffre-fort partagé et demande le secret de l'expéditeur ; aucun modèle personnel ni coffre-fort existant n'est requis. Les coffres-forts personnels restent verrouillés.

Les partages de serveur contrôlés appliquent les sessions d'accès maximales de l'expéditeur, l'expiration fixe dans les 30 jours, la révocation et l'autorisation d'exportation facultative. Une séance est accordée de manière atomique et dure au maximum 15 minutes, délimitées par les délais de partage. Un accès compte lorsque la session est accordée, même si le téléchargement ou le décryptage échoue. Le spectateur vérifie l'accès en cours et ferme à la date limite.

Les sommes de contrôle SHA-256 vérifient les parties transférées, tandis que le cryptage authentifié vérifie leur contenu. Lorsque l'exportation est autorisée, le spectateur peut enregistrer une copie cryptée .qvault qui s'ouvre avec le secret de partage. La désactivation de l'exportation supprime cette action d'application ; il ne peut pas empêcher cryptographiquement les captures d'écran ou un client modifié de conserver le texte en clair. La suppression d'un fichier source ne révoque pas un partage créé indépendamment.

Un délai après le premier accès

Un expéditeur peut activer un minuteur de destruction distinct. Il démarre de manière atomique lorsque la première session d'accès au serveur est accordée, même si le transfert ou le décryptage échoue ultérieurement. Chaque session ultérieure partage la même date limite ; la réouverture ne le réinitialise jamais. La première date entre l'expiration fixe, l'heure de destruction et l'expiration de la session s'applique. À la date limite, le service refuse toute lecture supplémentaire et met en file d'attente le texte chiffré pour suppression, tandis que le visualiseur natif ferme et libère ses clés de partage et ses fichiers temporaires. Le nettoyage est asynchrone et ne peut pas effacer les captures d’écran, les données conservées d’un client modifié ou les copies exportées précédemment.

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.

Safe Exit supprime l'accès local

Un coffre-fort sur un appareil peut être désigné pour Safe Exit. La saisie de son modèle l'ouvre normalement tout en supprimant les autres enregistrements du coffre-fort local, les morceaux chiffrés, le matériel de déverrouillage de l'appareil et les modifications en file d'attente. L'application conserve une liste verte locale persistante afin que la synchronisation ne puisse pas repeupler silencieusement les coffres exclus. Les transferts cryptés déjà en vol peuvent encore se terminer.

Les copies cloud natives et les copies sur d'autres appareils restent. La récupération explicite nécessite la clé de récupération du coffre-fort exclu avant qu'un nouveau modèle local ne soit inscrit. Un coffre-fort hors ligne uniquement sans sauvegarde distincte peut être perdu. Ce paramètre s'applique à l'installation actuelle et non à tous les appareils utilisant le même compte cloud.

Safe Exit ne garantit pas l'effacement ou la dissimulation médico-légale. Le stockage Flash, les caches du système d'exploitation, les sauvegardes et les exportations antérieures peuvent conserver des traces. La suppression des données de l'application ou la réinstallation peuvent supprimer la limite d'isolement local ; les enregistrements cloud peuvent ensuite être découverts à nouveau via le compte cloud natif. Seul le secret de récupération peut déverrouiller ces enregistrements.

Ce qui reste visible

Le cryptage masque le contenu, mais pas toutes les informations opérationnelles. Les enregistrements locaux et les fournisseurs de cloud peuvent observer les identifiants, les relations entre les enregistrements, le nombre d'objets, les tailles, les révisions, les horodatages, les wrappers de clés chiffrés et les en-têtes de flux. Les identifiants utilisent UUIDv7 et incluent des informations au moment de la création ; ce ne sont pas des secrets. Apple ou Google peuvent associer une activité de synchronisation native au compte de plateforme.

Le service de partage contrôlé de Revault peut observer la taille des paquets chiffrés, les sommes de contrôle des parties, les paramètres d'expiration, le nombre de sessions d'accès et les horodatages de session facultatifs, mais pas le secret de décryptage fourni séparément. Le partage de CloudKit expose les informations sur les invitations et les participants à Apple. Les enregistrements réseau et opérationnels peuvent exposer des informations de connexion. Revault n'offre pas d'anonymat ni de résistance à l'analyse du trafic.

HTTPS protège les requêtes réseau en transit. Le chiffrement authentifié sur l'appareil protège séparément le contenu du coffre-fort stocké localement et dans le cloud. Ni le chiffrement de transport ni le texte chiffré ne cachent tous les faits sur le moment, le lieu et la quantité de données transférées.

Où s'arrête la protection

Un coffre-fort déverrouillé expose nécessairement les informations déchiffrées à sa session d'application. Un logiciel malveillant, un système d'exploitation ou une application compromis, une personne regardant l'écran ou un destinataire non fiable peuvent le capturer. Le stockage des clés sur l’appareil uniquement constitue une limite supplémentaire et non une garantie contre un appareil entièrement compromis. Un modèle prévisible devient dangereux une fois que son secret local est compromis.

Le chiffrement n'empêche pas la suppression du cloud, les ransomwares, la perte d'un secret de récupération, la rétention d'enregistrements par un fournisseur ou la restauration de l'intégralité d'un état chiffré précédemment valide. Conservez des sauvegardes cryptées indépendantes et vérifiez la récupération avant de supprimer un ancien appareil. La révocation ne peut pas rappeler les captures d'écran, les exportations ou les copies déjà conservées par une autre personne.

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.

Coffres-forts de navigateur existants

Cette référence décrit les applications natives. Les coffres-forts de navigateur existants ont un modèle de compte, de stockage sur appareil et de cloud Web distinct. Les téléchargements S3 spécifiques au navigateur et les liens de partage du navigateur ne sont pas synchronisés dans le cloud natif. Le compte du navigateur ne vous connecte pas aux applications mobiles ; utilisez une sauvegarde cryptée et sa clé de récupération pour déplacer les données du navigateur existantes vers un coffre-fort natif.