Technologies de gestion des clés

Tout modèle de conservation se résume à une question : comment produit-on une signature valide, et qui peut la produire ? Quatre familles de technologies dominent la gestion institutionnelle des clés, et la plupart des dépositaires les combinent. Chacune implique des compromis différents en matière de transparence, de flexibilité, de prise en charge des chaînes et de dépendance à un fournisseur. Un professionnel doit pouvoir expliquer ces compromis à un comité des risques.

Modules de sécurité matériels

Un module de sécurité matériel (HSM) est un appareil inviolable qui génère, stocke et utilise des clés de sorte que les éléments de clé privée ne le quittent jamais en texte clair. Les applications envoient un message au HSM pour qu’il le signe, puis récupèrent une signature. Les banques utilisent des HSM depuis des décennies pour les cartes de paiement et l’infrastructure à clés publiques (PKI), et la plupart des dépositaires institutionnels de cryptomonnaies en utilisent quelque part dans leur infrastructure.

Les HSM sont validés conformément à la norme FIPS 140-3, la norme américaine et canadienne pour les modules cryptographiques administrée par le Cryptographic Module Validation Program (CMVP) du NIST. La norme FIPS 140-3 est entrée en vigueur le 22 septembre 2019 et est alignée sur ISO/IEC 19790:2012 (exigences) et ISO/IEC 24759 (méthodes d’essai). Elle définit quatre niveaux de sécurité :

La conservation institutionnelle vise généralement le niveau 3. L’ancienne norme, FIPS 140-2, a cessé d’accepter de nouvelles soumissions pour évaluation en septembre 2021. Le 21 septembre 2026, tous les certificats FIPS 140-2 encore valides ont été transférés à la Historical List du CMVP. Les agences fédérales américaines ne devraient pas acheter de modules figurant sur cette liste pour de nouveaux systèmes, et la plupart des acheteurs institutionnels appliquent la même règle. Un nouvel achat de HSM devrait donc être accompagné d’un certificat FIPS 140-3 en cours de validité.

Un certificat couvre un module précis, pour une version particulière du micrologiciel et dans un mode particulier. Il ne certifie pas l’ensemble du système de conservation. Lors de l’évaluation d’un HSM, vérifiez le numéro du certificat, le niveau, la version du micrologiciel et la prise en charge des algorithmes nécessaires à l’entreprise : secp256k1 pour Bitcoin et Ethereum, Ed25519 pour des chaînes comme Solana. Un HSM classique qui détient une seule clé constitue également un point de contrôle unique. Toute personne pouvant se connecter au HSM et lui soumettre des messages peut obtenir des signatures ; les politiques qui l’encadrent comptent donc autant que le matériel.

Portefeuilles multisignatures

Un portefeuille multisignature (multisig) exige des signatures provenant de m clés indépendantes sur n, par exemple 3 sur 5. La règle est appliquée par la blockchain elle-même :

• Sur Bitcoin, par des scripts natifs (P2WSH, ou scripts Taproot depuis la mise à niveau de 2021).
• Sur Ethereum et les autres chaînes EVM, par un contrat intelligent. Le plus utilisé est Safe (anciennement Gnosis Safe).

Les avantages du multisig sont évidents. La politique est visible sur la chaîne, de sorte qu’un auditeur peut confirmer que 3 signatures sur 5 sont requises. Les clés peuvent se trouver sur différents appareils, auprès de différents fournisseurs et dans différents pays, de sorte qu’une compromission isolée ne suffit pas. Les inconvénients sont tout aussi concrets. Chaque chaîne nécessite sa propre implémentation, et certaines chaînes ne prennent pas du tout en charge le multisig. Les transactions sont plus volumineuses et les frais plus élevés. Sur Bitcoin, changer de signataire implique de transférer les fonds vers une nouvelle adresse. Sur les chaînes EVM, le contrat du portefeuille et son interface utilisateur font partie de la surface d’attaque. Le vol de Bybit en février 2025 a visé un multisig Safe via son interface, et non sa cryptographie (voir la leçon Menaces et mesures de sécurité opérationnelle).

MPC et signatures à seuil

Un schéma de signature à seuil (TSS) utilise le calcul multipartite (MPC) pour répartir le pouvoir de signature entre plusieurs parties. Pendant la génération distribuée de clés (DKG), chaque partie crée son propre fragment de clé, et la clé privée complète n’existe nulle part, même l’espace d’un instant. Pour signer, n’importe quelles t parties sur n exécutent un protocole qui produit une signature ordinaire unique. Sur la chaîne, la transaction est identique à une transaction à clé unique.

Parmi les protocoles courants figurent GG18, GG20 et CGGMP pour ECDSA (le schéma de signature de Bitcoin et Ethereum), ainsi que FROST pour les signatures Schnorr et EdDSA. FROST a été publié par l’IETF sous la référence RFC 9591 en juin 2024.

Le MPC présente de réels avantages :

• Indépendance vis-à-vis des chaînes : toute chaîne qui utilise une courbe prise en charge fonctionne, sans nécessiter de prise en charge du multisig sur cette chaîne.
• Frais réduits et confidentialité accrue : la transaction ne comporte qu’une seule signature.
• Renouvellement des fragments : les fragments peuvent être renouvelés, ou le quorum modifié, sans transférer les fonds ni changer l’adresse.

