BitGo Défend Ses Systèmes Après L’Affaire Unocoin

Quand une plateforme d’échange indienne voit des transactions sortir d’un portefeuille censé être gelé, la question qui brûle immédiatement les lèvres est simple : qui détient réellement le contrôle des clés ? Le 13 novembre 2026, BitGo a tranché clairement. Selon la société américaine, ses propres systèmes n’ont jamais été compromis. Les mouvements suspects repérés chez Unocoin ont été signés uniquement avec les deux clés que l’exchange détenait lui-même. Une affirmation qui change complètement la lecture de l’affaire et soulève des interrogations bien plus larges sur la sécurité des wallets en auto-conservation.

BitGo Clarifie La Situation Après Les Transferts Suspects

Dans un message publié sur X le 13 novembre, BitGo a voulu couper court aux spéculations. L’entreprise explique avoir mené une revue complète après avoir été alertée par Unocoin. Le constat est net : le gel du compte demandé le 6 novembre a parfaitement fonctionné côté BitGo. Aucune signature n’a été réalisée avec la clé détenue par le fournisseur de wallets. Les transactions sortantes ont été autorisées uniquement grâce aux deux autres clés, celles que Unocoin conservait de son côté.

Cette précision est essentielle. Dans le modèle de portefeuille proposé par BitGo, trois clés existent. Deux suffisent pour valider une opération. Unocoin détenait la clé utilisateur et la clé de secours. BitGo gardait la troisième. Lorsque les fonds ont bougé, c’est donc la combinaison des deux clés client qui a été utilisée, puis la transaction a été diffusée directement sur la blockchain, hors de la plateforme BitGo.

Les transactions récentes ont été signées avec les clés utilisateur et de secours détenues par Unocoin, puis diffusées en externe sur la chaîne, sans aucune participation de BitGo.

Déclaration officielle de BitGo, 13 novembre 2026

Le fournisseur insiste également sur un point rassurant pour le reste de sa clientèle : aucun autre compte n’a été impacté. Toute question relative aux fonds des utilisateurs d’Unocoin doit désormais être adressée directement à l’exchange indien.

Un modèle de wallet en 2-sur-3 qui change la donne

Pour bien comprendre ce qui s’est passé, il faut revenir au fonctionnement même des wallets BitGo en mode auto-conservation. Ce n’est pas un simple dépôt centralisé. Le client génère lui-même ses clés sur ses propres machines. Il fournit ensuite à BitGo une version chiffrée de la clé utilisateur et la clé publique de secours. BitGo ne possède jamais les clés privées complètes nécessaires pour signer seul une transaction.

En usage normal, les opérations quotidiennes combinent la clé utilisateur et celle de BitGo. Mais le système prévoit aussi une issue de secours. Si BitGo devenait inaccessible, le client peut toujours récupérer ses fonds en associant sa clé utilisateur avec la clé de backup, ou la clé BitGo avec la backup. C’est précisément ce mécanisme de récupération qui semble avoir été utiliséé ici, selon les premières analyses d’Unocoin.

Cette architecture est présentée comme un avantage majeur pour la résilience. Elle garantit que les fonds ne sont jamais totalement dépendants d’un seul acteur. Mais elle place aussi une responsabilité énorme sur les épaules du client, qui doit sécuriser ses propres clés avec un niveau de protection digne d’une banque.

La chronologie des événements côté Unocoin

L’affaire ne commence pas le 13 novembre. Elle démarre plusieurs jours plus tôt. Le 6 novembre, Unocoin détecte une activité suspecte. À 11h24 UTC, l’exchange demande le gel de son compte Fireblocks. Cinq minutes plus tard, il formule la même demande auprès de BitGo. Les deux prestataires confirment le blocage.

Trois jours plus tard, le 9 novembre, de nouvelles activités non autorisées apparaissent. Unocoin décide alors de suspendre tous ses services et de couper l’accès des clients à la plateforme. Le site affiche bientôt une erreur 504. L’exchange communique rapidement pour rassurer : plus de 90 % des cryptomonnaies des clients se trouvent en cold storage. Aucune perte de fonds clients n’est alors annoncée.

Ce n’est que le 12 novembre que l’équipe repère des transactions sortantes provenant d’une adresse Ethereum liée à son infrastructure BitGo. À ce moment-là, le gel en place empêche Unocoin de consulter l’historique complet directement via l’interface du fournisseur. L’exchange doit donc demander les détails transaction par transaction.

