Bug Coldcard: 1.778 bitcoin spariti, il tuo seed è il prossimo?

Nella notte fra il 30 e il 31 luglio 2026, nel giro di 41 minuti, 1.196 indirizzi bitcoin sono stati svuotati uno dopo l’altro con la stessa commissione di rete, la stessa struttura di transazione e nessun resto. In questa analisi di MoneyViz vedrai da dove arrivava quella chiave privata: da un errore di configurazione nel firmware di uno dei portafogli hardware più rispettati del settore, cioè nel programma interno che fa funzionare l’apparecchio, grande come una calcolatrice, in cui molti custodiscono le chiavi dei propri bitcoin.

Il difetto vive nel codice dal marzo 2021 ed è rimasto invisibile per cinque anni, attraverso decine di release e revisioni, perché produceva numeri che superavano ogni test statistico di casualità. Quegli stessi numeri, per chi conosceva il difetto, erano ricalcolabili a tavolino.

Il seed è il numero segreto da cui nasce tutto il resto: le dodici o ventiquattro parole che scrivi sul foglio di backup ne sono soltanto la trascrizione leggibile, e da quel numero il portafoglio ricava ogni chiave privata e ogni indirizzo. Chi lo indovina non deve rubare nulla di fisico: può autorizzare le tue transazioni come faresti tu. Vale la pena capire con precisione che cosa è andato storto, perché il meccanismo che ha ceduto qui è lo stesso che regge ogni portafoglio bitcoin al mondo.

Che cos’è una COLDCARD, in concreto?

È un apparecchio grande come una calcolatrice che custodisce le chiavi dei tuoi bitcoin restando scollegato da internet: le firme avvengono al suo interno e le chiavi non escono mai.

Un portafoglio hardware non contiene i bitcoin. I bitcoin stanno sul registro pubblico della rete, dove sono sempre stati; quello che il dispositivo custodisce sono le chiavi, cioè l’unica cosa al mondo che permette di spostarli. Quando vuoi pagare, il computer o il telefono prepara la transazione e la passa al dispositivo; il dispositivo la firma al proprio interno e restituisce soltanto la firma. La chiave non attraversa mai il computer, e resta quindi fuori dalla portata dei programmi malevoli che potrebbero averlo infettato.

La COLDCARD è prodotta dal 2017 dall’azienda canadese Coinkite e gestisce soltanto bitcoin: niente altre cripto-attività, per scelta deliberata, così da ridurre il numero di cose che possono rompersi. Oggi si comprano due modelli: la Q, circa 250 dollari, con schermo da 3,2 pollici, tastiera completa e lettore di codici QR; e la Mk5, circa 170 dollari, più compatta, con schermo OLED e tastierino numerico. Le generazioni precedenti si chiamavano Mk1, Mk2, Mk3 e Mk4: sono i nomi che ritrovi in tutta questa pagina, e sapere quale hai in mano è il primo dato che ti serve.

Nessuna di queste difese è stata aggirata. L’air-gap ha tenuto, gli elementi sicuri hanno fatto il loro lavoro, il codice era sotto gli occhi di tutti da cinque anni. Il difetto vive prima che le difese entrino in gioco: nell’istante in cui il dispositivo estrae il numero casuale da cui nascerà il portafoglio.

Che cosa è successo alle COLDCARD dal 30 luglio 2026?

Migliaia di indirizzi sono stati svuotati da chi ha ricalcolato le chiavi private a tavolino, senza mai toccare un dispositivo; l’ultima ondata confermata è del 6 agosto.

La prima ondata cade nella notte fra il 30 e il 31 luglio. Le due ricostruzioni più citate la datano in modo diverso perché usano fusi orari diversi: Galaxy Research la colloca il 30 luglio, mentre CoinDesk registra i movimenti sulla catena fra le 01:31 e le 01:56 UTC del 31 luglio. È lo stesso evento, letto su due orologi diversi. Le prime segnalazioni contavano 594 BTC spostati in venticinque minuti, circa 38 milioni di dollari; la ricostruzione completa di Galaxy Research ha poi mappato l’ondata a 1.083 BTC, pari a circa 70,2 milioni di dollari, prelevati da 1.196 indirizzi in 41 minuti.

L’avviso di sicurezza di Coinkite porta la data del 30 luglio 2026, con un aggiornamento sostanziale il 1° agosto: fra la pubblicazione dell’avviso e i primi prelievi di massa passano ore, non giorni.

