FROST est un protocole de signatures de Schnorr à seuil : des signatures numériques créées à plusieurs. Le seuil impose la coopération d’un nombre minimal de détenteurs de parts distinctes d’une même clé secrète. Une clé secrète est un nombre nécessaire à la création d’une signature ; ici, les participants utilisent leurs parts lors de la signature, plutôt que la clé complète. Le résultat se vérifie avec une seule clé publique de groupe, qui peut être partagée et ne permet pas de signer à elle seule. Le nom signifie Flexible Round-Optimized Schnorr Threshold ; ce n’est ni un portefeuille ni un nouveau type de bitcoin.
Imaginons une association dont Anna, Jan et Eva gèrent l’épargne. Ils choisissent la règle 2 sur 3 : Anna et Jan, Anna et Eva, ou Jan et Eva peuvent autoriser un paiement. Chacun conserve une part secrète différente, une portion du matériel de clé commun construite cryptographiquement. Une seule part ne suffit pas, mais il ne s’agit pas non plus de trois copies du même mot de passe. Si Eva est indisponible, les deux autres peuvent coopérer. La même limite vaut pour un attaquant : obtenir assez de parts lui permet aussi de signer. La répartition n’aide donc que si compromettre un appareil ou un compte ne donne pas accès à tous les autres. [1] [2]
Anna ne devrait pas confirmer une opération simplement parce que l’application annonce une signature en attente. Elle doit connaître le destinataire, le montant et les frais, et vérifier que la monnaie éventuellement rendue revient à l’association. Chaque signataire a besoin d’un moyen fiable de vérifier la transaction réelle. Un hash, une courte empreinte cryptographique des données, n’en explique pas le contenu à une personne. FROST permet de coopérer sur un même message ; il ne juge ni l’authenticité d’une facture ni la compréhension de celui qui l’approuve. Même une signature achevée n’est pas une confirmation du paiement dans un bloc. Un bloc regroupe des transactions inscrites dans l’historique commun du réseau Bitcoin. RFC 9591 est une spécification informative du protocole, pas un certificat de sécurité de l’application entière. [1] [2]
Taproot est une amélioration de Bitcoin qui permet de dépenser des fonds soit avec une signature correspondant à la clé prévue, soit en remplissant des conditions fixées à l’avance. Une signature à seuil correctement construite peut ressembler à une signature ordinaire produite avec une seule clé lors d’une dépense par la voie de clé de Taproot. La signature seule ne révèle ni le nombre interne de parts ni le seuil. Cela favorise la confidentialité et réduit la taille des données de signature, mais ne garantit pas l’anonymat de la transaction ni des communications entre participants. Bitcoin exige les règles précises de BIP 340 ; un FROST générique sur la courbe secp256k1, la base mathématique des calculs sur les clés de Bitcoin, ne suffit pas. Zcash Foundation (ZF) propose donc frost-secp256k1-tr spécialement pour Taproot. Les ajustements de clé de Taproot doivent eux aussi être correctement appliqués. Un même nom de courbe ne prouve pas la compatibilité, et l’existence d’une bibliothèque ne signifie pas que tous les portefeuilles la prennent en charge. [3] [4]
Avant toute signature, l’association doit créer les parts de manière sûre. Un distributeur de confiance peut générer la clé complète et la diviser. Cela crée un moment sensible : il connaît toute la clé, et une copie conservée permettrait de contourner l’approbation collective prévue. L’autre voie est DKG, la génération distribuée de clés, où la clé secrète complète n’a pas à apparaître chez un seul participant. Elle exige des communications authentifiées et protégées ainsi qu’une exécution correcte du protocole. Envoyer quelques fichiers par courriel ne suffit pas. RFC 9591 porte surtout sur la signature ; il ne promet pas automatiquement DKG dans chaque produit. Une part de clé à long terme est également distincte d’une part de signature pour un paiement précis. [1] [2]
La signature elle-même comporte deux tours, sans compter la génération préalable de la clé. Chaque participant sélectionné crée d’abord deux valeurs secrètes à usage unique, les nonce, et transmet leurs engagements publics : des valeurs qui le lient cryptographiquement à ces nonce. Il reçoit ensuite le message commun et la liste des engagements, vérifie les données et calcule sa part de signature. Le coordinateur rassemble ces parts. Des facteurs de liaison rattachent les calculs au message précis, à la clé publique du groupe et aux engagements. Avec une règle 2 sur 3, une session peut commencer avec deux participants. Si les trois sont sélectionnés pour cette session, tous doivent contribuer ; celui qui cesse de répondre ne peut pas simplement être écarté. [1] [3]
Un nonce est ici une valeur secrète destinée à une seule tentative de signature, pas un mot de passe réutilisable. Sa réutilisation peut révéler du matériel de clé secret. Si l’ordinateur de Jan tombe en panne après l’envoi d’une part de signature, restaurer un état ancien ne doit pas rendre à nouveau disponibles les nonce déjà utilisés. Un paiement inachevé n’autorise pas non plus leur réutilisation. Une implémentation sûre exige un bon aléa, la séparation des tentatives simultanées et l’élimination fiable des valeurs consommées. Voilà pourquoi il ne faut pas bricoler FROST à partir de scripts quelconques. Des mathématiques correctes ne suffisent pas à protéger des données secrètes mal gérées. [1]
Le coordinateur organise les messages, mais ce rôle seul ne lui permet pas de signer pour l’association. Il lui faut les contributions des détenteurs de parts sélectionnés. Il peut néanmoins retenir les communications ou interrompre une session, tout comme une contribution invalide peut la faire échouer. Les contrôles peuvent détecter une part de signature invalide ; attribuer la faute à une personne exige de connaître de manière fiable l’origine des messages. Détecter le problème ne garantit pas l’aboutissement. Une nouvelle tentative demande un groupe autorisé disponible et de nouveaux nonce. L’association a donc besoin d’un plan pour les pannes et les désaccords, pas seulement d’un seuil affiché sur l’écran d’accueil. [1] [2]
Si Eva perd son appareil, le seul nom FROST ne récupérera pas ses fonds. La sauvegarde doit préserver sa part, son identifiant, les données de groupe nécessaires et la possibilité de les charger dans un logiciel compatible. Ce n’est pas automatiquement une Seed Phrase ordinaire, la sauvegarde d’un portefeuille sous forme de mots. Récupérer une part avec l’aide des autres et renouveler les parts sont des procédures supplémentaires que le système doit prendre en charge. Une copie de la part d’Eva reste la même part et n’ajoute aucune voix indépendante. Un renouvellement conservant la même clé de groupe ne neutralise pas non plus un ensemble suffisant de parts volées auparavant. Avant d’engager une épargne réelle, un essai doit donc couvrir la récupération, les pannes et la version exacte du logiciel, pas seulement une signature réussie. [2] [3]
Pour une vision complète, lisez aussi Schnorr Signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing, Bitcoin.