Bitcoin et les blockchains basées sur lui comme Liquid de Blockstream utilisent l’algorithme de signature ECDSA pour vérifier et transférer la propriété des coins stockés dans le système. Cette décision semble avoir été prise en 2008 sur la base des systèmes de signature numérique largement utilisés et non brevetés disponibles à l’époque. ECDSA a cependant de sérieuses limitations techniques. Par exemple, les multisignatures et les signatures de seuil - signatures effectuées par un quorum de parties indépendantes plutôt que par une seule personne - sont très difficiles à produire avec ECDSA.
Les signatures ECDSA ont une structure algébrique complexe qui les rend rigides et difficiles à utiliser. Cela oblige les développeurs à utiliser Bitcoin Script pour des applications telles que les échanges inter-chaînes atomic swap ou Lightning, qui pourraient être implémentées de manière plus compacte et confidentielle avec un schéma de signature plus flexible.
Cependant, bien que les technologies de signatures numériques aient considérablement progressé depuis 2008, les schémas de signature alternatifs décrits dans la littérature négligent de nombreux aspects pratiques pour une utilisation dans le monde réel. Ils supposent, par exemple, que les signataires contrôlent complètement le moment et la manière dont leurs clés sont générées ; qu’ils ont toujours accès à une source de nombres aléatoires parfaite ; et qu’ils ont une mémoire persistante, fiable et sécurisée. En pratique, les utilisateurs de Bitcoin ont souvent un accès restreint à leurs clés, peu de contrôle sur leur mécanisme de génération et aucun contrôle sur la manière dont les tiers externes utilisent les adresses qu’ils génèrent. Pour remédier à cela, nous avons lancé la conception d’un nouveau schéma de signature et réalisé d’importants efforts techniques pour l’implémenter de façon robuste et antifragile.
Introduction
Avec Yannick Seurin, Gregory Maxwell et le cryptographe de Blockstream Pieter Wuille, nous avons publié l’an dernier un nouveau schéma de multisignature appelé MuSig. Ce système multisignature offre une sécurité prouvable, même contre la collusion de sous-ensembles de signataires malveillants, et produit des signatures indiscernables des signatures de Schnorr simples.
Depuis, MuSig, qui n’était au départ qu’un document académique, est devenu un code utilisable. Cette semaine nous avons fusionné ce code dans secp256k1-zkp, un fork de secp256k1, la bibliothèque cryptographique haute sécurité utilisée par Bitcoin Core, que nous avons étendue pour permettre à Elements et Liquid de prendre en charge Confidential Transaction.
Alors que la communauté examine l’utilisation des signatures de Schnorr dans Bitcoin, nous espérons que notre code sera fusionné dans la bibliothèque secp256k1 utilisée par Bitcoin Core et de nombreux autres projets. \ Notre code produit des signatures conformes à BIP-schnorr et peut également générer des adaptor signatures, ce qui pourrait activer Lightning dans scriptless script.
Pourquoi MuSig?
Comme nous l’avons évoqué l’année dernière, la littérature cryptographique contient de nombreux schémas multisignatures déjà existants. Il est donc raisonnable de se demander pourquoi nous devions développer le nôtre. En deux mots, c’est parce que aucun des schémas existants ne répondaient à nos deux exigences suivantes :
- Des signatures courtes de taille constante et non différentiables pour les vérificateurs, quel que soit le groupe de signataires. Dans un système blockchain, l’efficacité de la vérification est primordiale et il est inutile de donner aux vérificateurs plus de détails sur la composition du signataire qu’ils n’en ont besoin pour prévenir les vols. Autre avantage, les signatures MuSig améliorent la confidentialité en masquant l’exacte stratégie de signature.
- Sécurité prouvable dans le modèle à clé publique simple. Cela signifie que les signataires ont toute latitude pour participer à une multisignature à l’aide de paires de clés ordinaires, sans fournir d’informations supplémentaires sur la manière spécifique dont ces clés ont été produites ou sont contrôlées. Il peut être difficile de fournir des informations sur la génération de clés dans le contexte de Bitcoin, car les signataires individuels ont des stratégies de gestion de clés variées et restrictives. De plus, la dépendance à l’égard des détails de génération de clé pourrait poser des problèmes avec Taproot, une proposition d’extension de Bitcoin dans laquelle des clés de signature publiques peuvent contenir une sémantique encodée invisible.
De plus, depuis l’annonce de MuSig, nous avons appris que de nombreux schémas de signature publiés, y compris une version antérieure non publiée de MuSig, sont en réalité peu sûrs ! Nous approfondirons ce sujet dans un prochain article, mais pour l’instant, nous sommes en phase de développement d’un système multisignature adapté à Bitcoin et à Liquid.
Le développement d’API sécurisée et ses écueils
Comme toutes les descriptions mathématiques de protocoles multisignatures, MuSig, tel qu’il a été publié, suppose que les participants ont accès à la mémoire tout au long du processus de signature. Ce processus est persistant, facile à mettre à jour et n’est pas réversible à un état précédent. Cela suppose également que les signataires ont accès à des sources aléatoires impossibles à distinguer. Malheureusement, en pratique, ce n’est pas si simple et nous avons beaucoup travaillé pour concevoir une API utilisable dans une grande variété de scénarios sans que les limitations matérielles ou des situations imprévisibles puissent entraîner la perte d’informations relatives aux clés secrètes.
Les signatures MuSig, tout comme les signatures Schnorr ou ECDSA, utilisent dans leur construction un « nonce » secret qui doit être produit uniformément et aléatoirement. Tout écart d’uniformité, même d’un seul bit, peut entraîner des pertes de clés secrètes et des vols de fonds.
Notre objectif principal était de créer une API résistante aux attaques, et qui n’encourage pas les utilisations risquées, même dans les environnements contraints.
Uniformité aléatoire
Avec les signatures individuelles, l’approche standard pour obtenir des nonces uniformes et aléatoires est simple : prenez quelques données secrètes ainsi que le message à signer, et transmettez-les via une fonction de hachage cryptographique pour obtenir une valeur uniforme et aléatoire qui sera indépendante pour chaque message à signer.
Cependant, avec les multisignatures, cette solution simple et résistante devient un handicap. Un signataire malveillant pourrait demander deux multisignatures sur le même message en modifiant sa propre contribution sur la deuxième itération. Si le premier signataire choisit son nonce en hachant un secret à côté du message, il finira par utiliser le même nonce dans deux signatures très différentes – c’est le même type de défaillances qui a causé le piratage de la PS3.
Malheureusement, lorsqu’il y a plusieurs signataires, il n’y a pas de solution simple parce que chacun doit choisir ses nonces avant de connaître tous les détails de la signature à produire.
Une solution à ce problème, celle utilisée avant que le hachage ne devienne populaire, est d’employer un générateur de nombre aléatoire. Malheureusement ces mesures sont coûteuses, sujettes à des biais environnementaux ou à d’autres influences externes, et, surtout, il n’y a aucun moyen de vérifier leur bon fonctionnement.
Ce dernier point, au sujet de la vérification, présente quelques solutions innovantes que nous étudierons dans un autre article. Pour l’instant, notre choix était de demander aux utilisateurs d’API qu’ils fournissent un « identificateur de session » unique pour chaque opération de signature. Les nonces sont produites en hachant le secret du signataire, le set de signataires, le message à signer et enfin l’input unique de cette session. Les utilisateurs qui ont accès à un générateur de nombres aléatoires peuvent l’utiliser pour produire des ID de session ; ceux qui ont accès à la mémoire persistante peuvent simplement se servir d’un compteur.
Nous ne sommes pas satisfaits de devoir exiger des nombres aléatoires ou une mémoire persistante et nous espérons que les travaux en cours seront bientôt en mesure de proposer une solution vraiment solide.
Attaques par rejeu (replay attack)
Même avec une source solide de nombres aléatoires, il est toujours possible d’extraire les clés secrètes d’un participant dans une multisignature si on peut rejouer un protocole de signature à partir d’une étape du processus. Ce type d’attaque est appelé « une attaque par rejeu » et peut être perpétré contre un signataire opérant à l’intérieur d’une machine virtuelle redémarrable, ou qui prend en charge l’interruption de la signature et la restauration d’un certain état sérialisable.
Ce genre d’incidents peut aussi se produire accidentellement sans attaquant actif, par exemple en faisant fonctionner deux machines virtuelles clonées à partir du même état, ou en exécutant un code d’une base de données distribuée qui n’est plus en mode de synchronisation.
Plus précisément, si un signataire participe à une multisignature et que le processus de signature est relancé après qu’il ait choisi son nonce, il est possible de modifier les contributions à la signature des autres signataires pour procéder à l’attaque décrite dans la section précédente.
Ces attaques ne se produisent pas avec des signatures uniques parce qu’elles sont produites en une seule étape, sans aucun état intermédiaire à partir duquel on pourrait redémarrer. Ces défis supplémentaires sont propres aux protocoles cryptographiques multi-round.
Sans les nouveaux mécanismes que nous recherchons activement, il n’y a rien que nous puissions faire pour protéger les utilisateurs qui signent avec des machines virtuelles. Bien que nous puissions constater que l’utilisation de machines virtuelles est de toute façon moins sécurisée, parce que si un attaquant est capable de réinitialiser une machine, il pourrait peut-être également en extraire des données secrètes.
Afin de protéger les signataires susceptibles de sérialiser des états obsolètes et de les redémarrer, notre API ne prend tout simplement pas en charge la sérialisation des sessions de signature.
En pratique, cela signifie que les utilisateurs de notre code qui souhaitent exécuter des sessions de signature capables de survivre à des réinitialisations ou des interruptions d’alimentation, (objectif raisonnable pour un wallet hardware) doivent conserver une mémoire persistante sécurisée. Si de tels wallets souhaitent générer plusieurs sessions de signature en parallèle, il leur faut une mémoire persistante supplémentaire pour chaque session. Encore une fois, nous pensons pouvoir remédier à ce problème en creusant les approches sur lesquelles nous travaillons.
Conclusion et perspectives
Comme nous l’avons vu, les protocoles multipartites présentent de nouveaux défis considérablement plus difficiles que les protocoles monopartites. En termes de complexité mathématique, MuSig est beaucoup plus simple que, par exemple, Bulletproofs. Mais en termes d’implémentation, MuSig a demandé plus d’efforts et a nécessité davantage de compromis entre antifragilité et flexibilité des API.
Ce billet est dédié aux multisignatures - signatures dans lesquelles un nombre N de signataires collaborent pour produire une signature unique. Dans un prochain article, nous décrirons les signatures de seuil, un concept associé dans lequel chaque sous-ensemble des N signataires, à condition qu’ils soient en quantité suffisante, est capable de produire des signatures sans contribution de la part du groupe entier.
Dans les prochains articles, nous parlerons également de certaines techniques permettant de rendre l’aspect aléatoire de la production des nonces plus sûr et vérifiable. Par exemple, en utilisant une technique appelée “sign to contract”, un ordinateur hôte peut éliminer toute possibilité de biais provenant du générateur de nombres aléatoires d’un wallet hardware non fiable.