La façon la plus simple d'imaginer un coffre à photos
Imaginez placer une photographie à l'intérieur d'un coffre-fort.
L'analogie a une limite importante. Un coffre-fort physique contient un objet. Un téléphone peut contenir de nombreuses copies : l'original dans Photos ou la Galerie, une copie importée dans le coffre, une vignette, une version retouchée, une pièce jointe de message, une copie cloud et une exportation. Chiffrer une copie ne protège ni ne supprime automatiquement les autres.
Un coffre protège les données qu'il gère lorsqu'il est verrouillé. Les copies sources, le texte en clair affiché et les exportations relèvent de limites de sécurité différentes.
- La photo est le texte en clair : l'information originale lisible.
- La clé du coffre-fort est la clé de chiffrement : un secret long et aléatoire utilisé par l'algorithme de chiffrement.
- Le coffre-fort verrouillé est le texte chiffré : des données qui devraient paraître dénuées de sens sans la clé.
- Votre mot de passe, code PIN ou schéma prouve que l'app peut utiliser la clé. Il ne devrait pas être la clé utilisée pour chiffrer chaque fichier directement.
Ce qui se passe quand vous importez une photo
Un flux d'importation bien conçu suit généralement quatre grandes étapes :
De nombreux coffres modernes utilisent AES-GCM. AES est le chiffrement par bloc normalisé dans NIST FIPS 197, et GCM est un mode de chiffrement authentifié spécifié dans NIST SP 800-38D.
Ce pedigree normatif compte, mais le nom d'un algorithme seul ne prouve pas qu'une app est sûre. La génération de clés, la gestion des nonces, les métadonnées, les sauvegardes, la gestion des erreurs et la durée de vie du texte en clair comptent tous aussi.
- L'app lit le fichier sélectionné. À ce moment, la photo source peut encore exister dans la photothèque du système.
- L'app crée ou récupère une clé de coffre aléatoire. Les applications sûres utilisent les générateurs cryptographiques de nombres aléatoires du système d'exploitation plutôt qu'un mot mémorable ou une valeur prévisible.
- L'app chiffre et authentifie la photo. La sortie est du texte chiffré plus l'information nécessaire pour vérifier qu'elle n'a pas été altérée.
- L'app stocke le résultat scellé. Lorsque le coffre est verrouillé, l'accès ordinaire de l'app à la clé de déchiffrement est retiré.
Pourquoi votre mot de passe ne devrait pas être la clé du fichier
Les gens choisissent des mots de passe, des codes PIN et des schémas dont ils peuvent se souvenir. Les clés cryptographiques devraient être longues, aléatoires et impossibles à deviner en pratique. Ce sont des tâches différentes.
Une conception saine sépare l'identifiant de la clé aléatoire qui protège le coffre :
Argon2id est un choix moderne de dérivation de clés. La RFC 9106 décrit Argon2 comme une fonction à forte intensité de mémoire et inclut Argon2id comme sa variante principale. Le traitement à forte intensité de mémoire rend chaque tentative plus coûteuse, surtout à grande échelle. Il ne transforme pas 1234, un petit carré ou un mot de passe réutilisé en un secret solide.
Ce modèle en couches rend aussi les changements de mot de passe plus pratiques. L'app peut changer la façon dont l'accès à la clé de coffre stable est enveloppé au lieu de déchiffrer et rechiffrer chaque photo. OWASP décrit la même séparation générale comme une clé de chiffrement de données protégée par une clé de chiffrement de clés distincte dans son Cryptographic Storage Cheat Sheet.
- Vous saisissez un mot de passe, un code PIN ou un schéma.
- Une fonction de dérivation de clés le traite avec un sel unique et consomme délibérément des ressources de calcul.
- Le résultat déverrouille ou désenveloppe une clé de coffre aléatoire.
- La clé de coffre ancre des clés distinctes pour le contenu, les métadonnées ou les fichiers individuels.
Pourquoi le chiffrement authentifié compte
Le chiffrement répond à une question : « Quelqu'un peut-il comprendre ces données sans la clé ? »
L'authentification répond à une autre : « Ces données chiffrées ont-elles été modifiées ? »
AES-GCM combine les deux tâches. Lorsqu'une app scelle un fichier, elle produit aussi une étiquette d'authentification. Si le texte chiffré ou son contexte protégé change, la vérification devrait échouer et l'app devrait refuser de libérer le texte en clair. NIST appelle cela le chiffrement authentifié avec données associées dans SP 800-38D.
Les données associées peuvent lier un enregistrement chiffré à des faits qui ne devraient pas être interchangeables — par exemple, son coffre, son fichier, son type d'enregistrement ou sa position de fragment. Cela aide à empêcher qu'un bloc chiffré valide soit déplacé silencieusement dans le mauvais contexte.
Échouer de façon fermée a un compromis : le texte chiffré endommagé ou modifié peut devenir indisponible. C'est plus sûr qu'afficher une sortie non vérifiée, mais c'est aussi pourquoi les fichiers irremplaçables ont besoin d'une sauvegarde testée.
Une photo est plus que ses pixels en pleine taille
Les médias privés peuvent laisser des indices même quand le fichier original est chiffré. Une conception de coffre complète doit tenir compte de :
Si un coffre chiffre la photo en pleine taille mais laisse une vignette lisible ou un nom de fichier descriptif sur le disque, l'information la plus sensible peut encore être exposée. Une bonne documentation de produit devrait indiquer si sa limite protégée inclut le contenu, les métadonnées, les vignettes et les fichiers temporaires.
- les noms de fichiers et les libellés de l'utilisateur ;
- les dates, les localisations et d'autres métadonnées ;
- les vignettes et les aperçus ;
- les retouches et les versions optimisées ;
- les ressources Live Photo ou vidéo appariées ;
- l'appartenance à des albums et les index de recherche ;
- les fichiers temporaires créés lors de l'affichage ou de l'exportation.
Ce que « verrouillé » signifie réellement
Lorsqu'un coffre est verrouillé, l'app ne devrait plus avoir l'accès ordinaire aux clés de texte en clair actives dont elle a besoin pour afficher les fichiers. Les fichiers chiffrés peuvent rester sur le stockage ; sans la clé requise, ces fichiers ne devraient pas être lisibles de façon significative.
Le déverrouillage change la situation. Pour afficher une image, l'app doit déchiffrer assez de données pour que le système d'exploitation l'affiche. Le texte en clair existe alors en mémoire et sur la voie d'affichage. Le verrouillage par cycle de vie de l'app, les clés à courte durée de vie et le stockage temporaire protégé peuvent réduire l'exposition, mais ils ne peuvent pas rendre invisible le texte en clair visible.
Sur Android, l'Android Keystore peut garder le matériel de clé éligible non exportable et peut le lier à du matériel sécurisé sur les appareils compatibles. La protection des données du Keychain d'Apple fournit de même des classes de protection et des contrôles d'accès imposés par le Secure Enclave pour les éléments sensibles.
Ces fonctions de plateforme sont précieuses, mais elles ne rendent pas sûr un téléphone déjà compromis et déverrouillé. Un logiciel malveillant contrôlant l'app ou le système d'exploitation peut être capable de demander des opérations de clé ou d'observer le texte en clair pendant que l'utilisateur le consulte, même quand la clé elle-même ne peut pas être exportée.
Album masqué, chiffrement de l'appareil et coffre chiffré sont différents
Ces protections peuvent fonctionner ensemble, mais elles résolvent des problèmes différents.
« Chiffré » n'est donc pas une réponse complète. Demandez quelle copie, contre qui, pendant que l'appareil est dans quel état, et qui peut obtenir la clé.
- Protection — Ce qu'elle protège principalement — Autorité de déverrouillage — Limite importante
- Album masqué ou masquage dans la galerie — La découverte accidentelle dans une app de photos — Généralement le verrouillage de l'appareil ou de l'app de photos — L'élément peut rester dans la même photothèque et le même modèle de synchronisation cloud
- Chiffrement du stockage du téléphone — Les données sur un appareil verrouillé ou éteint — Le code de l'appareil et les clés de la plateforme — Une fois l'appareil déverrouillé, les apps autorisées peuvent utiliser leurs données permises
- Coffre à photos chiffré — La copie gérée par l'app pendant que le coffre est verrouillé — L'identifiant du coffre plus la conception de clés de l'app — Les originaux, les exportations, les écrans et les autres copies restent séparés
- Copie cloud chiffrée de bout en bout — Le contenu entre les extrémités autorisées — Clés disponibles pour les appareils autorisés — Le fournisseur peut encore traiter les métadonnées de compte, de chronologie, de taille et de trafic
Ce que signifie le chiffrement à connaissance nulle
Le chiffrement à connaissance nulle est couramment utilisé pour une architecture de service dans laquelle le fournisseur stocke des données chiffrées mais n'a pas les clés nécessaires pour déchiffrer le contenu de l'utilisateur. Le chiffrement se produit avant que les données n'atteignent le fournisseur, et le déchiffrement se produit sur un appareil d'utilisateur autorisé.
Une analogie simple est un hôtel qui vous loue un coffre-fort mais ne reçoit jamais la combinaison. L'hôtel peut stocker et déplacer le coffre-fort. Il peut voir qu'un coffre-fort existe et sa taille. Il ne peut pas ouvrir le coffre-fort pour vous si vous oubliez la combinaison.
Pour un coffre cloud, les questions centrales sont :
Connaissance nulle ne signifie pas que le service n'apprend littéralement rien. Cela décrit l'accès au contenu chiffré, pas l'absence de toutes les métadonnées de service. Cela ne protège pas non plus une extrémité déverrouillée : un téléphone compromis peut observer une photo après un déchiffrement légitime.
Un système peut utiliser les deux descriptions, mais les lecteurs devraient chercher une conception documentée de clés et de récupération plutôt que de se fier à l'une ou l'autre étiquette seule.
Cela crée un compromis réel : une séparation plus forte du fournisseur place plus de responsabilité sur l'utilisateur. Perdre chaque appareil autorisé et chaque secret de récupération peut rendre les données définitivement inaccessibles.
- Les clés de chiffrement sont-elles créées ou dérivées sur l'appareil de l'utilisateur ?
- Le fournisseur reçoit-il jamais la clé ou l'identifiant en clair ?
- Le support du compte peut-il réinitialiser l'accès et révéler les anciens fichiers ?
- Un nouvel appareil a-t-il besoin d'un secret de récupération ou de l'approbation d'un appareil existant ?
- Quelles métadonnées de compte, de chronologie, d'appareil, de taille de stockage et de réseau restent visibles ?
- Connaissance nulle contre chiffrement de bout en bout — Les idées se recoupent, mais l'accent est différent.
- Le chiffrement de bout en bout décrit une voie : seules les extrémités autorisées devraient déchiffrer le contenu pendant qu'il se déplace ou se synchronise à travers un service.
- Le chiffrement à connaissance nulle met l'accent sur l'accès du fournisseur : le fournisseur ne devrait pas posséder l'autorité nécessaire pour déchiffrer le contenu utilisateur stocké.
- Le compromis de récupération — Si le fournisseur manque vraiment d'autorité de déchiffrement, il ne peut pas simplement envoyer un lien de réinitialisation qui restaure l'accès à l'ancien contenu chiffré. La récupération a besoin d'une autre source d'autorité, comme une phrase de récupération, une clé de récupération, l'approbation d'un appareil existant ou une clé exportée auparavant.
Sept questions à poser avant de faire confiance à toute app de coffre
- 1. Qu'est-ce qui est chiffré exactement ? — Cherchez une déclaration explicite sur le contenu original, les vignettes, les noms de fichiers, les métadonnées, les notes et les fichiers temporaires. Un nom de chiffrement seul ne suffit pas.
- 2. D'où viennent les clés ? — L'app devrait utiliser un aléa cryptographiquement sûr pour les clés de contenu. Un mot de passe ou un schéma devrait passer par une conception documentée de dérivation de clés plutôt que de devenir directement une clé de fichier.
- 3. Détecte-t-elle l'altération ? — Cherchez un chiffrement authentifié comme AES-GCM ou ChaCha20-Poly1305, ou une autre construction bien documentée de chiffrer-puis-authentifier. OWASP recommande les modes authentifiés là où ils sont disponibles.
- 4. Qu'advient-il de l'original ? — L'importation et la suppression sont des opérations distinctes. Vérifiez Photos ou la Galerie, Supprimés récemment ou la corbeille, Fichiers, les photothèques cloud, les messages, les albums partagés et les autres appareils.
- 5. Que se passe-t-il si le téléphone est perdu ? — Un coffre chiffré sans copie récupérable protège la confidentialité mais pas la disponibilité. Comprenez si la récupération a besoin de l'appareil d'origine, d'un fichier de sauvegarde chiffrée, d'une phrase, d'un compte ou d'une combinaison.
- 6. Le fournisseur peut-il réinitialiser l'accès et révéler les anciennes données ? — Si oui, le fournisseur ou le système de récupération a une voie vers l'autorité de déchiffrement. Cela peut être une commodité intentionnelle, mais cela devrait être divulgué clairement.
- 7. Les limites sont-elles écrites ? — Une documentation fiable devrait aborder les appareils compromis, les identifiants faibles, les exportations, les limites de suppression, les sauvegardes et les données irrécupérables — pas seulement les noms de chiffrements.
Un exemple fictif
Dans ce scénario fictif, Maya importe un scan de passeport dans un coffre et confirme que la copie en pleine résolution s'ouvre après verrouillage et déverrouillage. Elle crée et teste ensuite la sauvegarde chiffrée documentée. Ce n'est qu'après ces deux vérifications qu'elle examine Photos, Supprimés récemment, Fichiers, Messages et sa photothèque cloud à la recherche de copies sources non désirées.
Le coffre protège sa copie gérée pendant qu'il est verrouillé. La sauvegarde protège contre la perte de l'appareil. Retirer les autres copies réduit l'exposition hors du coffre. Ce sont trois tâches distinctes, et en omettre une change le résultat.
L'identifiant mémorable autorise l'accès à une clé aléatoire ; le chiffrement authentifié transforme la photo gérée en texte chiffré scellé.
Ce que le chiffrement ne peut pas protéger
Un coffre à photos chiffré ne peut pas :
Le bon modèle mental est simple : le chiffrement est puissant à l'intérieur de sa limite déclarée. Une bonne confidentialité vient de la compréhension de cette limite et de la gestion de chaque copie qui la franchit.
- supprimer automatiquement les originaux, les exportations, les messages, les sauvegardes ou les copies des destinataires ;
- empêcher un autre appareil photo de photographier un écran déverrouillé ;
- rendre indevinable un mot de passe ou un schéma faible ou observé ;
- protéger le texte en clair d'un système d'exploitation compromis pendant le déverrouillage ;
- garantir l'effacement physique du stockage flash, des instantanés ou des anciennes sauvegardes ;
- récupérer des données quand chaque copie valide de texte chiffré ou le secret de récupération requis est perdu ;
- masquer toute preuve que l'app ou le stockage chiffré existent.
Questions fréquentes
- Quelqu'un peut-il lire un coffre en copiant ses fichiers ? — Une conception saine vise à rendre le texte chiffré copié illisible sans le matériel de clé requis. Cela décrit une copie hors ligne. Quelqu'un qui contrôle l'appareil d'origine pendant que le coffre est déverrouillé affronte une surface d'attaque différente — et bien plus facile.
- AES-256 suffit-il à prouver qu'une app est sûre ? — Non. AES-256 est un chiffrement normalisé, mais la conception environnante détermine s'il est utilisé de façon sûre. La génération de clés, le mode authentifié, les nonces uniques, les métadonnées, les fichiers temporaires, les sauvegardes et la gestion des erreurs comptent tous.
- Les vignettes sont-elles aussi chiffrées ? — Elles devraient être à l'intérieur de la limite protégée du coffre si elles révèlent du contenu privé. D'autres apps ou le système d'exploitation peuvent encore détenir des aperçus créés avant l'importation ou après l'exportation.
- Changer un mot de passe rechiffre-t-il chaque photo ? — Pas nécessairement. Dans une conception en couches, le mot de passe contrôle l'accès à une clé de coffre aléatoire stable. L'app peut réenvelopper l'accès à cette clé sans rechiffrer chaque objet de contenu simplement parce que l'identifiant a changé.
- Que se passe-t-il si les données chiffrées sont endommagées ? — Le déchiffrement authentifié devrait échouer quand le texte chiffré ou son contexte protégé ne se vérifie pas. Cela empêche l'acceptation silencieuse de données modifiées, mais cela peut rendre un fichier endommagé indisponible. Gardez une sauvegarde testée pour tout ce qui est irremplaçable.
- Une sauvegarde chiffrée est-elle automatiquement privée et récupérable ? — Non. La confidentialité dépend de qui a les clés ; la récupération dépend de la conservation à la fois de l'autorité requise et d'une copie chiffrée valide. Une phrase de récupération ne peut pas recréer un fichier de sauvegarde manquant.
Sources primaires et lectures complémentaires
Pour l'implémentation propre au produit NullVault, voir séparément l'architecture de sécurité et les limites de sécurité.
Guide revu le 30 août 2026.
- NIST FIPS 197 : spécification de l'Advanced Encryption Standard (AES)
- NIST SP 800-38D : mode Galois/Counter (GCM) et GMAC
- RFC 9106 : fonction à forte intensité de mémoire Argon2
- OWASP : aide-mémoire sur le stockage cryptographique
- Android Developers : système Android Keystore
- Android Developers : cryptographie
- Apple Platform Security : protection des données du Keychain
- Apple Platform Security : présentation du chiffrement et de la protection des données
Eli commence par un test non sensible : « commence par un élément non sensible tout en évaluant comment fonctionnent les coffres de photos chiffrés ». Ensuite, Eli suit la deuxième vérification : « verrouille l'app ou l'appareil concerné puis confirme le résultat depuis une nouvelle session ». Ce scénario fictif illustre le processus de décision ; ce n'est pas un compte rendu de tests de produit.
- Le résultat décrit par comment fonctionnent les coffres de photos chiffrés ne couvre pas automatiquement les copies exportées, partagées, en cache ou synchronisées dans le cloud.
- Un identifiant perdu, un conteneur d'app supprimé, un appareil réinitialisé ou une sauvegarde non testée peuvent rendre les données protégées indisponibles.
Que protège réellement un coffre ?
Il protège sa propre copie gérée pendant que cette copie est verrouillée au repos. Il ne protège pas une photo encore dans la pellicule, déjà exportée ou visible sur un écran déverrouillé.
Qui détient la clé d'un coffre chiffré ?
Dans une conception locale d'abord, la clé est dérivée sur votre appareil à partir de votre identifiant et du matériel de clé de la plateforme, c'est pourquoi un identifiant oublié et une voie de récupération non testée peuvent rendre le contenu définitivement indisponible.