Negli ultimi giorni, i detentori di Bitcoin che avevano seguito ogni pratica di sicurezza consigliata hanno comunque perso i propri fondi. Hanno acquistato un signer hardware rispettato, generato una seed phrase offline su quel dispositivo — il metodo BIP39 standard per creare chiavi Bitcoin, progettato per codificare da 128 a 256 bit di casualità — e si sono affidati a esso per svolgere la singola funzione più critica che un signer esiste per svolgere: produrre un numero che nessun altro possa indovinare.

Il signer hardware Coldcard non è riuscito a farlo. Un guard di preprocessor che verificava la condizione sbagliata ha silenziosamente deviato la generazione del seed verso un generatore di numeri pseudocasuali software debole — Yasmarang di MicroPython — invece che verso la sorgente di entropia hardware del dispositivo. Su alcuni modelli Coldcard, l'entropia effettiva è collassata a circa 40 bit — circa un bilione di seed possibili, uno spazio di ricerca abbastanza piccolo da poter essere enumerato con hardware consumer, e una riduzione di oltre 200 bit rispetto al livello di sicurezza previsto. Il difetto è stato introdotto nel marzo 2021 ed è rimasto presente nel firmware leggibile pubblicamente per oltre cinque anni.

Gli attaccanti hanno svuotato 500 indirizzi prima che la causa principale fosse compresa. Entro pochi giorni, il conteggio di Galaxy Research aveva raggiunto 4.585 indirizzi e quasi 90 milioni di dollari di perdite. L'attacco è ancora in corso alla data di questo articolo.

Coinkite, il produttore di Coldcard, opera sulla base dell'assunzione di lavoro — ampiamente condivisa su X — che l'attaccante abbia utilizzato l'IA per analizzare il firmware pubblicamente disponibile e scoprire il bug. Che l'IA sia stata usata o meno in questo caso specifico, il prossimo attaccante quasi certamente la impiegherà. In particolare, un audit assistito dall'IA condotto settimane prima del furto non ha rilevato nulla, potenzialmente a causa delle limitazioni del modello o della specifica costruzione della ricerca. Da quando l'attacco è iniziato, i ricercatori hanno dimostrato che diversi modelli di IA di frontiera possono individuare lo stesso difetto in pochi minuti a partire da un singolo prompt.

Il codice è rimasto aperto alla revisione umana per cinque anni, e nessun essere umano lo ha individuato.

Cambiamenti di licenza che non hanno cambiato nulla

Coinkite aveva precedentemente spostato il proprio firmware da una licenza di software libero a termini source-available — specificamente, MIT con una Commons Clause — dopo che Foundation Devices aveva incorporato il codice in un prodotto concorrente. Secondo i termini rivisti, gli utenti potevano leggere il codice sorgente ma non potevano costruire un business su di esso.

Questo cambiamento non ha avuto alcun effetto sulla sicurezza. Il bug risiedeva in codice che una macchina poteva leggere indipendentemente dalle restrizioni di licenza. In effetti, è entrato nel codebase nel preciso momento del rewrite che ha rimosso gli ultimi resti del codice con licenza GPL. La modifica della licenza non ha aumentato la protezione; ha soltanto alterato l'economia della scoperta della vulnerabilità.

L'illusione del codice chiuso

Nell'era dell'IA sempre più capace, tutto ciò che viene distribuito è leggibile — o lo sarà a breve. Rimuovere i simboli da un binario e passarlo attraverso un decompilatore produce l'output pseudo-C familiare a chiunque abbia aperto Ghidra, una suite di reverse engineering ampiamente utilizzata originariamente sviluppata dall'NSA: variabili senza nome, flusso di controllo appiattito, funzioni etichettate FUN_00401a20. Per la maggior parte delle persone, questo output è illeggibile. Quell'alta barriera alla comprensione umana era l'intero premio di sicurezza del "codice chiuso".

