EIP-7730 sofort implementieren

Der jüngste Hackerangriff auf die Kryptobörse Bybit, bei dem 1,5 Milliarden US-Dollar entwendet wurden, legt eine seit Jahren unterschätzte Schwachstelle im Web3-Ökosystem offen. Zwar waren eine kompromittierte Lieferkette und fehlende Signaturprüfungen auf separaten Geräten die unmittelbaren Ursachen, doch der Vorfall verweist auf grundlegende Sicherheitsprobleme, die alle Wallet-Nutzer betreffen – nicht nur große Handelsplattformen.

Die zentrale Frage lautet: Haben durchschnittliche Nutzer genügend Informationen, um ihre Transaktionen zuverlässig zu validieren? Die ernüchternde Antwort lautet: nein. Von Anwendern zu erwarten, dass sie Signaturen auf mehreren Geräten gegenprüfen, ist nicht realistisch. Kaum jemand überprüft regelmäßig Calldata oder verifiziert Transaktionen mit mehreren Methoden, bevor eine Signatur erfolgt. Dies zeigte sich bereits im „Custodial Stablecoin Rekt Test“ von Trail of Bits, in dem die Forscher aufzeigten, wie unrealistisch die aktuellen Sicherheitsanforderungen an Nutzer sind.

Als Lösung verweisen die Experten von Trail of Bits auf den Standard EIP-7730. Dieser ermöglicht es Hardware-Wallets, Transaktionen zu entschlüsseln, sodass Nutzer nachvollziehen können, welche Aktion sie tatsächlich autorisieren. Dapps, die EIP-7730 implementieren, könnten sich damit klar von der Konkurrenz abheben. Mit der wachsenden Zahl hochkarätiger Angriffe durch Blind Signing steigt der Druck auf Entwickler, ihren Nutzern bessere Sicherheitsmechanismen zu bieten.

Blind Signing: ein untragbares Risiko

Die derzeitigen Sicherheitsanforderungen an Anwender verdeutlichen die Problematik:

• Abgleich der Transaktions-Calldata mit der beabsichtigten Aktion am Arbeitsplatzrechner

• Bestätigung, dass der Transaktions-Hash auf dem Rechner mit dem der Hardware-Wallet übereinstimmt

• Überprüfung von Hash und Calldata auf einem weiteren separaten Gerät

Dieser Prozess ist zwar theoretisch sicher, für die breite Masse jedoch kaum durchführbar. Nutzer müssten mehrere Minuten aufbringen, um jede Transaktion auf verschiedenen Geräten zu kontrollieren. Damit wird deutlich: Für eine breite Akzeptanz von Dapps muss Sicherheit gewährleistet sein, ohne dass die Benutzerfreundlichkeit darunter leidet.

Das Problem der blinden Signaturen

Das Kernproblem liegt in blinden Signaturen: Benutzer werden aufgefordert, Daten zu signieren, die sie nicht sinnvoll interpretieren können. Dies geschieht, weil Wallets nicht über das protokollspezifische Wissen verfügen, das erforderlich ist, um Transaktionsdaten in für Menschen lesbare Formate zu decodieren. Jedes DeFi-Protokoll hat seine eigenen einzigartigen Smart-Contract-Schnittstellen und Parameterstrukturen, aber Wallets können ohne explizite Anweisungen zur Interpretation nicht verstehen, was diese technischen Parameter tatsächlich bedeuten. Würden Sie einen rechtlichen Vertrag unterschreiben, ohne dessen Inhalt zu lesen? In Web3 unterschreiben Benutzer jedoch regelmäßig kryptografische Hashes, die als unverständliche Zeichenfolgen erscheinen:

0x3b812a5cf28be8e4787e1d1d4d513744966d8684da2f9a61187a79607c1b9fca

Benutzer greifen darauf zurück, weil sie bei der Interaktion mit bestimmten Protokollen oft keine Alternative haben. Die meisten Wallet-Implementierungen bieten Raw Signing als vermeintlich bessere Option an, bei der Sie Informationen in einem nicht decodierten Format signieren. Beispiel:

0x0000000000000000000000008c1ed7e19abaa9f23c476da86dc1577f1ef401f5000000000000000000000000
7a250d5630b4cf539739df2c5dacb4c659f2488dffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000063ae3c1f

