Vai al contenuto
Financial Context Wiki

Wallet con chiave di sessione

Scopri come le chiavi di sessione degli smart account delegano autorità limitata, quali vincoli devono essere applicati e come verificare, revocare e gestire una chiave compromessa.

Aggiornato

Solo a scopo educativo; non è una consulenza d’investimento. Una chiave di sessione compromessa o con privilegi eccessivi può causare perdite irreversibili di asset digitali.

Risposta diretta

Una chiave di sessione del wallet è in genere una chiave di firma secondaria, o una credenziale delegata collegata a essa, che uno smart account accetta solo in base a regole definite. Le regole possono limitare tempo, contratti destinatari, selettori di funzione, quantità di token, numero di transazioni o altre condizioni. Lo scopo è consentire a un’app di eseguire azioni ripetute senza chiedere al titolare di approvare ogni operazione con il firmatario principale.

La “chiave di sessione” è un modello progettuale, non uno standard Ethereum universale. ERC-4337 offre convalida programmabile dell’account e convalida temporale di UserOperation, mentre sistemi modulari come ERC-7579 possono ospitare validatori, esecutori e hook. Il codice distribuito dell’account e dei moduli decide in ultima analisi che cosa può fare la chiave. La sola scadenza non rende sicura una sessione e cancellare una copia dal browser non revoca necessariamente l’autorità registrata on-chain o contenuta in una delega ancora valida.

Come funziona

Un flusso tipico prevede 5 fasi:

  1. Il titolare crea una nuova coppia di chiavi su un dispositivo o autorizza una credenziale che identifica il firmatario della sessione. La chiave privata di sessione non deve mai essere inviata al server dell’app, salvo che il progetto renda esplicitamente quel server un custode fidato.
  2. Il titolare autorizza una politica con il wallet principale. Alcuni sistemi installano chiave e politica on-chain; altri usano una delega firmata che l’account convalida all’arrivo di un’operazione.
  3. L’app prepara un’operazione e la firma con la chiave di sessione. In un flusso ERC-4337, la logica validateUserOp dell’account verifica firma e politica; la simulazione del bundler è un controllo di ammissione, non una prova di esecuzione o sicurezza.
  4. L’account deve applicare ogni restrizione prima dell’esecuzione. L’autorità effettiva si può riassumere come A_effective = K ∩ P ∩ S: possesso della chiave (K), politica configurata (P) e stato corrente dell’account o della rete (S) devono tutti consentire l’azione.
  5. La sessione termina per scadenza, esaurimento del nonce o della quota, revoca esplicita, rimozione del modulo o altra procedura specifica dell’implementazione. Verifica lo stato risultante dell’account sulla rete corretta.

Prima di autorizzare una sessione, verifica:

  • ID della rete, indirizzo dello smart account, implementazione dell’account e indirizzo del validatore o modulo;
  • chiave pubblica di sessione o identificatore della credenziale e luogo di conservazione del materiale privato;
  • ogni destinazione, selettore di funzione, token e regola del destinatario consentiti, oltre al limite di valore nativo e al tetto per chiamata o cumulativo;
  • validAfter, validUntil, regole del nonce, numero di utilizzi e se il tempo è misurato dal timestamp del blocco o da altra fonte;
  • se batch, chiamate annidate, delegatecall, approvazioni di token, installazione di moduli, aggiornamenti dell’account e firme di messaggi ERC-1271 sono bloccati salvo necessità esplicita;
  • chi può revocare, se il titolare conserva un percorso di recupero indipendente e se la revoca richiede Gas o un bundler o paymaster funzionante.

La politica deve ispezionare l’azione realmente eseguita. Controllare solo il destinatario esterno di un batch può lasciare libere le chiamate interne; controllare solo il destinatario ignorando funzione e valore crea lo stesso problema. Un limite ha senso solo se il codice che lo applica copre ogni percorso di esecuzione.

Esempio