Le lendemain, après avoir reçu les précisions de BitGo, Unocoin reconnaît que le gel a bien fonctionné côté prestataire et que les signatures ont été réalisées en dehors de la plateforme. L’investigation se concentre désormais sur la façon dont le mécanisme de backup a pu être utilisé de manière frauduleuse.

Ce que Unocoin soupçonne aujourd’hui

Dans sa mise à jour du 13 novembre, l’exchange indien est plus précis. Il confirme avoir obtenu toutes les informations demandées à BitGo. Il admet que le gel a joué son rôle. Et il oriente désormais ses recherches vers une exploitation possible du système de récupération prévu pour les situations d’urgence.

Ce mécanisme, conçu pour permettre de récupérer les fonds si BitGo n’était plus disponible, nécessite plusieurs éléments : la clé utilisateur chiffrée, la clé de backup, la phrase de passe du wallet, l’adresse de destination, et pour Ethereum l’adresse du contrat de wallet. Pour les tokens ERC-20, il faut en plus l’adresse du contrat du token.

Si un attaquant a pu mettre la main sur ces éléments, il a pu générer une transaction entièrement signée et la diffuser lui-même sur le réseau, sans jamais passer par les serveurs de BitGo. C’est exactement le scénario que décrit aujourd’hui le prestataire américain.

Unocoin précise qu’il examine encore plusieurs points critiques : l’ampleur exacte des pertes éventuelles, la manière dont l’accès aux clés de backup a été obtenu, et la possibilité qu’une fuite d’informations privées ait également eu lieu. Pour l’instant, aucun chiffre définitif n’a été communiqué, ni aucune identification formelle de l’auteur des mouvements.

Les limites du gel de compte dans un modèle multi-clés

Cette affaire met en lumière une réalité souvent mal comprise par les utilisateurs. Un gel de compte chez un fournisseur de wallets multi-signatures n’équivaut pas toujours à un gel total des fonds. Si le client conserve deux clés sur trois, il reste techniquement capable de sortir les actifs même après le gel, à condition de disposer des éléments nécessaires à la récupération hors ligne.

BitGo a conçu ce système pour éviter qu’un client ne se retrouve prisonnier d’un prestataire défaillant ou d’une décision arbitraire. C’est une garantie de souveraineté. Mais cette même garantie devient une vulnérabilité dès que les clés client sont compromises. Le gel ne protège alors que contre les opérations passant par la plateforme BitGo elle-même.

Dans le cas d’Unocoin, le gel a bien empêché toute signature impliquant la clé BitGo. Il n’a en revanche pas pu empêcher l’utilisation des deux clés restées sous le contrôle de l’exchange. C’est toute la différence entre un modèle purement custodial et un modèle d’auto-conservation partagée.

Les implications pour les exchanges qui utilisent des wallets multi-signatures

La plupart des plateformes d’échange sérieuses s’appuient aujourd’hui sur des prestataires spécialisés comme BitGo ou Fireblocks pour gérer une partie de leurs réserves. Ces solutions apportent des couches de sécurité avancées, des audits réguliers et des processus de conformité stricts. Elles ne suppriment cependant jamais la nécessité pour l’exchange de protéger ses propres clés avec la même rigueur.

Unocoin avait déjà signalé un accès non autorisé à ses serveurs le 9 novembre. C’est probablement à ce moment-là que les éléments permettant d’utiliser le mécanisme de backup ont pu être extraits. Une fois ces informations en main, l’attaquant n’avait plus besoin de passer par les interfaces officielles. Il pouvait signer et diffuser les transactions en toute autonomie.

Cette séquence rappelle que la sécurité d’un système multi-clés est égale à celle de son maillon le plus faible. Si les clés client sont stockées sur des serveurs compromis, ou si les phrases de passe sont accessibles, le modèle 2-sur-3 perd une grande partie de son intérêt défensif.

Ce que l’on sait et ce qui reste flou

À ce stade, plusieurs éléments sont établis avec certitude. Le compte Unocoin chez BitGo a bien été gelé le 6 novembre. Le gel a empêché toute utilisation de la clé BitGo. Les transactions sortantes ont été signées avec les deux clés détenues par Unocoin. Elles ont été diffusées directement sur la blockchain Ethereum. Aucun autre client de BitGo n’a été touché.