Um jedoch fundierte Entscheidungen beim Signieren treffen zu können, müssen Benutzer wichtige Transaktionsdetails verstehen: den genauen Betrag der übertragenen, getauschten oder eingezahlten Gelder, die Zieladressen, die Art der durchgeführten Operation, alle damit verbundenen Risiken wie Slippage-Toleranz oder Delegationsberechtigungen usw. Ohne diese Details vertraut der Benutzer im Wesentlichen darauf, dass sein Arbeitsplatzrechner eine nicht böswillige Transaktion an seine Hardware-Wallet sendet, wodurch eine gefährliche Abhängigkeit von potenziell kompromittierten Systemen entsteht.

Dies bringt uns zurück zu unserem ursprünglichen Problem der blinden Signatur: Benutzer signieren Datenrepräsentationen, die sie nicht überprüfen oder verstehen können.

Ein Schritt nach vorne mit EIP-712, aber nicht genug

EIP-712 wurde ursprünglich speziell eingeführt, um das Problem der blinden Signaturen zu lösen, indem es eine standardisierte Methode für Anwendungen bereitstellt, um den Benutzern vor der Signatur strukturierte, für Menschen lesbare Daten zu präsentieren. Dieser Standard definiert ein strukturiertes Datenformat, das Wallets interpretieren und anzeigen können, sodass Benutzer organisierte Felder wie Token-Beträge, Empfängeradressen und Operationstypen anstelle von rohen kryptografischen Daten sehen können. Das Protokoll erreicht dies, indem es von Anwendungen verlangt, sowohl die rohen Transaktionsdaten als auch ein strukturiertes Schema bereitzustellen, das beschreibt, was die einzelnen Datenelemente darstellen, sodass Wallets den Benutzern aussagekräftige Informationen anzeigen können.

Dieser Standard ermöglicht es Benutzern, einzelne Felder, die sie signieren, zu überprüfen, wodurch theoretisch eine „klare Signatur” anstelle einer Blind-Signatur möglich wird.

Metamask-Signaturanforderung ohne EIP-712 (links) und mit EIP-712 (rechts) Grafik Quelle: Trail of Bits

Obwohl EIP-712 durch die Standardisierung strukturierter Datensignaturen über viele Protokolle hinweg einen bedeutenden Fortschritt darstellt, weist es dennoch entscheidende Mängel auf. Der Hack von Bybit zeigt diese Einschränkungen deutlich. Trotz der Unterstützung von EIP-712 blieben die Transaktionsdaten für eine manuelle Überprüfung zu komplex. Bei den kompromittierten Transaktionen wurden einige Parameter der Signatur-Eingabe geändert, vor allem der Operationstyp von 0 (normaler Aufruf) zu 1 (delegierter Aufruf) sowie die Zieladresse.

Hier sind die kompromittierten Informationen, die sie unterzeichnet haben:

Für den Bybit-Hack auf Etherscan unterzeichnete kompromittierte Transaktion Grafik Quelle: Trail of Bits

Dieser subtile Unterschied in der Funktionsweise veränderte das Verhalten der Transaktion vollständig und ermöglichte es dem Angreifer, bösartigen Code im Kontext des Safe-Vertrags auszuführen. Diese technischen Details wären für die meisten Benutzer kaum zu erkennen, wenn sie mit hexadezimal codierten Werten konfrontiert werden, die keinen für Menschen lesbaren Kontext bieten.

Was die Unterzeichner wahrscheinlich in ihren Wallets sahen, waren leicht abweichende Darstellungen der EIP-712-Datenstruktur. Während einige Hardware-Wallets wie Trezor Model T EIP-712 unterstützen und die strukturierte Nachricht anzeigen können, geht der Standard nicht auf die Herausforderung ein, verschachtelte Operationen in einem für Menschen lesbaren Format darzustellen. Die Wallet würde spezielles Wissen darüber benötigen, dass der Parameter „data” eine Calldata-Operation darstellt, die einer weiteren Dekodierung bedarf.

Selbst bei einem direkten Vergleich in Schnittstellen wie MetaMask würden die ursprünglichen und die manipulierten Transaktionen so ähnlich aussehen, dass Benutzer ohne tiefgreifende technische Kenntnisse der zugrunde liegenden Parameter leicht eine mit der anderen verwechseln könnten. Die wichtigste Änderung, die Umstellung des Operationstyps auf delegatecall, war ohne spezielle Kenntnisse besonders schwer zu erkennen.

