Institutionelle Bitcoin-Verwahrung in Google Cloud

Wenn Sie Bitcoin-Reserven von Institutionen schützen möchten, ohne einen Single Point of Compromise zu schaffen, können Sie Signaturschlüssel mithilfe von Google Cloud Multi-Party Computation auf hardwareisolierte Enklaven verteilen. In diesem Dokument werden Cloud Key Management Service (Cloud KMS) und Cloud HSM mit Multi-Party Computation verglichen, beide Sicherheitsmodelle für die Bitcoin-Verwahrung bewertet und eine Referenztopologie vorgestellt.

Wenn Sie die Bitcoin-Verwahrung in die Cloud verlagern, können Sie zwischen zwei Schlüsselverwaltungsarchitekturen wählen:

  • Hardwaresicherheitsmodule (HSMs) mit einem Schlüssel: Cloud KMS und Cloud HSM verwalten statische kryptografische Schlüssel innerhalb physischer HSM-Grenzen.
  • Verteilte Schwellenwertsignierung: Multi-Party Compute verteilt Schlüsselfreigaben auf hardwareisolierte vertrauenswürdige Ausführungsumgebungen (Trusted Execution Environments, TEEs), die durch HSM-Root-of-Trust-Schlüssel gesichert sind.

Cloud KMS und Cloud HSM unterstützen die Umschlagverschlüsselung für Unternehmen und die Web-Public-Key-Infrastruktur. Sie wurden jedoch nicht für Bitcoin-Verwaltungsprimitive wie die hierarchisch deterministische (HD) Schlüsselableitung gemäß Bitcoin Improvement Proposal 32 (BIP32), BIP340-Schnorr-Signaturen und die granulare Multi-Party-Governance entwickelt.

Wichtige Herausforderungen bei der cloudbasierten Bitcoin-Verwahrung

In der folgenden Tabelle sind drei primäre Herausforderungen zusammengefasst, die bei der Bewertung von Standard-Cloud-Schlüsselverwaltungsdiensten für die Bitcoin-Verwahrung auftreten, und wie Multi-Party Compute die einzelnen Anforderungen erfüllt.

Anforderung Einschränkung in Cloud KMS und Cloud HSM Wie Multi-Party Compute diese Anforderung erfüllt
BIP32-Schlüsselableitung

Mandantenfähige Cloud HSM-Partitionen sind für die statische, flache Schlüsselverwaltung konzipiert, z. B. für die Umschlagverschlüsselung in Unternehmen. Um die Sicherheit auf Hypervisorebene in gemeinsam genutzten Cloud-Umgebungen zu gewährleisten, lassen Cloud-Anbieter keine benutzerdefinierten HSM-Firmwaremodule zu. Daher kann Cloud HSM keine BIP32-Ableitungspfade nativ berechnen.

Aufgrund dieser Einschränkung erfordert Cloud KMS flache Schlüsselarchitekturen. Anwendungen müssen entweder diskrete Schlüsselressourcen verfolgen oder untergeordnete Schlüssel im unverschlüsselten Hostspeicher ableiten.

Multi-Party Compute verwendet den linearen Homomorphismus des monotonen Span-Programms DKLS23, um nicht gehärtete BIP32-Ableitungspfade lokal zu berechnen. Jeder Knoten berechnet unabhängig die öffentliche skalare Offset-Anpassung (IL) und wendet diesen Offset auf seinen lokalen Schlüsselfreigabe an, ohne dass Netzwerkkommunikationsrunden erforderlich sind.

Wenn bei Wallets mit einem Schlüssel sowohl ein erweiterter öffentlicher Schlüssel (xpub) als auch ein nicht gehärteter untergeordneter privater Schlüssel kompromittiert werden, kann ein Angreifer den übergeordneten privaten Schlüssel berechnen. Bei der Multi-Party Computation wird dieses Risiko beseitigt, da untergeordnete private Schlüssel (kchild) nicht im Klartext zusammengesetzt werden. Sie existieren nur als verteilte, temporäre lokale Freigaben (s1', s2') im hardwareverschlüsselten TEE-Speicher.
Single Point of Compromise

