Schwellenwertkryptografie und MPC aus den Grundprinzipien

Was ist Schwellenwertkryptografie?

Ein herkömmlicher Signaturschlüssel stellt eine geballte Autorität dar. Wer den privaten Schlüssel nutzen kann, kann signieren, und wer ihn dauerhaft verliert, verliert möglicherweise den Zugriff. Backups verbessern die Verfügbarkeit, schaffen jedoch zusätzliche Kopien derselben Autorität. Die Schwellenwertkryptografie verändert die Struktur: Die Teilnehmer halten Anteile, und die kryptografische Operation wird gemeinsam berechnet. Das Ziel besteht darin, sicherzustellen, dass ein einzelnes Gerät, ein einzelner Betreiber oder ein einzelner Sicherheitsverstoß weder für Diebstahl noch für dauerhaften Verlust ausreicht.

Der Begriff „Schwellenwert“ beschreibt eine Regel wie „2 von 3“ oder „3 von 5“. Bei einem „2-von-3“-Signaturdesign können beliebige zwei autorisierte Teilnehmer den Vorgang abschließen. Ein Teilnehmer allein sollte nicht in der Lage sein, zu signieren oder das zugrunde liegende Geheimnis zu erfahren. Die Anteile können sich auf Geräten, in Hardware-Sicherheitsmodulen, auf Servern, in Offline-Systemen oder bei verschiedenen Personen befinden. Die Architektur ist ebenso wichtig wie die Arithmetik: Drei Anteile, die von einem einzigen Cloud-Administrator kontrolliert werden, können sich eher wie eine einzige Ausfalldomäne verhalten als wie drei unabhängige Parteien.

MPC ist weiter gefasst als Schwellenwertsignaturen. Die sichere Mehrparteienberechnung untersucht, wie Parteien Funktionen über private Eingaben auswerten können, während sie gleichzeitig kontrollieren, was preisgegeben wird. Die Schwellenwert-Schlüsselerzeugung, das Signieren, die Entschlüsselung und die Zufallsgenerierung sind spezielle Anwendungen. Eine als „MPC“ vermarktete Wallet kann daher sehr unterschiedliche Protokolle, Schwellenwerte, Wiederherstellungskonzepte und Sicherheitsmodelle verwenden. Die Bezeichnung allein sagt wenig über die tatsächlichen Garantien aus.

Was garantiert „t-of-n“ eigentlich?

Ein Schwellenwert ist keine universelle Garantie. Experten unterscheiden zwischen Geheimhaltung, Fälschungssicherheit, Verfügbarkeit, Robustheit und Nachvollziehbarkeit. Ein Design kann den Schlüssel schützen und dennoch zulassen, dass ein böswilliger Teilnehmer jeden Signaturversuch abbricht. Es kann einen Saboteur identifizieren, ist aber dennoch nicht in der Lage, die Signatur abzuschließen, ohne diesen Teilnehmer zu ersetzen. Es kann unter einem statischen Angreifer-Modell einen kompromittierten Unterzeichner tolerieren, versagt jedoch, wenn ein Angreifer im Laufe der Zeit verschiedene Unterzeichner kompromittiert.

Selbst der Satz „Weniger als t Anteile geben nichts preis“ benötigt einen Kontext. Die perfekte Shamir-Geheimnisaufteilung liefert eine informationstheoretische Aussage über die mathematischen Anteile. Eine eingesetzte Threshold-Wallet erzeugt zudem Transkripte, öffentliche Commitments, Protokolle, Zeitangaben und Fehlermeldungen. Diese umgebenden Systeme können Metadaten preisgeben, Angriffe mit ausgewählter Eingabe ermöglichen oder Implementierungsfehler offenlegen, ohne dem idealen Geheimnisaufteilungssatz zu widersprechen.

Fazit: „t-of-n“ gibt das Quorum an. Es sagt nichts über das Angreifer-Modell aus, ob ein böswilliger Unterzeichner das System zum Stillstand bringen kann, ob Anteile aktualisiert werden können oder ob der Code unabhängig validiert wurde.

Warum ist die Shamir-Geheimnisaufteilung nicht dasselbe wie die Schwellenwertsignatur?

Shamirs Konstruktion aus dem Jahr 1979 stellt ein Geheimnis als konstanten Term eines Zufallspolynoms dar. Jeder Teilnehmer erhält einen Punkt auf diesem Polynom. Bei Erreichen einer beliebigen Schwelle lässt sich das Polynom interpolieren und das Geheimnis wiederherstellen; bei weniger Punkten bleibt das Geheimnis unbestimmt. Dies ist eine elegante und leistungsstarke Methode zum Schutz von Backups, Treuhandmaterial und Wiederherstellungsgeheimnissen.

Die operative Einschränkung tritt zutage, wenn das Geheimnis verwendet werden muss. Ist die Shamir-Rekonstruktion das einzige verfügbare Werkzeug, kombinieren die autorisierten Teilnehmer ihre Fragmente auf einem Rechner, erhalten den vollständigen privaten Schlüssel und rufen einen gewöhnlichen Signaturalgorithmus auf. In diesem Moment werden das Rekonstruktionsgerät, der Speicher, die Prozessprotokolle, der Auslagerungsspeicher und der Bediener zu einem einzigen Schwachpunkt. Das Geheimnis kann anschließend gelöscht werden, doch die Angriffsfläche bestand bereits.

Eine Schwellenwertsignatur führt arithmetische Operationen über Anteile durch. Die Teilnehmer erzeugen Teilwerte, weisen nach oder überprüfen, dass diese Werte korrekt gebildet sind, und kombinieren die Teilergebnisse zu einer Signatur. Der vollständige Signaturschlüssel muss während der Signatursitzung nicht offenliegen. Viele Schwellenwertschemata nutzen die Polynom-Aufteilung nach Shamir als eine Komponente. Der eigentliche Unterschied besteht zwischen der Speicherung von Geheimnissen mit Rekonstruktion einerseits und einem vollständig verteilten Signaturprotokoll andererseits.

