Architektur für Multi-Party Compute

Google Cloud Multi-Party Compute bietet eine kryptografische Vertrauensinfrastruktur für institutionelle digitale Asset-Vorgänge. Es wird eine Multi-Single-Tenant-Architektur verwendet: Jede von Ihnen erstellte Instanz ist eine dedizierte, isolierte Umgebung mit eigenem Netzwerk-Ingress, eigenem Speicher und eigener hardwareisolierter Rechenleistung für kryptografische Vorgänge.

Kernkomponenten

Architekturdiagramm für Multi-Party Computation

Jede Multi-Party-Compute-Instanz hat drei Hauptkomponenten. Governance-Logik, Anfrage-Routing und kryptografische Berechnungen werden in separaten Komponenten ausgeführt.

MPC API

Die Multi-Party Compute API verwaltet die folgenden Ressourcen:

  • Nutzer und Teams: Die Identitäten, die Rollen in der Instanz haben, und die Gruppen von Signierern, auf die sich Schlüsselrichtlinien beziehen.
  • Schlüsselbunde und Schlüsselrichtlinien: Die Schlüsselbunde, die Schlüssel gruppieren, jeweils mit der Schlüsselrichtlinie, die festlegt, welche Teams und Nutzer Schlüsselanteile haben und wie viele von ihnen eine Signatur genehmigen müssen.
  • TransactionPolicies: die Cedar-Regeln, die Transaktionen zulassen oder verbieten, und die Genehmigungen des Richtlinienautors, die sie aktivieren oder deaktivieren.
  • KeyLists: Die benannten Listen von Adressen, auf die sich Transaktionsrichtlinien beziehen können.

Die Multi-Party-Compute API verfolgt den Status jeder Transaktion und die dafür aufgezeichneten Genehmigungen und fordert den Koordinator auf, die Schlüsselgenerierung und ‑signierung zu orchestrieren. Spanner speichert Anfragen und die signierten Genehmigungen. Worker-TEEs prüfen die Genehmigungssignaturen selbst, bevor sie darauf reagieren.

Koordinator

Die Multi-Party Compute API verbindet den Controller mit den TEEs der Teilnehmer:

  • Erkennung von Schlüsselfreigaben und Anfrage-Routing: Es werden fehlerfreie TEEs zugewiesen, um neue Schlüsselfreigaben während der Schlüsselgenerierung zu speichern. Später wird die Anfrage an die entsprechenden TEEs weitergeleitet.
  • Zustand: Überwacht den Zustand der TEEs der Teilnehmer und fungiert als Load Balancer für die Signaturanfragen.
  • Langlebigkeit: Es verwaltet die erneute Freigabe, wenn eine Schlüsselfreigabe ersetzt werden muss.

Der Koordinator hat keinen Einfluss auf die Sicherheit des Protokolls. Es enthält keine Schlüsselfreigaben und überprüft keine Genehmigungen oder Richtlinienergebnisse. Diese Überprüfung erfolgt in den TEEs der Teilnehmer.

Worker-TEEs

Jeder Worker ist eine TEE, die in Confidential Space ausgeführt wird. In einer Worker-TEE werden zwei Teile ausgeführt:

  • Kryptografische Engine: Enthält Schlüsselfragmente und führt die sicheren Protokolle zur Generierung und Signierung von Schwellenwertschlüsseln mit den anderen Worker-TEEs aus.
  • Richtlinienbewerter: Bewertet Transaktionen anhand der aktiven Transaktionsrichtlinien.

Ablauf der Transaktionssignierung