Due elementi hanno reso evidente fin da subito che dietro non c’erano proprietari che spostavano i propri fondi. Il primo è la commissione. Ogni transazione ne pagava una identica, 30,0 satoshi (la centomilionesima parte di un bitcoin) per virtual byte, l’unità con cui si misura quanto spazio occupa una transazione nella rete. Le commissioni oscillano di ora in ora e ogni portafoglio le ricalcola al momento dell’invio: vederne centinaia identiche al decimale significa che il valore era scritto una volta sola dentro un programma automatico. Ed era un valore altissimo — quella settimana la commissione mediana stava fra 0,4 e 1,0 satoshi per virtual byte, quindi ogni prelievo pagava dalle trenta alle settantacinque volte il necessario: chi svuotava un portafoglio non stava badando al costo, gli importava solo arrivare prima del proprietario. Il secondo è l’assenza di resto. Quando paghi, di norma una parte del saldo torna a te su un nuovo indirizzo, il cosiddetto output di resto; qui ogni indirizzo veniva chiuso fino all’ultimo satoshi, comportamento tipico di un programma che raccoglie saldi interi.

Chainalysis ha osservato inoltre un ordine di priorità preciso: circa 30 milioni di dollari nei primi dieci minuti, con 1,8 milioni sottratti a una sola vittima. Chi ha condotto l’operazione sapeva già quali indirizzi erano vulnerabili e quanto contenevano, prima di iniziare.

Le ondate successive sono proseguite per una settimana. Al 4 agosto Galaxy Research contava 1.596 BTC, circa 100 milioni di dollari; l’aggiornamento del 13 agosto porta il totale confermato a oltre 1.778 BTC, circa 112 milioni, distribuiti su tre ondate principali e almeno trentatré altre tracce di attività, per oltre 5.200 indirizzi svuotati. Una quarta ondata da 638,5 BTC, ancora da confermare, porterebbe il conto a 2.417 BTC, oltre 151 milioni di dollari. Nello stesso periodo Galaxy descrive il passaggio da poche ondate coordinate a almeno quindici soggetti distinti che setacciano in parallelo lo stesso spazio di chiavi, e riferisce di aver parlato con oltre duecento vittime.

Dopo il 6 agosto Galaxy non registra più ondate confermate. Il rallentamento ha due spiegazioni possibili, entrambe indicate dagli analisti: chi era esposto ha migrato, oppure i portafogli raggiungibili sono già stati svuotati. Dei bitcoin sottratti, 1.531 non si sono ancora mossi dagli indirizzi di raccolta e restano tracciabili sulla catena; dei 246 movimentati, circa due terzi sono finiti in transazioni di mescolamento. Gli indirizzi colpiti appartenevano quasi sempre a chi conservava e non muoveva: il bitcoin tipico era fermo da tre anni e mezzo, e l’88 per cento dei fondi sottratti aveva almeno un anno.

Coinkite ha reagito anche sul piano industriale: ha fermato le spedizioni e distrutto le unità rimaste nei propri magazzini che avevano già installato il firmware difettoso, contattando direttamente i clienti che avevano già ricevuto l’ordine per comunicare l’avviso e i passaggi di migrazione.

Perché una chiave privata si può indovinare?

Perché ogni chiave nasce da un numero estratto a caso: se quel numero è prevedibile, chiunque può rifarlo a tavolino e ottenere la stessa identica chiave.

Una chiave privata somiglia alla combinazione di una cassaforte, con una differenza che cambia tutto: la cassaforte sta in casa tua, la combinazione si prova da qualunque punto del pianeta, in silenzio, un milione di volte al secondo, e te ne accorgi quando la porta è già aperta.

Quando un dispositivo crea un portafoglio nuovo, la prima cosa che fa è estrarre un numero casuale. Quel numero viene poi convertito nelle dodici o ventiquattro parole che sei abituato a scrivere sul foglio di backup, secondo lo standard BIP-39 (Bitcoin Improvement Proposal 39, la specifica che definisce le frasi mnemoniche). Dodici parole rappresentano 128 bit di casualità più 4 bit di controllo, una piccola somma di verifica che serve al dispositivo per accorgersi se hai trascritto male una parola; ventiquattro parole ne rappresentano 256 più 8.

Quanto tempo ci vorrebbe davvero, in anni

I bit restano astratti finché non si traducono in tempo. La tabella qui sotto lo fa, con un’ipotesi dichiarata: un milione di tentativi al secondo per ogni scheda grafica di fascia alta impegnata nella ricerca. È una stima prudente — gli strumenti pubblici di recupero seed su una scheda di ultima generazione arrivano a circa 1,8 milioni — e serve solo a dare l’ordine di grandezza: ogni tentativo comprende la ricostruzione della frase e la derivazione degli indirizzi, il passaggio che costa davvero.