Existiert der vollständige private Schlüssel jemals?

Vertrauenswürdiger Händler

Ein Händler generiert einen normalen privaten Schlüssel, erstellt Anteile und verteilt diese. Dies kann sicher sein, wenn der Händler starke Zufälligkeit verwendet, jeden Teilnehmer authentifiziert, die Verpflichtungen zur Aufteilung überprüft und das ursprüngliche Geheimnis sowie ungenutzte Anteile zuverlässig löscht. Dennoch entsteht dadurch ein Moment und ein Akteur mit Kenntnis des vollständigen Schlüssels. RFC 9591 verlagert die Schlüsselgenerierung außerhalb des Haupt-FROST-Protokolls und enthält ein Verfahren für einen vertrauenswürdigen Händler nur als Anhang.

Verteilte Schlüsselgenerierung

Ein DKG-Protokoll ermöglicht es den Teilnehmern, Zufallswerte beizusteuern und gemeinsam Anteile sowie einen gemeinsamen öffentlichen Schlüssel abzuleiten. Keine einzelne Partei sollte den entsprechenden privaten Schlüssel erfahren, vorausgesetzt, das Protokoll wird korrekt implementiert und die Korruptionsschwelle wird nicht überschritten. DKG ist kein einzelner Algorithmus: Verschiedene Schemata gehen von unterschiedlichen Annahmen hinsichtlich Rundsendungen, authentifizierter Kanäle, Beschwerden, böswilliger Parteien und der Verfügbarkeit der Teilnehmer aus.

Importieren eines bestehenden Schlüssels

Institutionen möchten möglicherweise eine bestehende Adresse, einen Kontoverlauf oder einen öffentlichen Schlüssel beibehalten. Einige Protokolle unterstützen die Konvertierung oder Weitergabe eines bestehenden Schlüssels. Dieser Vorgang kann erfordern, dass der Schlüsselinhaber den vollständigen Schlüssel verwaltet, oder es können spezielle Importprotokolle zum Einsatz kommen. Die Sicherheitshistorie vor dem Import spielt weiterhin eine Rolle: Die Verteilung eines Schlüssels macht eine frühere Kopie, ein Foto, ein Backup oder eine Kompromittierung nicht rückgängig.

Wiederherstellung und Notfallrekonstruktion

Einige Systeme verfügen über einen Notfallweg, der den Schlüssel aus Sicherungsmaterial rekonstruiert. Dies kann die Notfallwiederherstellung verbessern, führt aber gleichzeitig wieder zu der Gefährdung durch einen einzelnen Schlüssel, die das Schwellenwertdesign eigentlich vermeiden sollte. Andere Systeme bieten bewusst keinen Rekonstruktionsweg an und erfordern für jede Wiederherstellungsmaßnahme eine Mindestanzahl an aktiven Teilnehmern. Keine der beiden Vorgehensweisen ist automatisch richtig; die Wahl sollte explizit getroffen, getestet und in das Bedrohungsmodell aufgenommen werden.

Wie erzeugt MPC eine Signatur aus mehreren Anteilen?

Eine digitale Signatur ist eine mathematische Beziehung zwischen einer Nachricht, einem öffentlichen Schlüssel und geheimem Signaturmaterial. Schwellenwertprotokolle nutzen die Algebra des Signaturschemas oder verwenden allgemeine Werkzeuge für sichere Berechnungen, sodass jeder Teilnehmer zu dieser Beziehung beiträgt, ohne seinen Eingabeanteil preiszugeben. Die Details unterscheiden sich stark zwischen Signaturen nach Schnorr und ECDSA, doch der operative Lebenszyklus weist gemeinsame Phasen auf.

• Sitzungserstellung. Das System definiert den Gruppenschlüssel, die Teilnehmermenge, die Schwelle, die genaue Nachricht, den ketten-spezifischen Signatur-Digest, die Protokollversion und eine eindeutige Sitzungskennung.
• Eingabevalidierung. Jeder Teilnehmer überprüft, ob die Nachricht syntaktisch gültig ist und den Richtlinien entspricht. Ein Schwellenwertprotokoll darf nicht zu einem Signatur-Orakel für beliebige Eingaben werden.
• Vorbereitung von Nonce oder Vorsignatur. Die Teilnehmer generieren einmalige geheime Werte, Commitments und – in einigen ECDSA-Schemata – Multiplikationsmaterial. Diese Werte müssen eindeutig sein, korrekt an die Sitzung gebunden und wie Schlüsselmaterial geschützt werden.
• Erzeugung von Signaturanteilen. Mindestens t Teilnehmer kombinieren ihre privaten Anteile mit dem gemeinsamen Transkript, um Teil-Signaturen oder entsprechende MPC-Ausgaben zu erzeugen.
• Überprüfung und Aggregation der Anteile. Ungültige Anteile werden verworfen. Ein Koordinator oder alle Teilnehmer kombinieren gültige Anteile zu einer endgültigen Signatur.
• Gewöhnliche Verifizierung. Die Blockchain oder Anwendung überprüft die endgültige Signatur unter dem öffentlichen Gruppenschlüssel mithilfe ihres normalen Verifizierers. Sie muss das interne Schwellenwertprotokoll nicht verstehen.

Der Koordinator ist eine Protokollrolle, nicht unbedingt ein vertrauenswürdiger Schlüsselinhaber. In FROST kann der Koordinator beispielsweise Commitments sammeln, die Gruppe der Unterzeichner auswählen, die Nachricht verteilen und Anteile aggregieren, ohne private Anteile zu erhalten. Der Koordinator kann dennoch einen Denial-of-Service-Angriff auslösen, inkonsistente Ansichten senden oder eine böswillige Nachricht vorlegen, sodass authentifizierte Kommunikation und teilnehmerseitige Validierung weiterhin erforderlich sind.

Warum sind Nonces, Vorverarbeitung und Koordinatoren wichtig?

