Livelli dei wallet, policy delle transazioni e flussi di firma

Le chiavi più solide sono inutili se una sola persona può ordinarne la firma per qualsiasi cosa. I controlli che regolano la firma determinano dove si trovano le chiavi, quali transazioni sono consentite, chi deve approvarle e cosa vedono effettivamente i firmatari; è proprio qui che la maggior parte delle perdite istituzionali viene impedita o resa possibile. Questa lezione segue una transazione dalla richiesta alla trasmissione.

Wallet hot, warm e cold

I custodi e gli exchange suddividono gli asset in livelli. Ogni livello scambia velocità con sicurezza.

Il wallet hot dovrebbe contenere solo ciò che serve alle operazioni. A titolo illustrativo, prendiamo un exchange con 2 miliardi di USD di asset dei clienti e prelievi netti giornalieri medi di 30 milioni di USD. Potrebbe mantenere 40–60 milioni di USD in hot (2–3%), una quantità sufficiente per una giornata normale più un margine. I depositi eccedenti vengono trasferiti regolarmente allo storage warm o cold, mentre il wallet hot viene ricaricato tramite una procedura controllata. Questi valori sono un esempio, non uno standard. La quantità appropriata dipende dai modelli di prelievo, dagli impegni sui livelli di servizio e dalle condizioni assicurative.

«Cold» non significa al sicuro da qualsiasi attacco. Le chiavi cold sono offline, ma le persone devono comunque approvare le transazioni e le procedure di approvazione possono essere raggirate. Il furto di Bybit del febbraio 2025 è iniziato con un normale trasferimento in uscita da un wallet cold (vedi la lezione Minacce e controlli di sicurezza operativa).

Motori di policy

Un motore di policy verifica ogni richiesta di transazione rispetto a un insieme di regole prima che una chiave o una quota di chiave firmi. Ecco alcuni tipi di regole comuni:

Due aspetti di progettazione sono importanti. Primo, la policy deve essere applicata nel punto in cui avviene la firma: nell'ambiente sicuro dell'HSM, dai cofirmatari MPC o nello smart-contract wallet. Se viene verificata solo in un'applicazione web, chiunque abbia accesso al server può aggirarla. Secondo, le modifiche alla policy sono a loro volta transazioni ad alto rischio. Aggiungere un approvatore, aumentare un limite o modificare la allowlist dovrebbe richiedere un quorum specifico e un periodo di attesa.

Un motore di policy produce anche prove documentali. Ogni richiesta, valutazione di una regola, approvazione e rifiuto dovrebbe essere registrato in un registro non modificabile, con l'utente, il dispositivo e l'ora. I revisori verificano i controlli sulla base di questi registri, e chi risponde agli incidenti li usa per ricostruire l'accaduto. Anche le richieste rifiutate meritano attenzione: una serie di tentativi bloccati verso nuovi indirizzi può essere il primo segnale di un attacco.

Quorum e segregazione dei compiti

Un quorum è il numero di approvazioni necessarie, espresso come m-di-n (per esempio, 3-di-5). Il quorum funziona solo se gli approvatori sono davvero indipendenti.

La segregazione dei compiti separa i ruoli che altrimenti potrebbero combinarsi per commettere una frode:

• L'iniziatore crea la richiesta, ma non può approvarla.
• Gli approvatori esaminano e approvano, ma non possono modificare la destinazione.
• I firmatari o custodi delle chiavi gestiscono le chiavi, spesso senza la possibilità di avviare transazioni.
• Gli amministratori delle policy gestiscono regole e utenti, ma non possono trasferire fondi.

Tra i problemi più comuni c'è il collasso del quorum: in un sistema 3-di-5 in cui tre approvatori appartengono allo stesso team, un manager o una singola campagna di phishing può raggiungere il quorum. Altri problemi sono gli ex dipendenti che mantengono l'accesso dopo aver cambiato ruolo e l'uso di credenziali condivise. Le buone pratiche prevedono di distribuire gli approvatori tra diversi reparti e sedi, verificare gli accessi almeno ogni trimestre, revocare l'accesso il giorno in cui una persona lascia l'organizzazione e richiedere il controllo duale, cioè la presenza di due persone in ogni momento, per l'accesso fisico allo storage cold.

Allowlist, limiti di velocità e blocchi temporali

Le allowlist (dette anche whitelist) limitano i prelievi agli indirizzi approvati in precedenza. Impediscono la maggior parte degli attacchi basati sulla sostituzione dell'indirizzo solo se aggiungerne uno è difficile. Una procedura solida richiede:

• una richiesta corredata da prove che attestino chi è il titolare dell'indirizzo
• una conferma tramite un canale separato, usando un numero di telefono già registrato e non fornito nella richiesta
• un piccolo trasferimento di prova, che la controparte deve confermare
• un periodo di attesa, spesso da 24 a 48 ore, prima che l'indirizzo diventi utilizzabile

