Zum Inhalt springen
Financial Context Wiki

Wallet mit Sitzungsschlüssel

Erfahren Sie, wie Sitzungsschlüssel von Smart Accounts begrenzte Befugnisse delegieren, welche Einschränkungen durchgesetzt werden müssen und wie ein Schlüssel geprüft, widerrufen und nach einem Leck behandelt wird.

Aktualisiert

Nur zu Bildungszwecken; keine Anlageberatung. Ein offengelegter oder zu weit berechtigter Sitzungsschlüssel kann zu unwiderruflichen Verlusten digitaler Vermögenswerte führen.

Direkte Antwort

Ein Wallet-Sitzungsschlüssel ist gewöhnlich ein sekundärer Signaturschlüssel oder ein damit verknüpfter delegierter Berechtigungsnachweis, den ein Smart Account nur nach festgelegten Regeln akzeptiert. Diese Regeln können Zeit, Zielverträge, Funktionsselektoren, Tokenbeträge, Transaktionszahl oder andere Bedingungen begrenzen. So kann eine Anwendung wiederkehrende Aktionen ausführen, ohne dass der Inhaber jeden Vorgang mit dem Hauptsignierer genehmigen muss.

„Sitzungsschlüssel“ bezeichnet ein Entwurfsmuster, keinen einheitlichen Ethereum-Standard. ERC-4337 bietet programmierbare Kontoprüfung und zeitlich begrenzte UserOperation-Validierung; modulare Systeme wie ERC-7579 können Validatoren, Ausführer und Hooks aufnehmen. Der bereitgestellte Konto- und Modulcode entscheidet letztlich, was der Schlüssel darf. Ein Ablaufdatum allein macht eine Sitzung nicht sicher, und das Löschen einer Browserkopie widerruft nicht zwingend bereits On-Chain registrierte oder in einer noch gültigen Delegation enthaltene Befugnisse.

Funktionsweise

Ein typischer Ablauf umfasst 5 Schritte:

  1. Der Inhaber erzeugt auf einem Gerät ein neues Schlüsselpaar oder genehmigt einen Nachweis, der den Sitzungssignierer identifiziert. Der private Sitzungsschlüssel darf nie an den Anwendungsserver gesendet werden, außer das Design bestimmt diesen ausdrücklich zum vertrauenswürdigen Verwahrer.
  2. Der Inhaber genehmigt mit der Haupt-Wallet eine Richtlinie. Manche Systeme installieren Schlüssel und Richtlinie On-Chain; andere nutzen eine signierte Delegation, die das Konto bei Eingang eines Vorgangs prüft.
  3. Die Anwendung erstellt einen Vorgang und signiert ihn mit dem Sitzungsschlüssel. In einem ERC-4337-Ablauf prüft die validateUserOp-Logik Signatur und Richtlinie. Die Simulation eines Bundlers ist eine Zulassungsprüfung, kein Beleg für Ausführung oder Sicherheit.
  4. Das Konto muss vor der Ausführung sämtliche Einschränkungen durchsetzen. Die wirksame Befugnis lässt sich als A_effective = K ∩ P ∩ S zusammenfassen: Schlüsselbesitz (K), konfigurierte Richtlinie (P) und aktueller Konto- oder Chain-Zustand (S) müssen die Aktion erlauben.
  5. Die Sitzung endet durch Ablauf, Ausschöpfen von Nonce oder Quote, ausdrücklichen Widerruf, Entfernen des Moduls oder einen anderen implementierungsspezifischen Ungültigkeitspfad. Prüfen Sie den resultierenden Kontostand auf der richtigen Chain.

Vor der Genehmigung sind zu prüfen:

  • Chain-ID, Smart-Account-Adresse, Kontoimplementierung und Adresse des Validators oder Moduls;
  • öffentlicher Sitzungsschlüssel oder Nachweis-ID sowie Speicherort des privaten Materials;
  • jedes erlaubte Ziel, jeder Funktionsselektor, Token und Empfängerregel sowie Grenze für nativen Wert und Limit je Aufruf oder insgesamt;
  • validAfter, validUntil, Nonce-Regeln, Nutzungszahl und ob die Zeit per Blockzeitstempel oder aus anderer Quelle gemessen wird;
  • ob Batches, verschachtelte Aufrufe, delegatecall, Tokenfreigaben, Modulinstallation, Konto-Upgrades und ERC-1271-Nachrichtensignaturen gesperrt sind, sofern sie nicht ausdrücklich benötigt werden;
  • wer widerrufen darf, ob der Inhaber einen unabhängigen Wiederherstellungsweg behält und ob der Widerruf Gas oder einen funktionierenden Bundler oder Paymaster benötigt.

Die Richtlinie muss die tatsächlich ausgeführte Aktion prüfen. Wird nur das äußere Batch-Ziel geprüft, können innere Aufrufe unbeschränkt bleiben; wird nur der Empfänger ohne Funktion und Wert geprüft, entsteht dasselbe Problem. Ein Limit ist nur sinnvoll, wenn der durchsetzende Code jeden Ausführungspfad erfasst.

Beispiel

