Gli utenti canadesi rappresentano il 25% delle perdite causate dalla vulnerabilità di Coldcard

Distribuzione geografica delle perdite

I possessori canadesi di Bitcoin sono emersi come il singolo gruppo demografico più colpito dall’attuale exploit del portafoglio hardware Coldcard, assorbendo il 25% di tutte le perdite attribuibili. Gli analisti osservano che questa forte concentrazione regionale è in linea con la significativa presenza locale della società madre di Coldcard, Coinkite, che ha sede a Toronto.

Secondo il monitoraggio visivo di Chainalysis, l’Australia si colloca al secondo posto tra i paesi più gravemente colpiti, rappresentando dal 15% al 20% dei danni totali. Nel frattempo, gli Stati Uniti e la Thailandia seguono a ruota, con perdite comprese tra il 10% e il 15%. Sebbene la violazione abbia colpito più duramente le giurisdizioni anglofone e quelle che hanno adottato precocemente il bitcoin, i dati evidenziano un’ampia ripercussione globale in Europa occidentale, America Latina e nei principali hub africani delle criptovalute, come la Nigeria e il Sudafrica.

Il valore totale dei beni sottratti a seguito dell’incidente ha raggiunto i 116 milioni di dollari. In un’analisi della violazione, Galaxy Research ha identificato un aggiornamento del firmware del marzo 2021 — in particolare l’implementazione di un nuovo generatore di numeri casuali — come l’unico punto di errore che ha reso possibile l’attacco.

«Il problema era che era stato configurato in modo errato e, di default, utilizzava invece un generatore più debole. Il malfunzionamento avveniva in modo silenzioso, senza alcun preavviso. Nessuno sapeva che le proprie chiavi private venivano generate con bassa entropia», ha dichiarato Galaxy Research. «Cinque anni dopo, un hacker ha sottratto 70 milioni di dollari da 1.200 portafogli in 41 minuti».

Spiegando come i controlli standard abbiano trascurato il bug per oltre cinque anni, Natalie Newson, investigatrice senior specializzata in blockchain presso CertiK, ha rivelato che la causa principale derivava da uno specifico errore di configurazione: MICROPY_HW_ENABLE_RNG era impostato a zero.

«Per un controllo statico #ifndef, una macro impostata a 0 risulta comunque definita», ha spiegato Newson. «Il controllo di sicurezza ha restituito il valore "true", sopprimendo il controllo #error e consentendo al sistema di compilazione di procedere come se tutto fosse configurato correttamente».

Protocolli di risposta agli incidenti e di risoluzione delle emergenze

Per prevenire simili ricorsi silenziosi alla pseudo-casualità del software, Newson ha esortato i produttori a rivedere i propri standard architetturali. «Il controllo più efficace consiste nel rimuovere il fallback dalla produzione e avvalersi di un unico fornitore di RNG approvato», ha sottolineato, osservando che l’intero percorso, dall’acquisizione dell’entropia alla generazione del seme, deve rientrare rigorosamente nei limiti di convalida definiti dallo standard NIST FIPS 140-3.

Nel gestire il rischio operativo legato al rilascio affrettato di patch di emergenza mentre sono in corso scansioni automatizzate attive, Newson ha sottolineato che la risposta agli incidenti deve dare priorità alla comunicazione con gli utenti parallelamente ai test tecnici.

«La priorità dovrebbe essere quella di comunicare immediatamente la portata della vulnerabilità, identificare gli utenti interessati e fornire chiare indicazioni di mitigazione, validando al contempo accuratamente qualsiasi correzione prima del rilascio», ha affermato Newson, aggiungendo che la trasparenza è fondamentale tanto quanto la patch stessa.

Per gli utenti non esperti in possesso di frasi seed compromesse che temono di rendere inutilizzabili i propri dispositivi durante gli aggiornamenti di emergenza del firmware, Newson ha raccomandato un protocollo di risoluzione rigoroso: in primo luogo, gli utenti dovrebbero procurarsi un portafoglio hardware affidabile, generare una nuova frase seed offline e verificare la configurazione con una piccola transazione di prova. Successivamente, dovrebbero trasferire tutti i fondi rimanenti alla configurazione appena verificata prima di tentare qualsiasi aggiornamento del firmware sul dispositivo originale. Newson ha inoltre esortato gli utenti a evitare di creare un unico punto di errore utilizzando portafogli hardware di diversi produttori per distribuire il rischio su più conti.

Una svolta per la narrativa sull’autocustodia

L’incidente ha costretto il settore dell’autocustodia e i suoi sostenitori a confrontarsi con questioni fondamentali relative ai modelli di sicurezza standard. I critici indicano l’improvviso prosciugamento delle partecipazioni inattive e a lungo termine come prova del fatto che l’esecuzione offline da sola non garantisce una protezione assoluta.

Nanak Nihal Khalsa, cofondatore di Human.tech, ha sostenuto che l’incidente sottolinea la realtà persistente del rischio legato a terze parti all’interno degli ecosistemi hardware. “Il motto ‘Non sono le tue chiavi, non sono le tue monete’ tralascia un fatto importante: si sta sempre esternalizzando la fiducia, anche con l’autocustodia. Questo non fa che aggiungere un’ulteriore prova del fatto che l’autocustodia non cambia questa realtà», ha osservato Khalsa, avvertendo che i vettori di minaccia emergenti, come gli exploit assistiti dall’intelligenza artificiale, probabilmente aggraveranno questi rischi.

Newson di CertiK ha fatto eco alle preoccupazioni relative alle configurazioni a firma singola, sottolineando che l’adozione su larga scala richiede sistemi progettati con un ‘degrado graduale’, in cui un singolo errore — da parte di un utente o di un fornitore — non comporti la perdita dei risparmi di una vita dell’utente.

"L'autocustodia a firma singola non offre alcun margine di errore", ha affermato Newson. "Gli utenti che si affidano a un unico dispositivo ripongono la propria fiducia nell’hardware fisico, nel codice e in tutte le sue dipendenze, nonché nei controlli di qualità volti a individuare eventuali problemi".

Di conseguenza, il consenso del settore si sta orientando verso configurazioni multi-fornitore, multi-firma o a firma a soglia (MPC) come standard di base imprescindibile. «Sì, dovrebbe essere lo standard di base predefinito», ha concluso Newson. "L'obiettivo è passare dal 'fidarsi di un singolo dispositivo' al garantire che nessun singolo componente o soggetto compromesso possa movimentare i fondi. In pratica, le chiavi di firma o le quote di soglia dovrebbero estendersi su domini organizzativi e tecnologici indipendenti, in modo che nessun fornitore possa ricostruire la chiave o autorizzare una transazione da solo."