Signatures de seuil : la clé privée n'existe jamais

Cet article a été publié pour la première fois sur Medium.
Un schéma de signature à seuil (TSS) (t, n) est un protocole cryptographique qui permet à un groupe de n participants de signer collectivement des documents ou des transactions, où tout sous-ensemble de t + 1 ou plusieurs participants peut produire une signature valide, mais des sous-ensembles de t ou moins ne le peuvent pas. Ce système est conçu pour améliorer la sécurité et la confiance dans les systèmes distribués en garantissant qu'aucune partie ne peut générer unilatéralement une signature, empêchant ainsi les actions non autorisées. TSS améliore la sécurité des clés cryptographiques en répartissant le contrôle entre plusieurs parties, où la clé n'existe jamais.

Préliminaire : Interpolation polynomiale

Un polynôme de degré (t-1) est déterminé de manière unique par t points. Par exemple, deux points définissent une ligne, trois points une parabole, etc.
Si tous les points sont mis à l'échelle selon un facteur constant, le polynôme interpolé est également mis à l'échelle selon le même facteur. Il en va de même pour son ordonnée à l’origine en x = 0.
Interpoler un polynôme mis à l'échelle par k = 2Dans l'exemple ci-dessus, vous avez un polynôme P(x) de degré 2 qui correspond aux points {(1,2), (2,3), (3,5)} et vous mettez à l'échelle les valeurs y de 2, vous obtenez effectivement échelle P(x) par 2 pour obtenir le polynôme d'interpolation pour {(1,4), (2,6), (3,10)}. Son ordonnée à l’origine est également mise à l’échelle par 2, de 2 à 4.
Nous utiliserons cette observation à plusieurs reprises tout au long de l’article.

Schémas de signature à seuil

Imaginez un scénario avec un groupe de n participants étiquetés de P₁ à Pₙ. Dans cette configuration, un schéma de signature à seuil (TSS) (t, n) permet à toute combinaison de t + 1 membres de produire une signature en collaboration. Cependant, tout groupe inférieur ou égal à t membres n’a pas cette capacité.
TSS comprend trois phases.

1. Génération de clé

Le protocole Distributed Key Generation (DKG) est utilisé, comme décrit dans notre article précédent
Génération de clés distribuées. Le secret partagé est une clé privée sk, inconnue de quiconque.
Supposons que DKG soit géré par des participants, notés P₁ à Pₙ, et que chaque utilisateur Pᵢ reçoive un partage secret individuel skᵢ, ainsi qu'une clé publique partagée pk à des fins de validation. skᵢ représente une part secrète (t, n) Shamir du secret global sk. Notez que cette génération de clé est une phase de configuration initiale unique pour TSS, ce qui signifie qu'une fois établis, ces partages de clés privées sont réutilisables pour plusieurs opérations.
La clé publique partagée pk est l'interception 0 de l'interpolation de tous les engagements d'actions (skᵢG), qui sont diffusés dans la phase de partage de secret vérifiable (VSS). Pour voir pourquoi, remarquez
pk = skG
G au point générateur et une constante. sk est l'intersection 0 de tous les skᵢ, donc pk est celui de tous les skᵢG.

2. Génération de signatures

