Do tradutor e TL;DR
-
TL; DR:
Parece que o VoLTE acabou sendo ainda pior protegido do que os primeiros clientes Wi-Fi com WEP. Um erro de cálculo exclusivamente arquitetônico que permite XOR um pouco o tráfego e restaurar a chave. Um ataque é possível se você estiver perto do chamador e ele fizer ligações com frequência.
-
Obrigado pela dica e TL;DR
-
Pesquisadores criaram um aplicativo para determinar se sua operadora está vulnerável, leia mais . Compartilhe os resultados nos comentários, VoLTE está desabilitado na minha região no Megafon.
Sobre o autor
Mateus Verde.
Sou criptógrafo e professor na Universidade Johns Hopkins. Projetei e analisei sistemas criptográficos utilizados em redes sem fio, sistemas de pagamento e plataformas de segurança de conteúdo digital. Em minha pesquisa, procuro diferentes maneiras de usar a criptografia para melhorar a privacidade do usuário.
Já faz um tempo que não escrevo um formato de post , e isso me chateou. Não porque não houve ataques, mas principalmente porque não houve um ataque a algo amplamente utilizado o suficiente para me tirar do bloqueio de escritor.
Mas hoje me deparei chamado ReVoLTE para protocolos que estou particularmente entusiasmado com hackers, ou seja, protocolos LTE de rede celular (voz sobre). Estou entusiasmado com esses protocolos específicos – e com esse novo ataque – porque é muito raro ver protocolos e implementações reais de redes celulares sendo invadidos. Principalmente porque esses padrões foram desenvolvidos em salas cheias de fumaça e documentados em documentos de 12000 mil páginas que nem todos os pesquisadores conseguem lidar. Além disso, a implementação destes ataques obriga os investigadores a utilizar protocolos de rádio complexos.
Assim, vulnerabilidades criptográficas graves poderão espalhar-se por todo o mundo, talvez apenas para serem exploradas pelos governos, antes que qualquer investigador tome conhecimento. Mas de vez em quando há exceções, e o ataque de hoje é uma 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 é um ótimo ataque para reinstalar a chave no protocolo de voz que você provavelmente já usa (supondo que você seja de uma geração mais antiga que ainda faz ligações pelo celular).
Para começar, uma breve excursão histórica.
O que são LTE e VoLTE?
A base dos nossos modernos padrões de telefonia celular foi lançada na Europa na década de 80 pelo padrão (Sistema Global para Comunicações Móveis). GSM foi o primeiro grande padrão de telefonia celular digital, que introduziu uma série de recursos revolucionários, como o uso para proteger chamadas telefônicas. Os primeiros GSM foram projetados principalmente para comunicações de voz, embora o dinheiro pudesse ser .
À medida que a transmissão de dados se tornou mais importante nas comunicações celulares, os padrões Long Term Evolution (LTE) foram desenvolvidos para agilizar esse tipo de comunicação. LTE é baseado em um grupo de padrões mais antigos como GSM, и e foi projetado para aumentar a velocidade de troca de dados. Há muitas marcas e mas o TL;DR é que LTE é um sistema de transmissão de dados que serve como uma ponte entre protocolos de dados de pacotes mais antigos e futuras tecnologias de dados celulares .
É claro que a história nos diz que quando houver largura de banda (IP) suficiente disponível, conceitos como “voz” e “dados” começarão a se confundir. O mesmo se aplica aos protocolos celulares modernos. Para tornar esta transição mais suave, os padrões LTE definem (VoLTE), que é um padrão IP para transportar chamadas de voz diretamente no plano de dados de um sistema LTE, ignorando totalmente a parte dial-up da rede celular. Tal como acontece com o padrão ,As chamadas VoLTE podem ser encerradas pela operadora de celular e conectadas à rede telefônica regular. Ou (como está se tornando cada vez mais comum) eles diretamente de um cliente de celular para outro e até mesmo entre diferentes operadoras.
Assim como o VoIP padrão, o VoLTE é baseado em dois protocolos populares baseados em IP: Session Initiation Protocol ( – SIP) para configuração de chamadas e protocolo de transporte em tempo real (, que deveria ser chamado de RTTP, mas na verdade é chamado de RTP) para processamento de dados de voz. VoLTE também adiciona algumas otimizações adicionais de largura de banda, como compactação de cabeçalho.
Ok, o que isso tem a ver com criptografia?
LTE, como , possui um conjunto padrão de protocolos criptográficos para criptografar pacotes à medida que são transmitidos pelo ar. Eles são projetados principalmente para proteger seus dados enquanto eles trafegam entre o telefone (chamado de equipamento do usuário, ou UE) e a torre de celular (ou onde quer que seu provedor decida encerrar a conexão). Isso ocorre porque as operadoras de celular veem os dispositivos externos de escuta como inimigos. Bem, claro.
(No entanto, o fato de que as conexões VoLTE podem ocorrer diretamente entre clientes em redes de provedores diferentes significa que o próprio protocolo VoLTE possui alguns protocolos de criptografia adicionais e opcionais que podem ocorrer em camadas de rede mais altas. Isso não é relevante para o artigo atual, exceto o fato de que eles podem estragar tudo (falaremos sobre eles brevemente a seguir).
Historicamente, a criptografia no GSM tem sido : ruim , protocolos nos quais apenas o telefone era autenticado na torre (o que significa que um invasor poderia se passar pela torre, gerando ) e assim por diante. LTE corrigiu muitos dos bugs óbvios, mantendo grande parte da mesma estrutura.
Vamos começar com a criptografia em si. Supondo que a criação da chave já tenha acontecido - e falaremos sobre isso em um minuto - então cada pacote de dados é criptografado usando criptografia de fluxo usando algo chamado "EEA" (que na prática pode ser implementado usando coisas como AES). Essencialmente, o mecanismo de criptografia aqui é como abaixo:
O principal algoritmo de criptografia para pacotes VoLTE (fonte: ). EEA é uma cifra, “COUNT” é um contador de 32 bits, “BEARER” é um identificador de sessão exclusivo que separa as conexões VoLTE do tráfego normal da Internet. "DIRECTION" indica em qual direção o tráfego está fluindo - do UE para a torre ou vice-versa.
Como o próprio algoritmo de criptografia (EEA) pode ser implementado usando uma cifra forte como AES, é improvável que haja qualquer ataque direto à própria cifra como este. . Porém, está claro que mesmo com uma cifra forte, esse esquema de criptografia é uma ótima maneira de dar um tiro no próprio pé.
Em particular: o padrão LTE usa uma cifra de fluxo (não autenticada) com um modo que será extremamente vulnerável se o contador - e outras entradas como "portador" e "direção" - forem reutilizados. Na linguagem moderna, o termo para este conceito é “ataque de reutilização única”, mas os riscos potenciais aqui não são algo moderno. Eles são famosos e antigos, datando da época do glam metal e até da discoteca.
Ataques à reutilização de nonce no modo CTR existiam mesmo quando o Poison se tornou conhecido
Para ser justo, os padrões LTE dizem: “Por favor, não reutilize estes medidores”. Mas os padrões LTE têm cerca de 7000 páginas e, de qualquer forma, é como implorar às crianças para não brincarem com uma arma. Eles inevitavelmente acontecerão, e coisas terríveis acontecerão. A arma de fogo, neste caso, é um ataque de reutilização de keystream, no qual duas mensagens confidenciais diferentes fazem XOR dos mesmos bytes de keystream. Sabe-se que isso .
O que é ReVoLTE?
O ataque ReVoLTE demonstra que, na prática, esse design de criptografia muito vulnerável é mal utilizado por hardware do mundo real. Especificamente, os autores analisam chamadas VoLTE reais feitas com equipamentos comerciais e mostram que podem usar algo chamado “ataque de reinstalação de chave”. (Muito crédito por encontrar este problema vai para (Raza & Lu), que foram os primeiros a apontar a potencial vulnerabilidade. Mas a pesquisa ReVoLTE transforma isso em um ataque prático).
Deixe-me mostrar brevemente a essência do ataque, embora você deva olhar e .
Pode-se supor que, uma vez que o LTE estabeleça uma conexão de dados por pacote, a tarefa de voz sobre LTE se torne apenas uma questão de rotear pacotes de voz por essa conexão junto com todo o restante do seu tráfego. Em outras palavras, VoLTE será um conceito que só existe há mais de [Modelos OSI – Aproximadamente.]. Isso não é inteiramente verdade.
Na verdade, a camada de link LTE introduz o conceito de “portador”. Os portadores são identificadores de sessão separados que separam diferentes tipos de tráfego de pacotes. O tráfego regular da Internet (Twitter e Snapchat) passa por um portador. A sinalização SIP para VoIP passa por outro e os pacotes de tráfego de voz são processados por um terceiro. Não tenho muito conhecimento sobre mecanismos de roteamento de rede e rádio LTE, mas acredito que isso seja feito dessa maneira porque as redes LTE desejam impor mecanismos de QoS (qualidade de serviço) para que diferentes fluxos de pacotes sejam processados em diferentes níveis de prioridade: ou seja, seu segunda categoria As conexões TCP com o Facebook podem ter uma prioridade mais baixa do que as chamadas de voz em tempo real.
Geralmente isso não é um problema, mas as consequências são as seguintes. As chaves para criptografia LTE são criadas separadamente cada vez que um novo “portador” é instalado. Basicamente, isso deve acontecer novamente sempre que você fizer uma nova ligação. Isto resultará na utilização de uma chave de criptografia diferente para cada chamada, eliminando a possibilidade de reutilizar a mesma chave para criptografar dois conjuntos diferentes de pacotes de chamadas de voz. Na verdade, o padrão LTE diz algo como “você deve usar uma chave diferente cada vez que instalar uma nova portadora para lidar com uma nova chamada”. Mas isso não significa que isso realmente aconteça.
Na verdade, em implementações da vida real, duas chamadas diferentes que ocorrem em estreita proximidade temporal usarão a mesma chave - apesar de novos portadores com o mesmo nome serem configurados entre elas. A única mudança prática que ocorre entre essas chamadas é que o contador de criptografia é zerado. Na literatura isso às vezes é chamado . Poderíamos argumentar que se trata essencialmente de um erro de implementação, embora neste caso os riscos pareçam decorrer em grande parte da própria norma.
Na prática, este ataque resulta na reutilização do fluxo de chaves, onde o invasor pode obter os pacotes criptografados $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$inline$. Melhor ainda, se o invasor conhecer um dos $inline$M_1$inline$ ou $inline$M_2$inline$, ele poderá recuperar imediatamente o outro. Isso lhe dá um forte incentivo descubra um dos dois componentes não criptografados.
Isso nos leva ao cenário de ataque completo e mais eficaz. Considere um invasor que consegue interceptar o tráfego de rádio entre um telefone alvo e uma torre de celular e que, de alguma forma, tem a sorte de gravar duas chamadas diferentes, com a segunda ocorrendo imediatamente após a primeira. Agora imagine que ele pudesse de alguma forma adivinhar o conteúdo não criptografado de uma das chamadas. Com tamanha acaso nosso invasor pode descriptografar totalmente a primeira chamada usando um simples XOR entre os dois conjuntos de pacotes.
Claro, a sorte não tem nada a ver com isso. Como os telefones são projetados para receber chamadas, um invasor que conseguir ouvir a primeira chamada poderá iniciar uma segunda chamada no exato momento em que a primeira terminar. Esta segunda chamada, se a mesma chave de criptografia for usada novamente com o contador zerado, permitirá a recuperação dos dados não criptografados. Além disso, uma vez que o nosso atacante controla realmente os dados durante a segunda chamada, ele pode recuperar o conteúdo da primeira chamada - graças a muitos programas especificamente implementados Coisas pequenas, jogando ao seu lado.
Aqui está uma imagem do plano geral de ataque retirado de :
Visão geral do ataque de . Este esquema pressupõe que duas chamadas diferentes sejam feitas usando a mesma tecla. O invasor controla o sniffer passivo (canto superior esquerdo), bem como um segundo telefone, com o qual pode fazer uma segunda ligação para o telefone da vítima.
Então o ataque realmente funciona?
Por um lado, esta é realmente a questão principal do artigo sobre ReVoLTE. Todas as ideias acima são ótimas em teoria, mas deixam muitas questões. Como:
- É possível (para pesquisadores acadêmicos) realmente interceptar uma conexão VoLTE?
- Os sistemas LTE reais realmente são recodificados?
- Você pode realmente iniciar uma segunda chamada de forma rápida e confiável o suficiente para que o telefone e a torre reutilizem a chave?
- Mesmo que os sistemas sejam recodificados, você pode realmente saber o conteúdo não criptografado da segunda chamada - visto que coisas como codecs e transcodificação podem alterar completamente o conteúdo (bit a bit) dessa segunda chamada, mesmo se você tiver acesso aos "bits " vindo do seu telefone de ataque?
O trabalho da ReVoLTE responde afirmativamente a algumas dessas questões. Os autores usam um sniffer comercial de fluxo de rádio reconfigurável por software chamado para interceptar uma chamada VoLTE do lado do downlink. (Acho que apenas familiarizar-se com o software e ter uma ideia aproximada de como ele funciona tirou meses da vida dos pobres estudantes de pós-graduação - o que é típico desse tipo de pesquisa acadêmica).
Os pesquisadores descobriram que, para que a reutilização de chaves funcionasse, a segunda chamada precisava acontecer com rapidez suficiente após o término da primeira, mas não muito rapidamente – cerca de dez segundos para os operadores com os quais eles experimentaram. Felizmente, não importa se o usuário atende a chamada dentro desse tempo - o “toque”, ou seja. A própria conexão SIP obriga a operadora a reutilizar a mesma chave.
Assim, muitos dos piores problemas giram em torno do problema (4) – receber bits do conteúdo não criptografado de uma chamada iniciada por um invasor. Isso ocorre porque muita coisa pode acontecer com o seu conteúdo enquanto ele viaja do telefone do invasor para o telefone da vítima pela rede celular. Por exemplo, truques sujos como recodificar um fluxo de áudio codificado, que deixa o som igual, mas muda completamente sua representação binária. As redes LTE também usam compactação de cabeçalho RTP, o que pode alterar significativamente grande parte do pacote RTP.
Finalmente, os pacotes enviados pelo invasor devem estar aproximadamente alinhados com os pacotes enviados durante a primeira chamada telefônica. Isso pode ser problemático porque modificar o silêncio durante uma chamada resulta em mensagens mais curtas (também conhecidas como ruído de conforto) que podem não se adequar bem à chamada original.
Vale a pena ler detalhadamente. Ele aborda muitos dos problemas acima - em particular, os autores descobriram que alguns codecs não são recodificados e que aproximadamente 89% da representação binária da chamada alvo pode ser recuperada. Isto é verdade para pelo menos dois operadores europeus que foram testados.
Esta é uma taxa de sucesso surpreendentemente elevada e, francamente, muito mais elevada do que eu esperava quando comecei a trabalhar neste documento.
Então, o que podemos fazer para consertar isso?
A resposta imediata a esta pergunta é muito simples: como a essência da vulnerabilidade é um ataque de reutilização (reinstalação) de chave, basta corrigir o problema. Certifique-se de obter uma nova chave para cada chamada telefônica e nunca permita que o contador de pacotes redefina o contador para zero usando a mesma chave. Problema resolvido!
Ou talvez não. Isso exigirá a atualização de muitos equipamentos e, francamente, tal solução por si só não é muito confiável. Seria bom se os padrões pudessem encontrar uma maneira mais segura de implementar seus modos de criptografia que não fosse, por padrão, catastroficamente vulnerável a tais problemas de reutilização de chaves.
Uma opção possível é usar . Isso pode ser muito caro para alguns hardwares atuais, mas é certamente uma área na qual os designers deveriam estar pensando no futuro, especialmente porque os padrões 5G estão prestes a dominar o mundo.
Este novo estudo também levanta a questão geral de por que , muitos dos quais usam designs e protocolos muito semelhantes. Quando você se depara com o problema de reinstalar a mesma chave em vários protocolos amplamente usados, como o WPA2, você não acha que talvez seja hora de tornar suas especificações e procedimentos de teste mais robustos? Pare de tratar os implementadores de padrões como parceiros atenciosos e atentos aos seus avisos. Trate-os como adversários (não intencionais) que inevitavelmente vão errar.
Ou, alternativamente, podemos fazer o que empresas como o Facebook e a Apple estão fazendo cada vez mais: fazer com que a criptografia de chamadas de voz aconteça em um nível mais alto da pilha de rede OSI, sem depender de fabricantes de equipamentos celulares. Poderíamos até pressionar pela criptografia ponta a ponta das chamadas de voz, como o WhatsApp está fazendo com o Signal e o FaceTime, presumindo que o governo dos EUA simplesmente pare . Então (com exceção de alguns metadados) muitos destes problemas simplesmente desapareceriam. Esta solução é especialmente relevante num mundo onde .
Ou podemos simplesmente fazer o que nossos filhos já fizeram: parar de atender aquelas chamadas de voz irritantes.
Fonte: habr.com