Il 30 luglio 2026, tra le 01:31 e le 01:56 UTC, qualcuno ha svuotato circa 500 portafogli Coldcard in venticinque minuti. Bottino: 594 bitcoin, circa 38 milioni di dollari, poi in gran parte consolidati in un unico indirizzo. Non è stato un phishing, né un malware, né una truffa. È stato un difetto nel cuore stesso di uno degli hardware wallet più rispettati dai bitcoiner: il modo in cui generava le chiavi private. Vale la pena capirlo bene, perché tocca il fondamento della self-custody.

Il caso che non c’era

La sicurezza di Bitcoin poggia su un numero enorme e imprevedibile: il seed. Con 128 bit di entropia, indovinare una chiave è impossibile anche per tutti i computer del pianeta messi insieme. Ma se quel numero smette di essere casuale, l’intera fortezza crolla dalle fondamenta.

È esattamente ciò che è accaduto. Nel firmware di Coldcard convivevano due funzioni identiche per generare casualità: quella hardware scritta da Coinkite, che sfrutta il rumore fisico del chip, e un ripiego software ereditato da MicroPython. Un controllo del compilatore verificava soltanto se un’impostazione esistesse, senza mai leggerne il valore. Risultato: da una migrazione del marzo 2021 in poi, il dispositivo ha silenziosamente usato il ripiego software invece del vero generatore hardware.

Quel ripiego non pescava dal caso, ma da dati prevedibili del dispositivo: il numero di serie e l’orologio interno, un contatore che segue schemi indovinabili. Un seed che sembrava inviolabile si è trasformato in un indovinello risolvibile. Coinkite stima lo spazio di ricerca effettivo di una Mk3 attorno ai 40 bit, contro i 128 previsti: non più un oceano, ma una piscina.

Chi è colpito e quanto

Il problema riguarda in modo diverso i vari modelli. Le Mk3 con seed generato dal firmware 4.0.1 in poi sono le più esposte, ed è da lì che sono spariti i fondi. Le più recenti Mk4, Q e Mk5 ereditavano una versione attenuata del difetto: grazie all’entropia aggiuntiva dei loro secure element arrivavano a circa 72 bit, meglio ma comunque sotto la soglia di sicurezza. Restano immuni i firmware precedenti alla 4.0.0 e i prodotti Tapsigner, Opendime e Satscard, che usano codice diverso.

Un punto cruciale, spesso frainteso: un seed debole resta debole per sempre. L’air gap, il secure element, la firma offline, la conferma sullo schermo — tutte le difese classiche di un hardware wallet proteggono una chiave già esistente. Non servono a nulla se la chiave era prevedibile fin dalla nascita. Per lo stesso motivo, ripristinare quel seed su un dispositivo di un’altra marca non lo rende più sicuro: Trezor lo ha ribadito ai propri utenti, rassicurandoli di non essere coinvolti. Anche il team di ingegneria Bitcoin di Block ha pubblicato un’analisi indipendente confermando che i propri prodotti non erano affetti.

C’è poi un dettaglio inquietante sull’origine. Coinkite ipotizza che un attaccante abbia usato un’intelligenza artificiale per analizzare le vecchie versioni del firmware open source e scovare il bug. L’azienda ammette di aver dato in pasto lo stesso codice a uno dei migliori modelli poche settimane prima, senza che trovasse nulla. Difensori e aggressori usano gli stessi strumenti: stavolta hanno aiutato solo i secondi.

Cosa fare se possiedi una Coldcard

Prima regola: niente panico. La fretta, in queste situazioni, causa più danni del bug stesso — indirizzi digitati male, wallet temporanei improvvisati, backup incompleti. Coinkite ha rilasciato un hotfix d’emergenza (versione 5.6.0 per Mk4 e Mk5, 1.5.0Q per la Q), ma aggiornare non ripara un seed già creato: serve generare un seed nuovo su hardware corretto e spostarci i fondi. Per le Mk3, ormai fuori supporto, esiste un percorso di migrazione dedicato.

Il metodo prudente è quello di sempre: genera il nuovo wallet, verifica backup, fingerprint e indirizzo di ricezione, invia un piccolo pagamento di prova, e solo dopo trasferisci l’intero saldo. Chi aveva aggiunto una passphrase BIP-39 robusta e unica, almeno 99 lanci di dado come entropia esterna, o una configurazione multisig con firmatari indipendenti, aveva una barriera in più — ma Coinkite raccomanda comunque di migrare a un seed nuovo.

Conclusione

Questa vicenda non è un atto d’accusa contro la self-custody, ma una lezione sulla sua manutenzione. Il codice open source e le build riproducibili di Coldcard hanno permesso a chiunque di verificare quale firmware girasse — ma nessuno aveva studiato il preciso percorso che generava il seed. La trasparenza è una condizione necessaria alla sicurezza, non una garanzia automatica. La custodia a freddo non è un gesto che si compie una volta e si dimentica: è un impegno che va rivisto, aggiornato e stratificato con passphrase, dadi e multisig. Le tue chiavi restano tue. Ma proprio per questo, la responsabilità di controllarle è, fino in fondo, soltanto tua.

Fonti: