💥 Zero Bullshit
Chapitre 05

La clé (publique) du mystère

Pour comprendre comment on a pu vider ces wallets dormants depuis 14 ans, il faut d'abord saisir une chose : le Bitcoin de 2011, c'est l'équivalent d'un Nokia 3310 face à un iPhone 15. Fonctionnel, robuste, mais avec des standards de sécurité qui feraient hausser les sourcils aujourd'hui.

À l'époque, on utilisait massivement le P2PKH3. Un nom barbare qui cache une idée simple : au lieu d'envoyer des bitcoins directement à une clé publique (comme on le faisait dans les tout premiers temps), on les envoie à l'empreinte cryptographique de cette clé. C'est comme si, au lieu de donner votre adresse complète, vous donniez juste votre code postal - mais un code postal magique qui ne peut appartenir qu'à vous.

Ces adresses commencent toutes par « 1 », comme nos 7 wallets mystérieux. C'est la signature de l'époque Satoshi, le marqueur temporel d'une ère où le Bitcoin valait moins qu'un café et où personne n'imaginait qu'on parlerait un jour de milliards.

Pour faire simple sur le fonctionnement, imaginez que vous voulez recevoir des bitcoins. Avec P2PKH :

  • Vous générez une paire de clés : une privée (votre sésame secret) et une publique (ce que vous pouvez partager)
  • Vous hachez votre clé publique avec SHA-256 puis RIPEMD-160 (deux fonctions cryptographiques qui transforment n'importe quelle donnée en bouillie illisible mais unique)
  • Vous construisez l'adresse comme un millefeuille : un byte de version (0x00 pour le mainnet, d'où le « 1 »), votre hash de 160 bits, et un checksum de 4 bytes qui évite les erreurs de frappe. Le tout est encodé en Base58, un alphabet spécial sans les caractères ambigus comme 0, O, l ou I. C'est pour ça qu’on ne confond jamais un zéro avec un O quand on recopie une adresse Bitcoin

Pour dépenser ces fonds, il faut prouver deux choses : que vous connaissez la clé privée correspondante ET que cette clé privée correspond bien à l'empreinte stockée sur la blockchain. C'est élégant, c'est simple, c'est... vulnérable à certaines attaques qu'on ne soupçonnait pas en 2009.

Mais alors, comment tout ça est possible ?

Arkham Intelligence4; plateforme d'analyse crypto, a balancé son hypothèse rassurante dimanche sort : les 80 000 BTC ne seraient pas volés mais simplement migrés. Une mise à jour de format, de P2PKH (adresses en « 1 ») vers Bech32 (adresses en « bc1q »). Comme quand vous passez de Windows 95 à Windows 11, mais avec 8 milliards de dollars.

Techniquement, c'est plausible. Si vous avez la clé privée d'une vieille adresse, rien ne vous empêche de transférer vos fonds vers une adresse moderne que vous contrôlez aussi. Des milliers de holders le font régulièrement pour :

  • Réduire les frais de transaction (SegWit oblige) ;
  • Améliorer la sécurité (protection contre les fautes de frappe) ;
  • Se préparer à l'avenir (compatibilité hardware wallets).

Sauf que plusieurs détails clochent dans cette belle histoire :

L'absence totale d'activité pendant 14 ans. On parle de wallets complètement morts depuis 2011. Pas un mouvement, pas un test, rien. Et paf, 7 d'entre eux se réveillent le même jour, avec des montants ronds de 10 000 BTC pile. C'est comme si sept comateux se réveillaient simultanément pour faire leur jogging.

Les messages gravés dans la blockchain. « LEGAL NOTICE: We have taken possession of this wallet ». « Prove ownership by on-chain transaction before Sept 30 ». Les chiffres de Lost. Ça ressemble plus à une prise d'otage numérique qu'à une paisible mise à jour. Si c'était vraiment le propriétaire légitime, pourquoi cette mise en scène ?

L'absence de signature cryptographique. Le propriétaire aurait pu signer un message avec sa clé privée originelle pour prouver qu'il contrôle toujours les fonds. C'est la base. Là, que dalle.

Arkham ne fournit aucune preuve. Leur hypothèse se base uniquement sur l'observation que les fonds arrivent sur des adresses bc1q. C'est comme dire qu'un braquage n'en est pas un parce que les billets finissent dans un coffre-fort moderne plutôt qu'un vieux matelas.

