12.7 milliers de BTC ont été confisqués ? La ligne de vie aléatoire derrière la sécurité

Le 14 octobre 2025, la cour fédérale de Brooklyn à New York a levé le sceau d'un acte d'accusation, révélant que le ministère de la Justice des États-Unis avait récemment mené la plus grande opération de saisie de cryptoactifs de l'histoire, confisquant environ 127 000 jetons Bitcoin, d'une valeur de plus de 15 milliards de dollars.

Mais le détail le plus choquant est que les autorités américaines ont obtenu la clé privée non pas par le piratage ou l'intrusion dans le système, mais en découvrant un fait absurde : ces clés privées ont été générées dès le départ de manière non « aléatoire ».

On peut dire que cette tempête de plusieurs milliards de dollars, déclenchée par un défaut de clé privée, a instantanément ramené l'attention de l'industrie des récits macro à des détails techniques fondamentaux sur la sécurité des portefeuilles : la randomisation.

12.7 milliers de Bitcoins du « vol » de Rashomon

En y regardant de plus près, cette affaire majeure impliquant environ 127271 jetons Bitcoin (d'une valeur d'environ 15 milliards de dollars) est en réalité un roshomon impliquant un “vol de pool minier”.

L'ensemble de l'événement a deux mots-clés : le schéma de Ponzi et le pool minier Lubian.

Tout a commencé avec une chaîne complexe de blanchiment de gains illégaux, liée à une organisation de type “tuerie de cochon” au Cambodge qui a investi les bénéfices de la fraude dans une activité minière de cryptoactifs Lubian, apparemment légale et contrôlée par elle-même. Le site minier produit sans cesse de nouveaux Bitcoins, et l'argent sale, à l'origine entaché de crimes, est ainsi converti en nouveaux BTC “propres” fraîchement extraits, permettant un blanchiment complet.

Il est intéressant de noter que Lubian a été l'un des plus grands pools miniers au monde en 2020, contrôlant près de 6 % du taux de hachage total du réseau Bitcoin à son pic de puissance de calcul. C'est un tel acteur du minage de Bitcoin très en vue qui est devenu un pivot clé de tout le réseau de blanchiment d'argent illégal.

Source : Arkham

Cependant, de manière paradoxale, LuBian a soudainement été suspecté d'avoir volé 127 426 Bitcoins en décembre 2020.

Pourquoi parle-t-on de soupçons ? Parce que LuBian et les hackers n'ont pas publiquement reconnu cette attaque, seule la plateforme d'intelligence sur la chaîne Arkham a d'abord signalé l'affaire, et Lubian a disparu peu après avoir été touché, fermant soudainement ses activités de minage en février 2021.

Ainsi, l'extérieur a toujours spéculé sur la question de savoir si des pirates informatiques externes avaient volé de l'argent sale ou si le contrôleur de l'escroquerie avait orchestré lui-même le tout, transférant les fonds volés hors du pool minier, tentant de créer une fausse apparence de « vol ». Quoi qu'il en soit, dans tous les cas, cette quantité de Bitcoin d'une valeur inestimable est restée silencieuse sur la chaîne pendant plus de trois ans, devenant une affaire non résolue.

Jusqu'en juillet 2024, environ 127 000 BTC ont soudainement été transférés et consolidés dans le cadre d'un mouvement massif et centralisé, et ces adresses, comparées, correspondent exactement à la destination des fonds « volés » de Lubian en 2020. En y regardant de plus près, le moment est d'une subtilité extrême - il se produit juste avant que les agences d'application de la loi des États-Unis, du Cambodge et de plusieurs pays d'Asie du Sud-Est ne lancent leur opération conjointe.

Et selon les documents de la procédure civile de confiscation du ministère de la Justice des États-Unis, 25 adresses de portefeuille ont été répertoriées, qui correspondent de manière très précise aux adresses des hackers dans l'affaire du vol du pool minier Lubian. En d'autres termes, le gouvernement américain considère que ces BTC n'ont pas été volés par des hackers, mais qu'ils proviennent d'un groupe de fraudeurs et de leurs complices qui ont blanchi de l'argent par le biais de Lubian.

