À des fins éducatives uniquement ; ceci ne constitue pas un conseil en investissement ou en sécurité. Un dispositif à seuil ne réduit certains risques de clé que si le protocole, l’implémentation, les participants et la récupération sont sécurisés indépendamment.
Réponse directe
Un schéma de signature à seuil permet à au moins M participants sur N de produire ensemble une signature sous une clé publique unique. Moins de M parts valides ne doivent permettre ni de signer ni de découvrir la clé. Dans un protocole correct, la clé privée complète n’est pas reconstruite pendant la signature courante.
Le vérificateur emploie normalement l’algorithme habituel du format obtenu : il peut voir une seule signature ECDSA, EdDSA ou Schnorr, et non une liste on-chain. Cette compatibilité peut donc masquer le seuil, les participants et leur indépendance réelle.
La signature à seuil est une application du calcul multipartite sécurisé (MPC), pas un synonyme. Un portefeuille MPC peut l’utiliser, mais le MPC couvre aussi d’autres calculs. Diviser une sauvegarde de seed n’est pas une signature à seuil si le secret doit être reconstitué avant usage.
La sécurité dépend du protocole précis, du modèle d’adversaire, des communications authentifiées, de l’aléa, de la garde des parts, de l’indépendance, de la chaîne logicielle, du moteur de politiques et de la récupération. « M-of-N » ne suffit pas à l’évaluer.
Fonctionnement
- Choisir le schéma et le modèle de menace. Fixer algorithme, M-of-N, identités, hypothèses de compromission et de réseau, et propriétés requises. Une protection contre un adversaire statique peut échouer si celui-ci compromet successivement plusieurs parties.
- Créer les éléments distribués. Un dépositaire de confiance peut partager le secret ; une génération distribuée de clé (DKG) peut créer parts et clé publique sans assembler la clé privée. La DKG supprime le dépositaire mais ajoute tours, preuves, plaintes et cas d’échec.
- Autoriser un message exact. Chaque participant doit vérifier chaîne, compte, montant, destination, frais, nonce et politique. Le quorum cryptographique ne remplace pas le contrôle de la transaction.
- Exécuter le protocole. Le quorum échange engagements, preuves et parts de signature. Les nonces propres au protocole doivent rester uniques et secrets : réutilisation ou biais peut révéler la clé. Certains schémas prétraitent ; FROST spécifie un protocole Schnorr à seuil en deux tours.
- Vérifier et maintenir. Vérifier le résultat avec la clé publique de groupe avant diffusion, conserver les traces utiles, surveiller les échecs, rafraîchir les parts ou changer la clé selon une cérémonie définie, et tester la récupération sans abaisser le seuil.
| Conception | Ce que voit le vérificateur | Application du seuil | Périmètre principal d’examen |
|---|---|---|---|
| Signature à seuil | Une signature et une clé publique | Protocole cryptographique hors chaîne | Protocole, clients, parts, coordinateur, politique et récupération |
| Multisignature on-chain | Plusieurs approbations ou un état de contrat | Chaîne ou smart contract | Contrat, signataires, seuil, modules et pouvoirs de mise à niveau |
| Sauvegarde divisée | Une clé normale après reconstitution | Procédure de récupération | Garde des parts, environnement de reconstitution et traitement ultérieur |
Les protocoles varient selon la famille de signature et le modèle de sécurité. La linéarité facilite les constructions de type Schnorr, sans rendre le protocole concret secondaire. ECDSA n’étant pas linéaire de la même manière, ECDSA à seuil requiert des techniques multipartites supplémentaires. Agrégation, multisignature et signature à seuil peuvent sembler proches tout en affirmant des règles de participation différentes.
Exemple
Imaginons une garde 2-of-3 : équipe de transactions, équipe de risque indépendante et prestataire de récupération détiennent chacun une part. Le retrait normal mobilise les deux équipes ; si une part manque, une autre paire autorisée préserve la disponibilité.
Le chiffre ne prouve pas l’indépendance. Si les 2 premières parts utilisent le même compte cloud, le même jeton d’identité ou un service de politique compromis, un incident peut contrôler le quorum. Séparer appareils, administrateurs, identifiants, réseaux, régions, fournisseurs et preuves d’approbation selon le modèle de menace.
Avant déploiement, tester au minimum :
- chaque combinaison autorisée de 2 parties signe le message prévu ;
- 1 partie ne peut signer, reconstruire la clé ou remplacer un participant ;
- les sessions dupliquées, réordonnées, abandonnées ou retardées ne réutilisent pas de nonce ;
- un coordinateur compromis ne peut modifier le message ni cacher une défaillance ;
- restauration, rafraîchissement, remplacement et rotation complète conservent la politique documentée.
Consigner la clé publique et la version logicielle de chaque cérémonie. Une part restaurée qui contourne la politique actuelle n’est pas une récupération réussie.
Risques
- Compromission corrélée : des parts distinctes dépendent du même administrateur, cloud, composant, environnement ou service de politique.
- Quorum malveillant ou compromis : si M participants autorisés approuvent un message malveillant, la signature reste valide.
- Défaillance des nonces et de l’aléa : réutilisation, biais, fuite, retour d’état ou prétraitement dangereux peut révéler les parts ou la clé effective.
- Écart protocole-implémentation : une preuve pour un protocole, groupe, adversaire ou modèle de session ne couvre pas automatiquement une autre réalisation.
- Abus du coordinateur ou du réseau : censure, équivoque, collecte de métadonnées, rejeu ou abandon sélectif restent possibles sans pouvoir signer seul.
- Indisponibilité : moins de M parties en ligne, compatibles et approuvées empêche toute signature ; un déni de service exige moins qu’un vol.
- Rafraîchissement ou récupération dangereux : sauvegardes périmées, remplacement ou reconstruction urgente peuvent abaisser le seuil, réactiver des parts révoquées ou exposer la clé.
- Gouvernance invisible : rotation, listes d’autorisation, mises à jour et administrateurs de récupération gardent du pouvoir malgré une signature ordinaire on-chain.
- Fausse équivalence : agrégat BLS, multisignature N-of-N, seed divisée et signature à seuil M-of-N ne sont pas interchangeables parce qu’ils combinent des contributions.
Idées reçues
- « La clé privée n’existe jamais. » Elle peut ne pas être assemblée au quotidien, mais initialisation, import, sauvegarde, migration ou urgence changent cette affirmation. Examiner tout le cycle de vie.
- « 2-of-3 supprime tout point unique. » Seules les défaillances portées par des parts réellement indépendantes disparaissent ; infrastructure et politique communes peuvent en recréer un.
- « Une signature on-chain prouve qu’une personne a approuvé. » Le résultat n’indique généralement ni le nombre de parties ni la politique hors chaîne.
- « Le seuil bloque les mauvaises transactions. » Il impose un quorum, pas un bon jugement. Un quorum trompé ou complice peut autoriser un vol.
- « Toute bibliothèque MPC convient à toute chaîne. » Format, courbe, hachage, dérivation, encodage, hypothèses et vérificateur doivent correspondre.
Sujets connexes
Sources
- NIST First Call for Multi-Party Threshold Schemes - NIST (consulté le 2026-08-21)
- Threshold Schemes for Cryptographic Primitives - NIST (consulté le 2026-08-21)
- RFC 9591: The FROST Protocol - IETF (consulté le 2026-08-21)
- Digital Signature Standard (DSS) - NIST (consulté le 2026-08-21)
- Fast Multiparty Threshold ECDSA with Fast Trustless Setup - ACM (consulté le 2026-08-21)