Multisig 2026 : sept signatures, une seule faiblesse

Le 29 octobre 2026, un attaquant a vidé un portefeuille chaud de Binance de l’équivalent de 6,36 milliards de dollars (environ 5,7 milliards d’euros) en une vingtaine de minutes, selon TRM Labs. C’est le plus gros vol de l’histoire de la crypto, près de quatre fois le piratage de Bybit de février 2025. Le mécanisme tient en une phrase : une seule transaction contenant cinquante autorisations pré-signées a délégué le portefeuille à un contrat siphon qui n’obéissait qu’à l’opérateur. Aucune clé cassée, aucune cryptographie vaincue ; une seule signature a suffi à transférer le contrôle de tout.

Binance n’exploitait pas de multisig sur ce portefeuille, et c’est précisément ce qui rend l’épisode instructif pour quiconque en gère un. Octobre 2026 restera le pire mois de l’histoire des piratages crypto, et l’année a pulvérisé tous les records. Dans ce décompte, les pertes liées aux multisig racontent presque toutes la même histoire : un schéma M-sur-N, censé répartir le risque entre plusieurs signataires, s’est effondré parce que ces signataires partageaient une faiblesse cachée. Sept signatures, une seule faiblesse.

Le casse à 6,36 milliards qui a tout recadré

Le hold-up Binance est devenu le cas d’école de 2026. TRM Labs a reconstitué l’enchaînement : l’attaquant a exploité la fonctionnalité de délégation de compte d’Ethereum, l’EIP-7702, en soumettant une seule transaction porteuse de cinquante autorisations signées. Selon la firme, chacune « était signée par le portefeuille chaud de Binance, et chacune le pointait vers un contrat siphon qui n’accepte d’instructions que de l’opérateur ». Une autorisation correspondait au compteur de nonce au moment de l’exécution ; le contrat a alors vidé le portefeuille de 167 464 ETH et de 63 jetons, dont 1,615 milliard d’USDT, en trois minutes et vingt-quatre secondes.

Le butin s’est éparpillé sur dix chaînes (Ethereum, Bitcoin, Tron, XRP Ledger, Solana, Arbitrum, Optimism, Base, Polygon et Avalanche). TRM a attribué l’opération à TraderTraitor, l’unité d’élite nord-coréenne déjà responsable du vol Bybit. Les émetteurs de stablecoins et le conseil de sécurité d’Arbitrum ont gelé environ 2,7 milliards de dollars ; l’attaquant a conservé près de 2,4 milliards. Côté Ethereum seul, les pertes dépassaient 3,8 milliards de dollars.

Le reste de l’année est à l’avenant. CertiK chiffre les pertes de 2026 à un record d’environ 9,2 milliards de dollars (près de 8,2 milliards d’euros), dont environ 6,5 milliards pour le seul mois d’octobre, tiré par Binance. Le marché n’a offert aucun répit : le 6 novembre, le Bitcoin glissait autour de 76 000 dollars après un rapport sur l’emploi américain, prolongeant un reflux que le rebond avorté de fin octobre avait déjà amorcé. Dans ce climat, la question n’est plus de savoir si un trésor sera visé, mais si son architecture tiendra le choc.

Le fil rouge de ces désastres n’est pas une faille cryptographique. C’est un point de contrôle unique, exactement ce que le multisig est censé éliminer. Binance l’illustre par l’absurde : sur ce portefeuille chaud, il n’existait aucune répartition du pouvoir de signer, et une délégation a suffi. Les multisig, eux, répartissent ce pouvoir ; mais ils ne le répartissent vraiment que si leurs parties sont indépendantes. C’est toute la thèse de cet article.

Ce qu’un multisig protège, et ce qu’il n’empêche pas

Un portefeuille multisignature exige que M signatures parmi N clés autorisées valident chaque transaction. Sur l’écosystème EVM, le standard de fait est Safe (ex-Gnosis Safe), un compte intelligent qui sécurise des dizaines de milliards de dollars d’actifs. L’intérêt est clair : voler une seule clé ne suffit plus, et un signataire malhonnête isolé ne peut rien faire seul. Le multisig supprime le point unique de défaillance d’une clé privée unique.

