Multisig : les bonnes pratiques après les piratages à milliards
Le piratage de Bybit a montré qu'un multisig mal opéré ne protège de rien. Voici les bonnes pratiques pour configurer, signer et gouverner un portefeuille multisignature en 2026.
Le 21 février 2025, l’auteur du casse le plus rentable de l’histoire de la crypto n’a cassé aucun chiffrement. Il a convaincu plusieurs signataires de Bybit de valider une transaction qu’ils ne comprenaient pas. Bilan : environ 401 347 ETH détournés, près de 1,4 milliard d’euros (1,5 milliard de dollars) au cours de l’Ether de l’époque, suivi par CoinGecko. C’est, à ce jour, le plus gros vol de cryptomonnaies jamais enregistré, rapporte CNBC.
Le détail qui dérange : le multisig de Bybit a parfaitement fonctionné. Le seuil de signatures requis a été atteint, la transaction a été validée, le contrat a exécuté ce qu’on lui demandait. Le portefeuille multisignature, présenté depuis des années comme le standard de sécurité des trésoreries crypto, n’a pas été contourné ; il a été retourné contre ses propres détenteurs. Voilà pourquoi les bonnes pratiques multisig méritent une révision sérieuse cette année.
Un multisig, c’est quoi exactement
Un portefeuille multisignature, ou multisig, est un compte qui réclame plusieurs signatures cryptographiques distinctes pour valider une opération. On parle de schéma M sur N : il faut M approbations parmi N détenteurs de clés. Une trésorerie configurée en 3 sur 5 exige trois validations sur cinq signataires possibles. L’objectif tient en une phrase : supprimer le point de défaillance unique que représente une clé privée isolée, dont le vol suffit à tout perdre.
Sur Ethereum et les réseaux compatibles EVM, la quasi-totalité des trésoreries s’appuient sur Safe (ex-Gnosis Safe), une suite de smart contracts audités et publiés en open source sur GitHub. Ce modèle on-chain, où la logique de seuil vit dans un contrat public, se distingue des solutions MPC (multi-party computation) qui fractionnent une clé unique en plusieurs parts. Les deux approches répartissent le pouvoir de signer. Aucune, en revanche, ne protège d’un signataire qui approuve à l’aveugle une transaction piégée, et c’est tout le problème.
Bybit, Radiant, WazirX : la même faille opérationnelle
Trois des vols les plus spectaculaires de ces deux dernières années partagent un scénario quasi identique. Dans aucun cas le contrat multisig n’a été cassé. À chaque fois, les attaquants ont manipulé ce que les signataires voyaient à l’écran pour leur faire valider une opération malveillante maquillée en routine.
Chez Bybit, le groupe Lazarus, rattaché à la Corée du Nord, a d’abord compromis la machine d’un développeur de l’infrastructure Safe{Wallet}, avant d’injecter du JavaScript malveillant ciblant uniquement l’exchange, d’après l’analyse technique de NCC Group. Le FBI a formellement attribué l’attaque à Pyongyang cinq jours plus tard.
Radiant Capital a perdu environ 46 millions d’euros (50 millions de dollars) en octobre 2024. Un malware dissimulé dans un faux document PDF a infecté les postes de plusieurs développeurs, puis remplacé les données envoyées aux portefeuilles matériels Ledger, comme le détaille le post-mortem officiel du projet. WazirX, de son côté, a vu s’envoler près de 215 millions d’euros (235 millions de dollars) en juillet 2024, via un multisig Safe 4 sur 6 partagé avec un dépositaire tiers : l’écran affichait une transaction anodine pendant que la charge utile réelle réécrivait le contrat, analyse la société de sécurité Halborn.
| Incident | Date | Perte estimée | Schéma multisig | Cause principale |
|---|---|---|---|---|
| Bybit | Février 2025 | ~1,4 Md€ (1,5 Md$) | Safe, seuil de 3 signataires | JavaScript malveillant injecté dans l’interface Safe{Wallet} |
| WazirX | Juillet 2024 | ~215 M€ (235 M$) | Safe 4 sur 6 (garde partagée) | Interface du dépositaire falsifiée |
| Radiant Capital | Octobre 2024 | ~46 M€ (50 M$) | Safe 3 sur 11 | Malware sur les postes, blind signing Ledger |
Le point commun saute aux yeux : la cryptographie a tenu, c’est l’interface qui a menti. Ces trois dossiers sont d’ailleurs attribués à la Corée du Nord, dont les opérateurs ont dérobé environ 1,85 milliard d’euros (2 milliards de dollars) de cryptomonnaies sur la seule année 2025, selon Chainalysis, un record relayé par CoinDesk.
Choisir un seuil qui tient la route
Le premier réglage, c’est le seuil. Radiant fonctionnait en 3 sur 11, soit 27 % des signataires : il suffisait aux attaquants d’en piéger trois sur onze, avec huit échecs possibles en réserve. Après l’incident, le projet est passé à 4 sur 7, près de 57 % des détenteurs devant désormais approuver chaque transaction sensible.
La règle pratique tient en une ligne : viser au moins une majorité stricte des signataires pour les opérations critiques. Un schéma 1 sur N n’offre aucune protection, puisqu’une seule clé compromise suffit. Un 2 sur 3 reste fragile pour une trésorerie importante. L’excès inverse a pourtant un coût : un 9 sur 10 paralyse les fonds dès que deux signataires sont indisponibles ou perdent leur clé. Pour la plupart des trésoreries, un 3 sur 5 ou un 4 sur 7 offre un compromis raisonnable entre sécurité et disponibilité ; les réserves les plus lourdes justifient des seuils plus élevés.
Répartir les signataires et leurs appareils
Un seuil élevé ne sert à rien si toutes les clés tombent en même temps. C’est exactement ce qui s’est produit chez Radiant, où les postes de plusieurs développeurs ont été infectés par le même malware, et chez Bybit, où tous les signataires passaient par la même interface compromise. La diversité constitue donc la deuxième ligne de défense.
Concrètement, il faut répartir les signataires entre plusieurs personnes réellement indépendantes, idéalement situées dans des lieux et des organisations différents, afin qu’aucun individu ne contrôle plusieurs clés. Il faut aussi diversifier le matériel : éviter que tous emploient le même système d’exploitation, le même modèle de portefeuille matériel et la même interface de signature, sous peine de créer une compromission corrélée. Pour les montants les plus élevés, la signature sur un appareil isolé du réseau (air-gapped) réduit encore la surface d’attaque.
Le blind signing, le maillon faible
Le vrai coupable des trois piratages porte un nom : le blind signing, ou signature à l’aveugle. Il désigne l’approbation d’une transaction dont le contenu réel n’est pas lisible sur l’appareil de signature, qui n’affiche qu’un hash ou des données brutes incompréhensibles. Le signataire fait alors confiance à l’écran de son ordinateur, c’est-à-dire précisément l’élément que les attaquants avaient piégé.
Face à un appel de contrat complexe, beaucoup de portefeuilles matériels ne montrent pas l’intention réelle de la transaction, seulement une empreinte. Chez Radiant, les développeurs ont ainsi signé sans le voir un appel transferOwnership() qui cédait le contrôle du contrat. La parade s’appelle clear signing : afficher en clair, sur l’appareil sécurisé lui-même, le détail de ce qui est signé. Ledger, dont les appareils étaient impliqués dans l’affaire Radiant, en a depuis fait un cheval de bataille, comme l’explique son analyse de l’attaque Bybit.
Vérifier chaque transaction avant de signer
Puisque l’interface peut mentir, la vérification doit sortir de l’interface. Premier réflexe : simuler la transaction avant de la signer, avec un outil comme Tenderly, pour observer ses effets réels sur la chaîne plutôt que sa description à l’écran. Deuxième réflexe : recalculer de façon indépendante le hash de la transaction, puis le comparer à celui qu’affiche le portefeuille matériel.
Troisième réflexe, le plus simple et le plus négligé : confirmer hors bande l’adresse de destination et le montant. Un appel vidéo, un canal séparé, une checklist contresignée par une autre personne, n’importe quel mécanisme qui ne dépend pas de l’écran potentiellement compromis fait l’affaire. Chez Bybit comme chez WazirX, une vérification croisée des données réelles de la transaction, menée en dehors de l’interface, aurait pu enrayer l’attaque avant la signature finale.
Gouvernance : timelocks, listes blanches et rotation
La technique ne suffit pas sans procédures. Un timelock, qui impose un délai entre l’approbation et l’exécution d’un transfert important, ouvre une fenêtre pour détecter et annuler une opération frauduleuse. Les listes blanches d’adresses de destination et les plafonds de retrait réduisent la marge de manoeuvre d’un attaquant, même après une signature obtenue par ruse.
Côté humain, une trésorerie sérieuse documente la rotation des clés, le retrait immédiat des droits d’un signataire qui quitte l’organisation et un plan de réponse à incident écrit, testé à l’avance. La surveillance on-chain en temps réel, assortie d’alertes sur les mouvements inhabituels, transforme un vol silencieux en signal exploitable. Enfin, mieux vaut séparer les signataires de la trésorerie de long terme de ceux qui gèrent les opérations quotidiennes.
Reste la question des sauvegardes. Chaque clé doit disposer d’une procédure de récupération testée (sauvegarde chiffrée, phrase de récupération stockée hors ligne et répartie), car un signataire qui perd définitivement sa clé peut bloquer un seuil tout aussi sûrement qu’un attaquant. La sécurité d’un multisig se mesure autant à sa résistance au vol qu’à sa capacité à survivre à la perte d’un signataire.
Multisig, MPC et conformité MiCA en France
Faut-il préférer le multisig on-chain au MPC ? Le premier offre une transparence et une auditabilité totales, puisque la logique de seuil est inscrite dans un contrat public ; le second, plus discret et plus souple pour une entreprise, fractionne une clé hors chaîne. Les deux restent vulnérables au blind signing et aux interfaces piégées : le choix relève davantage de l’organisation que de la sécurité brute.
Pour les acteurs réglementés en France, le sujet dépasse la seule technique. Depuis le 1er janvier 2025, le règlement européen MiCA a remplacé l’ancien régime PSAN ; les prestataires doivent décrocher l’agrément PSCA auprès de l’AMF, et la période transitoire s’achève le 1er juillet 2026, précise un communiqué de l’autorité. La conservation de crypto-actifs pour le compte de clients y est un service réglementé : la gestion des clés, la ségrégation des avoirs et la solidité du dispositif de garde font partie intégrante du dossier d’agrément. Un multisig mal gouverné n’est plus seulement un risque financier, c’est aussi un risque de conformité.
Checklist : sept réflexes à adopter
Pour résumer, voici les sept réflexes qui séparent une trésorerie multisig solide d’une cible facile :
- Fixer un seuil au moins majoritaire, par exemple 3 sur 5 ou 4 sur 7, et jamais 1 sur N.
- Répartir les clés entre des personnes, des lieux et des organisations distincts.
- Diversifier les systèmes d’exploitation, les modèles de portefeuilles matériels et les interfaces.
- Bannir le blind signing et exiger le clear signing sur l’appareil sécurisé.
- Simuler chaque transaction et recalculer son hash en dehors de l’interface.
- Confirmer hors bande l’adresse et le montant avant toute signature.
- Ajouter timelocks, listes blanches, surveillance on-chain et plan de réponse écrit.
Aucune de ces mesures n’est révolutionnaire. Appliquées ensemble, elles auraient pourtant sérieusement compliqué la tâche des attaquants de Bybit, de Radiant et de WazirX. Le multisig demeure un excellent outil de sécurité ; encore faut-il le gouverner comme tel, et non le traiter comme une formalité une fois déployé.
Par la rédaction de HOGE Wire, pôle sécurité et exploits.