Mises à jour d'août bloquent une fuite critique de clé privée dans le portefeuille crypto Vultisig

Vultisig, un portefeuille crypto qui utilise une signature partagée, a mal géré un signal d'arrêt critique dans son implémentation de signature ECDSA, comme l'ont découvert des chercheurs en sécurité de ChainSecurity.

La divulgation des chercheurs du 21 octobre décrit comment continuer après l'erreur pourrait permettre à un signataire déjà compromis de récupérer la clé privée complète.

Les mainteneurs d'Android et d'iOS ont décrit un code qui a réessayé après que la bibliothèque a identifié un participant malveillant, puis a ajouté un traitement pour arrêter ces réessais et avertir l'utilisateur. Les changements apparaissent dans les notes de version ultérieures du dépôt.

Exiger plusieurs appareils offre une protection uniquement si le logiciel préserve cette exigence lorsque l'un des participants commence à mal se comporter.

Un portefeuille de calcul multipartite (portefeuille MPC) distribue l'autorité de signature entre des parts de clé. Assez de parts coopèrent pour produire une signature blockchain standard sans assembler la clé privée complète pendant le fonctionnement normal.

Dans un arrangement à deux appareils nécessitant la participation des deux, compromettre un appareil devrait laisser l'attaquant dépendre de l'approbation de l'autre appareil.

Le défaut divulgué impliquait la signature ECDSA et nécessitait cette compromission initiale. Un attaquant pourrait alors envoyer de nombreux messages de signature malveillants et observer si l'autre signataire renvoyait une erreur.

Ces réponses révélaient des bits d'une graine de protocole interne réutilisable, permettant finalement de récupérer l'autre part et la clé complète, selon ChainSecurity.

Cette graine est un secret de configuration interne, et la bibliothèque supposait que la signature ultérieure s'arrêterait après l'erreur critique jusqu'à ce que la graine soit renouvelée. L'application affichait une erreur générique et n'imposait pas cette réponse.

Le flux ECDSA historique de Vultisig pourrait fuir des matériaux de clé à travers des réponses d'erreur répétées ; les mises à jour d'août arrêtent désormais les réessais et identifient l'appareil compromis.

La conséquence en matière de sécurité est qu'une tentative de signature échouée peut avoir de l'importance même si elle ne produit pas de signature de transaction utilisable.

Si la poursuite de l'échange révèle plus d'informations secrètes, le simple rejet de la transaction ne préserve pas la séparation promise entre les signataires. L'application doit répondre à l'échec du protocole lui-même.

Ce que les changements d'août démontrent

Le changement Android (#5658) et le changement iOS (#5235) ont tous deux été fusionnés le 21 août, deux mois avant la divulgation publique.

Leurs descriptions indiquent que l'ancien code comparait les échecs de signature avec le résultat de succès de la bibliothèque sans gérer séparément les erreurs d'interdiction de parties malveillantes. Les routines de signature pouvaient réessayer jusqu'à trois fois, tandis que l'utilisateur recevait un message d'échec générique.

Ce compte de réessai n'établit pas combien de messages seraient nécessaires pour récupérer une clé, ou combien de sessions un attaquant aurait besoin.

Les changements de code Android et iOS reconnaissent les codes d'erreur de partie malveillante de la bibliothèque de signature DKLS lors de la configuration de session, du traitement des messages et de l'achèvement de la signature.

Les deux mappent le participant signalé à un identifiant d'appareil, portent une erreur dédiée au-delà des réessais automatiques, et affichent un avertissement localisé contre l'utilisation de cet appareil à nouveau. Sur Android, l'exception contourne également la récupération de relais.

Ensemble, ces changements montrent que les applications distinguent un verdict cryptographique sur un participant d'un échec de signature ordinaire.

Un comportement de réessai approprié pour un échec temporaire peut devenir dangereux lorsque la bibliothèque dit à l'appelant d'arrêter d'interagir avec un signataire malveillant.

Les notes GitHub pour iOS v1.45.71, datées du 21 août, listent #5235. La version Android v1.0.118, datée du 25 août, liste #5658.

Les comptes de portefeuille et la portée de l'audit ont besoin de contexte

Les descriptions de coffre de Vultisig distinguent qui contrôle les signataires. Fast Vault utilise un appareil utilisateur avec VultiServer tenant la seconde part et co-signant. Secure Vault utilise deux appareils ou plus détenus par l'utilisateur sans VultiServer.

Un portefeuille assisté par un fournisseur et un portefeuille réparti sur les propres appareils d'un utilisateur peuvent tous deux utiliser une signature distribuée, mais leurs dépendances opérationnelles diffèrent. Deux participants dans un échange de signature ne signifient pas non plus que le coffre n'a que deux parts au total.

La divulgation examinée et les matériaux d'application ne fournissent pas une matrice complète des versions affectées et des configurations de coffre.

La documentation de sécurité de Vultisig indique que Trail of Bits a audité la bibliothèque DKLS23 de Silence Laboratories en 2024. Elle indique que les rapports d'audit des applications mobiles et de bureau seront liés lorsqu'ils seront publiés.

Lors de la divulgation, ChainSecurity a déclaré qu'il n'avait pas examiné les correctifs de Vultisig ni audité d'autres parties du protocole, donc les correctifs restaient en dehors de cette évaluation.

Des détails de remédiation utiles relieraient les configurations affectées aux versions expédiées et expliqueraient l'application après des redémarrages automatiques et initiés par l'utilisateur. Un examen couvrant ces comportements aborderait l'échec au niveau de l'application décrit ici.

Les détenteurs de protection se voient promettre que l'application impose la condition d'arrêt de la bibliothèque tout au long de la signature, y compris lorsque les utilisateurs recommencent après un échec.