Zum Inhalt springen
Financial Context Wiki

Wallet-Signatur

Eine Wallet-Signatur belegt, dass ein Schlüssel oder Vertragskonto bestimmte Daten unter konkreten Prüfregeln freigegeben hat. Unterschiede zwischen Nachrichten, Transaktionen, Permits, Replay-Schutz und Phishing.

Aktualisiert

Nur zu Bildungszwecken; keine Anlage- oder Sicherheitsberatung. Eine bösartige Signaturanfrage kann zu unumkehrbaren Verlusten führen.

Kurzantwort

Eine Wallet-Signatur ist ein kryptografischer Nachweis, dass ein privater Schlüssel oder die Richtlinie eines Smart Accounts eine bestimmte codierte Nachricht freigegeben hat. Die Prüfung ordnet diese exakten Bytes und Regeln einem Konto zu; sie beweist weder rechtliche Identität oder Verständnis noch die Ehrlichkeit der Website-Beschreibung.

Signieren ist kein einheitlicher Vorgang. Eine Transaktionssignatur autorisiert direkt eine Netzwerktransaktion. Eine Offchain-Nachricht kann eine Anmeldung ohne Vermögensberechtigung sein oder eine später durch einen Relayer einreichbare Order, ein Token-Permit, eine Governance-Anweisung oder andere Vollmacht. Kein Gas-Hinweis bedeutet nicht kein Risiko.

Prüfe vor dem Signieren Anfragetyp, lesbare Aktion, Domain oder vorgesehenen Prüfer, Chain, Prüfvertrag, Adressen, Beträge, Nonce und Ablauf. Lehne unerklärte Hashes, unlesbare Bytes, unerwartete Felder oder unzureichend angezeigte Anfragen ab.

Wallet-Signatur
0 / 5
0 Artikel überprüft; 5 noch ungelöste Punkte

Der Abschluss dieser Überprüfung beweist nicht, dass ein Vermögenswert, eine Transaktion oder ein System sicher ist.

Funktionsweise

  1. Die Anwendung codiert Transaktion, Klartextnachricht oder typisierte Daten. Schon eine kleine Änderung erzeugt einen anderen Digest.
  2. Die Wallet zeigt decodierbare Inhalte und fragt nach Zustimmung. Der private Schlüssel bleibt in Wallet oder Signiergerät; nur die Signatur des Digests wird zurückgegeben.
  3. Der Prüfer rekonstruiert denselben Digest. Bei extern geführten Konten wird meist die Adresse wiederhergestellt oder geprüft; ein Vertragskonto kann über ERC-1271 seine aktuelle Richtlinie anwenden.
  4. Der Prüfer deutet das Ergebnis nach Anwendungsregeln. Ein Server kann eine Sitzung anlegen; ein Vertrag kann ein Permit verbrauchen, eine Order ausführen, Governance ändern oder einen anderen autorisierten Aufruf ausführen.
  5. Replay-Schutz ist anwendungsspezifisch. EIP-712 liefert typisierte Codierung und Domain-Trennung, aber keinen Replay-Schutz; die Anwendung muss Nonce, Deadline, vorgesehenen Prüfer, Chain oder eine andere Einmalgrenze erzwingen.

ERC-191 trennt signierte Daten von der normalen Ethereum-Transaktionscodierung und definiert Formate wie personal_sign. EIP-712 bindet strukturierte Felder an eine Domain mit möglichen Feldern name, version, chainId und verifyingContract. ERC-4361-Anmeldungen enthalten Domain, URI, Chain-ID, Nonce und Ausgabezeit, müssen aber auch vom Dienst geprüft werden.

Beispiel

Leah erhält beim offiziellen Dienst eine ERC-4361-Anfrage mit erwarteter Domain und URI, frischer Nonce und kurzer Gültigkeit. Sie verlangt nur Authentifizierung. Nach Prüfung signiert Leah; der Server prüft und erstellt eine Sitzung. Die Nachricht erzeugt selbst weder Token-Allowance noch Onchain-Transaktion.

Auf einer Nachahmerseite lautet der Knopf weiterhin „Anmelden“, doch die Wallet zeigt EIP-712-Permit-Daten mit Token, Spender, Betrag, Nonce und Deadline. Damit kann ein Relayer nach Vertragsregeln Ausgabeberechtigung erzeugen. Leah muss ablehnen: Der Knopftext ändert die signierten Bytes nicht.

Risiken und Kontrollen

  • Täuschende Bedeutung: Eine Seite kann Permit oder Order als Anmeldung bezeichnen. Vertraue decodierter Nutzlast und geprüftem Vertrag, nicht dem Knopf.
  • Blind Signing: Rohe Hashes und undurchsichtige Bytes verhindern Prüfung. Abbrechen, wenn Originaldaten und Ausführungspfad nicht mit einem vertrauenswürdigen Werkzeug reproduzierbar sind.
  • Falsche Domain: Ein bekannter Markenname authentifiziert weder chainId, verifyingContract, Webdomain noch URI. Prüfe jedes Feld und die vollständige Adresse unabhängig.
  • Replay oder späte Ausführung: Bis Nonce-Verbrauch oder Deadline kann ein Besitzer der Signatur sie nutzen. Verwende frische Nonces und kurze Fristen; veröffentliche keine Signatur.
  • Weite Vollmacht: Permits, Orders, Sitzungsschlüssel und Smart-Account-Aktionen können spätere Schritte ohne neue Wallet-Abfrage erlauben. Prüfe Asset, Spender, Empfänger, Betrag, Umfang und Widerruf.
  • Kompromittierter Signierer: Eine Hardware-Wallet schützt vor Schlüsselextraktion, nicht vor bösartigen Nachrichten. Bei offengelegter Seed-Phrase oder privatem Schlüssel ist das ganze Konto kompromittiert.

Nach einer verdächtigen Signatur sichere decodierte Nutzlast und Signatur ohne Veröffentlichung, trenne die Seite und bestimme das Schema. Prüfe Onchain-Freigaben oder Transaktionen auf der richtigen Chain und nutze dokumentierten Widerruf, Nonce-Ungültigmachung oder Asset-Migration. Es gibt keinen universellen Widerruf aller Offchain-Signaturen; die Seitentrennung macht sie nicht ungültig.

Häufige Irrtümer

  • „Jede Signatur bewegt Guthaben.“ Viele authentifizieren nur oder drücken eine Absicht aus; manche erlauben spätere Guthabenbewegungen.
  • „Ohne Gas ist es harmlos.“ Ein Relayer kann Gas zahlen und ein signiertes Permit, eine Order oder andere Vollmacht einreichen.
  • „EIP-712 garantiert Sicherheit.“ Es verbessert strukturierte Anzeige und Domain-Trennung, bietet aber weder Replay-Schutz noch Prüfung der Anwendungsaussage.
  • „Die wiederhergestellte Adresse beweist informierte Zustimmung.“ Sie verknüpft exakte Daten und Schlüssel unter einer Regel, nicht Identität, Verständnis oder freien Willen.
  • „Vertrags-Wallets signieren wie normale Konten.“ ERC-1271-Gültigkeit kann vom aktuellen Zustand und der Richtlinie abhängen; der Prüfer muss den Vertrag aufrufen.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...