Architecture de calcul multipartite

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.

Google Cloud Le calcul multipartite fournit une infrastructure de confiance cryptographique pour les opérations institutionnelles sur les actifs numériques. Il utilise une architecture mutualisée : chaque instance que vous créez est un environnement dédié et isolé, avec sa propre entrée réseau, son propre stockage et son propre calcul isolé au niveau matériel pour les opérations cryptographiques.

Composants principaux

Chaque instance de calcul multipartite comporte trois composants principaux. La logique de gouvernance, le routage des requêtes et les calculs cryptographiques s'exécutent dans des composants distincts.

API MPC

L'API Multi-party Compute gère les ressources suivantes :

• Utilisateurs et équipes : identités qui détiennent des rôles dans l'instance et groupes de signataires auxquels les règles de clé font référence.
• Trousseaux de clés et règles de clé : les trousseaux de clés qui regroupent les clés, chacun avec la règle de clé qui détermine quelles équipes et quels utilisateurs détiennent des parts de clé et combien d'entre eux doivent approuver une signature.
• TransactionPolicies : règles Cedar qui autorisent ou interdisent les transactions, et approbations des auteurs de règles qui les activent ou les désactivent.
• KeyLists : listes d'adresses nommées auxquelles les règles de transaction peuvent faire référence.

L'API Multi-party Compute suit l'état de chaque transaction et les approbations enregistrées, et demande au coordinateur d'orchestrer la génération et la signature des clés. Spanner stocke les requêtes et les approbations signées. Les TEE de nœuds de calcul vérifient eux-mêmes les signatures d'approbation avant d'agir en conséquence.

Coordinateur

L'API Multi-party Compute connecte le contrôleur aux TEE des participants :

• Découverte des partages de clés et routage des requêtes : il attribue des TEE opérationnels pour stocker les nouveaux partages de clés lors de la génération des clés, puis achemine la requête vers les TEE appropriés.
• État : il surveille l'état des TEE des participants et sert d'équilibreur de charge pour les requêtes de signature.
• Durabilité : il gère le repartage lorsqu'un partage de clé doit être remplacé.

Le coordinateur n'affecte pas la sécurité du protocole. Il ne détient aucune part de clé et ne vérifie pas les approbations ni les résultats des règles. Cette vérification s'effectue dans les TEE des participants.

TEE de nœud de calcul

Chaque nœud de calcul est un TEE qui s'exécute sur Confidential Space. Un TEE de nœud de calcul exécute deux parties :

• Moteur cryptographique : contient les parts de clé et exécute les protocoles de génération et de signature de clés à seuil sécurisé avec les autres TEE de nœud de calcul.
• Évaluateur de règles : évalue les transactions par rapport à l'ensemble actif de règles de transaction.

Flux de signature de transaction

Dans Multi-party Compute, vous signez une charge utile avec un seul appel d'API, CreateTransaction. L'évaluation des règles de transaction, les approbations des signataires et la signature de seuil commencent toutes par cet appel. Voici le flux dans un ordre fixe :

1. Requête Un signataire appelle CreateTransaction sur une clé. La requête comporte l'approbation du signataire, signée avec sa clé d'autorisation. IAM vérifie que l'appelant peut appeler la méthode, et la requête est enregistrée dans Cloud Audit Logs.
2. Évaluation des règles. La transaction est évaluée par rapport à l'ensemble actif de règles de transaction. L'évaluation de la stratégie génère un journal d'audit durable pour chaque verdict, APPROVED ou REJECTED.
3. Approbation de l'initiateur. Si l'approbation de l'initiateur suffit à atteindre les seuils de la règle de clé, CreateTransaction passe immédiatement à l'étape 5.
4. Approbations des signataires. Si l'approbation de l'initiateur ne suffit pas à atteindre les seuils de la règle de clé, la transaction passe à l'état PENDING_AUTHORIZATION. Les autres signataires qui détiennent des parts de la clé approuvent ou refusent la transaction à l'aide de l'appel RecordSignerDecision, chacun signé avec leur clé d'autorisation. La transaction attend à l'état PENDING_AUTHORIZATION jusqu'à ce qu'un nombre suffisant de signataires l'approuvent pour atteindre les seuils de la règle de clé. Si un nombre suffisant de signataires la refusent, de sorte que les seuils ne peuvent plus être atteints, la transaction passe à l'état REJECTED. Si elle n'obtient pas suffisamment d'approbations avant son expiration, elle est EXPIRED.

5. Signature par seuil Lorsque les seuils sont atteints, les environnements d'exécution sécurisés (TEE) qui détiennent les parts de la clé exécutent le protocole de signature de seuil et produisent la signature sur la transaction.

   Avant qu'un TEE participant n'utilise sa part de clé, il vérifie que la charge utile exacte qu'il est invité à signer a été évaluée par rapport à vos règles de transaction. Aucun client, opérateur ou autre composant de service ne peut faire signer à un participant une charge utile qui n'a pas été évaluée.

Pour en savoir plus sur les ressources impliquées, telles que les utilisateurs, les équipes, les trousseaux de clés et les règles de transaction, consultez la présentation du calcul multipartite.