I limiti di velocità fissano un tetto al valore per transazione, per ora e per giorno, idealmente sommando gli importi in una valuta di riferimento su tutti gli asset, così che un aggressore non possa suddividere un furto in molti piccoli trasferimenti.

I blocchi temporali introducono un ritardo tra l'approvazione e la trasmissione, oppure tra la trasmissione e la possibilità di spendere i fondi. Questa finestra consente ai team di monitoraggio di rilevare e annullare una transazione fraudolenta. Possono essere implementati off-chain, come una coda di operazioni in sospeso nella piattaforma di custodia, oppure on-chain. Bitcoin supporta i blocchi temporali on-chain tramite CHECKLOCKTIMEVERIFY (BIP 65) e CHECKSEQUENCEVERIFY (BIP 112), e i design «vault» li usano per dare a una chiave di recupero il tempo necessario per recuperare i fondi. Sulle blockchain EVM, i contratti timelock svolgono la stessa funzione. Il costo è una minore velocità, quindi gli accordi con i clienti devono indicare tempi di prelievo che tengano conto di questi ritardi.

Simulazione delle transazioni e firma leggibile

Un firmatario dovrebbe sapere esattamente cosa farà una firma. Due tecniche lo rendono possibile.

La simulazione della transazione esegue la transazione sullo stato corrente della blockchain prima che venga firmata. Indica cosa accadrà: quali saldi cambieranno, quali autorizzazioni per i token verranno concesse, quali contratti verranno chiamati e se la chiamata usa delegatecall o modifica i proprietari o il codice del wallet. Una simulazione che mostra «–5.000.000 USDC dal wallet, +5.000.000 USDC a 0xAb…9F, nessun'altra modifica» fornisce all'approvatore elementi concreti da verificare.

La firma leggibile significa che il dispositivo di firma mostra il significato in un formato comprensibile per una persona (destinatario, importo, nome della funzione e parametri) invece di un hash o di dati esadecimali grezzi. L'opposto è la firma cieca: approvare dati che il firmatario non può leggere. Standard come EIP-712 (dati strutturati tipizzati) aiutano i wallet a mostrare il significato di un messaggio. Quando un dispositivo non è in grado di decodificare una transazione, l'impostazione sicura predefinita è rifiutarla, non firmarla comunque.

La firma leggibile funziona solo se ci si può fidare del display. Se il computer che prepara la transazione è compromesso, può mostrare una cosa e inviarne un'altra. Una buona pratica consiste nel verificare tramite un canale indipendente. Per esempio, calcolare l'hash atteso della transazione su una macchina separata e pulita e confrontarlo con l'hash mostrato sul dispositivo hardware prima di approvare.

Esempio svolto: un prelievo di 5 milioni di USD

Un cliente aziendale chiede di prelevare 5 milioni di USD in USDC verso un proprio indirizzo.

1. Richiesta. Un analista delle operations del tesoro inserisce la richiesta. La piattaforma registra chi l'ha avviata e quando.
2. Verifica della policy. La destinazione è nella allowlist da 60 giorni. L'importo supera la soglia di 1 milione di USD, quindi si applica il percorso cold. Il limite di velocità giornaliero ha ancora margine. Il tipo di transazione è un semplice trasferimento di token.
3. Approvazioni. Il quorum è di 3-di-5: un approvatore delle operations, uno del team rischi e un dirigente senior. L'iniziatore non può essere uno di loro.
4. Simulazione e firma leggibile. La simulazione mostra che esattamente 5.000.000 USDC vengono inviati all'indirizzo presente nella allowlist, senza altre chiamate. I firmatari verificano gli stessi dettagli sui propri dispositivi e controllano l'hash su una macchina indipendente.
5. Blocco temporale e trasmissione. Un ritardo di quattro ore consente l'annullamento. In seguito la transazione viene firmata e trasmessa, e la riconciliazione post-trade conferma la variazione del saldo on-chain rispetto al registro interno.

Ogni fase blocca un tipo diverso di errore. La allowlist impedisce l'uso di un indirizzo digitato in modo errato o sostituito. Il quorum impedisce che un singolo insider agisca da solo. La simulazione e il controllo indipendente dell'hash rilevano un'interfaccia compromessa. Il blocco temporale offre al team di monitoraggio un'ultima possibilità di intervenire.

Focus sull'esame: le caratteristiche dei wallet hot, warm e cold e perché il wallet hot dovrebbe contenere solo ciò che serve alle operazioni; cosa verifica un motore di policy e perché deve essere applicato nel punto in cui avviene la firma; la progettazione del quorum e la segregazione dei compiti (iniziatore, approvatore, firmatario, amministratore delle policy) e il rischio di collasso del quorum; una procedura sicura per l'inserimento di indirizzi nella allowlist, con verifica tramite un canale separato e un periodo di attesa; limiti di velocità e blocchi temporali (code off-chain o blocchi on-chain); simulazione delle transazioni, firma leggibile rispetto a firma cieca e verifica indipendente di ciò che viene firmato.