Per Haseeb Qureshi, managing partner di Dragonfly, l'aspetto più sorprendente dell'esperimento GLM 5.2 è stato il suo costo: "GLM 5.2 in esecuzione per 20 minuti costa circa 2 dollari. Cosa significa? Significa che siamo in un mondo nuovo."

Dragonfly è una società di venture capital focalizzata sulle criptovalute, e le osservazioni di Qureshi hanno un peso in un settore in cui le falle software hanno reso possibili alcuni dei più grandi furti mai registrati. Il modello ha presumibilmente riscoperto la vulnerabilità legata al recente furto ColdCard dopo che i ricercatori lo hanno indirizzato verso il software interessato. ColdCard, prodotta da Coinkite, è un portafoglio hardware molto diffuso tra gli utenti di Bitcoin che praticano l'autocustodia. Non ci sono prove che i ladri abbiano usato l'IA. Il test dimostra invece quanto economicamente sia diventato per attaccanti e sviluppatori esaminare il codice che protegge grandi quantità di criptovaluta.

Perché il costo di 2 dollari è importante

La ricerca seria sulle vulnerabilità ha tradizionalmente richiesto conoscenze specialistiche e molte ore di lavoro manuale. Anche un ricercatore esperto può ispezionare solo un numero limitato di versioni firmware, smart contract e librerie crittografiche.

L'IA permette a una quantità molto maggiore di codice di ricevere una prima revisione. I ricercatori possono assegnare diversi modelli allo stesso codebase, chiedere loro di indagare diversi percorsi di errore e ripetere il processo ogni volta che diventa disponibile un modello più potente.

Gran parte delle ricerche potrebbe non produrre nulla di utile. Questo diventa meno significativo quando un singolo tentativo costa solo pochi dollari. Chi cerca debolezze può esaminare molti obiettivi senza che ogni esecuzione debba avere successo. Una singola falla valida in un software che protegge milioni di dollari potrebbe giustificare il costo di migliaia di tentativi falliti.

L'IA non ha eliminato la necessità di competenze in materia di sicurezza. Ha abbassato il costo per generare piste, testare teorie e coprire più codice di quanto un ricercatore umano potesse ispezionare da solo.

Cosa dimostra effettivamente il test GLM 5.2

Qureshi ha detto che i ricercatori hanno chiesto a diversi modelli di esaminare il software dopo che l'incidente ColdCard aveva già attirato l'attenzione su di esso. Secondo lui, ai modelli non è stato detto dove si trovava la vulnerabilità, e GLM 5.2 l'ha trovata in circa 20 minuti.

Il contesto è importante. I ricercatori sapevano già che il software pertinente conteneva un problema grave. Il modello non stava cercando alla cieca in ogni portafoglio hardware e non stava scoprendo un attacco senza un punto di partenza.

Identificare un bug è anche diverso dal sfruttarlo su larga scala. Un attaccante potrebbe ancora dover:

• Determinare quali dispositivi o portafogli sono interessati.
• Ricostruire chiavi private utilizzabili.
• Identificare i portafogli contenenti saldi di valore.
• Spostare i fondi prima che utenti o produttori possano rispondere.

I commenti di Qureshi non dimostrano che GLM 5.2 abbia compiuto questi passaggi o che un sistema di IA abbia partecipato al furto originale. Ciò che l'esperimento stabilisce è più limitato ma comunque importante: un modello generalistico ha presumibilmente riscoperto la debolezza tecnica sottostante rapidamente e a costo quasi nullo.

L'IA è già qui, prima della minaccia quantistica

Gran parte del dibattito a lungo termine sulla sicurezza di Bitcoin si è concentrata sul calcolo quantistico. Una macchina quantistica sufficientemente potente potrebbe eventualmente minacciare gli schemi di firma che proteggono le monete, costringendo reti e utenti a migrare verso una nuova crittografia. Questo rischio richiede una preparazione preventiva.