In Multi-Party Compute signieren Sie eine Nutzlast mit einem einzigen API-Aufruf, CreateTransaction. Die Auswertung der Transaktionsrichtlinie, die Genehmigungen der Unterzeichner und die Schwellenwertsignierung beginnen alle mit diesem Aufruf. Hier ist der Ablauf in einer festen Reihenfolge:

  1. Anfrage Ein Signer ruft CreateTransaction für einen Schlüssel auf. Die Anfrage enthält die eigene Genehmigung des Signierers, die mit seinem Autorisierungsschlüssel signiert ist. IAM prüft, ob der Aufrufer die Methode aufrufen kann, und die Anfrage wird in Cloud-Audit-Logs aufgezeichnet.
  2. Richtlinienbewertung. Die Transaktion wird anhand der aktiven Transaktionsrichtlinien bewertet. Bei der Richtlinienbewertung wird für jedes Ergebnis (APPROVED oder REJECTED) ein dauerhaftes Audit-Log erstellt.
  3. Genehmigung durch den Initiator: Wenn die Genehmigung des Initiators allein die Schwellenwerte der Schlüsselrichtlinie erfüllt, geht CreateTransaction sofort zu Schritt 5 über.
  4. Genehmigungen von Unterzeichnern: Wenn die Genehmigung des Initiators allein nicht die Grenzwerte der Schlüsselrichtlinie erfüllt, wechselt die Transaktion in den Status PENDING_AUTHORIZATION. Andere Signierer, die Schlüsselfreigaben des Schlüssels haben, genehmigen oder lehnen die Transaktion mit dem Aufruf RecordSignerDecision ab, der jeweils mit ihrem Autorisierungsschlüssel signiert ist. Die Transaktion wartet im Status PENDING_AUTHORIZATION, bis genügend Signierer zustimmen, um die Schwellenwerte der Schlüsselrichtlinie zu erfüllen. Wenn so viele Signer die Transaktion ablehnen, dass die Schwellenwerte nicht mehr erreicht werden können, wird die Transaktion in den Status REJECTED versetzt. Wenn sie vor Ablauf der Frist nicht genügend Genehmigungen erhält, wird sie EXPIRED.

  5. Schwellenwertsignierung Wenn die Schwellenwerte erreicht sind, führen die vertrauenswürdigen Ausführungsumgebungen (TEEs), die die Schlüsselanteile enthalten, das Schwellenwert-Signaturprotokoll aus und erstellen die Signatur für die Transaktion.

    Bevor eine TEE eines Teilnehmers ihre Schlüsselfreigabe verwendet, prüft sie, ob die genaue Nutzlast, die sie signieren soll, anhand Ihrer Transaktionsrichtlinien ausgewertet wurde. Kein Client, Operator oder andere Dienstkomponente kann einen Teilnehmer dazu bringen, eine Nutzlast zu signieren, die nicht ausgewertet wurde.

Informationen zu den beteiligten Ressourcen wie Nutzern, Teams, Schlüsselbunden und Transaktionsrichtlinien finden Sie in der Übersicht über Multi-Party Computation.

Sicherheitsmodell

  • Schlüsselfreigaben, die an ihre TEE angepinnt sind. Jeder Schlüsselfreigabe kann nur von der TEE gelesen werden, die sie erstellt hat. Schlüsselfreigaben verlassen diese TEE nie in einer Form, die von einer anderen Komponente, einschließlich des Koordinators, des Controllers oder eines Google-Operators, gelesen werden kann.
  • Verwahrung von Kundenschlüsseln. Der Kunde behält jederzeit die volle Kontrolle über seine Verschlüsselungsschlüssel, indem er den Cloud Key Management Service in der Google Cloud -Organisation des Kunden verwendet.
  • Hardware-Isolation. Die TEEs der Teilnehmer werden in Confidential Space ausgeführt. Dort wird die hardwarebasierte Arbeitsspeicherverschlüsselung verwendet, um aktive Daten vor dem Host und der Google-Infrastruktur zu schützen. Durch die Attestierung wird jede TEE an ein verifiziertes Container-Image gebunden.
  • Ende-zu-Ende-Verschlüsselung Die Worker-TEEs kommunizieren direkt über Ende-zu-Ende-verschlüsseltes gRPC.
  • Unterzeichnete Genehmigungen: Signierer, Richtlinienautoren und Administratoren signieren ihre Genehmigungen mit einem Autorisierungsschlüssel, dessen private Hälfte sie nie verlässt. Die TEEs der Teilnehmer überprüfen diese Signaturen, bevor sie eine Transaktion signieren, eine Transaktionsrichtlinie akzeptieren oder eine Änderung der Rolle „Administrator“ oder „Richtlinienautor“ akzeptieren. Dadurch sind die Transaktionen manipulationssicher und es wird ein dauerhaftes Audit-Log erstellt.
  • Quorum für Richtlinienautoren. Eine neue Transaktionsrichtlinie oder eine Anfrage zum Deaktivieren einer Richtlinie wird erst wirksam, wenn die erforderliche Anzahl von Richtlinienautoren sie genehmigt hat.
  • Administrator-Quorum. Das Zuweisen oder Entfernen der Rolle „Administrator“ oder „Richtlinienautor“ wird erst wirksam, wenn die erforderliche Anzahl von Administratoren die Änderung genehmigt hat. Weitere Informationen finden Sie unter Administratorgenehmigung für Rollenänderungen.