Der vollständige private Schlüssel befindet sich innerhalb einer einzelnen physischen HSM-Grenze. Ein kompromittierter Autorisierungsnachweis oder eine Insider-Bedrohung legt die gesamte Wallet offen.

Der vollständige private Schlüssel ist an keinem Ort im Klartext vorhanden. Schlüsselfreigaben werden mathematisch auf unabhängige Rechenknoten verteilt.
Algorithmus-Agilität (Schnorr und Taproot)

Physische HSM-Hardwarezyklen sind langsam. Wenn Unterstützung für elliptische Kurven oder Signaturschemas wie BIP340 Schnorr auf der secp256k1-Kurve hinzugefügt werden soll, ist eine mehrjährige Hardware-Rezertifizierung erforderlich.

Kryptografische Vorgänge werden in hardwareisolierten Confidential VM-Enklaven ausgeführt. Dadurch kann Multi-Party Computation Protokollaktualisierungen übernehmen, ohne die physische HSM-Grenze zu ändern.

Cloud KMS und Multi-Party Computation im Vergleich

Wenn Sie eine Infrastruktur für die Signierung digitaler Assets in Google Cloudentwerfen, können Sie das HSM-Modell mit einem einzelnen Schlüssel mit dem verteilten Schwellenwertmodell vergleichen.

Cloud KMS- und Cloud HSM-Modell mit einem Schlüssel

In einer Cloud KMS-Bereitstellung generiert Cloud HSM einen asymmetrischen Signaturschlüssel, der den Algorithmus EC_SIGN_SECP256K1_SHA256 direkt in einem gemäß FIPS 140-2 Level 3 validierten physischen HSM verwendet. Die folgende Abbildung zeigt, wie eine Anwendungsebene mit Cloud HSM interagiert, wenn untergeordnete Schlüssel abgeleitet werden:

Zwei Standard-VM-Anwendungsebenen, die mit einer Cloud HSM-FIPS 140-2 Level 3-Grenze interagieren, wobei die gehärtete untergeordnete Ableitung den übergeordneten Schlüssel im Hostspeicher verfügbar macht.

Diese Architektur bietet eine verwaltete FIPS 140-2 Level 3-Validierung und erzeugt normalisierte secp256k1-ECDSA-Signaturen (Elliptic Curve Digital Signature Algorithm) mit niedrigem S, die vom Bitcoin-Netzwerk akzeptiert werden. Es gibt jedoch zwei architektonische Einschränkungen für die Bitcoin-Verwahrung:

  • Fragmentierung der Schlüsselverwaltung: Da Cloud HSM keine BIP32-Ableitungspfade berechnen kann, muss Ihre Anwendung Millionen von diskreten CryptoKey-Ressourcen-IDs in Cloud KMS verfolgen, wodurch Wiederherstellungs-Workflows mit einer einzigen Wurzel entfernt werden.
  • Risiko der Arbeitsspeicherexposition: Um eine gehärtete Ableitung durchzuführen, muss Ihre Anwendung den Root-Seed in den Hostspeicher exportieren, wodurch der Hardware-Sicherheitsperimeter unterbrochen wird.

Schwellenwertmodell für verteilte Multi-Party Computation

Multi-Party Computation implementiert eine gehärtete Erweiterung des ECDSA-Protokolls mit Schwellenwert DKLS23. Anstatt einen einzelnen vollständigen Schlüssel zu generieren, generieren und speichern unabhängige Knoten, die in Confidential Space auf hardwareverschlüsselten AMD SEV-SNP-Enklaven ausgeführt werden, mathematische Schlüsselfragmente. Weitere Informationen zum Protokoll finden Sie unter Kryptografischer Hintergrund von DKLS23.

Die folgende Abbildung zeigt, wie Multi-Party Computation die Signierung auf TEE-Knoten verteilt, die durch unabhängige HSM-Schlüsselverschlüsselungsschlüssel unterstützt werden:

Bitcoin-Transaktionsanfrage, die an zwei TEE-Knoten weitergeleitet wird, die das DKLS23-Protokoll ausführen und Schlüsselfreigaben über Cloud HSM und Cloud EKM entpacken.

