Une « fuite de signature normale » a exposé une clé privée : l’incident des 16 millions d’ADA m’a fait redécouvrir SecureKey

Les phrases mnémoniques n’ont pas été envoyées à des pirates, et il n’est pas nécessaire non plus que les utilisateurs cliquent par erreur sur « autorisation illimitée ». Il suffit qu’une transaction soit signée « normalement » : l’attaquant peut alors reconstituer la clé privée à partir des données publiques de la blockchain

Une alerte officielle de sécurité de SecondFi indique que, en juin, trois attaques externes ont touché 374 adresses Cardano, entraînant le vol d’environ 16 millions d’ADA, soit environ 2,4 millions de dollars US selon les chiffres communiqués à l’époque.

L’équipe a également, via des mesures d’intervention d’urgence, protégé environ 129 millions d’ADA ; ces actifs faisaient partie des fonds protégés, et il ne faut pas les décrire comme « 129 millions d’ADA dérobés par des pirates ».

La cause profonde réside dans un défaut de dérivation déterministe du nonce au niveau du signataire logiciel concerné. À chaque fois qu’une adresse affectée signe une transaction, la signature divulgue suffisamment d’informations mathématiques pour que l’attaquant puisse reconstruire la clé privée de cette adresse en s’appuyant sur les données publiques de la blockchain.

Le risque se situant au niveau des adresses et des clés, SecondFi rappelle tout particulièrement : importer la même phrase mnémonique dans une autre application de portefeuille ne fait que regénérer les mêmes clés et la même adresse, sans supprimer l’exposition.

À ce jour, aucun lien direct avec GRVT, Ethereum ou Privy n’a été publiquement prouvé ; on ne peut donc pas laisser entendre que @grvt_io utilisait du code similaire. Mais cette affaire révèle un problème crucial pour tous les systèmes de self-custody :

D’après les explications officielles de GRVT, SecureKey est un identifiant Web3 de l’utilisateur ; il s’agit essentiellement d’un couple clé publique/clé privée d’Ethereum. L’e-mail, le mot de passe ou l’OAuth servent principalement à l’accès au compte et aux fonctions qui ne sont pas liées aux transactions. Toute opération susceptible de modifier l’attribution des actifs nécessite une signature SecureKey.

La documentation la plus récente de GRVT sur la self-custody révèle aussi que les clés des portefeuilles Privy (liées à l’e-mail) sont générées dans un environnement matériel isolé, puis réparties via un partage secret de Shamir : ni GRVT ni Privy ne détiennent, à eux seuls, la clé complète.

Cela résout les problèmes de génération, de stockage et de contrôle unilatéral des clés ; ce n’est pas une garantie absolue couvrant tous les algorithmes de signature, une intrusion d’appareil ou une erreur de l’utilisateur.

L’incident SecondFi m’a aussi fait mieux comprendre l’usage de Secondary SecureKey : la clé de secours n’est vraiment une « clé de secours » que si la génération, l’équipement et les matériaux de récupération sont indépendants : « génération indépendante, équipement indépendant, matériaux de récupération indépendants ».

La leçon la plus dure de l’incident des 16 millions d’ADA est la suivante : une signature « valide » sur le plan cryptographique peut aussi divulguer des indices nécessaires à la création de la signature falsifiée de la transaction suivante.

#grvt #SelfCustody #WalletSecurity #CardanoSecurity