Le grand frère des monnaies privées en difficulté ? La faille de falsification surprise de Zcash

Auteur : David Christopher ; Traduction : Blockchain en langage clair

Cet article porte sur la dernière faille Orchard révélée dans Zcash : bien que le problème ait déjà été corrigé, ce qui est plus problématique, c’est que la vulnérabilité pourrait permettre à un attaquant de forger des ZEC dans la pool privée, et la conception même de la confidentialité empêche de prouver si de la fausse monnaie a réellement été créée auparavant. Par conséquent, le point central n’est plus simplement de “corriger une faille”, mais de “reconstruire la confiance en réévaluant la méthode de vérification du système”.

Trois points méritent une attention particulière : premièrement, le marché n’acceptera pas simplement l’hypothèse que “la probabilité d’exploitation est très faible” ; deuxièmement, Zcash pourrait devoir migrer vers une nouvelle pool pour simuler une “nettoyage” ; troisièmement, la vérification formelle devient une infrastructure fondamentale de tous les protocoles, plutôt qu’un simple atout supplémentaire. Pour un projet mettant en avant la cryptographie complexe et la conception de la confidentialité, ce sont là des avertissements très concrets.

Zcash n’a pas passé une bonne semaine.

Le 29 mai, le chercheur en sécurité Taylor Hornby, utilisant Opus 4.8 pour étudier le protocole pour le compte de Shielded Labs, une organisation indépendante de support à Zcash, a découvert une faille grave dans Orchard — la dernière et la plus grande pool de Zcash. Il a ensuite divulgué le problème en privé au laboratoire de développement ouvert Zcash (ZODL), en tant que membre de l’équipe centrale du protocole, qui a confirmé le problème en quelques heures et commencé à coordonner une réponse.

Étant donné que divulguer trop de détails pourrait revenir à donner directement la feuille de route d’une attaque potentielle, la correction a été menée par étapes :

2 juin : Une mise à jour de sécurité en soft fork a annulé les transactions Orchard.

3 juin : Le hard fork NU6.2 a réactivé la pool et déployé le circuit modifié — une sorte de “manuel de règles” pour définir ce qu’est une transaction valide.

Apparence d’un récit déjà résolu : une faille grave découverte, corrigée, sans exploitation connue dans l’intervalle.

Mais, après une rétrospective complète publiée hier, la nature de l’incident a été totalement réécrite.

Il apparaît que c’est en réalité une “faille de falsification” , qui pourrait théoriquement permettre à un attaquant de créer à l’infini de faux ZEC dans Orchard ; pire encore, il n’existe actuellement aucun moyen de vérifier si cette faille a été exploitée avant sa correction.

Bien que l’équipe concernée pense toujours que “la probabilité d’exploitation est faible”, dans ce nouveau contexte, l’histoire n’est plus simplement “Zcash a corrigé un bug”, mais plutôt “Zcash a corrigé un bug qui pourrait permettre de fabriquer de faux ZEC dans Orchard, et le système ne peut pas encore prouver que cela n’a jamais été le cas”.

Qu’est-ce qu’Orchard, où se situe le problème ? Orchard est la dernière pool de Zcash, une couche de confidentialité dissimulant les montants, expéditeurs et destinataires.

Comme d’autres systèmes de confidentialité, il repose sur des preuves à divulgation zéro. Les utilisateurs peuvent prouver qu’ils respectent les règles du système sans révéler de détails spécifiques ; ces règles sont codées dans des circuits.

Ce vulnérable existe depuis le lancement d’Orchard en mai 2022, et pourrait théoriquement permettre à quelqu’un de falsifier des ZEC dans Orchard, en faisant croire au réseau que ses actifs sont réels. Étant donné qu’Orchard masque les montants et les factures, ces unités falsifiées pourraient rester dans la pool indéfiniment, sans laisser de trace sur la chaîne publique.

Actuellement, du moins pour l’instant, puisque Orchard est transparent, il est impossible d’auditer directement son historique ou de conclure que : avant la correction, aucune fausse ZEC n’a été créée.