Nonzen sind Teil des Geheimnisses

Schnorr-, EdDSA- und ECDSA-Signaturen basieren alle auf geheimen Werten pro Signatur, die gemeinhin als Nonces bezeichnet werden. Bei gewöhnlichen Signaturen mit einer einzigen Partei kann eine zuverlässige Bibliothek die Nonce innerhalb einer vertrauenswürdigen Grenze generieren oder ableiten. In einem Schwellenwertprotokoll tragen mehrere Parteien gemeinsam zum Nonce-bezogenen Zustand bei oder berechnen diesen. Eine wiederverwendete Nonce, eine wiederholte Commitment-Nachricht oder eine absichtlich fehlerhaft formatierte Multiplikationsnachricht kann eine oder mehrere Signatursitzungen in einen Schlüsselextraktionsangriff verwandeln. RFC 9591 warnt ausdrücklich davor, dass eine deterministische Nonce-Ableitung, die für gewöhnliches EdDSA geeignet ist, in einer Mehrparteienumgebung unsicher ist und die Generierung neuer, gleichmäßig verteilter Zufalls-Nonces erfordert.

Vorverarbeitungsschritte finden vor der Nachricht statt

Viele Schwellenwert-ECDSA-Systeme berechnen rechenintensive Inhalte, bevor die Transaktion bekannt ist. Die Online-Phase lässt sich dadurch auf eine geringe Anzahl von Nachrichten reduzieren, was für Cold-Signers und Netzwerke mit hoher Latenz von Vorteil ist. Der Kompromiss ist operativer Natur: Vorsignaturen werden zu einmalig verwendbarem kryptografischem Inventar. Wiederverwendung, Rollback, Duplizierung über Replikate hinweg oder der Verlust der Zustandssynchronisation können katastrophale Folgen haben. Backups dürfen verbrauchte Vorsignaturen nicht so wiederherstellen, als wären sie unbenutzt.

Die Sitzungsbindung verhindert „Mix-and-Match“-Angriffe

Jede Nachricht sollte an die Protokollversion, den öffentlichen Gruppenschlüssel, die Teilnehmergruppe, den Nachrichten-Digest, die Kette, das Netzwerk, die Signaturrolle und eine eindeutige Sitzung gebunden sein. Ein Teilnehmer sollte veraltete oder inkonsistente Verpflichtungen ablehnen und bestätigen, dass die endgültigen Transaktionsbytes mit den durch die Richtlinie autorisierten Bytes übereinstimmen. Hier trifft Anwendungsdesign auf Kryptografie: Ein formal sicherer Signaturkern kann dennoch die falsche Kette, den falschen Nonce-Wert, den falschen Kontraktaufruf oder das falsche Ziel signieren, wenn der Adapter eine falsche Nutzlast liefert.

Robustheit ist nicht automatisch gegeben

Einige Protokolle garantieren Geheimhaltung und Fälschungssicherheit, brechen jedoch ab, wenn sich ein Teilnehmer falsch verhält. Bei einem identifizierbaren Abbruch kann ein für den Fehler verantwortlicher Teilnehmer benannt werden; Robustheit zielt darauf ab, den Vorgang trotz einiger böswilliger Parteien abzuschließen. RFC 9591 erhebt keinen Anspruch auf Robustheit und weist darauf hin, dass ein übergeordneter Wrapper wie ROAST in bestimmten Konfigurationen böswillige Störungen beheben kann.

Was ist FROST, und was standardisiert RFC 9591?

FROST nutzt die lineare Struktur von Schnorr-Signaturen. Jeder ausgewählte Teilnehmer hält einen Anteil am Gruppen-Signaturschlüssel. In Runde eins generieren die Teilnehmer einmalige Nonces und veröffentlichen Commitments. In Runde zwei berechnen sie Signaturanteile, die an die Nachricht, die Unterzeichnergruppe und die Commitments gebunden sind. Der Koordinator verifiziert die Anteile und fügt sie zusammen, um die endgültige Schnorr-Signatur zu erhalten.

Die Unterscheidung zwischen einem Forschungs-RFC und einem Internetstandard ist von Bedeutung. RFC 9591 repräsentiert den Konsens der Crypto Forum Research Group und bietet Implementierern eine präzise gemeinsame Spezifikation, doch im Abschnitt zum Status wird darauf hingewiesen, dass es sich um einen informativen RFC handelt, der nicht auf dem IETF-Standardisierungspfad liegt. Das NIST hat separat einen mehrjährigen Evaluierungsprozess für Schwellenwertschemata eingeleitet; FROST gehört zu den Schemata, die im Rahmen dieser Ausschreibung geprüft werden.

Ist die RFC-secp256k1-Suite mit Bitcoin Taproot kompatibel?

Nicht automatisch. Bitcoin BIP340 definiert „x-only“-öffentliche Schlüssel, getaggte Hashes, eine spezifische Challenge-Gleichung und eine 64-Byte-Kodierung. Die FROST-secp256k1-Verschlüsselungssuite in RFC 9591 verwendet eine eigene, domänengetrennte Hash-Konstruktion und eine generische Verarbeitung komprimierter Punkte. Ein Protokoll kann dieselbe Kurve verwenden und dennoch Signaturen erzeugen, die ein BIP340-Verifizierer ablehnt. Ein Bitcoin-kompatibler Schnorr-Schwellenwert benötigt daher eine Konstruktion und Implementierung, die explizit auf die BIP340-Semantik ausgelegt ist.

Fazit: „Verwendet secp256k1“ ist kein Kompatibilitätszertifikat. Die Kurve ist nur eine Ebene eines Signatursystems.

Warum ist Schwellenwert-ECDSA schwieriger als Schwellenwert-Schnorr?