Il salto fra la prima riga e le altre è il punto di tutta la vicenda. Un seed corretto non è difficile da indovinare: è impossibile, e lo resta anche immaginando ogni computer del pianeta al lavoro per l’intera storia dell’universo. Un seed a 40 bit è un compito di due settimane per un appassionato con una scheda da gioco. Fra i due estremi non c’è una gradazione: c’è il confine fra un segreto e una password.

È il punto che rende questo caso diverso dai furti a cui siamo abituati. Bitcoin ha continuato a funzionare come previsto, e con lui lo standard BIP-39 e la crittografia a curva ellittica, la matematica che lega una chiave privata al suo indirizzo pubblico. A cedere è stata la provenienza della casualità.

Quali COLDCARD e quali firmware sono coinvolti?

Tutti i modelli usciti dal 2021 in poi, con intervalli diversi per generazione e per ramo di firmware; restano fuori il Mk1 e i seed creati su Mk2 e Mk3 prima della serie 4.0.

Sulla prima versione colpita le due fonti primarie divergono di un numero. Coinkite indica l’intervallo «dalla 4.0.1 (marzo 2021) alla 4.1.9 inclusa»; Block Engineering elenca invece «v4.0.0 - v4.1.9» e data al 17 marzo 2021 la prima release che contiene il percorso difettoso. Nella pratica la divergenza non cambia il tuo comportamento: se il seed è nato su un Mk2 o un Mk3 con una qualsiasi versione della serie 4.0 o 4.1, trattalo come interessato.

Conta la versione di firmware installata nel momento in cui il seed è stato creato, non quella installata oggi. Il numero casuale da cui il seed nasce viene estratto una volta sola, alla creazione, e poi non viene più toccato: un dispositivo aggiornato la settimana scorsa, con un seed nato nel 2022, resta esposto esattamente come prima.

Sono a rischio anche Ledger, Trezor e gli altri?

No: il difetto sta nel firmware COLDCARD e non è condiviso con altri produttori. Ma un seed nato su una COLDCARD interessata resta debole anche dopo averlo importato su un dispositivo di un’altra marca.

Nei giorni successivi all’avviso i principali concorrenti hanno pubblicato una verifica, e le tre risposte coincidono.

• Ledger non è interessata: usa un generatore hardware certificato integrato nel proprio elemento sicuro, che produce 256 bit di casualità per ogni frase di recupero da ventiquattro parole
• Trezor non condivide quel codice e mescola fra loro casualità proveniente da più sorgenti indipendenti
• BitBox dichiara hardware, firmware e sorgenti di casualità diversi: né la BitBox02 né la BitBox02 Nova condividono con il firmware COLDCARD il codice in questione

C’è però una precisazione che vale più delle tre rassicurazioni messe insieme, e la scrive BitBox: «se hai generato le tue parole di recupero su una COLDCARD interessata e le hai poi ripristinate su una BitBox, il seed può restare vulnerabile». La debolezza sta nel numero da cui quelle parole sono nate, non nell’apparecchio che oggi le conserva, e viaggia con loro ovunque vengano copiate. Cambiare marca di dispositivo lascia le cose come stanno: serve un seed nuovo, creato da zero.

Vale anche la lettura opposta, per chi teme di dover ripensare tutto. La vicenda riguarda una singola implementazione, in un singolo punto del programma, rimasta scoperta per cinque anni. Gli altri produttori raccolgono quella casualità per strade diverse, e i seed nati sui loro dispositivi non sono toccati da questo difetto.

I dadi e la passphrase BIP-39 ti mettono al riparo?

I dadi contano soltanto se li hai lanciati alla creazione del seed; una passphrase forte già in uso alza una barriera in più, e nessuno dei due ripara il seed sottostante.

Coinkite indica due protezioni, entrambe legate a scelte fatte quando il seed è nato.

La prima è il lancio dei dadi. Il dispositivo permette di aggiungere casualità fornita da te: tiri un dado a sei facce, digiti i risultati, e quei valori si mescolano con quelli del generatore interno. La soglia indicata è di almeno 50 lanci equi, indipendenti e privati, e Coinkite aggiunge una condizione precisa: i lanci non devono essere stati registrati né esposti. Cinquanta lanci valgono circa 129 bit, all’incirca quanto dovrebbe valere un seed da dodici parole; da 99 lanci in su si arriva a circa 256 bit, il livello di un seed da ventiquattro. Se non ricordi con certezza di averli fatti, la risposta prudente è che non li hai fatti.

