Zilliqa a révélé qu'un bug dans la manière dont son application Ledger pour portefeuille matériel signait les transactions a exposé au moins 6 772 comptes d'utilisateurs et permis le vol de 683 millions de ZIL, le jeton natif du réseau. Le projet de blockchain a présenté les détails dans un post-mortem, décrivant une faille liée à la façon dont l'application gérait les données secrètes qui protègent les clés privées. Zilliqa est elle-même une blockchain publique mise en service début 2019, ayant fait du sharding — la répartition de la charge de transactions entre des groupes de nœuds parallèles — sa caractéristique de conception centrale, le ZIL servant à payer les frais de transaction sur le réseau.

Selon le post-mortem, un bug de signature dans l'application Ledger de Zilliqa a laissé un minimum de 6 772 comptes exposés. Un bug de signature signifie que l'application de portefeuille a mal géré le processus d'approbation des transactions — l'étape conçue pour garantir la sécurité des fonds des utilisateurs. La faille se situait dans l'application développée par Zilliqa qui fonctionne sur les appareils de Ledger, et non dans le matériel de Ledger lui-même : les portefeuilles Ledger fonctionnent via des applications distinctes, propres à chaque blockchain et fournies par chaque projet, ce qui place le code du projet concerné dans le chemin de signature.

Zilliqa présente le chiffre de 6 772 comme un minimum, et non comme un total final confirmé de l'ensemble des personnes affectées. Selon le projet, cette même faille a permis le vol de 683 millions de ZIL.

Le reportage de CryptoSlate a attribué le problème au rejet de l'entropie par l'application de portefeuille matériel. L'entropie désigne l'aléa utilisé pour générer une clé privée ; en quantité insuffisante, les clés deviennent devinables, ce qui peut exposer les cryptoactifs qu'elles protègent.

Pourquoi le nombre de comptes et la perte de jetons comptent

Le chiffre de 6 772 constitue un plancher mesurable du nombre d'utilisateurs impliqués dans l'incident. Comme Zilliqa le présente comme un minimum, le nombre réel de comptes touchés pourrait être plus élevé. Les jetons volés illustrent le poids financier du bug : une faille de signature se situe dans la couche de confiance de tout portefeuille, et une défaillance à ce niveau menace directement les fonds des utilisateurs ainsi que la confiance dans le ZIL.

Le bug était suffisamment grave pour que Zilliqa suspende les transactions natives sur le réseau, selon The Block, qui a rapporté que la faille remontait au code de 2019 de l'application Ledger — un code écrit l'année même du lancement du réseau, ce qui signifie que le chemin de signature vulnérable datait de la première année d'exploitation de Zilliqa.

Ce que les utilisateurs de Zilliqa doivent retenir

Les utilisateurs qui détenaient du ZIL via un appareil Ledger pourraient compter parmi les comptes exposés. L'incident rappelle que même les portefeuilles matériels, largement considérés comme l'option la plus sûre, peuvent comporter des failles au niveau applicatif.

Ce n'est pas la première fois que la signature fait l'objet d'un examen dans l'écosystème Ledger. Ledger avait précédemment corrigé un problème distinct en réparant une vulnérabilité de signature Ethereum, soulignant à quel point l'étape d'approbation continue de se révéler un point faible. Ce schéma fait écho à d'autres projets ayant suspendu leurs opérations après un problème au niveau du code, à l'image de TAC, qui a interrompu la production de blocs en raison d'une exploitation de l'offre de jetons. L'arrêt du réseau permet de gagner du temps, mais il indique aussi à quel point la faille sous-jacente est profonde.

Pour les détenteurs ordinaires, le point pratique est simple : suivre les canaux officiels de Zilliqa pour obtenir des orientations et vérifier si un compte entre dans le cadre de l'exposition divulguée avant de déplacer des fonds. Deux questions restent ouvertes derrière ce conseil — le chiffre de 6 772 sera-t-il révisé à la hausse ultérieurement, et quelles mesures de remédiation, le cas échéant, le projet prescrit-il pour les clés générées via l'application défaillante.