Les codes leurres, et pourquoi la plupart ne fonctionnent pas

« Saisissez un second mot de passe et voyez un autre contenu » n'est pas une idée neuve. Les apps coffre-fort à photos le proposent depuis plus de dix ans, et des dizaines d'entre elles le font aujourd'hui sur l'App Store.

La plupart échouent au seul moment où cela compterait. Il vaut la peine de comprendre pourquoi, parce que l'échec ne tient pas à la force du chiffrement. Il tient à quelque chose de beaucoup plus banal.

Le test

Imaginez que la personne à qui vous donnez le code ait déjà utilisé cette app. Elle l'a sur son propre téléphone, ou elle en a lu quelque chose, ou elle en a vu une sur l'appareil de quelqu'un d'autre.

Elle tape le code que vous lui avez donné. L'app s'ouvre.

Y a-t-il quoi que ce soit de visible qui lui dise que c'est le leurre ?

C'est tout le test. Tout ce qui suit décrit les différentes façons dont une app y échoue.

Échec numéro un : le leurre est un autre écran

L'implémentation courante est un branchement dans l'interface. L'app stocke deux mots de passe, compare ce que vous avez tapé aux deux, et affiche la galerie A ou la galerie B.

Cela pose deux problèmes.

Les deux mots de passe existent sur l'appareil. Ils sont dans une base de données, un fichier de préférences ou le trousseau. Récupérez le stockage et vous les récupérez tous les deux, et avec eux le fait qu'il y en avait deux. Le chiffrement des photos n'y change rien, parce que l'app doit pouvoir vérifier un mot de passe qu'on lui donne, ce qui veut dire qu'elle a gardé quelque chose pour le comparer.

La base de données dit qu'il y en a deux. Une colonne appelée is_decoy, un vault_id valant 2, un nombre de lignes. Un examinateur qui lit le stockage de l'app n'a rien à casser. Il lit, et il sait désormais qu'il faut continuer à demander.

Échec numéro deux : le leurre a visiblement l'air d'un leurre

Celui-ci est plus subtil et, en pratique, pire.

Beaucoup d'apps font du leurre une version réduite du vrai coffre. Le vrai coffre a des réglages pour créer et gérer le second mot de passe. Le leurre, non, parce que pourquoi un faux coffre aurait-il besoin de fabriquer de faux coffres ?

Résultat : il manque au leurre une fonction que le vrai possède. Quiconque a déjà vu l'app l'ouvre, jette un œil aux réglages, voit une section qui devrait être là et n'y est pas, et sait en une seconde exactement ce qu'il a sous les yeux.

À ce moment-là, la personne qui a donné le code est plus mal lotie que si elle n'avait jamais installé l'app. Elle n'a rien protégé, et elle a visiblement essayé de le faire, ce qui est un fait bien plus intéressant que tout ce que contient le coffre.

Échec numéro trois : l'app s'annonce elle-même

Une icône avec un cadenas. Un nom contenant « Vault » ou « Secret ». Une fiche qui promet de cacher des choses à des gens.

Rien de tout cela n'est une faiblesse cryptographique. C'est juste une enseigne sur la porte. L'app n'a pas besoin d'être trouvée et cassée si l'on peut la désigner du doigt et l'exiger.

Ce qu'il faut pour réussir le test

Trois propriétés, dont aucune n'est exotique.

Rien de stocké à quoi comparer

Le code ne doit être stocké nulle part, sous aucune forme, empreinte comprise. Il doit être tapé, servir à dériver une clé, puis être oublié.

La conséquence est lourde et non négociable : un code oublié ne peut être récupéré par personne, y compris le développeur. Toute app qui vous propose une option de récupération vous dit qu'elle a gardé quelque chose, et tout ce qu'elle a gardé peut être pris.

Rien sur le disque qui compte les espaces

Si le stockage contient trois blocs chiffrés, un examinateur sait qu'il y a trois choses. La solution est que le stockage ait exactement la même allure qu'il contienne un espace, cinq, ou aucun.

L'approche habituelle est d'allouer tous les emplacements au premier lancement, de tous les remplir de données aléatoires, et de compléter chaque emplacement réel jusqu'à la même taille exacte. Les données chiffrées et les données aléatoires issues d'un bon générateur suivent la même distribution. Rien ne les sépare sans la clé.

C'est pourquoi ces apps ne peuvent pas afficher un chiffre d'« espace utilisé » qui varie. Tout nombre qui bouge est un nombre qui fuit.

Chaque espace identique

C'est ce que la plupart des implémentations ratent, et c'est le vrai sujet du test plus haut.

Le leurre ne doit pas être une version moindre du vrai. Mêmes réglages, mêmes sections dans le même ordre, mêmes formulations, même capacité à créer des espaces à son tour, mêmes messages d'erreur. Il ne doit y avoir aucun badge marquant l'un comme l'original, ni aucune fonction que seul l'original possède.

Le corollaire, c'est qu'il n'y a pas de « sommet ». Un espace doit lister les espaces qu'il a créés et jamais celui dont il vient, pour que celui qui en ouvre un ne puisse pas dire s'il se trouve au premier ou trois niveaux plus bas.

Comment vérifier une app vous-même

Vous n'avez besoin de lire le code source de personne. Quatre questions font l'essentiel du chemin.

Ce dernier point mérite un mot. Le stockage flash ne réécrit pas honnêtement sur place, donc frotter des octets relève du théâtre. La réponse la plus solide est que la suppression jette la clé, ce qui rend les octets restants définitivement illisibles et évite que le nombre de fichiers baisse d'une manière qui montrerait que quelque chose a été retiré.

Où se situe Vessum

Vessum a été bâti autour de ce test, et c'est la raison de plusieurs choix de conception qui paraissent étranges autrement.

Chaque espace a les mêmes réglages et peut créer des espaces à son tour, imbriqués aussi profond que vous voulez. Il n'y a pas d'espace principal ni d'indicateur marquant l'un comme l'original. Le stockage est fait de vingt-quatre emplacements de taille fixe, tous écrits avec des données aléatoires au premier lancement et tous pleins à partir de cet instant, si bien qu'un emplacement contenant un espace et un emplacement ne contenant rien font le même nombre d'octets de données à forte entropie.

Et il n'y a aucune récupération de code, parce qu'il n'y a rien de stocké à partir de quoi le récupérer.

Il y a une limite que nous énonçons clairement : le fait que Vessum soit installé n'est pas caché et ne peut pas l'être. Quiconque regarde le téléphone voit l'app et voit qu'elle contient des données chiffrées. Ce qui reste caché, c'est le nombre d'espaces et leur contenu.

Si vous voulez essayer vous-même de distinguer un emplacement occupé d'un emplacement vide, la page d'accueil exécute la vraie cryptographie dans votre navigateur et vous invite à désigner les emplacements qui contiennent quelque chose. Personne ne fait mieux que le hasard, et c'est précisément l'idée.