Source : Milk Sad

Bien sûr, le véritable mystère réside dans le fait que, bien que le contrôleur réel de ce groupe de fraude ne soit théoriquement toujours pas appréhendé, le gouvernement américain a déjà obtenu les clés privées correspondantes. Shen Yu, cofondateur de Cobo, estime que les agences d'application de la loi n'ont pas obtenu les clés privées par des méthodes de force brute ou d'intrusion, mais parce que Lubian a utilisé, au cours de ses opérations, un algorithme pseudo-aléatoire présentant de graves défauts, ce qui a conduit à la prévisibilité des clés privées générées par le portefeuille Lubian.

En résumé, la « confiscation » de cet actif à prix exorbitant est due à une vulnérabilité dans le nombre aléatoire de la clé privée, et non à un problème du mécanisme sous-jacent du Bitcoin.

Randomité : L'ordre numérique derrière la sécurité des Cryptoactifs

Alors, qu'est-ce que la randomité ?

Dans le monde de la blockchain, la clé privée est essentiellement un nombre binaire de 256 bits, un chiffre presque abstrait — la taille théorique est de 2 à la puissance 256, bien supérieure au nombre d'atomes dans l'univers, c'est pourquoi la probabilité que la clé privée soit brute forcée tend théoriquement vers zéro :

La randomisation est l'« imprévisibilité » de la génération de clés, de semences ou de mots de passe pour ce gigantesque nombre, en d'autres termes, une clé privée sécurisée doit être générée de manière totalement aléatoire, c'est-à-dire extraite de manière véritablement aléatoire et uniforme parmi les possibilités de 2 à la puissance 256.

Si ce processus d'extraction est complètement aléatoire, il est presque impossible pour un attaquant de heurter votre clé privée par énumération, devinette ou génération répétée. Mais le problème est que, une fois que l'aléatoire est insuffisant, la prévisibilité augmente considérablement, réduisant le champ de la force brute, rendant ainsi la clé privée facile à deviner.

