Auteur : Omer Shlomovits, ZenGo.
Threshold Signature Scheme (TSS) est une primitive cryptographique pour la génération et la signature de clés distribuées. L’utilisation de TSS dans les clients blockchain est un nouveau paradigme qui peut apporter de nombreux avantages, notamment en termes de sécurité. Dans un sens plus large, TSS peut influencer la conception des systèmes de gestion de clés (tels que les portefeuilles cryptographiques) et ouvrir la voie à une prise en charge native dans les cas d'utilisation de DeFi. Cela dit, le TSS est encore une nouvelle technologie, ses risques et ses limites doivent donc également être pris en compte.
Dans cet article, nous expliquerons ce qu'est un TSS, quels sont les avantages potentiels qu'il apporte à l'espace blockchain, comment il peut être implémenté dans un client blockchain, comment il se compare au partage de secret Shamir et à Multisig, quelles sont les différentes façons de le faire. utilisez TSS pour la gestion des clés distribuées et enfin nous discutons des risques et des limites.
Le pouvoir de la cryptographie
Pour comprendre TSS, nous avons d’abord besoin de connaissances de base en cryptographie. Depuis les années 1970, de plus en plus de systèmes Internet (tels que TLS et PGP) ont utilisé la cryptographie asymétrique, également connue sous le nom de cryptographie à clé publique (PKC). PKC utilise deux clés : une publique et une privée. Même si la clé publique n’est pas secrète et peut être publiée et utilisée par n’importe qui, la clé privée est une information secrète qui représente la sécurité du système.
Le cryptage et les signatures numériques sont les deux utilisations les plus courantes de PKC. Les systèmes de cryptage et de signature numérique reposent sur des ensembles de trois algorithmes. Le premier est la génération de paires de clés privées et publiques, le deuxième est la génération d'un texte chiffré/signature et le troisième est le processus de déchiffrement/vérification. En ce qui concerne les signatures numériques, l'algorithme de signature nécessite que la clé privée, connue uniquement de son propriétaire, produise une signature unique. La signature est attachée à un message donné de manière à ce que toute personne détenant la clé publique puisse vérifier son authenticité et son exactitude.
Chaîne de blocs
Il ne fait aucun doute que la blockchain est une technologie très puissante. Il fournit une couche de consensus qui organise et enregistre les événements. Une telle infrastructure nous donne, à nous les utilisateurs, le pouvoir potentiel de construire des économies décentralisées et même des gouvernements. Étonnamment, la cryptographie nécessaire au fonctionnement d’une blockchain de base peut être basée uniquement sur des signatures numériques. Dans le contexte d'une blockchain, les clés privées représentent des identités tandis qu'une signature est une déclaration ou une revendication publique faite par une identité. La blockchain ordonnera les déclarations et les validera selon un ensemble de règles qui garantissent, entre autres, que les signatures sont infalsifiables et correctes.
Contrairement à la cryptographie plus classique utilisée dans la blockchain, la boîte à outils cryptographique moderne comprend des tours de magie impressionnants : des preuves sans connaissance, un cryptage homomorphe et un calcul multipartite, pour n'en nommer que quelques-uns. Comme nous l’avons vu au cours de la dernière décennie, la recherche sur la blockchain a considérablement fait progresser la cryptographie appliquée, avec des percées récentes dans tout ce qui précède et bien plus encore.
Dans cet article, nous nous concentrerons sur une seule de ces avancées : les signatures à seuil sécurisé (TSS) efficaces.
MPC et le schéma de signature à seuil (TSS)
Le calcul multipartite (MPC) est une branche de la cryptographie qui a débuté avec les travaux fondateurs d'Andrew C. Yao, il y a près de 40 ans. Dans MPC, un ensemble de parties qui ne se font pas confiance tentent de calculer conjointement une fonction sur leurs entrées tout en gardant ces entrées privées.
A titre d'exemple, disons que n salariés d'une entreprise souhaitent savoir qui est le mieux payé mais sans se dévoiler leur salaire réel. Ici, les entrées privées sont les salaires et la sortie sera le nom de l'employé avec le salaire le plus élevé. En effectuant ce calcul à l'aide de MPC, nous obtenons qu'aucun salaire n'est divulgué pendant le calcul.
Les deux propriétés principales de MPC sont l’exactitude et la confidentialité :
Exactitude : le résultat produit par un algorithme est correct (comme prévu).
Confidentialité : les données d'entrée secrètes détenues par une partie ne seront pas divulguées aux autres parties.
Nous utiliserons MPC pour calculer une signature numérique de manière distribuée. Voyons comment les propriétés ci-dessus peuvent être appliquées aux signatures. Rappelons que, pour les signatures, nous avons trois étapes :
Génération de clés : la première étape est aussi la plus complexe. Nous devons générer une clé qui sera publique et utilisée pour vérifier les futures signatures. Mais nous devons également générer un secret individuel pour chaque partie, que nous appellerons un partage de secret. En termes d'exactitude et de confidentialité, nous disons que la fonction fournira la même clé publique à toutes les parties, et un partage secret différent pour chacune, de sorte que : (1) confidentialité : aucune donnée de partage secret n'est divulguée entre les parties, et (2) exactitude : la clé publique est fonction des partages secrets.
Signature : cette étape implique une fonction de génération de signature. L'entrée de chaque partie sera sa part secrète, créée en sortie de l'étape précédente (génération de clé distribuée). Il existe également une contribution publique connue de tous, qui constitue le message à signer. Le résultat sera une signature numérique, et la propriété de confidentialité garantit qu'aucune fuite de partages secrets ne s'est produite pendant le calcul.
Vérification : l'algorithme de vérification reste tel qu'il est dans le cadre classique. Pour être compatible avec les signatures à clé unique, toute personne connaissant la clé publique doit être en mesure de vérifier et de valider les signatures. C’est exactement ce que font les nœuds de validation de la blockchain.
Le schéma de signature à seuil (TSS) est le nom que nous donnons à cette composition de génération de clé distribuée (DKG) et de signature distribuée d'un schéma de signature à seuil.
Combiner TSS avec des blockchains
La manière naturelle dont TSS peut être utilisé dans une blockchain consiste à modifier un client blockchain pour générer des clés et des signatures à l'aide de TSS. Ici, nous utilisons le terme client blockchain pour désigner l'ensemble de commandes exécutées par un nœud complet. En pratique, la technologie TSS nous permet de remplacer toutes les commandes liées aux clés privées par des calculs distribués.
Pour l'expliquer plus en détail, nous commençons par décrire brièvement comment les nouvelles adresses sont créées sur la conception classique de la blockchain. En termes simples, nous pouvons créer une nouvelle adresse en générant une clé privée, puis en calculant la clé publique à partir de la clé privée. Enfin, l’adresse blockchain est dérivée de la clé publique.
Maintenant, en utilisant TSS, nous aurions un ensemble de n parties calculant conjointement la clé publique, chacune détenant une part secrète de la clé privée (les parts individuelles ne sont pas révélées aux autres parties). À partir de la clé publique, nous pouvons dériver l’adresse de la même manière que dans le système traditionnel, rendant la blockchain indépendante de la manière dont l’adresse est générée. L’avantage est que la clé privée n’est plus un point de défaillance unique car chaque partie n’en détient qu’une partie.
La même chose peut être faite lors de la signature des transactions. Dans ce cas, au lieu qu’une seule partie signe avec sa clé privée, nous exécutons une génération de signature distribuée entre plusieurs parties. Ainsi, chaque partie peut produire une signature valide à condition qu’un nombre suffisant d’entre elles agissent honnêtement. Encore une fois, nous sommes passés du calcul local (point de défaillance unique) à un calcul interactif.
Il est important de mentionner que la génération de clé distribuée peut être effectuée de manière à permettre différents types de structures d'accès : le paramètre général « t sur n » sera capable de résister jusqu'à t échecs arbitraires dans les opérations liées à la clé privée, sans compromettre la sécurité.
TSS contre Multisig
Certaines blockchains offrent la fonctionnalité TSS en tant que partie intégrée ou programmable du logiciel. Nous appelons cette fonctionnalité multisig ou multi-signature. Pour mieux comprendre les différences, nous pouvons considérer le multisig comme un TSS dans la couche application de la blockchain.
En d’autres termes, multisig et TSS tentent essentiellement d’atteindre des objectifs similaires, mais TSS utilise la cryptographie hors chaîne, tandis que le multisig se produit en chaîne. Cependant, la blockchain a besoin d'un moyen de coder le multisig, ce qui pourrait nuire à la confidentialité car la structure d'accès (nombre de signataires) est exposée sur la blockchain. Le coût d’une transaction multisig est plus élevé car les informations sur les différents signataires doivent également être communiquées sur la blockchain.
Dans TSS, les détails des signataires sont intégrés dans une transaction d’apparence régulière, ce qui réduit les coûts et préserve la confidentialité. D'un autre côté, le multisig peut être non interactif, ce qui évite d'avoir à gérer une couche de communication complexe entre les différents signataires.
Le principal point de différence est que le multisig est spécifique à la blockchain et doit être réimplémenté pour chaque blockchain et, dans certains cas, il n'est pas du tout pris en charge. À l’inverse, TSS s’appuie sur la cryptographie pure, le support est donc toujours possible. Un excellent article avec des illustrations sur les différences peut être trouvé ici.
Schéma de partage de secrets TSS contre Shamir
Le système de partage de secret Shamir (SSSS) fournit un moyen de stocker la clé privée de manière distribuée, de sorte que même si la clé privée est au repos, elle est stockée à plusieurs emplacements. Il existe deux différences entre SSSS et TSS :
Génération de clé : dans SSSS, il existe une seule partie appelée « le concessionnaire » qui est chargée de générer les partages secrets de clé privée. Cela signifie qu'au moment de la génération de clé, la clé privée est générée en un seul emplacement puis distribuée par le revendeur aux différents emplacements. Dans TSS, il n'y a pas de revendeur car son rôle est réparti de telle sorte que la clé privée complète ne se trouve jamais à un seul emplacement.
Signature : dans SSSS, les parties doivent reconstruire la clé privée complète afin de signer, ce qui entraîne encore une fois un point de défaillance unique à chaque fois qu'une signature est nécessaire. Dans TSS, la signature se fait de manière distribuée sans jamais reconstruire les partages secrets.
Comme nous pouvons le voir, dans TSS, la clé privée (qui représente la sécurité du système) ne se trouve jamais à un seul endroit pendant toute sa durée de vie.
Portefeuilles à seuil
Un portefeuille basé sur la technologie TSS est un peu différent des portefeuilles de crypto-monnaie traditionnels. En règle générale, un portefeuille conventionnel génère une phrase de départ et l'utilise pour dériver les adresses de manière déterministe. L'utilisateur peut ensuite utiliser cette structure déterministe hiérarchique (HD) pour 1) atteindre les clés privées qui correspondent aux adresses du portefeuille et signer des transactions avec elles, et 2) récupérer toutes les clés du portefeuille à l'aide de la phrase de départ.
Dans un portefeuille à seuil, les choses sont plus complexes. Bien qu'il soit possible de générer une structure HD, sa génération doit être calculée de manière distribuée, comme un autre protocole MPC. Les parties doivent décider ensemble de la prochaine clé à utiliser. En d’autres termes, chaque parti aura sa propre phrase de départ. Les phrases de départ sont générées séparément et jamais combinées, de sorte qu'une seule partie ne peut pas dériver les clés privées de sa graine.
Les portefeuilles basés sur TSS disposent également d'une fonctionnalité de sécurité intéressante, qui permet la rotation de la clé privée sans modifier la clé publique et l'adresse blockchain correspondantes. La rotation de clé privée, également connue sous le nom de partage proactif de secrets, est un autre protocole MPC qui prend les partages secrets en entrée et génère un nouvel ensemble de partages secrets. Les anciens partages secrets peuvent être supprimés et les nouveaux peuvent être utilisés de la même manière.
Une telle structure ajoute une dimension temporelle à la sécurité, ce qui signifie qu'un attaquant doit se trouver à plusieurs endroits en même temps pour attaquer un portefeuille à seuil. La combinaison des partages secrets avant et après la rotation ne donnera à l'attaquant aucun pouvoir supplémentaire s'il souhaite forger une signature.
L’inconvénient de ce type de portefeuille est que l’absence de phrase de départ le rend incompatible avec les systèmes de portefeuille à clé unique. Il est donc important de déterminer quelles parties détiendront les actions secrètes.
Il existe quelques architectures possibles :
Externalisation du TSS : l'utilisateur laissera « n » serveurs exécuter le calcul en son nom. Externaliser efficacement la génération, la gestion et la signature des clés à des prestataires de services qui ne sont pas propriétaires des actifs mais fournissent une couche de sécurité en échange d'une certaine incitation.
Utilisation de plusieurs appareils : l'utilisateur exécutera le TSS entre les appareils qu'il possède. Par exemple, une partie sera un appareil IoT, une autre partie sera l'utilisateur mobile, une autre partie sera son ordinateur portable, et ainsi de suite.
Hybride : TSS fonctionnera de telle sorte que certaines parties soient contrôlées par des fournisseurs de services externes et que d'autres fonctionnent sur des appareils appartenant aux utilisateurs.
La première méthode décharge le lourd calcul TSS du côté utilisateur client. D’un autre côté, les fournisseurs de services peuvent s’entendre (nous supposons qu’un nombre suffisant d’entre eux ne sont pas attaqués en même temps, mais en pratique, ils pourraient le faire) et voler les actifs de l’utilisateur.
La deuxième méthode donne à l'utilisateur un contrôle total, mais rend la réalisation de transactions fastidieuse car vous avez besoin de plusieurs appareils pour vous connecter en ligne et participer au calcul TSS.
La troisième option est considérée comme le meilleur des deux mondes car elle offre à l'utilisateur un moyen simple et rapide d'effectuer des transactions, mais sans compromettre le fait que les transactions soient effectuées sans l'autorisation de l'utilisateur.
TSS et contrats intelligents
Au fil des années, les chercheurs ont découvert de nombreuses utilisations des signatures numériques, et certaines sont étonnamment non triviales. Comme mentionné, TSS est une primitive cryptographique qui peut considérablement augmenter la sécurité. Dans le contexte des blockchains, on peut dire que de nombreuses fonctionnalités peuvent être remplacées par la cryptographie basée sur TSS. Les applications décentralisées, les solutions de mise à l'échelle de couche 2, les échanges atomiques, le mixage, l'héritage et bien plus encore peuvent être construits sur un framework TSS. Cela permettrait à terme de remplacer les opérations de contrats intelligents en chaîne coûteuses et risquées par des alternatives moins chères et plus fiables.
Pour donner quelques exemples concrets : Multi-Hop Locks utilise les signatures bipartites de manière intelligente et peut être utilisé comme alternative au réseau Lightning Bitcoin avec un réseau de canaux de paiement plus sécurisé et privé. ShareLock est probablement la solution de mixage en chaîne la moins chère pour Ethereum, basée sur la vérification d'une signature de seuil unique.
Des risques
Au cours des deux dernières années, il y a eu une augmentation significative des implémentations de TSS. Cependant, en tant que technologie relativement nouvelle, elle présente encore certaines limites et préoccupations. Comparés à la cryptographie classique à clé publique, les protocoles TSS peuvent être très complexes et doivent encore être « testés au combat ». Habituellement, TSS nécessite des hypothèses cryptographiques supplémentaires, plus faibles, par rapport aux simples signatures numériques. En conséquence, des vecteurs d’attaque cryptographiques qui n’existaient pas dans les configurations traditionnelles sont désormais découverts (voir cette présentation de la Breaking Bitcoin Conference 2019). Les ingénieurs en sécurité et les cryptographes appliqués peuvent vous aider à déployer en toute sécurité TSS dans votre système.
Du côté positif, les implémentations existantes et nouvelles deviennent plus solides grâce à une augmentation des contributions de qualité, des évaluations par les pairs, des audits et des améliorations des performances algorithmiques.
Pensées finales
Dans cet article, nous avons présenté les bases du schéma de signature à seuil (TSS), qui est une primitive cryptographique fascinante qui a le potentiel de changer considérablement la façon dont nous utilisons la blockchain.
Étant donné que cet article ne traite pas du seuil ECDSA qui peut être utilisé dans Binance Chain et Bitcoin, les personnes intéressées peuvent se référer à la liste suivante d'articles récents. De plus, si vous souhaitez jouer avec certaines implémentations TSS, vous pouvez trouver un code pour le portefeuille Binance Chain bipartite ici ou essayer le portefeuille ZenGo, qui utilise la méthode hybride pour fournir un portefeuille Binance Chain bipartite non dépositaire.
Lectures complémentaires :
Signature ECDSA bipartite rapide et sécurisée
ECDSA multipartite rapide et sécurisé avec génération de clés distribuées pratiques et applications pour la garde de crypto-monnaie
ECDSA bipartite à partir de systèmes de preuve de hachage et d'instanciations efficaces
ECDSA à seuil multipartite rapide avec configuration rapide sans confiance
Seuil bipartite sécurisé ECDSA à partir des hypothèses ECDSA
Seuil ECDSA à partir des hypothèses ECDSA : le cas du multipartisme
