UC-Secure Star DKG for Non-Exportable Key Shares with VSS-Free Enforcement

Cet article présente SDKG, un protocole de génération distribuée de clés (DKG) universellement composable qui, en exploitant des modules matériels de type KeyBox pour des parts de clés non exportables, assure la cohérence affine et l'extraction UC sans partage de secrets ni rétroaction, permettant ainsi la mise en œuvre sécurisée de portefeuilles à seuil en étoile pour des applications multi-appareils.

L'essentiel

🌟 Le Secret de la Clé Indissociable : Une Nouvelle Façon de Sécuriser les Portefeuilles Crypto

Imaginez que vous possédez un coffre-fort numérique contenant des millions de dollars en cryptomonnaie. Pour l'ouvrir, vous avez besoin d'une clé. Mais cette clé est trop précieuse pour être gardée dans un seul endroit (trop risqué) ou partagée de manière classique (trop complexe).

Ce papier de recherche propose une solution ingénieuse pour créer cette clé de manière sécurisée, décentralisée et impossible à voler, même si l'ordinateur qui l'utilise est piraté.

1. Le Problème : La "Clé Interdite" (NXK)

Dans le monde de la sécurité moderne, on utilise souvent des boîtiers de sécurité matériels (comme des puces sécurisées dans les téléphones ou des coffres-forts électroniques appelés HSM/TEEs).

• L'analogie : Imaginez un magicien qui détient le secret de l'ouverture du coffre. Ce magicien vit dans une cage de verre indestructible.
• La règle d'or : Le magicien peut faire des tours de magie (signer des transactions), mais il est interdit de sortir de la cage. Il ne peut même pas écrire le secret sur un papier et le tendre à quelqu'un. Si quelqu'un essaie de lui voler le secret, il ne peut pas le donner. C'est ce qu'on appelle une clé non-exportable.

Le problème, c'est que pour créer une clé partagée entre plusieurs personnes (un "coffre à plusieurs clés"), les méthodes classiques demandent aux participants de s'envoyer des morceaux de la clé par la poste. Mais ici, le magicien ne peut pas envoyer de morceaux de clé ! Comment faire confiance sans échanger les secrets ?

2. La Solution : Le "Certificat de Structure Unique" (USV)

Les auteurs ont inventé une nouvelle astuce magique appelée USV (Unique Structure Verification).

• L'analogie : Au lieu de demander au magicien de sortir le secret, on lui demande de produire un sceau officiel (un certificat).
  • Le magicien garde son secret (le nombre magique) bien caché dans sa cage.
  • Il sort un sceau scellé. Ce sceau ne révèle pas le nombre, mais il prouve mathématiquement qu'il existe un nombre spécifique derrière.
  • N'importe qui, à l'extérieur, peut regarder le sceau et dire : "Ah oui, ce sceau correspond bien à ce point public sur la carte, donc le magicien a bien le bon secret, même si je ne le connais pas."

C'est comme si le magicien vous donnait une empreinte digitale parfaite qui prouve qu'il possède la clé, sans jamais vous montrer la clé elle-même.

3. La Structure en "Étoile" (Star DKG)

Le papier propose un système spécifique pour les entreprises ou les portefeuilles de récupération, appelé SDKG (Star Distributed Key Generation).