Vereinfacht ausgedrückt enthält eine ECDSA-Signatur einen Wert s = k^-1(H(m) + r x) mod q, wobei x der private Schlüssel und k ein einmaliger Nonce ist. In einer Schwellenwertkonfiguration dürfen weder x noch k einer Partei bekannt sein. Die Teilnehmer müssen daher additive oder polynomiale Anteile an Produkten, die x und k beinhalten, und letztendlich am Ausdruck, der mit der Umkehrung zusammenhängt, erhalten, während sie gleichzeitig verhindern, dass eine böswillige Partei fehlerhafte Werte wählt, die einen anderen Anteil preisgeben.

Paillier-basierte Protokolle nutzen additiv homomorphe Verschlüsselung und „Multiplication-to-Addition“-Subprotokolle (MtA). Andere Familien nutzen Klassengruppen oder Oblivious Transfer. Null-Wissens-Beweise oder Konsistenzprüfungen zeigen, dass verschlüsselte Werte und Anteile in den erforderlichen Bereichen liegen und die Protokollbeziehungen erfüllen. Diese Komponenten schaffen eine größere Implementierungsfläche als das Schwellenwert-Schnorr-Protokoll: Arithmetik mit großen ganzen Zahlen, Beweissysteme, Transkriptverwaltung, Vorverarbeitung, Fehlerzuordnung und mehrere kryptografische Annahmen.

Threshold-ECDSA bleibt wichtig, da Bitcoin-Legacy- und SegWit-v0-Schlüsselausgaben, extern verwaltete Ethereum-Konten und viele andere eingesetzte Systeme ECDSA verifizieren. Die Kompatibilität mit bestehenden Adressen und Hardware kann die Komplexität rechtfertigen, doch die Entscheidung sollte in klarem Bewusstsein der größeren Angriffsfläche getroffen werden.

Welche Threshold-ECDSA-Protokollfamilien sind von Bedeutung?

Das Fachgebiet entwickelt sich rasant weiter, und Protokoll-Spitznamen werden oft ungenau verwendet. Implementierer müssen die genaue Version der Veröffentlichung, den Parametersatz, den Sicherheitsnachweis und die Code-Version angeben. Eine als „GG18“ bezeichnete Bibliothek kann spätere Patches enthalten, erforderliche Nachweise weglassen, proprietäre Vorverarbeitung hinzufügen oder eine ältere, anfällige Variante implementieren. Das Jahr in einem Spitznamen ist keine ausreichende Sicherheitsgarantie.

Der Artikel erstellt keine Rangliste dieser Protokolle. Die Leistung hängt von der Teilnehmerzahl, der geografischen Verteilung, dem Schwellenwert, der Vorverarbeitung, der Hardware, den Annahmen zur Verfügbarkeit und der Qualität der Implementierung ab. Eine neuere Veröffentlichung ist nicht automatisch sicherer als eine ausgereifte Implementierung, und eine ausgereifte Implementierung ist nicht allein deshalb sicher, weil die zugrunde liegende Veröffentlichung gut untersucht ist.

Wie unterscheiden sich FROST, MuSig2 und gewöhnliche Multisig-Verfahren?

MuSig2 wird manchmal als Schwellenwertsignatur bezeichnet, da mehrere Parteien zusammenarbeiten. BIP327 stellt ausdrücklich klar, dass es sich um ein n-von-n-Multisignatur-Schema handelt, nicht um eine t-von-n-Schwellenwertsignatur. Jeder in der Aggregation verwendete Schlüssel bleibt ein vollständiger Signaturschlüssel. Ist ein Teilnehmer nicht verfügbar, kann die Gruppe nicht signieren, es sei denn, es existiert ein separater Fallback-Pfad.

Taproot erschwert den Vergleich der Sichtbarkeit. Eine MuSig2- oder andere aggregierte Schlüsselpfad-Ausgabe kann wie eine gewöhnliche BIP340-Ausgabe mit einem einzigen Unterzeichner aussehen, und optionale Skriptpfade bleiben verborgen, solange sie nicht verwendet werden. Eine Skriptpfad-Ausgabe offenbart den ausgeführten Zweig und den Nachweis, nicht unbedingt jeden ungenutzten Zweig. Daher ist die Aussage „Multisig ist sichtbar, Schwellenwert ist unsichtbar“ zu absolut.

Schwellenwert-Signatur vs. On-Chain-Multisig: Welche Kompromisse ändern sich?

Der Vergleich stellt keine allgemeingültige Rangliste dar. Bitcoin-Skript, Taproot und Ethereum-Smart-Contract-Konten bieten unterschiedliche Möglichkeiten. Einige Blockchains unterstützen effiziente native Multisignaturen; andere erfordern Contract-Wallets oder verfügen gar nicht über ein flexibles Skript. Durch die Schwellenwert-Signatur sieht die Blockchain zwar eine vertraute Signatur, doch das Off-Chain-Protokoll wird Teil der Trusted Computing Base.

Ein sinnvolles Design kann beides kombinieren. Beispielsweise kann ein Taproot-Output einen aggregierten oder Schwellenwert-Schlüsselpfad für routinemäßige Ausgaben nutzen und versteckte Skriptpfade für zeitverzögerte oder Notfall-Wiederherstellungen beibehalten. Ein Ethereum-Smart-Account kann eine durch einen Schwellenwert erzeugte ECDSA-Signatur sowie Beschränkungen auf Vertragsebene erfordern. Eine mehrschichtige Architektur kann ein Risiko verringern, erhöht jedoch die operative Komplexität, sodass jeder Wiederherstellungszweig getestet und nicht nur dokumentiert werden muss.

Funktioniert eine Schwellenwert-Signatur auf jeder Blockchain?

Ein Blockchain-Signatur-Stack besteht aus mehreren Schichten: der mathematischen Kurve, der Signaturgleichung, der Verschlüsselung des öffentlichen Schlüssels, der Signaturverschlüsselung, der Transaktionsserialisierung, dem Signatur-Digest, der Domänen-Trennung, den Regeln für kanonische Werte sowie der Konto- oder Skript-Semantik. Die Schwellenwert-Signatur muss mit all diesen Komponenten übereinstimmen. Die Aussage „funktioniert auf jeder Kette mit derselben Kurve“ lässt den Großteil dieses Stacks außer Acht.