La seconda è la passphrase BIP-39, la parola o frase aggiuntiva che si combina alle dodici parole prima della derivazione e che dà vita a un portafoglio distinto. Coinkite avverte che «una passphrase crea un portafoglio diverso»: sposta i fondi in un ramo dell’albero che chi ricostruisce la frase non raggiunge senza indovinare anche la passphrase, e lascia intatto il seed sottostante. Vale come protezione se è lunga, unica, segreta, tenuta separata dal backup delle parole, e se nulla è rimasto sul portafoglio senza passphrase. Anche in quel caso Coinkite chiede di migrare: «anche con una passphrase forte, passa a un seed appena generato appena possibile».

Che cosa devi fare se hai una COLDCARD?

Aggiornare il firmware, generare un seed completamente nuovo e spostare i fondi: nell’ordine, e senza saltare il secondo passaggio.

Questo è il punto su cui tutte le fonti convergono, Coinkite compresa: aggiornare il firmware «non cambia e non ripara un seed esistente». La casualità si fissa nel momento della creazione, e nessun aggiornamento successivo la ricostruisce. Il numero è stato estratto una volta sola: riparare la macchina che lo ha estratto non ristampa il biglietto già uscito.

1. Smetti di ricevere fondi sugli indirizzi del portafoglio esistente
2. Aggiorna il firmware alla versione correttiva del tuo modello e del tuo ramo: 4.2.0 per Mk2 e Mk3; 5.6.0 standard oppure 6.6.0X Edge per Mk4 e Mk5; 1.5.0Q standard oppure 6.6.0QX Edge per Q
3. Conferma sul dispositivo che la versione installata è quella corretta, prima di creare qualunque cosa
4. Crea un seed completamente nuovo sul dispositivo aggiornato, senza ripristinare la frase precedente
5. Annota e verifica il nuovo backup, l’impronta del portafoglio e un indirizzo di ricezione mostrato sullo schermo; se scegli di usare una passphrase, conservala separata dalle parole
6. Spegni e riaccendi il dispositivo, poi controlla che impronta e indirizzo di ricezione coincidano con quelli che hai annotato
7. Manda una transazione di prova di importo minimo e attendi la conferma
8. Trasferisci il resto del saldo solo dopo che la prova è andata a buon fine, e conserva il vecchio backup finché l’intero saldo non è arrivato e confermato

Chi possiede un Mk2 o un Mk3 si trova nella condizione peggiore, con circa 40 bit residui e dispositivi ormai fuori dal ciclo di produzione. Diverse analisi indipendenti, fra cui quella di Wizardsardine, suggeriscono in quel caso di valutare direttamente un dispositivo di un altro produttore, oltre alla generazione di un nuovo seed.

Un portafoglio a più firme (multisig) ti protegge?

Dipende da dove sono nate le chiavi: un multisig protegge solo se almeno una firma necessaria viene da un dispositivo non interessato.

Un portafoglio multisig richiede più firme per muovere i fondi, tipicamente due su tre, e le chiavi stanno di norma su dispositivi diversi. La protezione regge finché nessun insieme di chiavi sufficiente a firmare può essere ricostruito per intero.

Se le tre chiavi di un 2-su-3 sono state generate tutte su COLDCARD con firmware interessato, ricostruirne due basta: il multisig non aggiunge nulla. Tre serrature sulla stessa porta tengono finché non le ha forgiate lo stesso fabbro, con lo stesso stampo. Se invece una delle chiavi viene da un produttore diverso, o da un seed creato con i dadi, quella firma resta fuori portata e lo schema tiene.

La regola operativa che emerge dalle analisi è di migrare ogni volta che un singolo percorso di spesa può essere soddisfatto usando soltanto chiavi interessate dal difetto. È anche il motivo per cui gli schemi con dispositivi di produttori diversi vengono raccomandati da anni: un difetto in un firmware lascia in piedi il resto dell’insieme.

Come nasce un seed, passaggio per passaggio?

Dal numero casuale alle parole, dalle parole a un seme binario, dal seme a tutti gli indirizzi: una catena in cui nessun passaggio aggiunge altra casualità.

Una volta estratto quel numero e convertito nelle parole, tutto il resto è deterministico: gli stessi ingredienti danno sempre lo stesso risultato, e nessun passaggio aggiunge altra casualità. Le parole attraversano PBKDF2-HMAC-SHA512, una funzione che le trasforma in un seme binario, e quel seme alimenta BIP-32, lo standard che genera a cascata tutti gli indirizzi del portafoglio. È l’albero del portafoglio: un’unica radice, il seed, e da lì rami e foglie, cioè gli indirizzi, tutti ricavabili dalla radice e da nient’altro.

