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

La pile de sécurité de Vaultaire utilise AES-256-GCM pour le chiffrement des fichiers, PBKDF2 avec 600 000 itérations pour la dérivation de clés, ChaCha20 pour la protection des métadonnées, et le Secure Enclave d'Apple pour la gestion des clés par matériel dédié. Chaque fichier obtient son propre vecteur d'initialisation, chaque coffre-fort obtient son propre sel, et les clés sont effacées de la mémoire quand l'application se verrouille.

La pile cryptographique

La plupart des applications de sécurité choisissent un algorithme de chiffrement et s'en contentent. Vaultaire utilise six mécanismes cryptographiques distincts qui fonctionnent ensemble, chacun choisi pour un modèle de menace spécifique. Le contenu des fichiers est chiffré avec un chiffre. Les métadonnées sont chiffrées avec un autre. Les clés sont dérivées via une fonction coûteuse en calcul. La sécurité matérielle stocke le résultat. Et une architecture Zero-Knowledge garantit que même les personnes qui ont créé Vaultaire ne peuvent pas accéder à tes données.

Ce n'est pas de la complexité pour le plaisir. Chaque couche adresse une surface d'attaque différente. AES-256-GCM gère le chiffrement massif des fichiers car il est rapide et accéléré par matériel sur les puces Apple. ChaCha20 protège les métadonnées car il est à temps constant et résistant aux attaques par mesure du temps de cache. PBKDF2 dérive les clés à travers des centaines de milliers d'itérations, rendant les attaques par force brute computationnellement prohibitives. Le Secure Enclave stocke le matériel cryptographique car la protection logicielle seule ne suffit pas quand quelqu'un a un accès physique à ton appareil.

Ensemble, ces couches forment une architecture de défense en profondeur. Un attaquant devrait casser plusieurs primitives cryptographiques indépendantes simultanément — un scénario qui relève fermement de l'impossible mathématique.

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 en mode Galois/Compteur. C'est le même chiffre utilisé par le gouvernement américain pour les informations classifiées top secret. Ce n'est pas une comparaison marketing. C'est littéralement le même algorithme, la même taille de clé et le même mode de fonctionnement.

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

Ta clé de chiffrement ne surgit pas de nulle part. Elle est dérivée de ton schéma (ou phrase secrète) via une fonction de dérivation de clés — un algorithme spécifiquement conçu pour transformer une entrée fournie par l'humain en une clé cryptographique. Vaultaire utilise PBKDF2 (Password-Based Key Derivation Function 2) avec HMAC-SHA512, un standard recommandé par le NIST utilisé dans les systèmes gouvernementaux et financiers du monde entier.

Comment PBKDF2 protège ton schéma

L'idée centrale de PBKDF2 est la lenteur délibérée. Il prend ton schéma et le fait passer par des centaines de milliers de tours de hachage cryptographique. Chaque tour prend une infime fraction de seconde. Pour toi, tracer ton schéma et attendre le déchiffrement est quasi instantané. Pour un attaquant qui tente de deviner des schémas par force brute, cette fraction de seconde se multiplie par chaque tentative.

Vaultaire configure PBKDF2 avec un nombre d'itérations élevé, spécifiquement calibré pour le matériel moderne. À ces paramètres, chaque tentative de dérivation de clés nécessite un travail de calcul significatif. Un attaquant qui essaierait un milliard de schémas aurait besoin d'années de calcul continu — pour un seul coffre-fort. Et cela suppose qu'il connaisse le sel, qui est unique à chaque coffre-fort et stocké sur ton appareil.

Chaque coffre-fort obtient son propre sel aléatoire cryptographiquement sûr. Ainsi, deux utilisateurs qui tracent le même schéma produiront des clés de chiffrement entièrement différentes. Les tables de correspondance précalculées (rainbow tables) sont inutiles car le sel rend la dérivation de clés unique pour chaque coffre-fort. L'attaquant doit repartir de zéro pour chaque coffre-fort qu'il cible.

ChaCha20 : 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 chiffre toutes les métadonnées avec ChaCha20, un chiffre de flux conçu par Daniel J. Bernstein. ChaCha20 est utilisé en complément d'AES plutôt qu'à la place, pour une raison précise : la diversité cryptographique.

Pourquoi un chiffre séparé pour les métadonnées ?

Utiliser le même algorithme pour le contenu des fichiers et les métadonnées signifie qu'une percée théorique contre cet algorithme exposerait tout d'un coup. En utilisant AES-256-GCM pour le contenu des fichiers et ChaCha20 pour les métadonnées, Vaultaire garantit que même dans l'hypothèse extraordinairement improbable qu'un chiffre soit compromis, l'autre couche reste intacte.

ChaCha20 présente aussi des avantages pratiques pour les métadonnées. C'est un chiffre purement logiciel — il ne repose pas sur les instructions matérielles AES — ce qui rend ses performances parfaitement constantes quelle que soit la donnée chiffrée. Cela élimine les canaux latéraux par mesure du temps de cache, une classe d'attaque où un adversaire mesure la durée du chiffrement pour inférer des informations sur la clé ou le texte en clair. Pour des données petites et structurées comme les métadonnées, cette propriété de temps constant est particulièrement importante.

