🥇 Attaque de la semaine : appels vocaux en LTE (ReVoLTE)

Du traducteur et TL;DR

TL;DR :

Il semble que le VoLTE soit encore moins sécurisé que les premiers clients Wi-Fi avec WEP. C'est un échec architectural qui permet de légèrement XORer le trafic et de récupérer la clé. L'attaque est possible si vous êtes à proximité de l'appelant et qu'il passe souvent des appels.
Merci pour la suggestion et TL;DR Klukonin
Les chercheurs ont créé une application pour déterminer si votre opérateur est vulnérable, plus de détails. ici. Partagez vos résultats dans les commentaires, chez moi sur MegaFon, VoLTE est désactivé.

À propos de l'auteur

Matthew Green.

Je suis cryptographe et professeur à l'université Johns Hopkins. J'ai conçu et analysé des systèmes cryptographiques utilisés dans les réseaux sans fil, les systèmes de paiement et les plateformes de protection du contenu numérique. Dans mes recherches, j'examine différentes manières d'utiliser la cryptographie pour améliorer la confidentialité des utilisateurs.

Cela fait longtemps que je n'ai pas écrit de publication au format « attaque de la semaine », et cela me pesait. Pas parce qu'il n'y avait pas d'attaques, mais surtout parce qu'il n'y avait pas d'attaques sur quelque chose de suffisamment largement utilisé pour me sortir de ma crise créative.

Mais aujourd'hui, je suis tombé sur une attaque intéressante appelée ReVoLTE sur des protocoles dont le piratage me réjouit particulièrement, notamment les protocoles de réseaux mobiles (voix sur) LTE. Je suis enthousiasmé par ces protocoles – et cette nouvelle attaque – parce qu'il est très rare de voir une réelle attaque sur des protocoles et des mises en œuvre de réseaux mobiles. Principalement parce que ces normes sont conçues dans des salles enfumées et présentées dans des documents de 12 000 pages, difficiles à maîtriser pour chaque chercheur. De plus, l'exécution de ces attaques oblige les chercheurs à utiliser des protocoles radio complexes.

Ainsi, de sérieuses vulnérabilités cryptographiques peuvent se répandre dans le monde entier et seront peut-être utilisées uniquement par des gouvernements avant qu'un chercheur ne les remarque. Mais il y a parfois des exceptions, et l'attaque d'aujourd'hui en est une.

Auteurs les attaques: David Rupprecht, Katharina Kohls, Thorsten Holz et Christina Pöpper de l'Université de la Ruhr à Bochum et de l'Université de New York à Abu Dhabi. C'est une excellente attaque sur la réinstallation de clés dans le protocole vocal que vous utilisez probablement déjà (si l'on suppose que vous faites partie de la génération plus âgée qui utilise encore un téléphone mobile pour passer des appels).

Pour commencer – un bref historique.

Qu'est-ce que LTE et VoLTE ?

Les bases de nos normes de téléphonie mobile modernes ont été posées en Europe dans les années 80 avec la norme Global System for Mobile (Système Mondial de Mobilité). GSM a été la première norme principale de téléphonie mobile numérique à introduire plusieurs fonctions révolutionnaires, telles que l'utilisation de cryptage pour protéger les appels téléphoniques. Le GSM initial était principalement conçu pour la communication vocal, bien qu'il soit possible de transmettre d'autres données moyennant un coût.

À mesure que l'importance de la transmission de données dans la téléphonie mobile a augmenté, des normes de Long Terme Evolution (LTE) ont été développées pour rationaliser ce type de communication. Le LTE repose sur un groupe de normes plus anciennes, telles que GSM, EDGE et HSPA et vise à augmenter la vitesse d'échange de données. Dans ce domaine, il y a beaucoup de marketing et de confusion causée par des désignations incorrectes, mais TL;DR est que LTE est un système de transmission de données qui sert de pont entre les anciens protocoles de transmission de données par paquets et les technologies futures de transmission de données mobiles 5G.