L'analisi del codice assistita dall'IA presenta un problema diverso perché gli strumenti possono già essere usati contro il software in esecuzione oggi. L'IA non ha bisogno di sconfiggere la matematica alla base di Bitcoin. Può cercare errori nel codice circostante, come generazione debole di numeri casuali, segreti esposti, implementazioni crittografiche difettose e funzioni di recupero non sicure.

Una precedente analisi delle minacce legate a IA e calcolo quantistico per le criptovalute ha esaminato la stessa distinzione. Il calcolo quantistico potrebbe eventualmente creare un problema crittografico a livello di rete. L'IA può già essere indirizzata verso portafogli, bridge, librerie e applicazioni che attualmente proteggono i fondi degli utenti.

La preoccupazione immediata è quindi un errore umano nel software intorno a Bitcoin, piuttosto che un'IA che viola Bitcoin stesso.

Attaccanti e sviluppatori hanno accesso allo stesso strumento

L'IA non ha preferenze per una maggiore sicurezza o per un attacco di successo. Il suo effetto dipende dal compito che le persone le assegnano.

Un attaccante può usare un modello per scansionare vecchi firmware, automatizzare analisi ripetitive e testare possibili debolezze. Un produttore di portafogli può usare lo stesso modello prima del rilascio, indirizzandolo verso la generazione di chiavi, la firma delle transazioni e le procedure di recupero.

Gli sviluppatori possono anche rivedere prodotti rilasciati prima dell'esistenza degli agenti di codifica moderni. Il software auditato cinque anni fa può ora essere esaminato con strumenti che non erano disponibili quando ha raggiunto i clienti. Diverse società di sicurezza blockchain hanno già iniziato a incorporare l'analisi assistita dall'IA nei propri flussi di lavoro di audit, sebbene la tecnologia rimanga un complemento alla revisione umana piuttosto che una sua sostituzione.

Le due parti non operano però in condizioni di parità. Un attaccante può agire non appena una vulnerabilità utile viene confermata. Uno sviluppatore deve riprodurre il risultato, capire quali utenti sono interessati, preparare una correzione sicura e distribuirla senza rivelare informazioni sufficienti ad accelerarne lo sfruttamento.

I modelli possono anche fraintendere il codice, produrre falsi positivi o descrivere attacchi che falliscono nella pratica. I ricercatori umani rimangono responsabili della verifica del risultato e della decisione sull'urgenza della risposta del progetto.

L'IA amplia la quantità di codice che può essere esaminato. Non sostituisce l'esperienza o la risposta agli incidenti necessaria dopo che viene individuata una debolezza grave.

L'autocustodia dipende ancora dal portafoglio

Qureshi ha descritto gli utenti interessati come persone che avevano seguito i consueti consigli di sicurezza: "Persone che stanno facendo tutte le cose giuste."

Avevano spostato Bitcoin lontano dagli exchange e lo avevano conservato in portafogli hardware dedicati. Eppure l'autocustodia dipende ancora dalla corretta creazione e protezione delle chiavi da parte del dispositivo.

Qureshi ha detto che il firmware interessato utilizzava una fonte di casualità più debole del previsto. Se una chiave privata viene generata da input prevedibili, mantenere il dispositivo offline non può rendere la chiave più forte in seguito. Un air gap può ridurre l'esposizione agli attacchi remoti contro un segreto generato correttamente. Non può riparare un segreto debole fin dal momento della sua creazione.

Gli utenti di portafogli hardware dipendono quindi da qualcosa in più rispetto alla propria gestione della frase di recupero. Si fidano anche del firmware del produttore, del design hardware, delle librerie crittografiche e del generatore di numeri casuali. Anni senza un exploit noto possono dimostrare che il software è sopravvissuto all'uso ordinario. Non provano che ogni debolezza grave sia già stata identificata.

Il vecchio codice dei portafogli deve essere revisionato di nuovo

Un'analisi AI più economica rende più semplice rivedere il vecchio codice. Il software che in precedenza attirava poca attenzione può ora essere esaminato ripetutamente e su larga scala.