• L'analogie : Imaginez une équipe de sauvetage en forme d'étoile.
  • Au centre, il y a le Gardien (un service de confiance, comme une banque ou un serveur sécurisé). Il doit toujours être présent pour ouvrir le coffre.
  • Autour de lui, il y a plusieurs Sauveteurs (votre téléphone, votre ordinateur, un ami de confiance).
  • La règle : Pour ouvrir le coffre, il faut le Gardien + un Sauveteur. Le Gardien ne peut jamais ouvrir seul (trop dangereux), et un Sauveteur ne peut jamais ouvrir seul (il n'a pas la clé centrale).

Ce système permet d'ajouter facilement de nouveaux sauveteurs (par exemple, si vous perdez votre téléphone, vous en ajoutez un nouveau) sans avoir à refaire toute la clé au début. C'est comme ajouter une nouvelle personne à l'équipe de secours sans changer le code du coffre.

4. Pourquoi c'est révolutionnaire ?

Avant, pour sécuriser ce genre de système, il fallait utiliser des méthodes lourdes qui obligeaient les participants à échanger des données sensibles, ce qui était incompatible avec les puces de sécurité modernes (qui refusent de sortir les données).

Ce papier montre comment :

1. Ne jamais sortir le secret : Les données sensibles restent enfermées dans la "cage de verre" (le matériel sécurisé).
2. Vérifier sans voir : Grâce aux certificats (USV) et à des preuves mathématiques avancées (NIZK), on peut vérifier que tout le monde joue le jeu honnêtement sans jamais voir les secrets.
3. Résister aux pirates : Même si un pirate prend le contrôle de votre ordinateur (le "cerveau" qui parle au magicien), il ne peut pas voler la clé car elle reste dans le boîtier sécurisé. Le pirate ne peut que regarder, pas toucher.

En Résumé

Ce papier décrit un protocole de création de clés qui fonctionne comme un jeu de rôle sécurisé :

• Le Magicien (le matériel sécurisé) garde le secret.
• Il produit des Sceaux (certificats) pour prouver sa bonne foi.
• L'Équipe en Étoile (le Gardien + les Sauveteurs) s'assemble pour ouvrir le coffre, mais personne ne peut le faire seul.
• Tout cela se fait sans jamais sortir le secret de sa cage, rendant le système extrêmement robuste contre le vol et la corruption.

C'est une avancée majeure pour les portefeuilles crypto sécurisés, permettant aux entreprises et aux particuliers de gérer leurs actifs avec une confiance absolue, même dans un monde numérique hostile.

Résumé technique

Voici un résumé technique détaillé du papier « UC-Secure Star DKG for Non-Exportable Key Shares with VSS-Free Enforcement » par Vipin Singh Sehrawat.

1. Problématique et Contexte

Le papier aborde le défi de la Génération de Clés Distribuée (DKG) dans un contexte de sécurité renforcé par le matériel, spécifiquement pour les portefeuilles cryptographiques multi-parties (MPC).

• Contrainte des Clés Non Exportables (NXK) : Dans les environnements modernes (enclaves sécurisées, TEE, HSM), les parts de clés secrètes doivent être générées et stockées à l'intérieur du module matériel. Elles ne peuvent jamais être exportées, ni même sous forme d'images affines inversibles par l'appelant. Cela empêche les mécanismes classiques de DKG qui reposent sur l'échange de parts de clés ou de témoins (witnesses) hors du matériel.
• Incompatibilité avec le VSS : Les protocoles DKG universellement composables (UC) sécurisés reposent traditionnellement sur une couche d'Application de Partage Vérifiable (VSE), souvent implémentée via le Partage Secret Vérifiable (VSS). Le VSS nécessite que les parts soient exportées, ouvertes ou rééchangées pour vérifier la cohérence affine et assurer l'unicité de la clé partagée. Cette exigence est fondamentalement incompatible avec le modèle NXK.
• Absence de Réécriture (Rewinding) : La sécurité UC repose souvent sur des techniques d'extraction de témoins par réécriture (rewinding) ou fork (forking lemma). Or, les modules matériels imposent une continuité d'état (State Continuity) : il est impossible de réinitialiser l'état interne du matériel pour répondre à deux défis différents avec le même engagement. L'extraction doit donc être linéaire (straight-line).
• Structure d'Accès en Étoile : L'application cible est un accès de type « 1+1 sur n » (Star Access Structure), où un service central (P1) doit obligatoirement signer avec n'importe quel autre dispositif (P2...Pn), mais ne peut jamais signer seul. Les structures de seuil classiques (t-sur-n) ne conviennent pas car elles autorisent des sous-ensembles sans le service central.

2. Méthodologie et Approche

L'auteur propose une architecture qui découple la confidentialité (gérée par le matériel) de la cohérence (garantie par le protocole cryptographique), sans jamais exporter les secrets.

A. Le Modèle KeyBox et l'Opacité des Clés

Le papier formalise le matériel comme une fonctionnalité idéale FKeyBox.

• Opacité des clés (Key-Opacity) : Les sorties de l'API du KeyBox sont simulables à partir de la clé publique uniquement. Aucune information sur la clé secrète (ni même une image affine inversible) ne peut être déduite des sorties.
• Continuité d'état : Le matériel ne peut pas être réinitialisé ou cloné.
• Sceau KeyBox-to-KeyBox : Le transfert de données sensibles entre modules se fait par chiffrement attesté, sans que le matériel hôte (host) ne puisse déchiffrer les parts.

B. Vérification de Structure Unique (USV - Unique Structure Verification)

C'est la contribution centrale pour contourner l'impossibilité du VSS.

• Concept : L'USV est un certificat non interactif, publiquement vérifiable, qui permet de dériver un élément de groupe public unique à partir d'un engagement sur un scalaire secret, sans exporter le scalaire.
• Fonctionnement : Le module matériel génère un scalaire $m$ (non exportable), calcule un engagement $C$ et un certificat $\zeta$. Le certificat permet à n'importe qui de calculer de manière déterministe le point public $M = mG$ à partir de $(C, \zeta)$, sans connaître $m$.
• Propriété clé : L'extraction de $M$ est linéaire (straight-line) et publique. Cela remplace la nécessité d'ouvrir un engagement (comme dans le VSS) pour vérifier la structure affine.

C. Preuves ZK UC-Extractables (Fischlin Transform)

Pour garantir la cohérence affine entre les parties sans réécriture :

• L'auteur utilise la transformation de Fischlin optimisée dans un modèle d'Oracle Aléatoire Global avec Programmabilité Restreinte (gRO-CRP).
• Cela permet d'obtenir des Arguments de Connaissance Non Interactifs (NIZK-AoK) avec extraction linéaire. Le simulateur UC peut extraire les témoins en inspectant le journal des requêtes de l'oracle (query log) de l'adversaire, sans avoir besoin de réexécuter le protocole.
• Les preuves sont générées par l'hôte (host) pour les vérifications de cohérence (permettant l'extraction), tandis que les preuves internes au KeyBox (LinOS) sont traitées uniquement pour le ZK (simulation).

