Vultisig corrige une faille ECDSA permettant la récupération de la clé privée

ChainSecurity a divulgué le 21 octobre une faille historique dans l’implémentation de signature ECDSA du portefeuille crypto Vultisig, qui permettait la récupération d’une clé privée complète. L’exploitation de cette vulnérabilité nécessitait un signataire compromis et la transmission de plusieurs messages de signature malveillants afin d’exploiter un signal d’arrêt mal géré dans le code de l’application.

Exploitation par un signataire malveillant

Vultisig fonctionne comme un portefeuille à calcul multi-parties (MPC), distribuant l’autorité de signature parmi des parts de clé afin qu’un nombre suffisant de parts puisse coopérer pour produire une signature blockchain standard sans assembler la clé privée complète lors du fonctionnement normal. Dans une configuration à deux appareils, la compromission d’un participant devrait laisser l’attaquant dépendre de l’approbation de l’autre appareil. Cependant, la faille divulguée permettait à un attaquant ayant déjà compromis un signataire d’envoyer de nombreux messages de signature malveillants et d’observer si l’autre signataire renvoyait une erreur.

Selon ChainSecurity, ces réponses d’erreur révélaient des bits d’une graine de protocole interne réutilisable. Cette graine est un secret de configuration interne. La bibliothèque sous-jacente supposait que la signature supplémentaire s’arrêterait après une erreur critique jusqu’à ce que la graine soit renouvelée. L’application Vultisig, en revanche, affichait un message d’erreur générique et n’appliquait pas la réponse d’arrêt de la bibliothèque. En continuant l’échange, l’attaquant pouvait éventuellement récupérer l’autre part et la clé privée complète. Cela signifiait qu’une tentative de signature échouée pouvait compromettre le portefeuille même si elle ne produisait pas de signature de transaction utilisable, car le simple rejet de la transaction ne préservait pas la séparation entre les signataires.

Mises à jour du code en août

Les mainteneurs Android et iOS ont fusionné des modifications de code le 21 août, deux mois avant la divulgation publique par ChainSecurity. Ces modifications ont traité le problème où l’ancien code 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. Auparavant, les routines de signature pouvaient réessayer jusqu’à trois fois tandis que l’utilisateur ne recevait qu’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, spécifiquement les codes 100 à 109, lors de la configuration de la session, du traitement des messages et de l’achèvement de la signature. Les mises à jour Android et iOS associent le participant signalé à un identifiant d’appareil et transmettent une erreur dédiée au-delà des réessais automatiques. Les applications affichent désormais un avertissement localisé contre l’utilisation à nouveau de l’appareil signalé. Sur Android, l’exception contourne également la récupération par relais. Ces modifications permettent aux applications de distinguer un verdict cryptographique sur un participant d’un échec de signature ordinaire.

La version iOS v1.45.71, datée du 21 août, liste la modification n°5235. La version Android v1.0.118, datée du 25 août, liste la modification n°5658. Les descriptions de coffre-fort de Vultisig distinguent entre le Fast Vault, qui utilise un appareil utilisateur avec VultiServer détenant la deuxième part, et le Secure Vault, qui utilise deux ou plusieurs appareils détenus par l’utilisateur sans VultiServer. La divulgation examinée et les documents de l’application ne fournissent pas une matrice complète des versions et configurations de coffre-fort affectées.

Portée de l’audit et vérification

La documentation de sécurité de Vultisig indique que Trail of Bits a audité la bibliothèque DKLS23 de Silence Laboratories en 2024. La documentation 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. Par conséquent, les correctifs restaient hors du périmètre de l’évaluation de ChainSecurity. Les modifications publiées laissent la protection entre les sessions redémarrées non vérifiée, car l’application de la condition d’arrêt de la bibliothèque tout au long de la signature, y compris après les redémarrages initiés par l’utilisateur, n’a pas été pleinement établie.