Bitcoin

Bei Legacy- und SegWit-v0-Schlüsselausgaben wird ECDSA verwendet, während Taproot-Key-Path-Signaturen BIP340-Schnorr nutzen. BIP340 verfügt über spezifische „x-only“-Schlüssel und Tagged Hashing. MuSig2 BIP327 wurde ausdrücklich für BIP340 entwickelt. Eine generische Threshold-ECDSA- oder FROST-Bibliothek benötigt einen Bitcoin-Adapter, der die Sighash-Konstruktion, den Skripttyp, die Schlüsselanpassung, Nonce-Regeln und die akzeptierte Signaturkodierung handhabt.

Ethereum

Extern verwaltete Konten verwenden secp256k1-ECDSA und stellen eine Adresse aus Signaturkomponenten wieder her. Ethereum-Transaktionstypen, Chain-IDs und strukturierte Daten nach EIP-712 verwenden unterschiedliche Signaturdomänen. EIP-2 lehnt Signaturen mit „high-s“-Transaktionen ab. Ein Schwellenwert-Signierer muss daher kanonische r- und s-Werte sowie die korrekten Wiederherstellungsinformationen für die genaue Nutzlast erzeugen.

Ed25519-basierte Systeme

RFC 9591 umfasst Ed25519-kompatible und Ed448-kompatible Suiten, deren endgültige Signaturen durch die entsprechenden Standard-Verifizierer überprüft werden können. Die Anwendung muss weiterhin die genaue Kettennachricht, das Format des öffentlichen Schlüssels und die Transaktionsrichtlinie bereitstellen. Die Kompatibilität der Verifizierer validiert nicht die zugehörige Wallet-Integration.

Wie funktionieren Aktualisierung, erneute Freigabe, Wiederherstellung und Änderungen der Mitgliedschaft?

Proaktive Aktualisierung

Eine Aktualisierung fügt einen Share von Null hinzu oder randomisiert die Shares anderweitig neu, sodass das zugrunde liegende Gruppengeheimnis gleich bleibt. Alte Shares sollten nach der Aktualisierung unbrauchbar werden. Im Rahmen eines proaktiven Sicherheitsmodells muss ein Angreifer, der im Laufe der Zeit verschiedene Teilnehmer kompromittiert, eine Schwelle innerhalb eines Aktualisierungszeitraums erreichen, anstatt Shares auf unbestimmte Zeit anzuhäufen. Eine Aktualisierung behebt keine Kompromittierung, die bereits die Schwelle erreicht hat, und löscht keine Kopien, die ein Angreifer möglicherweise von Anwendungszugangsdaten oder Richtlinien-Systemen angefertigt hat.

Neuverteilung und Teilnehmeraustausch

Ein Protokoll zur Neuverteilung von Anteilen kann neue Anteile an eine neue Teilnehmergruppe verteilen und dabei t oder n ändern, während derselbe öffentliche Gruppenschlüssel beibehalten wird. Dies ermöglicht den Ersatz eines verlorenen Geräts, die Rotation eines Mitarbeiters oder die Änderung der organisatorischen Kontrolle, ohne dass Gelder auf der Blockchain bewegt werden. Dies ist nur möglich, wenn das Protokoll dies unterstützt und eine ausreichende Anzahl autorisierter Teilnehmer mitwirkt. Ein Produkt kann einen verlorenen Anteil nicht aus dem Nichts „neu erstellen“.

Was passiert, wenn ein Anteil verloren geht?

Wenn mindestens t gültige Anteile übrig bleiben, kann die Gruppe normalerweise weiterhin signieren. Möglicherweise kann durch erneutes Teilen ein Ersatz geschaffen werden. Wenn weniger als t Anteile übrig sind und es keinen separaten Wiederherstellungsschlüssel, kein Backup und keinen Vertragspfad gibt, ist die Signaturberechtigung verloren. Ein Schwellenwertschema verbessert die Redundanz; es garantiert jedoch nicht die Wiederherstellung bei jedem Verlustszenario.

Was passiert, wenn ein Anteil gestohlen wird?

In einem idealen „t-aus-n“-Geheimnisaufteilungsmodell geben weniger als t Anteile das Geheimnis nicht preis und können nicht signieren. Operativ gesehen stellt ein gestohlener Anteil dennoch einen aktiven Sicherheitsvorfall dar. Der Angreifer kann ihn in Protokollsitzungen nutzen, mit zukünftigen Kompromittierungen kombinieren, Implementierungsfehler ausnutzen oder Metadaten ermitteln. Die richtige Reaktion besteht darin, riskante Sitzungen zu unterbrechen, Nachforschungen anzustellen, die Anteile zu aktualisieren oder neu zu verteilen, die zugehörigen Zugangsdaten zu rotieren und zu überprüfen, ob die verbleibenden Teilnehmer unabhängig sind.

Was sind die wichtigsten Sicherheitsannahmen und Fehlermodi?

Sicherheit gegen Abbruch unterscheidet sich von Sicherheit gegen Diebstahl

Viele Protokolle für unehrliche Mehrheiten wahren die Geheimhaltung auch dann, wenn ein böswilliger Teilnehmer die Sitzung abbricht. Das ist ein erfolgreiches kryptografisches Ergebnis, aber ein gescheitertes operatives Ergebnis. Finanzsysteme sollten festlegen, wie schnell ein böswilliger Teilnehmer ausgeschlossen werden kann, ob es alternative Untergruppen von Unterzeichnern gibt, wie veraltete Sitzungen abgebrochen werden und wie der Geschäftsbetrieb während eines Streits fortgesetzt wird.

Der Koordinator kann offen sein und dennoch mächtig

