Mises à jour d’août de Vultisig bloquent la fuite de clé privée ECDSA

ChainSecurity a divulgué le 21 octobre une faille historique dans l’implémentation de signature ECDSA du portefeuille crypto Vultisig, permettant la récupération d’une clé privée complète dans des conditions d’attaque spécifiques. La vulnérabilité nécessitait un signataire compromis et la transmission de nombreux messages de signature malveillants pour extraire des bits d’une graine de protocole interne. Vultisig a fusionné des modifications de code sur Android et iOS le 21 août pour corriger le problème, deux mois avant la divulgation publique.

Mécanique de la faille et exposition de la graine

La divulgation détaille comment l’application Vultisig gérait mal un signal d’arrêt critique provenant de la bibliothèque de signature sous-jacente. Dans un portefeuille à calcul multi-parties (MPC), l’autorité de signature est distribuée entre des parts de clé. La bibliothèque suppose qu’après une erreur critique, les tentatives de signature supplémentaires doivent s’arrêter jusqu’à ce que la graine de protocole interne soit régénérée. Cette graine est un secret de configuration ; les réponses aux messages malveillants révélaient des bits de cette graine, ce qui a finalement permis la récupération de l’autre part et de la clé privée complète.

Selon ChainSecurity, l’application affichait précédemment un message d’erreur générique et n’appliquait pas la réponse d’arrêt de la bibliothèque. Cela permettait à l’attaquant de poursuivre l’échange, en observant si l’autre signataire renvoyait une erreur. La conséquence en matière de sécurité est qu’une tentative de signature échouée peut révéler des informations secrètes, même lorsqu’elle ne produit pas une signature de transaction utilisable. Le simple rejet de la transaction ne préservait pas la séparation entre les signataires, car l’application continuait d’interagir avec le participant malveillant.

Modifications de code d’août et notes de version

La modification Android n° 5658 et la modification iOS n° 5235 ont toutes deux été fusionnées le 21 août. Les descriptions de ces modifications indiquent que le code précédent comparait les échecs de signature avec le résultat de succès de la bibliothèque sans traiter séparément les erreurs d’interdiction des parties malveillantes. Les routines de signature anciennes pouvaient réessayer jusqu’à trois fois tandis que l’utilisateur recevait un message d’échec générique.

Le nouveau code reconnaît les codes d’erreur de partie malveillante de la bibliothèque de signature DKLS 100–109 lors de la configuration de la session, du traitement des messages et de l’achèvement de la signature. Les modifications Android et iOS associent le participant signalé à un identifiant d’appareil et transmettent une erreur dédiée au-delà des réessais automatiques. Elles affichent également un avertissement localisé contre l’utilisation à nouveau de l’appareil signalé. Sur Android, l’exception contourne également la récupération par relais.

Les notes GitHub pour iOS v1.45.71, datées du 21 août, listent la PR n° 5235. La version Android v1.0.118, datée du 25 août, liste la PR n° 5658. Ces modifications démontrent que les applications distinguent désormais un verdict cryptographique sur un participant d’un échec de signature ordinaire, empêchant un comportement de réessai qui pourrait être dangereux lorsque la bibliothèque identifie un signataire malveillant.

Portée de l’audit et vérification restante

La documentation de sécurité de Vultisig indique que Trail of Bits a audité la bibliothèque DKLS23 de Silence Laboratories en 2024. Elle note que les rapports d’audit des applications mobiles et de bureau seront liés lorsqu’ils seront publiés. Au moment de la divulgation, ChainSecurity a déclaré n’avoir pas examiné les correctifs de Vultisig ni audité d’autres parties du protocole. Les modifications publiées laissent la protection entre les sessions redémarrées non vérifiée, car les matériaux examinés ne fournissent pas une matrice complète des versions affectées et de la configuration du coffre-fort, ni n’expliquent l’application après les redémarrages initiés par l’utilisateur.