Dove si è rotto il firmware COLDCARD?

In una riga di configurazione che controllava se un’opzione esisteva, invece di controllare se era attiva.

Nel marzo 2021 Coinkite, l’azienda canadese che produce COLDCARD, ha spostato i calcoli crittografici del dispositivo su libsecp256k1, la raccolta di codice già usata da Bitcoin Core, il programma che manda avanti la maggior parte dei nodi della rete bitcoin. Riusare codice collaudato invece di mantenerne uno proprio era la scelta giusta; per collegarlo al dispositivo serviva però un secondo pezzo di codice, chiamato libngu. Durante quella migrazione, come racconta l’azienda stessa nel proprio resoconto tecnico, «la generazione del seed è passata da ckcc.rng_bytes() a ngu.random.bytes()».

La prima funzione parlava direttamente al generatore hardware del microcontrollore STM32, il chip che governa il dispositivo. La seconda avrebbe dovuto fare lo stesso. Non lo ha fatto, e il motivo sta tutto in un dettaglio di compilazione: il passaggio in cui il codice scritto dai programmatori viene tradotto nel programma che il dispositivo esegue davvero, e in cui si decide quali pezzi di codice finiscono nel risultato finale.

Il firmware COLDCARD definisce l’opzione MICROPY_HW_ENABLE_RNG con valore zero. Coinkite lo racconta in prima persona: «ho impostato esplicitamente MICROPY_HW_ENABLE_RNG a zero, pensando che non ci servisse nessuna delle due versioni, ma non è quello che quel codice fa». La libreria di supporto verificava infatti con un controllo del tipo #ifndef MICROPY_HW_ENABLE_RNG: una domanda che chiede se l’opzione esiste, non se vale zero o uno. «Abbiamo definito quella macro come zero», scrive ancora Coinkite, «quindi l’#error non ha fermato la compilazione».

L’opzione esisteva. Il controllo passava. E la compilazione agganciava la strada sbagliata.

La modifica entra nel codice il 1° marzo 2021 e arriva sui dispositivi degli utenti il 17 marzo 2021, con il firmware 4.0.0.

Che cos’è Yasmarang e perché non regge per un portafoglio?

È un generatore software di ripiego, previsto per i microcontrollori senza chip dedicato e costruito per sembrare casuale, non per resistere a chi prova a ricostruirlo.

Quando un dispositivo non ha un generatore hardware, MicroPython — il linguaggio su cui gira il firmware COLDCARD — ricade su un generatore software chiamato Yasmarang, che vive nel file ports/stm32/rng.c del progetto. Aggiorna quattro variabili interne con qualche operazione aritmetica e restituisce numeri che superano senza problemi i test statistici di casualità. È il ripiego previsto per le schede prive di un circuito dedicato, e non è mai stato pensato per uso crittografico.

Il problema sta nel punto di partenza. L’analisi pubblicata da Block Engineering mostra che Yasmarang veniva inizializzato con tre soli ingredienti: i 32 bit bassi del numero di serie inciso nel chip, mescolati con SysTick, il contatore che scandisce il tempo trascorso dall’accensione; il registro dell’ora dell’orologio interno; e il contatore delle frazioni di secondo dello stesso orologio.

Il numero di serie è fisso e legato al lotto di produzione: non cambia mai, quindi non aggiunge nessuna imprevedibilità, e chi conosce il lotto lo restringe a poche possibilità. I due valori di tempo dipendono da quanto passa fra l’accensione e la creazione del seed, e sono fra loro correlati: un gesto ripetuto sempre allo stesso modo li rende quasi identici a ogni avvio. Nessuno dei tre viene mai riletto: si raccolgono una volta all’avvio e poi la sequenza scorre da sola, per sempre. Somiglia a comporre un PIN unendo il numero di matricola stampato sul retro dell’apparecchio e l’ora del giorno: due dati già scritti da qualche parte, che per chi li ha visti riducono i tentativi a una manciata.

Chi riesce a restringere quei tre valori a un insieme plausibile può riprodurre offline l’intera sequenza di numeri che il dispositivo ha usato per creare il seed.

Perché il rimedio dei modelli più recenti si ferma a 32 bit?

Perché prende quaranta byte di buona casualità dagli elementi sicuri, ne conserva quattro e li usa per riscrivere una sola variabile su quattro.