Dieses verteilte Schwellenwertmodell bietet drei wesentliche Sicherheitsvorteile:

  • Kein vollständiger privater Schlüssel: Kein einzelnes physisches Gerät, keine Enklave und kein Betreiber hat den vollständigen privaten Schlüssel.
  • Hardwareverankerte Root of Trust: Schlüsselfreigaben werden im Ruhezustand mit Schlüsselverschlüsselungsschlüsseln (Key Encryption Keys, KEKs) verschlüsselt, die durch FIPS 140-2 Level 3 Cloud HSM-Partitionen oder externe lokale HSMs geschützt sind, die über Cloud External Key Manager verbunden sind.
  • Attestierungsbasierte Entschlüsselung: Cloud KMS entpackt Schlüsselanteile nur dann in den Enklavenspeicher, wenn ein Hardware-Attestierungsangebot bestätigt, dass auf dem Knoten verifizierte, nicht manipulierte Multi-Party-Compute-Container-Images ausgeführt werden.

Kryptografische Mechanismen für BIP32 und Taproot

Wenn Sie die Schwellenwertsignatur für die Bitcoin-Verwahrung bewerten, sollten Sie prüfen, ob das Protokoll die hierarchische Adressableitung und Taproot-Anpassung unterstützt, ohne dass zusätzliche Netzwerkrunden zwischen Knoten erforderlich sind.

Nicht gehärtete additive BIP32-Ableitung

BIP32 definiert die Ableitung nicht gehärteter untergeordneter privater Schlüssel als modulare Skalaraddition:

\[ k_{\text{child} } = (k_{\text{par} } + \text{parse}_{256}(I_L)) \bmod n \]

Da Multi-Party Computation ein lineares Secret-Sharing-Schema verwendet, das auf monotonen Span-Programmen basiert, leiten Teilnehmerknoten untergeordnete Schlüsselfreigaben lokal ohne Netzwerkkommunikationsrunden ab. Die folgende Abbildung veranschaulicht diesen lokalen Ableitungsablauf ohne Runden:

Knoten 1 und Knoten 2 berechnen unabhängig voneinander die HMAC-SHA512-Skalaroptimierung lokal, aktualisieren Share 1, während Share 2 unverändert bleibt, und führen eine Online-DKLS23-Signatursitzung aus.

BIP341-Taproot-Schlüsseloptimierung

Diese lineare Eigenschaft unterstützt auch die BIP341-Taproot-Schlüsseloptimierung, ohne die zugrunde liegende Schlüsselverteilung zu ändern:

\[ Q = P + t \cdot G \quad \text{where} \quad t = H_{\text{TapTweak} }(P \parallel \text{MerkleRoot}) \]

Bevor ein Teilnehmerknoten an der Schwellenwert-Signaturzeremonie teilnimmt, wendet er die skalare Anpassung (t) direkt auf seine lokale Schlüsselfreigabe an. Mit dieser Funktion können Sie mit Taproot-Skriptbäumen, Ordinals und Discreet Log Contracts interagieren, ohne Schlüssel neu generieren oder freigeben zu müssen.

Architekturvergleich

In der folgenden Tabelle werden Cloud KMS und Cloud HSM mit Multi-Party Computation in Bezug auf die wichtigsten Dimensionen der Verwahrung verglichen.

