Dal traduttore e TL;DR
TL;DR:
Sembra che VoLTE sia protetto ancora peggio dei primi client Wi-Fi con WEP. Un errore architettonico che consente di fare un po’ di XOR sul traffico e ripristinare la chiave. L'attacco è possibile se ci si trova vicino a chi sta effettuando una chiamata e questa persona fa spesso chiamate.
Grazie per l'indicazione e TL;DR
I ricercatori hanno creato un'app per determinare se il tuo operatore è vulnerabile, maggiori dettagli . Condividi nei commenti i risultati, nella mia regione su MegaFon VoLTE è disattivato.
Informazioni sull'autore
Matthew Green.
Sono un crittografo e professore all'Università Johns Hopkins. Ho sviluppato e analizzato sistemi crittografici utilizzati in reti wireless, sistemi di pagamento e piattaforme di protezione dei contenuti digitali. Nella mia ricerca esploro vari modi di utilizzare la crittografia per aumentare la riservatezza degli utenti.
È passato del tempo da quando ho scritto un post del formato , e questo mi ha rattristato. Non perché non ci siano stati attacchi, ma principalmente perché non c'è stato un attacco su qualcosa di abbastanza ampiamente utilizzato da tirarmi fuori dalla mia crisi creativa.
Ma oggi mi sono imbattuto in chiamato ReVoLTE sui protocolli, la compromissione dei quali mi entusiasma particolarmente, ossia i protocolli delle reti cellulari (voice over) LTE. Sono entusiasta proprio di questi protocolli – e di questo nuovo attacco – perché è molto raro osservare la compromissione di protocolli reali e implementazioni delle reti cellulari. Principalmente perché questi standard sono stati sviluppati in stanze fumose e plasmati in documenti di 12000 pagine, che non ogni ricercatore riesce a superare. Inoltre, l'implementazione di questi attacchi costringe i ricercatori a utilizzare protocolli radio complessi.
Pertanto, gravi vulnerabilità crittografiche possono diffondersi in tutto il mondo e potrebbero essere utilizzate solo dai governi, prima che qualche ricercatore ci faccia attenzione. Ma di tanto in tanto ci sono eccezioni, e l'attacco di oggi è una di esse.
Autori : David Rupprecht, Katharina Kohls, Thorsten Holz e Christina Pöpper dell'Università della Ruhr a Bochum e della New York University di Abu Dhabi. Questa è una brillante critica alla reinstallazione della chiave nel protocollo vocale che probabilmente già utilizzate (se si assume che facciate parte di quella generazione che effettua ancora telefonate tramite cellulare).
Per cominciare – una breve panoramica storica.
Che cos'è LTE e VoLTE?
Le fondamenta dei nostri attuali standard di telecomunicazione mobile risalgono agli anni '80 in Europa con lo standard (Sistema globale per la comunicazione mobile). Il GSM è stato il primo standard fondamentale della telefonia mobile digitale a introdurre una serie di funzionalità rivoluzionarie, come l'uso del per proteggere le chiamate telefoniche. L'iniziale GSM è stato progettato principalmente per la comunicazione vocale, anche se era possibile .
Con l'aumentare dell'importanza della trasmissione dei dati nella telefonia mobile, sono stati sviluppati standard Long Term Evolution (LTE) per ottimizzare questo tipo di comunicazione. LTE si basa su un insieme di standard più vecchi, come il GSM, e ed è progettato per aumentare la velocità di trasmissione dei dati. In questo campo ci sono molte brandizzazioni e , ma TL;DR è che LTE è un sistema di trasmissione dati che funge da ponte tra i vecchi protocolli di trasmissione dei dati e le future tecnologie di telefonia cellulare. .
Naturalmente, la storia ci dice che una volta che ci sarà sufficiente larghezza di banda (IP), concetti come "voce" e "dati" inizieranno a sfumare. Lo stesso vale per i protocolli cellulari moderni. Per rendere questa transizione più fluida, gli standard LTE definiscono (VoLTE), che è uno standard IP per la trasmissione di chiamate vocali direttamente attraverso il piano di trasmissione dati del sistema LTE, evitando completamente la parte commutata della rete cellulare. Come nei tradizionali , le chiamate VoLTE possono essere terminate dall'operatore di telefonia mobile e collegate a una rete telefonica tradizionale. Oppure (cosa che sta diventando sempre più comune) possono direttamente da un cliente mobile all'altro, e persino tra fornitori diversi.
Come la VoIP standard, la VoLTE si basa su due protocolli popolari basati su IP: il protocollo di inizializzazione della sessione ( – SIP) per stabilire la chiamata, e il protocollo di trasporto in tempo reale (, che dovrebbe chiamarsi RTTP, ma in realtà si chiama RTP) per gestire i dati vocali. La VoLTE aggiunge anche alcune ottimizzazioni per la larghezza di banda, come la compressione dell'intestazione.
Bene, quale relazione ha questo con la crittografia?
LTE, proprio come , ha un set standard di protocolli crittografici per la crittografia dei pacchetti durante la loro trasmissione via aria. Sono principalmente destinati a proteggere i tuoi dati mentre si spostano tra il telefono (chiamato «attrezzatura dell'utente», o UE) e la torre cellulare (o ovunque il tuo fornitore decida di terminare la connessione). Questo accade perché i fornitori di servizi mobili considerano i dispositivi di intercettazione esterni come nemici. Beh, ovviamente.
(Tuttavia, il fatto che le connessioni VoLTE possano avvenire direttamente tra clienti in diverse reti dei fornitori significa che il protocollo VoLTE stesso ha alcuni protocolli di crittografia aggiuntivi e facoltativi che possono avvenire a livelli di rete più elevati. Questo non si applica al presente articolo, tranne per il fatto che possono tutto rovinare. Ne parleremo brevemente più avanti).
Storicamente, la crittografia in GSM ha avuto : scadenti , protocolli in cui solo il telefono si autenticava sulla torre (significa che un malintenzionato poteva fingersi una torre, generando ) e così via. LTE ha corretto molti degli errori evidenti, mantenendo però gran parte della struttura precedente.
Iniziamo con la crittografia. Se ipotizziamo che la creazione della chiave sia già avvenuta – di questo ne parleremo tra un minuto – ogni pacchetto di dati viene crittografato utilizzando una modalità di crittografia a flusso con un algoritmo chiamato «EEA» (che nella pratica può essere implementato con algoritmi come l'AES). Fondamentalmente, il meccanismo di crittografia qui è , come mostrato di seguito:
L'algoritmo principale di crittografia dei pacchetti VoLTE (fonte: ). L'EEA è il cifrario, «COUNT» è un contatore a 32 bit, «BEARER» è un identificatore unico di sessione che separa le connessioni VoLTE dal normale traffico internet. «DIRECTION» indica in quale direzione fluisce il traffico - dall'UE alla torre o viceversa.
Poiché l'algoritmo di crittografia stesso (EEA) può essere implementato utilizzando un cifrario forte come l'AES, è poco probabile che ci sia un attacco diretto al cifrario stesso, come è Tuttavia, è chiaro che anche con un cifrario potente, questo schema di crittografia rappresenta un'ottima opportunità per colpirsi da soli.
In particolare: nello standard LTE viene utilizzato un cifrario a flusso (non autenticato) in una modalità che risulterà estremamente vulnerabile se il contatore — e altri input, come «bearer» e «direction» — dovessero mai essere riutilizzati. Nella terminologia moderna, il termine per questo concetto è «attacco di riutilizzo del nonce», ma i rischi potenziali in questo caso non sono qualcosa di nuovo. Sono noti e antichi, risalenti ai tempi del glam metal e persino della disco.
Gli attacchi al riutilizzo del nonce in modalità CTR esistevano già quando i Poison divennero noti.
A sua discolpa, negli standard LTE si legge: «Non riutilizzare mai questi contatori, per favore». Tuttavia, gli standard LTE occupano circa 7000 pagine e, in ogni caso, è come implorare dei bambini di non giocare con una pistola. Inevitabilmente lo faranno, e accadranno cose terribili. In questo caso, la pistola scarica è rappresentata dall'attacco di riutilizzo del flusso di chiave, in cui due diversi messaggi riservati vengono XORati con gli stessi byte del flusso di chiave. È noto che ciò .
Cos'è ReVoLTE?
L'attacco ReVoLTE dimostra che, nella pratica, questa vulnerabilità del sistema di crittografia viene utilizzata in modo errato da attrezzature reali. In particolare, gli autori analizzano le chiamate VoLTE effettuate utilizzando dispositivi commerciali e mostrano che possono sfruttare qualcosa chiamato 'attacco di reinstallazione della chiave'. (Gran parte del merito per la scoperta di questo problema va a (Raza & Lu), che sono stati i primi a segnalare la potenziale vulnerabilità. Tuttavia, le ricerche su ReVoLTE la trasformano in un attacco pratico).
Lasciatemi mostrarvi brevemente il nocciolo dell'attacco, anche se dovreste dare un'occhiata anche al .
Si può supporre che, una volta che LTE stabilisce una connessione di trasmissione dati, il compito di trasmettere la voce tramite LTE diventa solo una questione di instradamento dei pacchetti vocali attraverso tale connessione insieme a tutto il resto del vostro traffico. In altre parole, VoLTE sarà un concetto che esiste solo sopra [modello OSI – es. cit.]. Non è esattamente così.
In effetti, il livello di canale LTE introduce il concetto di «bearer». Bearer è un identificatore di sessione separato che separa diversi tipi di traffico a pacchetto. Il traffico internet comune (il tuo Twitter e Snapchat) passa attraverso un bearer. La segnalazione SIP per VoIP utilizza un altro, mentre i pacchetti vocali vengono gestiti su un terzo. Non sono molto esperto nei meccanismi delle radiofrequenze e del routing di rete LTE, ma suppongo che sia fatto in questo modo perché le reti LTE vogliono garantire il funzionamento dei meccanismi QoS (Quality of Service), in modo che diversi flussi di pacchetti vengano trattati con livelli di priorità differenti: ovvero, i tuoi di seconda scelta le connessioni TCP con Facebook possono avere una priorità inferiore rispetto alle tue chiamate vocali in tempo reale.
In generale, questo non rappresenta un problema, ma le conseguenze sono le seguenti. Le chiavi per la crittografia LTE vengono generate separatamente ogni volta che viene installato un nuovo «bearer». In effetti, questo dovrebbe avvenire di nuovo ogni volta che effettui una nuova telefonata. Ciò comporterà che per ogni chiamata verrà utilizzata una chiave di crittografia diversa, escludendo la possibilità di riutilizzare la stessa chiave per crittografare due diversi gruppi di pacchetti delle chiamate vocali. Infatti, lo standard LTE afferma qualcosa come «devi utilizzare chiavi diverse ogni volta che imposti un nuovo bearer per gestire una nuova telefonata». Ma ciò non significa che questo avvenga realmente.
In realtà, nelle implementazioni reali, due chiamate diverse avvenenti in una stretta vicinanza temporale utilizzeranno la stessa chiave, nonostante vengano configurati nuovi bearer (con lo stesso nome) tra di esse. L'unica modifica pratica che si verifica tra queste chiamate è che il contatore di crittografia viene azzerato. In letteratura, a volte questo è chiamato . Si può affermare che, in sostanza, si tratta di un errore di implementazione, anche se in questo caso i rischi sembrano derivare in gran parte dallo standard stesso.
Nella pratica, questo attacco porta al riutilizzo del flusso di chiavi, dove un malintenzionato può ottenere pacchetti crittografati $inline$C_1 = M_1 oplus KS$inline$ e $inline$C_2 = M_2 oplus KS$inline$, che permette di calcolare $inline$C_1 oplus C_2 = M_1 oplus M_2$inline$. È ancora meglio se il malintenzionato conosce uno di $inline$M_1$inline$ o $inline$M_2$inline$, poiché può immediatamente recuperare l'altro. Questo gli fornisce una forte motivazione a scoprire uno dei due componenti non crittografati.
Questo ci porta a uno scenario di attacco completo e più efficace. Consideriamo un attaccante che può intercettare il traffico radio tra un telefono target e una torre cellulare, e che per qualche strano motivo ha ‘fortunatamente’ registrato due chiamate diverse, dove la seconda avviene subito dopo la prima. Ora immaginate che possa in qualche modo indovinare il contenuto non crittografato di una delle chiamate. In tale fortunata coincidenza il nostro aggressore può completamente decifrare la prima chiamata utilizzando un semplice XOR tra due set di pacchetti.
Certo, qui non c'entra nulla la fortuna. Poiché i telefoni sono progettati per ricevere chiamate, un aggressore che può intercettare la prima chiamata potrà avviare una seconda chiamata proprio nel momento in cui termina la prima. Questa seconda chiamata, nel caso in cui venga riutilizzata la stessa chiave di crittografia con il contatore resettato a zero, permetterà di recuperare i dati non crittografati. Inoltre, dato che il nostro aggressore controlla effettivamente i dati durante la seconda chiamata, può ripristinare il contenuto della prima chiamata, grazie a numerosi dettagli specificamente realizzati particolari, che giocano a suo favore.
Ecco un'immagine del piano generale di attacco, estratta da :
Panoramica dell'attacco da . Questo schema presuppone che ci siano due diverse chiamate utilizzando la stessa chiave. L'attaccante controlla un sniffatore passivo (in alto a sinistra), così come un secondo telefono con cui può effettuare una seconda chiamata al telefono della vittima.
Quindi l'attacco funziona davvero?
Da un lato, questa è davvero la domanda principale per un articolo su ReVoLTE. Teoricamente, tutte le idee sopra elencate sono ottime, ma sollevano molte domande. Ad esempio:
- È realmente possibile (per i ricercatori accademici) intercettare una connessione VoLTE?
- Le vere sistemi LTE riutilizzano realmente le chiavi?
- Puoi davvero avviare una seconda chiamata sufficientemente veloce e affidabile affinché il telefono e la torre riutilizzino la chiave?
- Anche se i sistemi riutilizzano le chiavi, puoi davvero scoprire il contenuto non cifrato della seconda chiamata, tenendo presente che cose come i codec e la ricodifica possono cambiare completamente il contenuto (bit per bit) di questa seconda chiamata, anche se hai accesso ai "bit" provenienti dal tuo telefono attaccante?
Alcune di queste domande trovano risposta affermativa nel lavoro di ReVoLTE. Gli autori utilizzano un sniffatore di flusso radio commerciale e riconfigurabile chiamato per intercettare le chiamate VoLTE da un numero in ingresso. (Penso che semplicemente padroneggiare il software e avere una comprensione approssimativa del suo funzionamento abbia richiesto mesi di vita ai poveri dottorandi – cosa tipica per questo genere di ricerche accademiche).
I ricercatori hanno scoperto che per attivare il riutilizzo della chiave, la seconda chiamata deve avvenire abbastanza rapidamente dopo la conclusione della prima, ma non troppo – circa dieci secondi per gli operatori su cui hanno condotto esperimenti. Fortunatamente, non importa se l'utente risponde alla chiamata in quel lasso di tempo – la "chiamata", cioè la stessa connessione SIP, costringe l'operatore a riutilizzare la stessa chiave.
Pertanto, molti dei problemi più gravi ruotano attorno al problema (4) – ottenere i bit di contenuto non crittografato di una chiamata avviata da un aggressore. Ciò accade poiché il tuo contenuto può subire molte modifiche mentre passa dal telefono dell'aggressore a quello della vittima attraverso la rete cellulare. Ad esempio, brutte sorprese come la ricodifica di un flusso audio codificato, che lascia il suono invariato ma altera completamente la sua rappresentazione binaria. Nelle reti LTE viene utilizzata anche la compressione dell'intestazione RTP, che può modificare in modo significativo gran parte del pacchetto RTP.
Infine, i pacchetti inviati dall'aggressore devono allinearsi approssimativamente con i pacchetti inviati durante la prima telefonata. Questo può essere problematico, poiché la modifica del silenzio durante una chiamata comporta messaggi più brevi (il cosiddetto rumore di comfort), che possono non allinearsi bene con la chiamata originale.
vale la pena leggerlo in tutti i dettagli. Esamina molte delle problematiche menzionate in precedenza: in particolare, gli autori hanno scoperto che alcuni codec non sono stati ricodificati e che circa l'89% della rappresentazione binaria della chiamata target può essere recuperato. Questo è pertinente almeno per due operatori europei che sono stati testati.
È un livello di successo incredibilmente alto e, francamente, molto superiore a quello che mi aspettavo quando ho iniziato a lavorare su questo documento.
Quindi, cosa possiamo fare per risolvere questo problema?
La risposta urgente a questa domanda è estremamente semplice: poiché l'essenza della vulnerabilità risiede nell'attacco al riutilizzo (reinstallazione) della chiave, correggi semplicemente questo problema. Assicurati che per ogni chiamata telefonica venga utilizzata una nuova chiave e non lasciare mai che il contatore dei pacchetti venga resettato a zero usando la stessa chiave. Problema risolto!
E forse no. Richiederà l'aggiornamento di un gran numero di attrezzature e, a essere sinceri, una soluzione del genere non è particolarmente affidabile di per sé. Sarebbe utile se gli standard potessero trovare un modo più sicuro di implementare i loro metodi di crittografia, che non siano intrinsecamente vulnerabili a problemi di riutilizzo delle chiavi.
Uno dei possibili approcci è utilizzare . Questo potrebbe essere troppo costoso per alcune attrezzature moderne, ma è certamente una direzione di cui i progettisti dovrebbero tenere conto in futuro, specialmente considerando che gli standard 5G stanno per conquistare il mondo.
Questa nuova ricerca solleva anche la questione generale del perché , molti dei quali utilizzano strutture e protocolli molto simili. Quando ti trovi di fronte al problema della reinstallazione dello stesso codice in diversi protocolli ampiamente utilizzati, come WPA2, non ti sembra che sia giunto il momento di rendere le tue specifiche e procedure di test più affidabili? È ora di smettere di considerare i realizzatori degli standard come partner riflessivi, attenti alle tue avvertenze. Trattali come (involontari) avversari, che inevitabilmente implementeranno tutto in modo errato.
Oppure, come opzione, possiamo fare ciò che sempre più aziende come Facebook e Apple stanno facendo: implementare la crittografia delle chiamate vocali a un livello superiore dello stack di rete OSI, senza fare affidamento sui produttori di hardware delle telecomunicazioni. Possiamo anche promuovere la crittografia end-to-end delle chiamate vocali, come fanno WhatsApp con Signal e FaceTime, supponendo che il governo degli Stati Uniti decida semplicemente di smettere di . Allora (eccetto alcune metadati), molti di questi problemi scomparirebbero semplicemente. Questa soluzione è particolarmente rilevante in un mondo in cui .
O possiamo semplicemente fare ciò che hanno già fatto i nostri figli: smettere di rispondere a queste fastidiose chiamate vocali.
Fonte: habr.com
