Multi-Party Computation signiert mit zwei Schlüsselalgorithmen: ECDSA auf secp256k1 und EdDSA auf Ed25519 (demnächst verfügbar). Auf dieser Seite werden das ECDSA-Schwellenwertprotokoll DKLS23 und die von Google vorgenommenen Änderungen beschrieben. Informationen zu den unterstützten Algorithmen finden Sie unter Unterstützte Blockchains.
Threshold ECDSA und DKLS23
Im Gegensatz zu anderen Signaturschemas ist das Problem der Schwellenwertsignatur für ECDSA bekanntermaßen schwierig. Bis 2017 waren die meisten Lösungen mit erheblichen Kompromissen verbunden.
2018 präsentierte DKLS die erste Lösung für die 2-von-2-Signatur für ECDSA, die nur auf ECDSA-basierten kryptografischen Annahmen beruhte (z.B. keine Paillier-, RSA- oder andere kryptografische Annahmen erforderte). Die bahnbrechende Idee dieses Protokolls war ein neuartiger Ansatz, um die Sicherheit gegen böswillige Angriffe für einen MPC-basierten Ansatz zu gewährleisten. Frühere Versuche, generische, gegen böswillige Angriffe sichere MPC-Techniken anzuwenden, führten zu Protokollen, deren Ausführung Minuten statt Millisekunden dauerte.
Nachfolgende Verbesserungen durch dieselben Autoren führten zu einem k-von-n-Protokoll und schließlich führte die DKLS23-Verbesserung zu einem generischen Framework für 3-Runden-k-von-n-Schwellenwert-ECDSA, das alle vorherigen Ansätze abdeckte und den DKLS-Ansatz als den effizientesten in Bezug auf wichtige Leistungsmesswerte identifizierte. Insbesondere basiert diese Version des Protokolls nur auf idealen Commitment- und Zweiparteien-Multiplikations-Primitiven. Das resultierende Protokoll erfordert nur wenige Millisekunden Rechenzeit pro Partei (was zu einer um Größenordnungen höheren Geschwindigkeit im Vergleich zu konkurrierenden Ansätzen führt). Vor allem aber basiert es auf einfacheren kryptografischen Primitiven, die nur elliptische Kurvenoperationen verwenden (im Gegensatz zu teuren Paillier-Operationen, homomorphen Operationen und teuren Zero-Knowledge-Bereichsbeweisen und Beweisen der Wohlgeformtheit kryptografischer Schlüssel, die in anderen Arbeiten erforderlich sind).
Das Protokoll wurde intern von mehreren Prüfern bewertet, darunter von Coinbase beauftragte Experten und andere Kryptografieexperten. Doerner und Roy DR26 haben kürzlich einen Fehler in der Sicherheitsanalyse für den DKLS-Multiplikator identifiziert, der 22 zusätzliche Aufrufe von OT erfordert, um die behaupteten 120 Bit Sicherheit zu erreichen. Diese Änderung wurde bereits umgesetzt. Andere externe Prüfer haben ebenfalls auf fehlende Details in der Beschreibung des Protokolls in Bezug auf die Auswirkungen von Broadcast im Punkt-zu-Punkt-Kanalmodell hingewiesen (insbesondere ist es wichtig, einige Konfigurationsparameter zu wiederholen, um ein gemeinsames Verständnis zu erreichen).
Durch die anschließende Arbeit am Protokoll bei Google wurde die Implementierung erheblich verbessert, die für den Betrieb des Protokolls im großen Maßstab erforderlichen Ressourcen wurden reduziert und die Funktionalität des Schemas wurde erweitert. In der wissenschaftlichen Literatur wird beispielsweise die Auswahl und Implementierung des Random Oracle nicht ausreichend spezifiziert. Die Implementierung des Random Oracle ist zwar eine nützliche akademische Abstraktion, aber eine komplexe Aufgabe, die zu mehreren Fehlern geführt hat, die in Sicherheitsaudits dokumentiert wurden.
Ein wichtiger Aspekt unserer Arbeit war die Entwicklung eines Typsystems (basierend auf zwei Spawn- und Fork-Vorgängen sowie der strikten Verwendung von Typsystemen, um das Kopieren, Verschieben und Aliasing von Zeigern auf Orakel zu verhindern), um sicherzustellen, dass jede Sitzung und Untersitzung ein anderes Zufallsorakel verwendet.
Eine weitere wichtige Verbesserung betrifft die Auswahl von Sitzungs- und Untersitzungskennungen. Das UC-Modell und damit alle Protokolle, die in diesem Modell als sicher gelten, erfordern, dass die Umgebung neue Sitzungs-IDs bereitstellt. In der Praxis muss ein System sicherstellen, dass der Angreifer diese Annahme nicht verletzen kann. Dazu müssen die Teilnehmer in der Regel einen unbegrenzten Status beibehalten. Wir haben das ursprüngliche DKLS-Protokoll um zusätzliche Runden erweitert, um diese Kennung so auszuwählen, dass nur ein Zustand mit konstanter Größe erforderlich ist.
Insgesamt dauert ein Signiervorgang mit dem aktualisierten und gehärteten Protokoll immer noch nur einige Millisekunden.
In Bezug auf die Funktionalität wird im DKLS23-Paper nur die standardmäßige k-von-n-Schwellenwert-Zugriffsstruktur berücksichtigt. In der Praxis benötigen Kunden möglicherweise eine Zugriffsstruktur, die die Organisationsregeln widerspiegelt. In der kryptografischen Literatur finden sich viele Ansätze zur Entwicklung von Zugriffsstrukturen für die gemeinsame Nutzung von Geheimnissen. Hier haben wir das DKLS-Protokoll erweitert, um allgemeinere Zugriffsstrukturen zu unterstützen, die aus Schwellenwert-k-von-n-Gates zusammengesetzt werden können. So können Richtlinien wie „2 von 3 der folgenden Gruppen: (a) der Kunde, (b) 2 von 10 Risikokontrollbeauftragten, (c) 2 von 3 Leitern der Finanz-, Rechts- und Buchhaltungsabteilung“ usw. festgelegt werden.
In der v1beta API definieren Sie diese Zugriffsstruktur als Schlüsselrichtlinie eines Schlüsselbunds im Feld keyPolicy. Jeder im Schlüsselbund erstellte Schlüssel verwendet ihn. Eine Schlüsselrichtlinie kann maximal zwei Ebenen haben: die Stamm-Schwellenwertregel und die Schwellenwertregeln direkt darunter. Eine Grenzwertregel unter dem Stamm darf keine weitere Grenzwertregel enthalten.