Eine Spiele-Wallet richtet eine Sitzung für 24 Stunden ein. Sie erlaubt nur Aufrufe an einen verifizierten Spielevertrag, sperrt delegatecall und Tokenfreigaben, begrenzt den nativen Wert auf 0.02 ETH je Aufruf und die Gesamtausgaben auf 20 USDC. Das Spiel kann erlaubte Züge ohne wiederholte Bestätigung senden; die Übertragung eines fremden NFT muss jedoch an der Validierung scheitern.

Vor der Nutzung protokolliert der Inhaber Konto, Chain, Modul, öffentlichen Sitzungsschlüssel, Ablauf, Limits und Widerrufsweg. Er testet eine Aktion mit geringem Wert, prüft den dekodierten Aufruf und das Kontoereignis und testet danach getrennt den Widerruf. Das bestätigt den eingerichteten Weg, beweist aber weder Fehlerfreiheit des Moduls noch, dass ein kompromittiertes Gerät die verbleibenden Limits nicht ausschöpfen kann.

Risiken und Kontrollen

  • Zu weite Richtlinie: Platzhalterziele, unbeschränkte Selektoren, unbegrenzte Tokenfreigaben, Batches oder delegatecall können einen „begrenzten“ Schlüssel fast zum Inhaberschlüssel machen. Verwenden Sie eindeutige Positivlisten und sperren Sie Verwaltungsaktionen.
  • Schlüsseldiebstahl: Browserspeicher, Protokolle, Sicherungen, Erweiterungen, Schadsoftware und gemeinsam genutzte Geräte können den Schlüssel offenlegen. Bevorzugen Sie, falls unterstützt, hardwaregestützte oder isolierte Speicherung, kurze Laufzeiten und niedrige Gesamtkappen.
  • Fehlerhafte Durchsetzung: Konto, Validator, Ausführer oder Hook können Aufrufe falsch dekodieren oder einen alternativen Pfad übersehen. Nutzen Sie verifizierte Bereitstellungen, geprüften Code, Audits und Umgehungstests.
  • Replay und Kontextverwechslung: Schwache Nonce-Prüfung oder fehlende Bindung an vorgesehene Chain, Konto, Modul oder Richtlinie kann Wiederverwendung ermöglichen. Prüfen Sie die genaue Signaturdomäne und den On-Chain-Replay-Schutz.
  • Annahmen zum Ablauf: validUntil kann einen ERC-4337-Vorgang begrenzen, ohne registrierte Schlüssel, Tokenfreigaben oder andere Delegationen automatisch zu entfernen. Prüfen Sie danach den tatsächlichen Zustand jeder Berechtigung.
  • Fehlgeschlagener Widerruf: Lokales Löschen entfernt nur eine Kopie des Geheimnisses. Widerrufen Sie über den dokumentierten Kontopfad und prüfen Sie das On-Chain-Ergebnis; halten Sie genügend Gas und einen inhaberkontrollierten Ersatzweg vor.
  • Aktualisierbare oder bösartige Module: Module können weitreichende Ausführungsrechte haben, und Upgrades können Richtlinien ändern. Prüfen Sie Inhaber, Upgrade-Verzögerung, Pausenrechte, Implementierungsadresse und Entfernungsvorgang.
  • Gas- und Sponsoring-Missbrauch: Eine Sitzung kann Kontomittel für Gas verbrauchen oder bei Ablehnung durch einen Paymaster unbrauchbar werden. Begrenzen Sie Gebühren soweit möglich und behalten Sie einen unabhängigen Übermittlungsweg.

Bei möglicher Offenlegung beenden Sie die Nutzung der betroffenen Anwendung, sichern Sitzungs-ID und relevante Transaktions-Hashes und widerrufen oder deaktivieren den Schlüssel von einem sauberen, inhaberkontrollierten Gerät. Prüfen Sie anschließend ausstehende und jüngste Vorgänge, Tokenfreigaben, installierte Module, Konto-Upgrades und Salden auf allen unterstützten Chains. Verschieben Sie Restvermögen nur, wenn das Design einen zuverlässigen Widerruf verhindert; eine ungeprüfte „Wiederherstellungsseite“ kann den Verlust vergrößern.

Häufige Missverständnisse

  • „Ein Sitzungsschlüssel kann keine Vermögenswerte bewegen.“ Er kann jede von der Richtlinie erlaubte Aktion ausführen, darunter Übertragungen, Swaps, Freigaben oder Signaturen.
  • „ERC-4337 definiert Sitzungsschlüsselrechte.“ ERC-4337 liefert einen Prüf- und Ausführungsrahmen; die Richtlinie bleibt Wallet- oder modulspezifisch.
  • „Kurzer Ablauf begrenzt den Höchstverlust.“ Dieser hängt auch von Einzel- und Gesamtkappen, Häufigkeit, Gas, Freigaben, Preisen und allen erreichbaren Pfaden ab.
  • „Abmelden widerruft den Schlüssel.“ Es kann die lokale Kopie löschen, beweist aber nicht, dass Registrierung oder signierte Delegation ungültig sind.
  • „Erfolgreiche Simulation bedeutet Sicherheit.“ Sie kann aktuelle Annahme zeigen, beweist aber weder Absicht, spätere Aufnahme, Ausführung, Finalität noch Fehlerfreiheit des Moduls.

Verwandte Themen

Quellen

Navigation

Wiki durchsuchen...