Su Mk4, Mk5 e Q il firmware fa un passaggio in più: legge 32 byte dal primo elemento sicuro e 8 dal secondo, li passa attraverso una funzione di hash e usa il risultato per rimescolare lo stato del generatore. Un byte vale 8 bit, quindi quei 40 byte sono 320 bit di ottima casualità. Sulla carta è il rimedio giusto. Nell’implementazione, come documenta Block, del risultato vengono conservati soltanto i primi quattro byte — 32 bit su 320 — e quei quattro byte finiscono in una sola delle quattro variabili interne di Yasmarang.

Le altre tre restano dove erano. Il risultato è un tetto matematico: a parità di stato di partenza, quel rimescolamento può produrre al massimo 2³² sequenze diverse, poco più di quattro miliardi.

È come avere un lucchetto a quattro rotelle e rimescolarne una sola: le altre tre restano nella posizione che avevano, e chi le ha già dedotte deve provare soltanto le posizioni della rotella rimasta, poco più di quattro miliardi invece dei numeri astronomici che il lucchetto dovrebbe garantire.

Quanto vale esattamente lo spazio di ricerca?

Circa 40 bit su Mk2 e Mk3 e circa 72 su Mk4, Mk5 e Q nell’ipotesi più favorevole, contro i 128 di un seed generato correttamente: nel caso peggiore si scende a poche decine di migliaia di tentativi.

Le due stime più citate coincidono. Coinkite scrive nel proprio resoconto di stimare «lo spazio di ricerca effettivo attorno ai 40 bit» per Mk2 e Mk3, e «attorno ai 72 bit» per i modelli che rimescolano la casualità presa dagli elementi sicuri. Block Engineering, partendo dal codice, colloca il primo caso sotto 2^40,7 e il secondo sotto 2^73,3.

Quei due numeri indicano il tetto dello spazio di ricerca, e valgono soltanto quando chi cerca non sa nulla dei valori di tempo del dispositivo. Nella stessa tabella Block riporta anche l’altra colonna, quella dei tempi noti: per Mk4, Mk5 e Q restano al massimo 2³² possibilità, per Mk2 e Mk3 ne resta una sola. Block lo scrive senza giri di parole: «questa non è sicurezza crittografica a 73 bit; i campi temporali sono correlati, possono occupare intervalli molto più ristretti e possono essere osservati o ricostruiti». E anche restando a metà strada, con il numero di serie noto e il solo contatore di avvio da indovinare, su Mk2 e Mk3 i valori possibili di quel contatore sono circa ottantamila (2^16,3): il lavoro di un attimo per un computer domestico.

Le cifre vanno lette per quello che sono: stime che dipendono da quanto chi cerca conosce già del dispositivo bersaglio. Un lotto di produzione noto restringe il numero di serie; abitudini d’uso ripetitive restringono i valori di tempo. Come mostra la tabella dei tempi nella Parte 1, lo spazio reale può risultare enormemente più piccolo del tetto teorico, e la misura che conta quando si decide se migrare è quella pessimistica.

Block segnala infine un caso limite che nessuna delle due stime copre: se durante l’avvio il dispositivo incontra un errore recuperabile prima di leggere gli elementi sicuri, il rimescolamento non avviene affatto e anche Mk4, Mk5 e Q scendono sotto 2^41,3, cioè nella fascia dei modelli più vecchi. Gli stessi autori lo classificano come ipotesi teorica — in produzione un guasto dell’elemento sicuro di norma blocca il dispositivo invece di lasciarlo proseguire — ma nessuno può escluderlo guardando il seed a posteriori.

Come si passa da un seed debole a un prelievo?

Si ricostruisce la sequenza offline, si derivano gli indirizzi e si chiede alla blockchain quali contengono fondi: la risposta è pubblica e gratuita.

Il procedimento non richiede di toccare il dispositivo, di conoscere il proprietario o di intercettare alcunché. Passo dopo passo:

1. Si riscrive Yasmarang così com’è in MicroPython, incluso il modo in cui viene inizializzato
2. Si enumerano i valori plausibili di numero di serie, contatore di avvio e orologio interno
3. Per ogni combinazione si produce la sequenza di numeri che il dispositivo avrebbe generato
4. Da ogni sequenza si costruisce la frase BIP-39 e si ricava il seme binario
5. Da ogni seme si derivano gli indirizzi più comuni, seguendo i percorsi di derivazione predefiniti, cioè le regole standard con cui dal seed si ricava il primo, il secondo, il centesimo indirizzo
6. Si interroga un nodo della rete bitcoin, cioè un computer che conserva l’intero registro pubblico delle transazioni, per sapere quali di quegli indirizzi hanno un saldo
7. Quando un indirizzo risponde, la chiave privata è già in mano: basta firmare, cioè autorizzare con quella chiave una transazione in uscita

