Quando il rischio esce dalla porta e rientra dalla finestra. Il caso Coldcard e i bitcoin trafugati senza hack

Per anni la regola è stata "not your keys, not your coins". Il caso Coldcard mostra che le proprie chiavi non bastano: se il dispositivo che le genera sbaglia a produrre casualità, la chiave è indovinabile pur non essendo mai stata esposta. Ed è un difetto che nessun aggiornamento può riparare.

Cosa è successo, con precisione

Il 30 luglio 2026 Coinkite ha pubblicato un advisory di sicurezza sui propri hardware wallet Coldcard. Non si è trattato di un'intrusione: nessuno ha bucato i dispositivi, e chiamarlo "hack" è fuorviante. Il problema è un difetto nella generazione dell'entropia introdotto con il firmware 4.0.1 di marzo 2021: la casualità da cui nasce il seed non veniva prodotta come previsto.

Sono interessati Mk2 e Mk3 con firmware dalla 4.0.1 alla 4.1.9, Mk4 e Mk5 prima della 5.6.0, e Q prima della 1.5.0Q. Per Mk4, Mk5 e Q l'advisory quantifica: i seed generati contengono "approximately 72 bits of entropy rather than the expected 128 bits". La coverage tecnica indipendente attribuisce il difetto a una libreria interna che, invece dell'RNG hardware del microcontrollore, usava un generatore software alimentato da numero di serie, orologio interno e pressioni dei tasti, con entropia sui Mk3 stimata attorno ai 40 bit: sono ricostruzioni plausibili e coerenti con i fatti, ma l'advisory ufficiale non le conferma e non nomina la libreria.

La differenza fra 128, 72 e 40 bit non è accademica. A 40 bit un attaccante con risorse ordinarie enumera lo spazio delle chiavi; a 72 bit l'impresa è costosa ma non impossibile; a 128 bit è fuori portata. Il 30 luglio circa 594 BTC — allora ~38 milioni di dollari — sono stati prelevati da circa 500 indirizzi a firma singola in meno di mezz'ora, e il totale riportato nei giorni successivi è salito attorno a 1.367 BTC da oltre 4.500 indirizzi. Molti erano dormienti da anni: segno che l'attaccante aveva precalcolato un ampio insieme di chiavi vulnerabili e stava eseguendo un drenaggio sistematico, non reagendo a movimenti in corso.

Il difetto che nessuna patch ripara

Coinkite ha rilasciato firmware correttivo il giorno seguente, ma con un avvertimento che è il cuore tecnico della vicenda: aggiornare il firmware non ripara un seed già generato. Occorre creare un seed nuovo sul firmware corretto e spostare i fondi.

È una categoria di difetto che vale la pena isolare, perché non si comporta come le altre. Quando un bug produce un segreto persistente, la correzione del bug non annulla il danno: la chiave debole esiste da cinque anni, è già scritta su un foglio in una cassaforte, e l'attacco è arrivato dopo. È la stessa struttura temporale di harvest now, decrypt later: il momento della compromissione e il momento dello sfruttamento sono separati da anni, e nel mezzo la vittima non ha alcun segnale. Nei sistemi che generano segreti a vita lunga, il tempo lavora contro chi li custodisce.

Non le tue chiavi: il tuo generatore

"Not your keys, not your coins" descrive la custodia e tace sulla generazione. È una formula che risolve un problema — il rischio di controparte dell'exchange — e ne nasconde un altro: la self-custody non elimina la fiducia, la sposta. Dal custode al fornitore del firmware, cioè in un punto meno verificabile dall'utente e privo di qualsiasi rimedio contrattuale. Nessuno, comprando il dispositivo, era in condizione di sapere che l'RNG hardware non veniva usato.

Il punto interessante per chi si occupa di sicurezza è che questa verifica è un problema risolto, fuori dal mondo consumer. Le sorgenti di entropia si validano, e gli standard esistono da anni: NIST SP 800-90B per la stima e il test delle sorgenti, AIS-31 del BSI tedesco, la certificazione FIPS 140-3 per i moduli crittografici. La domanda "chi ha validato il vostro generatore, e con quale metodo?" è ordinaria in un capitolato per un HSM, e assente nell'acquisto di un dispositivo che protegge cifre a sei zeri.