Oui, migrer de P2PKH vers Bech32 est courant. Mais dans ce cas précis, avec les messages menaçants, le timing parfait, la coordination entre wallets dormants... tout pointe vers une prise de contrôle externe.

Est-ce un hack quantique ? Un vol posthume ? Des ayants droit avec les clés ? On ne sait pas, mais on peut quand même imaginer plusieurs solutions techniques de hack. Les vulnérabilités se classent en trois grandes familles, chacune avec ses spécificités.

Note : ce paragraphe a été rédigé en collaboration avec un expert blockchain, que je remercie. Il a été écrit le samedi, au lendemain de l’attaque. Le dimanche, Cyphertux a publié une longue enquête sur le sujet qui reprend en partie les mêmes hypothèses, et le paragraphe a partiellement été enrichi avec son analyse.

1 - Failles liées au protocole lui-même

La clé publique exposée. C'est LA vulnérabilité fondamentale du P2PKH. Contrairement aux formats modernes, dès que vous dépensez des bitcoins, votre clé publique complète est révélée sur la blockchain. C'est une vulnérabilité à retardement : tant que vous ne dépensez pas, seul le hash est visible. Mais une fois la clé publique exposée, vous n'avez plus que ECDSA5 entre vous et vos fonds.

ECDSA et la menace quantique. Le P2PKH utilise donc ECDSA, vulnérable aux ordinateurs quantiques suffisamment puissants. Google vient d'annoncer Willow avec 105 qubits physiques - on est loin des 1000 à 3000 qubits logiques nécessaires pour casser ECDSA via l'algorithme de Shor. Contrairement à une idée reçue, Taproot a adopté les signatures Schnorr pour leur efficacité et l'agrégation, pas pour la résistance quantique : Schnorr reste aussi vulnérable que ECDSA face à un ordinateur quantique.

La double protection SHA-256 + RIPEMD-160. Soyons clairs : ce combo n'a jamais été cassé. Jamais. C'est l'équivalent cryptographique d'un bunker suisse. Mais dans la crypto, on ne parie pas sur « jamais », on anticipe. D'où la migration progressive vers des standards plus modernes, pas parce que c'est cassé, mais parce qu'on préfère avoir trois longueurs d'avance.

2 - Erreurs humaines et pratiques douteuses

La réutilisation d'adresses. Le péché capital des early adopters. Réutiliser une adresse P2PKH après avoir dépensé expose votre clé publique de manière permanente. Si ECDSA venait à faiblir (notamment avec l'avènement des ordinateurs quantiques), tous les fonds associés à cette clé seraient compromis. Sans compter la perte totale de confidentialité. SegWit et Taproot ont justement été conçus pour rendre la création d'adresses uniques aussi simple qu'un clic.

Stockage catastrophique. En 2011, pas de hardware wallets, pas de phrases mnémoniques standardisées. Les clés privées étaient souvent stockées en clair dans des fichiers wallet.dat, sur des disques durs non chiffrés, voire imprimées sur du papier rangé dans un tiroir. Et si cette mise en scène ne visait qu’à couvrir un vol tout à faire classique dans un appartement ?

3 - Implémentations faibles

Les générateurs aléatoires foireux. Le bug Android de 2013 reste l'exemple parfait. Un défaut dans SecureRandom provoquait la réutilisation de nonces ECDSA, rendant les clés privées calculables. Des centaines de wallets ont été vidés avant le correctif d'août 2013. C'était comme distribuer des clés de maison identiques dans tout le quartier. Encore aujourd’hui, Google déconseille clairement d’utiliser ces fonctions pour protéger quoi que ce soit6.

L'affaire des seeds catastrophiques. Un développeur de Mt.Gox avait généré son wallet avec une seed tellement faible qu'un script Python de 50 lignes pouvait la retrouver en quelques heures7. Son « mot de passe sécurisé » ? Une concaténation de son pseudo et de sa date de naissance. 100 BTC envolés. À l'époque, c'était « juste » 1000$. Aujourd'hui, c'est 10M$.

L'absence de standards. Avant 2013, pas de BIP32 pour les clés déterministes hiérarchiques, pas de BIP39 pour les phrases de récupération. Chaque wallet bricolait sa solution avec des approches parfois fragiles : seeds courtes, mots de passe hashés directement en clés privées, entropie insuffisante.