En revanche, plusieurs zones d’ombre persistent. Le montant exact des fonds sortis n’a pas été confirmé. L’identité de la personne ou du groupe qui a utiliséé les clés de backup reste inconnue. Le niveau d’exposition des données personnelles des clients d’Unocoin n’est pas encore tranché. Et la façon précise dont l’accès aux éléments de récupération a été obtenu fait toujours l’objet d’investigations internes.

Les leçons pour les utilisateurs et les plateformes

Cette affaire offre plusieurs enseignements concrets. Pour les exchanges, elle rappelle que confier une partie de la gestion des wallets à un prestataire spécialisé ne dispense pas d’une sécurisation irréprochable de ses propres clés et de ses systèmes internes. Un accès serveur réussi peut suffire à contourner les protections mises en place côté fournisseur.

Pour les utilisateurs, elle illustre la différence fondamentale entre un wallet purement custodial et un modèle d’auto-conservation partagée. Dans le second cas, le prestataire ne peut pas toujours bloquer totalement les sorties de fonds une fois que le client possède deux clés. C’est à la fois une force et une faiblesse, selon la qualité de la protection des clés client.

Les procédures de récupération hors ligne, souvent présentées comme un filet de sécurité, doivent être traitées avec le même niveau de confidentialité que les seed phrases d’un hardware wallet. Toute personne qui y accède peut potentiellement vider le portefeuille sans laisser de trace dans les journaux de la plateforme.

Unocoin face à la reconstruction de ses services

Parallèlement à l’enquête sur les mouvements de fonds, Unocoin travaille à la remise en état de son infrastructure. L’exchange avait estimé initialement qu’il lui faudrait quatre à cinq jours ouvrés pour reconstruire et sécuriser ses serveurs, puis procéder aux vérifications nécessaires avant de rouvrir l’accès aux clients.

La suspension des services a été motivée par la découverte d’un accès non autorisé à l’infrastructure. Les systèmes touchés et la nature exacte des informations potentiellement exposées restent sous revue. L’exchange a maintenu dès le début que la grande majorité des actifs clients se trouvaient en stockage à froid, ce qui limite théoriquement l’exposition.

La communication progressive d’Unocoin montre une volonté de transparence, même si les détails les plus sensibles restent encore protégés le temps de l’investigation. L’échange d’informations avec BitGo a permis de clarifier la partie technique liée aux signatures, ce qui évite désormais de faire porter à tort la responsabilité sur le prestataire de wallets.

Pourquoi BitGo a tenu à communiquer rapidement

Dans un secteur où la confiance est fragile, un silence prolongé de la part d’un acteur majeur comme BitGo aurait immédiatement alimenté les rumeurs d’une faille généralisée. En publiant rapidement sa position, la société a cherché à protéger sa réputation et à rassurer l’ensemble de sa clientèle institutionnelle et retail.

La déclaration insiste lourdement sur deux points : le gel a fonctionné comme prévu, et la clé BitGo n’a jamais été utilisée. Ces deux affirmations permettent de cantonner l’incident au périmètre d’Unocoin et de ses propres procédures de sécurité interne. Pour un prestataire qui gère des milliards d’actifs, cette distinction est cruciale.

BitGo renvoie explicitement les questions relatives aux fonds des clients vers Unocoin. C’est une façon de marquer la limite de responsabilité dans un modèle où le client conserve une part significative du contrôle des clés.

Le contexte plus large des incidents de sécurité en 2026

L’année 2026 n’est pas épargnée par les problèmes de sécurité dans l’écosystème crypto. Les attaques ciblent de plus en plus les infrastructures des exchanges et les mécanismes de récupération plutôt que les protocoles blockchain eux-mêmes. Les acteurs malveillants savent que les contrats intelligents sont souvent audités, tandis que les procédures internes et les clés de secours restent parfois moins protégées.

Dans ce contexte, l’affaire Unocoin s’inscrit dans une tendance plus générale. Les modèles multi-signatures apportent une vraie amélioration par rapport aux wallets à clé unique, mais ils déplacent la surface d’attaque vers la gestion des secrets côté client. Tant que ces secrets restent accessibles sur des serveurs ou via des procédures de récupération insuffisamment cloisonnées, le risque demeure élevé.

