Google lancera une plateforme de garde institutionnelle de cryptomonnaies en 2027 : comment fonctionne sa technologie MPC

2026/11/01 11:01:00

Google Cloud a lancé Google Multi-Party Compute (MPC), une solution d'infrastructure spécialisée de gestion et de garde des clés d'actifs numériques conçue pour les banques mondiales, les gestionnaires d'actifs et les institutions financières réglementées. Actuellement en préversion privée sur invitation uniquement, le fournisseur de cloud cible une disponibilité générale commerciale (GA) au début de l'année 2027. Avant un déploiement commercial élargi, Google a validé l'architecture dans des environnements de production internes prenant en charge de grands écosystèmes blockchain, notamment Ethereum et Solana.

Cette initiative représente une expansion notable de l'infrastructure cloud institutionnelle Web3. Depuis plusieurs années, les principaux fournisseurs de cloud ont concentré leurs services d'actifs numériques principalement sur l'hébergement de nœuds RPC, l'indexation des jeux de données de blockchain publiques dans BigQuery et l'exploration de réseaux de règlement d'entreprise.

En introduisant une infrastructure MPC native, Google Cloud s'engage davantage dans la pile de sécurité de la finance numérique institutionnelle : la génération distribuée, la vérification des politiques et la signature seuil des clés cryptographiques. Alors que les institutions financières réglementées augmentent leur implication dans les dépôts tokenisés, les produits négociés en bourse (ETP) à terme et le règlement d'actifs du monde réel (RWA), la MPC intégrée au cloud offre une base technique modulaire aux côtés des fournisseurs de custody traditionnels et des coffres matériels hérités.

Compromission des clés et compromis en matière de garde institutionnelle

La croissance de la participation institutionnelle dans les actifs numériques a souligné l'importance de systèmes de gestion des clés résilients. Le suivi de la sécurité sectorielle par des plateformes telles que DeFiLlama montre constamment que les identifiants compromis et les exploitations de clés privées représentent l'un des principaux vecteurs de perte de capital dans le secteur des cryptomonnaies, ayant causé des milliards de dollars de pertes cumulées au cours des derniers cycles de marché.

Historiquement, le stockage institutionnel d'actifs numériques a reposé sur deux modèles architecturaux principaux, chacun impliquant des compromis opérationnels distincts pour les institutions financières commerciales.

Modules de sécurité matériels hérités et risques de point unique

La gestion traditionnelle des clés financières repose fortement sur des modules de sécurité matériels (HSM) physiques et des environnements de stockage à froid isolés du réseau. Bien que les HSM isolent les clés cryptographiques dans du matériel résistant à la manipulation, les configurations standard à clé unique peuvent toujours introduire un point unique de défaillance structurel (SPOF).

Pour autoriser une transaction blockchain à signature unique conventionnelle, la clé privée complète doit exister dans la limite de mémoire d’un seul module pendant la génération de la signature. Si un attaquant compromet la couche de gestion de l’hôte, exploite une vulnérabilité du micrologiciel ou contourne les contrôles d’accès administratifs, les actifs contrôlés par cette clé unique sont immédiatement exposés.

Limitations des signatures multiples sur chaîne

Pour éviter les dépendances à une seule clé, de nombreux protocoles Web3 utilisent des contrats intelligents multi-signatures (Multi-Sig) sur chaîne, tels que Safe. Dans une structure standard M sur N Multi-Sig, plusieurs clés privées indépendantes doivent soumettre des approbations séparées pour satisfaire les règles d'exécution du contrat intelligent.

Bien que très efficace pour les trésoreries décentralisées, le Multi-Sig sur chaîne présente trois obstacles pratiques pour les processus bancaires traditionnels :

Incompatibilité entre chaînes : la logique Multi-Sig des contrats intelligents n'est pas uniforme sur les blockchains hétérogènes de couche 1. Bien que largement standardisée sur les réseaux de la Machine Virtuelle Ethereum (EVM), la mise en œuvre d'une gouvernance identique par contrat intelligent sur des chaînes non-EVM (telles que Bitcoin ou Solana) nécessite des scripts natifs différents et des pipelines opérationnels séparés.

Coûts de transaction réseau plus élevés : En raison du fait que plusieurs signatures cryptographiques ou appels de contrat sont vérifiés directement sur la chaîne, les transactions Multi-Sig consomment davantage d'espace de bloc et de frais de gaz que les transferts standards à signature unique.