Vale la pena estendere la domanda oltre le criptovalute, perché la stessa classe di difetto colpisce chiavi che ogni azienda genera continuamente: chiavi SSH, certificati TLS, secret di firma dei token JWT. Una casualità debole non lascia tracce nei log, non fa fallire nessun test funzionale e non attiva alcun alert: il sistema funziona perfettamente, semplicemente le sue chiavi sono prevedibili. È lo stesso fenomeno che rende inaffidabili le password generate da un modello linguistico, ottimizzato per plausibilità e non per casualità.

Il dado che ha salvato qualcuno

Un dettaglio dell'advisory smentisce la lettura fatalista secondo cui l'utente non poteva fare nulla. Coldcard consente di aggiungere tiri di dado fisici alla generazione del seed, e il dispositivo "hashed the device-generated seed together with every dice roll entered": chi aveva usato 50 o più tiri disponeva di almeno 128 bit di entropia dal solo input umano, indipendentemente dal difetto del firmware. Quei seed non erano attaccabili.

È difesa in profondità dimostrata dai fatti, non in teoria: una seconda sorgente di entropia indipendentedalla prima ha tenuto quando la prima era silenziosamente rotta. Vale come principio generale di progettazione — quando un controllo può fallire senza dare segnali, la ridondanza non è zelo, è l'unica difesa disponibile.

La domanda vera: autocustodia o custode terzo?

Qui il discorso smette di essere tecnico e diventa gestione del rischio. Le implementazioni crittografiche sono fragili, gli errori operativi sono frequenti, e la conclusione ragionevole non è scegliere uno slogan: è fare una valutazione del rischioe confrontare i due scenari. Perché non sono ordinabili su una scala "più sicuro / meno sicuro": hanno profili di rischio con eventi diversi.

Autocustodia. Gli scenari dominanti sono l'errore operativo — seed trascritto male, backup unico, backup in un solo luogo fisico, passphrase dimenticata — il difetto del fornitore che abbiamo appena visto, la coercizione fisica, e l'evento che quasi nessuno pianifica: la morte o l'incapacità di chi detiene le chiavi, con i fondi irraggiungibili per gli eredi. L'impatto è totale e irreversibile, non c'è appello, e soprattutto il rischio non è trasferibile: nessuna polizza copre il vostro errore di trascrizione, e nessuno vi risarcisce se sbagliate.

Custodia presso terzi. Gli scenari sono l'insolvenza del custode, la frode interna, la violazione dei suoi sistemi, il sequestro o la censura, il rischio giurisdizionale. L'impatto può essere altrettanto totale, ma esistono un rimedio e un trasferimento — entrambi parziali, e conviene sapere esattamente dove si fermano.

La conclusione più utile è anche la meno ideologica: la custodia terza non è più sicura, è più governabile. Converte un rischio tecnico, che dipende da una competenza crittografica e operativa rara, in un rischio di controparte — cioè nella categoria di rischio che qualunque organizzazione già sa trattare: due diligence del fornitore, requisiti contrattuali, clausole di responsabilità, assicurazione, monitoraggio. Sono i controlli sui rapporti con i fornitori dell'Annex A della ISO 27001 (A.5.19–A.5.22), applicati a un fornitore come agli altri. Per un'azienda questo è spesso l'argomento decisivo. Per un privato con competenze crittografiche solide, procedure di backup provate e un piano successorio scritto, la valutazione può ribaltarsi legittimamente: il punto non è la risposta, è aver fatto il confronto.

Che garanzie chiedere a un custode

Se la scelta è il trasferimento, va verificato che il rischio si trasferisca davvero. In Unione europea il riferimento è il regolamento MiCA, che disciplina la custodia di cripto-attività per conto dei clienti. La checklist minima:

Autorizzazione, verificata nei registri — il custode deve essere un prestatore autorizzato ai sensi dell'articolo 59 MiCA, e la cosa si controlla negli elenchi pubblici delle autorità, non nella pagina "compliance" del suo sito.
Segregazione legale, non solo contabile — l'articolo 75(7) impone che le cripto-attività in custodia siano "legally segregated from the crypto-asset service provider's estate in the interest of the clients". È la protezione che decide se, in caso di insolvenza, si è titolari di beni propri o creditori in mezzo agli altri.
La clausola di responsabilità, letta nei suoi limiti — l'articolo 75(8) rende il custode responsabile della perdita di cripto-attività o dei mezzi di accesso "as a result of an incident that is attributable to them", con responsabilità "capped at the market value of the crypto-asset that was lost, at the time the loss occurred". Due limiti da tenere presenti: il risarcimento è ancorato al valore al momento della perdita, quindi l'apprezzamento successivo resta a carico vostro; e copre solo gli incidenti attribuibili al custode, non un problema inerente al funzionamento del ledger o un evento fuori dal suo controllo ragionevole.
La polizza, nei dettagli — l'esistenza di un'assicurazione dice poco. Contano il sottolimite per i fondi in cold storage rispetto a quelli in hot wallet, l'eventuale esclusione dell'infedeltà dei dipendenti (che è uno degli scenari più probabili), e chi è l'assicurato: la polizza a beneficio del custode non è una polizza a vostro beneficio.
Attestazioni con uno scope leggibile — una certificazione ISO 27001 vale per quello che dice il suo campo di applicazione e il suo Statement of Applicability; un SOC 2 vale se è di tipo II, cioè con un periodo di osservazione, e va letto nelle eccezioni. Il logo sul sito non è un'attestazione.
Prova delle riserve e via d'uscita — attestazione indipendente e periodica dell'esistenza degli asset, e una procedura di uscita documentata: come si rientra in possesso dei fondi, in quanto tempo, e cosa accade se il custode cessa l'attività.

Il terzo modello è interessante, non risolutivo

Fra i due estremi esiste la ripartizione: schemi multifirma con dispositivi di produttori diversi, o custodia collaborativa in cui una delle chiavi sta presso un fornitore. È la stessa logica del dado — non fidarsi di una sorgente sola — e diversifica sia il rischio di difetto del fornitore sia quello di controparte. Ma non è la soluzione, e vale la pena dirlo chiaramente: aggiunge complessità, e la complessità è essa stessa un fattore di rischio.

Ogni controllo aggiunto introduce un modo nuovo di fallire. In uno schema a quorum i modi nuovi sono l'impossibilità di raggiungere il numero di firme richiesto: un firmatario irraggiungibile, in conflitto o deceduto, una chiave perduta oltre la soglia di tolleranza, un produttore uscito dal mercato, e il caso più sottovalutato — la perdita del descriptor del portafoglio, senza il quale le chiavi da sole non ricostruiscono nulla. A questo si aggiunge il fatto che la procedura di firma è più articolata, e le procedure articolate vengono eseguite male più spesso.

Nel vocabolario classico della sicurezza, il multifirma converte rischio di riservatezza in rischio di disponibilità: rende molto più difficile che qualcuno vi sottragga i fondi, e più facile che non riusciate ad accedervi voi. È una permuta, non una riduzione — e va scelta sapendo quale dei due rischi si è più attrezzati a gestire, e provando le procedure di recupero prima di averne bisogno.

Il rischio non si elimina

È la lezione che il caso Coldcard consegna a chi non possiede un bitcoin. Ogni opzione qui scambia un profilo di rischio con un altro: l'autocustodia elimina il rischio di controparte e vi consegna un rischio tecnico non trasferibile; il custode elimina il rischio tecnico e vi consegna un rischio di controparte parzialmente coperto; il multifirma riduce entrambi e vi consegna un rischio di disponibilità.

Non esiste la casella senza rischio, ed è per questo che la domanda "dove tengo i miei bitcoin" non ha una risposta universale. La domanda giusta è un'altra, e vale identica per un patrimonio personale e per il tesoro di un'azienda: quale rischio residuo sono disposto a tenermi, l'ho scelto consapevolmente, e l'ho scritto da qualche parte? Un rischio scelto e documentato è una decisione di governo. Lo stesso rischio non valutato è solo una speranza.