Les plateformes qui opèrent dans des juridictions comme l’Inde font face à une pression réglementaire croissante. Tout incident de sécurité est désormais scruté non seulement par les utilisateurs, mais aussi par les autorités locales. La façon dont Unocoin gérera la suite de l’affaire, notamment la communication sur d’éventuelles pertes et les mesures de compensation, sera observée de près.

Les questions qui restent en suspens

Plusieurs interrogations continuent de planer. Comment les éléments nécessaires à la récupération hors ligne ont-ils pu être extraits malgré les mesures de sécurité en place ? Existe-t-il des logs permettant de retracer l’accès aux clés de backup ? Les fonds sortis pourront-ils être suivis sur la blockchain et potentiellement gelés sur d’autres plateformes ?

Unocoin n’a pour l’instant donné aucun chiffre précis sur les montants concernés. Les premières analyses on-chain évoquées par certains observateurs montraient des soldes proches de zéro sur un grand nombre d’adresses liées à l’exchange, mais ces données restent à interpréter avec prudence. Elles ne distinguent pas nécessairement les fonds en cold storage des liquidités opérationnelles.

La suite de l’enquête devrait apporter des réponses plus précises. En attendant, BitGo a clairement marqué son territoire : ses systèmes n’ont pas été piratés, son gel a fonctionné, et la responsabilité des signatures repose entièrement sur les clés que Unocoin détenait.

Ce que cette affaire change pour l’avenir des wallets institutionnels

Au-delà du cas particulier d’Unocoin, l’incident devrait pousser les acteurs du secteur à revoir leurs procédures de gestion des clés de secours. Les mécanismes de récupération conçus pour les situations d’urgence doivent eux-mêmes être protégés par des contrôles d’accès extrêmement stricts, idéalement avec des éléments matériels et des procédures multi-personnes.

Certains prestataires proposent déjà des solutions où la clé de backup est elle-même divisée ou stockée hors ligne dans des conditions ultra-sécurisées. D’autres explorent des modèles dans lesquels le client ne détient jamais deux clés complètes simultanément, ce qui rend plus difficile une sortie non autorisée même en cas de compromission partielle.

La transparence de BitGo dans cette affaire pourrait aussi servir de modèle. En communiquant rapidement et précisément, le prestataire a évité que le doute ne s’installe durablement sur la solidité de son infrastructure. Dans un marché où la confiance se construit lentement et se détruit en quelques heures, cette réactivité a une valeur réelle.

Pour Unocoin, le chemin est plus long. L’exchange doit non seulement sécuriser à nouveau ses systèmes, mais aussi restaurer la confiance de ses utilisateurs indiens. La façon dont il communiquera sur l’origine exacte de la compromission et sur d’éventuelles pertes déterminera en grande partie sa capacité à se relever.

Une affaire qui rappelle les fondamentaux de la sécurité crypto

Au fond, cette histoire ramène à une vérité simple mais souvent oubliée. Dans l’univers des cryptomonnaies, celui qui contrôle les clés contrôle les fonds. Les architectures multi-signatures et les gels de compte apportent des couches de protection supplémentaires, mais elles ne suppriment jamais cette règle de base.

Lorsque deux clés sur trois sont détenues par le même acteur, la compromission de cet acteur peut suffire à vider le wallet, même si le troisième détenteur a parfaitement joué son rôle de garde-fou. C’est exactement ce qui semble s’être produit ici.

BitGo a fait ce qu’on attendait d’elle : geler le compte lorsqu’on le lui a demandé, et ne jamais utiliser sa propre clé dans des transactions non autorisées. Le reste de la responsabilité reposait sur Unocoin et sur la protection de ses propres secrets. C’est cette partie du dispositif qui a apparemment cédé.

Les prochains jours et semaines permettront sans doute d’y voir plus clair sur les montants exacts et sur les mesures correctives mises en place. En attendant, l’affaire Unocoin-BitGo restera comme un cas d’école sur les forces et les limites des modèles d’auto-conservation partagée dans le monde des exchanges centralisés.

Les utilisateurs, eux, retiendront peut-être une leçon plus personnelle. Même lorsqu’une plateforme confie une partie de ses wallets à un prestataire réputé, la sécurité globale dépend toujours de la solidité de chaque maillon de la chaîne. Et dans cette chaîne, les clés client restent souvent le point le plus sensible.