J'ai ajouté un PIN de panique à mon app de coffre photo
Inner Gallery a un second PIN qui ouvre un espace leurre fonctionnel. Retour sur le concept, l'architecture et les pièges à éviter.
Inner Gallery a maintenant un PIN de panique : un second code PIN qui ouvre un espace secondaire fonctionnel avec sa propre clé de chiffrement. Pas de destruction de données, pas de comportement suspect. Juste une app normale avec un contenu différent.
La demande qui revenait sans cesse
Depuis que j'ai lancé Inner Gallery, le même retour revenait régulièrement : « Que se passe-t-il si quelqu'un me force à déverrouiller l'app ? »
Un PIN protège contre la curiosité ordinaire. Mais si quelqu'un se tient à côté de vous et exige votre code, un PIN ne vaut rien. Les options : refuser (suspect), obtempérer (vos photos sont exposées), ou tenter de supprimer des choses en douce (tout aussi suspect).
Je voulais une quatrième option : obtempérer, mais sans rien à trouver.
Le principe : nier de manière crédible
Le concept existe en crypto depuis que TrueCrypt a introduit les volumes cachés il y a plus de dix ans. L'idée est simple : deux mots de passe, deux jeux de données, et aucun moyen de prouver que le second existe.
GrapheneOS a un PIN de contrainte au niveau de l'OS qui efface l'appareil. Les wallets Ledger ont un mécanisme similaire pour les cryptos. Mais la destruction a un défaut : si l'attaquant connaît le concept (et c'est de plus en plus le cas), un appareil vidé est en soi une preuve.
J'ai choisi une autre approche.
Un leurre fonctionnel
Le PIN de panique d'Inner Gallery ne détruit rien. Il ouvre un second espace avec son propre contenu. On peut y importer des photos, les organiser, l'utiliser normalement. De l'extérieur, tout a l'air normal.
L'espace du PIN de panique est une vraie partition avec sa propre clé de chiffrement. Les deux espaces sont isolés cryptographiquement. Même avec un accès complet au disque, rien ne relie l'un à l'autre.
De l'extérieur, l'app se comporte de manière identique quel que soit le PIN entré. Mêmes animations, même temps de chargement, même interface. J'ai aussi ajouté une protection contre les attaques par timing : une dérivation PBKDF2 factice tourne lors de la vérification du PIN de panique pour que le temps de réponse soit le même. Sans ça, la réponse plus rapide du PIN de panique serait détectable.
Les choix techniques
1. Clés de chiffrement séparées. L'espace principal utilise une DEK dérivée du PIN principal via PBKDF2 avec 600 000 itérations. L'espace du PIN de panique a sa propre DEK, dérivée indépendamment. Aucune clé ne peut déchiffrer le contenu de l'autre. C'est le même chiffrement ChaChaPoly utilisé partout dans Inner Gallery, via le framework CryptoKit d'Apple.
2. Zéro fuite de métadonnées. Les index chiffrés (spaces-index.json, media-index.json) sont séparés par partition. Pas d'index global qui référence les deux. En auditant mon propre code, j'ai réalisé que les métadonnées sont souvent le maillon faible : nombre de fichiers, horodatages, tailles — tout ça peut trahir l'existence d'un second espace.
3. L'espace doit être vraiment utilisable. Un leurre vide, c'est un leurre évident. L'espace du PIN de panique supporte tout : import, favoris, tri, opérations par lot, partage avec nettoyage des métadonnées. Il faut le remplir avec du contenu crédible.
Ce que j'ai écarté
PIN d'autodestruction. Un code qui efface tout. Deux problèmes : la perte est irréversible, et une app vide après avoir tapé un code est suspecte en soi. L'approche GrapheneOS a du sens au niveau OS — un téléphone réinitialisé, c'est normal. Dans une app isolée, le vide est un signal d'alarme.
Icône déguisée. Certaines apps se font passer pour une calculatrice. Inner Gallery reste visible — le design honnête prime sur l'obscurité. L'app n'a pas à être secrète, c'est son contenu qui l'est.
Effacement à distance. Ça impliquerait un serveur. Inner Gallery n'a ni serveur, ni comptes, ni cloud.
Le piège du timing
La partie la plus subtile. La dérivation PBKDF2 avec 600k itérations prend un temps mesurable. Pour le PIN principal, l'app dérive la clé puis déchiffre l'index. Pour le PIN de panique, le hash est vérifié instantanément.
Cette différence de temps de réponse est un canal auxiliaire. Si quelqu'un observe les deux PINs et remarque que l'un met 200ms de plus, il sait lequel est le vrai.
La solution : quand le PIN de panique est vérifié, l'app exécute une dérivation PBKDF2 factice. Mêmes itérations, même coût, même délai. L'expérience est identique pour les deux PINs.
Ce genre de détail compte en dev privacy-first. La plupart des apps ne s'en soucient pas. Mais quand la feature est conçue pour les situations où quelqu'un vous observe, la cohérence temporelle est le minimum.
Une feature de sécurité qui fuit des infos via le timing ou des différences de comportement n'en est pas une. C'est du théâtre.
À qui ça sert
Journalistes et activistes. Ceux qui transportent du matériel sensible et risquent une fouille d'appareil à une frontière ou un checkpoint. Le CPJ recommande ce type de protection.
Situations domestiques. Un partenaire contrôlant exige de voir le téléphone. C'est bien plus courant que ce que la plupart des devs imaginent en construisant des outils de vie privée.
Passages aux frontières. Plusieurs pays peuvent légalement forcer le déverrouillage d'un appareil. Le PIN de panique permet de coopérer sans tout exposer.
Je ne sais pas quel cas s'applique à quel utilisateur. Je ne collecte pas d'analytics — je n'ai aucune idée de comment les gens utilisent l'app. C'est voulu. La feature existe parce que le besoin est réel, et ceux qui en ont le plus besoin ne peuvent pas le demander publiquement.
Ce que j'en retiens
Rendre des données indétectables est plus dur que les chiffrer. Le chiffrement est un problème résolu. Faire en sorte que personne ne puisse prouver que les données existent, c'est un autre niveau. Chaque log, chaque timestamp, chaque différence de taille de fichier est une fuite potentielle.
Penser en attaquant. J'ai passé du temps à essayer de casser ma propre implémentation. L'espace de panique est-il détectable depuis le filesystem ? Y a-t-il des différences de timing ? Un comportement observable ? S'auditer soi-même semble fastidieux, mais c'est la seule façon de trouver ces failles.
Les features les plus importantes se livrent en silence. Pas de campagne marketing, pas de branding « propulsé par l'IA ». Le PIN de panique est un toggle dans les réglages. Ceux qui en ont besoin le trouveront.
La suite
Le PIN de panique est dispo dans Inner Gallery, en achat unique.
J'explore la reconnaissance d'objets on-device pour l'auto-tagging, comme mentionné ici. Mais les features de vie privée comme le PIN de panique passeront toujours avant les features de confort. C'est le compromis d'un produit privacy-first.
Pour aller plus loin :
- Pourquoi j'ai créé Inner Gallery — l'histoire d'origine
- Le chiffrement expliqué aux non-développeurs — comment le crypto fonctionne sous le capot
- Soumission App Store pour une app privacy-first — le processus de review et l'audit sécurité
- Zéro dépendances : quand ça compte — pourquoi aucune librairie tierce
- Les apps local-first — la philosophie d'architecture