Home Blockchain News V4 Hard Fork résout la vulnérabilité du portefeuille Wasabi

V4 Hard Fork résout la vulnérabilité du portefeuille Wasabi

0
V4 Hard Fork résout la vulnérabilité du portefeuille Wasabi

Le 10 mai, Ondřej Vejpustek de TREZOR a envoyé un message crypté PGP à Wasabi. Le message contenait une explication perspicace sur une possible vulnérabilité de déni de service Conjoin dans le cadre de la politique de divulgation de sécurité de Wasabi. Ces attaques ont été conçues pour exploiter le portefeuille de confidentialité Wasabi Bitcoin pour voler des pièces.

Un attaquant aurait pu exploiter la vulnérabilité pour mener une attaque DoS (déni de service) avant la v4 Hard Fork. Dans ce scénario, il était difficile d’identifier la source de l’attaque. Grâce à DoS, le hacker arrêterait tout le processus CoinJoin pour tous les autres participants et les rondes Wasabi ne fonctionneraient plus.

Puisqu’il n’y a pas de tentative de DoS à ce jour, on suppose qu’aucun utilisateur Wasabi n’a été affecté par la vulnérabilité. Il est important de noter que l’attaquant ne pouvait ni voler les fonds des utilisateurs ni désanonymiser qui que ce soit. Ce qu’ils pouvaient faire, cependant, était d’empêcher l’achèvement du processus CoinJoin.

Les utilisateurs qui ont déjà téléchargé Wasabi Wallet v1.1.12 sorti le 5 août 2020 peuvent profiter pleinement de la v4 Hard Fork. Le Hard Fork a corrigé cette vulnérabilité et aucune action de l’utilisateur n’est donc nécessaire. Pour tous ceux qui n’ont pas encore mis à niveau leur Wasabi vers la version v1.1.12, ils sont encouragés à le faire car le Hard Fork rompt la compatibilité avec les logiciels plus anciens.

Signatures Blind Schnorr

Au début de chaque tour, une nouvelle paire de clés de signature Schnorr aveugle est générée pour chaque niveau de ronde. Lors de la phase d’enregistrement des entrées, un participant au CoinJoin enregistre toutes les sorties non dépensées en sa possession en tant qu’entrées de la transaction coinjoin. Il enregistre également une ou même plusieurs adresses masquées en tant que sorties de la transaction de coinjoin.

Le coordinateur détermine le nombre de niveaux auxquels le participant peut participer pendant la phase de confirmation de connexion. Ils renvoient ensuite le participant au nombre correspondant d’adresses masquées qui sont signées avec les touches de niveau correspondantes. En ce qui concerne la phase d’enregistrement de sortie, le participant utilisant une identité différente révèle ses sorties non mélangées avec les signatures non mélangées qui sont validées par le coordinateur.

Chaque signature utilise un nonce fraîchement généré pour les signatures Schnorr aveugles. Dans le cas où un signataire génère deux signatures en utilisant un nonce, il est facile de déterminer sa clé privée comme étant la même que la partie privée du nonce particulier.

Le problème se pose que le nonce dans la phase de mise en œuvre fait partie de la paire de clés. En conséquence, le nonce est le même pour toutes les sorties enregistrées au même niveau. Ainsi, un participant qui enregistre deux sorties ou plus au même niveau peut déterminer la clé privée du signataire.

Fonctionnement des attaquants avant la mise à niveau de Hard Fork v4

Tout attaquant qui connaît la clé privée du signataire peut facilement générer une signature valide pour chaque message. Par conséquent, ils peuvent enregistrer une sortie qui n’a jamais été signée en aveugle par le coordinateur. Que se passe-t-il ensuite? À condition que la mise en œuvre du client soit correcte et solide, les attaquants ne peuvent pas voler beaucoup de pièces et ils ne peuvent pas non plus désanonymiser qui que ce soit.

L’attaquant peut simplement empêcher l’achèvement de la coinjoin entraînant une attaque par déni de service. L’attaquant commence par enregistrer ses sorties réelles et fausses dans la phase d’enregistrement des sorties. Finalement, il est interdit à plusieurs participants d’enregistrer leurs sorties car la phase d’enregistrement de sortie se termine lorsque les sorties enregistrées égalent les signatures aveugles renvoyées dans la phase de confirmation de connexion.

Ces participants refusent normalement de signer la transaction conjointe. En fin de compte, leur sortie non dépensée qui est enregistrée comme entrée dans le coinjoin est interdite. L’attaquant enregistre l’une de ses sorties réelles. En dehors de cela, ils enregistrent une fausse sortie à un niveau supérieur. Puisqu’ils ont enregistré des sorties égales au nombre de signatures aveugles qu’ils ont obtenues, les autres participants pourraient enregistrer leurs sorties.

Si cela se produit, le coordinateur crée une transaction qui n’est pas valide car la somme de toutes les entrées est inférieure à la somme de toutes les sorties.

Corrections possibles pour le bogue

Le coordinateur génère une paire nonce sur demande, se souvient à la fois de la partie publique et de la partie privée, puis renvoie la partie publique. Tout participant qui enregistre ses sorties non dépensées et ses adresses masquées utilise ce nonce pour masquer les adresses et envoie le nonce dans sa requête. Ensuite, le coordinateur obtient le nonce privé correspondant, signe les adresses en aveugle et oublie la paire nonce. Par conséquent, il n’est pas utilisé à plusieurs reprises.

Les utilisateurs peuvent également remplacer les signatures aveugles Schnorr par des signatures aveugles RSA. Cela peut fonctionner car la signature RSA n’a pas besoin de nonce. Mais cette approche n’est pas populaire car RSA, contrairement à la cryptographie à courbe elliptique, n’est pas assez répandue dans la communauté Bitcoin.

Merci pour votre subscription! Veuillez vérifier votre courrier électronique pour obtenir des instructions supplémentaires.

NO COMMENTS

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Exit mobile version