Il sesto passaggio è quello che rende l’operazione praticabile. Per provare le password di un servizio online devi chiederlo al servizio, che conta i tentativi, li rallenta e a un certo punto blocca l’accesso. Il registro pubblico di bitcoin non conta nulla e non blocca nessuno: contiene già il saldo di ogni indirizzo esistente, chiunque può consultarlo quante volte vuole e gratuitamente, e il proprietario non ha modo di accorgersi che qualcuno sta verificando i suoi indirizzi. La lista dei bersagli e la conferma di aver indovinato arrivano dalla stessa fonte, sempre aperta.

Questo spiega anche la rapidità osservata sulla catena: migliaia di indirizzi svuotati in decine di minuti indicano che le chiavi erano già state calcolate prima, con calma, e che la notte del 30 luglio è stata soltanto il momento in cui sono state usate.

Che cosa lascia questo caso a chi custodisce da solo le proprie chiavi?

Che la casualità di un seed non si può verificare guardando il seed: va documentata quando viene creata.

Un seed a 40 bit e un seed a 128 bit sono indistinguibili. Stesse dodici parole, stesso formato, stesso aspetto sul foglio di backup. Nessun controllo eseguito dopo può dirti da dove arrivava il numero iniziale: puoi soltanto sapere quale dispositivo, con quale firmware, in quale data lo ha prodotto.

Da qui la raccomandazione che diversi analisti hanno formulato dopo il caso: annotare, al momento della creazione di un portafoglio, quali sorgenti di casualità sono state usate, come sono state combinate e con quale versione di firmware. È una nota di due righe che, cinque anni dopo, distingue una decisione informata da un’ipotesi.

Coinkite riconosce nel proprio resoconto che il difetto ha attraversato revisioni interne e verifiche esterne senza essere notato, e che nemmeno una revisione del codice affidata a un modello di intelligenza artificiale, poche settimane prima, lo aveva segnalato. Le due funzioni si chiamavano quasi allo stesso modo e avevano la stessa forma; l’errore stava in una direttiva di compilazione, nel posto dove nessuno guardava.

Il commento di Danilo Giudice

Rileggendo il resoconto di Coinkite e l’analisi di Block Engineering mi sono più volte chiesto che cosa avrebbe potuto fare, un possessore di COLDCARD, per accorgersene prima. La risposta onesta è niente. Il difetto stava in una direttiva di compilazione, la riga che decide quale delle due funzioni quasi omonime finisce dentro al firmware. Il risultato visibile, le dodici parole della seed phrase, ha lo stesso aspetto in entrambi i casi, e nessun controllo eseguito sul dispositivo dopo la creazione avrebbe potuto distinguerli.

Quindi il problema sta da un’altra parte: di un portafoglio bitcoin posso verificare da solo quasi tutto: che l’indirizzo sullo schermo sia quello che sto per usare, che la transazione firmata dica quello che credo dica, che il saldo sulla catena corrisponda. La casualità del seed resta l’unico ingrediente che sfugge a questa verifica. È osservabile una volta sola, nell’istante in cui viene estratta, e da quel momento in avanti devo fidarmi di chi ha scritto il firmware.

Chi ha scelto la custodia personale lo ha fatto per smettere di dipendere da un exchange, e quella scelta regge ancora: nessuno ha congelato quei fondi, nessuno li ha prestati a un terzo, il registro pubblico ha continuato a funzionare come previsto. Il caso COLDCARD indica dove è finita la fiducia che avevamo tolto al custodian. È passata al costruttore dello strumento, e merita la stessa diffidenza operativa che riservavamo all’exchange: dispositivi di produttori diversi con multisig a più firme, entropia propria mescolata a quella del dispositivo dove il modello lo consente, e due righe scritte il giorno della creazione, data, firmware, sorgenti usate, che possano distinguere, cinque anni dopo, la procedura usata.

La self-custody non è stata intaccata da questo avvenimento, anzi, ne uscirà rafforzata.

— Danilo Giudice

Fonti