Dies macht deutlich, dass EIP-712 zwar eine Struktur vorgibt, diese komplexen Transaktionen jedoch weiter in wirklich für Menschen lesbare Formate dekodiert werden müssen. Ohne diese zusätzliche Interpretationsebene unterschreiben Benutzer weiterhin Daten, die sie nicht sinnvoll validieren können.

Hardware-Wallets bieten keine vollständige Lösung

Laptops, Telefone und Computer können alle kompromittiert werden. Hardware-Wallets sind sicherer, da sie nur dazu dienen, Transaktionen zu signieren und geheime Schlüssel zu schützen. Sie haben die geringste Wahrscheinlichkeit, kompromittiert zu werden. Während Computer jedoch umfangreiche Benutzeroberflächen anzeigen können, haben Hardware-Wallets eine sehr einfache und minimalistische Benutzeroberfläche, die nicht durch Websites, die Signaturen anfordern, verändert werden kann. Hardware-Wallets sind jedoch nicht in der Lage, andere als die einfachsten Transaktionen zu entschlüsseln. Das liegt daran, dass ihnen die semantischen Informationen fehlen, die erforderlich sind, um zu entschlüsseln, was passiert, wenn eine bestimmte Vertrags-Funktion aufgerufen wird. Beispielsweise kann der Aufruf der Funktion transferFrom bei einem normalen ERC-20 zu einem anderen Ergebnis führen als der Aufruf von transferFrom bei einem Vertrag, der eine Gebühr bei der Übertragung vorsieht. Einige Hersteller von Hardware-Wallets wie Ledger haben versucht, dieses Problem durch spezielle Plugins zu beheben. Bei der Interaktion mit unterstützten Protokollen wie Paraswap können Benutzer bestimmte Apps auf ihre Hardware-Wallets herunterladen, sodass sie Transaktionsdetails direkt auf ihrem sicheren Gerät anzeigen können, ohne dass kompromittierte Informationen auf ihrem Computer gespeichert werden. Dieser Ansatz stößt jedoch auf eine erhebliche Akzeptanzlücke. Von den Hunderten von DeFi-Anwendungen verfügen weniger als 200 über spezielle Ledger-Apps^{1 1 Source: Ledger Live App (June 6, 2025)}, wobei es sich bei vielen um einfache Wallets und nicht um Dapps handelt. Wichtige DeFi-Protokolle fehlen auffällig.

Ein wesentlicher Faktor für diese begrenzte Akzeptanz sind die erheblichen Investitionen, die für die Entwicklung dieser Plugins erforderlich sind. Protokollteams vermeiden oft die Integration von Hardware-Wallets, da dies mit einem erheblichen Zeit- und Finanzaufwand verbunden ist. Die Entwicklung, das Testen und die Wartung dieser spezialisierten Anwendungen erfordern engagierte Ingenieure und kontinuierlichen Support für jede der auf dem Markt erhältlichen Hardware-Wallets – Ressourcen, die viele Protokolle lieber für die Entwicklung von Funktionen, Liquiditätsanreize oder andere Wachstumsinitiativen einsetzen. Bei dieser Kosten-Nutzen-Rechnung werden jedoch die kritischen Sicherheitsauswirkungen von Blind Signatures nicht angemessen berücksichtigt.

Der Weg nach vorn mit EIP-7730 und darüber hinaus

Glücklicherweise zeichnet sich eine vielversprechende Lösung ab. EIP-7730 stellt eine wichtige Initiative dar, um Blind Signing zu eliminieren, indem echtes „Clear Signing” mit minimalem Aufwand für die Protokollimplementierung ermöglicht wird.

Dieser Ansatz erhöht die Effizienz der Transaktionsüberprüfung erheblich. Da das Hardwaregerät den Inhalt jeder Nachricht mit expliziten Anweisungen dazu, was wie angezeigt werden soll, direkt analysieren kann, sehen Benutzer lesbare Informationen anstelle von kryptografischem Kauderwelsch. Stellen Sie sich vor, Sie sehen diese technischen Daten:

uint256 amountIn: 500000000000000000
uint256 amountOutMin: 800000000
uint256 slippageBps: 100
uint256 deadline: 1715157000

Auf dem Bildschirm Ihrer Hardware-Wallet wird dies umgewandelt in: Tauschen Sie 0,5 ETH gegen mindestens 800 USDC (1 % Slippage-Schutz) – gültig bis zum 8. Mai 2024 um 8:30 Uhr. Diese Verbesserung der Klarheit ermöglicht eine wirklich informierte Zustimmung, indem technische Parameter in Konzepte übersetzt werden, die die Benutzer tatsächlich verstehen.

