Vai al contenuto
Financial Context Wiki

Firma del wallet

Una firma del wallet prova che una chiave o un account a contratto ha approvato dati esatti secondo regole precise. Distingue messaggi, transazioni, permit, replay e phishing.

Aggiornato

Solo a scopo didattico; non è consulenza finanziaria o di sicurezza. Una richiesta di firma malevola può causare perdite irreversibili.

Risposta diretta

Una firma del wallet è la prova crittografica che una chiave privata, o la politica di uno smart account, ha approvato uno specifico messaggio codificato. La verifica identifica l’account per quei byte e quelle regole; non prova identità legale, comprensione del firmatario o sincerità della descrizione del sito.

Firmare non è un’azione uniforme. La firma di transazione autorizza direttamente un’operazione di rete. Un messaggio off-chain può essere una richiesta di login senza poteri sugli asset, oppure un ordine, permit di token, istruzione di governance o altra autorizzazione che un relayer invierà dopo. Nessun avviso di gas non significa nessun rischio.

Prima di firmare identifica tipo di richiesta, azione leggibile, dominio o verificatore previsto, chain, contratto verificatore, indirizzi, importi, nonce e scadenza. Rifiuta hash inspiegati, byte illeggibili, campi inattesi o richieste mostrate in modo insufficiente.

Firma del wallet
0 / 5
0 elementi recensiti; 5 elementi ancora irrisolti

Il completamento di questa revisione non dimostra che una risorsa, una transazione o un sistema siano sicuri.

Come funziona

  1. L’applicazione codifica una transazione, un messaggio semplice o dati tipizzati. Una minima variazione produce un digest diverso.
  2. Il wallet mostra ciò che riesce a decodificare e chiede conferma. La chiave privata resta nel wallet o dispositivo; viene restituita solo la firma del digest.
  3. Il verificatore ricostruisce lo stesso digest. Per un account esterno recupera o controlla l’indirizzo; un account a contratto può applicare la politica corrente tramite ERC-1271.
  4. Il verificatore interpreta il risultato secondo le regole applicative. Un server può creare una sessione; un contratto può consumare un permit, eseguire un ordine, cambiare governance o effettuare un’altra chiamata autorizzata.
  5. La protezione dal replay dipende dall’applicazione. EIP-712 offre codifica tipizzata e separazione del dominio ma non impedisce replay; l’applicazione deve imporre nonce, deadline, verificatore previsto, chain o altro limite monouso.

ERC-191 separa i dati firmati dalla codifica delle normali transazioni Ethereum e definisce formati come personal_sign. EIP-712 lega campi strutturati a un dominio che può includere name, version, chainId e verifyingContract. I messaggi ERC-4361 includono dominio, URI, ID della chain, nonce e orario di emissione, ma il servizio deve comunque validarli.

Esempio

Leah riceve dal servizio ufficiale un login ERC-4361 con dominio e URI attesi, nonce nuovo e validità breve. Chiede solo autenticazione. Dopo i controlli firma; il server verifica e crea una sessione. Il messaggio non crea da solo allowance di token né transazioni on-chain.

Su un sito clone il pulsante dice ancora “Accedi”, ma il wallet mostra dati EIP-712 Permit con token, spender, importo, nonce e deadline. La firma può permettere a un relayer di creare potere di spesa secondo il contratto. Leah deve rifiutare: il testo del pulsante non cambia i byte firmati.

Rischi e controlli

  • Significato ingannevole: una pagina può chiamare login un permit o ordine. Fidati del payload decodificato e del contratto verificato, non del pulsante.
  • Firma cieca: hash grezzi e byte opachi impediscono una verifica consapevole. Annulla se non puoi riprodurre messaggio e percorso di esecuzione con uno strumento affidabile.
  • Dominio errato: un marchio noto non autentica chainId, verifyingContract, dominio web o URI. Controlla ogni campo e l’indirizzo completo separatamente.
  • Replay o esecuzione tardiva: chi ottiene una firma valida può usarla finché il nonce non è consumato o il deadline scade. Usa nonce nuovi, scadenze brevi e non pubblicare firme.
  • Autorità ampia: permit, ordini, chiavi di sessione e operazioni smart account possono abilitare azioni successive senza altro avviso. Controlla asset, spender, destinatario, importo, ambito e revoca.
  • Firmatario compromesso: un hardware wallet ostacola l’estrazione della chiave, non rende sicuro un messaggio malevolo. Se seed phrase o chiave privata sono esposte, considera compromesso l’intero account.

Se hai firmato una richiesta sospetta, conserva payload e firma senza pubblicarli, disconnetti il sito e identifica lo schema. Per approvazioni o transazioni on-chain, verifica lo stato sulla chain corretta e usa revoca, invalidazione del nonce o migrazione documentata. Non esiste una revoca universale delle firme off-chain; disconnettere il sito non le invalida.

Idee sbagliate comuni

  • “Ogni firma muove fondi.” Molte servono solo ad autenticare o esprimere intento; alcune autorizzano movimenti successivi.
  • “Senza gas è innocua.” Un relayer può pagare il gas e inviare permit, ordine o altra autorizzazione firmata.
  • “EIP-712 garantisce sicurezza.” Migliora visualizzazione e separazione del dominio, ma non impedisce replay né verifica le affermazioni dell’app.
  • “L’indirizzo recuperato prova consenso informato.” Collega dati esatti e chiave secondo una regola, non prova identità, comprensione o libertà.
  • “Le firme dei wallet a contratto sono come quelle normali.” La validità ERC-1271 può dipendere da stato e politica correnti; il verificatore deve interrogare il contratto.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...