Reste ce qu’il ne fait pas. Un multisig vérifie qu’il a reçu M signatures valides ; il ne vérifie pas que les M personnes ont compris ce qu’elles signaient, ni que leurs M appareils, canaux et logiciels étaient réellement distincts. Autoriser n’est pas auditer. Le contrat compte des signatures ; il ne juge ni l’intention, ni la véracité de ce qu’on lui présente. Si la même tromperie atteint tous les signataires en même temps, le quorum valide un ordre frauduleux avec la même assurance qu’un virement légitime.

C’est la nuance que les gros titres manquent. On parle de « piratage de multisig » comme s’il s’agissait d’une faille du schéma. Dans presque tous les cas de 2024 à 2026, le schéma a fonctionné comme prévu : il a enregistré des signatures authentiques. Le problème s’est logé en amont (ce que les signataires voyaient, sur quels appareils, via quel revendeur) ou en aval (une permission accordée puis oubliée). Le nombre de signataires ne protège de rien si une seule faiblesse les traverse tous.

Sept signatures, une seule faiblesse

Prenons un multisig 4-sur-7. Sur le papier, il faut compromettre quatre clés indépendantes pour le vider, un obstacle réputé insurmontable. Mais si les sept signataires partagent un facteur commun invisible (le même firmware, le même ordinateur, le même revendeur, la même interface, le même logiciel de validation ou la même approbation oubliée), alors une seule attaque sur ce facteur partagé les met tous à terre d’un coup. Le seuil effectif retombe à 1. L’indépendance des parties, pas leur nombre, fait la sécurité.

Cette grille de lecture explique les plus gros vols liés aux multisig des deux dernières années mieux que n’importe quelle analyse clé par clé. Dans chaque cas, le quorum a bien réuni ses signatures ; c’est la faiblesse partagée qui a transformé un schéma redondant en point unique de défaillance.

Les montants sont convertis au cours du 6 novembre 2026 (environ 1,117 dollar pour un euro). Chaque ligne se lit de la même façon : le multisig n’a pas été brisé, il a été contourné par un défaut commun à ses signataires. Les sections qui suivent reprennent ces axes un par un, de l’humain au logiciel.

Les gens : choisir des signataires indépendants

La première indépendance est humaine. Vitalik Buterin, cofondateur d’Ethereum, résume le problème en deux questions : « Deux questions clés pour utiliser des portefeuilles multisig et à récupération sociale en toute sécurité : (i) qui choisissez-vous comme gardiens, et (ii) quelles instructions leur donnez-vous ? » Des signataires qui relèvent du même employeur, siègent dans le même bureau ou obéissent à la même hiérarchie ne sont pas quatre gardiens, mais un seul réparti sur quatre adresses.

Les cadres de la Security Alliance (SEAL) en tirent des règles concrètes : confier les clés à des personnes de confiance différentes, et prévoir au moins un signataire externe à l’organisation pour les trésors de valeur. Un signataire externe casse la corrélation sociale ; il n’a pas été recruté par le même responsable, formé aux mêmes habitudes, ni joignable sur le même canal compromis.

Car le signataire est la cible, pas le contrat. Les vols Bybit, Drift et Binance sont tous attribués à la Corée du Nord, qui ne casse pas la cryptographie : elle manipule les humains. Hameçonnage ciblé, faux entretiens d’embauche, PDF piégés sur Telegram (le vecteur de Radiant Capital). La professionnalisation de ces campagnes, où un bot sert désormais d’appât, rend la vérification hors bande indispensable : avant toute signature sensible, les signataires se confirment l’ordre par un second canal (appel vidéo, message signé), jamais celui qui a servi à proposer la transaction.