Un programma compilato, tuttavia, non ha altra scelta che dire la verità. Il codice che rimane crittografato non può essere eseguito. Nel momento dell'esecuzione, il processore deve ricevere le istruzioni effettive, quindi qualunque cosa faccia un programma, consegna alla macchina un resoconto completo ed esatto di come farlo. L'informazione è interamente presente nel codice macchina. L'offuscamento non può, e non può, rimuoverla.

Se leggere un binario sembra troppo difficile perché le macchine possano padroneggiarlo nel prossimo futuro, si consideri ciò che stanno già realizzando con problemi ben più difficili. Leggere un binario è un esercizio di analisi: ogni fatto necessario è presente, e il lavoro è l'estrazione. L'invenzione matematica rappresenta un altro ordine di difficoltà, perché richiede la creazione di un oggetto che nessuno ha mai visto.

Alle 02:19 UTC del 20 luglio, Levent Alpöge, un matematico che lavorava con Claude Fable 5 di Anthropic, ha pubblicato un controesempio alla congettura giacobiana di Keller — un problema rimasto aperto dal 1939 e abbastanza significativo da apparire nella lista di sfide di Stephen Smale per il ventunesimo secolo. Generazioni di matematici avevano tentato di risolverlo. La confutazione consiste in tre polinomi in tre variabili. Lean lo ha verificato entro poche ore, ed è abbastanza breve perché chiunque possa confermarlo in un sistema di algebra computazionale in circa un minuto.

La congettura giacobiana è caduta in un solo pomeriggio, mentre l'interrogatore apparentemente guardava la finale dei Mondiali di FIFA. A maggio, un modello OpenAI ha abbattuto la congettura delle distanze unitarie di Erdős, un quesito aperto dal 1946. A fine luglio, una congettura di teoria dei grafi trentennale è caduta con quattro prompt. Tra questi traguardi sono arrivate la confutazione della congettura giacobiana e una serie di altri risultati che resistevano da decenni.

Si posi quel ritmo di progresso accanto al compito comparativamente modesto di leggere codice macchina già pubblicato su Internet. I modelli di oggi gestiscono il codice sorgente e l'output del decompilatore in modo più efficace rispetto ai byte grezzi, quindi un binario completamente chiuso conserva solo un sottile margine di protezione. Quel margine funziona come un dosso di costo, e si sta erodendo allo stesso ritmo visibile in ogni altro ambito. Scommettere la sicurezza su quanto a lungo durerà significa scommettere contro un orologio che sta solo accelerando.

La vittima più silenziosa: i segreti commerciali

La stessa capacità di IA che individua un bug di entropia può leggere metodi proprietari. Questa è la vittima più silenziosa, e colpisce aziende che non si sono mai considerate esposte alle dinamiche dell'open source. Il segreto commerciale nel software distribuito è sempre stato semplicemente oscurità in abito formale.

La legge lo ha riconosciuto per tutto il tempo in cui è esistita la disciplina dei segreti commerciali. Il reverse engineering di un prodotto che si possiede legittimamente è lecito, e quindi un segreto sopravvive solo finché quel reverse engineering rimane costoso. Quando il costo di estrazione scende al prezzo di un abbonamento e di un prompt, il segreto incorporato nel codice distribuito ai clienti cessa di esserlo. Algoritmi proprietari, formati non documentati, vantaggi competitivi incorporati nei binari — tutto diventa leggibile per chiunque sia interessato a guardare, in una tempistica sempre più misurata in minuti.

L'open source non è una garanzia

Niente di tutto ciò rende necessariamente sicuro l'open source. Heartbleed si è nascosto nella libreria TLS più diffusa al mondo per due anni, perché la visibilità senza attenzione finanziata non trova nulla. Il backdoor xz ha dimostrato che il modello di contribuzione aperta è esso stesso una superficie di attacco — una che un avversario paziente può attraversare con una persona amichevole e due anni di commit apparentemente legittimi.