Architecture Zero-Knowledge

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 repose sur une architecture Zero-Knowledge. Cela signifie que l'entreprise qui crée Vaultaire n'a jamais accès à tes clés de chiffrement, à ton schéma, à ta phrase secrète, ni à tes données non chiffrées. Ni pendant la synchronisation. Ni pendant la sauvegarde. Jamais. Les opérations cryptographiques se déroulent entièrement sur ton appareil. Ce qui quitte ton appareil — si quoi que ce soit le fait — est déjà chiffré avec des clés que toi seul possèdes.

Ce que Zero-Knowledge signifie en pratique

Si une autorité judiciaire remet à Vaultaire une assignation exigeant tes données, l'entreprise peut se conformer pleinement et remettre exactement rien d'utile. Il n'y a aucune clé à livrer. Il n'y a pas de mot de passe maître. Il n'y a pas de porte dérobée. Les blobs chiffrés stockés dans iCloud sont mathématiquement impossibles à distinguer du bruit aléatoire sans ta clé, et ta clé n'existe que dans ta tête (sous forme de schéma) et momentanément dans le Secure Enclave de ton appareil (pendant que l'application est ouverte).

Ce n'est pas une décision de politique. C'est une décision architecturale. Vaultaire ne peut pas accéder à tes données, quelle que soit l'intention, l'incitation ou la pression juridique. Le système est conçu pour que cette capacité n'existe pas.

Intégration du Secure Enclave

La sécurité purement logicielle a ses limites. Quelle que soit la prudence avec laquelle une application gère les clés de chiffrement en mémoire, le système d'exploitation, d'autres applications ou des outils d'accès physique pourraient théoriquement lire cette mémoire. Le Secure Enclave d'Apple élimine cette vulnérabilité en fournissant un environnement isolé par matériel pour les opérations sur les clés.

Le Secure Enclave est un coprocesseur dédié intégré à chaque iPhone moderne. Il possède sa propre mémoire chiffrée, son propre processus de démarrage et sa propre frontière de sécurité. Les clés stockées dans le Secure Enclave ne le quittent jamais — même le processeur principal ne peut pas les lire. À la place, l'application envoie des données au Secure Enclave, qui effectue les opérations cryptographiques en interne et ne retourne que le résultat.

Vaultaire utilise le Secure Enclave pour la gestion des clés. Quand tu traces ton schéma et que la fonction de dérivation de clés produit une clé de chiffrement, cette clé est confiée au Secure Enclave. Toutes les opérations de chiffrement et de déchiffrement ultérieures sont déléguées au matériel. La clé n'existe jamais dans l'espace mémoire de l'application sous une forme qui pourrait être extraite par un débogueur, un outil de jailbreak ou un système d'imagerie forensique.

Cela signifie que même si un attaquant a un accès root à ton iPhone — un scénario qui nécessite un jailbreak sophistiqué — les clés de chiffrement restent inaccessibles. Le Secure Enclave est une puce séparée avec son propre silicium. Compromettre iOS ne compromet pas l'Enclave.

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 élimine cela en générant un vecteur d'initialisation (IV) unique et cryptographiquement aléatoire pour chaque fichier. L'IV est combiné avec la clé de chiffrement lors de l'opération AES-256-GCM, garantissant que même des fichiers identiques octet par octet produisent un texte chiffré entièrement différent. Deux copies de la même photo, chiffrées avec la même clé, ressembleront à des données aléatoires sans aucun lien.

Les IVs sont stockés aux côtés des fichiers chiffrés mais ne sont pas secrets — leur sécurité vient de l'unicité, pas de la confidentialité. Chaque IV est généré par le générateur de nombres aléatoires cryptographiques de l'appareil, qui puise l'entropie dans des sources de bruit matériel. La probabilité de générer deux fois le même IV est astronomiquement faible : environ 1 sur 2⁹⁶ pour les IVs de 96 bits du mode GCM.

Gestion de la mémoire : des clés qui s'autodétruisent

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 adopte une approche agressive de l'hygiène mémoire. Quand tu fermes l'application ou que tu verrouilles ton coffre-fort, voici ce qui se passe immédiatement dans cet ordre :

• Les clés de chiffrement sont écrasées. Les emplacements mémoire contenant le matériel cryptographique sont remplis de zéros, puis de données aléatoires, puis de zéros à nouveau. Ce n'est pas une simple libération de mémoire — la mémoire est activement effacée pour empêcher toute récupération.
• Le matériel de clé dérivé est purgé. Les valeurs intermédiaires du calcul PBKDF2, les tampons temporaires et toute donnée déchiffrée en cache sont mis à zéro.
• Les clés du Secure Enclave sont invalidées. Les références de clés dans le Secure Enclave sont marquées pour destruction, garantissant qu'elles ne peuvent pas être réutilisées sans re-dériver depuis le schéma.
• Les vignettes et aperçus déchiffrés sont effacés. Toutes les données d'image en cache dans la mémoire sont écrasées avant que l'application ne se ferme complètement.

La prochaine fois que tu ouvres Vaultaire, tu repars de zéro. Tu traces ton schéma, la clé est dérivée à nouveau, et le Secure Enclave reçoit une nouvelle référence de clé. Il n'y a pas de jeton de session, pas d'identifiant mis en cache, pas de raccourci. Chaque lancement de l'application est cryptographiquement indépendant du précédent.