Multi-party Compute est une plate-forme de conservation Google Cloud pour les clés de signature des ressources numériques. Il combine la signature de seuil, l'application de règles de transaction et des contrôles de gouvernance d'entreprise.
Pourquoi utiliser la signature à seuil ?
Dans la conservation institutionnelle des ressources numériques, une clé de signature privée contrôle directement le mouvement des ressources. La protection des clés de signature nécessite d'atténuer trois risques opérationnels et de sécurité distincts :
- Solidité cryptographique : le vol de clé ou l'utilisation non autorisée permet à un pirate informatique de signer des transactions frauduleuses, ce qui entraîne une perte d'éléments irréversible.
- Disponibilité : les pannes temporaires ou l'inaccessibilité de l'infrastructure de signature interrompent le règlement des transactions et les opérations de liquidité.
- Durabilité : la perte ou la corruption permanente d'un matériel de clé rend les ressources numériques associées irrécupérables.
La gestion centralisée des clés impose un compromis entre sécurité et résilience opérationnelle. Le stockage d'une clé privée complète dans un seul module de sécurité matériel (HSM) crée un point de défaillance unique pour la disponibilité, la durabilité et la fiabilité cryptographique. La réplication de cette clé sur plusieurs HSM ou régions améliore la disponibilité et la durabilité, mais elle élargit la surface d'attaque. Étant donné que chaque instance répliquée contient la clé complète, chaque copie introduit un autre point de compromission unique.
Le calcul multipartite résout ce compromis en utilisant des schémas de signature à seuil, y compris une extension renforcée du protocole DKLS23. Des parties indépendantes, intégrées au matériel, génèrent et détiennent chacune un partage de clé isolé. Lors de la signature, ces parties exécutent un protocole multipartite pour produire une signature valide sans assembler la clé privée complète à un seul emplacement. Un pirate informatique qui compromet moins de parties que le seuil de signature ne peut pas falsifier une signature ni reconstruire la clé. En même temps, les opérations de signature se poursuivent même si des parties individuelles sont indisponibles ou échouent définitivement, à condition qu'il reste suffisamment de parties pour atteindre le seuil. Pour en savoir plus sur le protocole, consultez Contexte cryptographique DKLS23.
Blockchains compatibles
Le calcul multipartite est compatible avec les algorithmes de clé suivants :
| Algorithme | Courbe | Chaînes types |
|---|---|---|
ECDSA (EC_SIGN_SECP256K1) |
secp256k1 | Chaînes compatibles avec Bitcoin, Ethereum et EVM |
EdDSA (EC_SIGN_ED25519) |
Ed25519 | Solana (bientôt disponible) |
Une fois qu'une clé distribuée est générée, le calcul multipartite renvoie sa clé publique et les adresses de blockchain qui en sont dérivées.
Contrôles à l'échelle de l'entreprise
Le calcul multipartite modélise votre organisation dans votre propre instance dédiée et isolée. Il décide qui détient les parts de clé, combien d'entre elles doivent approuver une signature et quelles règles sont appliquées à chaque transaction avant la signature.
Utilisateurs et rôles
Un utilisateur est une identité que vous intégrez à une instance. Chaque utilisateur est lié à un compte principal, soit un compte Google, soit un compte principal de la fédération des identités des employés. Chaque utilisateur dispose d'un ou de plusieurs rôles :
- Administrateur : administre les utilisateurs, les équipes et les autres ressources de l'instance.
- Auteur de règles : crée et approuve les règles de transaction.
- Signataire : détient des parts de clé et approuve les transactions.
Les signataires, les auteurs de règles et les administrateurs signent leurs approbations à l'aide d'une clé d'autorisation, dont la moitié privée ne quitte jamais la garde du client.
Au niveau de l'API, les rôles de calcul multipartite fonctionnent avec les rôles IAM. IAM contrôle les méthodes d'API qu'un compte principal peut appeler. Les rôles d'un utilisateur contrôlent ce que ce compte principal peut faire dans l'instance. Pour savoir comment les rôles IAM et les rôles utilisateur fonctionnent ensemble, consultez Sécurité et autorisation.
Équipes
Une équipe est un groupe de signataires, comme un service ou un ensemble de responsables. Chaque signataire appartient à une seule équipe. Les équipes permettent à une règle KeyPolicy de faire référence à des groupes de signataires, par exemple "générer des parts de clé pour trois membres de l'équipe Treasury et exiger que deux d'entre eux signent" au lieu de nommer chaque personne.
Règles MPC
KeyRings et KeyPolicies
Un KeyRing regroupe des clés. Lorsque vous créez un KeyRing, vous définissez sa KeyPolicy, qui définit pour chaque clé créée dans le KeyRing :
- quelles équipes et quels utilisateurs détiennent des parts de clé ;
- combien d'entre eux doivent participer à la signature (le seuil) ;
- où chaque partage de clé est stocké (Google Cloud, locaux du client ou appareils mobiles des utilisateurs).
Les clés ne peuvent pas être déplacées entre des trousseaux de clés ni supprimées. Vous pouvez uniquement désactiver une clé, ce qui l'empêche de signer à nouveau.
KeyLists
Une KeyList est une liste nommée d'adresses de blockchain auxquelles les règles de transaction peuvent faire référence, telles que des destinations de confiance. Une entrée est une clé existante, un trousseau de clés (y compris les clés qui y sont ajoutées ultérieurement) ou une adresse que vous saisissez manuellement.
Stratégies de transaction
Une règle de transaction est une règle Cedar qui autorise ou interdit les transactions dans le calcul multipartite, par exemple une limite de dépense ou une liste d'autorisation de destinations. Ensemble, les stratégies actives produisent un verdict, une autorisation ou un refus pour chaque transaction. Le verdict guide les signataires, mais n'impose pas la décision finale : une transaction refusée par les règles de transaction automatisées peut toujours être exécutée si un nombre suffisant de signataires l'approuvent.
Pour savoir comment les règles sont écrites et combinées, consultez Rédiger des règles de stratégie de transaction et Évaluation des stratégies de transaction.