Le calcul multipartite signe avec deux algorithmes de clé : ECDSA sur secp256k1 et EdDSA sur Ed25519 (bientôt disponible). Cette page présente le protocole ECDSA à seuil, DKLS23, et les modifications que Google y a apportées. Pour connaître les algorithmes compatibles, consultez Blockchains compatibles.
ECDSA à seuil et DKLS23
Contrairement à d'autres schémas de signature, le problème de la signature à seuil pour l'ECDSA est notoirement difficile. Jusqu'en 2017, la plupart des solutions impliquaient des compromis importants.
En 2018, DKLS a présenté la première solution de signature 2 sur 2 pour l'ECDSA qui ne reposait que sur des hypothèses cryptographiques basées sur l'ECDSA (par exemple, elle ne nécessitait pas Paillier, RSA ni d'autres familles d'hypothèses de dureté cryptographique). L'idée révolutionnaire de ce protocole était une nouvelle façon de plaider en faveur de la sécurité malveillante pour une approche basée sur le MPC (les tentatives précédentes d'application de techniques MPC génériques sécurisées contre les attaques malveillantes ont abouti à des protocoles dont l'exécution nécessitait des minutes au lieu de millisecondes).
Les améliorations ultérieures apportées par les mêmes auteurs ont abouti à un protocole k-out-of-n, et enfin l'amélioration DKLS23 a abouti à un framework générique pour l'ECDSA à seuil k-out-of-n à trois tours qui a capturé toutes les approches précédentes et a identifié l'approche DKLS comme la plus efficace selon des métriques de performances notables. En particulier, cette version du protocole ne repose que sur des primitives d'engagement idéal et de multiplication à deux parties. Le protocole obtenu nécessite quelques millisecondes de calcul par partie (ce qui se traduit par des gains de vitesse d'un ordre de grandeur par rapport aux approches concurrentes). De plus, il repose sur des primitives cryptographiques plus simples qui n'utilisent que des opérations de courbe elliptique (contrairement aux opérations homomorphes coûteuses de Paillier, et aux preuves de plage à divulgation nulle de connaissance et de conformité des clés cryptographiques requises dans d'autres travaux).
Le protocole a été évalué en interne par plusieurs auditeurs, y compris des experts engagés par Coinbase et d'autres experts en cryptographie. Doerner et Roy DR26 ont récemment identifié une erreur de calcul dans l'analyse de sécurité du multiplicateur DKLS, qui nécessite 22 appels supplémentaires d'OT pour atteindre les 120 bits de sécurité revendiqués. Ce changement a été appliqué. De même, d'autres auditeurs externes ont souligné l'absence de détails dans la description du protocole concernant les implications de la diffusion dans le modèle de canal point à point (il est notamment important de répéter certains paramètres de configuration pour obtenir des connaissances communes).
Les travaux ultérieurs de Google sur le protocole ont considérablement renforcé l'implémentation, réduit les ressources nécessaires pour exploiter le protocole à grande échelle et étendu les fonctionnalités du schéma. Par exemple, la documentation universitaire ne spécifie pas suffisamment la sélection et l'implémentation de l'oracle aléatoire. Bien qu'il s'agisse d'une abstraction académique utile, l'implémentation de l'oracle aléatoire est une tâche subtile qui a entraîné plusieurs failles documentées par des audits de sécurité.
Un aspect notable de notre travail a été de développer un système de types (basé sur deux opérations de génération et de duplication, ainsi que sur l'utilisation rigoureuse de systèmes de types pour empêcher la copie, le déplacement et l'aliasing des pointeurs vers les oracles) afin de s'assurer que chaque session et sous-session utilise un oracle aléatoire différent.
Une autre amélioration importante concerne la sélection des identifiants de session et de sous-session. Le modèle UC, et donc tous les protocoles dont la sécurité a été prouvée dans ce modèle, nécessitent que l'environnement fournisse de nouveaux identifiants de session. En pratique, un système doit s'assurer que l'adversaire ne peut pas enfreindre cette hypothèse, ce qui nécessite généralement que les participants maintiennent un état illimité à cette fin. Nous avons ajouté des tours supplémentaires au protocole DKLS d'origine pour sélectionner cet identifiant d'une manière qui ne nécessite qu'un état de taille constante.
Dans l'ensemble, le protocole mis à jour et renforcé effectue toujours une opération de signature en quelques dizaines de millisecondes.
En termes de fonctionnalités, l'article DKLS23 ne prend en compte que la structure d'accès au seuil k-out-of-n standard. En pratique, les clients peuvent avoir besoin d'une structure d'accès qui imite les règles de l'organisation. La littérature cryptographique contient de nombreuses approches pour concevoir des structures d'accès pour le partage de secrets. Ici, nous avons étendu le protocole DKLS pour prendre en charge des structures d'accès plus générales qui peuvent être composées à partir de portes de seuil k-out-of-n. Cela permet de définir des règles telles que "2 groupes sur 3 parmi les suivants : (a) le client, (b) 2 responsables du contrôle des risques sur 10, (c) 2 responsables des services financier, juridique et comptable sur 3", etc.
Dans l'API v1beta, vous définissez cette structure d'accès en tant que stratégie de clé d'un trousseau de clés, dans le champ keyPolicy. Chaque clé créée dans le trousseau de clés l'utilise. Une stratégie de clé peut comporter au maximum deux niveaux : la règle de seuil racine et les règles de seuil directement en dessous. Une règle de seuil sous la racine ne peut pas contenir une autre règle de seuil.