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. La réclamation doit nommer son modèle de menace : une image statique d'un magasin chiffré correctement complété est différente d'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 dépend de la collaboration entre le chiffrement, la présentation, le remplissage et la conception opérationnelle.

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 magasin chiffré ne devrait pas être en mesure de distinguer le contenu caché de l'espace rembourré inutilisé au sein du modèle de menace indiqué. Aucune application ne peut étendre cette promesse à un coffre-fort 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.

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. Les informations d'identification alternatives ne divulguent que leur propre ensemble de données. Le système ne conserve pas de drapeau leurre distinct qui identifie un identifiant comme camouflage. Des informations d’identification non valides peuvent é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

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 demander des informations d'identification. Si une conception permet effectivement un déni au niveau du stockage, un identifiant peut divulguer un ensemble de données inoffensif alors qu'une image statique ne dispose pas d'un marqueur structurel qui distingue le contenu caché du remplissage. La disposition actuelle de Vaultaire, à un fichier d'index par coffre-fort, 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 magasin refusable correctement rempli vise à dissimuler le nombre d'ensembles de données occupant le pool, même si l'allocation totale, l'état des appareils, 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-fort 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 implémente un accès séparé par modèles et une interface normale sans liste de coffres-forts visible. 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 modèles configurés ouvrent des coffres-forts chiffrés distincts. PBKDF2 dérive une clé de coffre-fort à partir du modèle et un sel à l'échelle de l'appareil. Une clé configurée authentifie son index chiffré et déballe une clé principale aléatoire. Un modèle non configuré affiche un état vide plutôt qu'un message de « modèle incorrect ».

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

Le stockage local n’est pas de taille constante. Le contenu des fichiers et les métadonnées sont cryptés et les morceaux de sauvegarde dans le 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-fort 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 fournit donc une compartimentation de l'interface et un stockage crypté, et non une preuve théorique de l'information qu'aucun coffre-fort supplémentaire n'existe. Un futur catalogue à capacité fixe avec des emplacements réels et factices indiscernables serait nécessaire pour masquer le nombre de coffres-forts 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 quelles sont les limites du coût de estimation et si la configuration du stockage offre une empreinte digitale de clé moins chère.
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 ?

Les outils forensiques professionnels (Cellebrite, GrayKey, Magnet AXIOM) peuvent détecter que Vaultaire est installé et que des données chiffrées existent. Ils ne peuvent pas déterminer combien de coffres existent, ce qu'ils contiennent ou s'il en existe des supplémentaires. Les données chiffrées sont indiscernables du bruit aléatoire. C'est vérifié par conception, pas affirmé par politique.

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

Un examinateur qui obtient le conteneur d'applications de Vaultaire peut détecter le stockage crypté et le compter vault_index_*.bin fichiers. Les fichiers ne divulguent pas les noms des coffres-forts ni le contenu en texte brut, mais leur décompte révèle le nombre d'index cryptés locaux. La conception actuelle cache donc les coffres-forts à la navigation normale, et non à chaque inspection médico-légale du stockage.

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

AES-256-GCM fournit une limite de chiffrement de contenu solide lorsque les clés, les noms occasionnels et l'implémentation sont valables. Cela ne rend pas la disposition de stockage actuelle de Vaultaire indiscutable pour un examinateur d'un État-nation : le nombre d'index locaux reste visible, et une compromission en direct peut cibler des modèles, des clés, des aperçus ou des exportations pendant qu'un coffre-fort est ouvert. La fonctionnalité actuelle sépare les différents modèles ouverts dans l'interface ; cela ne garantit pas qu'un examinateur déterminé ne pourra pas prouver l'existence d'index locaux supplémentaires.

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

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

Conclusion

Vaultaire écrit des manifestes de sauvegarde chiffrés et des morceaux de fichiers chiffrés complétés dans le domaine privé de l'utilisateur. CloudKit base de données. 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 dans le cloud ne crée pas un magasin d'informations de taille constante et théoriquement niable.

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