La SEAL insiste d’ailleurs sur un point souvent négligé : toute action administrative critique, comme ajouter ou remplacer un signataire, doit être vérifiée par plusieurs canaux indépendants. Modifier la composition du quorum est aussi lourd de conséquences qu’un virement à neuf chiffres, parfois davantage.

Le matériel : la faille partagée du silicium

La SEAL recommande d’employer des modèles et des fabricants de portefeuilles matériels différents. La raison tient en un mot : la corrélation. Si vos cinq signataires détiennent le même appareil, du même fabricant, acheté au même endroit, un seul défaut matériel les compromet tous en même temps. L’année 2026 a fourni deux démonstrations spectaculaires.

La première est le vol Coldcard, qui a atteint environ 116 millions de dollars (près de 104 millions d’euros) en quatre vagues, à partir du 30 juillet 2026 et sans aucun accès physique aux appareils. Un défaut présent dans le firmware 4.0.0 depuis mars 2021 faisait contourner au portefeuille sa puce matérielle de génération d’aléa, lui substituant un générateur logiciel prévisible. Les graines ainsi produites étaient devinables par force brute ; plus de 5 200 adresses ont été vidées. Même modèle, même firmware, même faiblesse : des milliers d’utilisateurs partageaient sans le savoir la même clé affaiblie.

Rodolfo Novak, cofondateur de Coinkite (le fabricant de Coldcard), a livré un constat qui dépasse son propre produit : « la revue de code assistée par IA peut désormais trouver des bugs latents à une vitesse qui dépasse même les experts les plus chevronnés du secteur ». Autrement dit, les défauts dormants de firmware ne sont plus une hypothèse d’école : des outils automatisés les débusquent plus vite que les défenseurs ne les corrigent.

La seconde démonstration vise la chaîne d’approvisionnement. En octobre 2026, Ledger a confirmé qu’une puce espion avait été implantée dans des appareils vendus par le revendeur CryptoBilis en Asie du Sud-Est (Malaisie, Indonésie, Philippines). Le composant, un microcontrôleur logé à la place d’une batterie réduite, lisait la phrase de récupération de 24 mots affichée à l’écran et la transmettait par le réseau mobile. Selon une trace de Bitquery relayée par BleepingComputer, environ 93,2 millions de dollars (près de 83 millions d’euros) ont été dérobés sur 315 portefeuilles répartis sur six chaînes.

La leçon est brutale pour un multisig : si vos signataires ont acheté leurs appareils au même revendeur, votre diversité matérielle est une illusion. L’implant ne distingue pas un porteur de clé d’un autre ; il capte la graine de chacun. Acheter en direct auprès du fabricant, vérifier les scellés et varier les sources d’approvisionnement deviennent des gestes de sécurité, pas des détails logistiques.

Face à cette complexité, le directeur technique de Ledger, Charles Guillemet, a lui-même prêché la prudence après l’affaire Coldcard. Le 4 août 2026, il a mis en garde contre la tentation de « se précipiter sur le multisig », estimant que « complexifier la configuration peut en réalité introduire des risques supplémentaires » et rendre la récupération plus difficile. Pour beaucoup de particuliers, un portefeuille matériel à signature unique, bien sauvegardé, reste selon lui le choix le plus pratique ; la décision doit se fonder sur un modèle de menace, pas sur un réflexe après le piratage du voisin.

Le logiciel : quand tous les nœuds se trompent ensemble

Il existe une forme de corrélation plus insidieuse encore, car elle frappe au-dessus des clés : le logiciel qui décide de ce qui est valide. Le 6 septembre 2026, le Liquid Network, une sidechain Bitcoin de Blockstream, a vu près de 320 millions de dollars (environ 286 millions d’euros) sortir en une minute, soit 95 % de ses réserves.

Aucune clé n’a été volée. Le défaut se trouvait dans la vérification des preuves de montant d’Elements, le logiciel de nœud dérivé de Bitcoin Core : une clé de cache omettait le type d’actif et le script de destination, si bien qu’une preuve validée une fois dans un contexte légitime pouvait être rejouée dans un contexte malveillant. Les nœuds ont alors cru que des L-BTC non adossés l’étaient ; la fédération de fonctionnaires, en 11-sur-15, a signé une sortie de peg qui paraissait parfaitement valide. Blockstream a confirmé qu’aucune clé fédérale n’avait été compromise.

