Comparative Timing Characterization of Early-Exit and Fixed-Work Secret Comparisons on ESP32 and ESP8266

Nel mondo nascosto della sicurezza informatica, esiste un pericolo silenzioso che nulla ha a che fare con serrature rotte o chiavi rubate. Si tratta del tempo. Quando un computer controlla se un codice segreto corrisponde a una password, di solito lo fa confrontando le due stringhe di caratteri una alla volta. Se la prima lettera è errata, un programma standard si interrompe immediatamente e dice "no". Se le prime dieci lettere sono corrette e l'undicesima è sbagliata, il programma continua a lavorare finché non trova quell'errore. Questa differenza nel tempo impiegato dal computer per pensare può essere una fuga di informazioni. Un osservatore esperto, monitorando quanto tempo richiede una risposta, potrebbe teoricamente contare i secondi per capire quanti caratteri erano corretti prima che avvenisse l'errore. Questo è noto come canale laterale temporale (timing side channel), un modo per rubare informazioni non rompendo il codice, ma ascoltando l'orologio. Per decenni, gli esperti di sicurezza hanno avvertito che il software deve essere scritto in modo da impiegare esattamente lo stesso tempo indipendentemente da dove si verifichi l'errore, una pratica chiamata programmazione a tempo costante. Ma sui chip minuscoli ed economici che alimentano tutto, dai dispositivi per la smart home ai semplici sensori, non è sempre chiaro se queste regole valgano nel mondo reale, o se l'hardware stesso introduca nuove sorprese.

Uno studio recente si è proposto di testare questa realtà su due dei microchip più comuni al mondo: l'ESP32 e l'ESP8266. Questi chip sono i cervelli dietro innumerevoli dispositivi economici connessi a Internet. Il ricercatore, lavorando da solo, ha costruito due modi diversi affinché questi chip confrontino codici segreti di 16 byte. Il primo metodo era l'approccio standard, vulnerabile: si sarebbe interrotto non appena trovato un disallineamento. Il secondo metodo era l'approccio a "lavoro fisso", progettato per essere sicuro: avrebbe costretto il chip a controllare ogni singolo byte dell'input, indipendentemente da quanto presto apparisse un errore, garantendo che il tempo totale rimanesse lo stesso. Per vedere come si comportavano questi metodi, il ricercatore ha inviato migliaia di codici di test ai chip. Ogni codice di test era stato creato per corrispondere alla password segreta per un numero specifico di lettere all'inizio — a volte nessuna, a volte tutte le sedici — prima di deviare. I chip misuravano i propri cicli di clock interni per registrare esattamente quanto tempo impiegasse ogni confronto, ripetendo il processo centinaia di volte per ogni possibile lunghezza iniziale.

I risultati hanno dipinto un quadro chiaro della vulnerabilità del metodo standard. Sul chip ESP32, più veloce, ogni volta che il codice di test corrispondeva a una lettera in più del segreto prima di fallire, il chip impiegava esattamente quaranta cicli di clock in più per finire il lavoro. Sull'ESP8266, più lento, il ritardo era di venticinque cicli per ogni lettera aggiuntiva corrispondente. Ciò ha creato una scala temporale perfetta e prevedibile. Se il codice corrispondeva a zero lettere, il chip terminava rapidamente; se corrispondeva a quindici, impiegava significativamente più tempo. In effetti, la tempistica era così costante che, in molti dei gruppi di test, ognuna delle trecento prove produceva esattamente lo stesso conteggio di cicli di clock. Per l'ESP32, una singola misurazione del tempo impiegato era sufficiente per dire al ricercatore esattamente quante lettere corrispondevano al segreto in quella specifica sessione. Ciò ha confermato che il metodo standard "stop precoce" perde informazioni direttamente attraverso il tempo impiegato per l'esecuzione.

Al contrario, il metodo a lavoro fisso si è comportato esattamente come sperano gli esperti di sicurezza. Quando il ricercatore ha utilizzato la versione che costringeva il chip a controllare tutti i sedici byte, il tempo impiegato non cambiava in base a quante lettere corrispondevano. Che il codice di test fallisse sulla prima lettera o sull'ultima, il chip impiegava lo stesso tempo per elaborare i dati. Il tempo mediano è rimasto piatto in tutti gli scenari. Tuttavia, lo studio ha anche rivelato un costo per questa sicurezza. Il metodo a lavoro fisso impiegava sempre più tempo rispetto al metodo vulnerabile, specialmente quando il codice di test falliva immediatamente. Sull'ESP32, il metodo sicuro impiegava quasi ottocento cicli anche quando la prima lettera era errata, mentre il metodo vulnerabile terminava in meno di settanta cicli. Il metodo sicuro sprecava essenzialmente tempo controllando il resto delle lettere per garantire che la durata totale rimanesse costante. Questo compromesso tra velocità e sicurezza è una realtà fondamentale nei sistemi embedded, dove ogni ciclo extra di elaborazione consuma una batteria o rallenta un dispositivo.

Lo studio ha anche scoperto alcune stranezze inaspettate nel modo in cui questi chip si comportano sotto pressione. Sebbene i tempi medi fossero stabili, un piccolo numero di misurazioni individuali era molto più alto delle altre, raddoppiando o triplicando quasi il tempo previsto. Questi picchi accadevano soprattutto quando i chip erano lasciati gestire normali interruzioni di background, piuttosto che quando erano isolati in uno stato di quiete. Ciò suggerisce che, sebbene la logica centrale del codice sicuro funzioni, l'ambiente circostante del chip può comunque causare ritardi occasionali e imprevedibili. Il ricercatore ha notato che queste misurazioni sono state effettuate direttamente all'interno della memoria del chip, non su una rete, il che significa che, sebbene la fuga temporale sia reale e misurabile sul dispositivo, ciò non prova automaticamente che un hacker possa rubare una password attraverso Internet. Il rumore di una connessione del mondo reale probabilmente nasconderebbe queste sottili differenze.

In definitiva, questa ricerca fornisce una mappa concreta di come le perdite temporali appaiano su hardware specifici e ampiamente utilizzati. Dimostra che il semplice atto di interrompere un confronto precocemente crea un segnale preciso e misurabile che rivela il segreto. Dimostra anche che un semplice cambiamento nel codice — forzare il computer a finire il lavoro indipendentemente dal risultato — può eliminare quel segnale, sebbene comporti una penalità di prestazioni. I risultati sono un promemoria del fatto che, nel mondo della sicurezza embedded, il modo in cui un programma viene scritto conta tanto quanto la matematica che utilizza. I chip hanno fatto esattamente ciò che era stato loro ordinato di fare e, così facendo, hanno rivelato che senza una progettazione attenta, anche le operazioni più basilari possono sussurrare segreti a chiunque stia ascoltando l'orologio.