Ein Koordinator kann Unterzeichner auswählen, Zusagen sammeln, die Nachricht festlegen, Sitzungen planen und die endgültige Signatur veröffentlichen. Selbst ohne Schlüsselteilung kann er Metadaten beobachten, Anfragen zensieren, die Ansichten der Teilnehmer aufteilen oder wiederholt aufwendige Arbeitsschritte auslösen. Protokollnachrichten sollten authentifiziert werden, die Teilnehmer sollten die Transaktion ableiten oder unabhängig validieren, und die Überwachung sollte zwischen gewöhnlichen Fehlern und böswilligem Verhalten unterscheiden.

Schwellenwertsignaturen sind standardmäßig nicht postquantenresistent

FROST, ECDSA und aktuelle Schnorr-Systeme beruhen auf Annahmen zum diskreten Logarithmus. Die Aufteilung eines Schlüssels macht den zugrunde liegenden Signaturalgorithmus nicht resistent gegen einen ausreichend leistungsfähigen Quantencomputer. Post-Quanten-Schwellenwertsignaturen sind ein aktives Forschungs- und Standardisierungsgebiet, und bei der Migrationsplanung müssen sowohl der Chain-Verifier als auch die verteilte Schlüsselverwaltungsschicht berücksichtigt werden.

Was haben Alpha-Rays, TSSHOCK und spätere Forschungen zur Schlüsselextraktion gezeigt?

Alpha-Rays

Die Alpha-Rays-Studie aus dem Jahr 2021 beschrieb Schlüsselextraktionsangriffe auf Implementierungen von Schwellenwert-ECDSA im GG18- und GG20-Stil. Die Angriffe zielten auf Multiplikations-zu-Additions-Teilprotokolle und Implementierungsentscheidungen wie „schnelle“ Modi ohne die erforderlichen Bereichsnachweise ab. Ein böswilliger Teilnehmer konnte die Interaktion ausnutzen, um den vollständigen Schlüssel wiederherzustellen. Das Ergebnis hat ECDSA nicht geknackt; es hat jedoch gezeigt, dass das Weglassen von Nachweis- und Validierungsschritten das Sicherheitsargument ungültig macht.

TSSHOCK

TSSHOCK, das 2023 veröffentlicht wurde, dokumentierte weitere Angriffe auf Schwellenwert-ECDSA-Implementierungen. Die Untersuchung konzentrierte sich auf Implementierungsfehler bei der homomorphen Verschlüsselung und der Beweisverarbeitung und zeigte mehrere Wege zur Wiederherstellung des privaten Schlüssels auf. Die wichtige Erkenntnis geht über die genannten Angriffe hinaus: Schwellenwert-ECDSA-Protokolle sind empfindlich gegenüber exakten Bereichen, der Parametervalidierung, Beweisaussagen und der Fehlerbehandlung.

BitGo Zero Proof

Eine von Fireblocks entdeckte und öffentlich bekannt gegebene Schwachstelle in einer BitGo-Wallet veranschaulichte dasselbe Muster in einer Produktionsumgebung. Eine fehlende Nachweisvalidierung in einem ECDSA-Ablauf zwischen zwei Parteien könnte es einer Partei ermöglichen, den Anteil der anderen Partei zu extrahieren und den Schlüssel zu rekonstruieren. Der betroffene Dienst wurde nach der Offenlegung ausgesetzt und gepatcht. Auch hier lag der Fehler nicht in der ECDSA-Primitive, sondern in der Protokollimplementierung und der fehlenden Verifizierungsgrenze.

Praktische Forschung zur Schlüsselextraktion im Jahr 2024

Spätere Forschungsarbeiten aus Wissenschaft und Industrie analysierten führende MPC-Wallet-Implementierungen und berichteten von Angriffen zur Schlüsselextraktion, die eine unterschiedliche Anzahl von Signaturinteraktionen erforderten – in einem Fall unter den untersuchten Bedingungen sogar nur eine einzige Signatur. Diese Ergebnisse unterstreichen die Notwendigkeit, genaue Protokollversionen zu identifizieren, jeden Nachweis- und Validierungsschritt einzubeziehen und die Überprüfung der Implementierung als Teil der kryptografischen Sicherheitsaussage zu betrachten.

Wie sollte eine MPC- oder Schwellenwert-Signatur-Implementierung bewertet werden?

Kryptografische Spezifikation

• Geben Sie den genauen Titel der Veröffentlichung, die Revision, die Verschlüsselungssuite und den Parametersatz an. Vergewissern Sie sich, ob die Implementierung mit der Version übereinstimmt, deren Nachweis zitiert wird.
• Dokumentieren Sie den Schwellenwert, die Teilnehmeranzahl, das statische oder adaptive Korruptionsmodell, die Annahme einer ehrlichen oder unehrlichen Mehrheit, das Abbruchverhalten und die Robustheitsaussagen.
• Bestätigen Sie, wie Schlüssel generiert oder importiert werden, ob es einen vertrauenswürdigen Anbieter gibt und ob jemals ein vollständiger Schlüssel oder ein rekonstruierbares Backup erstellt wird.
• Identifizieren Sie jede Hilfsprimitive: Paillier-Parameter, Oblivious Transfer, Klassengruppen, Commitments, Zero-Knowledge-Beweise, Hash-Funktionen und Zufallszahlengeneratoren.

Implementierung und Test

• Verlangen Sie eine unabhängige Überprüfung durch Spezialisten für genau diese Protokollfamilie, nicht nur ein allgemeines Audit von Smart Contracts oder Anwendungen.
• Testen Sie alle negativen Pfade: fehlerhafte Punkte, Skalare, Beweise, Chiffretexte, Teilnehmerkennungen, Signaturgruppen, doppelte Nonces, wiederholte Nachrichten und abgebrochene Sitzungen.
• Verwenden Sie für die Geräteumgebung geeignete Primitive mit konstanter Laufzeit und Seitenkanalresistenz; schützen Sie Protokolle, Absturzberichte, den Swap-Speicher, Telemetrie- und Beobachtbarkeitssysteme.
• Führen Sie Vergleiche mit veröffentlichten Testvektoren durch und erstellen Sie implementierungsübergreifende Interoperabilitätstests, sofern eine Spezifikation vorliegt.
• Ein Verfahren zur Reaktion auf Sicherheitslücken aufrechterhalten, mit dem Teilnehmer ausgeschlossen, die Signatur gestoppt, Freigaben aktualisiert und Gelder migriert werden können, ohne die betrieblichen Auswirkungen zu verschleiern.

