Protokolle zur verteilten Schlüsselerzeugung

Distributed Key Generation (DKG) löst das Problem des vertrauenswürdigen Dealers in der Threshold-Kryptografie. Ohne DKG müsste eine zentrale Partei das Schlüsselpaar erzeugen und die Anteile verteilen, wobei sie den vollständigen privaten Schlüssel vorübergehend kennen würde. Mit DKG können n Parteien gemeinsam ein öffentliches und ein privates Schlüsselpaar erzeugen. Dabei erfährt keine einzelne Partei den privaten Schlüssel, auch nicht der Koordinator des Protokolls.

Pedersen-DKG war das erste praktische DKG-Protokoll und wurde 1991 veröffentlicht. Jede der n Parteien erzeugt ein zufälliges Geheimnis s_i und führt ein Verifiable-Secret-Sharing-(VSS-)Protokoll aus, um es zu teilen. Jede Partei veröffentlicht Commitments für die Koeffizienten ihres Polynoms. Nachdem alle Parteien ihre Beiträge geteilt haben, ist das gemeinsame Geheimnis die Summe aller s_i-Werte, und jede Partei besitzt einen Anteil an dieser Summe.

Feldman VSS (Verifiable Secret Sharing von Feldman, 1987) ist der zentrale Baustein der meisten DKG-Protokolle. Der Dealer verpflichtet sich auf die Koeffizienten des Polynoms als Gruppenelemente (C_j = g^{a_j} mod p). Jede Partei, die einen Anteil f(i) erhält, kann ihn anhand dieser Commitments überprüfen, indem sie kontrolliert, ob g^{f(i)} dem Produkt aus C_j^{i^j} entspricht. So können die Parteien erkennen, ob der Dealer fehlerhafte Anteile gesendet hat.

Beim Joint-Feldman-DKG führt jede der n Parteien parallel Feldman VSS aus und fungiert dabei für ihr eigenes Geheimnis als Dealer. Anschließend melden die Parteien ungültige Anteile. Der endgültige Schlüssel ist die Summe der Geheimnisse der Dealer, gegen die keine Beschwerde vorliegt. Das Joint-Feldman-DKG ist jedoch nicht gegen adaptive Angreifer geschützt, die Parteien auf Grundlage der Protokollnachrichten kompromittieren. Diese Schwäche wurde von Gennaro, Jarecki, Krawczyk und Rabin aufgezeigt.

Das GJKR-DKG-Protokoll (Gennaro, Jarecki, Krawczyk, Rabin, 1999 und 2007) behob die Schwächen des Joint-Feldman-DKG. GJKR verwendet Pedersen VSS mit informationstheoretisch verbergenden Commitments anstelle von Feldman VSS und ergänzt Beschwerderunden, in denen Parteien ungültige Anteile anfechten können. Das resultierende DKG ist gegen adaptive Angreifer geschützt und wurde zur theoretischen Standardreferenz für sichere DKG-Protokolle.

GJKR-DKG erfordert drei Runden: eine Commitment-Runde, in der jede Partei VSS-Commitments veröffentlicht, eine Anteilsrunde, in der die Parteien sich gegenseitig Anteile direkt senden, und eine Beschwerderunde, in der die Parteien Beschwerden über ungültige Anteile veröffentlichen. Parteien, die Beschwerden nicht ausräumen können, werden ausgeschlossen. In einer vierten Runde werden die Beiträge der gültigen Parteien zum endgültigen öffentlichen Schlüssel und zu den verteilten privaten Schlüsselanteilen zusammengeführt.

Das Schlüsselmanagement von Ethereum-Validatoren verwendet DKG für Distributed Validator Technology (DVT). EIP-4844 und das DVT-Ökosystem (Obol Network, SSV Network) nutzen Threshold-BLS-Signaturen über BLS12-381. So können Validator-Komitees Blöcke signieren, ohne dass ein einzelner Betreiber den vollständigen Validator-Schlüssel kennt. Dies verbessert die Fehlertoleranz der Validatoren und verringert das Risiko eines Slashing aufgrund eines kompromittierten Schlüssels.

DRAND ist ein verteiltes Zufallsorakel, das von der Ethereum Beacon Chain zur Erzeugung unvorhersehbarer Zufallszahlen verwendet wird. DRAND führt DKG unter einer Gruppe von Knoten der League of Entropy (Cloudflare, EPFL, Protocol Labs usw.) aus, um einen Threshold-BLS-Schlüssel zu erzeugen. In jeder Runde tragen t von n Knoten Teilsignaturen bei, die zu einem unvorhersehbaren Zufallswert kombiniert werden. Kein einzelner Knoten kann die Ausgabe beeinflussen oder vorhersagen.

DKG ist für Threshold-Schemata mit Schnorr/EdDSA wesentlich einfacher als für ECDSA. Bei Threshold-Schemata mit Schnorr ist der verteilte private Schlüssel einfach die Summe der Geheimnisse der Parteien (x = x1 + x2 + ... + xn), und der öffentliche Schlüssel ist die Summe der öffentlichen Schlüsselanteile (X = X1 + X2 + ... + Xn). Bei ECDSA erfordert die Nichtlinearität, dass DKG multiplikative Anteile erzeugt, wofür komplexere Protokolle nötig sind.

Langfristig verwendete Schlüsselanteile in einem Threshold-Schema können kompromittiert werden, wenn ein Angreifer nach und nach über längere Zeit Parteien korrumpiert. Proaktives Secret Sharing (Auffrischungsprotokolle) randomisiert die Anteile regelmäßig neu, ohne den zugrunde liegenden Schlüssel zu ändern. Nach einer Auffrischung sind die Anteile aus der Zeit davor unbrauchbar, wodurch das Zeitfenster für einen Angriff begrenzt wird. GJKR und darauf aufbauende Protokolle enthalten Auffrischungsprotokolle, die dieselbe Struktur wie das ursprüngliche DKG verwenden.

DKG ist in mehreren Produktivsystemen implementiert. Der Ethereum-DVT-Client Obol Charon verwendet eine DKG-Zeremonie auf Grundlage von Pedersen VSS über BLS12-381. Silent Shard von Silence Laboratories nutzt DKG für mobile MPC-Wallets. Die Bibliothek dkg-go implementiert GJKR für Go-Anwendungen. Das Threshold Network (früher Keep Network) verwendet DKG für seinen Threshold-ECDSA-Dienst, der tBTC auf Bitcoin absichert.

Welche zentrale Eigenschaft macht Pedersen-DKG einem Setup mit einem einzelnen vertrauenswürdigen Dealer überlegen?

DKG macht einen vertrauenswürdigen Dealer überflüssig, indem alle n Parteien gemeinsam ein Threshold-Schlüsselpaar erzeugen, ohne dass eine Partei den privaten Schlüssel kennt. Beim Pedersen-DKG führt jede Partei VSS für ihren Beitrag aus. GJKR ergänzt adaptive Sicherheit durch Beschwerderunden. DKG bildet die Grundlage für Ethereum-DVT (Obol, SSV), das DRAND-Zufallsorakel und produktive MPC-Wallet-Setups. Auffrischungsprotokolle erweitern die Sicherheit, indem sie die Anteile regelmäßig neu randomisieren.