Der entscheidende Sicherheitsvorteil besteht darin, dass diese Informationen auf einem vollständig isolierten Hardwaregerät angezeigt werden, das nicht durch Malware kompromittiert werden kann, ohne eine Schwachstelle in der Hardware-Wallet selbst auszunutzen.

Benutzer können sich sicherer sein, dass das, was sie auf ihrer Hardware-Wallet sehen, genau das ist, was sie unterschreiben. Keine kompromittierte Lieferkette oder Workstation kann die Transaktion manipulieren, ohne ihre semantische Beschreibung zu ändern. Wenn die Beschreibung nicht ihren Erwartungen entspricht, können sie die Transaktion einfach ablehnen.

Was EIP-7730 so bahnbrechend macht, ist die einfache Implementierung für Entwickler. Anstatt komplexe Hardware-Wallet-Integrationen zu entwickeln, müssen Protokolle lediglich eine JSON-Datei bereitstellen, um ihren Vertrag in Geräte-Registern auf die Whitelist zu setzen. Dieser standardisierte Ansatz reduziert die technischen Hindernisse, die eine breite Einführung sicherer Signaturverfahren bisher verhindert haben, erheblich. Aus Sicht des Protokolls könnte der gesamte Implementierungsprozess so einfach sein wie das Einreichen einer Pull-Anfrage mit der entsprechenden JSON-Datei.

EIP-7730 in der Praxis

Um zu zeigen, wie einfach die Implementierung von EIP-7730 sein kann, gehen wir die Erstellung eines JSON-Manifests für eine grundlegende Token-Swap-Funktion durch. Betrachten Sie diese Solidity-Funktion aus Uniswap V3:

function swapTokensForExactTokens(
    uint amountOut,
    uint amountInMax,
    address[] calldata path,
    address to,
    uint deadline
) external returns (uint[] memory amounts);

Mit EIP-712 würden Benutzer strukturierte, aber dennoch technische Daten in ihrer Wallet sehen:

Domain: Uniswap V3 Router 2
amountOut: 800000000
amountInMax: 800000000000000000000
path: [0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48,
0x6b175474e89094c44da98b954eedeac495271d0f]
to: 0x742d35Cc6634C0532925a3b8D5c5E3e7e7e7e7e7
deadline: 1715157000

Dies ist zwar besser als rohe Hex-Daten, aber die Benutzer müssen dennoch Folgendes tun:

• Manuelle Umrechnung von 800000000 in USDC-Betrag
• Umrechnung von 800000000000000000 in DAI-Betrag
• Nachschlagen der Token-Adressen, um zu verstehen, welche Token getauscht werden
• Umwandlung des Zeitstempels in ein lesbares Datum
• Überprüfung, ob die Empfängeradresse mit ihrer Wallet übereinstimmt

Mit EIP-7730 können Entwickler ein einfaches JSON-Manifest erstellen, das diese technischen Daten in ein wirklich lesbares Format umwandelt. Hier sind die Schritte:

1. Klonen Sie das clear-signing-erc7730-developer-tools Repo
2. Gehen Sie zum /developer-preview Verzeichnis
3. Installieren Sie die Abhängigkeiten mit npm i
4. Erstellen Sie die JSON-Datei und fügen Sie sie zum Registrierungsordner hinzu

{
    "context": {
        "$id": "Uniswap v3 Router 2",
        "contract": {
            "deployments": [
                {
                    "chainId": 1,
                    "address": "0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45"
                }
            ],
            "abi": "https://github.com/LedgerHQ/ledger-asset-dapps/blob/211e75ed27de3894f592ca73710fa0b72c3ceeae/ethereum/uniswap/abis/0x68b3465833fb72a70ecdf485e0e4c7bd8665fc45.abi.json"
        }
    },

    "metadata": {
        "owner": "Uniswap",
        "info": {
            "legalName": "Uniswap Labs",
            "url": "https://uniswap.org/"
        }
    },

    "display": {
        "formats": {
            "0x42712a67": {
                "$id": "swapTokensForExactTokens",
                "intent": "Swap tokens",
                "fields": [
                    {
                        "path": "amountOut",
                        "label": "Amount to Receive",
                        "format": "tokenAmount",
                        "params": {
                            "tokenPath": "path.[-1]"
                        }
                    },
                    {
                        "path": "amountInMax",
                        "label": "Maximum Amount to Send",
                        "format": "tokenAmount",
                        "params": {
                            "tokenPath": "path.[0]"
                        }
                    },
                    {
                        "path": "to",
                        "label": "Recipient of the output tokens",
                        "format": "addressName",
                        "params": {
                            "sources": ["local"]
                        }
                    },
                    {
                        "path": "deadline",
                        "label": "Valid until",
                        "format": "date"
                    }
                ]
            }
        }
    }
}

