Digitale Signaturen und Transaktionsautorisierung

Was eine Signatur autorisiert

Eine digitale Signatur ist ein kryptografischer Wert, der mithilfe eines privaten Schlüssels und eines Signaturalgorithmus über einer festgelegten Nachricht erstellt wird. Andere Teilnehmer können die Signatur anhand der Nachricht und des zugehörigen öffentlichen Schlüssels überprüfen. Bei einer Blockchain-Transaktion stellt die Nachricht im Allgemeinen eine beabsichtigte Änderung gemäß den Regeln des Netzwerks dar: die Übertragung von Werten, den Aufruf eines Programms oder die Erfüllung von Bedingungen, die an eine bestehende Ausgabe geknüpft sind. Welche exakten Bytes in dieser Nachricht enthalten sind, bestimmt, was autorisiert wird und was nicht. Eine Signatur bedeutet nicht: „Ich stimme allem zu“; sie wird für eine genau definierte Aussage verifiziert, selbst wenn eine Software diese Aussage der unterzeichnenden Person in Form einer kurzen, für Menschen verständlichen Zusammenfassung anzeigt.

Signieren und Übertragen sind unterschiedliche Vorgänge. Ein Gerät oder eine Anwendung kann eine Transaktion erstellen, eine Signatur anfordern und erst danach die signierten Bytes an einen Netzwerkknoten senden. Eine Signatur kann daher bereits existieren, bevor die Transaktion in einem Block-Explorer sichtbar ist. Nach der Übermittlung prüft das Netzwerk weiterhin ihre Gültigkeit und die Einhaltung anderer Regeln; die Aufnahme in einen Block erfolgt nicht automatisch. Lernende sollten Vorbereitung, Signierung, Übermittlung, Validierung und Aufnahme voneinander unterscheiden. Die Konsensmechanismen aus Modul 2 bestimmen, wie akzeptierte Transaktionen Teil einer gemeinsamen Historie werden; sie sind nicht selbst der kryptografische Vorgang des Signierens.

Eine Nachricht muss eindeutig sein

Serialisierung und signierbare Felder

Durch Serialisierung werden strukturierte Informationen in eine exakte Byte-Darstellung umgewandelt. Eine Anwendung könnte Empfänger, Betrag, Gebühr und Netzwerkname anzeigen; die Signaturprüfung erfolgt jedoch anhand festgelegter Bytes gemäß den Kodierungsregeln eines Protokolls. Wird nach dem Erstellen einer Signatur ein signiertes Feld geändert, schlägt die Verifizierung üblicherweise fehl. Manche Protokolle autorisieren bewusst nur eine bestimmte Teilmenge von Feldern und verwenden Signaturmodi, durch die sich ändert, welche Teile abgedeckt sind. Daher sollte ein Analyst nicht davon ausgehen, dass jede Signatur alle angezeigten Kontextinformationen bindet. Die entscheidende technische Frage lautet: An welche Felder hat dieser konkrete Signaturmodus tatsächlich gebunden?

Eine Bitcoin-artige Transaktion verbraucht zuvor nicht ausgegebene Transaktionsausgaben und schlägt neue Ausgaben vor. Der anwendbare Signatur-Hash bindet gemäß den Regeln und Hash-Typ-Flags Transaktionsinformationen ein. Eine Ethereum-artige Transaktion enthält im Allgemeinen Felder wie Ziel, Wert, Daten, Nonce und Gebührenparameter und verwendet zum Signieren eine geeignete Transaktionskodierung. Eine Solana-Transaktion signiert eine serialisierte Nachricht, die Anweisungen, Kontoinformationen und einen aktuellen Block-Hash oder eine zulässige Alternative enthält. Trotz ihrer unterschiedlichen Strukturen beruhen alle drei auf demselben Prinzip: Verifizierende müssen dieselbe beabsichtigte Nachricht prüfen, die signiert wurde.

Die Autorisierung einer Transaktion ist nicht dasselbe wie ihre Ausführung

Eine gültige Signatur ist für viele Transaktionstypen notwendig, reicht aber nicht aus, um eine erfolgreiche Zustandsänderung zu bewirken. Eine vorgeschlagene Transaktion kann einen ungültigen Sequenzzähler, ein unzureichendes Guthaben, einen abgelaufenen aktuellen Block-Hash, eine nicht erfüllte Ausgabebedingung oder einen Fehler bei der Ausführung eines Vertrags aufweisen. In kontobasierten Systemen kann die Signatur gültig sein, obwohl die Ausführung fehlschlägt und eine Bearbeitungsgebühr erhoben wird. In anderen Fällen erreicht die Transaktion die Blockchain möglicherweise überhaupt nicht. Um eine strittige Übertragung zu erklären, sind daher mindestens zwei Fragen zu beantworten: Wurde die Nachricht gemäß den Netzwerkregeln ordnungsgemäß autorisiert, und was ergaben die tatsächliche Ausführung oder Abwicklung durch das Netzwerk?

Eine Autorisierung kann auch mehr als einen einzelnen Schlüssel umfassen. Eine Ausgaberegel kann mehrere Signaturen verlangen, zeitabhängige Bedingungen auferlegen oder Programmlogik verwenden. Ein Smart-Contract-Konto kann Anweisungen anhand seines Codes validieren, anstatt sich auf ein einzelnes herkömmliches extern kontrolliertes Konto zu stützen. Solche Systeme sollten nicht als frei von Signaturen beschrieben werden, nur weil im selben Feld keine gewöhnliche Kontosignatur erscheint. Die übergeordnete Erkenntnis lautet: Autorisierungsregeln sind Teil des Protokolls oder Programms und müssen im jeweiligen Kontext gelesen werden. Governance- und Verwahrkontrollen sind eigene Themen, die später im Kurs behandelt werden.