C’est l’exemple pur du principe selon lequel autoriser n’est pas auditer. Le multisig a signé fidèlement ce que son logiciel lui présentait comme vrai. La faiblesse partagée était la monoculture logicielle : tous les nœuds exécutaient la même implémentation avec le même bug, donc tous se sont trompés à l’identique. L’équivalent, au niveau logiciel, de la diversité matérielle est la diversité des clients : faire tourner plusieurs implémentations indépendantes, afin qu’un seul défaut de validation ne puisse pas convaincre l’ensemble du quorum d’une fausse réalité.

L’interface : vérifier ce que l’on signe

Le vecteur le plus spectaculaire reste l’interface. Le vol Bybit de février 2025, 1,5 milliard de dollars (environ 1,3 milliard d’euros), n’a cassé aucune clé : du code JavaScript malveillant avait été injecté dans l’interface de Safe{Wallet} depuis la machine compromise d’un développeur de Safe. Au moment de signer, l’ordre réellement soumis différait de celui affiché ; les signataires ont approuvé un écran falsifié pendant qu’une transaction toute autre partait en arrière-plan. La faiblesse partagée : la même interface, pour tout le monde.

La parade porte un nom en 2026 : le clear signing. Lancé le 12 mai 2026 par l’Ethereum Foundation dans le cadre de son initiative Trillion Dollar Security, le standard rend les données d’une transaction lisibles par un humain sur l’écran sécurisé du portefeuille, au lieu d’une suite d’octets opaques. Il s’appuie sur l’ERC-7730, un format de descripteurs JSON, complété d’un registre public et d’un système d’attestation. Le principe revendiqué : ce que vous voyez est ce que vous signez. La Fondation le dit sans détour : approuver une transaction est censé être la dernière ligne de défense, et lorsque cela se fait à l’aveugle, cette défense ne tient pas.

En pratique, la discipline consiste à lire les données brutes (adresse cible, fonction appelée, paramètres), puis à recalculer le hash de la transaction sur un appareil propre et isolé pour le comparer à celui affiché. C’est long, c’est fastidieux, et c’est précisément ce que la signature à l’aveugle avait supprimé.

Mais le clear signing a une limite qu’il faut nommer. Il garantit que l’écran reflète fidèlement la transaction ; il ne dit pas que la transaction est économiquement malveillante, ni que la logique de validation sous-jacente est faussée. Il aurait déjoué Bybit (attaque de l’affichage), pas Liquid (attaque de la validité), ni l’approbation dormante d’Avalanche que nous verrons ensuite. La vérification est nécessaire ; elle n’est pas suffisante.

Les permissions dormantes : l’approbation que personne n’a révoquée

Le 26 octobre 2026, un Safe 2-sur-7 sur la C-Chain d’Avalanche, détenant environ 7,45 millions de dollars (près de 6,7 millions d’euros) d’inventaire de trading, a été vidé en un seul bloc. Aucune signature frauduleuse ce jour-là : l’argent est sorti par quatre approbations de jetons que le Safe avait lui-même signées sept mois plus tôt, le 7 mars 2026, puis jamais révoquées.

Ces approbations illimitées (sur l’USDC, le WAVAX, le WETH.e et le BTC.b) pointaient vers une adresse qui, sur Avalanche, ne contenait aucun code. Comme l’explique l’analyse technique de Panda Security, cette adresse était la sortie déterministe de la fabrique publique CreateCall de Safe, à son treizième déploiement, une fabrique jamais utilisée sur cette chaîne. Un attaquant a donc pu y déployer du code et réclamer les jetons approuvés. Un bot d’extraction de valeur (MEV) a copié et devancé sa transaction ; le 27 octobre, un des propriétaires du Safe a négocié on-chain pour laisser au bot 42 500 WAVAX (environ 332 000 euros).