L’équipe estime que “la probabilité qu’elle ait été exploitée est faible”, ce qui n’est pas sans fondement : la faille est profonde, facile à découvrir, et nécessite une expertise avancée pour l’exploiter.

Mais ce que le marché valorise, ce n’est pas une “probabilité” mais une “preuve vérifiable”. Avant que Zcash ne confirme qu’aucune fausse ZEC n’a été créée, le protocole demande en réalité aux utilisateurs de croire en quelque chose qu’il ne peut pas encore prouver.

Que va-t-il se passer ensuite ? Zcash doit trouver une méthode pour soit prouver qu’il n’y a pas de copies excessives de ZEC dans Orchard, soit forcer le système à un état où les faux ZEC ne peuvent plus se dissimuler.

La correction probable viendra de deux directions : premièrement, auditer les subventions ; deuxièmement, rendre ces vulnérabilités plus difficiles à manquer à l’avenir.

Concernant l’audit, le fondateur de Zcash, Zooko Wilcox, suggère de migrer l’approvisionnement en pool vers une nouvelle pool Orchard. La clé est le “rotation d’audit” : un pool ne doit pas dépasser une certaine limite de valeur, correspondant à la valeur légitime qui y a été injectée.

En forçant tout le fonds dans Orchard à passer par cette “rotation”, la valeur formatée en ZEC sera forcément confrontée à un mur : toute tentative de dépasser cette limite sera inférieure à la valeur réelle qui a été légitimement injectée dans la pool. Des détails supplémentaires sur cette approche seront probablement fournis la semaine prochaine.

Quant à la seconde voie, Josh Swihart de ZODL évoque la “vérification formelle”. En termes simples, il s’agit d’écrire les règles du système sous une forme que la machine peut vérifier, puis de prouver que le circuit respecte ces règles.

Cela ne remplace pas la judgement humaine, mais cela permet de faire passer la question cruciale de “faire confiance à l’auditeur pour tout avoir compris” à “prouver directement que les contraintes clés existent”.

Zcash dispose actuellement de deux pistes pour corriger la situation. La première, est de développer une nouvelle version d’Orchard, validée par vérification formelle, comme solution transitoire ; elle pourrait viser la fenêtre de mise à jour NU7 fin juillet, mais n’a pas encore été officiellement décidée.

Une réponse plus longue et plus claire, c’est Tachyon. Il s’agit du nouveau protocole de confidentialité que Zcash conçoit, avec une architecture plus simple, basé sur la vérification formelle.

L’objectif est clair : réduire la complexité de Orchard, qui est très manuelle et difficile à raisonner complètement, afin que les circuits puissent être soumis à des vérifications plus strictes. Avant que la physique des particules superluminales ne devienne réalité, un Orchard vérifié pourrait servir de pont intermédiaire.

Bienvenue dans une nouvelle étape : l’intelligence artificielle commence à aider l’humain à découvrir des vulnérabilités potentielles dans les protocoles.

L’article mentionne aussi que des chercheurs ont déjà commencé à explorer comment cette problématique pourrait être détectée par des méthodes de détection assistée par IA. Quoi qu’il en soit, cet incident rappelle une fois de plus que : les hypothèses de sécurité des protocoles futurs sont en train d’être réécrites par des capacités de recherche automatisée de plus en plus avancées.

En attendant des mises à jour sur la question de savoir si du ZEC a réellement été injecté dans Orchard, la leçon la plus importante pourrait être : les projets que vous détenez, ont-ils une relation étroite et de haute qualité avec des chercheurs en sécurité et des ingénieurs ?

Comme l’indique la citation de Tayvano dans l’article, la raison pour laquelle Zcash pourrait avoir évité une exploitation avant la découverte de cette faille, c’est peut-être parce qu’il entretenait une relation de confiance avec ses intervenants. Vous priez, mais ce qui compte le plus, c’est la vérification du processus lui-même.

Cela peut sembler une répétition, mais il vaut encore une fois de souligner : nous entrons dans un nouveau paradigme, capable de briser la sécurité des protocoles valant des milliards de dollars.