L'apertura un tempo serviva da scudo, ma non lo fa più. Ciò che offre sono revisori a cui è permesso esaminare il codice, build che possono essere riprodotte e verificate in modo indipendente, una via di uscita quando un fornitore muore o cambia direzione, e il riconoscimento che tutto ciò accadrà indipendentemente dalle preferenze.

Il vantaggio del difensore

Dobbiamo ora presumere che ogni riga di codice distribuito sarà letta da qualcuno con intenti malevoli, perché lo sarà. Il difensore detiene un vantaggio strutturale che l'attaccante non avrà mai: il tempo. Gli sviluppatori possono applicare gli stessi modelli di frontiera al proprio codice prima del rilascio, durante l'intervallo tra commit e spedizione, mentre l'attaccante attende un binario che non esiste ancora.

Le build dovrebbero essere rese riproducibili — nel senso che chiunque possa compilare lo stesso codice sorgente e verificare che il binario risultante corrisponda a quanto distribuito, byte per byte — in modo che ogni binario sia riconducibile a un codice sorgente che può essere controllato in modo indipendente. I sistemi dovrebbero essere progettati per fallire in modo sicuro, e il nucleo attendibile dovrebbe essere mantenuto abbastanza piccolo affinché un singolo bug non possa compromettere tutto.

Per chi detiene specificamente Bitcoin, la lezione che Coldcard sta insegnando in tempo reale è chiara: possedere l'entropia che non ci si può permettere venga indovinata, mantenere minimo l'elemento di sicurezza e dietro un'interfaccia pubblicata, e distribuire le chiavi tra implementazioni indipendenti — in modo che nessun singolo dispositivo e nessun errore di un singolo fornitore costituisca la totalità dell'esposizione.

Conseguenze permanenti

Per Bitcoin, le poste in gioco sono implacabili in un modo che non lo sono in altri ambiti, perché la semplice conoscenza delle chiavi private concede il pieno possesso dei fondi. Il bug di entropia ha lasciato cicatrici permanenti. Riparare il generatore non fa nulla per i seed che ha già prodotto; uno spazio di chiavi debole rimane svuotabile per sempre, e la divulgazione consegna all'attaccante la ricetta.

Questo schema è stato osservato in precedenza. La vulnerabilità Milk Sad nello strumento libbitcoin explorer, bx, generava chiavi private da un valore a 32 bit, e gli attaccanti stavano svuotando i wallet che produceva prima che il difetto fosse mai reso pubblico. Gli attaccanti seguono il proprio programma, invitati o meno. Per denaro che non può essere recuperato una volta speso, "trovabile prima o poi" è un sinonimo di "perso prima o poi".

Lo standard che Bitcoin ha già fissato

Bitcoin non si è mai affidato all'oscurità. Il protocollo è aperto, le sue regole verificabili da chiunque, e la sua sicurezza non si fonda su segreti ma su matematica e incentivi che reggono alla piena luce del sole. L'hardware e il software che costruiamo attorno a esso meritano lo stesso standard, perché l'alternativa non è più praticabile.

La scelta non è mai stata tra aperto e chiuso. Era tra disciplinato ed esposto.

La lezione più ampia della situazione Coldcard è che il software closed-source è come un seed generato da un Coldcard difettoso: può sembrare solido, ma è fondamentalmente costruito sulla sabbia. Tutti possono leggere il codice. L'unica domanda rimasta è se gli sviluppatori riconoscano volontariamente questo fatto — o se lo imparino insieme ai loro utenti come hanno fatto gli utenti di Coldcard, un indirizzo svuotato alla volta.

*Questo è un guest post di Colin Crossman, content producer presso Fedi. Le opinioni espresse sono interamente sue e non riflettono necessariamente quelle di BTC Inc o di Bitcoin Magazine. Questo post è apparso originariamente su Bitcoin Magazine.