La leçon : une permission accordée est une clé permanente. Les approbations de jetons, les modules activés, les listes blanches, les ensembles de propriétaires et les administrateurs de proxy survivent longtemps après que la transaction a disparu des mémoires. La faiblesse partagée, ici, est un angle mort partagé : une configuration que tous les signataires ont approuvée une fois, puis oubliée ensemble. Ces coffres de trésorerie branchent souvent leur capital sur des marchés de prêt comme Aave ou Morpho, que des grossistes de liquidité tels que Spark refinancent ; chaque intégration ajoute ses propres permissions permanentes à surveiller.

Les bonnes pratiques découlent directement du cas : traiter tout changement de permission comme un virement (même cérémonie, même timelock, même vérification hors bande), auditer et révoquer périodiquement les approbations et modules, proscrire les approbations illimitées, et surveiller en continu les changements de propriétaires, de modules et de listes blanches.

Seuils et diversité : le plancher que fixe la SEAL

Une fois l’indépendance posée comme objectif, les chiffres suivent. Les cadres de la Security Alliance fixent des planchers clairs : au minimum trois signataires, un seuil d’au moins 50 %, et sept signataires ou plus pour tout multisig détenant plus d’un million de dollars (environ 900 000 euros). Ils proscrivent les schémas N-sur-N, où la perte d’une seule clé entraîne la perte définitive de l’accès à tous les fonds.

À ces planchers s’ajoutent les règles de diversité déjà vues : modèles et fabricants de matériel différents, séparation géographique des appareils, au moins un signataire externe pour les trésors de valeur, un appareil de signature dédié (isolé ou durci), et une adresse dédiée par multisig. Le tableau ci-dessous traduit ces seuils en fonction de la valeur gérée.

Un avertissement toutefois, qui est le cœur de cet article : ces nombres ne valent que si les signataires sont indépendants. Sept signataires corrélés (même matériel, même revendeur, même ordinateur) valent, en pratique, un seul. Trois signataires réellement indépendants battent sept signataires clonés. Le seuil est un plancher, pas une garantie ; ajouter des signataires qui partagent la même faiblesse ne fait qu’épaissir l’illusion.

L’axe d’indépendance : la grille de lecture

L’indépendance n’est pas une case à cocher mais un ensemble d’axes, chacun correspondant à une faiblesse partagée observée en 2026. Le tableau suivant met en regard, pour chaque axe, à quoi ressemble la corrélation (le piège) et la pratique qui restaure l’indépendance.

Lire son dispositif ligne par ligne a une vertu : cela révèle les corrélations invisibles. Beaucoup d’équipes croient détenir un 4-sur-7 robuste alors qu’elles ont, dans les faits, un 1-sur-1 sur l’un de ces axes. La sécurité d’un multisig est celle de son axe le plus corrélé.

Gagner du temps et se préparer à l’échec

Même un dispositif bien conçu doit prévoir l’instant où quelque chose cède. Trois pratiques achètent ce temps. D’abord le timelock : un délai obligatoire entre l’approbation d’une transaction et son exécution, qui ouvre une fenêtre pour détecter et annuler un ordre frauduleux. Drift Protocol l’a appris à ses dépens : le conseil de sécurité avait migré vers un schéma sans aucun timelock quelques jours avant le vol d’environ 285 millions de dollars (près de 255 millions d’euros) en avril 2026, supprimant la fenêtre de détection au pire moment, alors que des attaquants détenaient déjà des transactions pré-signées.

Ensuite la simulation : rejouer la transaction avant exécution pour en voir l’effet réel. Utile, mais pas infaillible. Chez Radiant Capital, les outils de simulation ne montraient aucune anomalie parce que les machines des développeurs elles-mêmes étaient compromises ; l’écran mentait en amont de la simulation. La simulation est une couche, pas une preuve. Enfin la surveillance : être alerté en temps réel de toute activité on-chain liée au multisig, qu’il s’agisse d’une transaction proposée, d’une nouvelle signature ou d’un changement de propriétaire ou de module.

