Au lieu de conserver vos bitcoins avec un seul jeu de clés, vous pouvez aussi les conserver avec plusieurs jeux de clés. C'est ce qu'on appelle la multisignature, ou multisig en abrégé, qui exige plusieurs signatures pour autoriser une transaction Bitcoin. Vous pouvez définir à la fois le nombre total de clés et le seuil requis pour dépenser les coins. Si vous choisissez un seuil supérieur à un, un attaquant qui découvre l'une des clés ne peut toujours pas voler vos fonds. C'est pourquoi beaucoup de personnes du secteur recommandent que tout le monde utilise le multisig pour sécuriser ses coins. Cependant, cet article explique pourquoi la complexité accrue du multisig par rapport au singlesig comporte ses propres pièges. Il inclut également des divulgations responsables que nous avons faites à SatoshiLabs (qui produit Trezor) et à Ledger à ce sujet, et que nous n'avions encore jamais publiées.

Pourquoi enquêtons-nous sur nos concurrents ?

Lors de l'implémentation d'une prise en charge expérimentale du multisig dans la BitBoxApp, j'ai signalé à mon collègue benma que l'écran d'adresse de réception de son Trezor n'est pas fiable en cas de multisig (voir plus bas pour plus de détails). Après avoir compris plus tôt cette année à quel point il est important de traiter les adresses de change de la même manière que les adresses de réception, nous sommes devenus plus curieux de voir comment les autres portefeuilles matériels gèrent le multisig. Nous avons lancé la BitBox02 à la fin du mois de septembre et avons enfin eu le temps d'examiner les implémentations d'autres portefeuilles matériels, aussi pour évaluer l'effort nécessaire afin d'ajouter correctement le multisig nous-mêmes. Nous avons découvert plusieurs problèmes, qui ont donné lieu à des divulgations responsables auprès de Trezor, Coldcard et Ledger (comme expliqué ici).

Pourquoi devrais-je utiliser un portefeuille matériel ?

J'en parle plus en détail dans un billet de blog précédent, mais en bref, un portefeuille matériel doit vous permettre de recevoir et de dépenser des fonds en toute sécurité, ainsi que de recevoir en toute sécurité la monnaie rendue sur le même compte, même si votre ordinateur ou votre téléphone mobile est infecté par un malware. Bien que chaque fabricant puisse définir ce contre quoi son produit vous protège ou non, nous estimons que le modèle de menace des portefeuilles matériels devrait inclure des cosignataires malveillants ou compromis dans un contexte multisig. La raison est que des entreprises souhaitent utiliser le multisig dans le cadre de services de conservation de coins, de limitation de débit ou d'héritage. Si leur infrastructure est compromise, de nombreux utilisateurs pourraient être touchés, surtout s'ils utilisent l'application du fournisseur de services pour interagir avec leur portefeuille matériel.

Quelle est la motivation pour utiliser le multisig ?

Il existe deux principaux cas d'usage du multisig : (i) partager l'autorité de dépense des coins entre plusieurs parties sans point unique de défaillance ou (ii) réduire l'impact des vulnérabilités en utilisant des portefeuilles matériels de fabricants différents. Dans les deux scénarios, vous devez faire attention à certains points. Sinon, vous pourriez finir avec moins de sécurité que si vous utilisiez un singlesig classique. Le multisig ajoute de la complexité pour le portefeuille matériel, le portefeuille logiciel et pour vous, mais « la complexité est l'ennemie de la sécurité ». En outre, comme le singlesig est bien plus populaire que le multisig, les entreprises accordent davantage d'attention à la sécurité et à l'ergonomie de leur flux singlesig qu'à leur implémentation multisig. Même si je suis d'accord pour dire que le multisig est plus sûr en théorie, les sections suivantes expliquent pourquoi ce n'est parfois pas le cas en pratique.

Comment sauvegarder la configuration multisig en toute sécurité ?

Le premier piège survient avant même de commencer à recevoir ou dépenser de l'argent. Supposons que vous créiez, par exemple, une configuration 2 sur 3, où le seuil est inférieur au nombre de cosignataires. En d'autres termes, 2 signatures sur 3 possibles sont nécessaires pour approuver une transaction. Il est absolument crucial que la sauvegarde de chaque cosignataire inclue les clés publiques étendues (xpubs, en abrégé) de tous les autres cosignataires (au keypath du compte multisig et, idéalement, avec le seuil utilisé, le chemin de dérivation et le type de script). Sinon, la perte d'une seule seed signifie que vous ne pourrez plus récupérer et dépenser les fonds. En effet, les sorties de transaction non dépensées des comptes multisig sont verrouillées avec le hash de toutes les clés publiques (et du seuil). Techniquement, si vous ne pouvez plus dériver les clés publiques de tous les cosignataires, vous ne pouvez plus déterminer les redeem scripts nécessaires pour trouver et dépenser les UTXOs de votre compte multisig. Par exemple, si vous configurez un compte multisig 2 sur 3 mais oubliez aussi de sauvegarder les clés publiques étendues des deux autres cosignataires, alors deux signatures sur trois suffisent pour dépenser et recevoir des fonds tant que les portefeuilles (matériels) individuels fonctionnent. En revanche, si vous perdez tous l'accès à vos portefeuilles pour une raison quelconque, vous aurez besoin des trois sauvegardes de seed pour la récupération, et non de seulement deux.