Visibilité publique des règles de gouvernance : Étant donné que les règles Multi-Sig s'exécutent via des contrats intelligents publics, les seuils de quorum, les adresses des signataires et les schémas d'approbation organisationnelle d'une institution sont visibles sur le registre public.

Ces contraintes ont stimulé la demande institutionnelle pour la cryptographie seuil hors chaîne qui unifie les politiques de sécurité sur plusieurs blockchains.

Comment fonctionne le calcul multipartite de Google

Google Cloud Multi-Party Compute résout les risques liés aux clés à point unique en mettant en œuvre des schémas de signatures seuil (TSS) basés sur le calcul multipartite (MPC). Dans ce modèle cryptographique, une clé privée complète n'est jamais assemblée sur un seul appareil, bus mémoire serveur ou centre de données à aucune étape de la génération, du stockage ou de la signature des transactions.

Le protocole de signature de seuil DKLs23 renforcé

Selon les spécifications techniques de la plateforme, le moteur de signature ECDSA de Google intègre une implémentation renforcée du protocole DKLs23. Nommé d'après les cryptographes Döttling, Komargodski, Lai et Shen, DKLs23 est un protocole moderne de signature seuil conçu pour calculer des signatures sur courbe elliptique de manière sécurisée entre des parties distribuées avec un minimum de surcharge de communication.

La mise en œuvre de Google se concentre sur trois priorités opérationnelles :

Résilience face aux adversaires malveillants : le protocole est conçu pour maintenir l'inviolabilité même si un attaquant compromet un sous-ensemble de nœuds participants en dessous du seuil de signature. Des vérifications de cohérence intégrées détectent les parts cryptographiques mal formées pendant la cérémonie de signature et interrompent automatiquement la session avant la production d'une signature invalide.

Optimisation des rounds à faible latence : Les premières implémentations de MPC souffraient souvent de temps de signature lents en raison de multiples rounds de communication réseau aller-retour. En utilisant la structure de round simplifiée de DKLs23, les calculs cryptographiques locaux s'achèvent en quelques millisecondes, permettant des flux de signature bout en bout en moins d'une seconde une fois les vérifications de politique institutionnelle validées.

Prise en charge multi-courbes blockchain : l'architecture prend en charge nativement l'algorithme de signature numérique à courbe elliptique (ECDSA) sur la courbe secp256k1—la norme pour Bitcoin, Ethereum et les réseaux Layer-2 compatibles EVM—ainsi qu'une prise en charge provisoire de l'algorithme de signature numérique à courbe d'Edwards (EdDSA) sur Ed25519 pour couvrir les réseaux à haut débit comme Solana.

Fractionnement hétérogène des clés : le modèle de quorum 2 sur 3

Plutôt que de générer une clé privée en un seul endroit puis de la diviser par la suite, la plateforme utilise la génération distribuée de clés (DKG), où des nœuds indépendants calculent mathématiquement leurs parts de clé respectives sans qu'aucun nœud ne voie jamais la clé complète.

Pour éviter de concentrer le risque sur un seul fournisseur de cloud, les déploiements institutionnels utilisent généralement une structure de quorum hétérogène 2 sur 3 :

Partage 1 (Environnement contrôlé par le client) : Hébergé directement dans le centre de données sur site de l'institution financière ou dans un environnement HSM dédié.

Partagez 2 (Enclave Google Cloud) : Hébergé dans l'environnement isolé matériellement Confidential Space de Google Cloud.

Partagez 3 (Récupération indépendante ou nuage tiers) : Hébergé dans un environnement nuage externe (tel qu’AWS ou Azure) ou conservé hors ligne par un fiduciaire de récupération indépendant.

Dans cette structure de seuil 2 sur 3, deux parts autorisées peuvent collaborer hors chaîne pour produire une signature cryptographique standard. Pour la blockchain sous-jacente, la transaction résultante semble identique à un transfert normal à clé unique.

Si un attaquant parvenait à compromettre un seul environnement, il obtiendrait uniquement une part isolée de la clé — qui, sur le plan mathématique, ne révèle rien sur la clé privée complète et ne peut pas autoriser de transactions par elle-même. À l'inverse, si la station de travail locale d'une institution est compromise, l'attaquant ne peut toujours pas déplacer les fonds unilatéralement à moins que l'enclave de Google Cloud ne vérifie indépendamment que la transaction respecte les politiques de sécurité prédéfinies.

