Multisig ist den meisten Bitcoin-Nutzern ein vertrautes Konzept: Eine Multisig-Transaktion erfordert die Zustimmung mehrerer Parteien, bevor sie ausgeführt werden kann. Wir unterscheiden zwischen „n-von-n“-Multisignaturen, bei denen die Anzahl der beteiligten Parteien n ist und alle zustimmen müssen, und „t-von-n“-Schwellensignaturen, bei denen nur eine kleinere Anzahl t von Teilnehmern zustimmen muss. Kryptografische Schemata wie MuSig, MuSig-DN und MuSig2 für Multisignaturen und FROST von Komlo und Goldberg für Schwellenwertsignaturen können die Transaktionskosten senken und die Privatsphäre von Multisig-Wallets verbessern.

Bisher wurde FROST in der Bitcoin-Community nur in experimentellen Implementierungen verwendet. In diesem Beitrag erklären wir, warum das so ist und wie wir FROST in einer Bitcoin-Produktionsumgebung voranbringen wollen, indem wir kürzlich einen BIP-Entwurf für das verteilte Schlüsselgenerierungsprotokoll ChillDKG veröffentlicht haben.

Zunächst: Was sind die Vorteile von FROST?

Datenschutz- und Effizienzgewinne mit MuSig2 und FROST

Bei MuSig2 und FROST ist das Ergebnis eine einzige Signatur, auch wenn mehrere Teilnehmer am Signaturprozess beteiligt sind.

Dies bietet den Teilnehmern nicht nur mehr Privatsphäre, da die Transaktion wie eine normale SingleSig-Wallet-Transaktion aussieht. Es reduziert auch die Transaktionsgröße und senkt somit die Transaktionsgebühr. Alles großartige Dinge!

MuSig2 und FROST ermöglichen Bitcoin-Benutzern den Betrieb einer Multisig-Wallet zu den gleichen Transaktionskosten wie bei einer normalen Single-Signature-Wallet. Die Kostenvorteile sind besonders bei Systemen mit einer großen Anzahl von Unterzeichnern und häufigen Transaktionen signifikant, wie etwa föderierten Sidechains wie Liquid oder Fedimint. Im Gegensatz zu herkömmlichen Multisig, die einen eindeutigen Fingerabdruck hinterlassen, der es Blockchain-Beobachtern ermöglicht, Transaktionen der Wallet zu identifizieren, sind FROST-basierte Wallets auf der Blockchain nicht von normalen Single-Signature-Wallets zu unterscheiden. Daher bieten sie im Vergleich zu herkömmlichen Multisig-Wallets eine Verbesserung der Privatsphäre.

Während MuSig2 in der Bitcoin-Branche angenommen wurde, kann das unseres Wissens nach nicht von FROST gesagt werden. Dies mag angesichts der Existenz mehrerer FROST-Implementierungen überraschend sein, wie z. B. in ZF FROST (von der Zcash Foundation), secp256kfun (von Lloyd Fournier) und einer experimentellen Implementierung in libsecp256k1-zkp (von Jesse Posner und Blockstream Research). Es gibt sogar eine IETF-Spezifikation für FROST, RFC 9591 (obwohl sie aufgrund von Taproot-Optimierungen und x-only-öffentlichen Schlüsseln nicht mit Bitcoin kompatibel ist). Eine der plausibelsten Erklärungen ist, dass der Schlüsselgenerierungsprozess von FROST im Vergleich zu MuSig2 erheblich komplexer ist.

Das ungelöste Rätsel von FROST in Produktionssystemen

FROST besteht im Wesentlichen aus zwei Teilen: Schlüsselgenerierung und Signierung. Während der Signierungsprozess dem von MuSig2 sehr ähnelt, ist die Schlüsselgenerierung deutlich aufwändiger als bei MuSig2. Die Schlüsselgenerierung in FROST ist entweder vertrauenswürdig oder verteilt:

  1. Bei der vertrauenswürdigen Schlüsselgenerierung ist ein „vertrauenswürdiger Händler“ beteiligt, der den Schlüssel generiert und Schlüsselanteile an die Unterzeichner verteilt. Der Händler stellt einen einzigen Ausfallpunkt dar: Bei böswilligen Handlungen oder Hackerangriffen besteht die Gefahr, dass die FROST-Wallet geleert wird.

  2. Obwohl die verteilte Schlüsselgenerierung (DKG) die Notwendigkeit eines vertrauenswürdigen Händlers überflüssig macht, bringt sie auch ihre eigenen Herausforderungen mit sich: Alle Teilnehmer müssen an einer interaktiven „Zeremonie“ zur Schlüsselgenerierung teilnehmen, bevor mit der Signierung begonnen werden kann.

Die zentrale Herausforderung: Einigung