Roadmap

Die folgenden Funktionen sind für spätere Releases geplant:

  • Externe TEEs: Schlüsselfreigaben, die in TEEs gespeichert sind, die Kunden außerhalb von Google Cloudausführen, z. B. AWS Nitro Enclaves.
  • Mobile Schlüsselfreigaben: Schlüsselfreigaben auf den Mobilgeräten der Nutzer.
  • Erneutes Teilen: Ändern der Inhaber der Anteile eines vorhandenen Schlüssels oder Ersetzen eines verlorenen Anteils, ohne den Schlüssel zu ändern.

Systemeigenschaften

Die Trust-Infrastruktur für die Multi-Party Computation hat die folgenden Systemeigenschaften.

Sicherheit (Korrektheit in einem kryptografischen Kontext)

Das System darf sich unter keinen Umständen auf unzulässige Weise verhalten. Beispielsweise kann keine Gruppe von weniger als k Teilnehmern aufgrund des DKLS23-Protokolls Signaturen fälschen. Die genauen Sicherheitsdefinitionen sind im Universal Composable-Framework in der Literatur formalisiert.

Wenn ein kryptografisches System in einer praktischen Implementierung umgesetzt wird, muss darauf geachtet werden, dass keine Annahmen getroffen werden, die die Sicherheitseigenschaften beeinträchtigen. Beispielsweise muss jede Partei im Protokoll unabhängig sein: Ihre Anfälligkeit für Kompromittierungen sollte unabhängig sein.

Um diese Eigenschaft zu gewährleisten, wird bei der Multi-Party Computation jeder Teilnehmer in einer beglaubigten TEE ausgeführt und jeder Schlüsselfragment wird an die TEE gebunden, die ihn erstellt hat. Die Kompromittierung eines Teilnehmers im Protokoll hat keine Auswirkungen auf die anderen Teilnehmer.

In der wissenschaftlichen Literatur zur Multi-Party Computation wird fast ausschließlich die Korrektheit betrachtet. Dabei wird von einer vereinfachten Welt ausgegangen, in der die Gruppe der Parteien unveränderlich ist, alle Parteien immer verfügbar sind und die Parteien über ideale und immer verfügbare authentifizierte Punkt-zu-Punkt-Kanäle kommunizieren. Bei einem realen Produkt müssen mehrere zusätzliche Aspekte berücksichtigt werden.

Aktivität

Das System macht schließlich Fortschritte. Die banalste Lebendigkeitseigenschaft ist das Fehlen von Deadlocks, was im DKLS23-Protokoll der Fall ist. Ein Schwellenwertschlüssel kann zum Signieren verwendet werden, solange genügend TEEs, die seine Anteile enthalten, verfügbar sind, um die Schwellenwerte der Schlüsselrichtlinie zu erfüllen. Bei einem 2-von-3-Schlüssel können beispielsweise zwei der drei Anteile eine Signatur erstellen.

Langlebigkeit

Parteien, die dauerhaft ausfallen, müssen ersetzt werden, da das System sonst irgendwann das gemeinsame Secret dauerhaft verliert. Wenn beispielsweise die Hardware ausfällt, geht der Status des Teilnehmers verloren, der auf dieser Hardware ausgeführt wird. Da Schlüsselfreigaben an ihre TEEs gebunden sind, verfolgt der Koordinator, welche TEEs die Freigaben der einzelnen Schlüssel enthalten. In v1beta bleibt ein Schlüssel verwendbar, solange genügend Freigaben vorhanden sind, um die Schwellenwerte der Schlüsselrichtlinie zu erfüllen. Wenn Sie eine verlorene Freigabe ersetzen möchten, müssen Sie sie noch einmal freigeben. Dies ist für eine spätere Version geplant.

Konfigurationsänderungen

Sowohl Hardwarefehler (ein TEE verliert Daten) als auch organisatorische Änderungen (ein neuer Mitarbeiter tritt dem Protokoll mit einem Teil des geheimen Schlüssels bei) erfordern eine Änderung der Inhaber der Schlüsselanteile. Multi-Party Computation soll dies mit einem sicheren Protokoll für die erneute Freigabe unterstützen, das die Integritätseigenschaften von DKLS23 beibehält: Eine böswillige neue Partei, die an der erneuten Freigabe beteiligt ist, gibt höchstens einen Teil des Geheimnisses preis, genau wie jede andere böswillige Partei.