Isolation au niveau matériel : Google Cloud Confidential Space (TEE)

Une préoccupation historique liée à la gestion des clés hébergées dans le cloud est l'élévation de privilèges au niveau de l'hôte : si le système d'exploitation ou l'hyperviseur d'un serveur cloud était compromis, un administrateur privilégié pourrait tenter d'inspecter les éléments cryptographiques stockés en mémoire système (RAM).

Google atténue ce risque en exécutant ses nœuds de signature MPC dans Google Cloud Confidential Space, un environnement d'exécution fiable (TEE) soutenu par du matériel de calcul confidentiel :

Chiffrement matériel de la mémoire : Confidential Space utilise le chiffrement de mémoire au niveau du processeur (tel qu'AMD SEV-SNP), garantissant que les parts de clé et les calculs intermédiaires de signature restent chiffrés en RAM à l'aide de clés matérielles inaccessibles au système d'exploitation hôte.

Attestation cryptographique : Avant qu'une part de clé ne soit accessible ou qu'un cycle de signature ne commence, l'enclave génère un jeton d'attestation ancré dans le matériel, vérifiant le hachage cryptographique exact de l'image du conteneur et de la base de firmware. Si l'image logicielle a été modifiée d'une quelconque manière, la vérification d'attestation échoue et le processus de signature est bloqué.

Accès administratif restreint : Confidential Space applique une isolation stricte des charges de travail qui supprime l'accès root standard ou les capacités de débogage interactif, empêchant même les administrateurs d'infrastructure cloud de consulter les données à l'intérieur d'un enclave actif.

Application de la politique de transaction et mécanismes de rafraîchissement des clés partagées

Protéger les parts de clé contre l'extraction ne résout qu'une partie du défi de la garde. En pratique, de nombreux incidents de sécurité institutionnels proviennent de crédentiels API compromis, d'attaques d'hameçonnage ou d'approbations internes non autorisées qui trompent des systèmes valides pour signer des transactions malveillantes.

Moteurs de vérification de politique de pré-signature

Pour se prémunir contre les transferts non autorisés au niveau de la couche application, Google Cloud intègre un moteur de vérification de politique déterministe directement au sein de l'enclave Confidential Space. Avant que le nœud MPC de Google ne participe à une session de signature seuil, la charge utile de la transaction proposée est vérifiée à l'aide des règles de gouvernance définies par l'institution — telles que les adresses de destination autorisées, les limites de valeur maximale des transactions, les plafonds de vitesse, les fenêtres horaires et les signatures de quorum à plusieurs approbateurs.

Si un terminal endpoint compromis tente de demander un transfert vers une adresse non approuvée ou au-delà des seuils autorisés, l'enclave rejette la demande de signature avant tout calcul de part cryptographique.

Partage secret proactif (actualisation des parts de clé)

Pour réduire le risque qu'un attaquant sophistiqué compromette progressivement plusieurs nœuds sur une longue période, l'architecture prend en charge le partage secret proactif (PSS), également connu sous le nom de rotation ou rafraîchissement des clés partagées.

Sur une base planifiée ou suite à des changements de personnel, les nœuds participants exécutent un protocole de rafraîchissement mathématique :

Les nœuds calculent collectivement un tout nouveau jeu de parts cryptographiques.

Les anciennes parts de clé sont définitivement invalidées et écrasées.

La clé publique maîtresse sous-jacente et l'adresse wallet sur chaîne restent complètement inchangées.

Cela signifie que même si un attaquant parvenait à voler une seule part de clé en un mois, ce fragment devient inutile dès la prochaine actualisation planifiée des parts — permettant aux institutions de renouveler régulièrement leur matériel de sécurité sous-jacent sans avoir à déplacer les fonds vers une nouvelle adresse blockchain ni payer des frais de gaz sur la chaîne.

Agilité post-quantique et préparation commerciale pour 2027

Alors que les institutions financières évaluent les infrastructures de garde avec des horizons pluriannuels, l'agilité cryptographique à long terme, y compris la préparation à l'informatique quantique, est devenue une considération architecturale importante. Les schémas standards de courbes elliptiques (secp256k1 et Ed25519) reposent sur des problèmes mathématiques qui pourraient éventuellement être vulnérables à des ordinateurs quantiques suffisamment puissants et tolérants aux pannes.

Alors que le déploiement initial de MPC de Google Cloud se concentre sur la résolution de menaces opérationnelles immédiates, telles que le vol d'identifiants, les points uniques de défaillance et la collusion interne, la plateforme est conçue avec une modularité cryptographique à l'esprit. En séparant les couches d'orchestration des politiques et d'API des primitives de signature sous-jacentes, l'architecture est structurée pour intégrer ultérieurement la cryptographie post-quantique (PQC) et les normes de transport résistantes aux quantiques, dès que les réseaux blockchain et les organismes internationaux de normalisation (tels que le NIST) finaliseront les spécifications de signatures post-quantiques.

Conclusion

Le déploiement par Google Cloud de l'infrastructure Multi-Party Compute institutionnelle met en lumière la maturation continue de la sécurité des actifs numériques en entreprise. En combinant le protocole de signature seuil DKLs23 avec des enclaves Confidential Space attestées par matériel et une répartition hétérogène des clés 2 sur 3, la plateforme aide les institutions financières à atténuer les vulnérabilités liées aux clés à point unique sans sacrifier la vitesse de signature ni la flexibilité multi-chaîne. Alors que le service se dirige vers une disponibilité commerciale en 2027, le MPC intégré au cloud est appelé à jouer un rôle croissant dans la sécurisation à grande échelle des actifs tokenisés par les banques et les gestionnaires d'actifs.

FAQ

Qu'est-ce que Google Cloud Multi-Party Compute ?

Google Cloud Multi-Party Compute (MPC) est une plateforme d'infrastructure de gestion et de signature de clés pour actifs numériques institutionnels actuellement en prévisualisation privée avant un lancement commercial prévu au début de l'année 2027. Elle utilise la cryptographie à seuil pour répartir le contrôle des clés privées entre des environnements distincts, éliminant ainsi les points uniques de défaillance lors de la signature de transactions sur la blockchain.

Pourquoi Google cible-t-il la disponibilité commerciale en 2027 ?

La mise en œuvre d'une prévisualisation privée sur invitation à la fin de 2026 permet aux banques partenaires et aux gestionnaires d'actifs institutionnels de réaliser des audits de sécurité, l'intégration de politiques et des tests de conformité. L'objectif de disponibilité générale au début de 2027 s'aligne sur l'adoption croissante par les institutions dans le cadre de réglementations matures, telles que le régime MiCA de l'UE et les normes en évolution du Comité de Bâle sur les expositions des banques aux actifs cryptographiques.

Comment le MPC de Google diffère-t-il du multi-sig sur chaîne ?

Les contrats intelligents multi-signatures sur chaîne vérifient plusieurs signatures distinctes directement sur une blockchain, ce qui augmente les coûts de gaz, expose publiquement les structures d'approbation et nécessite un support de contrat intelligent spécifique à la chaîne. L'MPC de Google effectue l'approbation multipartite et les calculs de seuil hors chaîne en utilisant le protocole DKLs23 renforcé, produisant une seule signature standard fonctionnelle sur différentes blockchains, avec des frais réduits et des règles de gouvernance privées.

La technologie MPC élimine-t-elle tous les risques de custody en crypto ?

Aucune architecture de sécurité ne peut éliminer tous les risques. Bien que MPC élimine le point unique de défaillance lié au stockage d'une clé privée complète en un seul endroit, les institutions doivent toujours se protéger contre le phishing, la compromission des points d'accès et une gouvernance interne défaillante. La conception de Google permet de réduire ces risques opérationnels en combinant des parts de clé réparties de manière hétérogène avec des enclaves Confidential Space isolées matériellement et des vérifications de politique de pré-signature.

Avertissement

Ces informations générales sur le marché, provenant éventuellement de sources tierces, commerciales ou sponsorisées, sont fournies à titre de référence et éducatif uniquement et ne constituent ni un conseil financier ni un conseil en investissement, ni une offre, une sollicitation ou une garantie. Nous déclinons toute responsabilité quant à leur exactitude, intégralité, fiabilité et aux pertes résultantes. Les investissements/le trading comportent des risques ; les performances passées ne garantissent pas les résultats futurs. Les utilisateurs doivent effectuer leurs propres recherches, juger avec prudence et assumer pleine responsabilité. Pour plus de détails, veuillez consulter les Conditions d'utilisation et les Divulgation des risques de KuCoin.

Avertissement : Pour votre confort, cette page a été traduite à l'aide de la technologie IA. Pour obtenir les informations à la source, consultez la version anglaise originale.