Coldcard: vulnerabilità nella generazione delle chiavi, cosa è successo e chi è coinvolto

Tra il 30 luglio e il 3 agosto 2026 sono state individuate diverse ondate di sweep compatibili con lo sfruttamento della vulnerabilità Coldcard. Le prime tre ondate ricostruite da Galaxy Research avevano interessato circa 1.367,05 bitcoin e 4.585 indirizzi. Nelle prime ore del 3 agosto, Alex Thorn, responsabile della ricerca di Galaxy, ha segnalato una probabile quarta ondata: circa 388,93 bitcoin movimentati attraverso 218 transazioni, associate a 462 possibili indirizzi vittima. Al momento della segnalazione, ulteriori transazioni compatibili risultavano ancora presenti nella mempool.

Sommando provvisoriamente i dati delle prime tre ondate e quelli della quarta segnalazione, l’ammontare osservato arriverebbe a circa 1.756 bitcoin. Si tratta tuttavia di una ricostruzione on-chain ancora in evoluzione: i numeri potrebbero cambiare e non costituiscono la prova individuale che ogni indirizzo individuato sia stato generato da una Coldcard vulnerabile.

È essenziale distinguere subito i piani: non è stato violato Bitcoin, non è stata rotta la crittografia della rete e non esiste un problema generale dello standard BIP39. La vulnerabilità riguardava il modo in cui specifiche versioni del firmware Coldcard producevano la casualità usata per creare il seed.

Una seed phrase non è soltanto una lista di parole. Le parole rappresentano un numero casuale dal quale vengono derivate le chiavi private. La qualità di quella casualità viene chiamata entropia: più è elevata e imprevedibile, più combinazioni deve provare un attaccante.

La crescita è esponenziale: ogni bit aggiuntivo raddoppia lo spazio di ricerca. Passare da 40 a 72 bit non significa avere “quasi il doppio” della sicurezza, ma circa 4,3 miliardi di volte più combinazioni. Passare da 72 a 128 bit aggiunge un ulteriore fattore di circa 72 milioni di miliardi.

Nel formato BIP39, una seed da 12 parole contiene 128 bit di entropia reale; una da 24 parole ne contiene 256. Quindi sì: 24 parole offrono uno spazio teorico molto più grande. Ma non significa che una seed da 12 parole, se generata correttamente, sia debole: 2¹²⁸ possibilità sono già fuori dalla portata di un attacco brute force realistico.

In pratica, la sicurezza dipende spesso più dalla qualità della generazione, dal backup, dalla riservatezza e dall’eventuale passphrase che dal semplice aumento del numero di parole. Ventiquattro parole non possono compensare una fonte di casualità prevedibile.

Coldcard disponeva realmente di un generatore hardware di numeri casuali e di un’implementazione capace di utilizzarlo. Il problema nacque nel 2021, quando la generazione del wallet passò da ckcc.rng_bytes(), collegata al TRNG STM32, a ngu.random.bytes().

In quella nuova catena di chiamate, la funzione rng_get() si risolveva sul generatore software deterministico Yasmarang incluso in MicroPython, invece che sull’implementazione hardware prevista. Il controllo di compilazione usava #ifndef: verificava quindi soltanto che MICROPY_HW_ENABLE_RNG fosse definita, non che avesse un valore diverso da zero. Poiché la macro era definita con valore zero, la compilazione riusciva senza bloccare il percorso sbagliato.

Secondo le stime preliminari di Coinkite, sui Mk2 e Mk3 coinvolti lo spazio effettivo poteva scendere a circa 40 bit. Su Mk4, Mk5 e Q, le fonti aggiuntive provenienti dai secure element hanno ridotto l’impatto, ma non hanno ripristinato il livello di sicurezza previsto: Coinkite stima circa 72 bit invece dei 128 attesi.

Block ha inoltre evidenziato che il reseed conservava soltanto quattro byte del materiale proveniente dai secure element: una volta fissati gli altri elementi dello stato, ciò distingueva al massimo 2³² flussi attraverso quel contributo sicuro. Le stime utilizzano modelli d’attacco differenti e non rappresentano un costo universale valido per ogni dispositivo, ma convergono sul fatto che la sicurezza fosse molto inferiore a quella prevista.

L’elemento decisivo è il firmware utilizzato nel momento in cui il seed o il materiale crittografico sono stati generati.

L’elemento decisivo non è il firmware installato oggi, ma quello utilizzato nel momento in cui il seed o il materiale crittografico sono stati generati.

Aggiornare il firmware non modifica un seed già generato. Se il seed è stato creato con una delle versioni coinvolte, bisogna prima installare una versione corretta del firmware, generare un seed completamente nuovo e trasferire i fondi verso indirizzi derivati dal nuovo wallet.

Importare il vecchio seed su un’altra Coldcard, su BitBox, Jade o qualsiasi altro hardware wallet non risolve il problema: la debolezza appartiene al seed originario, non al dispositivo sul quale viene successivamente utilizzato.

In base alle analisi disponibili, chi durante la generazione aveva aggiunto almeno 50 lanci di dado realmente casuali, indipendenti e rimasti privati disponeva di una fonte aggiuntiva di entropia sufficiente a proteggere il seed da questa specifica vulnerabilità. Chi non ricorda con certezza quanti lanci abbia effettuato dovrebbe adottare l’ipotesi più prudente e considerare il seed coinvolto.