Il va de soi que l'histoire nous enseigne qu'une fois qu'il y a suffisamment de bande passante (IP), des concepts tels que « voix » et « données » commenceront à se mélanger. Il en va de même pour les protocoles mobiles modernes. Pour rendre cette transition plus fluide, les normes LTE définissent Voice-over-LTE (VoLTE), qui est une norme IP pour transmettre des appels vocaux directement à travers la couche de transmission de données du système LTE, contournant complètement la partie commutée du réseau mobile. Tout comme pour les appels VoIP standards, les appels VoLTE peuvent être terminés par l'opérateur de réseau mobile et connectés au réseau téléphonique traditionnel. Ou (ce qui devient de plus en plus commun) ils peuvent être acheminés directement d'un client mobile à un autre, et même entre différents fournisseurs.

Comme la VoIP standard, VoLTE repose sur deux protocoles IP populaires : le protocole d'initiation de session (Session Initiation Protocol – SIP) pour l'établissement de l'appel, et le protocole de transport en temps réel (Real Time Transport Protocol, qui devrait être appelé RTTP, mais qui s'appelle en réalité RTP) pour le traitement des données vocales. VoLTE ajoute également certaines optimisations supplémentaires de bande passante, telles que la compression des en-têtes.

Bien, quel rapport cela a-t-il avec le chiffrement ?

LTE, comme le GSM, dispose d'un ensemble standard de protocoles cryptographiques pour le chiffrement des paquets lors de leur transmission sans fil. Ils visent principalement à protéger vos données pendant leur transfert entre le téléphone (appelé « équipement utilisateur », ou UE) et la cellule de télécommunication (ou partout où votre fournisseur décide de terminer la connexion). Cela se produit parce que les fournisseurs de services mobiles considèrent les appareils externes d'écoute comme des ennemis. Évidemment.

(Cependant, le fait que les connexions VoLTE puissent se produire directement entre des clients de différents réseaux de fournisseurs signifie que le protocole lui-même VoLTE a certains protocoles de chiffrement supplémentaires et facultatifs qui peuvent se produire à des niveaux réseau plus élevés. Cela ne concerne pas l'article actuel, sauf pour le fait qu'ils peuvent tout gâcher. Nous en parlerons brièvement plus tard).

Historiquement, le chiffrement dans GSM avait de nombreuses faiblesses: de mauvais chiffres, des protocoles où seul le téléphone s'authentifiait auprès de la cellule (ce qui signifie qu'un attaquant pouvait se faire passer pour la cellule, générant un « Stingray ») et ainsi de suite. LTE a corrigé de nombreuses erreurs évidentes tout en conservant cependant une grande partie de l'ancienne structure.

