Auteur : Omer Shlomovits, ZenGo.
Le schéma de signature à seuil (TSS) est un schéma primitif cryptographique permettant de générer et de signer des clés distribuées. L’utilisation de TSS dans les calculs de blockchain est un nouveau paradigme qui peut offrir de nombreux avantages, notamment en termes de sécurité. Autrement dit, TSS peut influencer la conception des systèmes de gestion de clés (tels que les portefeuilles numériques) et diriger le domaine du support local dans les cas d'utilisation de DeFi. Cela dit, ce TSS est encore une nouvelle technologie, les risques et les limites doivent donc également être pris en compte lors de son utilisation.
Dans cet article, nous expliquerons ce qu'est TSS, quels avantages potentiels il peut apporter au domaine de la blockchain, comment il peut être implémenté dans la blockchain client, comment il se compare au partage de secret Shamir et à Multisig, quelles sont les différentes façons d'utiliser TSS. dans la gestion distribuée des clés, et enfin nous discutons de ses risques et limites potentiels.
Rôle du cryptage
Pour comprendre TSS, nous avons d’abord besoin de connaissances de base en cryptographie. Depuis les années 1970, les systèmes Internet utilisent de plus en plus le chiffrement asymétrique (tel que TLS et PGP), également connu sous le nom de cryptographie à clé publique (PKC). PKC utilise deux clés : une publique et une privée. Bien que la clé publique ne soit pas secrète et puisse être partagée et utilisée par n'importe qui, la clé privée est une information confidentielle qui représente la sécurité du système et ne peut être partagée.
Le cryptage et les signatures numériques sont les utilisations les plus courantes de PKC. Les schémas de chiffrement et de signature numérique reposent sur des ensembles de trois algorithmes. Le premier est la génération de la paire de clés privée et publique, le deuxième est la génération du texte chiffré/signature et le troisième est le processus de décryptage/vérification. Concernant les signatures numériques : L'algorithme de signature nécessite qu'une clé privée connue uniquement de son propriétaire crée une signature unique. Une signature est attachée à un message particulier de telle manière que toute personne détenant la clé publique puisse vérifier son authenticité et son authenticité.
Chaîne de blocs
Il ne fait aucun doute que la blockchain est une technologie extrêmement puissante. Il fournit une couche de consensus qui organise et enregistre les événements. Une telle infrastructure donne à nous, utilisateurs et même aux gouvernements, le pouvoir potentiel de construire des économies décentralisées. Étonnamment, le cryptage nécessaire au fonctionnement d’une simple blockchain ne peut s’appuyer que sur des signatures numériques. Dans la blockchain, les clés privées représentent des identités tandis que les signatures sont une déclaration publique ou une affirmation formulée par une identité. La blockchain demande et vérifie les données selon un ensemble de règles qui garantissent, entre autres choses, que les signatures sont infalsifiables et valides.
La boîte à outils de cryptographie moderne comprend quelques tours de magie intéressants, contrairement à la cryptographie plus classique utilisée dans la blockchain. Quelques exemples de ces astuces incluent les preuves sans connaissance, la cryptographie homomorphe et le calcul multipartite. 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 grâce à des avancées récentes surprenantes dans les connaissances dans tout ce qui précède et bien plus encore.
Dans cet article, nous nous concentrerons sur l’une des avancées, à savoir les signatures à seuil sécurisé (TSS) efficaces.
MPC et le schéma de signature de 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 groupe de parties qui ne se font pas confiance tentent de calculer une fonction sur leurs entrées tout en gardant ces entrées privées.
Par exemple, disons qu'un certain nombre d'employés d'une entreprise souhaitent savoir qui est mieux payé, mais sans se révéler leur salaire réel. Ici, l'entrée spéciale concerne les salaires et les embarras seront le nom de l'employé avec le salaire le plus élevé. Lorsque ce calcul est effectué à l’aide de MPC, le résultat est qu’aucun salaire n’est divulgué lors du calcul.
Les deux principales caractéristiques de MPC sont l’authenticité et la confidentialité :
Exactitude : la sortie générée par un algorithme est correcte (comme prévu).
Confidentialité : les données confidentielles détenues par une partie ne seront pas divulguées à d'autres parties.
Nous utiliserons MPC pour calculer la signature numérique de manière distribuée. Voyons comment les propriétés ci-dessus peuvent être appliquées aux signatures. Pour les signatures, nous avons trois étapes :
Génération de clé : La première étape est aussi la plus compliquée. Nous devons créer une clé qui sera publique et utilisée pour vérifier les futures signatures. Mais nous devons également créer un secret individuel pour chaque partie participante, que nous appellerons secret partagé. Dans le contexte de l'exactitude et de la confidentialité, nous disons que la fonction produira la même clé publique pour toutes les parties et un partage secret différent pour les éléments suivants : (1) Confidentialité : aucune donnée sur le partage secret n'est divulguée entre les deux parties et ( 2) Exactitude : La clé publique est fonction des partages secrets.
Signature : Cette étape inclut la fonction de création d’une signature. La contribution de chaque partie est sa part secrète, qui est générée comme résultat de l'étape précédente (génération de clé distribuée). Il existe également une entrée générale connue de tous qui est le message à signer. Le résultat sera une signature numérique et la fonction de confidentialité garantit qu'aucune fuite de partages secrets ne se produit pendant le calcul.
Vérification : L'algorithme de vérification reste le même que dans les paramètres classiques. Pour être compatible avec les signatures de clé individuelles, toute personne connaissant la clé publique doit être capable de vérifier et d'authentifier les signatures. C'est exactement ce que font les nœuds de vérification de la blockchain.
Le schéma de signature à seuil (TSS) est le nom que nous donnons à la combinaison de la génération de clés distribuées (DKG) et de la distribution de signatures sur un schéma de signature à seuil.
Combiner TSS et blockchain
La manière naturelle dont TSS peut être utilisé dans une blockchain consiste à modifier le client blockchain pour générer des clés et des signatures à l'aide de TSS. Ici, nous utilisons le terme client pour désigner un ensemble de commandes exécutées par un nœud complet. En application pratique, la technologie TSS nous permet de remplacer toutes les commandes liées à la clé privée par des calculs distribués.
Pour expliquer cela plus en détail, nous commencerons par une description rapide de la façon de créer de nouvelles adresses sur une structure blockchain classique. 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.
En utilisant désormais TSS, nous aurons un groupe de parties calculant conjointement la clé publique. Chaque partie participante détient une part secrète de la clé privée (les parts individuelles ne sont pas révélées aux autres parties participantes). En utilisant la clé publique, nous pouvons dériver l’adresse de la même manière que dans le système traditionnel, ce qui rend la blockchain quelque peu neutre dans la manière dont les adresses sont générées. L’avantage ici est que la clé privée n’est plus un point de défaillance unique car chaque partie en conserve une partie.
La même chose peut être faite lors de la signature des transactions. Dans ce cas, au lieu qu’une partie signe avec sa clé privée, nous exécutons un générateur de signature distribué entre plusieurs parties. Même chaque partie peut produire une signature valide à condition qu’un nombre suffisant de participants agissent honnêtement. Nous sommes à nouveau passés d'un compte local (point de défaillance unique) à un compte interactif.
Il est important de noter que la génération des clés distribuées peut se faire de manière à permettre différents types d'accès à celles-ci : un paramètre générique « t sur n » sera capable de résister jusqu'à t échecs arbitraires dans les opérations liées à la clé distribuée. clé privée sans compromettre la sécurité.
TSS contre Multisig
Certains réseaux blockchain offrent la fonctionnalité TSS en tant que partie intégrée ou programmable du logiciel. Nous appelons cette fonction multisig ou multi-signature. Pour mieux comprendre les différences, nous pouvons considérer le multisig comme un TSS dans la phase de mise en œuvre de la blockchain.
En d’autres termes, multisig et TSS tentent essentiellement d’atteindre des objectifs similaires, mais TSS utilise le cryptage hors chaîne tandis que multisig utilise le chiffrement en chaîne. Cependant, la blockchain nécessite une méthode de cryptage multisig, ce qui peut compromettre 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 deux sites différents doivent également être communiquées sur la blockchain.
Dans TSS, les détails des signataires sont intégrés dans une transaction régulière, ce qui réduit les coûts et préserve la confidentialité. Multisig, en revanche, peut être non interactif, ce qui évite le problème de la gestion d'une couche de communication complexe entre différents sites.
Le principal point de différence est que la blockchain multisig doit être réimplémentée sur chaque blockchain et, dans certains cas, n'est pas du tout prise en charge. En revanche, TSS est basé sur un cryptage pur, il est donc toujours pris en charge. Un excellent article décrivant les différences peut être trouvé ici.
Le projet de partage de secrets entre TSS et Shamir
Le système de partage de secrets Shamir (SSSS) fournit un moyen distribué de stocker la clé privée. Pendant que la clé privée est stockée, 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 partie appelée « le revendeur » qui est responsable de la création des partages secrets de la clé. Cela signifie qu'au moment de la génération de la clé, la clé privée est générée en un seul endroit puis distribuée par le distributeur aux différents emplacements. Mais dans TSS, il n'y a pas de distributeur car son rôle est distribué de telle sorte que la clé privée complète ne se trouve jamais au même endroit.
Signature : dans SSSS, les parties doivent reconstruire la clé privée complète afin de signer, ce qui conduit à nouveau à un point de défaillance unique à chaque fois qu'une signature est requise. En revanche dans TSS la signature se fait de manière distribuée sans recréer les partages secrets.
Comme nous le voyons dans TSS, la clé privée (représentant la sécurité du système) n'est jamais au même endroit tout au long de sa durée de vie.
Gouverneur de seuil
Un portefeuille construit sur la technologie TSS est un peu différent des portefeuilles de crypto-monnaie traditionnels. Un portefeuille traditionnel crée généralement une phrase de départ et l'utilise pour dériver des adresses de manière déterministe. L'utilisateur peut ensuite utiliser la structure hiérarchique déterministe (HD) pour 1) accéder aux clés privées qui correspondent aux adresses du portefeuille et signer des transactions avec elles. 2) Pour récupérer toutes les clés du portefeuille à l’aide de la phrase de départ.
Dans les portefeuilles à seuil, les choses sont plus compliquées. Bien qu'il soit possible de créer une architecture hiérarchique déterministe (HD), sa construction doit être calculée de manière distribuée comme tout autre protocole MPC. Les parties impliquées doivent prendre une décision commune sur la clé qui sera ensuite utilisée. En d’autres termes, chaque partie aura sa propre déclaration initiale. Les instructions de départ sont générées séparément et ne sont pas combinées, de sorte qu'aucune des parties ne peut à elle seule déduire les clés privées de l'instruction de départ.
Les portefeuilles basés sur TSS disposent également d'une fonctionnalité de sécurité intéressante qui permet de faire pivoter la clé privée sans modifier sa clé publique et son adresse blockchain correspondantes. La rotation des clés privées, é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 partages peuvent également être utilisés de la même manière.
Cette architecture ajoute une dimension temporelle à la sécurité, ce qui signifie qu'un attaquant devrait se trouver à plusieurs endroits en même temps pour tenter de pirater le portefeuille Threshold. La combinaison des partages secrets avant et après la rotation ne donnerait aucun pouvoir supplémentaire à un attaquant s'il souhaitait falsifier une signature.
L’inconvénient de ce type de portefeuille est l’absence de phrase de départ qui le rend incompatible avec les systèmes de portefeuille à clé unique. Il est donc important de décider quelles parties conserveront le partage confidentiel.
Il existe plusieurs moyens possibles tels que :
Externalisation TSS : l'utilisateur autorisera « n » serveurs à exécuter le calcul en son nom. Externalisez efficacement la création, la gestion et la signature des clés à des prestataires de services qui ne sont pas propriétaires des actifs mais qui fournissent un niveau de sécurité en échange d'incitations.
Utilisation de plusieurs appareils : l'utilisateur exécutera TSS sur les appareils qu'il possède. Par exemple, une partie serait un appareil IoT, une autre partie serait un utilisateur de téléphone mobile, une autre tierce partie serait un ordinateur portable, et ainsi de suite.
Systèmes hybrides : le TSS sera exploité de telle sorte que certaines parties soient contrôlées par des prestataires de services externes tandis que d'autres fonctionnent sur leur propre matériel.
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 grand nombre d’entre eux ne sont pas attaqués en même temps mais en pratique, ils peuvent être attaqués en même temps) et voler les actifs des utilisateurs.
La deuxième méthode donne à l'utilisateur un contrôle total mais rend le processus de transaction fastidieux car vous avez besoin de plusieurs appareils pour vous connecter à Internet et participer au compte TSS.
La troisième option est la meilleure des deux options car elle offre à l'utilisateur un moyen simple et rapide d'effectuer des transactions sans le compromis d'effectuer des transactions 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, mais certaines ne sont pas surprenantes. Comme mentionné précédemment, TSS est un cryptage primitif qui peut augmenter considérablement la sécurité. Dans le contexte de la blockchain, on pourrait dire que de nombreuses fonctions peuvent être remplacées par la cryptographie basée sur TSS. Des applications décentralisées, des solutions de couche 2 pour la mise à l'échelle, les échanges atomiques, le brassage, l'héritage et bien plus encore peuvent être construits sur le framework TSS. Cela permettra à terme de remplacer les opérations de contrats intelligents 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é pour échanger le réseau Lightning de Bitcoin contre un réseau de canaux de paiement plus sécurisé et privé. ShareLock est probablement la solution de brouillage de blockchain Ethereum la moins chère, basée sur la vérification à l'aide d'une signature à seuil unique.
Risques
Au cours des deux dernières années, le nombre de demandes TSS a considérablement augmenté. Mais comme toute technologie relativement nouvelle, elle présente encore certaines limites et préoccupations. Comparés à la cryptographie à clé publique traditionnelle, les protocoles TSS peuvent être très complexes et n’ont pas encore été « testés en action ». TSS nécessite généralement des hypothèses cryptographiques supplémentaires et plus faibles par rapport aux simples signatures numériques. En conséquence, des vecteurs d’attaque cryptographiques qui n’existaient pas auparavant dans les contextes traditionnels sont désormais détectés (voir cette présentation de la Breaking Bitcoin Conference 2019). Les ingénieurs en sécurité et les cryptographes d'applications peuvent vous aider à implémenter TSS en toute sécurité dans votre système.
Du côté positif, les applications existantes et nouvelles deviennent plus fortes grâce à des contributions accrues en matière de qualité, des évaluations par les pairs, des vérifications croisées et des améliorations des performances de calcul à l'aide d'algorithmes.
Réflexions finales
Dans cet article, nous présentons les bases du Threshold Signature Scheme (TSS), une étonnante primitive de cryptographie qui a le potentiel de changer radicalement la façon dont les blockchains sont utilisées.
Étant donné que cet article ne traite pas du seuil ECDSA qui peut être utilisé sur Binance Chain et Bitcoin, les personnes intéressées peuvent lire les articles de la liste suivante. De plus, si vous souhaitez essayer certaines implémentations TSS, vous pouvez trouver le code pour un portefeuille Binance Chain bipartite ici ou essayer le portefeuille ZenGo qui utilise la méthode hybride pour fournir un portefeuille Binance Chain bipartite.
Lecture approfondie :
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 à la garde des crypto-monnaies
ECDSA bipartite à partir de systèmes à l'épreuve du 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 multipartite