Comment recevoir des coins en toute sécurité avec le multisig ?

Votre portefeuille matériel doit vérifier, ou vous permettre de vérifier, les informations suivantes fournies par l'ordinateur non fiable :

  • L'adresse de réception, qui doit encoder le hash d'un redeem script multisig ordinaire sans autre condition de dépense
  • La clé du portefeuille matériel, qui doit être l'une des clés publiques du redeem script
  • Le keypath de l'adresse affichée afin d'éviter les attaques de rançon si le portefeuille matériel n'applique aucune restriction
  • Le nombre de cosignataires afin d'empêcher un attaquant d'en ajouter
  • Le seuil de signatures requises, qui ne doit pas être plus élevé ou plus bas que prévu
  • Les xpubs des cosignataires afin d'empêcher un attaquant de les remplacer

Afin d'éviter un point unique de défaillance humaine lors de l'utilisation d'une adresse de réception, le même seuil de cosignataires devrait confirmer à l'expéditeur que l'adresse de réception a été transmise correctement. Si vous utilisez une configuration multisig afin d'éviter le risque d'une vulnérabilité dans le firmware d'un appareil particulier, vous devez vérifier l'adresse de réception sur plusieurs portefeuilles matériels. Recevoir des coins en toute sécurité est tout aussi important que les dépenser en toute sécurité.

Alors, comment les différents portefeuilles matériels gèrent-ils cela ?

Comme d'autres l'ont déjà remarqué, Ledger ne gère pas cela. Au contraire, l'utilisateur doit faire confiance à l'adresse de réception affichée sur l'ordinateur, ce qui va à l'encontre de l'objectif d'un portefeuille matériel.

Trezor vérifie que sa clé fait partie de l'adresse de réception correctement formée et affiche à l'utilisateur toutes les autres informations (voir une nouvelle fois le tweet ci-dessus sur Ledger) sauf les cosignataires. Par souci de simplicité, les fabricants cherchent à garder le firmware des portefeuilles matériels aussi sans état que possible et cherchent donc à éviter de stocker autre chose que la seed. Jusqu'à la publication de la version 2.1.8 du firmware, le 6 novembre 2019, l'utilisateur n'avait aucun moyen de vérifier les xpubs des cosignataires fournis par l'ordinateur. Autrement dit, un malware pouvait remplacer les xpubs des deux cosignataires dans notre exemple multisig 2 sur 3 ci-dessus, et l'attaquant contrôlerait alors entièrement les coins reçus. Il s'agit d'un vrai problème, car on apprend aux utilisateurs à faire confiance à l'écran de leur portefeuille matériel, mais on ne les informe pas du risque de remplacement ci-dessus, qui rend l'écran de l'appareil non fiable en cas de multisig. C'est la deuxième vulnérabilité que nous avons signalée à Trezor, et elle est mentionnée dans les release notes. Ils ont considéré qu'il s'agissait davantage d'un problème d'ergonomie que de sécurité. (Tant que vous vérifiez l'adresse de réception sur plusieurs appareils qui confirment chacun que leur clé est incluse dans l'adresse multisig, ce ne serait en effet pas un problème de sécurité.) Bien que le nouveau firmware ne conserve toujours pas votre configuration multisig, vous pouvez désormais vérifier les xpubs de vos cosignataires lors de l'affichage d'une adresse de réception multisig :

Comment vérifier les xpubs de vos cosignataires multisig sur un Trezor Model T.

De manière peu pratique, autant que nous puissions en juger, le Trezor n'indique pas quel xpub est le vôtre. Comme le portefeuille matériel fournit votre propre xpub, vous n'auriez pas à le vérifier vous-même. En revanche, puisqu'il ne semble pas exister d'autre méthode pour afficher votre propre xpub sur l'écran de confiance de votre Trezor, vous pouvez au moins maintenant indiquer à vos cosignataires, avec davantage de confiance, quel est votre propre xpub.

Coldcard a la meilleure approche en conservant la configuration multisig après une configuration initiale. Cependant, il avait un problème d'assainissement du keypath de dérivation, que nous leur avons signalé de manière responsable.

Comment dépenser des coins en toute sécurité avec le multisig ?

