Zum Inhalt springen
Financial Context Wiki

EIP-712-Signaturen: Domains, Digests und sichere Prüfung

EIP-712 macht strukturierte Ethereum-Nachrichten deterministisch und darstellbar; sicheres Signieren verlangt dennoch die genaue Prüfung von Domain, Typ, Wert, Nonce, Frist, Ausführung und Signaturrichtlinie.

Aktualisiert

Nur zu Bildungszwecken; stellt keine Anlageberatung oder Anlageempfehlung dar. Anlagen können zu Verlusten führen.

Direkte Antwort

EIP-712 standardisiert, wie Ethereum-Anwendungen Signaturen über typisierte strukturierte Daten beschreiben, hashen und anfordern. Eine Anfrage enthält types, primaryType, domain und message; ihr Digest lautet keccak256("\x19\x01" || domainSeparator || hashStruct(message)). Die Codierung wird dadurch deterministisch, und eine geeignete Wallet kann Felder verständlicher als einen undurchsichtigen Hash anzeigen.

Der Standard macht eine Nachricht aber nicht wahr, harmlos, widerrufbar oder wiederholungssicher. Die Anwendung muss die Befugnis an Chain und Prüfer binden, jedes Feld eindeutig definieren, Nonces und Zeitgrenzen durchsetzen, den richtigen Signatär prüfen und die Ausführung beschränken. Eine gültige Signatur belegt nur die Zustimmung zu einem exakten Digest unter einer Prüfregel, nicht Identität, informierte Absicht oder Sicherheit von Website und Vertrag.

EIP-712-Signaturen
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. Aktion und Prüfpfad bestimmen

Klären Sie, ob die Anfrage Anmeldung, Auftrag, Abstimmung, Token-Allowance, Übertragung, Relay-Aufruf oder etwas anderes autorisiert. Suchen Sie den Code, der Digest und Verbrauch der Signatur bestimmt. Bei einem extern kontrollierten Konto wird meist eine Adresse aus einer ECDSA-Signatur wiederhergestellt; bei einem Vertragskonto kann ERC-1271 isValidSignature(hash, signature) mit dem Erfolgswert 0x1626ba7e nötig sein.

2. Domain festlegen

Prüfen Sie den exakten Typ EIP712Domain und seine Werte. Standardfelder sind name, version, chainId, verifyingContract und salt; nur vorhandene Felder werden gehasht. Bestätigen Sie aktive Chain, bereitgestellten Code und vorgesehenen Prüfer unabhängig. Ein vertrauter Name, Symbol, Proxy-Label oder eine Prüfsummenadresse genügt nicht. ERC-5267 eip712Domain() kann die Domain offenlegen, ist aber optional; Proxy- und Upgrade-Verhalten bleibt zu prüfen.

3. Typgraph rekonstruieren

Beginnen Sie bei primaryType, erhalten Sie die Mitgliederreihenfolge und sammeln Sie referenzierte Structs rekursiv. encodeType hängt deren Definitionen nach Typnamen sortiert an. EIP-712 unterstützt Ganzzahlen fester Breite, address, bool, bytes1 bis bytes32, dynamische bytes und string, Arrays und Structs. Die Aliase uint und int, Festkommatypen und zyklische Werte sind nicht definiert.

4. Jeden Wert und jede Einheit decodieren

Ordnen Sie jeden Wert seinem deklarierten Typ und seiner Anwendungsbedeutung zu. Prüfen Sie vollständige Adressen, Rohinteger, Vorzeichen, Array-Reihenfolge, Empfänger, Spender, Assets, Beträge, Gebühren, Grenzen, Ziele, Calldata-Hashes und lesbare Strings. Dynamische bytes und string erscheinen in encodeData als Keccak-256-Hash ihres Inhalts; Arrays hashen verkettete Elementcodierungen, verschachtelte Structs ihr eigenes hashStruct.

5. Digest unabhängig neu berechnen

Berechnen Sie typeHash = keccak256(encodeType(primaryType)) und anschließend hashStruct(message) = keccak256(typeHash || encodeData(message)). Berechnen Sie ebenso den Domain-Separator und verbinden Sie ihn mit den ERC-191-Versionsbytes 0x19 0x01. Vergleichen Sie Frontend, Signaturbibliothek, Prüfervertrag und eine unabhängige Implementierung; gleich aussehendes JSON beweist keine gleiche typisierte Codierung.

6. Replay-, Zeit- und Ausführungsschutz prüfen

EIP-712 enthält selbst keinen Replay-Schutz. Der Prüfer muss den vorgesehenen Signatär prüfen, die richtige Nonce verbrauchen oder sperren, deadline oder Gültigkeitsfenster erzwingen, alle sicherheitskritischen Parameter binden und bei früher Einreichung durch Relayer oder Frontrunner dasselbe beabsichtigte Ergebnis erzeugen. Domain-Trennung schützt nur zwischen tatsächlich codierten Domains; fehlende oder falsche Felder können Wiederverwendung zwischen Verträgen oder Chains erlauben.

7. Minimal signieren und Ergebnis abstimmen

Lehnen Sie verborgene Felder, unerklärte Typen, unbegrenzte Werte, ferne Fristen, unbekannte Verträge, abweichende Chain-IDs, Blind-Signing-Anzeigen oder unvollständigen Ausführungskontext ab. Bewahren Sie exaktes JSON und Digest auf, nutzen Sie möglichst ein zweckgebundenes Konto und prüfen Sie Transaktion, Receipt, Events, Salden, Allowances, Nonces, Auftragsstatus und Finalität. Das Trennen einer Website widerruft weder eine nutzbare Signatur noch bereits erteilte Befugnis.

