Architecture de sécurité : la pile technique complète

Vaultaire utilise AES-256-GCM pour le chiffrement authentifié des index du coffre-fort, des clés encapsulées, des en-têtes de fichiers, du contenu, des miniatures et des métadonnées. PBKDF2-HMAC-SHA512 dérive une clé de coffre-fort locale à partir du modèle et une clé à l'échelle de l'appareil Keychain sel. Cette clé de coffre-fort encapsule une clé principale aléatoire distincte de 256 bits, qui effectue le cryptage des fichiers via CryptoKit dans le processus d'application.

La pile cryptographique

Vaultaire utilise plusieurs mécanismes cryptographiques fonctionnant de concert, chacun choisi pour une tâche spécifique. PBKDF2 transforme un identifiant humain en clé de coffre-fort ou de récupération. AES-256-GCM protège les index, les wrappers, les métadonnées, les vignettes et le contenu des fichiers. Une clé principale aléatoire sépare le cryptage de fichier de longue durée d'un modèle modifiable. Keychain et iOS La protection des données protège les enregistrements de sel et de récupération liés à l'appareil lorsque l'appareil est verrouillé. Aucune clé de déchiffrement détenue par le fournisseur ne permet au développeur d'accéder régulièrement au texte brut du coffre-fort.

Il ne s’agit pas là d’une complexité en soi. Chaque couche s'adresse à une surface d'attaque différente. AES-256-GCM combine confidentialité et authentification, de sorte que le texte chiffré modifié échoue à la vérification. PBKDF2 augmente le coût du test de chaque modèle ou expression. La clé principale aléatoire signifie qu'un changement de modèle peut réemballer une clé au lieu de rechiffrer chaque fichier. Keychain protection des données protège les enregistrements locaux de sel et de récupération, tandis que l'application reconnaît toujours que le cryptage symétrique se produit dans la mémoire du processus.

Ensemble, ces couches forment une architecture de défense en profondeur, mais elles ne constituent pas toutes des barrières indépendantes. Un modèle deviné peut être vérifié par rapport au nom du fichier d'index et AES-GCM l'authentification et un appareil déverrouillé compromis peut observer les clés ou le texte en clair dans le processus de l'application. L'architecture dépend donc de l'entropie des identifiants, PBKDF2 coût, iOS la protection des appareils, la gestion correcte du cryptage authentifié ainsi que la force d'AES lui-même.

AES-256-GCM : chiffrement des fichiers

Chaque photo, vidéo et document stocké dans Vaultaire est crypté avec AES-256-GCM — l'Advanced Encryption Standard avec une clé de 256 bits dans Mode Galois/Compteur. Vaultaire utilise également AES-GCM pour les index de coffre-fort, les en-têtes de fichiers, les vignettes et les enveloppes de clés. L'algorithme et la taille de la clé sont standardisés ; La sécurité de Vaultaire dépend toujours de la gestion des cas occasionnels, de la gestion des clés, de la solidité des informations d'identification et de l'exactitude de la mise en œuvre.

Le « 256 » dans AES-256 désigne la longueur de la clé en bits. Une clé de 256 bits a 2²⁵⁶ valeurs possibles. Pour mettre ce chiffre en perspective : il y a environ 10⁸⁰ atomes dans l'univers observable. Si chaque atome était un supercalculateur testant un milliard de clés par seconde, depuis le Big Bang, ils n'auraient exploré qu'une fraction d'un milliardième d'un milliardième de un pour cent de l'espace des clés. AES-256 ne sera pas cassé par force brute. Pas aujourd'hui. Pas ce siècle. Pas avant que les étoiles s'éteignent.

Pourquoi le mode GCM est important

AES est un chiffre par blocs — il chiffre les données par morceaux de 128 bits. Le « mode » détermine comment ces morceaux sont combinés. GCM (Galois/Counter Mode) apporte deux choses que des modes plus simples comme CBC n'offrent pas : le chiffrement parallélisé et l'authentification intégrée.

