Do tradutor e TL;DR
-
TL; DR:
Parece que VoLTE resultou estar aínda peor protexido que os primeiros clientes Wi-Fi con WEP. Un erro de cálculo exclusivamente arquitectónico que permite XOR un pouco o tráfico e restaurar a chave. É posible un ataque se estás preto da persoa que chama e este fai chamadas con frecuencia.
-
Grazas polo consello e TL;DR
-
Os investigadores crearon unha aplicación para determinar se o teu operador é vulnerable. Lea máis . Comparte os resultados nos comentarios, VoLTE está desactivado na miña rexión en Megafon.
Sobre o autor
Matthew Green.
Son criptógrafo e profesor na Universidade Johns Hopkins. Deseñei e analizei sistemas criptográficos utilizados en redes sen fíos, sistemas de pago e plataformas de seguridade de contido dixital. Na miña investigación, vexo diferentes formas de usar a criptografía para mellorar a privacidade dos usuarios.
Hai tempo que non escribín un formato de publicación , e molestoume. Non porque non houbese ataques, senón sobre todo porque non houbo un ataque a algo moi utilizado o suficiente para sacarme do bloqueo do escritor.
Pero hoxe atopeime chamado ReVoLTE para protocolos que estou particularmente entusiasmado co pirateo, é dicir, protocolos LTE de rede móbil (voz en off). Estou entusiasmado con estes protocolos particulares, e este novo ataque, porque é moi raro ver que se piratean protocolos e implementacións de redes móbiles reais. Principalmente porque estes estándares foron desenvolvidos en salas cheas de fume e documentados en documentos de 12000 páxinas que non todos os investigadores poden manexar. Ademais, a implementación destes ataques obriga aos investigadores a utilizar complexos protocolos de radio.
Así, serias vulnerabilidades criptográficas poderían estenderse por todo o mundo, quizais só para ser explotadas polos gobernos, antes de que ningún investigador se dea conta. Pero de cando en vez hai excepcións, e o ataque de hoxe é unha delas.
Autores Colaboradores: David Rupprecht, Katharina Kohls, Thorsten Holz e Christina Pöpper da Ruhr-University Bochum e da New York University Abu Dhabi. Este é un gran ataque para reinstalar a chave no protocolo de voz que probablemente xa esteas usando (supoñendo que sexas dunha xeración máis antiga que aínda fai chamadas telefónicas usando un teléfono móbil).
Para comezar, unha breve excursión histórica.
Que son LTE e VoLTE?
A base dos nosos estándares modernos de telefonía móbil estableceuse en Europa nos anos 80 polo estándar (Sistema global de comunicacións móbiles). GSM foi o primeiro gran estándar de telefonía móbil dixital, que introduciu unha serie de características revolucionarias, como o uso para protexer as chamadas telefónicas. O primeiro GSM foi deseñado principalmente para comunicacións de voz, aínda que o diñeiro podería ser .
A medida que a transmisión de datos se fixo máis importante nas comunicacións móbiles, os estándares Long Term Evolution (LTE) foron desenvolvidos para axilizar este tipo de comunicación. LTE baséase nun grupo de estándares máis antigos como GSM, и e está deseñado para aumentar a velocidade de intercambio de datos. Hai moita marca e pero o TL;DR é que LTE é un sistema de transmisión de datos que serve de ponte entre os protocolos de paquetes de datos máis antigos e as futuras tecnoloxías de datos móbiles. .
Por suposto, a historia dinos que unha vez que haxa suficiente ancho de banda (IP) dispoñible, conceptos como "voz" e "datos" comezarán a difuminarse. O mesmo aplícase aos protocolos móbiles modernos. Para facer esta transición máis suave, os estándares LTE definen (VoLTE), que é un estándar IP para realizar chamadas de voz directamente sobre o plano de datos dun sistema LTE, evitando por completo a parte de acceso telefónico da rede móbil. Como co estándar ,O operador de telefonía móbil pode finalizar as chamadas VoLTE e conectarse á rede telefónica normal. Ou (como é cada vez máis común) eles directamente dun cliente móbil a outro, e mesmo entre diferentes provedores.
Como VoIP estándar, VoLTE baséase en dous protocolos populares baseados en IP: Protocolo de inicio de sesión (Session Initiation Protocol) - SIP) para a configuración de chamadas e protocolo de transporte en tempo real (, que debería chamarse RTTP pero en realidade chámase RTP) para procesar datos de voz. VoLTE tamén engade algunhas optimizacións de ancho de banda adicionais, como a compresión de cabeceira.
Vale, que ten que ver isto co cifrado?
LTE, como , ten un conxunto estándar de protocolos criptográficos para cifrar os paquetes a medida que se transmiten polo aire. Están deseñados principalmente para protexer os teus datos mentres viaxan entre o teléfono (chamado equipo de usuario ou UE) e a torre de telefonía móbil (ou onde o teu provedor decida finalizar a conexión). Isto débese a que os provedores de telefonía móbil ven os dispositivos externos de escoita como inimigos. Ben, claro.
(Non obstante, o feito de que as conexións VoLTE poidan producirse directamente entre clientes en redes de provedores diferentes significa que o propio protocolo VoLTE ten algúns protocolos de cifrado adicionais e opcionais que poden ocorrer en capas de rede máis altas. Isto non é relevante para o artigo actual, excepto o feito de que poden estragar todo (deles falaremos brevemente a continuación).
Historicamente, o cifrado en GSM foi : malo , protocolos nos que só o teléfono estaba autenticado na torre (o que significa que un atacante podería suplantar a torre, xerando ) etcétera. LTE corrixiu moitos dos erros obvios mantendo gran parte da mesma estrutura.
Comecemos co propio cifrado. Asumindo que a creación de chaves xa se produciu -e falaremos diso nun minuto-, entón cada paquete de datos cífrase mediante o cifrado de fluxo usando algo chamado "EEA" (que na práctica pódese implementar usando cousas como AES ). Esencialmente, aquí está o mecanismo de cifrado como a continuación:
O principal algoritmo de cifrado para paquetes VoLTE (fonte: ). EEA é un cifrado, "COUNT" é un contador de 32 bits, "BEARER" é un identificador de sesión único que separa as conexións VoLTE do tráfico normal de Internet. "DIRECCIÓN" indica en que dirección circula o tráfico: desde a UE ata a torre ou viceversa.
Dado que o propio algoritmo de cifrado (EEA) pode implementarse usando un cifrado forte como AES, é improbable que haxa algún ataque directo ao propio cifrado como este. . Non obstante, está claro que mesmo cun cifrado forte, este esquema de cifrado é unha boa forma de dispararse no pé.
En particular: o estándar LTE usa un cifrado de fluxo (non autenticado) cun modo que será extremadamente vulnerable se algunha vez se reutilizan o contador e outras entradas como "portador" e "dirección". Na linguaxe moderna, o termo para este concepto é "ataque nonce reuse", pero os posibles riscos aquí non son algo moderno. Son famosos e antigos, remóntanse aos tempos do glam metal e mesmo do disco.
Os ataques á reutilización nonce no modo CTR existían mesmo cando Poison se coñeceu
Para ser xustos, os estándares LTE din: "Por favor, non reutilices estes medidores". Pero os estándares LTE teñen unhas 7000 páxinas e, en calquera caso, é como pedirlles aos nenos que non xoguen cunha arma. Inevitablemente o farán, e sucederán cousas terribles. O arma de disparo neste caso é un ataque de reutilización de keystream, no que dúas mensaxes confidenciais diferentes XOR os mesmos bytes de keystream. Sábese que isto .
Que é ReVoLTE?
O ataque ReVoLTE demostra que, na práctica, este deseño de cifrado moi vulnerable é mal utilizado polo hardware do mundo real. En concreto, os autores analizan as chamadas VoLTE reais realizadas mediante equipos comerciais e demostran que poden usar algo chamado "ataque de reinstalación de claves". (Moito crédito por atopar este problema vai a (Raza & Lu), que foron os primeiros en sinalar a potencial vulnerabilidade. Pero a investigación de ReVoLTE convérteo nun ataque práctico).
Déixame mostrarche brevemente a esencia do ataque, aínda que deberías mirar e .
Pódese supoñer que unha vez que LTE establece unha conexión de paquetes de datos, a tarefa de voz sobre LTE pasa a ser só unha cuestión de enrutar os paquetes de voz a través desa conexión xunto con todo o resto do seu tráfico. Noutras palabras, VoLTE será un concepto que só existe [Modelos OSI - aprox.]. Isto non é totalmente certo.
De feito, a capa de enlace LTE introduce o concepto de "portador". Os portadores son identificadores de sesión separados que separan diferentes tipos de tráfico de paquetes. O tráfico regular de internet (o teu Twitter e Snapchat) pasa por un só portador. A sinalización SIP para VoIP pasa por outro, e os paquetes de tráfico de voz son procesados a través dun terceiro. Non coñezo moito os mecanismos de enrutamento de redes e radio LTE, pero creo que se fai deste xeito porque as redes LTE queren facer cumprir os mecanismos de QoS (calidade de servizo) para que os diferentes fluxos de paquetes sexan procesados en diferentes niveis de prioridade: é dicir. teu de segunda categoría As conexións TCP a Facebook poden ter unha prioridade máis baixa que as túas chamadas de voz en tempo real.
Isto xeralmente non é un problema, pero as consecuencias son as seguintes. As claves para o cifrado LTE créanse por separado cada vez que se instala un novo "portador". Basicamente, isto debería ocorrer de novo cada vez que faga unha nova chamada. Isto fará que se use unha clave de cifrado diferente para cada chamada, eliminando a posibilidade de reutilizar a mesma clave para cifrar dous conxuntos diferentes de paquetes de chamadas de voz. De feito, o estándar LTE di algo así como "debería usar unha clave diferente cada vez que instale un novo soporte para xestionar unha nova chamada telefónica". Pero isto non significa que isto suceda realmente.
De feito, nas implementacións da vida real, dúas chamadas diferentes que se producen en estreita proximidade temporal utilizarán a mesma clave, a pesar de que se configuran novos portadores do mesmo nome entre eles. O único cambio práctico que se produce entre estas chamadas é que o contador de cifrado se restablece a cero. Na literatura chámase así ás veces . Pódese argumentar que este é esencialmente un erro de implementación, aínda que neste caso os riscos parecen derivar en gran parte do propio estándar.
Na práctica, este ataque resulta na reutilización do fluxo de claves, onde o atacante pode obter os paquetes cifrados $inline$C_1 = M_1 oplus KS$inline$ e $inline$C_2 = M_2 oplus KS$inline$, permitindo o cálculo de $inline$ C_1 oplus C_2 = M_1 oplus M_2$en liña$. Aínda mellor, se o atacante coñece un de $inline$M_1$inline$ ou $inline$M_2$inline$, entón pode recuperar inmediatamente o outro. Isto dálle un forte incentivo descubrir un dos dous compoñentes sen cifrar.
Isto lévanos ao escenario de ataque completo e máis eficaz. Considere un atacante que pode interceptar o tráfico de radio entre un teléfono de destino e unha torre de telefonía móbil e que, dalgún xeito, ten a sorte de gravar dúas chamadas diferentes, e a segunda ocorre inmediatamente despois da primeira. Agora imaxina que podería adiviñar dalgún xeito o contido sen cifrar dunha das chamadas. Con tal serendipia o noso atacante pode descifrar completamente a primeira chamada usando un simple XOR entre os dous conxuntos de paquetes.
Por suposto, a sorte non ten nada que ver. Dado que os teléfonos están deseñados para recibir chamadas, un atacante que poida escoitar a primeira chamada poderá iniciar unha segunda chamada no momento exacto en que remate a primeira. Esta segunda chamada, se se usa de novo a mesma clave de cifrado co contador restablecido a cero, permitirá recuperar os datos sen cifrar. Ademais, dado que o noso atacante realmente controla os datos durante a segunda chamada, pode recuperar o contido da primeira chamada, grazas a moitos implementados especificamente. pequenas cousas, xogando ao seu lado.
Aquí tes unha imaxe do plan xeral de ataque tomada :
Vista xeral do ataque desde . Este esquema supón que se fan dúas chamadas diferentes usando a mesma tecla. O atacante controla o sniffer pasivo (arriba á esquerda), así como un segundo teléfono, co que pode facer unha segunda chamada ao teléfono da vítima.
Entón, o ataque realmente funciona?
Por unha banda, esta é realmente a pregunta principal para o artigo sobre ReVoLTE. Todas as ideas anteriores son xeniais en teoría, pero deixan moitas preguntas. Tales como:
- É posible (para investigadores académicos) interceptar realmente unha conexión VoLTE?
- Os sistemas LTE reais cambian de clave?
- Podes realmente iniciar unha segunda chamada de forma rápida e fiable para que o teléfono e a torre reutilicen a chave?
- Aínda que os sistemas cambien de clave, podes coñecer o contido sen cifrar da segunda chamada, dado que cousas como os códecs e a transcodificación poden cambiar completamente o contido (bit a bit) desa segunda chamada, aínda que teñas acceso aos "bits". " ven do teu teléfono de ataque?
O traballo de ReVoLTE responde afirmativamente a algunhas destas preguntas. Os autores usan un rastreador de fluxo de radio reconfigurable por software comercial chamado para interceptar unha chamada VoLTE desde o lado da ligazón descendente. (Creo que só familiarizarse co software e facerse unha idea aproximada de como funciona levoulle meses á vida dos pobres estudantes de posgrao, o que é típico para este tipo de investigación académica).
Os investigadores descubriron que para que a reutilización das chaves funcionase, a segunda chamada tiña que suceder o suficientemente rápido despois de que rematase a primeira, pero non demasiado rápido: uns dez segundos para os operadores cos que experimentaron. Afortunadamente, non importa se o usuario responde á chamada dentro deste tempo - o "ring" é dicir. A propia conexión SIP obriga ao operador a reutilizar a mesma clave.
Así, moitos dos problemas máis pésimos xiran en torno ao problema (4) - recibir anacos do contido sen cifrar dunha chamada iniciada por un atacante. Isto débese a que poden pasar moitas cousas ao teu contido mentres viaxa desde o teléfono do atacante ao teléfono da vítima a través da rede móbil. Por exemplo, trucos tan sucios como volver a codificar un fluxo de audio codificado, que deixa o son igual, pero cambia completamente a súa representación binaria. As redes LTE tamén usan a compresión de cabeceira RTP, que pode cambiar significativamente gran parte do paquete RTP.
Finalmente, os paquetes enviados polo atacante deberían estar máis ou menos acordes cos paquetes enviados durante a primeira chamada telefónica. Isto pode ser problemático porque modificar o silencio durante unha chamada telefónica provoca mensaxes máis curtas (tamén coñecido como ruído de confort) que poden non encaixar ben coa chamada orixinal.
Paga a pena ler en detalle. Aborda moitos dos problemas anteriores; en particular, os autores descubriron que algúns códecs non se codifican de novo e que aproximadamente o 89% da representación binaria da chamada de destino pódese recuperar. Isto é certo para polo menos dous operadores europeos que foron probados.
Esta é unha taxa de éxito sorprendentemente alta e, francamente, moito máis alta do que esperaba cando comecei a traballar neste documento.
Entón, que podemos facer para solucionalo?
A resposta inmediata a esta pregunta é moi sinxela: xa que a esencia da vulnerabilidade é un ataque de reutilización (reinstalación) clave, simplemente solucione o problema. Asegúrese de que se obtén unha nova clave para cada chamada telefónica e nunca permita que o contador de paquetes reinicie o contador a cero usando a mesma tecla. Problema resolto!
Ou quizais non. Isto requirirá actualizar moitos equipos e, francamente, tal corrección en si non é moi fiable. Sería bo que os estándares puidesen atopar un xeito máis seguro de implementar os seus modos de cifrado que non sexa por defecto catastróficamente vulnerable a tales problemas de reutilización de chaves.
Unha opción posible é usar . Isto pode ser demasiado caro para algún hardware actual, pero certamente é unha área na que os deseñadores deberían estar pensando no futuro, especialmente porque os estándares 5G están a piques de apoderarse do mundo.
Este novo estudo tamén suscita a pregunta xeral de por que , moitos dos cales utilizan deseños e protocolos moi similares. Cando te enfrontas ao problema de reinstalar a mesma chave en varios protocolos moi utilizados como WPA2, non cres que pode ser o momento de facer as túas especificacións e procedementos de proba máis robustos? Deixa de tratar aos implementadores de estándares como socios reflexivos que están atentos ás túas advertencias. Trátaos como adversarios (non intencionados) que inevitablemente se van a equivocar.
Ou, alternativamente, podemos facer o que empresas como Facebook e Apple están facendo cada vez máis: facer que o cifrado das chamadas de voz se produza nun nivel máis alto da pila de rede OSI, sen depender dos fabricantes de equipos móbiles. Incluso poderíamos impulsar o cifrado de extremo a extremo das chamadas de voz, como está a facer WhatsApp con Signal e FaceTime, asumindo que o goberno dos Estados Unidos só se deteña. . Entón (con excepción dalgúns metadatos) moitos destes problemas simplemente desaparecerían. Esta solución é especialmente relevante nun mundo onde .
Ou simplemente podemos facer o que xa fixeron os nosos fillos: deixar de responder esas molestas chamadas de voz.
Fonte: www.habr.com