D. Protocole SDKG (Star DKG)

Le protocole construit une clé partagée selon une structure en étoile :

1. Initialisation : Les nœuds utilisent l'USV pour publier des engagements sur leurs contributions scalaires sans révéler les scalaires.
2. Cohérence Affine : Les parties génèrent des preuves NIZK (basées sur Fischlin) pour prouver que leurs contributions respectent les relations affines nécessaires à la reconstruction de la clé (ex: $K = 3X_1 - 2X_2$).
3. Installation : Une fois le transcript accepté, chaque partie installe sa part de clé secrète dans son KeyBox via une fonction de dérivation locale, sans jamais avoir exposé la part brute.
4. Enregistrement (RDR) : Un mécanisme permet d'ajouter de nouveaux dispositifs de récupération (recovery devices) après la génération de la clé, en scellant les nouvelles parts de manière attestée KeyBox-to-KeyBox, sans recalculer la clé publique ni rééchanger les parts existantes.

3. Contributions Clés

1. USV (Unique Structure Verification) : Introduction d'un nouveau primitif cryptographique permettant de lier un engagement à un élément de groupe public de manière déterministe et vérifiable, tout en maintenant le scalaire sous-jacent non exportable et caché.
2. DKG UC-Sécurisé sans VSS : Première construction DKG UC-sécurisée qui fonctionne strictement dans le modèle NXK, éliminant le besoin de mécanismes de VSS, de plaintes (complaints) ou de rééquilibrage (resharing).
3. Extraction Linéaire sous Contraintes Matérielles : Démonstration de la faisabilité de l'extraction UC linéaire dans un environnement où le matériel empêche le fork/rewinding, en combinant l'USV et la transformation de Fischlin dans le modèle gRO-CRP.
4. Support de la Structure en Étoile (1+1-out-of-n) : Conception d'un schéma adapté aux portefeuilles MPC où un service central est obligatoire, avec un mécanisme d'enregistrement de dispositifs (RDR) qui préserve l'unicité de la clé et la non-exportabilité.
5. Analyse de Sécurité Formelle : Preuve de la réalisation UC (Universally Composable) du protocole, garantissant la confidentialité, l'unicité et la cohérence affine même face à des corruptions adaptatives.

4. Résultats et Performance

• Sécurité : Le protocole réalise une fonctionnalité idéale DKG sous les hypothèses de difficulté du Logarithme Discret (DL) et de DDH (DDLEQ), avec des corruptions adaptatives et des effacements sécurisés.
• Complexité :
  • Communication : $O(n \log p)$ bits pour la base (1+1-out-of-3) et $O(\log p)$ par dispositif supplémentaire enregistré.
  • Calcul : $O(n \log^{2.585} p)$ opérations en bits (modèle Karatsuba).
  • Taille du Transcript : Pour une sécurité de 128 bits, le transcript de base est d'environ 11–13 Ko.
• Comparaison : Contrairement aux DKG UC classiques qui ont une complexité quadratique $\Theta(n^2)$ due aux échanges de parts tous-contre-tous (VSS), le SDKG est linéaire en $n$ grâce à la structure en étoile et l'absence de VSS.

5. Signification et Impact

Ce travail est significatif car il résout un verrou majeur dans le déploiement de portefeuilles MPC sécurisés sur du matériel de confiance (HSM, TEE).

• Adoption Industrielle : Il permet d'utiliser des clés non exportables (exigence de conformité et de sécurité élevée) tout en obtenant les garanties formelles de sécurité UC, ce qui était auparavant impossible avec les protocoles DKG standards.
• Nouveau Paradigme : Il démontre que la vérification de la cohérence des parts de clés ne nécessite pas leur exportation, ouvrant la voie à d'autres protocoles MPC compatibles avec les contraintes matérielles strictes.
• Robustesse : La solution est résiliente aux attaques par réinitialisation (rollback) grâce à la génération déterministe de nonces et à l'utilisation de l'USV, assurant que même en cas de faille de continuité d'état partielle, la clé secrète ne peut être extraite.

En résumé, ce papier propose une fondation théorique et pratique pour des systèmes de gestion de clés distribués qui sont à la fois sécurisés par le matériel (NXK), mathématiquement prouvés (UC) et efficaces, répondant directement aux besoins des infrastructures de crypto-actifs modernes.