Il prelievo è durato 41 minuti
Il 30 luglio qualcuno ha attraversato 1.196 indirizzi bitcoin e li ha svuotati, portando via 1.082,65 bitcoin, per un valore di circa 70,2 milioni di dollari, in una finestra di 41 minuti. Nessuno ha forzato una serratura. Nessun dispositivo è stato toccato, nessun utente ingannato, nessun server violato. All'aggressore non serviva nulla di tutto ciò, perché le chiavi private che proteggevano quegli indirizzi potevano essere ricavate da zero. Le prime segnalazioni stimavano la perdita intorno ai 38 milioni di dollari; a conteggio ultimato la cifra sfiorava il doppio.
I dispositivi coinvolti erano portafogli hardware Coldcard prodotti da Coinkite, esattamente la categoria che si acquista per tenere le chiavi lontane dalle reti. È questo che rende l'episodio degno di un'ora di attenzione da parte di qualunque imprenditore, quale che sia la sua opinione sul bitcoin. Il cedimento non è avvenuto sul perimetro per cui tutti mettono a bilancio. È avvenuto nell'istante in cui il segreto è stato creato, anni prima che qualcuno provasse a rubarlo.
Una macro impostata a zero ha acceso il ripiego
Il resoconto tecnico della stessa Coinkite è insolitamente franco sul meccanismo. Nel marzo 2021, durante una migrazione a libsecp256k1 di Bitcoin Core, la generazione dei seed è stata dirottata dalla routine che invocava il generatore hardware di numeri casuali del dispositivo a una funzione di uso generale. Quel nuovo percorso si risolveva nel ripiego software di MicroPython anziché nell'implementazione hardware di Coldcard. Il codice di ripiego esisteva dal maggio 2018 e non aveva mai toccato la generazione dei seed fino a quella migrazione.
Il motivo per cui è finito compilato merita di entrare nella vostra lista di controllo. La guardia attorno al ripiego verificava se una macro di configurazione fosse definita, non se fosse impostata a uno. Gli sviluppatori l'avevano messa a zero, intendendo che lì il generatore hardware non serviva, e una macro impostata a zero resta una macro definita. La guardia ha letto la presenza del valore anziché il valore stesso, e ha acceso il ripiego. Nessuno ha scritto crittografia debole. Il generatore hardware esisteva e funzionava. Semplicemente ha smesso di essere ciò da cui il seed veniva estratto.
Sono passati cinque anni e ogni test restava verde
Sui dispositivi Mk2 e Mk3 con firmware dalla 4.0.1 alla 4.1.9, i seed ottenuti portavano circa 40 bit di entropia invece dei 128 che una frase di dodici parole dovrebbe avere. Su Mk4, Mk5 e Q il quadro era migliore ma non sicuro: gli ingegneri avevano mescolato valori provenienti dagli elementi sicuri nello stato del generatore come, per usare l'espressione di Coinkite, una riserva della riserva, il che portava quei seed a circa 72 bit. Entrambi i numeri sono catastrofici allo stesso modo. La casualità non si vede. Una chiave con 40 bit alle spalle firma transazioni, verifica indirizzi e si ripristina da copia esattamente come una da 128, perciò ogni test funzionale che l'azienda e i suoi clienti hanno eseguito per cinque anni è stato superato, giustamente, mentre il prodotto era guasto.
Coinkite offre inoltre un dettaglio che gran parte dei fornitori avrebbe sepolto. Qualche settimana fa, scrive, l'azienda ha usato uno dei migliori modelli di intelligenza artificiale disponibili per una revisione di sicurezza del proprio codice, e non ha trovato questo difetto. Vale la pena fermarsi lì prima che il prossimo fornitore vi dica che il suo codice è stato revisionato da un modello. Il difetto non era sottile col senno di poi né era nascosto, ma viveva nella giuntura tra una configurazione di compilazione e un'assunzione crittografica, cioè esattamente la cucitura che un revisore attento alla qualità del codice difficilmente tratterà come un confine di sicurezza.
La correzione protegge la prossima chiave, non quella passata
Coinkite ha rilasciato il 31 luglio firmware corretto per ogni modello e ramo interessato: 4.2.0 per Mk2 e Mk3, 5.6.0 per Mk4 e Mk5, 1.5.0Q per Q e le corrispondenti build edge. Poi ha pubblicato la frase che pesa più della correzione. Aggiornare il firmware non modifica né ripara un seed esistente. L'istruzione dell'azienda è installare il firmware corretto, generare un nuovo seed sul dispositivo aggiornato, annotare e verificare la copia di sicurezza prima di depositare qualsiasi cosa, confermare un nuovo indirizzo di ricezione sullo schermo del dispositivo, inviare una piccola transazione di prova e solo allora spostare i fondi rimanenti.
Questa è una migrazione, non un aggiornamento, e in tale distinzione sta l'intera lezione. Due cose potevano salvare un portafoglio creato nella finestra interessata: cinquanta lanci di dadi indipendenti e privati inseriti tramite la funzione dadi del dispositivo, poiché Coldcard li incorporava nel seed, oppure una passphrase forte e unica, che agisce da barriera separata davanti al seed debole. Coinkite invita comunque anche chi l'ha usata a migrare appena possibile. TAPSIGNER, OPENDIME e SATSCARD poggiano su basi di codice diverse e non sono interessati.
Inventariate ciò che avete generato, non solo ciò che eseguite
Quasi ogni processo di patch che un imprenditore abbia mai approvato tratta la versione del software come unità di rischio. Si scopre che una versione è vulnerabile, la si aggiorna, l'esposizione finisce. I difetti di entropia rompono del tutto questo modello, perché il danno non sta nel codice in esecuzione ma negli oggetti che il codice ha emesso e consegnato: chiavi, token, identificatori di sessione, codici di recupero, segreti di API, certificati. Quegli oggetti sopravvivono alla versione che li ha creati, migrano nei backup e nei sistemi di terzi e si portano dietro la debolezza in modo permanente. Aggiornare il generatore ferma la produzione di segreti difettosi. Non tocca l'inventario.
La domanda da porre a qualsiasi fornitore il cui prodotto crei segreti per vostro conto non è dunque soltanto quali versioni siano interessate. È quali segreti siano stati generati su una versione interessata, come si elencano e quale sia il percorso di rotazione. Ciò vale ben oltre i portafogli hardware: l'HSM nello stack dei pagamenti, l'autorità di certificazione, la linea di provisioning dei dispositivi, il fornitore di identità che emette token a lunga durata. Ovunque una macchina conii qualcosa su cui poi farete affidamento, la finestra difettosa è ciò che va inventariato, e quasi nessuno ne tiene registro.
Da leggere ora: Tre aziende decidono se il tuo telefono resta economico | Siemens e Schneider sono entrate il 22 luglio



