Conservation institutionnelle de bitcoins sur Google Cloud

Aperçu

Ce produit est soumis aux "Conditions des offres de pré-DG" de la section "Conditions générales du service" des Conditions spécifiques du service. Les produits de pré-DG sont disponibles "en l'état" et peuvent avoir une prise en charge limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Pour protéger les réserves institutionnelles de bitcoins sans créer de point de compromission unique, vous pouvez distribuer des clés de signature entre des enclaves isolées au niveau matériel à l'aide du calcul multipartite Google Cloud . Ce document compare Cloud Key Management Service (Cloud KMS) et Cloud HSM au calcul multipartite, évalue les deux modèles de sécurité pour la conservation de bitcoins et présente une topologie de référence.

Lorsque vous déplacez la conservation de Bitcoin vers le cloud, vous devez choisir entre deux architectures de gestion des clés :

• Modules de sécurité matériels (HSM) à clé unique : Cloud KMS et Cloud HSM gèrent les clés cryptographiques statiques dans les limites physiques des HSM.
• Signature de seuil distribuée : le calcul multipartite distribue les parts de clé entre des environnements d'exécution sécurisés (TEE) isolés par le matériel et soutenus par des clés de racine de confiance HSM.

Cloud KMS et Cloud HSM sont compatibles avec le chiffrement encapsulé d'entreprise et l'infrastructure de clé publique Web. Cependant, ils n'ont pas été conçus pour les primitives de conservation de Bitcoin, telles que la dérivation de clés déterministes hiérarchiques (HD) selon la proposition d'amélioration de Bitcoin 32 (BIP32), la signature Schnorr BIP340 et la gouvernance multipartite précise.

Principaux défis de la conservation de bitcoins dans le cloud

Le tableau suivant récapitule les trois principaux défis que vous rencontrez lorsque vous évaluez les services de gestion de clés cloud standards pour la conservation de bitcoins, et comment le calcul multipartite répond à chaque exigence.

Exigence	Limitation dans Cloud KMS et Cloud HSM	Comment le calcul multipartite répond à cette exigence
Dérivation de clé BIP32	Les partitions Cloud HSM mutualisées sont conçues pour la gestion statique et plate des clés, comme le chiffrement d'enveloppe d'entreprise. Pour préserver la sécurité au niveau de l'hyperviseur dans les environnements cloud partagés, les fournisseurs de services cloud n'autorisent pas les modules de micrologiciel HSM personnalisés. Cloud HSM ne peut donc pas calculer les chemins de dérivation BIP32 de manière native. En raison de cette contrainte, Cloud KMS nécessite des architectures de clés plates. Les applications doivent soit suivre des ressources de clés distinctes, soit dériver des clés enfants dans la mémoire hôte non chiffrée.	Le calcul multipartite utilise l'homomorphisme linéaire du programme de portée monotone DKLS23 pour calculer localement les chemins de dérivation BIP32 non renforcés. Chaque nœud calcule indépendamment l'ajustement du décalage scalaire public (IL) et applique ce décalage à son partage de clé local sans aucune communication réseau. Dans les portefeuilles à clé unique, la compromission d'une clé publique étendue parente (xpub) et d'une clé privée enfant non renforcée permet à un pirate informatique de calculer la clé privée parente. Le calcul multipartite supprime cette exposition, car les clés privées enfants (kchild) ne sont pas assemblées en texte brut. Elles n'existent que sous forme de partages locaux distribués et éphémères (s1', s2') dans la mémoire TEE chiffrée par le matériel.
Point de compromission unique	La clé privée complète réside dans une seule limite HSM physique. Un identifiant d'autorisation compromis ou une menace interne expose l'intégralité du portefeuille.	La clé privée complète n'existe en texte brut à aucun endroit. Les parts de clé sont distribuées mathématiquement sur des nœuds de calcul indépendants.
Agilité des algorithmes (Schnorr et Taproot)	Les cycles du matériel HSM physique sont lents. L'ajout de la compatibilité avec les courbes elliptiques ou les schémas de signature tels que BIP340 Schnorr sur la courbe secp256k1 nécessite une recertification matérielle pluriannuelle.	Les opérations cryptographiques s'exécutent dans des enclaves Confidential VM isolées au niveau matériel, ce qui permet au calcul multipartite d'adopter les mises à jour de protocole sans modifier la limite physique du HSM.