Par exemple, si la source aléatoire utilisée lors de la génération de la clé privée (c'est-à-dire la graine) est trop faible et provient d'une source prévisible (comme un horodatage, un compteur matériel fixe ou des variables faciles à déduire), cela peut réduire la plage de clés privées générées à un ensemble très petit, prévisible et énumérable - certains portefeuilles populaires ont été révélés dans des versions antérieures, où une certaine bibliothèque utilisée dans la version iOS se basait uniquement sur un horodatage pour l'entropie initiale en environnement de production, rendant certaines clés privées de portefeuille très faciles à restaurer par recherche par force brute.

En réalité, les pertes d'actifs cryptographiques causées par des nombres aléatoires faibles ne sont pas une nouveauté. Dès 2015, le groupe de hackers Blockchain Bandit a utilisé un générateur de nombres aléatoires défectueux et des vulnérabilités dans le code pour rechercher systématiquement des clés privées peu sécurisées, réussissant à cibler plus de 700 000 adresses de portefeuilles vulnérables et à voler plus de 50 000 ETH.

Et selon une étude de Milk Sad, il est tout simplement stupéfiant de constater qu'en examinant l'historique des portefeuilles dans une plage de 256 bits, à son sommet historique du 5 novembre 2020, le nombre total de Bitcoin stocké dans ces portefeuilles à faible randomisation a dépassé 53 500 BTC !

Ce qui est encore plus incroyable, c'est que même si les vulnérabilités ont été rendues publiques, il y a encore des gens qui continuent à transférer des fonds vers ces adresses faibles connues…

Dans l'ensemble, ces accidents ne sont pas une faiblesse du protocole Bitcoin lui-même, mais plutôt du niveau de mise en œuvre (portefeuilles, pools de minage, systèmes de gestion de clés) qui n'a pas respecté les exigences d'entropie au niveau cryptographique lors de la génération des clés privées ou qui a mal migré le code de test vers l'environnement de production, transformant ainsi un coffre-fort à l'origine inexploitable en une cible identifiable.

Comment renforcer la ligne de défense de la sécurité ?

Comme mentionné ci-dessus, la clé de la sécurité pour un portefeuille réside dans le fait qu'il soit « pseudo-aléatoire », tant qu'il utilise un algorithme de chiffrement aléatoire de niveau bancaire comme imToken, qui est imprévisible, non reproductible et irréversible, il peut être sécurisé sans souci.

Il convient de noter que la logique de génération de clés privées d'imToken est entièrement open source depuis octobre 2018 (dépôt de code TokenCore), et qu'elle utilise directement le générateur de nombres aléatoires sécurisé fourni par le système d'exploitation sur les systèmes Android et iOS.

Prenons l'exemple d'iOS, l'entropie du système provient des données statistiques des événements du noyau du système sur une période donnée, y compris les entrées tactiles, les interruptions du processeur, le jitter d'horloge, le bruit des capteurs, etc. — ces paramètres varient chaque milliseconde, même le système lui-même ne peut pas les reproduire.

Ainsi, les clés privées générées par imToken possèdent les caractéristiques « imprévisibilité, irréplicabilité, irréversibilité », éliminant le risque de pseudo-aléatoire au niveau de la source d'entropie. C'est aussi la raison fondamentale pour laquelle les utilisateurs d'imToken ne sont pas affectés par des vulnérabilités de type événement Lubian.

Bien sûr, la sécurité technique n'est que la base. Pour mieux comprendre et éviter les risques de sécurité, les points suivants sont également essentiels :

1. Privilégiez l'utilisation de portefeuilles non custodiaux vérifiés par le temps et la communauté, open source et audités (comme imToken), les utilisateurs conditionnels devraient privilégier les portefeuilles matériels (comme imKey), pour isoler davantage la génération de clés privées des risques réseau.

Par exemple, pour le portefeuille matériel imKey, la sécurité de l'aléatoire va encore plus loin : sa clé privée est générée directement par un générateur de nombres aléatoires véritable (True Random Number Generator, TRNG) à l'intérieur d'une puce de sécurité. La puce de sécurité Infineon SLE 78CLUFX5000PH (série SLE78) a même été certifiée selon le niveau BSI AIS 31 PTG.2 en Allemagne, ce qui représente le plus haut niveau d'évaluation de la sécurité pour les sources d'entropie physique. Cette norme exige que la source aléatoire soit soumise à des tests statistiques, à un modélisation de l'entropie et à une surveillance de la santé en ligne pour garantir la qualité de l'aléatoire utilisée pour la génération de clés cryptographiques.

En d'autres termes, la clé privée d'imKey est générée, stockée et ne quitte jamais les limites de la puce de sécurité, sa source aléatoire étant basée sur le bruit physique, sans dépendre d'aucun logiciel ou graine externe, ce qui signifie que même si un attaquant maîtrise complètement le système de l'appareil, il ne peut pas prédire ou reproduire sa clé privée. 2. De plus, ne capturez pas, ne copiez pas et ne collez pas vos phrases de récupération et vos clés privées, ne révélez jamais vos phrases de récupération ou vos clés privées à quiconque ; il est également conseillé d'écrire à la main vos phrases de récupération et de les conserver dans un endroit sûr hors ligne, vous pouvez utiliser une plaque de récupération en acier inoxydable pour la protection contre l'humidité, le feu et la corrosion, et faire des sauvegardes à plusieurs points dans au moins 2 à 3 endroits sécurisés. 3. Enfin, restez vigilant face aux phishing et aux plugins malveillants, la clé publique peut être rendue publique, mais lors de l'accès au portefeuille ou de la signature, assurez-vous de vérifier le lien et évitez d'installer des plugins ou des applications provenant de sources inconnues sur votre appareil.

Conclusion

De manière objective, dans le monde brillant des Cryptoactifs, chaque événement de sécurité majeur est une leçon d'éducation publique coûteuse.

On peut même dire que la sécurité de Web3 est en soi une guerre de longue haleine contre le temps et une lutte contre les probabilités, et nous ne pourrons jamais éliminer complètement les risques.

Mais chacun peut faire avancer les frontières de la sécurité - chaque ligne de code, chaque nombre aléatoire, chaque habitude de sécurité des utilisateurs, est une ligne de défense indispensable dans cette guerre.