Funzioni di Permutazione nell’IoT: Pilastri della Sicurezza o Tallone d’Achille? Vi Svelo il Caso ULBRAP!
Ciao a tutti, appassionati di tecnologia e sicurezza! Oggi voglio portarvi con me in un viaggio un po’ tecnico, ma spero affascinante, nel cuore pulsante dei sistemi IoT (Internet of Things) che gestiscono le nostre catene di approvvigionamento. Parleremo di come, a volte, le soluzioni pensate per essere “leggere” e a basso costo possano nascondere insidie non da poco. E lo faremo analizzando un caso studio specifico: un protocollo chiamato ULBRAP.
L’avvento dell’IoT ha rivoluzionato il modo in cui gli oggetti di uso quotidiano interagiscono, scambiando dati e informazioni. Pensate ai dispositivi che tracciano le merci nei magazzini, ai sensori che monitorano la temperatura dei container, fino ai veicoli connessi. Tutto questo fa parte di un ecosistema enorme. In particolare, nel mondo della logistica e della supply chain management (SCM), le tecnologie come l’RFID (Radio Frequency Identification) sono diventate protagoniste indiscusse. Ci permettono di tracciare, monitorare e garantire la rintracciabilità dei prodotti in tempo reale. Un vero toccasana per l’efficienza!
Ma, come spesso accade, tanta interconnessione porta con sé anche nuove sfide, soprattutto in termini di sicurezza. Se un sistema RFID viene compromesso, le conseguenze possono essere disastrose:
- Manipolazione dell’inventario: immaginate dati falsificati che portano a discrepanze di magazzino e perdite finanziarie.
- Contraffazione dei prodotti: malintenzionati potrebbero clonare i tag RFID per immettere merci false nella catena, danneggiando la reputazione dei marchi e la fiducia dei consumatori.
- Accesso non autorizzato ai dati: informazioni sensibili su prodotti e spedizioni potrebbero finire nelle mani sbagliate.
- Interruzioni operative: attacchi Denial-of-Service (DoS) potrebbero bloccare le operazioni logistiche, causando ritardi e caos.
Per far fronte a questi rischi, si cercano continuamente soluzioni che bilancino sicurezza ed efficienza, specialmente in contesti dove il costo dei dispositivi deve rimanere basso. Una delle strade esplorate è l’uso di funzioni di permutazione in protocolli di autenticazione ultra-leggeri, che si basano su operazioni semplici come XOR e Shift (rotazione di bit).
Il Protocollo ULBRAP Sotto la Lente
Recentemente, è stato proposto un protocollo chiamato ULBRAP (Ultra-Lightweight Blockchain-Enabled RFID Authentication Protocol), pensato proprio per la gestione della supply chain in ambienti 5G e mobile edge computing. Sulla carta, promettente. Ma, come dico sempre, il diavolo si nasconde nei dettagli, specialmente nella struttura interna delle funzioni crittografiche usate.
Nel nostro studio, abbiamo voluto mettere alla prova ULBRAP. E, ahimè, abbiamo scoperto delle falle di sicurezza piuttosto critiche. In particolare, siamo riusciti a dimostrare la possibilità di attacchi di divulgazione di segreti (secret disclosure) e di tracciabilità (traceability). Questo significa che, nonostante un protocollo possa sembrare ben progettato sulla carta, debolezze strutturali nelle sue componenti fondamentali possono renderlo vulnerabile.
Il problema principale che abbiamo identificato in ULBRAP risiede proprio nella sua funzione di permutazione, o meglio, nella sua implementazione. L’uso di semplici rotazioni di bit (indicate con `ROT`) e operazioni XOR, se non accompagnato da una robusta funzione non lineare (come una funzione hash applicata correttamente o un cifrario leggero), non garantisce quella che in gergo chiamiamo “confusione”. Secondo i principi di Shannon, un primitivo crittografico sicuro deve offrire sia confusione (rendere complessa la relazione tra il testo in chiaro e il testo cifrato) sia diffusione (spargere l’influenza di ogni bit del testo in chiaro su molti bit del testo cifrato). La funzione `Rot(·)` in ULBRAP offre diffusione, ma pecca terribilmente in confusione.
Abbiamo analizzato le discrepanze tra la descrizione testuale del protocollo e le figure schematiche presentate nel paper originale. Ad esempio, in alcuni punti si parla di una funzione hash `h(a ⊕ b ⊕ …)` mentre nelle figure questa funzione hash sembra mancare, lasciando solo `(a ⊕ b ⊕ …)`. Anche l’interpretazione dell’applicazione della funzione hash (XOR degli input vs. concatenazione degli input) non era chiarissima. Per la nostra analisi, abbiamo considerato lo scenario più robusto (con la funzione hash), ma abbiamo dimostrato che la vulnerabilità persiste.
L’Attacco Passo Dopo Passo (Semplificato)
Senza entrare nei dettagli matematici più complessi, vi spiego a grandi linee come siamo riusciti a “rompere” il protocollo. L’attacco per recuperare la chiave di sessione (`TK_ST`) si articola in alcuni passaggi chiave, sfruttando i messaggi scambiati tra Tag, Reader e Nodo della Supply Chain (MESG1, MESG2, MESG3, MESG4).
- Ascoltando il primo messaggio (MESG1), che contiene parametri come `P_R` e `CH_R`, e conoscendo il timestamp `TI_R`, siamo riusciti a ricavare un numero limitato di candidati (161, per la precisione) per il valore `R_O ⊕ IDN_T` (dove `R_O` è un numero casuale e `IDN_T` è l’identificativo del Tag).
- Similmente, analizzando il secondo messaggio (MESG2), abbiamo ottenuto 161 candidati per `R_O ⊕ IDN_S` (dove `IDN_S` è l’identificativo del nodo della Supply Chain).
- Combinando i risultati dei primi due passaggi, abbiamo potuto derivare 161 candidati per `IDN_S ⊕ IDN_T`.
- Analizzando il quarto messaggio (MESG4), in particolare il parametro `S_E`, e sfruttando la conoscenza del timestamp `TI_S`, siamo riusciti a generare circa 5313 candidati per un altro numero casuale, `S_O`.
- Infine, combinando i candidati per `IDN_S ⊕ IDN_T` e per `S_O`, e conoscendo il parametro `Bal_N` (il bilancio nel Blockchain, che abbiamo assunto essere noto alla rete per evitare attacchi di desincronizzazione), siamo arrivati a un numero gestibile di candidati per la chiave di sessione `TK_ST`. Verificando quale di questi soddisfacesse un’ulteriore equazione del protocollo, abbiamo isolato la chiave corretta.
Il bello (o il brutto, a seconda dei punti di vista!) è che tutto questo processo ha richiesto circa 1.710.947 calcoli di hash. Potrebbe sembrare un numero enorme, ma con la potenza di calcolo odierna, nei nostri esperimenti su un laptop comune, l’attacco è stato completato in circa 5 minuti! Per l’attacco di tracciabilità, è bastato intercettare i messaggi di due sessioni differenti e trovare l’intersezione dei candidati `IDN_T ⊕ IDN_S`.
Dimostrazione Pratica: Non Solo Teoria!
Per non lasciare nulla al caso, abbiamo implementato l’attacco praticamente. Abbiamo usato tre dispositivi Raspberry Pi (uno per il Tag, uno per il Reader e uno per il nodo della Supply Chain) e scritto il codice dell’attacco in Python. Abbiamo persino pubblicato i dettagli su GitHub e registrato un video che mostra l’attacco in azione. Questo dimostra che non si tratta di vulnerabilità puramente teoriche, ma di minacce concrete.
Abbiamo anche esteso i nostri scenari di attacco, simulando attacchi multi-sessione (con più Tag, inclusi ESP8266 e Raspberry Pi) e scenari multi-attaccante, dove un attaccante attivo impersonava un Tag legittimo per disturbare il protocollo e sabotare il recupero della chiave da parte di altri attaccanti passivi. Anche questi esperimenti hanno confermato la fragilità di ULBRAP in condizioni realistiche.
Cosa Imparare e Come Migliorare
La lezione fondamentale che emerge da questa analisi è l’importanza critica della struttura interna delle funzioni di permutazione (e, più in generale, dei primitivi crittografici) per garantire la sicurezza di un sistema. Anche un protocollo apparentemente ben congegnato può crollare se le sue fondamenta non sono solide.
Come si potrebbe migliorare un protocollo come ULBRAP? La nostra raccomandazione è di integrare funzioni che offrano una robusta confusione, oltre alla diffusione. Ad esempio, si potrebbero utilizzare cifrari leggeri, progettati specificamente per ambienti con risorse limitate, come `χper^z(·)`. Questo tipo di cifrario, implementabile con operazioni bit-wise e ampiamente analizzato per la sua sicurezza, potrebbe fornire quel livello di complessità necessario a rendere vani gli attacchi che abbiamo descritto.
In conclusione, la corsa verso sistemi IoT sempre più economici e interconnessi non deve farci abbassare la guardia sulla sicurezza. Ogni componente, anche il più “leggero”, deve essere scrutato attentamente. Il caso ULBRAP ci ricorda che, nel mondo della cybersecurity, non ci si può permettere scorciatoie, soprattutto quando sono in gioco dati sensibili e l’integrità di intere catene di approvvigionamento.
Spero che questa “discesa nelle trincee” della sicurezza IoT vi sia piaciuta e vi abbia dato qualche spunto di riflessione. Alla prossima!
Fonte: Springer