Comparer Cloud KMS et le calcul multipartite

Lorsque vous concevez une infrastructure de signature de ressources numériques sur Google Cloud, vous pouvez évaluer le modèle HSM à clé unique par rapport au modèle de seuil distribué.

Modèle Cloud KMS et Cloud HSM à clé unique

Dans un déploiement Cloud KMS, Cloud HSM génère une clé de signature asymétrique qui utilise l'algorithme EC_SIGN_SECP256K1_SHA256 directement dans un HSM physique validé FIPS 140-2 de niveau 3. La figure suivante montre comment une couche d'application interagit avec Cloud HSM lors de la dérivation de clés enfants :

Cette architecture fournit une validation gérée FIPS 140-2 de niveau 3 et produit des signatures ECDSA (Elliptic Curve Digital Signature Algorithm) secp256k1 normalisées à faible S que le réseau Bitcoin accepte. Toutefois, elle introduit deux limites architecturales pour la conservation de bitcoins :

• Fragmentation de la gestion des clés : comme Cloud HSM ne peut pas calculer les chemins de dérivation BIP32, votre application doit suivre des millions d'ID de ressources CryptoKey distincts dans Cloud KMS, ce qui supprime les workflows de récupération à racine unique.
• Risque d'exposition de la mémoire : pour effectuer une dérivation renforcée, votre application doit exporter la graine racine dans la mémoire de l'hôte, ce qui brise le périmètre de sécurité matériel.

Modèle de seuil de calcul multipartite distribué

Le calcul multipartite implémente une extension renforcée du protocole ECDSA à seuil DKLS23. Au lieu de générer une seule clé complète, des nœuds indépendants s'exécutant dans Confidential Space sur des enclaves chiffrées par matériel AMD SEV-SNP génèrent et détiennent des parts de clé mathématiques. Pour en savoir plus sur le protocole, consultez Contexte cryptographique DKLS23.

La figure suivante montre comment le calcul multipartite distribue la signature entre les nœuds TEE soutenus par des clés de chiffrement de clé HSM indépendantes :

Ce modèle de seuil distribué offre trois principaux avantages en termes de sécurité :

• Aucune clé privée complète : aucun appareil physique, enclave ou opérateur ne détient la clé privée complète.
• Racine de confiance ancrée au matériel : les parts de clé sont chiffrées au repos sous des clés de chiffrement de clé (KEK) protégées par des partitions Cloud HSM FIPS 140-2 de niveau 3 ou des HSM externes sur site connectés via Cloud External Key Manager.
• Déchiffrement appliqué par attestation : Cloud KMS désencapsule les parts de clé dans la mémoire de l'enclave uniquement lorsqu'un devis d'attestation matérielle confirme que le nœud exécute des images de conteneur de calcul multipartite vérifiées et non altérées.

Mécanismes cryptographiques pour BIP32 et Taproot

Lorsque vous évaluez la signature de seuil pour la conservation de Bitcoin, vérifiez que le protocole est compatible avec la dérivation d'adresse hiérarchique et l'ajustement Taproot sans ajouter de cycles réseau entre les nœuds.

Dérivation additive BIP32 non renforcée

BIP32 définit la dérivation de clé privée enfant non renforcée comme une addition scalaire modulaire :

\[ k_{\text{child} } = (k_{\text{par} } + \text{parse}_{256}(I_L)) \bmod n \]

