Déniabilité plausible dans les apps : ce que c'est et pourquoi ça compte

La déniabilité plausible signifie que l'existence des données cachées ne peut pas être prouvée.

Le déni plausible du chiffrement est une propriété de stockage qui permet à un utilisateur de divulguer un ensemble de données sans laisser d'artefact structurel prouvant qu'un autre ensemble de données existe. L'affirmation doit préciser son modèle de menace : une image statique d'un stockage chiffré correctement rempli n'est pas la même chose qu'un appareil actif et compromis, de métadonnées de service cloud ou de copies conservées ailleurs. C'est plus qu'une simple fonction de masquage : cela suppose que le chiffrement, la structure, le remplissage et l'usage opérationnel fonctionnent ensemble.

Ce guide explique comment la déniabilité plausible fonctionne dans les apps, la différence entre la vraie déniabilité cryptographique et les modes leurre cosmétiques, les scénarios réels où elle compte et comment évaluer les affirmations de déniabilité.

Ce que signifie la déniabilité plausible en chiffrement

Dans le langage courant, le déni plausible signifie que vous pouvez nier quelque chose de manière crédible. En cryptographie de stockage, la cible utile est plus étroite : un examinateur du stockage chiffré ne devrait pas pouvoir distinguer le contenu caché de l'espace de remplissage inutilisé, dans le modèle de menace indiqué. Aucune application ne peut étendre cette promesse à un coffre déjà ouvert, à des entrées enregistrées, à des copies externes ou à toute forme de compromission de l'appareil.

Le concept est né dans le chiffrement de disque. TrueCrypt (et son successeur VeraCrypt) a été pionnier du volume caché : un volume chiffré dans un autre volume chiffré. Un mot de passe révèle le volume externe avec des fichiers anodins. Un mot de passe différent révèle le volume interne caché avec des fichiers sensibles. Un examinateur forensique ne peut pas déterminer si un volume caché existe car l'espace inutilisé dans le volume externe est rempli de données aléatoires indiscernables des données chiffrées.

Pour une application, la déniabilité plausible signifie que des identifiants différents (mots de passe, codes PIN, motifs) ouvrent des ensembles de données différents, et qu'aucune métadonnée, aucun registre, aucun indicateur de configuration ni aucun artefact structurel ne révèle l'existence d'autres ensembles de données.

Vraie déniabilité vs. modes leurre cosmétiques

C'est la distinction critique que la plupart des apps ratent.

Mode leurre cosmétique (pas une vraie déniabilité)

Beaucoup d'apps coffre offrent une fonctionnalité « leurre » ou « faux PIN ». Vous définissez un PIN secondaire qui ouvre un espace séparé avec des photos différentes. Le problème : ces apps stockent généralement un indicateur booléen, une entrée de base de données ou un fichier de configuration indiquant qu'un mode leurre existe et est configuré.

Un examinateur forensique qui comprend l'app peut trouver cet indicateur. Trouver un mode leurre configuré prouve que des données cachées existent. La déniabilité est cosmétique — elle fonctionne contre un curieux informel mais échoue sous examen forensique.

Signes de déniabilité cosmétique :

• L'app a un interrupteur « mode leurre » dans les paramètres
• Un fichier de configuration stocke si le mode leurre est activé
• Une table de base de données liste les IDs de coffres avec des indicateurs de type (principal/leurre)
• La structure de stockage de l'app change quand le mode leurre est activé

Vraie déniabilité cryptographique

La vraie déniabilité est une propriété architecturale, pas un interrupteur de fonctionnalité. Le stockage chiffré doit être conçu de sorte que :

1. Chaque identifiant alternatif ne révèle que son propre ensemble de données. Le système ne garde aucun indicateur de leurre qui signalerait un identifiant comme couverture. Un identifiant non valide peut échouer, mais cet échec ne doit pas révéler l’existence d’un ensemble de données non divulgué.

2. Aucun registre de coffres n'existe. L'app ne peut pas énumérer combien de coffres existent. Il n'y a pas de compte, pas d'index, pas de liste d'IDs de coffres.

3. Aucun indicateur de configuration ne révèle les coffres cachés. Il n'y a pas de booléen, pas d'entrée de base de données, pas de fichier de préférences qui indique si des coffres supplémentaires existent.

4. Le stockage est rembourré. La taille totale du stockage consommé ne change pas en fonction du nombre de coffres ou de fichiers.

5. Les données chiffrées sont indiscernables du bruit aléatoire. Il n'y a pas de frontières de fichiers, pas d'en-têtes, pas de marqueurs structuraux qui révèlent où les données d'un coffre se terminent et celles d'un autre commencent.