Modèle de sécurité

• Quotes-parts de clés épinglées à leur TEE. Chaque partage de clé ne peut être lu que par l'ET de confiance qui l'a créé. Les parts de clé ne quittent jamais ce TEE sous une forme lisible par un autre composant, y compris le coordinateur, le contrôleur ou un opérateur Google.
• Conservation des clés client. Le client conserve à tout moment la garde complète de ses clés de chiffrement en utilisant Cloud Key Management Service dans l'organisation Google Cloud du client.
• Isolation matérielle. Les TEE des participants s'exécutent sur Confidential Space, qui utilise le chiffrement de la mémoire matérielle pour protéger les données utilisées contre l'hôte et l'infrastructure Google. L'attestation lie chaque TEE à une image de conteneur validée.
• Chiffrement de bout en bout. Les TEE de nœud de calcul communiquent directement via gRPC chiffré de bout en bout.
• Approbations signées. Les signataires, les auteurs de règles et les administrateurs signent leurs approbations avec une clé d'autorisation dont la moitié privée ne les quitte jamais. Les TEE des participants vérifient ces signatures avant de signer une transaction, d'accepter une règle de transaction ou d'accepter un changement de rôle d'administrateur ou d'auteur de règle. Cela rend les transactions inviolables et laisse un journal d'audit durable.
• Quorum d'auteurs de règles. Une nouvelle règle de transaction, ou une demande de désactivation d'une règle, ne prend effet qu'une fois qu'elle a été approuvée par le nombre requis d'auteurs de règles.
• Quorum d'administration L'attribution ou la suppression du rôle d'administrateur ou d'auteur de règles ne prend effet qu'une fois que le nombre requis d'administrateurs l'a approuvée. Pour en savoir plus, consultez Approbation par l'administrateur des modifications de rôle.

Feuille de route

Les fonctionnalités suivantes sont prévues pour les prochaines versions :

• TEE externes : parts de clé détenues dans des TEE que les clients exécutent en dehors de Google Cloud, comme AWS Nitro Enclaves.
• Partages de clés mobiles : partages de clés détenus sur les appareils mobiles des utilisateurs.
• Repartage : modification des détenteurs des parts d'une clé existante ou remplacement d'une part perdue, sans modifier la clé.

Propriétés système

L'infrastructure de confiance de calcul multipartite conserve les propriétés système suivantes.

Sécurité (solidité dans un contexte cryptographique)

En toutes circonstances, le système ne doit pas se comporter de manière non autorisée. Par exemple, aucun groupe de moins de k participants ne peut falsifier des signatures, en vertu du protocole DKLS23. Les définitions de sécurité exactes sont formalisées dans le framework Universal Composable de la documentation.

Lorsqu'un système cryptographique est intégré à une implémentation pratique, il convient de ne pas s'appuyer sur des hypothèses qui compromettent les propriétés de sécurité. Par exemple, chaque partie du protocole doit être indépendante : sa vulnérabilité aux compromissions doit être indépendante.

Pour garantir cette propriété, le calcul multipartite exécute chaque participant dans un TEE attesté, et chaque partage de clé est épinglé au TEE qui l'a créé. La compromission d'un participant au protocole n'affecte pas les autres participants.

La littérature universitaire sur le calcul multipartite se concentre presque exclusivement sur la solidité et suppose un monde simpliste dans lequel l'ensemble des parties est immuable, toutes les parties sont toujours disponibles et les parties communiquent à l'aide de canaux authentifiés point à point idéaux et toujours disponibles. Pour un produit réel, plusieurs autres points doivent être pris en compte.

Activité

Le système finit par progresser. La propriété de vivacité la plus courante est l'absence d'interblocage, qui est respectée dans le protocole DKLS23. Une clé de seuil peut être utilisée pour la signature tant qu'un nombre suffisant de TEE contenant ses parts sont disponibles pour respecter les seuils de la règle de clé. Par exemple, avec une clé 2 sur 3, deux des trois parts peuvent effectuer une signature.

Durabilité

Les parties qui échouent définitivement doivent être remplacées, sinon le système finit par perdre définitivement le secret partagé. Par exemple, en cas de défaillance matérielle, l'état du participant exécuté sur ce matériel est perdu. Étant donné que les parts de clé sont épinglées à leurs TEE, le coordinateur suit les TEE qui détiennent les parts de chaque clé. Dans la version v1beta, une clé reste utilisable tant qu'il reste suffisamment de parts pour respecter les seuils de la stratégie de clé. Le remplacement d'un partage perdu nécessite un nouveau partage, qui est prévu pour une version ultérieure.

Modifications de configuration

Les défaillances matérielles (un TEE perd des données) et les changements organisationnels (une nouvelle recrue rejoint le protocole avec une part de la clé secrète) nécessitent de modifier les détenteurs des parts d'une clé. Le calcul multipartite prévoit de prendre en charge cette fonctionnalité avec un protocole de repartage sécurisé qui préserve les propriétés de solidité de DKLS23 : une nouvelle partie malveillante qui s'engage dans le repartage ne divulgue au maximum qu'une partie du secret, comme toute autre partie malveillante.