DKG erfordert normalerweise sichere (d. h. authentifizierte und verschlüsselte) Kanäle zwischen den Teilnehmern, um geheime Anteile an einzelne Unterzeichner zu übermitteln, sowie einen sicheren Vereinbarungsmechanismus. Der Zweck des sicheren Vereinbarungsmechanismus besteht darin, sicherzustellen, dass sich alle Teilnehmer letztendlich über die Ergebnisse des DKG einig werden. Dazu gehören nicht nur Parameter wie der generierte öffentliche Schwellenwertschlüssel, sondern auch, ob kein Fehler aufgetreten ist und die Zeremonie nicht durch einen sich schlecht verhaltenden Teilnehmer gestört wurde.

Während die IETF-Spezifikation DKG als völlig außerhalb des Geltungsbereichs betrachtet, implementieren die oben genannten FROST-Implementierungen keine sichere Vereinbarung und überlassen diese Aufgabe dem Bibliotheksbenutzer. Die Implementierung einer Vereinbarung ist jedoch nicht trivial: Es gibt unzählige Protokolle und Arten von Vereinbarungen, von einfachen Echo-Broadcast-Schemata bis hin zu vollwertigen byzantinischen Konsensprotokollen, und ihre Sicherheits- und Verfügbarkeitsgarantien unterscheiden sich erheblich und manchmal sogar geringfügig.

Trotz der Verwirrung, die durch diesen Dschungel an Vereinbarungsprotokollen entstehen kann, wird den Ingenieuren die genaue Art der Vereinbarung, auf die sich DKG stützt, oft nicht klar mitgeteilt, sodass sie im Dunkeln tappen.

ChillDKG: ein eigenständiges DKG für FROST

Um dieses Hindernis zu überwinden, schlagen wir ChillDKG vor, ein neues „gebrauchsfertiges“ DKG-Protokoll, das auf die Verwendung in FROST zugeschnitten ist (Entwurf). Wir liefern eine detaillierte Beschreibung in Form eines Entwurfs eines Bitcoin Improvement Proposal (BIP), der als Spezifikation für Implementierer dienen soll.

Das Hauptmerkmal von ChillDKG ist, dass es eigenständig ist: Die Herstellung sicherer Kommunikation und sicherer Vereinbarungen erfolgt innerhalb des Protokolls, während die gesamte zugrunde liegende Komplexität hinter einer einfachen und schwer zu missbrauchenden API verborgen ist. Daher ist ChillDKG sofort einsatzbereit und basiert auf keiner Setup-Annahme, außer dass jeder Unterzeichner sich für die Gruppe der Mitunterzeichner entschieden hat, die durch individuelle öffentliche Schlüssel identifiziert werden. ChillDKG basiert auf dem SimplPedPop-Protokoll, an dessen Design und formalem Sicherheitsnachweis Blockstream Research beteiligt war, siehe das CRYPTO 2023-Papier „Practical Schnorr Threshold Signatures Without the Algebraic Group Model“ von Chu, Gerhart, Ruffing (Blockstream Research) und Schröder

Weitere Ziele des ChillDKG-Designs sind:

  • Breite Anwendbarkeit: ChillDKG unterstützt ein breites Spektrum an Szenarien, von solchen, in denen die Signaturgeräte einer einzelnen Person gehören und von ihr verbunden sind, bis hin zu solchen, in denen mehrere Besitzer die Geräte von unterschiedlichen Standorten aus verwalten.

  • Einfache Backups: Anstatt die von anderen Unterzeichnern erhaltenen Geheimnisse an einem sicheren Ort sichern zu müssen, ermöglicht ChillDKG die Wiederherstellung der Wallet ausschließlich aus dem Geräte-Seed und den öffentlichen Daten, die für alle DKG-Teilnehmer gleich sind. Folglich erhält ein Angreifer, der Zugriff auf die öffentlichen Backup-Daten erhält, nicht den geheimen Signaturschlüssel, und wenn ein Benutzer sein Backup verliert, kann er es von einem anderen ehrlichen Unterzeichner anfordern.

Der ChillDKG BIP befindet sich derzeit im Entwurfsstadium und wir suchen nach Feedback zu Designentscheidungen und Implementierungsdetails. Obwohl die Spezifikation größtenteils vollständig ist, fehlen Testvektoren und wir erwägen, einige zusätzliche Funktionen hinzuzufügen (z. B. „identifizierbare Abbrüche“). Sobald der ChillDKG BIP fertiggestellt ist, kann er in Kombination mit einem BIP für FROST-Signierung verwendet werden, um das gesamte FROST-Protokoll zu instanziieren.

Dies ist ein Gastbeitrag von Jonas Nick, Kiara Bickers und Tim Ruffing. Die geäußerten Meinungen sind ausschließlich ihre eigenen und spiegeln nicht unbedingt die von BTC Inc oder Bitcoin Magazine wider.

Quelle: Bitcoin Magazine

Der Beitrag „Der Schlüssel zu FROST: Was ist verteilte Schlüsselgenerierung?“ erschien zuerst auf Crypto Breaking News.

#BTC