Schwellenwertsignaturen
Schwellenwertsignaturen ermöglichen es einer erforderlichen Anzahl von Beteiligten, gemeinsam eine digitale Signatur mit Anteilen eines gemeinsamen Signaturschlüssels zu erzeugen. Bei der Verwahrung von Kryptowerten lässt sich so die Signaturbefugnis auf Systeme oder Organisationen verteilen. Eine Schwellenwertlösung hängt vom kryptographischen Protokoll und der Schlüsselverwaltung ab; die Bezeichnung MPC wallet legt diese Einzelheiten nicht fest.[1]
Schwellenwerte und Multisignaturen
Bei einem Schwellenwertverfahren kann eine ausreichend große Teilmenge der Beteiligten signieren. FROST ist ein zweirundiges Schnorr-Schwellenwertsignaturprotokoll mit Sicherheitsannahmen zur Erzeugung der Schlüsselanteile und zur Zahl kompromittierter Beteiligter. RFC 9591 ist eine informative Veröffentlichung der Crypto Forum Research Group, keine Spezifikation auf dem Internet Standards Track.[1]
Das Signieren durch mehrere Parteien ist nicht immer ein Schwellenwertverfahren. MuSig2, spezifiziert in BIP 327, aggregiert öffentliche Schlüssel und erzeugt eine mit BIP 340 kompatible Schnorr-Signatur. Dafür werden jedoch alle an der Schlüsselaggregation beteiligten Unterzeichner benötigt. Es handelt sich um ein n-von-n-Multisignaturverfahren, nicht um ein t-von-n-Schwellenwertverfahren.[2]
Sicherheitsannahmen und Betriebsbedingungen
Die Verteilung von Schlüsselanteilen verändert das Vertrauensmodell, ersetzt aber keine sicheren Systeme. FROST setzt eine sichere Erzeugung und Verteilung der Anteile voraus und begrenzt die Zahl der Beteiligten, die ein Angreifer kompromittieren darf. Die Sicherheitshinweise behandeln die Wiederverwendung von Nonces, Seitenkanäle und Protokollfehler. Signaturverfügbarkeit und Schutz vor Fälschungen sind unterschiedliche Eigenschaften.[1]
Verwahrungsdienste
Die im Oktober 2026 geprüfte Dokumentation zu Google Clouds Multi-party Compute beschreibt eine Verwahrungsplattform, die Schwellenwertsignaturen mit organisatorischen Kontrollen verbindet. Sie kennzeichnet den Dienst als Preview und beschreibt eine v1beta-API. Genannt wird ECDSA über secp256k1 für Bitcoin und EVM-kompatible Anwendungen; daraus folgt keine Unterstützung sämtlicher Blockchain-Signaturformate.[3]
Kryptographische Autorisierung unterscheidet sich zudem von automatisierten Transaktionsrichtlinien. Laut Googles Richtliniendokumentation können genügend Unterzeichner eine Transaktion autorisieren, die automatisierte Richtlinien ablehnen. Ein Richtlinienurteil muss deshalb im Kontext des Unterzeichner- und Governance-Modells des Dienstes verstanden werden.[4]
Einzelnachweise
- ↑ 1,0 1,1 1,2 RFC 9591: The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol, June 2024, introduction and security considerations.
- ↑ BIP 327: MuSig2 for BIP340-compatible Multi-Signatures, motivation and general signing flow, checked 29 October 2026.
- ↑ Google Cloud: Multi-party Compute overview, checked 29 October 2026.
- ↑ Google Cloud: Transaction policy evaluation, checked 29 October 2026.