L'authentification est cruciale. GCM génère une étiquette cryptographique pour chaque fichier chiffré. Cette étiquette agit comme un sceau d'inviolabilité. Si même un seul bit du texte chiffré est modifié — que ce soit par un acteur malveillant ou un secteur de disque corrompu — l'étiquette d'authentification ne correspondra pas, et le déchiffrement échouera. Tu n'obtiens pas des données corrompues. Tu obtiens un signal clair que quelque chose ne va pas. Cette propriété s'appelle le chiffrement authentifié, et elle prévient toute une classe d'attaques où un adversaire modifie des données chiffrées pour manipuler le résultat du déchiffrement.

PBKDF2 : dérivation de clés

Vaultaire dérive différentes clés pour différentes tâches. Le modèle et une application à l'échelle de l'appareil Keychain alimentation salée PBKDF2-HMAC-SHA512 pour 600 000 itérations pour produire la clé du coffre-fort local. Une dérivation de modèle déterministe produit la clé de sauvegarde cloud distincte. La phrase de récupération normalisée s'étend sur 800 000 PBKDF2 itérations pour produire la clé d’une enveloppe de récupération. Aucune de ces dérivations ne transforme un identifiant humain en 256 bits d’entropie simplement parce que la sortie fait 256 bits.

Comment PBKDF2 protège ton schéma

L'idée centrale derrière PBKDF2 est un travail délibéré. Il prend le modèle sérialisé ou la phrase normalisée et exécute des centaines de milliers de HMAC-SHA512 itérations. Un utilisateur légitime paie ce coût une fois lors d'une tentative de déverrouillage ou de récupération. Un attaquant paie pour chaque candidat, même si les choix parallèles en matière de matériel et d'implémentation déterminent le taux de devinette réel.

Vaultaire configure PBKDF2 avec 600 000 itérations pour les clés dérivées de modèles. Cela rend chaque estimation plus coûteuse, mais une estimation responsable de l'attaque doit indiquer un temps mesuré par candidat et des hypothèses matérielles. À exactement 1 ms par candidat, 1 000 000 000 de suppositions en série prennent environ 11,6 jours, et non des années. Le résultat de 256 bits n'étend pas l'entropie d'un modèle prévisible.

La dérivation de modèle local utilise un sel cryptographiquement aléatoire pour le périphérique, stocké en tant que WhenUnlockedThisDeviceOnly Keychain article. Le sel n'est pas secret et est partagé par les coffres-forts de cet appareil. Il empêche une table créée pour un appareil de s'appliquer directement à un autre appareil avec un sel différent, mais il n'oblige pas un attaquant à recommencer pour chaque coffre-fort sur le même appareil.

AES-256-GCM: Protection des métadonnées

Chiffrer le contenu des fichiers ne suffit pas. Les noms de fichiers, les dates de création, les dimensions des vignettes et la structure du coffre-fort sont tous des métadonnées — et les métadonnées peuvent être tout aussi révélatrices que les données elles-mêmes. Un fichier nommé « declaration-impots-2025.pdf » dit à un attaquant exactement ce qu'il contient, même si le contenu est chiffré. Un horodatage montre quand tu as utilisé le coffre-fort. La taille d'une vignette révèle si quelque chose est une photo ou une vidéo.

Vaultaire protège ces métadonnées avec AES-256-GCM, pas ChaCha20. Noms de fichiers et MIME les types sont codés dans des en-têtes de fichiers cryptés. L'index du coffre-fort chiffré contient les enregistrements de fichiers, les dates, les informations de taille, la disposition du stockage et la clé principale encapsulée. Les données miniatures sont également cryptées sous la clé principale aléatoire.

Pourquoi un chiffrement authentifié pour les métadonnées ?

Les métadonnées doivent être intègres et confidentielles. AES-GCM produit une balise d'authentification pour chaque valeur chiffrée, afin que Vaultaire puisse rejeter un en-tête, un index, une vignette ou une enveloppe modifié au lieu d'accepter le texte brut contrôlé par un attaquant. La conception utilise délibérément une construction de chiffrement authentifié pour ces formats de stockage plutôt que de revendiquer une diversité cryptographique que la mise en œuvre ne fournit pas.