Betriebsarchitektur

• Ordnen Sie Anteile wirklich unabhängigen Ausfalldomänen zu: unterschiedliche Anmeldedaten, Administratoren, Geräte, Netzwerke und, soweit praktikabel, vorzugsweise unterschiedliche Software- oder Hardware-Basisumgebungen.
• Schützen Sie den Zustand vor der Signatur und den Nonce-Zustand vor Rollback, Klonen und der Wiederherstellung aus Backups. Behandeln Sie verbrauchte Zustände als dauerhaft verbraucht.
• Authentifizieren Sie die Nachrichten der Teilnehmer und stellen Sie jedem Unterzeichner ausreichende Transaktionsdaten zur Verfügung, um die wirtschaftliche Handlung zu validieren – nicht nur einen Hash ohne Kontext.
• Üben Sie den Umgang mit Verlusten, Kompromittierungen, dem Ausscheiden von Mitarbeitern, Cloud-Ausfällen, Koordinatorausfällen und der Notfallwiederherstellung. Ein Wiederherstellungsplan, der noch nie ausgeführt wurde, ist reine Spekulation.
• Überwachen Sie Signaturversuche, die Auswahl der Teilnehmer, fehlgeschlagene Nachweise, Aktualisierungsereignisse und die Außerkraftsetzung von Richtlinien. Kryptografische Privatsphäre sollte die operative Rechenschaftspflicht nicht ausschließen.

Häufig gestellte Fragen

Ist MPC dasselbe wie Schwellenwertsignaturen?

Nein. MPC ist die übergreifende Disziplin der Berechnung anhand privater Eingaben, die von mehreren Parteien gehalten werden. Die Schwellenwertsignatur ist eine MPC-Anwendung, die eine digitale Signatur unter einem gemeinsamen Gruppenschlüssel erzeugt. Weitere MPC-Anwendungen sind die Schwellenwertentschlüsselung, die Schnittmenge privater Mengen und die gemeinsame Zufallsgenerierung.

Verfügt eine Schwellenwert-Wallet über einen privaten Schlüssel?

Sie verfügt über eine Signaturberechtigung, die einem öffentlichen Schlüssel entspricht, doch diese Berechtigung kann nur in Form von verteilten Anteilen vorliegen. Bei einem DKG-basierten Design besitzt kein Teilnehmer jemals den vollständigen privaten Schlüssel. Bei einem Dealer-, Import- oder Rekonstruktionsdesign kann zu einem bestimmten Zeitpunkt ein vollständiger Schlüssel vorliegen.

Kann ein gestohlener Anteil das Geld stehlen?

Bei einem korrekt implementierten t-of-n-Schema sollten weniger als t Anteile keine Signatur erzeugen oder den Schlüssel offenlegen. Ein gestohlener Anteil ist dennoch ein Vorfall: Der Angreifer kann ihn mit späteren Kompromittierungen kombinieren, Protokollsitzungen missbrauchen oder Implementierungsfehler ausnutzen. Aktualisieren oder teilen Sie den Anteil neu, wenn das Design dies zulässt.

Kann ein verlorener Anteil ersetzt werden?

Nur, wenn genügend autorisierte Anteile übrig sind und das Protokoll oder die Wiederherstellungsarchitektur eine erneute Verteilung unterstützt. Die verbleibenden Teilnehmer können manchmal einen neuen Anteil erstellen und dabei den öffentlichen Schlüssel beibehalten. Wenn weniger als die Schwelle übrig sind und kein separater Wiederherstellungspfad existiert, kann der Schlüssel nicht wiederhergestellt werden.

Ist FROST ein offizieller Internetstandard?

Nein. RFC 9591 ist eine informative IRTF-Veröffentlichung, die den Konsens der Crypto Forum Research Group widerspiegelt. Es handelt sich um eine präzise gemeinsame Spezifikation, jedoch nicht um ein Dokument im IETF-Standardisierungsprozess. Das NIST bewertet separat eingereichte Schwellenwertschemata im Rahmen eines Verfahrens, dessen formelle Ausschreibung im Jahr 2026 begann.

Beinhaltet RFC 9591 die Schlüsselgenerierung?

Die Hauptspezifikation deckt die FROST-Signatur in zwei Runden ab. Die Schlüsselgenerierung liegt ausdrücklich außerhalb ihres Hauptanwendungsbereichs. Ein Anhang enthält ein Beispiel für einen „Trusted Dealer“, und bei der Implementierung kann ein separates DKG-Protokoll verwendet werden.

Ist FROST secp256k1 mit Bitcoin Taproot kompatibel?

Der RFC enthält eine secp256k1-Verschlüsselungssuite, was jedoch nicht automatisch bedeutet, dass er BIP340-kompatibel ist. Bitcoin verwendet spezifische „x-only“-Schlüssel, getaggte Hashes und Kodierungsregeln. Eine Bitcoin-Implementierung benötigt eine BIP340-spezifische Schwellenwertkonstruktion und einen Chain-Adapter.

Ist MuSig2 eine Schwellenwertsignatur?

MuSig2 ist ein Multi-Signatur-Schema, das unabhängige Schnorr-Schlüssel aggregiert und alle n Unterzeichner erfordert. BIP327 beschreibt es ausdrücklich als „n-of-n“-Schema und nicht als allgemeines „t-of-n“-Schwellenwert-Signaturschema.

Kann die Blockchain erkennen, dass MPC verwendet wurde?