Scénarios réels où cela compte

La déniabilité plausible n'est pas une préoccupation théorique. Elle répond à des situations réelles, documentées et récurrentes.

Passages aux frontières

Aux États-Unis, les douanes (CBP) peuvent légalement contraindre l'accès à l'appareil à la frontière. Dans ce scénario, un utilisateur avec une vraie déniabilité plausible peut fournir un motif/mot de passe qui ouvre un coffre contenant du contenu anodin. L'examinateur ne peut pas prouver que d'autres coffres existent.

Violence domestique et relations coercitives

À un poste frontalier, un examinateur peut inspecter un appareil et exiger un identifiant. Si une conception offre réellement un déni au niveau du stockage, un identifiant peut révéler un ensemble de données anodin, tandis qu'une image statique ne contient aucun marqueur structurel qui distingue le contenu caché du remplissage. La disposition actuelle de Vaultaire, à un fichier d'index par coffre, n'offre pas cette garantie à un examinateur ayant accès au conteneur d'application.

Vol d'appareil

Un voleur avec des compétences techniques peut tenter d'extraire des données d'un téléphone volé. Avec la vraie déniabilité, le pool de données chiffrées ne révèle rien sur le nombre de coffres, leur contenu ou leur but.

Protection juridique et journalistique

Un voleur possédant des compétences techniques pourrait tenter d’extraire les données d’un téléphone volé. Un stockage niable correctement rempli vise à masquer le nombre d'ensembles de données présents dans le pool, même si l'allocation totale, l'état de l'appareil, les sauvegardes et les traces opérationnelles appartiennent toujours au modèle de menace. Vaultaire chiffre actuellement le contenu mais expose un index local dénombrable par coffre configuré.

Ce que Vaultaire met en œuvre aujourd'hui

Vaultaire atteint la vraie déniabilité plausible cryptographique par une conception architecturale :

Chaque motif ouvre un coffre différent. La grille 5x5 produit une clé via PBKDF2. Un motif différent produit une clé différente. Il n'y a pas de clé maîtresse, pas de liste de coffres, et pas de moyen pour l'app d'énumérer les coffres existants. Dessiner un motif qui n'a pas de coffre associé ouvre simplement un espace de coffre vide — il n'y a pas d'erreur « motif incorrect ».

Vaultaire met en œuvre un accès séparé par motif et une interface normale sans liste visible de coffres. Ces propriétés sont utiles lors de l'utilisation ordinaire de l'application, mais elles ne répondent pas à toutes les exigences de la liste de contrôle de véritable déni ci-dessus.

Les motifs configurés ouvrent des coffres chiffrés distincts. PBKDF2 dérive une clé de coffre à partir du motif et d'un sel commun à tout l'appareil. Une clé configurée authentifie son index chiffré et désencapsule une clé principale aléatoire. Un motif non configuré affiche un état vide plutôt qu'un message de « motif incorrect ».

Le format local est énumérable. Vaultaire stocke un fichier vault_index_<fingerprint>.bin par coffre. L'empreinte ne révèle pas le motif ni le nom du coffre, mais une personne ayant accès au conteneur d'application peut compter les fichiers d'index. L'authentification AES-GCM et le nom de fichier déterministe fournissent également un test hors ligne pour les clés de coffre candidates.

Le stockage local n’est pas de taille constante. Le contenu des fichiers et les métadonnées sont chiffrés, et les blocs de sauvegarde cloud utilisent un remplissage de taille et des enregistrements leurres. Le conteneur d'application local ne réserve pas de pool fixe d'emplacements de coffre réels et factices, de sorte que le stockage total et le nombre d'index peuvent exposer la structure.

Comment évaluer les affirmations de déniabilité

Vaultaire offre donc un cloisonnement de l'interface et un stockage chiffré, et non une garantie, au sens de la théorie de l'information, qu'aucun autre coffre n'existe. Un futur catalogue à capacité fixe avec des emplacements réels et factices indiscernables serait nécessaire pour masquer le nombre de coffres locaux à partir d'un instantané de conteneur d'application hors ligne.