Une fois que vous avez réussi à recevoir des coins en toute sécurité, comment pouvez-vous les dépenser avec confiance ? Le portefeuille matériel doit vérifier, ou vous permettre de vérifier, les informations suivantes fournies par l'ordinateur non fiable :

  • L'adresse du destinataire, affichée et confirmée par l'utilisateur comme en singlesig
  • L'adresse de change, avec les mêmes cosignataires et le même seuil dans un script multisig ordinaire sans autre condition de dépense
  • Le change est envoyé vers une adresse à un keypath que l'utilisateur peut récupérer

Alors, comment les différents portefeuilles matériels gèrent-ils cela ?

En vérifiant la configuration multisig, Coldcard a la meilleure approche. Cependant, en n'appliquant pas suffisamment de restrictions sur le keypath, l'accès au change n'était pas garanti. Nous leur avons signalé de manière responsable ce problème, et il a été corrigé dans le firmware 3.0.2 publié le 1er novembre 2019.

Trezor vérifie que le change retourne au même compte de portefeuille (avec les mêmes cosignataires et le même seuil), mais il y avait une erreur dans sa vérification. Parce que Trezor ne séparait pas correctement les flux singlesig et multisig, un attaquant pouvait (i) ajouter une entrée multisig partagée à une transaction singlesig, puis (ii) envoyer le change vers le même compte multisig et (iii) voler tous les fonds de l'utilisateur depuis celui-ci. Nous avons signalé cette attaque critique à distance le 1er octobre 2019, et elle a été corrigée dans la version 2.1.8 du firmware publiée le 6 novembre 2019. (Voir ce compte rendu de benma pour plus d'informations.) En dehors de cela, leur approche consistant à ne ni conserver ni faire confirmer par l'utilisateur les xpubs des cosignataires fonctionne pour la dépense, car le redeem script avec les clés publiques des cosignataires fait partie du hash en cours de signature. Par conséquent, si un malware sur votre ordinateur ment à propos des xpubs de vos cosignataires lors de la signature d'une transaction, les autres nœuds du réseau Bitcoin rejetteraient la transaction invalide.

Comme Saleem Rashid l'a déjà souligné il y a presque deux ans, Ledger laisse à l'utilisateur le soin de confirmer la sortie de change dans le cas des transactions multisig, ce qui entraîne divers problèmes. Comment les utilisateurs sont-ils censés vérifier l'adresse de change ? S'ils ont besoin pour cela d'un ordinateur séparé et totalement digne de confiance, pourquoi auraient-ils besoin d'un portefeuille matériel en premier lieu ? Si nous supposons que l'utilisateur doit confirmer l'adresse de change avec le cosignataire, cela mène alors aux deux problèmes suivants :

  1. Envoi à plusieurs non clairement distinguable du multisig : Le seul moyen pour les utilisateurs de savoir s'ils signent une transaction multisig plutôt qu'une transaction d'envoi à plusieurs destinataires est qu'ils reçoivent un avertissement sur le keypath de change dans le premier cas, mais pas dans le second. On ne peut pas attendre d'utilisateurs ordinaires qu'ils remarquent la différence, et les utilisateurs multisig ont l'habitude, sur un Ledger, de toujours confirmer quelque chose en plus du destinataire prévu. Par conséquent, un cosignataire compromis peut fournir une adresse de destination qu'il contrôle seul et la faire confirmer par erreur comme adresse de « change » multisig.
  2. Réduction du seuil multisig : Si vous avez une configuration multisig M sur N, vous ne pouvez pas détecter si le seuil multisig de la sortie de change est abaissé à 1 sur N. Si un cosignataire compromis vous ment sur ce qui constitue le change à confirmer, il peut voler le change une fois la transaction terminée. Bien que ces deux problèmes soient résolus si les utilisateurs ont accès à un oracle de change qui leur indique à quoi le change doit ressembler, il existe un autre problème contre lequel les utilisateurs ne peuvent pas se protéger :
  3. Entrées singlesig vers du change multisig : Si l'utilisateur détient également des fonds singlesig sur le même Ledger, un attaquant peut financer une transaction multisig que l'utilisateur souhaite effectuer avec ses UTXOs singlesig au lieu de les prendre sur le compte multisig. Si le compte multisig a une configuration 1 sur N, un cosignataire malveillant ou compromis peut dépenser le change immédiatement après. En d'autres termes, à cause de ce choix de conception, un Ledger ne vérifie pas que le change retourne au même compte, ce qui met en danger vos fonds singlesig (et vos autres fonds multisig).