Un wallet di gioco crea una sessione di 24 ore. Consente chiamate solo a un contratto di gioco verificato, blocca delegatecall e le approvazioni di token, limita il valore nativo a 0.02 ETH per chiamata e la spesa totale a 20 USDC. Il gioco può inviare mosse consentite senza conferme ripetute, ma una richiesta di trasferire un NFT estraneo deve fallire la convalida.

Prima dell’uso, il titolare registra account, rete, modulo, chiave pubblica della sessione, scadenza, limiti e metodo di revoca. Prova un’azione di basso valore, verifica la chiamata decodificata e l’evento dell’account, quindi prova separatamente la revoca. Ciò conferma il percorso configurato; non dimostra che il modulo sia privo di vulnerabilità né che un dispositivo compromesso non possa spendere fino ai limiti residui.

Rischi e controlli

  • Politica troppo ampia: destinazioni jolly, selettori senza vincoli, approvazioni illimitate, batch o delegatecall possono dare a una chiave “limitata” poteri quasi da titolare. Usa liste esplicite di consentiti e vieta le azioni amministrative.
  • Furto della chiave: memoria del browser, log, backup, estensioni, malware e dispositivi condivisi possono esporla. Preferisci archiviazione isolata o protetta da hardware, quando disponibile, durate brevi e limiti cumulativi bassi.
  • Applicazione difettosa: account, validatore, esecutore o hook possono decodificare male le chiamate o non coprire un percorso alternativo. Usa distribuzioni verificate, codice revisionato, audit e test di aggiramento.
  • Replay e confusione di contesto: gestione debole del nonce o mancato legame con rete, account, modulo o politica previsti può consentire il riuso. Verifica il dominio firmato esatto e la protezione on-chain dal replay.
  • Ipotesi sulla scadenza: validUntil può limitare una singola operazione ERC-4337 senza rimuovere automaticamente una chiave registrata, un’autorizzazione di token o un’altra delega. Controlla lo stato reale di ogni permesso dopo la scadenza.
  • Revoca fallita: eliminare dati locali rimuove solo una copia del segreto. Revoca tramite il percorso documentato e verifica il risultato on-chain; conserva Gas sufficiente e una via alternativa controllata dal titolare.
  • Moduli aggiornabili o dannosi: possono avere ampi poteri di esecuzione e gli aggiornamenti possono cambiare la politica. Controlla titolari, ritardo di aggiornamento, poteri di pausa, indirizzo di implementazione e procedura di rimozione.
  • Abuso di Gas e sponsorizzazione: la sessione può consumare fondi dell’account in Gas o diventare inutilizzabile se un paymaster la rifiuta. Limita le commissioni dove possibile e mantieni una via di invio indipendente.

Se una chiave può essere esposta, interrompi l’uso dell’app interessata, conserva identificatore di sessione e hash pertinenti e revoca o disabilita la chiave da un dispositivo pulito controllato dal titolare. Poi esamina operazioni pendenti e recenti, approvazioni, moduli installati, aggiornamenti e saldi su tutte le reti supportate. Sposta gli asset residui solo se il progetto rende inaffidabile la revoca; correre verso un sito di “recupero” non verificato può aggravare la perdita.

Errori comuni

  • “Una chiave di sessione non può spostare asset.” Può eseguire ogni azione permessa dalla politica, comprese trasferimenti, swap, approvazioni o firme.
  • “ERC-4337 definisce i permessi delle chiavi di sessione.” ERC-4337 fornisce un quadro di convalida ed esecuzione; la politica resta specifica del wallet o modulo.
  • “Una scadenza breve limita la perdita massima.” La perdita dipende anche da limiti per chiamata e cumulativi, frequenza, Gas, approvazioni, prezzi e ogni percorso raggiungibile.
  • “Disconnettersi revoca la chiave.” Può eliminare una copia locale, ma non dimostra che la registrazione on-chain o una delega firmata siano invalide.
  • “Una simulazione riuscita significa che l’operazione è sicura.” Può mostrare l’accettazione attuale, ma non prova intenzione, inclusione futura, esecuzione, finalità o assenza di vulnerabilità.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...