Rischio di esecuzione nelle criptovalute: la nuova minaccia alla custodia

Il settore delle criptovalute è spesso all’avanguardia nell’innovazione funzionale, ma la sicurezza operativa resta un punto debole. Per anni il rischio di custody è stato identificato principalmente con il furto delle private keys, spingendo verso soluzioni come cold storage, sistemi air-gapped e MPC. Tuttavia, proteggere soltanto le chiavi on‑chain non è più sufficiente: la custodia si è trasformata in un insieme complesso di credenziali e processi che possono trasferire valore anche fuori dalla blockchain.

L’evoluzione del concetto di custodia

Un tempo il termine custody richiamava esclusivamente la protezione delle private keys. Oggi la realtà operativa include molte tipologie di credenziali: API per gli scambi, chiavi di validatore per servizi di staking, credenziali di deployment e segreti di sistema per infrastrutture interne. Questi elementi sono spesso distribuiti tra diversi fornitori, exchange, piattaforme di staking e infrastrutture di terze parti, creando una superficie di attacco molto più ampia rispetto al solo spazio on‑chain.

Molti di questi segreti vengono conservati in secret managers che, per design, restituiscono la chiave completa a qualsiasi processo autenticato. Questa praticità facilita l’esecuzione in tempo reale ma introduce una fragilità strutturale: se l’ambiente di esecuzione viene compromesso, l’autorizzazione al movimento di capitale può essere ottenuta immediatamente.

Il rischio di esecuzione

Negli ultimi anni il cosiddetto execution risk è diventato il vettore principale per attacchi su larga scala. I criminali informatici spesso aggirano le protezioni on‑chain puntando al «ventre molle» off‑chain: API keys, credenziali server e altri segreti operativi necessari per il trading, il deployment di codice, lo staking e le attività di custodia.

Numerosi incidenti rilevanti sono iniziati proprio con compromissioni off‑chain delle credenziali, che hanno poi permesso spostamenti on‑chain dei fondi. Questo spostamento della minaccia evidenzia come il rischio non sia più limitato a chiavi dormienti, ma avvenga in un livello di esecuzione «live» dove il capitale si muove in frazioni di secondo.

Perché gli strumenti attuali non bastano

Le soluzioni esistenti spesso non sono all’altezza della complessità delle operazioni moderne. Anche se exchange, custodians e desk over‑the‑counter adottano policy robuste per specifiche funzioni, sincronizzare e far rispettare tali controlli in un ecosistema frammentato è estremamente difficile.

La gestione delle integrazioni con decine di CEX, DEX, fornitori di liquidità e partner introduce molteplici credenziali e dipendenze operative. Il coordinamento tra team di sviluppo, operation, trading, risk e sicurezza genera complessità che tende a crescere nel tempo, portando a errori di configurazione, regressioni nei controlli e punti ciechi sfruttabili.

In molti ambienti a bassa latenza, le chiavi vengono memorizzate con disponibilità completa nei sistemi live per minimizzare i ritardi: questa scelta architetturale, sebbene funzionale al modello di business dei market maker e dei trading firm, concentra l’autorità nel punto in cui avviene l’esecuzione rendendolo il vettore d’attacco più prevedibile e remunerativo per un aggressore.

Verso un’architettura a esposizione zero

La lezione appresa dalla protezione delle private keys è applicabile oltre la blockchain: occorre eliminare l’esposizione completa delle chiavi e imporre controlli di policy stringenti sull’utilizzo delle credenziali. Ciò significa ripensare l’architettura operativa per far sì che nessuna macchina o singolo dipendente abbia il controllo unilaterale sulle autorizzazioni che muovono valore.

Una possibile implementazione è basata su principi di multi-party computation e architetture che non espongono mai la chiave per intero a un singolo processo. In pratica, i sistemi dovrebbero eseguire firme e autorizzazioni in modo distribuito, applicando policy contestuali — ad esempio limiti di ammontare, geofencing, vincoli temporali e verifica dell’integrità dell’ambiente — prima di consentire qualsiasi azione che muova capitale.

Questa disciplina deve essere estesa anche alle credenziali di terze parti: ogni API key o credenziale di deployment dovrebbe essere trattata come una private key, con meccanismi di autorizzazione che non ne consentano la copia integrale in un ambiente di esecuzione.

Implicazioni per regolatori e operatori

L’evoluzione del rischio operativo ha rilevanza non solo tecnica ma anche regolamentare. Autorità di vigilanza e legislatori che si occupano di mercati finanziari e servizi di pagamento stanno osservando come le pratiche di custodia si estendano oltre le sole chiavi on‑chain, e potrebbero richiedere standard più elevati di governance, auditabilità e resilienza operativa.

Per gli operatori del settore la sfida è duplice: adottare soluzioni tecniche che riducano la superficie di esposizione e implementare processi di governance che armonizzino policy tra partner e fornitori. Standard condivisi e certificazioni indipendenti potrebbero contribuire a ridurre il rischio contro terze parti e a migliorare la fiducia degli investitori istituzionali.

Conclusioni operative

In sintesi, la protezione delle private keys rimane fondamentale, ma non più sufficiente. Il perimetro della custody oggi comprende un ampio ventaglio di credenziali e ambienti di esecuzione che richiedono lo stesso rigore: assenza di esposizione completa delle chiavi, controlli multi‑parte e policy contestuali applicate in modo coerente su tutte le integrazioni.

Solo adottando un modello che combina architetture a esposizione zero, automazione dei controlli e un quadro di governance esteso tra operatori sarà possibile ridurre significativamente il rischio sistemico e proteggere il capitale in un ecosistema sempre più distribuito e interdipendente.