Il présente aussi de réels inconvénients. Le quorum est invisible sur la chaîne, les auditeurs doivent donc se fier à la documentation du fournisseur et aux rapports d’assurance. La cryptographie est complexe et des implémentations ont connu des défaillances. En août 2023, les chercheurs de Fireblocks ont révélé les vulnérabilités « BitForge » dans des implémentations de GG18 et GG20 chez plusieurs fournisseurs de portefeuilles (l’une d’elles a été répertoriée sous le numéro CVE-2023-33241) ; dans certains cas, un attaquant pouvait extraire la clé complète. La plupart des solutions sont propriétaires, ce qui crée une dépendance envers le fournisseur. Un dépositaire a besoin d’une méthode éprouvée pour récupérer les actifs si le fournisseur disparaît.

Ne confondez pas le MPC avec le partage de secret de Shamir (SSS). Le SSS divise une clé déjà créée en plusieurs fragments à des fins de sauvegarde, mais la clé doit être reconstruite en un seul endroit pour signer. Le MPC ne la reconstruit jamais. Une idée connexe sur Bitcoin, MuSig2 (BIP 327), permet à n signataires de combiner leurs clés afin qu’une dépense Taproot à n signatures sur n ressemble à une signature unique.

Portefeuilles à contrats intelligents et abstraction de compte

Sur Ethereum, un compte à contrat intelligent est un portefeuille dont les règles sont codées. Il peut imposer des limites de dépense, des autorisations par rôle, des clés de session assorties de droits limités, une récupération sociale ou institutionnelle, et le paiement du gaz par un tiers. Deux normes sont importantes :

• ERC-4337, en production sur le réseau principal Ethereum depuis 2023, permet l’abstraction de compte sans modifier le protocole. Les utilisateurs soumettent des « opérations utilisateur » que des bundlers regroupent en transactions via un contrat EntryPoint commun. Des paymasters facultatifs peuvent payer le gaz.
• EIP-7702, activée avec la mise à niveau Pectra le 7 mai 2025, permet à un compte ordinaire détenu en externe (EOA) de pointer vers du code de contrat. Le compte bénéficie alors des fonctionnalités d’un compte intelligent tout en conservant son adresse.

Le compromis porte sur le risque lié aux contrats. Un bogue dans le code du portefeuille, ou une fonction de mise à niveau mal contrôlée, peut entraîner la perte de tous les fonds. Avec EIP-7702, une seule signature d’autorisation malveillante peut céder le contrôle d’un compte au code d’un attaquant, et des campagnes d’hameçonnage ont déjà ciblé cette vulnérabilité. Les questions de mise à niveau et de clés d’administration sont abordées dans la leçon Évaluer le risque DeFi.

Génération de clés et cérémonies de clés

La fiabilité d’une clé dépend de la manière dont elle a été créée. Les dépositaires institutionnels génèrent les clés de grande valeur lors d’une cérémonie de clés : une procédure scénarisée, observée et consignée.

Pour le MPC, la cérémonie DKG devrait faire appel à une infrastructure distincte pour chaque fragment, contrôlée par des personnes différentes, afin qu’aucune équipe ne détienne jamais à elle seule un nombre de fragments suffisant pour atteindre le seuil.

Choisir et combiner les technologies

Les grands dépositaires s’appuient rarement sur une seule technologie. Une approche courante consiste à utiliser le MPC pour les portefeuilles actifs et semi-actifs, où la rapidité et la prise en charge des chaînes sont importantes. Le stockage à froid repose sur des clés protégées par HSM ou sur un multisig avec des signataires répartis géographiquement. Des règles de contrat intelligent ajoutent des limites sur la chaîne lorsque celle-ci les prend en charge. Lors de l’évaluation d’un fournisseur, posez quatre questions :

1. Une clé privée complète existe-t-elle à un moment donné et, le cas échéant, où et pendant combien de temps ?
2. Un tiers peut-il vérifier la politique de signature, ou peut-il seulement lire la description qu’en donne le fournisseur ?
3. Que se passe-t-il si le fournisseur de technologie fait faillite, et la récupération sans lui a-t-elle été testée ?
4. Quels composants sont couverts par quelles certifications (un certificat FIPS 140-3 pour le HSM, un rapport d’assurance pour le système dans son ensemble) ?

Points clés pour l'examen : ce que fait un HSM et les quatre niveaux de sécurité FIPS 140-3 (le niveau 3 est courant pour la conservation) ; pourquoi un nouveau HSM devrait avoir un certificat FIPS 140-3 maintenant que les certificats FIPS 140-2 figurent sur la Historical List ; comment le multisig impose un seuil m sur n sur la chaîne et quels sont ses compromis (politique visible, solution propre à chaque chaîne, frais plus élevés) ; comment fonctionne le MPC/TSS (DKG, la clé n’existe jamais, une signature ordinaire unique sur la chaîne) et quels sont ses compromis (politique invisible, risque d’implémentation tel que BitForge, dépendance envers le fournisseur) ; la différence entre le MPC et le partage de secret de Shamir ; ERC-4337 et EIP-7702 (Pectra, mai 2025) et les risques liés aux contrats ; les étapes et les preuves d’une cérémonie de clés.