Replay und Kontextbindung

Ein Replay liegt vor, wenn gültige signierte Daten in einem Kontext wiederverwendet werden, in dem sie nicht zur Autorisierung einer weiteren Aktion bestimmt waren. Das Transaktionsdesign kann das Replay-Risiko durch netzwerkspezifische Kennungen, Sequenzzähler, Ablaufdaten oder andere signierte Kontextinformationen verringern. Ethereum Improvement Proposal (EIP) 155, Simple Replay Attack Protection, führte für relevante ältere Ethereum-Transaktionen eine netzwerkkennzeichnende Information in die Signaturkonstruktion ein. Moderne Transaktionsformate enthalten ebenfalls Regeln zum Netzwerkkontext, aber die Implementierungen unterscheiden sich. Das allgemeine Prinzip ist einfach: Verifizierende müssen nicht nur wissen, ob eine Signatur mathematisch gültig ist, sondern auch, ob sie für dieses Netzwerk, diesen Transaktionstyp und diese Verwendung gültig ist.

Signaturanfragen und menschliches Verständnis

Eine Benutzeroberfläche kann „Genehmigen“ oder „Signieren“ anzeigen, obwohl die zugrunde liegenden Vorgänge technisch unterschiedliche Folgen haben. Bei Ethereum-Token-Verträgen kann beispielsweise eine Genehmigung für eine Ausgabeberechtigung einem separaten Konto oder Vertrag erlauben, Token später innerhalb der Regeln des Vertrags zu bewegen. Eine einfache Übertragung eines nativen Vermögenswerts ist dagegen eine direkte Transaktion. Eine Off-Chain-Nachrichtensignatur kann eine spätere Aktion autorisieren, wenn ein Dienst oder Vertrag diese signierte Nachricht anerkennt. Weder das Wort „Signatur“ noch das Ausbleiben einer unmittelbaren Token-Bewegung beweist, dass die Anfrage harmlos ist. In einem Grundlagenkurs sollten Prüfer lernen zu fragen, welche konkrete Berechtigung erteilt wird und ob deren Umfang gemäß dem jeweiligen Design zeitlich oder betragsmäßig begrenzt oder widerrufbar ist.

Algorithmen und Signaturnachweise

NIST FIPS 186-5, Digital Signature Standard, legt unter anderem Verfahren wie ECDSA und EdDSA fest. Bitcoin Improvement Proposal 340 spezifiziert ein Schnorr-Signaturverfahren über secp256k1 für die Taproot-Umgebung von Bitcoin. Die Netzwerkimplementierungen legen fest, wie diese Algorithmen genau angewendet und kodiert werden. Es reicht nicht aus, eine Signatur als „ECDSA“ zu bezeichnen, ohne das tatsächliche Nachrichtenformat, die Kurve, die Verifizierungsregeln und die Protokollversion zu prüfen. Systeme können außerdem vor oder während des Signierens kryptografische Hashes verwenden; das Hashen der Nachricht und das Signieren der Nachricht sind miteinander verbundene, aber nicht identische Vorgänge.

So sollte ein Prüfer eine signierte Aktion dokumentieren

1. Erfassen Sie das Netzwerk, den Transaktionstyp und, sofern verfügbar, die genaue Transaktionskennung oder die serialisierten Daten.
2. Stellen Sie fest, wofür die angezeigten Felder zu unterzeichnender Person, Ziel, Vertrag, Betrag, Gebühr und Daten stehen.
3. Bestätigen Sie den Geltungsbereich der Signatur sowie den anwendbaren Sequenz- oder Replay-Schutzkontext.
4. Unterscheiden Sie die Gültigkeit der Signatur vom Transaktionsstatus, dem Ausführungsergebnis und der organisatorischen Autorisierung.

Diese Methode vermeidet zwei entgegengesetzte Fehler. Der erste besteht darin, eine erfolgreiche Transaktion als Beweis dafür zu behandeln, dass eine namentlich genannte Person sie wissentlich genehmigt hat. Der zweite besteht darin, eine gültige Signatur als Beweis dafür zu behandeln, dass die Transaktion erfolgreich gewesen sein muss. Technische Belege können eine Untersuchung unterstützen, aber die Zuordnung zu einer Person und die rechtliche Absicht beruhen auf Tatsachen, die üblicherweise nicht in einer Blockchain enthalten sind. Wenn einem Analysten nur Screenshots vorgelegt werden, ist es besser, die entsprechenden Blockchain-Datensätze unabhängig abzurufen, bevor eine Schlussfolgerung festgehalten wird. Das nächste Modul behandelt praktische Fragen zur Aufbewahrung von Schlüsseln und zur Gestaltung der Verwahrung, nicht die hier behandelte mathematische Funktionsweise.

Prüfungsschwerpunkt: Benennen Sie die fünf Phasen einer typischen signierten Transaktion, erklären Sie, warum die exakten signierbaren Bytes und der Replay-Schutz wichtig sind, und unterscheiden Sie eine gültige Signatur von erfolgreicher Ausführung, bestätigter Aufnahme in einen Block und organisatorischer Genehmigung. Beachten Sie, dass Signaturen je nach Protokollregeln unterschiedliche Geltungsbereiche haben können.