I produttori di portafogli e i protocolli crittografici dovrebbero ripetere la scansione delle versioni precedenti quando i modelli principali migliorano, in particolare quando il codice crea chiavi private, firma transazioni o controlla il recupero del portafoglio.

Un aggiornamento firmware non risolverà ogni problema. Quando una falla riguarda il modo in cui le chiavi esistenti sono state create, la correzione del software potrebbe proteggere i nuovi portafogli lasciando esposti quelli più vecchi. Gli utenti potrebbero aver bisogno di generare nuove chiavi nel sistema riparato e trasferire i propri fondi. I fornitori dovrebbero quindi essere in grado di identificare le versioni interessate, contattare rapidamente i clienti e spiegare come migrare in modo sicuro.

Questo processo crea anche opportunità per i truffatori. Gli incidenti di sicurezza spesso generano falsi account di supporto, siti web di migrazione dannosi e messaggi che chiedono agli utenti di verificare i propri portafogli. Gli utenti non dovrebbero mai fornire una frase seed o una chiave privata a un rappresentante dell'assistenza, a un sito web, a un account di social media o a un chatbot AI. Un processo di recupero legittimo non richiede che un'altra persona o servizio riceva tali segreti.

La revisione della sicurezza non può più essere un evento unico

L'analisi assistita dall'IA dovrebbe diventare parte dello sviluppo normale piuttosto che uno strumento utilizzato solo dopo che i fondi sono stati rubati. Le aziende crittovalutarie dovrebbero considerare:

• La scansione del nuovo codice prima del rilascio.
• La riesame del vecchio firmware e delle librerie man mano che i modelli migliorano.
• L'uso di diversi modelli per affrontare lo stesso codice da direzioni diverse.
• La riproduzione dei risultati gravi da parte di ricercatori esperti.
• La preparazione di procedure di comunicazione di emergenza e migrazione dei portafogli.
• Il mantenimento di programmi di divulgazione responsabile e bug bounty.

I modelli offrono una copertura più ampia e più rapida. I team di sicurezza devono ancora separare le vulnerabilità genuine dai rapporti errati, sviluppare una correzione e gestire le conseguenze per gli utenti.

La corsa alla sicurezza sta diventando più economica

L'esempio di Qureshi non dimostra che l'IA può violare Bitcoin. Dimostra che il software che protegge Bitcoin può ora essere testato per vulnerabilità a un costo che sta rapidamente diventando insignificante.

Questo sviluppo può produrre una maggiore sicurezza o attacchi più economici. Gli sviluppatori possono usare l'IA per sfidare i propri prodotti e individuare errori prima del rilascio. Gli attaccanti possono indirizzarla verso codice dimenticato, ripetere ricerche su molti obiettivi e agire sul primo risultato utile.

La tecnologia è disponibile per entrambi. Il risultato dipende da chi la utilizza, dalla precisione con cui i risultati vengono verificati e dalla rapidità con cui i difensori possono rispondere. I progetti che rivalutano continuamente il proprio software possono trarre vantaggio dagli stessi strumenti che rendono più facili gli attacchi. Chi si affida a vecchi audit o presume che un bug a lungo nascosto sarebbe già stato trovato lascia quell'opportunità a qualcun altro.

Disclaimer: questo articolo ha solo scopo informativo e non costituisce consulenza in materia di sicurezza, finanza o investimento. L'esperimento riportato non stabilisce che l'IA sia stata usata nel furto ColdCard o che GLM 5.2 possa identificare in modo affidabile ogni vulnerabilità del software.

Metodologia: questa analisi utilizza commenti pubblici di Haseeb Qureshi, managing partner di Dragonfly, riguardanti l'incidente ColdCard e il riportato test GLM 5.2. Il confronto tra rischio IA e rischio quantistico distingue gli strumenti di ricerca di vulnerabilità attualmente disponibili dalle minacce a lungo termine che richiedono hardware quantistico con capacità crittografiche.