Veuillez noter que ces attaques nécessitent que l'ordinateur de la victime soit compromis, ce qui est une hypothèse courante du modèle de menace des portefeuilles matériels. Nous avons signalé les trois problèmes à Ledger le 4 novembre 2019. Ils ont répondu que tout cela correspondait au comportement attendu et qu'ils travaillaient sur une nouvelle application Bitcoin qui devrait résoudre ces problèmes (voir ce commentaire sur Reddit pour plus d'informations). Si vous utilisez votre Ledger à la fois pour le singlesig et le multisig et que vous ne confieriez pas vos fonds singlesig à vos cosignataires, nous vous recommandons de déplacer d'abord vos fonds singlesig vers un autre portefeuille avant de signer de nouvelles transactions multisig. En outre, nous recommandons d'utiliser un seul appareil Trezor ou Ledger pour au plus une configuration multisig, car vous ne pouvez pas savoir depuis quel compte vous dépensez puisque le compte n'est pas affiché.

Un enregistrement du flux multisig sur un Ledger Nano X.

Qu'est-ce que toutes ces attaques ont en commun ?

La source de toutes les vulnérabilités mentionnées ici est que les portefeuilles matériels essaient soit d'être intelligents et d'afficher le moins possible (Trezor et Coldcard), soit d'être simples et d'afficher davantage (Ledger), mais les deux approches ont échoué, autrement dit, ils n'ont ni suffisamment vérifié ni suffisamment affiché. Trouver le bon équilibre entre les deux, avec la bonne quantité de vérification silencieuse et de confirmation par l'utilisateur, n'est pas facile. En outre, il me semble que cette famille d'attaques « change the change » mérite une attention plus soutenue. Toutes les attaques mentionnées dans cet article étaient (ou sont toujours) des attaques à distance, où un ordinateur compromis peut simplement détourner l'API du portefeuille matériel. Pour des idées sur ce que les portefeuilles matériels pourraient faire pour atténuer de telles attaques et donc améliorer leur sécurité, consultez l'article de benma. Et bien que cet article se concentre sur les portefeuilles matériels, il est important de noter qu'avec l'utilisation du multisig, les portefeuilles logiciels sont eux aussi vulnérables aux attaques par abus d'API, puisque des transactions peuvent leur être transmises de manière similaire aux portefeuilles matériels.

Remerciements

Les remerciements vont à TheCharlatan pour avoir compris qu'il était possible d'envoyer des fonds singlesig vers du change multisig avec un Ledger, et à benma pour avoir remis en question l'hypothèse selon laquelle les cosignataires sont dignes de confiance, tandis que j'ai affiné les attaques ci-dessus et les ai signalées à Ledger. TheCharlatan s'est également chargé de les reproduire avec des modifications apportées au portefeuille Electrum et à HWI. Cela conclut notre trilogie de divulgation de vulnérabilités.

Vous n'avez pas encore de BitBox ?

Garder vos cryptos en sécurité n'a pas besoin d'être compliqué. Le portefeuille matériel BitBox02 stocke hors ligne les clés privées de vos cryptomonnaies. Vous pouvez ainsi gérer vos coins en toute sécurité.

La BitBox02 existe aussi en version Bitcoin-only, avec un firmware résolument ciblé : moins de code signifie moins de surface d'attaque, ce qui améliore encore votre sécurité lorsque vous stockez uniquement du Bitcoin.

Procurez-vous-en une dans notre boutique !

Foire aux questions (FAQ)

Qu'est-ce que la multisignature ou multisig ? La multisignature (multisig) exige plusieurs signatures pour autoriser une transaction Bitcoin, ce qui permet de détenir des bitcoins avec plusieurs jeux de clés.

Pourquoi le multisig est-il recommandé ? Le multisig renforce la sécurité en exigeant plusieurs clés pour autoriser une transaction, ce qui complique le vol de fonds par un attaquant qui ne disposerait que d'une seule clé.

Quels sont les principaux cas d'usage du multisig ? Le multisig sert à partager l'autorité entre plusieurs parties sans point unique de défaillance et à réduire l'impact des vulnérabilités en utilisant différents portefeuilles matériels.

Comment le multisig ajoute-t-il de la complexité ? Le multisig augmente la complexité pour les portefeuilles matériels, les portefeuilles logiciels et les utilisateurs, et il est parfois moins sûr en pratique à cause de cette complexité.

Comment sauvegarder les configurations multisig ? Il est crucial d'inclure les clés publiques étendues (xpubs) de tous les cosignataires dans la sauvegarde de chaque cosignataire afin de pouvoir récupérer et dépenser les fonds.

Shift Crypto est une société privée basée à Zurich, en Suisse. Notre équipe internationale de spécialistes en ingénierie, cryptosécurité et développement Bitcoin Core conçoit les produits BitBox et fournit des services de conseil. La BitBox02, portefeuille matériel de deuxième génération, permet aux particuliers de stocker, protéger et transférer facilement des cryptomonnaies. Sa compagne, la BitBoxApp, offre une solution tout-en-un pour gérer vos actifs numériques en toute sécurité et simplement.

This post was translated with the help of AI