La génération de signature s'exécute en deux étapes :

  • Génération de signature partielle : Chaque participant produit une signature partielle σᵢ en utilisant son partage skᵢ sur un message M : σᵢ = S(skᵢ, M), S étant la fonction de signature
  • Agrégation de signatures partielles : L'agrégation de ces signatures partielles produira une signature finale σ. La chose la plus cruciale est que le processus garantit que la clé privée n’apparaît jamais et qu’ainsi aucune fuite de secret ne puisse se produire
  • Crédit : TSS3. Vérification des signatures
    La vérification d'un schéma de signature à seuil est identique à celui de son homologue sans seuil. Toute personne ayant accès à la clé publique et au message peut vérifier la validité de la signature.

    Signatures de seuil BLS

    Il existe plusieurs schémas de signature qui peuvent être étendus à une version à seuil, notamment ECDSA, Schnorr et BLS. Nous avons choisi BLS comme exemple pour faciliter l'exposition.

    Génération de clé

    A la fin de la génération de clé de seuil, chaque utilisateur Pᵢ obtient un partage de clé, skᵢ, et une clé publique commune pk pour vérification.

    Génération de signature partielle

    Cette étape est la même avec le BLS sans seuil.
    ᵢ génère un partage de signature comme suit.
    σᵢ = skᵢH(m)
    m est le message et H est une fonction de hachage cryptographique.

    Agrégation partielle de signatures

    Un vérificateur rassemble d’abord 𝑡 signatures BLS partielles différentes et valides, σᵢ, sur 𝑚.
    La difficulté ici est de savoir comment obtenir σ à partir de σᵢ, sans connaître sk.
    σ = skH(m)
    Il s'avère σ est l'ordonnée à l'origine d'une interpolation de Lagrange de tout σ's.
    En effet, σᵢ est un facteur constant de skᵢ, c'est-à-dire H(m), qui est partagé par tous les participants. Puisque sk est une ordonnée à l'origine d'une interpolation de Lagrange de tous les skᵢ de DKG, σ est celle de tous les σᵢ.

    Vérification

    La signature agrégée σ est désormais une signature valide pour m pour la clé publique agrégée pk. La vérification de la signature est la même que dans la version sans seuil. Un vérificateur vérifie l’équation suivante :
    e(H(m), pk) ?= e(σ, G)
    pk est la clé publique globale et G est le point générateur.

    Comparaisons

    Les signatures à seuil sont conçues à partir de l'intégration des technologies DKG et Multi-Signature (MultiSig), mélangeant les fonctionnalités supérieures de chacune. Cette fusion aboutit à une solution cryptographique robuste qui résume les atouts de ses prédécesseurs.

    TSS contre Multisig

    Contrairement aux approches multi-signatures, les schémas de signature à seuil (TSS) sont reconnus pour générer des signatures plus compactes tout en améliorant la protection de la vie privée. De plus, TSS étend intrinsèquement les fonctionnalités multi-signatures aux technologies blockchain qui autrement ne prennent pas directement en charge ces fonctionnalités, en particulier dans des contextes exigeant à la fois efficacité et discrétion. Surtout, Les architectures TSS évitent de stocker les clés privées sur les serveurs, renforçant ainsi la gestion des risques et facilitant la répartition des responsabilités entre les participants. Ces avantages importants positionnent TSS comme une solution optimale pour le développement de portefeuilles chauds sécurisés qui fonctionnent en temps réel sans compromettre la confidentialité des clés privées.
    Crédit : MultisigTSS contre DKG
    Dans DKG, un secret peut être construit si un quorum de participants collabore avec leurs actions. Dans le cadre des signatures, le secret est la clé privée. Il peut être créé en premier et utilisé pour la signature. Cependant, cette existence de clé privée dans son intégralité, même brièvement, crée un point de défaillance unique, la rendant vulnérable aux attaques. Dans TSS, la clé privée n'existe jamais et personne ne la voit en clair à aucun moment du processus de signature, ce qui la rend à l'abri de telles attaques.

    Mise en œuvre

    Nous avons implémenté un schéma de signature à seuil (3, 5) sur Bitcoin. Nous choisissons la version ECDSA de TSS puisque ECDSA est nativement pris en charge dans Bitcoin. Il est basé sur la bibliothèque tss-lib.
    Une seule exécution entraîne les transactions suivantes :
    L'adresse et la signature semblent identiques à celles générées normalement sans utiliser TSS.
    Regardez : les applications sCrypt prouvent la puissance du Bitcoin
    Nouveau sur la blockchain ? Consultez la section Blockchain pour les débutants de CoinGeek, le guide de ressources ultime pour en savoir plus sur la technologie blockchain.