Architektonische Dimension Cloud KMS und Cloud HSM Multi-Party Compute
Kryptografische Primitive ECDSA mit einzelner Signatur auf der secp256k1-Kurve Schwellenwert-ECDSA (DKLS23) und Schwellenwert-EdDSA (Edwards-curve Digital Signature Algorithm) auf der Ed25519-Kurve, erweiterbar auf Schwellenwert-Schnorr auf der secp256k1-Kurve
Hardwaregrenze Physische PCIe-HSM-Karte AMD SEV-SNP Confidential Space-Enklaven, die in einer Cloud HSM Root of Trust verankert sind
Unterstützung von BIP32-HD-Wallets Manuelle Verwaltung einzelner Cloud KMS-Schlüssel Lokale additive Schlüsselanteilsanpassung ohne Roundtrips
Schutz durch physischen Schlüssel FIPS 140-2 Level 3 FIPS 140-2 Level 3 für HSM-basierte KEKs, die Schlüsselfreigaben verpacken
Signaturlatenz (P95) 20–50 ms Weniger als 1.000 ms (weniger als eine Sekunde) über verteilte Regionen hinweg
Betroffener Umfang einer Datenpanne bei Anmeldedaten Vollständige Offenlegung des Schlüssels, wenn die Anmeldedaten des Aufrufers oder die IAM-Richtlinien (Identity and Access Management) kompromittiert werden Keine unbefugte Signierung, es sei denn, ein Angreifer kompromittiert gleichzeitig eine bestimmte Anzahl unabhängiger Enklaven und KEKs.
Nachvollziehbarkeit Cloud-Audit-Logs Cloud-Audit-Logs und Hardware-Attestierungslogs für Key Access Justifications

Entwicklung von BIP32 zur Schwellenwert-Schlüsselverwaltung

Wenn Sie eine interne Plattform für die Verwahrung digitaler Assets entwerfen, müssen Sie zwischen Ableitungsstandards, die für einzelne Hardware-Wallets erstellt wurden, und der verteilten Schlüsselverwaltung unterscheiden, die für die institutionelle Governance entwickelt wurde. Obwohl BIP32 häufig für das Adress-Tracking verwendet wird, ist die Verwendung von BIP32-Ableitungsbäumen für die Sicherheit in einer Multi-Party-Computation-Architektur (MPC) redundant und kann die operative Komplexität erhöhen.

Historischer Kontext von BIP32-Wallets mit einem Seed

BIP32 wurde unter Berücksichtigung der Einschränkungen der individuellen Selbstverwahrung entwickelt, bevor Schwellenwert-Kryptografie und Hardware-Enklaven allgemein verfügbar wurden:

  • Root-Seed-Abhängigkeit: Die frühe Bitcoin-Verwahrung beruhte auf der physischen Sicherung einer einzelnen menschenlesbaren mnemonischen Phrase mit 12 oder 24 Wörtern.
  • Wiederherstellung mit einer einzigen Sicherung: Mit BIP32-HD-Wallets können Nutzer eine einzige Seed-Phrase sichern und deterministisch Adressen für mehrere Konten ableiten.
  • Single Point of Failure: Der Root-Mnemonic-Seed stellt einen vollständigen Single Point of Failure dar. Wenn ein Angreifer diese Wortgruppe oder das physische Backup kompromittiert, sind alle abgeleiteten privaten Schlüssel für alle Konten gefährdet.

Die folgende Abbildung zeigt, wie die Kompromittierung eines einzelnen Root-Seeds alle abgeleiteten untergeordneten Konten gefährdet:

Ein Root-Mnemonic-Seed mit 12 oder 24 Wörtern, der sich in untergeordnete Schlüssel 1, 2 und N verzweigt. Wenn der Seed kompromittiert wird, werden alle abgeleiteten privaten Schlüssel der untergeordneten Schlüssel offengelegt.

Root-Seed mit Schwellenwertsignatur entfernen

In einer Zero-Trust-Cloud-Architektur für Institutionen ist kein menschenlesbarer Root-Mnemonic-Seed erforderlich. Multi-Party Computation macht den zentralen privaten Root-Schlüssel vollständig überflüssig. Da auf keinem einzelnen Computer oder Sicherungsmedium ein vollständiger privater Schlüssel im Klartext vorhanden ist, ist keine Adresswiederherstellung mit einer einzelnen Passphrase erforderlich. Anstatt einen Schlüsselbaum von einem Secret abzuleiten, werden bei der Multi-Party Computation unabhängige Schlüsselfreigaben auf kryptografisch isolierte Enklaven verteilt.

BIP32-Ableitungspfade in Multi-Party Computation vergleichen