Una passphrase BIP39 forte, casuale, unica e mantenuta segreta può aver costituito un’ulteriore barriera contro l’attacco. Tuttavia, non corregge il difetto originario del seed: anche in questo caso, per eliminare definitivamente l’esposizione, è consigliabile generare un nuovo seed e migrare i fondi.

Aggiornare il firmware non basta: corregge la generazione futura, ma non ripara le chiavi già create.

Le analisi tecniche successive hanno mostrato che lo stesso generatore casuale vulnerabile veniva utilizzato anche da diverse funzioni avanzate di Coldcard, tra cui:

– paper wallet e chiavi private autonome generate casualmente;
– modalità casuale di Seed XOR;
– alcune chiavi temporanee utilizzate per clonazione, comunicazione USB, Key Teleport e Web2FA;
– password generate tramite Secure Notes;
– alcuni materiali utilizzati dalla modalità HSM.

Questo non significa che tutte queste funzioni avessero lo stesso livello di rischio o che compromettessero automaticamente il wallet principale. Significa però che il materiale crittografico generato attraverso quelle funzioni poteva ereditare i limiti dello stesso generatore vulnerabile.

La modalità deterministica di Seed XOR non utilizzava direttamente quel generatore. Anche i segreti derivati tramite BIP85 non venivano generati direttamente dal PRNG difettoso, ma ereditavano completamente la sicurezza del seed principale: se il seed originario era prevedibile, devono essere considerati esposti anche i wallet, le password e le altre chiavi derivate da esso.

Chi ha utilizzato una di queste funzioni con un firmware coinvolto non dovrebbe quindi limitarsi a valutare il seed principale, ma dovrebbe verificare separatamente il materiale generato e considerare la sua sostituzione.

L’aggiunta di almeno 50 lanci di dado proteggeva il seed finale da questa specifica debolezza, ma non rendeva automaticamente sicure le altre funzioni che chiamavano direttamente il generatore vulnerabile.

Noi di Villaggio Bitcoin siamo rivenditori ufficiali di BitBox e Blockstream Jade. Il problema trovato su Coldcard non riguarda BitBox o Jade: si tratta di implementazioni distinte e questa specifica vulnerabilità non è presente nei due prodotti.

BitBox02 e BitBox02 Nova combinano cinque fonti di entropia: generatore del secure chip, generatore del microcontrollore, valore casuale univoco impostato in fabbrica, entropia fornita dall’app e hash della password del dispositivo. Le fonti sono combinate crittograficamente in modo che la robustezza complessiva sia almeno pari a quella della fonte più forte. La procedura è descritta nella documentazione di sicurezza BitBox.

Blockstream Jade combina a sua volta più fonti indipendenti, tra cui generatore hardware, input e timing dell’utente, contatori della CPU, stato del dispositivo ed entropia fornita dall’app. Blockstream ha confermato che la linea Jade non è interessata e documenta nel dettaglio come viene costruita la recovery phrase.

Resta una precisazione importante: se un seed vulnerabile generato originariamente su Coldcard viene importato su BitBox, Jade o qualsiasi altro dispositivo, il problema rimane nel seed. Cambiare hardware senza creare nuove chiavi non modifica l’entropia originale.

Nessun dispositivo o software complesso è infallibile al 100%. Questo episodio, però, non dimostra che la self-custody non funzioni: mostra perché servono codice aperto, ricerca indipendente, bug bounty, verifiche end-to-end e controlli automatici che seguano il percorso realmente eseguito dal software.

Coinkite ipotizza che l’errore possa essere stato individuato con strumenti di intelligenza artificiale applicati all’analisi del codice. Gli stessi strumenti possono essere usati anche in difesa: per esaminare più versioni, individuare percorsi non raggiunti dai test tradizionali e imporre controlli di compilazione più severi.

È possibile aumentare ulteriormente la resilienza con una passphrase ben costruita o con un wallet multisignature composto da chiavi realmente indipendenti, preferibilmente generate tramite dispositivi e implementazioni differenti.

Nel multisig, però, non basta che sia presente almeno una chiave sicura: bisogna verificare che nessun percorso di spesa possa raggiungere la propria soglia utilizzando soltanto chiavi coinvolte. In un 2-di-3 composto da due Coldcard vulnerabili e un dispositivo differente, per esempio, le due Coldcard possono ancora firmare insieme e spendere i fondi.

Per resistere a un difetto comune di un produttore, ogni percorso valido deve richiedere un numero sufficiente di chiavi generate indipendentemente e non coinvolte. Anche in questo caso, maggiore complessità significa più possibilità di errore nel backup, nel recupero o nella successione.

Custodire bitcoin significa custodire le chiavi che permettono di spenderli. È come proteggere la combinazione di una cassaforte piena d’oro: se qualcuno la scopre può prendere tutto; se la perdi, nessuno può ricrearla per te.

Per questo la sicurezza non dipende soltanto dall’hardware wallet, ma dall’intero sistema di generazione, backup, ridondanza, recupero e successione.

Articolo a cura di
Alessandro Angeli

Analisi Indipendenti

Analisi on-chain degli sweep

Verifiche sui dispositivi non coinvolti

Segnali dal Villaggio è curata da Alessandro Angeli e Valerio Dalla Costa.