Oftmals nicht allein anhand der endgültigen Signatur: Diese wird wie eine gewöhnliche Signatur unter einem öffentlichen Schlüssel verifiziert. Der Adresstyp, der Vertragscode, Transaktionsmuster, Dienstmetadaten oder spätere Offenlegungen können das Verwahrungsdesign dennoch offenbaren. Taproot kann zudem einige Multisignatur- und Skriptrichtlinien verbergen, sodass Unsichtbarkeit kein Alleinmerkmal von MPC ist.

Ist die Schwellenwertsignatur sicherer als Multisig?

Keines der beiden Verfahren ist grundsätzlich sicherer. Multisig bietet einfachere, durch die Blockchain erzwungene Richtlinien und unabhängige vollständige Schlüssel; Schwellenwert-Signaturen können den On-Chain-Fußabdruck verringern, das Quorum verbergen und eine Adresse durch erneutes Teilen erhalten. Schwellenwert-Protokolle erhöhen die kryptografische und implementierungstechnische Komplexität außerhalb der Blockchain. Die richtige Wahl hängt von der Blockchain, dem Bedrohungsmodell, den Wiederherstellungsanforderungen und den betrieblichen Fähigkeiten ab.

Schützt die Schwellenwert-Signatur vor Betrug?

Es kann mehrere Genehmigungen erfordern und Limits durchsetzen, aber ein legitimes Quorum kann dennoch eine böswillige Transaktion signieren. Teilnehmer und Richtlinien-Systeme müssen den genauen Empfänger, den Betrag, den Vertragsaufruf, das Netzwerk und die Berechtigungen kennen, bevor sie Anteile erzeugen.

Ist Schwellenwertkryptografie postquantum?

Aktuelle Schwellenwertschemata wie FROST, Schnorr und ECDSA sind nicht postquantum-sicher. Sie verteilen die bestehende Signaturbefugnis, behalten jedoch die Sicherheitsannahmen des zugrunde liegenden Signaturalgorithmus bei. Postquantum-Schwellenwertschemata erfordern andere Primitive und Unterstützung durch die Blockchain.

Fazit

Die Schwellenwertkryptografie löst ein echtes operatives Problem: Ein einzelnes Signaturgeheimnis sollte nicht über das Schicksal eines großen Guthabens, eines Systems oder einer Institution entscheiden. Die Lösung besteht nicht einfach darin, einen Schlüssel in Teile zu zerlegen. Ein vollständiges Schwellenwert-Signatur-Design muss definieren, wie Anteile generiert werden, wie einmalige Zufälligkeit geschützt wird, wie sich die Teilnehmer auf eine Nachricht einigen, wie fehlerhafte Beiträge abgelehnt werden, wie Ausfälle zugeordnet werden, wie Anteile aktualisiert werden und wie die endgültige Signatur mit der Zielkette übereinstimmt.

Die wichtigste Korrektur an der üblichen Marketing-Sprache besteht darin, dass jede Behauptung an Bedingungen geknüpft ist. Ein DKG-basiertes System kann während seiner gesamten Lebensdauer auf einen vollständigen Schlüssel verzichten; ein System mit importierten Schlüsseln kann dies nicht von sich behaupten. Ein einzelner Anteil kann kryptografisch unzureichend und betrieblich dringend sein. Eine Signatur kann in der Blockchain gewöhnlich aussehen, während sie von einer großen vertrauenswürdigen Rechenbasis außerhalb der Blockchain abhängt. Ein Protokoll kann als sicher bewiesen und dennoch unsicher implementiert sein.

In Verbindung mit unabhängigen Fehlerdomänen, geprüftem Code, strikter Nonce-Disziplin, korrekten Kettenadaptern, einstudierten Wiederherstellungsabläufen und Unterzeichnern, die das, was sie genehmigen, auch validieren, kann die Schwellenwertsignatur den Single Point of Failure beseitigen, ohne die Kompatibilität mit der gewöhnlichen Signaturprüfung zu beeinträchtigen. Wird sie ohne diese Kontrollmechanismen lediglich als Etikett verwendet, kann sie einen komplexeren Single Point of Failure verschleiern.

Quellen und weiterführende Literatur

Wichtige Referenzen für diesen Artikel, Stand: Juli 2026.

• NIST-Projekt „Multi-Party Threshold Cryptography“. https://csrc.nist.gov/projects/threshold-cryptography
• NIST IR 8214: Schwellenwertschemata für kryptografische Primitive. https://csrc.nist.gov/pubs/ir/8214/final
• NIST IR 8214A: Roadmap zur Entwicklung von Kriterien für Schwellenwertschemata. https://csrc.nist.gov/pubs/ir/8214/a/final
• NIST IR 8214C: Erster Aufruf zur Einreichung von Mehrparteien-Schwellenwertschemata. https://nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8214C.pdf
• Adi Shamir, Wie man ein Geheimnis teilt. https://dl.acm.org/doi/10.1145/359168.359176
• RFC 9591: FROST-Schnorr-Signaturen mit zwei Runden. https://www.rfc-editor.org/info/rfc9591/
• Komlo und Goldberg, FROST. https://eprint.iacr.org/2020/852
• BIP340: Schnorr-Signaturen für secp256k1. https://bips.dev/340/
• BIP327: MuSig2 für BIP340-kompatible Multisignaturen. https://bips.dev/327/
• BIP341: Taproot. https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
• Gennaro und Goldfeder, Schnelles Multiparty-Threshold-ECDSA mit schnellem vertrauensfreiem Setup. https://dl.acm.org/doi/10.1145/3243734.3243859
• Gennaro und Goldfeder, Ein-Runden-Schwellenwert-ECDSA mit identifizierbarem Abbruch. https://eprint.iacr.org/2020/540
• Canetti et al., UC-basiertes, nicht-interaktives, proaktives Threshold-ECDSA mit identifizierbaren Abbrüchen. https://eprint.iacr.org/2021/060
• Doerner et al., Schwellenwert-ECDSA auf Basis von ECDSA-Annahmen: Der Mehrparteienfall. https://eprint.iacr.org/2019/523