Wenn für Ihre Integration BIP32-Kompatibilität für externe Adresstracker oder Buchhaltungs-Workflows erforderlich ist, vergleichen Sie die beiden technischen Implementierungspfade in der folgenden Tabelle.

Vorgehensweise bei der Implementierung Kryptografischer Mechanismus Sicherheits- und Gefährdungsprofil Latenz und Signaturleistung
Nicht gehärtetes BIP32 mit Multi-Party Computation

Lokale additive Anpassung: s1' = (s1 + IL) mod n.

Jeder Knoten berechnet den öffentlichen skalaren Offset (IL) unabhängig und wendet diesen Offset auf seinen lokalen Schlüsselfreigabe an.
  • Risiko bei einem einzelnen Schlüssel: Bei Wallets ohne MPC kann ein Angreifer, der sowohl einen übergeordneten öffentlichen Schlüssel (xpub) als auch einen untergeordneten privaten Schlüssel kompromittiert, den übergeordneten privaten Schlüssel zurückrechnen.
  • MPC-Maßnahme: Untergeordnete private Schlüssel (kchild) werden nicht im Klartext zusammengesetzt und existieren nur als temporäre, verteilte Schlüsselfragmente (s1', s2') im hardwareverschlüsselten TEE-Speicher. Dadurch wird verhindert, dass der übergeordnete Schlüssel aus dem untergeordneten Schlüssel wiederhergestellt werden kann.
  • Erfordert keine Netzwerkkommunikationsrunden zwischen MPC-Knoten, um untergeordnete Schlüssel abzuleiten.
  • Wird vor dem Signieren mit der lokalen CPU-Geschwindigkeit ausgeführt.
  • Unterstützt Signaturlatenzen von weniger als einer Sekunde (p95 weniger als 1 Sekunde) über verschlüsselte gRPC-Kanäle.
Gehärtetes BIP32 mit Multi-Party Computation

Interaktiver HMAC-SHA512-Hashwert für mehrere Parteien, der über das geheim geteilte übergeordnete Schlüsselmaterial berechnet wird.
  • Schützt vor der Eskalation von untergeordneten zu übergeordneten Schlüsseln, indem der private Schlüssel des übergeordneten Schlüssels gehasht wird, was die Protokollkomplexität erheblich erhöht.
  • Bietet keinen zusätzlichen Sicherheitsvorteil in einer Enklavenumgebung mit mehreren Parteien, in der der übergeordnete Schlüssel bereits geheim geteilt und vor Exfiltration geschützt ist.
  • Erfordert mehrere interaktive Netzwerkrunden zwischen MPC-Knoten, um einen HMAC-SHA512-Schwellenwertschaltkreis über geheim geteilte Eingaben auszuwerten.
  • Erhöht die Signaturlatenz und führt zu Engpässen bei der Transaktionsverarbeitung.

Empfehlungen für die institutionelle Verwahrung

Multi-Party Computation unterstützt die nicht gehärtete additive Ableitung von BIP32, um die Kompatibilität mit vorhandenen Systemen und externen Adress-Trackern zu gewährleisten. Für eine dedizierte institutionelle Verwahrung sollten Sie den Übergang zu unabhängigen Schwellenwertschlüsseln in Betracht ziehen, die direkt in Multi-Party Computation verwaltet werden:

  • Abhängigkeiten von einem einzelnen Root-Schlüssel eliminieren: Unabhängige Schlüsselfreigaben in isolierten Enklaven generieren, rotieren und sichern, anstatt Schlüssel als mathematische Offsets von einem einzelnen Root-Schlüssel abzuleiten.
  • Algorithmus-Agilität erhöhen: Entkoppeln Sie Ihre Orchestrierungsebene von Bitcoin-spezifischen BIP32-Ableitungspfaden, damit Sie Nicht-ECDSA-Signaturschemas wie das Ed25519-Signaturschema für Smart-Contract-Netzwerke unter einem Governance-Modell übernehmen können.
  • Signaturkomplexität reduzieren: Verwalten Sie diskrete Schwellenwertschlüssel, um Datenbankabfragen zu vereinfachen, Transaktionsanfragen kurz zu halten und die Signaturlatenz zu minimieren.