Rechenbeispiele

Beispiel 1: Typ- und Digest-Aufbau

Für Order(address maker,address token,uint256 amount,uint256 nonce,uint256 deadline) ist typeHash der Keccak-256-Hash dieser exakten Zeichenfolge einschließlich Feldreihenfolge. Der Nachrichtenhash ist keccak256(typeHash || maker || token || amount || nonce || deadline); jedes codierte Mitglied belegt 32 Bytes. Der finale Digest ergänzt 0x1901, Domain-Separator und Nachrichtenhash. Eine Änderung von amount von 250000000 auf 250000001 ändert den Digest und macht die alte Signatur ungültig.

Beispiel 2: Einheiten und Frist

250 USDC eines Tokens mit sechs Dezimalstellen werden als Rohwert 250000000, nicht 250, codiert. Bei Zeitstempel 1727000000 und Frist 1727000900 beträgt das Fenster 900 seconds = 15 minutes. Dezimalanzeige und lokale Uhr helfen nur; der Prüfer nutzt Rohinteger und seine gewählte On-Chain-Zeitregel.

Beispiel 3: Replay-Kontrolle

Ein Auftrag trägt Nonce 41 und maximal 5 ETH. Nachdem der Prüfer Nonce 41 als verbraucht markiert, muss eine zweite Einreichung trotz kryptografisch gültiger Signatur scheitern. Verbraucht der Vertrag die Nonce nicht und ist die Ausführung nicht idempotent, kann dieselbe Signatur weitere 5 ETH autorisieren; der Domain-Separator allein verhindert das nicht.

Beispiel 4: Gültigkeit einer Vertrags-Wallet

Eine 2-von-3-Vertrags-Wallet genehmigt einen Digest mit A, B und C als Signatären. A und B können ERC-1271 heute 0x1626ba7e zurückgeben lassen. Ersetzt ein Modul-Upgrade B durch D, können dieselben Signaturbytes ungültig werden: ERC-1271 darf von aktuellem Zustand, Richtlinie, Zeit und externen Aufrufen abhängen; Adresswiederherstellung allein entscheidet keine Vertragskontogültigkeit.

Risiken

  • Falsche oder fehlende chainId
  • Gefälschter oder unerwarteter verifyingContract
  • Irreführender Domain-name oder falsche version
  • Nach Upgrade geänderte Proxy-Implementierung oder Domain
  • Falscher primaryType oder ähnlich benannter Schattentyp
  • Abweichende Mitglieder-, Abhängigkeits- oder Encoder-Reihenfolge
  • Gekürzte, ersetzte oder irreführend beschriftete Adresse
  • Fehler bei Token-Dezimalstellen oder vorzeichenbehafteten Ganzzahlen
  • Verdeckter Array-Eintrag, verschachteltes Struct oder bytes-Payload
  • Unbegrenzter Betrag, weiter Umfang oder angreifergesteuerter Empfänger
  • Fehlende, alte, geteilte oder falsch verbrauchte Nonce
  • Fehlende, ferne, übergelaufene oder mehrdeutige Frist
  • Replay zwischen Chains, Verträgen, Konten oder Aktionen
  • Zurückhalten, Zensur, Frontrunning oder Umleitung durch Relayer
  • Signaturmalleabilität oder zu tolerante ECDSA-Wiederherstellung
  • Änderung von ERC-1271-Signatär, Modul, Schwelle, Zustand oder Code
  • Wallet-Darstellung, Blind Signing oder nicht unterstützter Typ
  • Frontend-JSON weicht vom Digest des Prüfers ab
  • Widerruf oder Stornierung verliert Ordnungsrennen
  • Signaturdialog mit Receipt, Zustandsänderung oder Finalität verwechselt

Häufige Missverständnisse

Irrtum 1: EIP-712-Signaturen sind Transaktionen

Es sind Off-Chain signierte Nachrichten. Ein Relayer kann sie später an einen Vertrag übermitteln; die resultierende Transaktion kann Gas verbrauchen und Zustand ändern, ohne vom Signatär gesendet zu werden.

Irrtum 2: Strukturierte Anzeige bedeutet Sicherheit

Typisierte Felder verbessern die Prüfbarkeit, doch bösartige Schemata, Werte, Verträge, Labels, versteckte Verschachtelung und unvollständige Wallet-Darstellung können täuschen.

Irrtum 3: Der Domain-Separator verhindert jedes Replay

Er trennt nur die codierte Domain. Replay innerhalb derselben Domain braucht Nonce, Frist, Stornierung, Füllstandsführung oder Idempotenz; ausgelassene Domain-Felder schaffen keine Grenze.

Irrtum 4: Die erwartete Adresse beweist die Autorisierung

Wiederherstellung belegt eine EOA-Signatur über den Digest, nicht die Anwendungssemantik. Vertragskonten erfordern ihre ERC-1271-Richtlinie statt gewöhnlicher Adresswiederherstellung.

Irrtum 5: Seite schließen oder Wallet trennen storniert die Signatur

Eine kopierte Signatur bleibt nutzbar, bis Nonce, Frist, Stornierung, Zustand oder Richtlinie des Prüfers sie ungültig macht. Entscheidend ist der relevante On-Chain-Zustand.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...