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

Vaultaire utilise AES-256-GCM pour le chiffrement authentifié des index du coffre, 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 locale à partir du motif et d'un sel du Keychain commun à tout l'appareil. Cette clé de coffre encapsule une clé principale aléatoire distincte de 256 bits, qui effectue le chiffrement 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 ou de récupération. AES-256-GCM protège les index, les enveloppes de clés, les métadonnées, les vignettes et le contenu des fichiers. Une clé principale aléatoire sépare le chiffrement de fichier de longue durée d'un motif modifiable. Le Keychain et la protection des données d'iOS protègent 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.

Cette complexité n'est pas une fin 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 motif ou phrase. La clé principale aléatoire signifie qu'un changement de motif peut ré-encapsuler une clé au lieu de rechiffrer chaque fichier. Le Keychain et la protection des données protègent les enregistrements locaux de sel et de récupération, tandis que l'application reconnaît toujours que le chiffrement 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 motif deviné peut être vérifié grâce au nom du fichier d'index et à l'authentification AES-GCM, 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, du coût de PBKDF2, de la protection de l'appareil par iOS, de la gestion correcte du chiffrement authentifié ainsi que de la solidité d'AES lui-même.

AES-256-GCM : chiffrement des fichiers

Chaque photo, vidéo et document stocké dans Vaultaire est chiffré avec AES-256-GCM — l'Advanced Encryption Standard avec une clé de 256 bits dans mode Galois/Counter. Vaultaire utilise également AES-GCM pour les index de coffre, 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 nonces, 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. Vous n'obtenez pas des données corrompues. Vous obtenez 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 motif et un sel du Keychain commun à tout l'appareil alimentent PBKDF2-HMAC-SHA512 sur 600 000 itérations pour produire la clé du coffre local. Une dérivation de motif déterministe produit la clé de sauvegarde cloud distincte. La phrase de récupération normalisée passe par 800 000 itérations de PBKDF2 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 votre motif

L'idée centrale derrière PBKDF2 est un travail délibéré. Il prend le motif sérialisé ou la phrase normalisée et exécute des centaines de milliers d'itérations HMAC-SHA512. 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 le parallélisme, le matériel et l'implémentation déterminent le rythme réel des essais.

Vaultaire configure PBKDF2 avec 600 000 itérations pour les clés dérivées de motifs. Cela rend chaque essai plus coûteux, 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 motif prévisible.

La dérivation de motif local utilise un sel cryptographiquement aléatoire pour l'appareil, stocké comme élément Keychain WhenUnlockedThisDeviceOnly. Le sel n'est pas secret et est partagé par les coffres 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 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 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 vous avez utilisé le coffre. 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. Les noms de fichiers et les types MIME sont codés dans des en-têtes de fichiers chiffrés. L'index du coffre 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 chiffré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és 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 nonce est réutilisé aveuglément. La clé du coffre protège l'index et encapsule la clé principale aléatoire ; la clé principale protège les données des fichiers. CryptoKit crée des boîtes scellées authentifiées avec de nouveaux nonces, tandis que le format de streaming de Vaultaire dérive un nonce distinct pour chaque bloc ordonné. Les garanties pertinentes proviennent de la séparation des clés, de la rigueur dans l'usage des nonces 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 vos données, vos 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 motif, votre phrase secrète, vos clés de déchiffrement ou le contenu lisible du coffre. Le chiffrement et le déchiffrement ont lieu dans le processus de l'application sur votre appareil. Quand la sauvegarde iCloud est activée, l'application envoie un texte chiffré authentifié à la base de données CloudKit privée de votre compte plutôt que vers un service de coffre 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 injonction exigeant le texte brut du coffre, l'entreprise ne détient pas le motif, la phrase de récupération, la clé du coffre, la clé de sauvegarde ou la clé principale nécessaires pour le déchiffrer. Les enregistrements iCloud chiffrés se trouvent dans la base de données CloudKit privée. Toutefois, sur l'appareil, le matériel de récupération est conservé dans une base de données chiffrée protégée par le Keychain et des clés symétriques existent dans la mémoire de l'application pendant que CryptoKit chiffre ou déchiffre un coffre 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'elle pourrait remettre pour la récupération de routine du coffre. L'application livrée, iOS, l'appareil déverrouillé et l'implémentation cryptographique peuvent toujours traiter des données lisibles et doivent donc être dignes de confiance.

Le Keychain et la frontière du processus de l'application

La Secure Enclave d'Apple 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 une clé symétrique arbitraire dérivée par PBKDF2 pour exécuter les opérations AES-GCM de Vaultaire sur les fichiers à l'intérieur du coprocesseur. Vaultaire ne présente donc pas le chiffrement de ses coffres comme de l'AES Secure Enclave.

Vaultaire utilise des éléments de mot de passe génériques du Keychain iOS pour le sel d'appareil 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 diffère d'une clé Secure Enclave non exportable.

Lorsque vous dessinez le motif, CommonCrypto dérive la clé du coffre dans le processus de l'application. CryptoKit et le CryptoEngine de Vaultaire utilisent ensuite des octets de clé symétriques dans ce processus pour authentifier et déchiffrer l'index, désencapsuler 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 dispose d'autres possibilités qu'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 motifs, la mémoire d'application, les aperçus déchiffrés, les exportations ou l'écran. Vaultaire recommande un iPhone à jour et non jailbreaké, car la conception repose sur l'isolement des processus d'iOS, le Keychain et la protection des données. Vaultaire ne prétend pas qu'une compromission au niveau racine laisse inaccessibles les clés symétriques d’un coffre ouvert.

Vecteurs d'initialisation par fichier

Quand vous chiffrez 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 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 un nouveau nonce cryptographique pour chaque opération de scellement AES-256-GCM. 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 nonce de base aléatoire et un nonce distinct pour chaque bloc ordonné. Deux copies d’une même photo ne produisent donc pas la même représentation chiffrée.

Les nonces 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 nonces de 96 bits au générateur aléatoire cryptographique d'Apple pour un chiffrement unique et enregistre le nonce de base dans l'en-tête de streaming. Le risque de collision est régi par le nombre de chiffrements 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 garantie fixe et permanente d'un risque de un sur 2⁹⁶.

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 actif est supprimé. L'application supprime sa session de clé de coffre actuelle et nécessite un autre déverrouillage avant de présenter le contenu du coffre.
• Les enveloppes de clés effacent leurs tampons. 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 prétendre contrôler chaque copie faite par Swift, iOS ou un autre processus.

La prochaine fois que Vaultaire s'ouvrira dans un état verrouillé, vous dessinerez le motif et l'application dérivera à nouveau la clé du coffre avant de pouvoir authentifier l'index et désencapsuler 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'une référence de clé Secure Enclave a été détruite. Après un crash, iOS récupère le processus, mais le code de nettoyage ne peut pas s'exécuter après chaque arrêt brutal.