Commençons par le chiffrement lui-même. En supposant que la création de la clé a déjà eu lieu — et nous en parlerons dans une minute — chaque paquet de données est chiffré à l'aide d'un mode de chiffrement de flux avec un certain chiffre appelé « EEA » (qui peut en pratique être réalisé à l'aide de choses comme AES). En gros, ici, le mécanisme de chiffrement est CTR, comme indiqué ci-dessous :

L'algorithme de chiffrement principal pour les paquets VoLTE (source : ReVoLTE). L'EEA est un chiffrement, «COUNT» est un compteur de 32 bits, «BEARER» est un identifiant unique de la session, séparant les connexions VoLTE et le trafic Internet classique. «DIRECTION» indique la direction du trafic – de l'UE vers la tour ou vice versa.

Étant donné que l'algorithme de chiffrement lui-même (EEA) peut être implémenté en utilisant un chiffrement fort comme l'AES, il est peu probable qu'il y ait une attaque directe contre le chiffrement lui-même, comme cela se produisait à l'époque de la GSM. Cependant, il est clair que même avec un chiffrement fort, ce schéma de chiffrement constitue un excellent moyen de se tirer une balle dans le pied.

En particulier : dans la norme LTE, un chiffrement de flux (non authentifié) est utilisé avec un mode qui sera extrêmement vulnérable si le compteur – et d'autres entrées, telles que le «bearer» et la «direction» – sont jamais réutilisés. Dans le langage moderne, le terme pour ce concept est «attaque de réutilisation de nonce», mais les risques potentiels ne sont pas quelque chose de récent. Ils sont connus et anciens, remontant à l'époque du glam metal et même de la disco.

Les attaques contre la réutilisation de nonce en mode CTR existaient déjà à l'époque où Poison est devenu célèbre.

Pour être juste, les normes LTE précisent : «Ne réutilisez pas ces compteurs, s'il vous plaît». Mais les normes LTE font environ 7000 pages, et, de toute façon, c'est comme prier des enfants de ne pas jouer avec un pistolet. Ils le feront inévitablement, et des choses horribles se produiront. Dans ce cas, le pistolet déchargeable est une attaque de réutilisation du flux de clés, où deux messages confidentiels différents sont XORés avec les mêmes octets du flux de clés. Cela est connu pour avoir un impact extrêmement dévastateur sur la confidentialité des messages..

Qu'est-ce que ReVoLTE?

L'attaque ReVoLTE démontre qu'en pratique, cette construction de chiffrement très vulnérable est mal utilisée par le matériel réel. En particulier, les auteurs analysent des appels VoLTE réels effectués avec du matériel commercial et montrent qu'ils peuvent utiliser quelque chose appelé «attaque de réinitialisation de clé». (Un grand mérite dans la détection de ce problème revient à Reyze et Lou. (Raza & Lu), qui ont été les premiers à signaler une vulnérabilité potentielle. Mais les recherches de ReVoLTE la transforment en une attaque pratique).

Permettez-moi de vous expliquer brièvement l'essence de l'attaque, bien que vous devriez également consulter le document source.

On peut supposer qu'une fois que LTE établit une connexion de transmission de données, le transfert de la voix par LTE devient simplement une question de routage des paquets vocaux via cette connexion avec tout le reste de votre trafic. En d'autres termes, VoLTE sera un concept qui existe uniquement au-dessus du niveau 2 [modèle OSI – ex.]. Ce n'est pas tout à fait vrai.

En réalité, le niveau de liaison de LTE introduit la notion de « bearer ». Un bearer est un identifiant de session distinct qui sépare différents types de trafic par paquets. Le trafic Internet normal (votre Twitter et Snapchat) passe par un bearer. La signalisation SIP pour VoIP passe par un autre, tandis que les paquets de trafic vocal sont traités par un troisième. Je ne suis pas très au fait des mécanismes des canaux radio et du routage réseau LTE, mais je suppose que cela est fait de cette manière parce que les réseaux LTE veulent garantir le fonctionnement des mécanismes QoS (qualité de service), afin que différents flux de paquets soient traités avec différents niveaux de priorité : c'est-à-dire que vos connexions TCP de second ordre avec Facebook peuvent avoir une priorité inférieure à celle de vos appels vocaux en temps réel.

C'est en fait pas un problème, mais les conséquences sont les suivantes. Les clés de chiffrement LTE sont créées séparément chaque fois qu'un nouveau « bearer » est établi. En principe, cela devrait se produire à chaque fois que vous passez un nouvel appel téléphonique. Cela signifie qu'une clé de chiffrement différente sera utilisée pour chaque appel, ce qui élimine la possibilité de réutiliser la même clé pour chiffrer deux ensembles différents de paquets d'appels vocaux. En réalité, la norme LTE indique quelque chose comme « vous devez utiliser des clés différentes chaque fois que vous établissez un nouveau bearer pour traiter un nouvel appel téléphonique ». Mais cela ne signifie pas que cela se passe réellement comme ça.

En réalité, dans les mises en œuvre réelles, deux appels différents se produisant dans une proximité temporelle immédiate utiliseront la même clé, malgré le fait que de nouveaux bearers (porteurs) identiques soient configurés entre eux. Le seul changement pratique qui se produit entre ces appels est que le compteur de chiffrement est réinitialisé à zéro. Dans la littérature, cela est parfois appelé attaque de réinitialisation de clé. On peut affirmer qu'en essence, c'est une erreur de mise en œuvre, bien que dans ce cas, les risques semblent en grande partie dérivés de la norme elle-même.

En pratique, cette attaque conduit à une réutilisation du flux de clés, où un attaquant peut obtenir des paquets chiffrés $inline$C_1 = M_1 oplus KS$inline$ et $inline$C_2 = M_2 oplus KS$inline$, permettant de calculer $inline$C_1 oplus C_2 = M_1 oplus M_2$inline$. Mieux encore, si l'attaquant connaît l'un des $inline$M_1$inline$ ou $inline$M_2$inline$, il peut immédiatement retrouver l'autre. Cela lui donne un fort incitatif à découvrir l'un des deux composants non chiffrés..

Cela nous amène au scénario d'attaque complet et le plus efficace. Considérons un attaquant capable d'intercepter le trafic radio entre le téléphone cible et la tour de téléphonie mobile, et qui aurait d'une manière ou d'une autre « eu la chance » d'enregistrer deux appels différents, où le second se produit immédiatement après le premier. Imaginez maintenant qu'il puisse deviner le contenu non chiffré de l'un des appels. Avec un tel coup de chance notre attaquant peut complètement déchiffrer le premier appel en utilisant un simple XOR entre deux ensembles de paquets.

Bien sûr, la chance n'est pas en jeu ici. Étant donné que les téléphones sont conçus pour recevoir des appels, un attaquant qui peut écouter le premier appel pourra initier le deuxième appel exactement au moment où le premier se termine. Ce second appel, en cas de réutilisation de la même clé de chiffrement avec un compteur réinitialisé à zéro, permettra de récupérer les données non chiffrées. De plus, étant donné que notre attaquant contrôle effectivement les données pendant le deuxième appel, il peut récupérer le contenu du premier appel – grâce à de nombreux détails spécifiquement implémentés qui jouent en sa faveur.Voici une image du plan d'attaque général, tirée de

Voici une image du plan général de l'attaque, tirée de document source:

Aperçu de l'attaque de document ReVoLTE. Ce schéma suppose qu'il y a deux appels différents utilisant la même clé. L'attaquant contrôle un sniffeur passif (en haut à gauche), ainsi qu'un second téléphone avec lequel il peut passer un deuxième appel vers le téléphone de la victime.

Ainsi, l'attaque fonctionne-t-elle vraiment ?

D'une part, c'est vraiment la question principale pour l'article sur ReVoLTE. Théoriquement, toutes les idées ci-dessus sont excellentes, mais laissent de nombreuses questions. Telles que :

Est-il possible (pour des chercheurs académiques) de réellement intercepter une connexion VoLTE ?
Les véritables systèmes LTE réinitialisent-ils vraiment les clés ?
Pouvez-vous réellement initier un deuxième appel suffisamment rapidement et de manière fiable pour que le téléphone et l'antenne réutilisent la clé ?
Même si les systèmes réinitialisent les clés, pouvez-vous réellement connaître le contenu non chiffré du deuxième appel – étant donné que des éléments comme les codecs et la réencodage peuvent complètement modifier (bit à bit) le contenu de ce deuxième appel, même si vous avez accès aux « bits » provenant de votre téléphone d'attaque ?

À certaines de ces questions, le travail de ReVoLTE répond par l'affirmative. Les auteurs utilisent un sniffeur de flux radio programmable commercial appelé Airscope pour intercepter l'appel VoLTE du côté descendant. (Je pense que le simple fait d'acquérir le logiciel et de comprendre à peu près son fonctionnement a coûté des mois de vie aux pauvres doctorants – ce qui est typique pour ce genre de recherches académiques).

Les chercheurs ont découvert que, pour activer la réutilisation de la clé, le deuxième appel doit se produire suffisamment rapidement après la fin du premier, mais pas trop – environ dix secondes pour les opérateurs avec lesquels ils ont expérimenté. Heureusement, il n'est pas important que l'utilisateur réponde à l'appel pendant ce temps – « l'appel », c'est-à-dire la connexion SIP elle-même, oblige l'opérateur à réutiliser la même clé.

Ainsi, bon nombre des problèmes les plus graves tournent autour du problème (4) – l'obtention des bits de contenu non chiffré d'un appel initié par un attaquant. Cela se produit car de nombreuses choses peuvent arriver à votre contenu alors qu'il passe du téléphone de l'assaillant au téléphone de la victime via le réseau mobile. Par exemple, des nuisances telles que le reformatage du flux audio chiffré, qui laisse le son inchangé mais modifie complètement sa représentation binaire. Les réseaux LTE utilisent également la compression des en-têtes RTP, ce qui peut modifier considérablement la plus grande partie du paquet RTP.

Enfin, les paquets envoyés par l'assaillant doivent s'aligner à peu près sur les paquets qui ont été envoyés pendant le premier appel téléphonique. Cela peut être problématique, car la modification du silence durant l'appel téléphonique conduit à des messages plus courts (le fameux bruit de confort), qui peuvent mal coïncider avec l'appel original.

Section « attaque dans le monde réel » vaut la peine d'être lue dans tous ses détails. Elle aborde de nombreux problèmes mentionnés ci-dessus – en particulier, les auteurs ont découvert que certains codecs n'étaient pas reformatés, et qu'environ 89 % de la représentation binaire de l'appel ciblé pouvait être récupérée. Cela s'applique à au moins deux opérateurs européens qui ont été testés.

C'est un niveau de succès étonnamment élevé, et, en toute honnêteté, bien plus élevé que je ne l'avais espéré au début de mes travaux sur ce document.

Que pouvons-nous faire pour remédier à cela ?

La réponse immédiate à cette question est très simple : puisque l'essence de la vulnérabilité réside dans l'attaque par réutilisation (réinstallation) de la clé, il suffit de corriger ce problème. Assurez-vous qu'une nouvelle clé est obtenue pour chaque appel téléphonique, et ne laissez jamais le compteur de paquets revenir à zéro avec la même clé. Problème résolu !

Peut-être que non. Cela nécessiterait la modernisation d'un grand nombre d'équipements et, honnêtement, une telle correction en elle-même n'est pas ultra fiable. Ce serait bien si les normes pouvaient trouver un moyen plus sûr de mettre en œuvre leurs modes de chiffrement, qui ne sont pas par défaut catastrophiquement vulnérables à de tels problèmes de réutilisation des clés.

Une des options possibles est d'utiliser des modes de chiffrement où une utilisation non cible du nonce ne conduit pas à des conséquences catastrophiques. Cela peut être trop coûteux pour certains matériels modernes, mais c'est sans aucun doute une direction à laquelle les concepteurs doivent penser à l'avenir, surtout compte tenu du fait que les normes 5G vont bientôt conquérir le monde.

Cette nouvelle recherche soulève également la question générale de pourquoi les mêmes maudites attaques continuent d'apparaître d'une norme à l'autre, dont beaucoup utilisent des constructions et protocoles très similaires. Lorsque vous êtes confronté à un problème de réinstallation de la même clé dans plusieurs protocoles largement utilisés, comme WPA2, n'avez-vous pas l'impression qu'il serait peut-être temps de rendre vos spécifications et procédures de test plus fiables ? Il serait temps de ne plus traiter les réalisateurs de normes comme des partenaires réfléchis, attentifs à vos avertissements. Traitez-les comme des (involontaires) adversaires qui vont inévitablement tout mettre en œuvre de manière incorrecte.

Ou, en alternative, nous pourrions faire ce que font de plus en plus des entreprises comme Facebook et Apple : faire en sorte que le chiffrement des appels vocaux se fasse à un niveau supérieur de la pile réseau OSI, sans dépendre des fabricants d'équipements de téléphonie mobile. Nous pourrions même promouvoir le chiffrement de bout en bout des appels vocaux, comme le fait WhatsApp avec Signal et FaceTime, en supposant que le gouvernement américain cessera simplement de nous mettre des bâtons dans les roues.Alors, à l'exception de certaines métadonnées, beaucoup de ces problèmes disparaîtraient tout simplement. Cette solution est particulièrement pertinente dans un monde où même les gouvernements ne sont pas sûrs de faire confiance à leurs fournisseurs d'équipement..

Ou bien nous pouvons simplement faire ce que nos enfants ont déjà fait : cesser de répondre à ces appels vocaux ennuyeux.

Source : habr.com