Google veut devenir le coffre-fort des cryptomonnaies bancaires

Google développe une solution de conservation de cryptomonnaies pour les banques et l'a présentée publiquement mercredi. Lors de son premier symposium sur les actifs numériques à New York, Google Cloud a présenté Google Multi-Party Compute (MPC), un service permettant de stocker et de transférer des cryptomonnaies et des actifs tokenisés sans qu'aucune machine ne détienne l'intégralité de la clé privée, comme l'a rapporté CoinDesk. Le service est actuellement en phase de test privée. Son lancement commercial est prévu pour début 2027 et son prix n'a pas encore été communiqué.

La nouvelle s'est répandue sur X le même jour, Scott Melker la publiant comme une information « DERNIÈRE MINUTE ».

Qui teste cette solution ? Google reste muet. Plusieurs partenaires de conception et grandes institutions financières participent à la version préliminaire, sans être nommés. Le seul utilisateur confirmé est Alphabet, qui a commencé à sécuriser ses propres actifs numériques sur Ethereum et Solana grâce à ce système. La nature et le montant de ces actifs restent confidentiels. Rich Widmann, directeur de la stratégie des actifs numériques chez Google Cloud, a déclaré à CoinDesk que les banques qui adoptent la blockchain « ont besoin d’une infrastructure évolutive et éprouvée pour sécuriser les actifs de leurs clients ».

Un produit, pas un kit de bricolage

Le MPC en lui-même n'est pas nouveau. Il s'agit de diviser une clé privée en fragments, de les répartir sur différents systèmes, et ainsi, aucune défaillance unique ne compromet la sécurité des fonds. Google a même publié un guide en 2023 expliquant comment implémenter ce système sur son infrastructure Confidential Space. La nouveauté réside dans le fait que Google propose désormais une solution clé en main. L'entreprise a indiqué à CoinDesk n'avoir jamais proposé de produit de conservation MPC dédié aux cryptomonnaies. Jusqu'à présent, les banques utilisant Google Cloud bénéficiaient du service de gestion de clés et du Cloud HSM, et devaient ensuite gérer elles-mêmes la signature, les politiques et la récupération des actifs.

Prenons l'exemple de CoinDesk : une banque conserve une part de clé sur Google Cloud, une autre sur son propre serveur et la dernière chez un fournisseur de cloud concurrent. Lorsqu'elle souhaite transférer des fonds, la transaction transite par un espace confidentiel, un environnement matériellement isolé, où un moteur de règles la vérifie par rapport aux règles de la banque avant toute signature. Ces règles peuvent plafonner les montants, restreindre les portefeuilles de destination ou exiger l'approbation de plusieurs services. Les seuils sont configurables : 2 sur 3 ou 5 sur 7. Google affirme ne pas pouvoir lire les clés non chiffrées, même pour les parts stockées sur sa propre infrastructure.

Lors de sa mise à disposition générale, le service est conçu pour prendre en charge les signatures ECDSA et Ed25519. ECDSA est le protocole utilisé par la plupart des portefeuilles Bitcoin et Ethereum, et Ed25519 est celui de Solana.

Il existe également une documentation à ce sujet. Cointelegraph a rapporté que Google a mis à jour la documentation du service lundi, et les notes de version font état de modifications depuis août. Le 1er octobre, des règles Bitcoin ont été ajoutées concernant les montants des transactions, les types d'adresses de destination et les rendus de monnaie. Le produit est toujours en version préliminaire, ce qui signifie qu'il est proposé tel quel, avec un support potentiellement limité.

Un point reste obscur. Solana Compass a constaté que la documentation publique indique toujours que Solana sera bientôt disponible, tandis que Google a déclaré à CoinDesk qu'Alphabet exploitait déjà le système sur Solana. Google n'a pas expliqué cette incohérence.

Pourquoi les banques s'intéressent aux clés

Car c'est au niveau des clés que l'argent est volé. Selon les données de Chainalysis citées par CoinDesk, 43,8% des cryptomonnaies volées en 2024 étaient dues à des clés privées compromises. Les chiffres de DeFiLlama indiquent que les piratages et les exploits ont entraîné des pertes cumulées de 16,69 milliards de dollars en juin, dont environ 40% étaient liés à des compromissions de clés.