Le même chiffre ne signifie pas que la même clé ou le même nom occasionnel est réutilisé aveuglément. La clé du coffre-fort protège l'index et encapsule la clé principale aléatoire ; la clé principale protège le matériel du fichier. CryptoKit crée des boîtes scellées authentifiées avec de nouveaux noms occasionnels, tandis que le format de streaming de Vaultaire dérive un nom occasionnel distinct pour chaque morceau commandé. Les garanties pertinentes proviennent de la séparation des clés, de la discipline occasionnelle et de l'authentification, et non d'un deuxième chiffre de métadonnées.

Architecture Zéro Connaissance

Voici une question qui mérite d'être posée à propos de toute application de sécurité : que se passe-t-il si l'entreprise derrière est piratée, assignée à comparaître, ou simplement devient malveillante ?

Avec la plupart des applications, la réponse est inconfortable. Elles détiennent tes données, tes clés, ou les deux. Une ordonnance de tribunal les oblige à les remettre. Une violation de données les expose. Un employé indélicat y accède. La sécurité de l'application n'est que aussi solide que la sécurité opérationnelle de l'entreprise — et l'histoire montre que les entreprises se font pirater régulièrement.

Vaultaire n'exploite pas de compte ou de service de stockage qui reçoit votre modèle, votre phrase secrète, vos clés de déchiffrement ou le contenu lisible du coffre-fort. Le cryptage et le décryptage ont lieu lors du processus d'application sur votre appareil. Quand iCloud la sauvegarde est activée, l'application envoie un texte chiffré authentifié à votre compte privé CloudKit base de données plutôt que vers un service de coffre-fort contrôlé par Vaultaire.

Ce que Zéro Connaissance signifie en pratique

Si un organisme chargé de l'application de la loi envoie à Vaultaire une assignation à comparaître exigeant le texte brut du coffre-fort, l'entreprise ne détient pas le modèle, la phrase de récupération, la clé du coffre-fort, la clé de sauvegarde ou la clé principale nécessaires pour le déchiffrer. Crypté iCloud enregistrements en direct dans le CloudKit base de données privée. Toutefois, sur l'appareil, le matériel de récupération est conservé dans un format crypté. Keychain base de données et des clés symétriques existent dans la mémoire de l'application tandis que CryptoKit chiffre ou déchiffre un coffre-fort ouvert.

Cette limite de fournisseur est une propriété architecturale et non une promesse selon laquelle chaque partie de l'environnement client est en dehors du modèle de confiance. Vaultaire ne détient pas de clé de déchiffrement côté serveur qu'il peut remettre pour la récupération de routine du coffre-fort. L'application livrée, iOS, l'appareil déverrouillé et l'implémentation cryptographique peuvent toujours traiter des données lisibles et doivent être fiables en conséquence.

Keychain et la frontière application-processus

Apple Secure Enclave peut protéger les clés privées prises en charge et participe à certaines parties de l'architecture de sécurité de la plateforme, mais ses API publiques n'acceptent pas de décision arbitraire. PBKDF2-clé symétrique dérivée et effectuer celle de Vaultaire AES-GCM opérations sur les fichiers à l’intérieur du coprocesseur. Vaultaire ne décrit donc pas son chiffre de coffre-fort comme Secure Enclave AES.

Vaultaire utilise des iOS Keychain éléments de mot de passe génériques pour le sel de périphérique aléatoire, la base de données de récupération chiffrée et la clé aléatoire protégeant cette base de données. Ces éléments utilisent la classe d’accessibilité WhenUnlockedThisDeviceOnly. Keychain et la protection des données créent une limite significative entre les appareils, en particulier lorsque le téléphone est verrouillé, mais cette architecture est différente d'une architecture non exportable. Secure Enclave clé.

Lorsque vous dessinez le motif, CommonCrypto dérive la clé du coffre-fort dans le processus d'application. CryptoKit et CryptoEngine de Vaultaire utilise ensuite des octets de clé symétriques dans ce processus pour authentifier et déchiffrer l'index, déballer la clé principale et traiter les fichiers. L'application efface son état actif lorsqu'elle se verrouille, mais un attaquant suffisamment privilégié observant une session déverrouillée a une opportunité différente de celle d'un examinateur ne détenant que le texte chiffré d'un appareil verrouillé.