Reste la préparation à l’échec. La SEAL a publié une certification d’opérations multisig qui formalise ce que la plupart des équipes improvisent : un responsable désigné, un registre à jour, des revues d’accès trimestrielles, un retrait des droits sous 48 à 72 heures pour les signataires critiques, des procédures d’urgence écrites, des tests de joignabilité réguliers et des exercices annuels. La rotation des clés après tout départ ou tout soupçon de compromission, et un plan de reprise écrit pour le jour où un quorum de clés devient indisponible, complètent le dispositif. Un multisig qui n’a jamais répété sa procédure d’urgence n’en a pas.

Multisig, MPC, miniscript : d’autres façons de partager

Le multisig n’est pas la seule manière de répartir le pouvoir de signer, et le choix du modèle est lui-même une bonne pratique, car chaque modèle échoue différemment. Le calcul multipartite (MPC) découpe une clé unique en parts calculées hors chaîne, puis assemble une seule signature. Safe résume le contraste : le multisig externalise la confiance dans du code vérifiable on-chain, là où le MPC l’internalise dans une infrastructure que l’on ne peut pas vérifier entièrement. Fireblocks ajoute que, dans son approche MPC, la clé complète n’est jamais créée, stockée ni assemblée en un seul endroit.

Chaque modèle a donc son talon d’Achille. Le multisig échoue à l’écran d’approbation (corrigé par le clear signing) ; le MPC et les systèmes d’autorisation automatisés échouent dans un arrière-plan invisible. Le vol Bitget de septembre 2026, environ 387,5 millions de dollars (près de 347 millions d’euros), en est l’illustration côté plateforme : aucune clé privée volée, selon la direction, mais un système d’autorisation interne trompé par des données falsifiées. Le portefeuille chaud de Binance relève de la même famille de défaillances : un contrôle d’autorisation que personne ne voyait.

Pour les particuliers, Charles Guillemet pousse des alternatives plus sobres que le multisig : le miniscript Bitcoin pour des conditions de dépense avancées, le schéma de signature MuSig2, ou tout simplement une signature unique bien sauvegardée. La plupart des systèmes de conservation professionnels, eux, combinent les deux mondes : un multisig on-chain dont chaque clé est elle-même protégée par du MPC. Dans tous les cas, la grille d’indépendance s’applique : un MPC dont toutes les parts vivent sur le cloud d’un même prestataire est aussi corrélé qu’un multisig posé sur un seul ordinateur portable.

AMF, MiCA, DORA : qui répond quand un multisig cède

Toutes les victimes ne sont pas logées à la même enseigne. Lorsqu’un prestataire de services sur crypto-actifs (PSCA, ou CASP) conserve les fonds de ses clients dans un multisig, il répond de ses contrôles de signature. Le règlement MiCA (son régime de responsabilité, à l’article 75) et le règlement DORA sur la résilience opérationnelle informatique lui imposent des obligations précises, et le client dispose d’un recours auprès du régulateur national, l’AMF en France.

Le cadre s’est durci. La période transitoire du régime PSAN issu de la loi PACTE a pris fin le 1er juillet 2026 ; l’AMF avait rappelé dès février 2026 que les acteurs non conformes devaient organiser une sortie ordonnée. Passé l’échéance, l’exercice sans agrément devient un délit, puni jusqu’à deux ans d’emprisonnement et 30 000 euros d’amende au titre du Code monétaire et financier. Le calendrier réglementaire ne se détend pas : il se resserre encore en décembre.

Mais il existe une zone grise décisive : les multisig en auto-conservation, ou pleinement décentralisés, échappent à MiCA. Pas de prestataire, pas de régulateur, pas de recours. Quand Binance est frappé, la plateforme promet de couvrir les pertes sur ses propres fonds ; quand votre 3-sur-5 cède, vous supportez 100 % de la perte. Cette asymétrie est tout l’argument en faveur de routines de sécurité irréprochables : en auto-conservation, vos pratiques sont la seule police d’assurance qui existe. Et si l’horizon macroéconomique reste suspendu au seul rendez-vous de décembre, la sécurité d’un trésor, elle, ne dépend d’aucun banquier central.