Le piratage du protocole Humanity en juin dernier en est un exemple flagrant. Le 9 juin, le fondateur Terence Kwok annonçait que les clés privées d'un membre de la Humanity Foundation avaient été compromises et conseillait aux utilisateurs de se tenir à l'écart du pont et des pools de liquidités. L'analyste Specter d'Onchain suivait déjà l'ampleur des pertes, qui dépassaient les 20 millions de dollars dans sa publication. CoinDesk estimait ensuite le total à plus de 32 millions de dollars, répartis sur au moins 17 portefeuilles, et le token H chutait de plus de 80%. Les chiffres n'ont jamais concordé : le bilan mensuel de PeckShield s'élevait à 31 millions de dollars, tandis que l'estimation de l'équipe atteignait environ 36 millions de dollars, selon The Block.

L'explication n'a pas convaincu tout le monde. ZachXBT a déclaré ne pas croire à la version de l'équipe et a suggéré qu'il pourrait s'agir d'un teneur de marché qui encaissait ses gains. Ce n'est qu'une hypothèse, pas une preuve.

Quoi qu'il en soit, c'est précisément le type de défaillance pour lequel Google affirme que MPC a été conçu : un seul identifiant volé ne devrait pas suffire à transférer des fonds. Selon l'analyse de CoinDesk, une vérification des règles avant la signature pourrait bloquer les transferts qui enfreignent les limites prédéfinies ou les règles d'approbation. Il est impossible de dire de l'extérieur si cela aurait changé quoi que ce soit dans un cas comme celui de Humanity.

Ce qu'il ne couvre pas

Google met également en avant la protection de son produit contre les attaques basées sur l'IA et l'informatique quantique. Ce point est important. CoinDesk souligne que les protections actuelles ciblent les identifiants volés et les transactions non autorisées, et non une faille dans le système cryptographique sous-jacent.

Cette distinction est cruciale ce mois-ci. Le 7 octobre, Justin Drake, chercheur à la Fondation Ethereum, a exhorté le secteur à se préparer à la mise en place d'un « mode bunker », terme qu'il emploie pour désigner le transfert de fonds vers des adresses n'ayant jamais divulgué de clé publique. Cette demande fait suite à la crainte que l'IA puisse déchiffrer les signatures protégeant les portefeuilles Bitcoin et Ethereum en quelques mois, et non en plusieurs années dans le pire des cas. CoinDesk a indiqué que la publication avait généré près de 4 millions de vues. Vitalik Buterin a conseillé de prendre le risque au sérieux, mais de ne pas se précipiter pour transférer des fonds, tandis que Samson Mow a appelé ses abonnés au calme. Aucun système d'IA n'a encore démontré sa capacité à casser ces signatures.

Google affirme que son architecture pourra intégrer des mises à jour post-quantiques ultérieurement sans que les banques aient à reconstruire leurs systèmes. Aucun calendrier n'a été communiqué.

Un marché bondé

Google s'aventure sur un marché déjà dominé par Fireblocks, Fordefi et BitGo. Selon CoinDesk, son argument de vente repose sur des relations privilégiées avec les banques, une expertise en sécurité et une neutralité qui permet aux banques de ne pas louer d'infrastructure auprès d'un concurrent ciblant la même clientèle.

La question n'est pas la demande. Selon crypto.news, UniCredit étudiait en septembre une infrastructure de conservation et de courtage d'actifs numériques, et Finance Magnates a rapporté que JPMorgan prévoyait d'accepter le Bitcoin et l'Ether comme garantie de prêt pour ses clients institutionnels, par l'intermédiaire d'un dépositaire tiers.

Les réserves sont toutefois bien réelles. Même avec une répartition des parts, les banques pourraient rester dépendantes de Google pour certaines parties du logiciel, les politiques de transaction et les opérations. La sécurité dépend de la manière dont une banque configure les approbations et des personnes autorisées à modifier les règles. Un signataire légitime trompé et amené à approuver un transfert frauduleux représente toujours un problème. De plus, Google n'a fourni aucune comparaison de performance vérifiée de manière indépendante avec les solutions de conservation existantes.

Je dirais que la cryptographie est l'aspect le plus facile à prendre en compte. La question plus complexe est de savoir si le comité de gestion des risques d'une banque souhaite une dépendance supplémentaire vis-à-vis de Google. Prochaines étapes à suivre : si une banque de test rend son témoignage officiel et quels sont les tarifs pratiqués par Google.