Was ist eine Wallet-Signaturanforderung? Was genehmige ich eigentlich?

Grundlegendes zu Wallet-Signaturanfragen

1. Eine Wallet-Signaturanforderung ist eine kryptografische Aufforderung, die von einer dApp, einem Smart Contract oder einem Protokoll initiiert wird, um die Absicht des Benutzers zu überprüfen, bevor eine Aktion in der Kette ausgeführt wird.

2. Dabei geht es nicht um die direkte Überweisung von Geldern, sondern darum, dass der Benutzer eine Nachricht oder einen Transaktions-Hash mit seinem privaten Schlüssel kryptografisch signiert.

3. Die Unterschrift beweist den Besitz der Wallet-Adresse und bestätigt die Zustimmung zu den in der Nutzlast kodierten Bedingungen – wie z. B. Berechtigungsdelegation, NFT-Minting oder Vertragsinteraktion.

4. Im Gegensatz zu herkömmlichen Anmeldungen werden keine Anmeldeinformationen weitergegeben. Es wird lediglich ein überprüfbarer kryptografischer Beweis generiert und an das Blockchain-Netzwerk gesendet.

5. Bei jeder Signaturanforderung werden Metadaten angezeigt, einschließlich der Domäne der verbundenen dApp, der Ketten-ID und der genauen Funktion, die aufgerufen wird – obwohl Benutzer diese Felder bei schnellen Genehmigungsabläufen oft übersehen.

Was hinter der Signatur passiert

1. Wenn eine dApp eine Signaturanforderung auslöst, erstellt sie je nach Kontext und Kettenunterstützung eine Datenstruktur vom Typ EIP-712 oder eine einfache personal_sign-Nachricht.

2. Der Wallet-Client (z. B. MetaMask, Phantom, Trust Wallet) stellt diese Struktur in eine für Menschen lesbare Form um und extrahiert kritische Parameter wie Spenderadresse, Token-Betrag, Frist und Nonce.

3. Das Wallet wendet dann eine ECDSA-Signierung mit dem privaten Schlüssel des Benutzers auf den keccak256-Hash der strukturierten Eingabe an – wodurch eine 65-Byte-Signaturzeichenfolge entsteht.

4. Diese Signatur wird außerhalb der Kette an den dApp-Server übermittelt oder in eine Transaktionsnutzlast eingebettet, die für die On-Chain-Verifizierung durch Wiederherstellung der Adresse des Unterzeichners bestimmt ist.

5. Kein privater Schlüssel verlässt jemals das Gerät; Der kryptografische Vorgang erfolgt lokal innerhalb der sicheren Enklave oder Erweiterungssandbox.

Risiken des blinden Signierens

1. Benutzer, die Signaturanfragen genehmigen, ohne die Payload-Details zu prüfen, setzen sich der Gefahr unbefugter Token-Genehmigungen, Phishing-gesteuerter Vertragsinteraktionen oder böswilliger Genehmigungssignaturen aus.

2. Der BYBIT-Exploit im Wert von 1,4 Milliarden US-Dollar betraf kompromittierte Safes mit mehreren Signaturen, bei denen Angreifer die Signaturlogik manipulierten, um stETH und ETH durch gefälschte Genehmigungsaufrufe zu entleeren.

3. Ältere Ethereum-Signaturen verfügen nicht über eine integrierte Domänentrennung, was Replay-Angriffe über Ketten hinweg ermöglicht, wenn identische Nachrichten in verschiedenen Netzwerken ohne ordnungsgemäße Ketten-ID-Bindung signiert werden.

4. Einige Wallets können komplexe EIP-712-Strukturen nicht korrekt wiedergeben und zeigen abgeschnittene oder irreführende Werte an – insbesondere wenn verschachtelte Strukturen dynamische Arrays oder externe Vertragsaufrufe enthalten.

5. Schwachstellen bei der Wiederverwendung von Signaturen haben dazu geführt, dass Limit-Orders vorab ausgeführt werden und unbefugter Zugriff auf Tresore erfolgt, wenn Nonces oder Fristen in der signierten Nutzlast falsch konfiguriert sind.

Schutzmaßnahmen auf Wallet-Ebene

1. Moderne Wallets implementieren Domänenbindungsprüfungen, die Signaturen ablehnen, es sei denn, der anfordernde Ursprung stimmt mit einer verifizierten dApp-Domäne überein, die in ihrer Zulassungsliste gespeichert ist.

2. Bestimmte Hardware-Wallets erfordern eine explizite Bestätigung jedes Parameterfelds, bevor der Signaturvorgang eingeleitet wird, um eine versehentliche Autorisierung versteckter Zertifikate zu verhindern.

3. Wallet-Anbieter integrieren zunehmend Echtzeit-Vertragsanalyse-Engines, die vor der Signaturerstellung bekannte bösartige Adressen oder verdächtige Funktionsselektoren kennzeichnen.

4. Einige Verwahrungslösungen der Enterprise-Klasse erzwingen richtlinienbasierte Signaturregeln – zum Beispiel die Blockierung aller Genehmigungssignaturen, sofern diese nicht von auf der Whitelist befindlichen Governance-Multisigs ausgestellt werden.

5. Browsererweiterungen zeigen jetzt Warnungen an, wenn sie nicht übereinstimmende Ketten-IDs, doppelte Nonces oder nicht erkannte Funktionssignaturen erkennen, die in die Anfrage eingebettet sind.

Häufig gestellte Fragen

F: Gibt das Signieren einer Nachricht einer dApp die Kontrolle über mein Wallet? Das Signieren allein gewährt keine Kontrolle. Kontrolle entsteht nur, wenn die signierte Nutzlast einen Smart Contract autorisiert, Vermögenswerte auszugeben oder privilegierte Funktionen auszuführen – wie etwa die Genehmigung eines ERC-20-Spenders oder den Aufruf einer transferFrom-Methode.

F: Warum wird bei einigen Signaturanfragen „0x…“ anstelle von lesbarem Text angezeigt? Dies tritt auf, wenn die dApp hexadezimal codierte Rohdaten anstelle strukturierter EIP-712-Eingaben sendet. Wallets können die Bedeutung beliebiger Byte-Strings nicht analysieren und zeigen daher nur die Hash-Darstellung an.

F: Kann ich eine Signatur widerrufen, nachdem ich sie genehmigt habe? Nein. Kryptografische Signaturen sind unveränderlich und zustandslos. Für den Widerruf sind Aktionen in der Kette erforderlich – zum Beispiel das Zurücksetzen einer ERC-20-Zulage auf Null oder das Stornieren einer ausstehenden Bestellung über die vorgesehene Stornierungsfunktion.

F: Sind Signaturanfragen in allen Blockchains gleich? Nein. Ethereum verwendet personal_sign und eth_signTypedData, Solana verlässt sich auf die TransactionMessage-Serialisierung, wobei neuere Versionen die Domänentrennung erzwingen, während Cosmos SDK-Ketten Amino- oder Protobuf-basierte Sign-Doc-Formate verwenden – jedes mit unterschiedlichen Sicherheitsannahmen und Rendering-Verhalten.