EIP-712 erklärt: Signaturen, Typed Data, Domain Separator und Phishing-Risiken
Einleitung
Bei einer Krypto-Wallet ist nicht jede Unterschrift eine Überweisung. Oft fordert eine Anwendung Dich auf, eine Nachricht zu signieren, ohne unmittelbar eine Blockchain-Transaktion auszulösen. Genau hier setzt EIP-712 an: Der Ethereum-Standard definiert eine nachvollziehbare Struktur für signierbare Daten. Er kann Wallets helfen, Felder wie Betrag, Empfänger, Vertrag und Frist verständlicher darzustellen. Allerdings bedeutet eine lesbare Nachricht keineswegs, dass sie ungefährlich ist. Eine Signatur kann später in einem Smart Contract verwendet werden, um Rechte auszuüben oder Token zu bewegen. In diesem Fachartikel lernst Du, wie EIP-712 funktioniert, wie Du Signaturanfragen prüfst und wo die Grenzen der Technik liegen.
Was ist EIP-712?
EIP-712 ist ein Ethereum Improvement Proposal für das Hashing und Signieren typisierter strukturierter Daten. Statt einen beliebigen, für Menschen kaum verständlichen Byte-String zu unterschreiben, kann eine Anwendung einen Datensatz mit benannten Feldern und definierten Typen vorlegen. Eine Wallet kann daraus eine besser lesbare Bestätigung erzeugen. Der Standard beschreibt die Datenstruktur, das deterministische Hashing und eine sogenannte Domain Separation. Er legt nicht fest, dass jede Anwendung ehrlich handelt, und garantiert keine Wiederholungssperre. Seine technische Spezifikation ist auf eips.ethereum.org öffentlich dokumentiert. Wichtig ist die Unterscheidung zwischen einer kryptografisch gültigen Unterschrift und einer wirtschaftlich sinnvollen Zustimmung: Nur Letztere kannst Du selbst beurteilen.
Warum strukturierte Signaturen notwendig sind
Eine gewöhnliche Transaktion enthält direkt eine Aktion, die das Netzwerk verarbeitet. Eine Off-Chain-Signatur kann dagegen zunächst nur eine Nachricht sein. Die Nachricht wird später beispielsweise an einen Vertrag übergeben, der sie verifiziert. Das spart in bestimmten Abläufen eine eigene On-Chain-Freigabetransaktion, verschiebt aber einen Teil der Prüfung in die Anwendung und in den Smart Contract. Wenn ein Wallet nur einen unverständlichen Hex-Wert zeigt, kann ein Nutzer die Absicht kaum beurteilen. EIP-712 verbessert die Möglichkeit, Bedeutung und Kontext darzustellen. Die konkrete Benutzeroberfläche entscheidet jedoch, wie viele Felder wirklich sichtbar sind. Ein irreführender Titel oder eine versteckte Berechtigung bleibt auch bei korrekter Kryptografie gefährlich.
Die vier Bausteine: types, primaryType, domain und message
Ein EIP-712-Datensatz enthält typischerweise die Typdefinitionen, den primären Datentyp, die Domain und die eigentliche Nachricht. Unter types stehen die Felder und deren Typen, beispielsweise address, uint256 oder string. primaryType legt fest, welche Struktur signiert wird. domain beschreibt den Gültigkeitskontext; message enthält die konkreten Werte. Ein hypothetischer Auftrag könnte einen Tokenvertrag, eine Wallet-Adresse, einen Betrag und eine Frist nennen. Diese Felder sind nicht automatisch Pflichtfelder für jeden Anwendungsfall. Entwickler bestimmen die Struktur, weshalb Du nie allein aus dem Begriff EIP-712 auf eine bestimmte Sicherheitsfunktion schliessen solltest. Für den Nutzer ist besonders wichtig, dass eine Wallet alle wirtschaftlich relevanten Werte transparent aufschlüsselt.
Domain Separator: Wozu Name, Chain-ID und Vertragsadresse dienen
Die Domain Separation soll verhindern, dass gleich strukturierte Nachrichten unterschiedlicher Anwendungen ohne Weiteres austauschbar sind. Übliche Domain-Felder sind name, version, chainId und verifyingContract; die Spezifikation kennt auch salt. Eine Anwendung kann damit die Nachricht an ein bestimmtes Protokoll, eine Version, eine Blockchain und einen prüfenden Vertrag binden. Die EIP-712-Spezifikation erlaubt unterschiedliche Feldkombinationen. Deshalb darfst Du nicht unterstellen, dass jedes signierte Objekt alle vier Angaben enthält. Bei einer Anfrage solltest Du die angezeigte Chain-ID und den verifyingContract mit der unabhängig recherchierten Dokumentation vergleichen. Ein bekannter Name allein ist kein Beweis: Eine betrügerische Anwendung kann sich in der Oberfläche ähnlich nennen.
Wie Hashing und Signatur zusammenhängen
Die Daten werden nach festen Regeln kodiert und gehasht. Der Standard verwendet unter anderem einen typeHash und hashStruct, sodass nicht nur Feldwerte, sondern auch ihre Typstruktur in die kryptografische Verarbeitung eingehen. Der signierte Digest verbindet den Domain Separator mit dem Hash der Nachricht und einem festgelegten Präfix. Das Ergebnis kann mit dem privaten Schlüssel eines entsprechenden Kontos signiert werden. Auf diese Weise lassen sich strukturierte Informationen kryptografisch eindeutig referenzieren. Die Signatur bestätigt aber nicht, dass ein bestimmter Mensch den Inhalt vollständig gelesen hat. Sie beweist auch nicht, dass der zugrunde liegende Vertrag frei von Fehlern ist. Genau deshalb bleibt die inhaltliche Kontrolle der Nachricht unerlässlich.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Gutscheincode: AUSWANDERNSCHWEIZ.
Was eine EIP-712-Signatur nicht garantiert
Der Standard schützt nicht automatisch vor Replay-Angriffen. Das steht ausdrücklich in der ursprünglichen Spezifikation. Eine Anwendung muss selbst sicherstellen, dass dieselbe Autorisierung nicht unzulässig mehrfach ausgeführt werden kann, etwa durch Nonces, Fristen oder einen zustandsabhängigen Verbrauch der Berechtigung. EIP-712 garantiert ebenso wenig, dass eine Signatur nicht von einem Dritten vor Dir eingereicht wird. Wenn der Vertrag bei einer solchen Reihenfolge unerwartete Ergebnisse erzeugt, liegt ein Anwendungsproblem vor. Auch eine korrekte Domain Separation ersetzt keine Berechtigungsprüfung. Sicherheit entsteht aus dem Zusammenspiel von Datenformat, Wallet-Darstellung, Vertragslogik, Schlüsselverwaltung und dem Verhalten des Nutzers.
Praxisbeispiel: Eine begrenzte Token-Freigabe
Stell Dir vor, Du möchtest einen Tokenbetrag im Gegenwert von 200 CHF für eine DeFi-Anwendung freigeben. Die Anwendung bittet Dich um eine strukturierte Signatur mit einem maximalen Tokenbetrag, einem Spendervertrag und einer Deadline. Du musst prüfen, ob tatsächlich nur der beabsichtigte Vertrag und die gewünschte Menge autorisiert werden. Eine Zahl in kleinsten Token-Einheiten kann dabei leicht falsch interpretiert werden. Bei sechs Dezimalstellen entsprechen 200'000'000 Basiseinheiten genau 200 Token, nicht 200 Millionen Token. Ob diese Token 200 CHF wert sind, hängt vom Kurs ab. Eine unbegrenzte Freigabe ist etwas anderes als eine zeitlich und mengenmässig begrenzte Autorisierung.
EIP-712 ist nicht ERC-2612
EIP-712 beschreibt das allgemeine Format strukturierter Signaturen. ERC-2612 definiert dagegen eine konkrete Permit-Funktion für kompatible ERC-20-Token, die Signaturen verwendet, um Tokenfreigaben abzuwickeln. Nicht jeder ERC-20 unterstützt Permit, und nicht jede EIP-712-Nachricht ist eine Tokenfreigabe. Auch andere Anwendungen, beispielsweise Order-Signaturen oder Governance-Abstimmungen, können strukturierte Daten nutzen. Wer diese Ebenen verwechselt, versteht möglicherweise die Tragweite einer Signatur nicht. Der bestehende Artikel zu ERC-2612 auf auswandernschweiz.ch erklärt die spezielle Tokenfreigabe ausführlicher. Hier geht es um die allgemeinere Frage, wie strukturierte Nachrichten aufgebaut und sicher beurteilt werden.
Unterschied zu personal_sign und einer normalen Transaktion
Bei personal_sign wird eine Nachricht nach einem anderen Ethereum-Signaturschema verarbeitet. Eine Wallet kann dabei einen Text anzeigen, ohne die semantische Struktur eines komplexen Vertragsauftrags zu kennen. EIP-712 liefert dagegen benannte Felder und Typen, die die Darstellung erleichtern. Eine gewöhnliche Blockchain-Transaktion wird direkt an das Netzwerk gesendet und verbraucht bei Ausführung grundsätzlich Gas. Eine Off-Chain-Signatur kann zunächst ohne Netzwerkgebühr entstehen; erst eine spätere Verwendung im Smart Contract kann Kosten verursachen. Keine dieser Methoden ist pauschal sicher oder unsicher. Entscheidend ist, was autorisiert wird, welche Vertragsregeln gelten und wie transparent die Wallet den Vorgang darstellt.
Phishing mit signierten Nachrichten
Ein Angreifer kann eine gefälschte Website als Airdrop, Wallet-Prüfung oder vermeintliches Sicherheitsupdate präsentieren. Die Seite fordert eine EIP-712-Signatur an und behauptet, es handle sich lediglich um eine Anmeldung. Tatsächlich kann die Nachricht eine weitreichende Berechtigung enthalten. Besonders gefährlich sind unverständliche Contract-Adressen, grosse Tokenbeträge, lange Fristen und fehlende Angaben über den Empfänger. Eine echte kryptografische Signatur ist nicht gleichbedeutend mit einer legitimen Anfrage. Prüfe die Website-Adresse unabhängig und bestätige keine Nachricht, deren wirtschaftliche Folgen Du nicht verstehst. Bei einer unklaren Darstellung solltest Du den Vorgang abbrechen statt auf Vermutungen zu vertrauen.
Replay-Angriffe, Nonces und Deadlines
Eine Nonce ist ein Wert, mit dem eine Anwendung beispielsweise die einmalige Verwendung einer Signatur sicherstellen kann. Eine Deadline begrenzt die zeitliche Gültigkeit. Beides muss durch den prüfenden Vertrag korrekt durchgesetzt werden; bloss sichtbare Felder genügen nicht. Stell Dir eine Autorisierung vor, die bis 18 Uhr gültig ist und eine bestimmte Nonce enthält. Wird die Nonce nach erfolgreicher Nutzung verbraucht, soll dieselbe Nachricht nicht nochmals dieselbe Berechtigung auslösen. Fehlt diese Prüfung, kann eine wiederholte Einreichung möglich sein. Auch die Domain muss korrekt gewählt werden, damit Signaturen nicht unbeabsichtigt auf anderen Netzwerken oder Verträgen akzeptiert werden. Die genaue Schutzwirkung hängt vom Implementierungscode ab.
Smart-Contract-Wallets und ERC-1271
Nicht jede Wallet wird durch genau einen privaten Schlüssel kontrolliert. Smart-Contract-Wallets können mehrere Unterschriften, Guardians oder andere Prüfregeln verlangen. ERC-1271 bietet dafür eine Schnittstelle, mit der ein Vertrag die Gültigkeit einer Signatur nach seiner eigenen Logik beurteilt. Eine Anwendung, die nur klassische EOA-Signaturen erwartet, kann deshalb mit einer Contract-Wallet scheitern. EIP-712 und ERC-1271 behandeln unterschiedliche Ebenen: Das eine strukturiert den signierten Inhalt, das andere erlaubt Vertragskonten eine eigene Signaturprüfung. Wer Smart Wallets nutzt, sollte auf kompatible Anwendungen, transparente Berechtigungen und überprüfbare Vertragsimplementierungen achten. Eine schöne Signaturanzeige ersetzt auch hier keinen sicheren Wallet-Vertrag.
Gasgebühren und wirtschaftliche Kosten
Das Erzeugen einer Off-Chain-Signatur ist nicht automatisch eine kostenpflichtige Ethereum-Transaktion. Wird die Signatur später on-chain verarbeitet, können Gebühren entstehen. Die tatsächliche Höhe hängt von Netzwerk, Gasverbrauch und Auslastung ab. Ein hypothetisches Beispiel: Eine direkte Freigabe kostet 0.80 CHF, ein anschliessender Swap 1.20 CHF. Wenn eine kompatible Permit-Lösung einen separaten Freigabeschritt einspart, könnten 0.80 CHF vermieden werden. Die endgültige Swap-Transaktion kann aber zusätzliche Signaturprüfung enthalten und dadurch teurer werden als 1.20 CHF. Aus diesen Zahlen lässt sich kein allgemeines Sparversprechen ableiten. Vergleiche immer die Gesamtkosten inklusive Dienstleistungsgebühren und möglicher Kursabweichungen.
Wallet-Anzeige: Welche Felder Du kontrollieren solltest
Beginne bei der Domain: Welche Anwendung und Version werden angegeben? Stimmen Chain-ID und verifyingContract mit verlässlichen Angaben überein? Prüfe anschliessend die konkrete Nachricht: Wer erhält Rechte, für welchen Token, in welcher Höhe, mit welcher Frist und unter welchen Bedingungen? Wenn Zahlen in Basiseinheiten dargestellt werden, rechne sie anhand der dokumentierten Dezimalstellen um. Achte auf verschachtelte Strukturen und ungewöhnliche Datentypen. Eine Wallet kann Felder verkürzen oder technisch kodiert anzeigen. Wenn Du die kritischen Werte nicht vollständig sehen kannst, ist die Signatur nicht ausreichend prüfbar. Verlasse Dich nicht auf die Überschrift des Pop-ups, sondern auf die tatsächlich signierten Daten.
Warum Domain Separation allein nicht genügt
Ein korrekt angegebener verifyingContract kann trotzdem einen gefährlichen Vertrag bezeichnen. Ebenso kann eine bekannte Anwendung durch eine kompromittierte Website oder ein manipuliertes Frontend falsche Werte zur Signatur vorlegen. Domain Separation hilft, Kontexte kryptografisch zu unterscheiden, bewertet aber nicht die Vertrauenswürdigkeit des Kontexts. Auch Upgrade-Rechte, Admin-Schlüssel und Proxy-Verträge können die spätere Ausführung beeinflussen. Prüfe deshalb bei grösseren Beträgen die Vertragsadresse über eine unabhängige Quelle, dokumentierte Funktionen und gegebenenfalls vorhandene Auditberichte. Ein Audit ist keine Garantie. Eine Signatur sollte immer auf den kleinsten notwendigen Umfang begrenzt sein, soweit das verwendete Protokoll dies technisch ermöglicht.
EIP-712 bei DEX und DeFi
Dezentrale Börsen und DeFi-Protokolle können signierte Aufträge ausserhalb der Blockchain sammeln und später ausführen lassen. Ein Nutzer kann dadurch einen Auftrag autorisieren, ohne selbst jede Aktion unmittelbar an die Blockchain zu senden. Dabei entstehen besondere Fragen: Wer darf den Auftrag einreichen? Wie lange bleibt er gültig? Gibt es Mindest- oder Höchstpreise? Können Teilfüllungen stattfinden? Welche Nonce verhindert eine unerwünschte Wiederholung? Diese Bedingungen sind protokollspezifisch und dürfen nicht aus EIP-712 allein abgeleitet werden. Achte zusätzlich auf Slippage, Liquidität, MEV und mögliche Smart-Contract-Schwachstellen. Auch eine perfekt signierte Order kann wirtschaftlich nachteilig sein, wenn ihre Konditionen schlecht gewählt wurden.
Werbung / Affiliate-Link: Relai ist eine Bitcoin-App. Bei Nutzung unseres Links oder Codes können wir eine Provision erhalten. Gutscheincode: AUSWANDERNSCHWEIZ.
Krypto-Sicherheit: Praktischer Prüfablauf
Nutze für unbekannte Anwendungen möglichst eine separate Wallet mit begrenztem Guthaben. Öffne Dienste über selbst gespeicherte Adressen statt über Werbeanzeigen oder Direktnachrichten. Lies die vollständigen Signaturdaten und vergleiche kritische Vertragsadressen mit unabhängigen Quellen. Vermeide unbegrenzte Berechtigungen, wenn eine engere Freigabe verfügbar ist. Prüfe aktive Tokenfreigaben regelmässig und widerrufe nicht mehr benötigte Rechte. Ein Widerruf einer On-Chain-Freigabe macht eine bereits erfolgte schädliche Transaktion nicht rückgängig. Halte Seed Phrase und Private Keys offline und gib sie niemals auf einer Website ein. Trenne langfristige Verwahrung von experimentellen DeFi-Anwendungen.
Schweiz: Steuerliche und regulatorische Einordnung
Eine Signatur ist nicht automatisch ein steuerpflichtiger Verkauf oder eine Übertragung. Entscheidend sind die tatsächlich ausgelösten wirtschaftlichen Vorgänge und die steuerliche Situation der betreffenden Person. Werden durch eine signierte Autorisierung Token getauscht, übertragen oder Erträge erzielt, können sich daraus andere Fragen ergeben. Die blosse Verwendung von EIP-712 entscheidet nicht über die steuerliche Behandlung. Ebenso wenig begründet ein Signaturstandard eine FINMA-Bewilligung oder garantiert die Sicherheit eines Anbieters. Bei Verwahrdiensten sind die konkreten Kontrollrechte, Verträge und möglichen Gegenparteirisiken relevant. Für verbindliche steuerliche und rechtliche Fragen solltest Du die zuständigen Behörden und qualifizierte Fachpersonen konsultieren.
FAQ: Ist EIP-712 sicher?
EIP-712 ist ein etablierter technischer Standard für strukturierte Signaturen. Er kann die Verständlichkeit erhöhen, verhindert aber keine betrügerischen Vertragsinhalte. Muss ich für jede Signatur Gas bezahlen? Nein, eine reine Off-Chain-Signatur benötigt nicht zwingend eine Blockchain-Transaktion; die spätere Ausführung kann Gebühren auslösen. Kann ich eine Signatur zurückholen? Eine bereits weitergegebene Signatur lässt sich nicht einfach aus der Welt löschen. Ob sie durch Fristablauf, Nonce-Verbrauch oder einen anderen Mechanismus unwirksam wird, hängt von der Anwendung ab. Ist eine EIP-712-Signatur gleich einer Permit-Freigabe? Nein, Permit ist nur eine mögliche konkrete Verwendung strukturierter Signaturen.
FAQ: Was bedeutet verifyingContract?
Das Feld bezeichnet den Vertrag, der im jeweiligen Domain-Kontext die Signatur prüfen soll. Es ist nicht automatisch die Website-Adresse oder der Tokenempfänger. Kann eine Signatur auf einer anderen Chain funktionieren? Eine korrekt verwendete Chain-ID kann die Gültigkeit auf ein Netzwerk begrenzen, doch die konkrete Implementierung muss den Schutz tatsächlich berücksichtigen. Warum zeigt meine Wallet Hex-Daten? Möglicherweise unterstützt sie die Darstellung der Struktur nicht vollständig oder die Anwendung verwendet ein ungeeignetes Format. Unverständliche Signaturanfragen solltest Du nicht blind bestätigen. Können Hardware-Wallets EIP-712 signieren? Das hängt von Gerät, Firmware, Wallet-Software und unterstützten Datenstrukturen ab; eine allgemeine Kompatibilitätszusage wäre unseriös.
Fazit
EIP-712 macht strukturierte Ethereum-Signaturen technisch standardisierbar und potenziell verständlicher. Sein Wert liegt in der eindeutigen Kodierung von Typen, Nachrichten und Gültigkeitskontexten. Die entscheidende Grenze bleibt: Ein Standard für das Signieren ist kein Standard für die Sicherheit jeder denkbaren Anwendung. Replay-Schutz, Fristen, Nonces, Vertragsberechtigungen und verständliche Wallet-Anzeigen müssen separat richtig umgesetzt werden. Wer Signaturen als echte Autorisierungen behandelt, schützt sich besser vor Phishing als jemand, der sie für harmlose Login-Bestätigungen hält. Dieser Artikel dient der allgemeinen Information und ist keine individuelle Anlageberatung. Kryptowährungen und DeFi-Anwendungen können erhebliche Verluste bis hin zum Totalverlust verursachen.
Kommentare