1. Y a-t-il un interrupteur « mode leurre » ? Si oui, c'est cosmétique. Un examinateur forensique peut trouver l'interrupteur.
2. L'app a-t-elle une liste de coffres ou une base de données ? Si oui, l'existence du coffre est prouvable.
3. Les suppositions peuvent-elles être vérifiées hors ligne ? Le texte chiffré authentifié peut valider une clé candidate sans hachage de mot de passe distinct. Demandez ce qui limite le coût de chaque supposition et si la structure du stockage offre une empreinte de clé moins coûteuse à tester.
4. La consommation de stockage change-t-elle avec le nombre de coffres ? Si oui, l'analyse du disque peut estimer le nombre de coffres.
5. L'app peut-elle énumérer les coffres ? Si l'app peut vous montrer une liste de vos coffres, cette liste existe sur l'appareil et est détectable.

Questions fréquentes

La déniabilité plausible est-elle légale ?

Utiliser le chiffrement avec déniabilité plausible est légal dans la plupart des démocraties. Il n'y a pas de loi contre avoir des données chiffrées sur votre appareil dont l'existence ne peut pas être prouvée. Dans certaines juridictions (Royaume-Uni sous RIPA, Australie sous l'Assistance and Access Act), les autorités peuvent contraindre la divulgation de clés de chiffrement. La question juridique de savoir si contraindre la divulgation d'une clé pour des données dont l'existence ne peut pas être prouvée est exécutoire reste un domaine juridique en développement.

Les outils forensiques peuvent-ils détecter la déniabilité plausible ?

Un examinateur qui obtient le conteneur d'application de Vaultaire peut détecter le stockage chiffré et compter ses répertoires de stockage par coffre. Les fichiers racine vault_index_*.bin forment un pool de 64 avec des fichiers leurres, mais les répertoires montrent lesquels sont réels. Les fichiers ne révèlent ni les noms des coffres ni le contenu en clair, mais leur décompte révèle le nombre d'index chiffrés locaux. La conception actuelle cache donc les coffres à la navigation normale, et non à chaque inspection médico-légale du stockage.

La déniabilité plausible fonctionne-t-elle contre un État-nation déterminé ?

AES-256-GCM fournit une limite de chiffrement de contenu solide lorsque les clés, les nonces et l'implémentation sont corrects. Cela ne rend pas la structure de stockage actuelle de Vaultaire niable face à un examinateur étatique : le nombre d'index locaux reste visible, et une compromission en direct peut cibler des motifs, des clés, des aperçus ou des exportations pendant qu'un coffre est ouvert. La fonction actuelle sépare dans l'interface ce que chaque motif ouvre ; cela ne garantit pas qu'un examinateur déterminé ne pourra pas prouver l'existence d'index locaux supplémentaires.

Quelle est la différence entre déniabilité plausible et coffres cachés ?

Les coffres masqués sont des coffres qui ne sont pas visibles dans l’interface normale de l’application. Un déni cryptographique fort est une autre propriété : les données cachées ne peuvent pas être distinguées de l'espace de remplissage inutilisé. Vaultaire fournit actuellement la première propriété. Son format d'un fichier d'index par coffre ne fournit pas le second à un examinateur ayant accès au conteneur d'application.

Puis-je utiliser la déniabilité plausible avec des sauvegardes cloud ?

Vaultaire écrit des manifestes de sauvegarde chiffrés et des blocs de fichiers chiffrés et complétés dans la base de données CloudKit privée de l'utilisateur. Les noms d'enregistrement aléatoires, les types d'enregistrement uniformes, le remplissage de blocs de 10 Mo et les enregistrements leurres réduisent la divulgation directe du contenu. Le nombre d'enregistrements, le volume total, le calendrier et les modèles de mise à jour restent des métadonnées de service visibles, de sorte que la sauvegarde cloud ne constitue pas un stockage de taille constante niable au sens de la théorie de l'information.

Conclusion

Une déniabilité de stockage forte vise à empêcher un examinateur de distinguer les données dissimulées de l'espace libre de remplissage dans un stockage chiffré statique. La plupart des apps qui revendiquent cette fonction proposent des modes leurres cosmétiques, avec des indicateurs de configuration détectables. Satisfaire la définition la plus stricte exige un modèle de menace précis, aucun registre de coffres dénombrable, aucun indicateur de configuration révélateur, un remplissage stable et des enregistrements chiffrés qui n'indiquent pas quels emplacements sont réels.

Vaultaire utilise des motifs configurés pour séparer les coffres chiffrés et conserve les noms et le contenu des coffres hors de l'interface verrouillée. Sa disposition de stockage actuelle expose toujours le nombre d'index chiffrés à qui inspecte le conteneur de l'application. Traitez cela comme une dissimulation au niveau de l’interface soutenue par un chiffrement authentifié, et non comme une preuve qu’aucun coffre supplémentaire n’existe.