Un PIN de leurre — ou duress code, panic PIN, coerced password selon les milieux — est un PIN secondaire qui, au lieu de débloquer le vrai accès, ouvre une interface factice convaincante. L’agresseur croit avoir réussi son extorsion. Le vrai contenu n’a jamais bougé.
Le concept date des années 1970 dans le monde bancaire, est devenu standard dans certaines forces de sécurité, et reste paradoxalement absent de la quasi-totalité des wallets crypto en 2026. Voici pourquoi, comment ça marche, et comment Kronobi l’implémente.
L’idée de base : deux entrées, deux destinations
Un système d’authentification classique a une logique binaire : PIN correct → accès, PIN incorrect → erreur. Un système avec mode leurre a une logique ternaire :
PIN principal (1234) → ouvre le vrai compte
PIN de leurre (000000) → ouvre un faux compte plausible
Tout autre PIN → erreur classiqueL’agresseur qui force la victime à saisir un PIN ne peut pas distinguer les trois cas. Pour lui, l’app s’est ouverte, le solde s’affiche, les transactions sont disponibles. La supercherie n’est détectable qu’en vérifiant a posteriori — typiquement après avoir vidé le faux solde via un transfert, et constaté que rien n’arrive on-chain.
Sous menace immédiate, l’agresseur n’a ni le temps ni l’expertise pour faire cette vérification. C’est la fenêtre que le mécanisme de leurre exploite.
Origines historiques
Banques canadiennes (années 1970-1980)
Plusieurs banques canadiennes et nord-européennes ont expérimenté le concept de silent alarm PIN sur les distributeurs automatiques : un PIN spécifique qui, au lieu de débloquer normalement, déclenchait une alerte silencieuse au commissariat tout en laissant l’agresseur croire que la transaction se déroulait.
Le programme a été progressivement abandonné dans les années 1990 pour des raisons techniques : difficultés d’implémentation cross-réseau, taux de fausses alertes élevé (utilisateurs qui se trompaient de PIN sous stress), et études criminologiques montrant que les agresseurs apprenaient à varier leurs méthodes pour neutraliser le système.
Tor Browser (depuis 2014)
Le projet Tor implémente depuis longtemps une fonctionnalité panic button dans certaines builds : un raccourci clavier qui ferme instantanément le navigateur, vide le cache, et peut éventuellement ouvrir une session leurre avec un contenu anodin. Utilisé par les journalistes en zones répressives.
OpenBSD et certains OS chiffrés
Le système doas d’OpenBSD permet la configuration d’un mot de passe de panique qui, au lieu d’autoriser une élévation de privilèges, déclenche un script personnalisable (typiquement : effacement de données sensibles, alerte distante, ou ouverture d’un environnement de leurre).
Plusieurs OS de smartphones sécurisés (GrapheneOS, /e/OS pour certaines variantes) explorent depuis 2020 des mécanismes similaires de panic wipe ou de profil leurre.
Pourquoi c’est absent des wallets crypto
Trois raisons techniques et trois raisons culturelles expliquent l’absence du mode leurre dans le marché crypto mainstream.
Raisons techniques
1. Les wallets sont conçus pour la sécurité contre les hackers, pas l’agression. Ledger, Trezor, MetaMask, Phantom, etc. partent du modèle de menace “attaquant à distance”. Le code de panique ne protège pas contre ce modèle (un hacker à distance n’aura jamais besoin de coercer un PIN — il aura les clés directement). Donc l’effort de développement n’a pas été priorisé.
2. Le leurre doit être convaincant — c’est-à-dire afficher des balances réalistes, simuler des transactions plausibles, conserver une historique cohérent. C’est du travail UI/UX significatif que les hardware wallets ne savent pas faire (ils ont des écrans minimalistes), et que les logiciels n’ont pas priorisé.
3. Risque de fausse alerte ou de mauvais usage. Un utilisateur qui se trompe entre vrai PIN et code de panique peut, dans certains setups, déclencher une alerte non désirée ou perdre l’accès. Il faut un design soigneux pour éviter ces cas — ce qui demande des cycles de recherche utilisateur que peu d’équipes ont menés.
Raisons culturelles
4. Le narratif crypto a longtemps minimisé les attaques physiques. Pendant des années, la communauté Bitcoin a maintenu un récit “ta clé privée est ta seule défense, le reste est secondaire”. Les wrench attacks étaient considérées comme rares, anecdotiques, le problème des autres. L’affaire Balland a changé la donne en 2025.
5. L’industrie hardware a un conflit d’intérêt. Vendre un Ledger + un service multisig + une assurance crypto, c’est rentable. Vendre un mode leurre est plus difficile à monétiser. L’incitation économique a longtemps pointé ailleurs.
6. L’illusion de la cryptographie omnipotente. Pendant 10 ans, la communauté a survalorisé la couche cryptographique au détriment des couches OPSEC, sociale, physique. Le code de panique adresse la couche physique — un terrain où la culture crypto est encore peu mature.
Comment Kronobi implémente le mode leurre
Kronobi est conçu autour d’un modèle de menace spécifique : un attaquant physiquement présent qui contraint l’utilisateur à débloquer l’app. Trois principes de design en découlent.
Principe 1 — Le code de panique doit être impossible à confondre avec une faute de frappe
Le PIN principal est défini par l’utilisateur (4 à 6 chiffres). Le code de panique est fixe à 0 0 0 0 0 0 — six zéros consécutifs. Ce choix répond à deux contraintes :
- Mémorisation triviale sous stress : pas besoin de réfléchir, pas de risque d’oublier
- Plausibilité d’erreur : six zéros consécutifs ressemble à un code mal frappé / un mauvais code d’usine, ce qui n’éveille pas les soupçons d’un agresseur observant l’écran
- Distinction avec le vrai PIN : très peu d’utilisateurs choisissent
000000comme PIN principal, donc collision faible
Principe 2 — Second déclencheur : Face ID en sauvegarde
Le code de panique a une faiblesse : sous mains tremblantes, écran sale, ou agresseur qui regarde l’écran de près, taper exactement six zéros peut échouer.
Kronobi ajoute un second trigger de secours : un tap sur le bouton Face ID affiché sur l’écran d’accueil. Visuellement, ce bouton ressemble à un raccourci d’authentification biométrique standard (les utilisateurs iOS le connaissent). Pour l’agresseur, c’est un bouton anodin. Pour l’utilisateur entraîné, c’est l’alternative au code de panique quand celui-ci est difficile à saisir.
Principe 3 — Le mode leurre doit ouvrir une UI réaliste
Une fois le code de panique saisi (ou le Face ID button tapé), Kronobi ouvre un wallet crypto visuellement complet :
- Solde plausible (entre 5 000 € et 50 000 € selon configuration utilisateur)
- Liste de cryptos avec icônes réelles (Bitcoin, Ethereum, USDC, etc.) et cours mis à jour
- Historique de transactions factice mais cohérent (dates espacées, montants varios)
- Boutons Envoyer / Recevoir / Échanger fonctionnels en surface
L’agresseur peut simuler un transfert : saisir une adresse de destination, valider, voir un hash apparaître à l’écran, voir le solde diminuer. La simulation va jusqu’au bout. Aucune transaction réelle n’est broadcastée sur la blockchain.
Bonus — Alerte silencieuse en parallèle
C’est ce qui distingue Kronobi des mécanismes de leurre traditionnels (qui se contentent d’ouvrir un faux compte) : pendant que l’écran joue la pièce, l’app envoie en arrière-plan votre position GPS à vos contacts d’urgence via SMS + push chiffré (E2EE Signal Protocol). Pas de notification, pas de son, pas de vibration. L’agresseur n’a aucun moyen visuel de détecter qu’une alerte est partie.
C’est cette combinaison leurre + alerte silencieuse géolocalisée qui constitue l’innovation produit. Les mécanismes de leurre classiques se contentent du leurre. Kronobi transforme la fenêtre d’agression en fenêtre d’alerte.
Limites honnêtes du mode leurre
Trois limites à connaître avant de surévaluer le mécanisme :
1. Si l’agresseur connaît Kronobi et vous force à montrer votre vrai PIN. Le système peut être contourné par un agresseur informé qui exige explicitement la “vraie session”. À ce stade, la défense passe à d’autres couches (multisig, custody différée, refus assumé même au prix d’un risque physique).
2. Si la fenêtre d’agression est très longue (>1h). L’agresseur a alors le temps de tester un transfert, attendre la confirmation on-chain, et constater l’absence. Kronobi peut couvrir ce cas en confirmant visuellement le transfert avec un délai réaliste, mais au-delà d’une certaine durée, la supercherie devient détectable.
3. Si la cible attendue est trop élevée par rapport au solde leurre affiché. Si l’agresseur “sait” que vous avez 10 M€ et que le leurre en montre 50 k€, il insistera. La configuration du solde leurre doit donc être proportionnée à votre profil public.
Aucun outil de sécurité n’est magique. Mais le mode leurre couvre la majorité statistique des scénarios de wrench attack — agression rapide, agresseur non spécialiste crypto, objectif d’extorsion rapide. C’est précisément le profil des 67 cas français de 2025.