Un système d'exploitation jailbreaké ou autrement compromis peut cibler la saisie de modèles, la mémoire d'application, les aperçus déchiffrés, les exportations ou l'écran. Vaultaire recommande une version actuelle et non jailbreakée iPhone parce que la conception repose sur iOS l'isolement des processus, Keychainet Protection des données. Il ne prétend pas que la compromission de la racine rend inaccessibles les clés symétriques d’un coffre-fort ouvert.

Vecteurs d'initialisation par fichier

Quand tu chiffres deux fichiers identiques avec la même clé, une implémentation naïve produirait un texte chiffré identique. C'est un problème. Un attaquant qui voit deux blobs chiffrés identiques sait — sans rien déchiffrer — que les deux fichiers originaux sont identiques. Dans un coffre-fort plein de photos, ce type d'analyse de motifs peut révéler des informations même à travers le chiffrement.

Vaultaire empêche les textes chiffrés déterministes en générant une nouvelle valeur occasionnelle cryptographique pour chaque AES-256-GCM opération de scellement. Les en-têtes et le contenu des fichiers sont scellés séparément, et les fichiers volumineux utilisent un format de streaming authentifié avec un nom occasionnel de base aléatoire et un nom occasionnel distinct pour chaque bloc ordonné. Deux copies d’une même photo ne produisent donc pas la même représentation cryptée.

Les noms occasionnels sont stockés avec le texte chiffré et ne sont pas secrets ; leur exigence de sécurité est l’unicité sous une clé donnée. Vaultaire demande des noms occasionnels 96 bits au générateur aléatoire cryptographique d'Apple pour un cryptage unique et enregistre le nom occasionnel de base dans l'en-tête de streaming. Le risque de collision est régi par le nombre de cryptages sous une clé, de sorte que l'implémentation génère une nouvelle valeur plutôt que de présenter la taille de 96 bits comme une taille fixe un sur deux.⁹⁶ garantie à vie.

Gestion de la mémoire : effacement de l'état de la clé active

Un défaut courant dans les logiciels de sécurité est de laisser des données sensibles en mémoire après qu'elles ne sont plus nécessaires. Les clés de chiffrement, les mots de passe dérivés et les données déchiffrées peuvent persister en RAM longtemps après que l'application en a fini avec elles. Les outils forensiques peuvent vider la mémoire de l'appareil et chercher ces restes — une technique connue sous le nom d'attaque par démarrage à froid ou d'analyse de dump mémoire.

Vaultaire limite la durée pendant laquelle l'état de la clé active et les données déchiffrées de l'interface utilisateur restent disponibles. Lorsque l'application se verrouille ou que la session est supprimée, son code suit plusieurs chemins de nettoyage :

• L’état du coffre-fort actif est supprimé. L'application supprime sa session de clé de coffre-fort actuelle et nécessite un autre déverrouillage avant de présenter le contenu du coffre-fort.
• Les wrappers de clés effacent les tampons détenus. Les conteneurs d'octets sécurisés de Vaultaire écrasent les tampons qu'ils possèdent lorsque ces conteneurs sont libérés.
• L’état de la clé principale mise en cache est invalidé. La clé principale déchiffrée détenue pour l'index ouvert est supprimée sur les chemins de verrouillage et de réinitialisation du cache appropriés.
• Les caches déchiffrés de l'interface utilisateur sont effacés là où ils sont contrôlés par Vaultaire. Le nettoyage des vignettes et des aperçus réduit l'état résiduel de l'application, sans revendiquer le contrôle de chaque copie réalisée par Swift, iOS, ou un autre processus.

La prochaine fois que Vaultaire s'ouvrira dans un état verrouillé, vous dessinerez le modèle et l'application dérivera à nouveau la clé du coffre-fort avant de pouvoir authentifier l'index et déballer la clé principale. Il s'agit d'un nettoyage de session, et non d'une affirmation selon laquelle chaque copie de mémoire transitoire a reçu un effacement multi-passes prouvable ou qu'un Secure Enclave la référence clé a été détruite. Un crash provoque iOS pour récupérer le processus, mais le code de nettoyage ne peut pas s'exécuter après chaque arrêt brutal.