Étant donné que le calcul multipartite utilise un schéma de partage de secret linéaire basé sur des programmes de span monotones, les nœuds participants dérivent les parts de clé enfant localement, sans aucun cycle de communication réseau. La figure suivante illustre ce flux de dérivation locale sans aller-retour :

Ajustement de la clé Taproot BIP341

Cette propriété linéaire est également compatible avec l'ajustement de clé Taproot BIP341 sans modifier la distribution de partage de clé sous-jacente :

\[ Q = P + t \cdot G \quad \text{where} \quad t = H_{\text{TapTweak} }(P \parallel \text{MerkleRoot}) \]

Avant de participer à la cérémonie de signature de seuil, un nœud participant applique l'ajustement scalaire (t) directement à son partage de clé local. Cette fonctionnalité vous permet d'interagir avec les arbres de scripts Taproot, les ordinaux et les contrats de journal discrets sans régénérer ni repartager les clés.

Comparaison des architectures

Le tableau suivant compare Cloud KMS et Cloud HSM avec le calcul multipartite sur les principales dimensions de conservation.

Dimension architecturale	Cloud KMS et Cloud HSM	Calcul multipartite
Primitives cryptographiques	ECDSA à signature unique sur la courbe secp256k1	ECDSA à seuil (DKLS23) et algorithme de signature numérique à courbe d'Edwards (EdDSA) à seuil sur la courbe Ed25519, extensible à Schnorr à seuil sur la courbe secp256k1
Limite matérielle	Carte HSM PCIe physique	Enclaves Confidential Space AMD SEV-SNP ancrées à une racine de confiance Cloud HSM
Compatibilité avec les portefeuilles HD BIP32	Gestion manuelle de clés Cloud KMS distinctes	Ajustement du partage de clé additive locale sans round
Protection des clés physiques	FIPS 140-2 niveau 3	FIPS 140-2 niveau 3 pour les KEK résidant dans un HSM qui encapsulent les quotes-parts de clés
Latence de signature (p95)	20-50 ms	Moins de 1 000 ms (moins d'une seconde) dans les régions distribuées
Étendue d'une violation d'identifiants	Exposition complète de la clé si les identifiants de l'appelant ou les stratégies IAM (Identity and Access Management) sont compromis	Aucune signature non autorisée, sauf si un pirate informatique compromet simultanément un seuil d'enclaves et de KEK indépendantes
Possibilité de réaliser des audits	Cloud Audit Logs	Cloud Audit Logs et journaux d'attestation matérielle Key Access Justifications

Évolution de BIP32 vers la gestion des clés à seuil

Lorsque vous concevez une plate-forme interne de conservation des ressources numériques, faites la distinction entre les normes de dérivation créées pour les portefeuilles matériels individuels et la gestion des clés distribuées conçue pour la gouvernance institutionnelle. Bien que BIP32 soit largement utilisé pour le suivi des adresses, s'appuyer sur les arbres de dérivation BIP32 pour la sécurité au sein d'une architecture de calcul multipartite (MPC) est redondant et peut ajouter de la complexité opérationnelle.

Contexte historique des portefeuilles BIP32 à seed unique

BIP32 a été conçu en fonction des contraintes de l'auto-conservation individuelle avant que la cryptographie à seuil et les enclaves matérielles ne deviennent largement disponibles :

• Dépendance à la graine racine : au début, la conservation des bitcoins reposait sur la sécurisation physique d'une seule phrase mnémonique lisible par l'humain de 12 ou 24 mots.
• Récupération à partir d'une seule sauvegarde : les portefeuilles HD BIP32 permettent à un utilisateur de sauvegarder une seule phrase de départ et de dériver de manière déterministe des adresses sur plusieurs comptes.
• Point de défaillance unique : la graine mnémonique racine représente un point de défaillance unique total. Si un pirate informatique compromet cette phrase ou cette sauvegarde physique, toutes les clés privées enfants dérivées de tous les comptes sont exposées.

La figure suivante illustre comment la compromission d'une seule graine racine expose chaque compte enfant dérivé :

Supprimer la graine racine avec signature par seuil

Dans une architecture cloud institutionnelle zéro confiance, une graine mnémonique racine lisible par l'humain n'est pas requise. Le calcul multipartite élimine complètement la clé privée racine centrale. Comme aucune clé privée complète n'existe en texte brut sur une seule machine ou un seul support de sauvegarde, vous n'avez pas besoin de récupérer l'adresse à l'aide d'une phrase unique. Au lieu de dériver une arborescence de clés à partir d'un secret, le calcul multipartite distribue des parts de clés indépendantes dans des enclaves isolées de manière cryptographique.

Comparer les chemins de dérivation BIP32 dans le calcul multipartite

Si votre intégration nécessite une compatibilité BIP32 pour les outils de suivi d'adresses externes ou les workflows de comptabilité, comparez les deux chemins d'implémentation technique dans le tableau suivant.

Chemin d'accès de l'exécution	Mécanisme cryptographique	Profil de sécurité et d'exposition	Latence et performances de signature
BIP32 non renforcé avec calcul multipartite	Ajustement additif local : s1' = (s1 + IL) mod n. Chaque nœud calcule le décalage scalaire public (IL) indépendamment et l'applique à son partage de clé local.	Risque lié à une clé unique : dans les portefeuilles non MPC, la compromission d'une clé publique parente (xpub) et d'une clé privée enfant permet à un pirate informatique de recalculer la clé privée parente. Atténuation MPC : les clés privées enfants (kchild) ne sont pas assemblées en texte brut et n'existent que sous forme de partages de clés éphémères et distribués (s1', s2') dans la mémoire TEE chiffrée par le matériel, ce qui empêche la récupération des clés enfants vers les clés parents.	Ne nécessite aucun cycle de communication réseau entre les nœuds MPC pour dériver les clés enfants. S'exécute à la vitesse du processeur local avant la signature. Compatible avec les latences de signature inférieures à la seconde (p95 inférieur à 1 seconde) sur les canaux gRPC chiffrés.
BIP32 renforcé avec calcul multipartite	Hachage HMAC-SHA512 multipartite interactif calculé sur le matériel de clé parent partagé de manière secrète.	Protège contre l'élévation de clé enfant-parent en hachant la clé privée parente, ce qui introduit une complexité de protocole importante. N'offre aucun avantage de sécurité supplémentaire dans un environnement d'enclave multipartite où la clé parente est déjà partagée de manière secrète et protégée contre l'exfiltration.	Nécessite plusieurs cycles de réseau interactifs entre les nœuds MPC pour évaluer un circuit HMAC-SHA512 de seuil sur des entrées partagées secrètes. Augmente la latence de signature et crée des goulots d'étranglement dans le traitement des transactions.

Recommandations pour la conservation institutionnelle

Le calcul multipartite est compatible avec la dérivation additive BIP32 non renforcée pour assurer la compatibilité avec les systèmes existants et les outils de suivi d'adresses externes. Pour une conservation institutionnelle dédiée, envisagez de passer à des clés de seuil indépendantes gérées directement dans le calcul multipartite :

• Éliminer les dépendances à racine unique : générez, alternez et sauvegardez des parts de clés indépendantes dans des enclaves isolées au lieu de dériver des clés en tant que décalages mathématiques à partir d'une clé racine unique.
• Augmenter l'agilité des algorithmes : dissociez votre couche d'orchestration des chemins de dérivation BIP32 spécifiques à Bitcoin afin de pouvoir adopter des schémas de signature non ECDSA, tels que le schéma de signature Ed25519 pour les réseaux de contrats intelligents, sous un modèle de gouvernance unique.
• Réduire la complexité de la signature : gérez des clés de seuil distinctes pour simplifier les recherches dans la base de données, limiter la taille des requêtes de transaction et réduire la latence de signature.