• Block Engineering — Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware
• Coinkite — Technical Deep Dive into the Entropy Issue (30 luglio 2026, aggiornato il 1° agosto)
• Coinkite — Coldcard Security Advisory: versioni interessate, rami standard ed Edge, dadi e passphrase
• Wizardsardine — Critical Coldcard flaw: what happened, who is affected, and what to do
• BleepingComputer — ricostruzione delle ondate e cifre di Galaxy Research e Chainalysis
• The Hacker News — Coldcard Hardware Wallet Flaw Linked to $70 Million Bitcoin Theft in 41 Minutes
• CoinDesk — le prime 594 BTC, circa 38 milioni di dollari, fra le 01:31 e le 01:56 UTC del 31 luglio
• CoinDesk — l’invito di Coinkite a spostare i fondi mentre i prelievi proseguono (4 agosto 2026)
• Crypto Times — il conteggio rivisto di Galaxy Research al 4 agosto 2026: 1.596 BTC confermati, fino a 2.055
• Decrypt — l’aggiornamento di Galaxy Research al 13 agosto 2026: 1.778 BTC confermati, fino a 2.417 con la quarta ondata, nessuna attività confermata dopo il 6 agosto
• Bitcoin Magazine — almeno quindici attaccanti distinti e oltre duecento vittime sentite da Galaxy Research (17 agosto 2026)
• BIP-39 — specifica ufficiale delle frasi mnemoniche
• BIP-32 — specifica ufficiale dei portafogli deterministici gerarchici
• MicroPython — il file da cui proviene il generatore software di ripiego
• Coinkite — sito ufficiale del produttore COLDCARD
• MoneyViz — Quadro RW crypto 2026: guida completa alla compilazione
• MoneyViz — Tasse crypto 2026: cosa cambia con l’aliquota al 33%

Domande frequenti

Come faccio a sapere se la mia COLDCARD è interessata dal difetto di entropia?

Conta il firmware del giorno in cui hai creato il seed, non quello installato oggi. Sono interessati i seed nati su Mk2 e Mk3 con firmware dalla 4.0.1 alla 4.1.9 (Block Engineering include anche la 4.0.0: tratta come interessate tutte le serie 4.0 e 4.1), su Mk4 e Mk5 con qualsiasi versione precedente alla 5.6.0 standard o alla 6.6.0X Edge, e su Q con qualsiasi versione precedente alla 1.5.0Q standard o alla 6.6.0QX Edge. Restano fuori il Mk1 e i seed creati su Mk2 o Mk3 con firmware fino alla 3.2.2.

Aggiornare il firmware mette al sicuro il seed che ho già?

No. Coinkite lo scrive esplicitamente: aggiornare il firmware non cambia e non ripara un seed esistente. Il numero casuale viene estratto una volta sola, quando il seed nasce, e non viene mai più rigenerato. Per tornare al pieno livello di sicurezza servono tre mosse in quest'ordine: aggiorna il firmware, crea un seed completamente nuovo, sposta i fondi.

Quanta entropia resta a un seed generato con il firmware difettoso?

Circa 40 bit su Mk2 e Mk3, circa 72 bit su Mk4, Mk5 e Q, contro i 128 bit di un seed BIP-39 corretto da dodici parole. In tempo, a un milione di tentativi al secondo su una scheda grafica: 128 bit valgono circa 10 milioni di miliardi di miliardi di anni, 72 bit circa 150 milioni di anni, 40 bit circa 13 giorni. Sono tetti massimi: Block Engineering precisa che, conoscendo i valori temporali del dispositivo, per Mk4, Mk5 e Q restano al massimo 2^32 possibilità — poco più di un'ora di calcolo — e per Mk2 e Mk3 ne resta una sola.

Una passphrase BIP-39 protegge dal difetto di entropia COLDCARD?

Solo se la passphrase c'era già quando il seed è nato. In quel caso aggiunge una barriera indipendente, a condizione che sia lunga, unica, segreta e che tutti i fondi stiano nel portafoglio che la usa. Aggiungerla adesso a un seed già esistente lascia le cose come stanno. Coinkite chiede di migrare a un seed appena generato anche a chi ha una passphrase forte.

I lanci di dado sul dispositivo bastano a mettermi al riparo?

Sì, se i lanci erano almeno 50, equi, indipendenti, privati e mai registrati. Cinquanta lanci di un dado a sei facce valgono circa 129 bit di entropia, e Coinkite non considera a rischio per questo difetto un seed nato così. Se non ricordi con certezza di averli fatti, la risposta prudente è che non li hai fatti. Per il seed nuovo i dadi sono facoltativi: il firmware corretto basta da solo.

Un portafoglio multisig protegge dal difetto COLDCARD?

Solo se almeno una firma necessaria arriva da un dispositivo non interessato. Se tutte le chiavi di un 2-su-3 vengono da COLDCARD con firmware difettoso, ricostruirne due basta a spendere e il multisig non aggiunge nulla. Lo schema tiene quando una delle chiavi necessarie nasce su un dispositivo di un altro produttore o da un seed creato con i dadi.