1. Lokal ausführen mit npm run dev

Der Benutzer sieht nun:

UX auf Ledger mit implementiertem EIP-7730 Grafik Quelle: Trail of Bits

Fügen Sie die JSON-Datei zum offiziellen Repository hinzu

Der gesamte Implementierungsprozess umfasst die Erstellung dieser JSON-Datei und deren Übermittlung an die Registrierungsstelle. Keine komplexen Integrationen, keine Entwicklung einer benutzerdefinierten Hardware-Wallet, sondern nur ein einfaches Manifest, das die Transaktionen Ihres Protokolls für Menschen lesbar macht.

Dieser Ansatz lässt sich auf jede Protokollkomplexität skalieren und behält dabei das gleiche einfache Implementierungsmuster bei, sodass jede Dapp im Ökosystem Zugang zu sicherer Signatur erhält.

Implementieren Sie EIP-7730 noch heute

Der Weg zur Beseitigung blinder Signaturen in Ihrem Protokoll ist jetzt einfach und zugänglich. Als Dapp-Entwickler können Sie die Sicherheit und das Erlebnis Ihrer Benutzer in nur wenigen Stunden Implementierungsarbeit erheblich verbessern.

Der Einstieg ist ganz einfach:

1. Verwenden Sie das Entwicklungstool von Ledger: Ledger hat ein umfassendes Tool entwickelt, das die Erstellung von JSON-Manifesten unter https://get-clear-signed.ledger.com/ vereinfacht. Dieses Tool führt Sie durch den gesamten Prozess und macht die Implementierung von EIP-7730 auch für Teams ohne umfassende kryptografische Fachkenntnisse zugänglich.
2. Reichen Sie Ihre Integration ein: Sobald Ihr JSON-Manifest fertig ist, erstellen Sie einen Pull-Request, um es zum Ledger-Registry-Repository unter https://github.com/LedgerHQ/clear-signing-erc7730-registry hinzuzufügen. Diese zentralisierte Registry gewährleistet die Auffindbarkeit und gewährleistet gleichzeitig die Einhaltung von Sicherheitsstandards. Beachten Sie, dass die Eigentumsrechte an der Registry in Zukunft auf ein von einer Stiftung betriebenes Modell übergehen werden, ähnlich wie bei der Ethereum Chain ID-Liste, wodurch ein optimales Gleichgewicht zwischen Dezentralisierung und Auffindbarkeit erreicht wird.
3. Professioneller Überprüfungsprozess: Nach der Einreichung überprüft das Sicherheitsteam von Ledger Ihr Manifest innerhalb weniger Tage. Diese Überprüfung stellt sicher, dass Ihre Implementierung die Transaktionsdaten korrekt wiedergibt, ohne wichtige Informationen zu verbergen oder irreführende Begriffe zu verwenden. Es werden nur nicht bösartige, ordnungsgemäß funktionierende Manifeste genehmigt.
4. Clear Signing starten: Sobald Ihr Manifest genehmigt ist, steht die Clear-Signing-Funktionalität für Ihr Protokoll sofort zur Verfügung. Ihre Benutzer sehen dann lesbare Transaktionsdetails auf ihren Hardware-Wallets.

Das war’s schon! Sie haben die Erfahrung Ihrer Benutzer verändert, indem Sie die mit Blind Signing verbundene Unsicherheit und Angst beseitigt haben und ihre Web3-Erfahrung von Unsicherheit in echtes Vertrauen verwandelt haben.

Während EIP-7730 die Transaktionssicherheit durch die Beseitigung von Blind Signing erheblich verbessert, bleibt der direkteste Angriffsvektor für Hacker die Ausnutzung von Schwachstellen in den Smart Contracts selbst. Selbst bei perfekter Transaktionstransparenz können Benutzer immer noch Geld verlieren, wenn das zugrunde liegende Protokoll Sicherheitslücken enthält.

Entdecken Sie mehr

---

Bild/Quelle: https://depositphotos.com/de/home.html

Folgen Sie uns auf X

Folgen Sie uns auf Bluesky