La checklist d’indépendance

En résumé, voici les gestes qui transforment un multisig nominal en multisig réellement redondant. Chacun vise à supprimer une faiblesse partagée.

• Choisir des signataires distincts, sans lien de subordination, avec au moins un externe à l’organisation.
• Panacher les modèles et fabricants de portefeuilles matériels ; ne jamais tout acheter au même revendeur.
• Varier les versions de firmware et échelonner les mises à jour, pour qu’un bug unique ne frappe pas tout le monde en même temps.
• Répartir géographiquement les clés et les sauvegardes.
• Activer le clear signing et recalculer le hash de chaque transaction sensible sur un appareil propre et isolé.
• Pour les protocoles, diversifier les clients de validation plutôt que de dépendre d’une seule implémentation.
• Respecter les planchers SEAL : au moins trois signataires, seuil d’au moins 50 %, sept et plus au-delà de 900 000 euros, jamais de N-sur-N.
• Traiter tout changement de permission (approbation, module, propriétaire, proxy) comme un virement : timelock, vérification hors bande, révocation des autorisations dormantes.
• Imposer un timelock, simuler chaque opération, et surveiller en temps réel toute activité on-chain.
• Documenter un plan de reprise, répéter la procédure d’urgence, et faire tourner les clés après tout départ ou soupçon.

Foire aux questions

Un multisig est-il plus sûr qu’un seul portefeuille matériel ?

En principe oui, car il supprime le point unique de défaillance d’une seule clé. Mais seulement si les signataires sont réellement indépendants. Sept signataires qui partagent le même matériel, le même revendeur, le même ordinateur ou la même interface n’offrent pas plus de sécurité qu’un seul. Pour beaucoup de particuliers, un portefeuille matériel unique bien sauvegardé reste plus pratique, comme le rappelle le directeur technique de Ledger.

Qu’est-ce qu’une faiblesse partagée dans un multisig ?

C’est tout facteur commun à plusieurs signataires qui permet de les compromettre d’un seul coup : même modèle de matériel avec le même bug (Coldcard), même revendeur piégé (CryptoBilis), clés sur un même ordinateur (Humanity), même interface falsifiée (Bybit), même logiciel de validation défaillant (Liquid) ou même approbation oubliée (Avalanche). La faiblesse ramène le seuil effectif à un seul signataire.

Comment vérifier ce que l’on signe sur un multisig ?

Il faut lire les données brutes de la transaction (adresse cible, fonction appelée, paramètres) sur un appareil propre et isolé, puis recalculer le hash de la transaction et le comparer à celui affiché. Le standard Clear Signing (ERC-7730) rend ces données lisibles par un humain. La signature à l’aveugle, où l’on approuve un écran sans en comprendre le contenu, est le vecteur du vol Bybit.

Faut-il préférer le MPC au multisig ?

Les deux partagent la clé autrement et échouent différemment. Le multisig est entièrement on-chain et vérifiable mais échoue à l’écran d’approbation ; le MPC est plus souple mais repose sur une infrastructure que l’on ne peut pas vérifier entièrement, comme l’a montré le vol Bitget côté plateforme. La plupart des systèmes professionnels combinent les deux. Dans tous les cas, l’indépendance des parties reste le vrai critère.

Un particulier est-il protégé si son multisig est piraté ?

Cela dépend du cadre. Si les fonds sont confiés à un prestataire régulé (CASP), celui-ci répond de ses contrôles de signature sous MiCA et DORA, avec un recours possible auprès de l’AMF. En auto-conservation, l’utilisateur est hors du champ de MiCA : aucun prestataire, aucun recours réglementaire, la perte est intégrale. Ses propres routines de sécurité sont alors sa seule défense.

Par Anneke de Vries, journaliste sécurité et exploits chez HOGE Wire.