Du traducteur et TL;DR
-
TL; DR:
Il semble que VoLTE se soit avéré encore moins bien protégé que les premiers clients Wi-Fi avec WEP. Une erreur de calcul exclusivement architecturale qui permet de XOR un peu le trafic et de restaurer la clé. Une attaque est possible si vous êtes proche de l'appelant et qu'il appelle fréquemment.
-
Merci pour le conseil et TL;DR
-
Des chercheurs ont créé une application pour déterminer si votre opérateur est vulnérable. En savoir plus . Partagez les résultats dans les commentaires, VoLTE est désactivé dans ma région sur Megafon.
À propos de l'auteur
Matthieu 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 sécurité des contenus numériques. Dans mes recherches, j’examine différentes manières d’utiliser la cryptographie pour améliorer la confidentialité des utilisateurs.
Cela fait un moment que je n'ai pas écrit de format de message , et ça m'a bouleversé. Non pas parce qu'il n'y a pas eu d'attaques, mais surtout parce qu'il n'y a pas eu d'attaque contre quelque chose de suffisamment largement utilisé pour me sortir du blocage de l'écrivain.
Mais aujourd'hui, je suis tombé sur appelé ReVoLTE pour les protocoles que je suis particulièrement enthousiasmé par le piratage, à savoir les protocoles LTE des réseaux cellulaires (voix off). Je suis enthousiasmé par ces protocoles particuliers – et par cette nouvelle attaque – car il est très rare de voir de véritables protocoles et implémentations de réseaux cellulaires être piratés. Principalement parce que ces normes ont été élaborées dans des salles enfumées et documentées dans des documents de 12000 XNUMX pages que tous les chercheurs ne peuvent pas gérer. De plus, la mise en œuvre de ces attaques oblige les chercheurs à utiliser des protocoles radio complexes.
Ainsi, de graves vulnérabilités cryptographiques pourraient se propager à travers le monde, peut-être uniquement pour être exploitées par les gouvernements, avant qu’aucun chercheur ne s’en aperçoive. Mais il y a parfois des exceptions, et l’attaque d’aujourd’hui en fait partie.
Auteurs Contributeurs : 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. Il s'agit d'une excellente attaque visant à réinstaller la clé dans le protocole vocal que vous utilisez probablement déjà (en supposant que vous apparteniez à une génération plus ancienne qui passe encore des appels téléphoniques à l'aide d'un téléphone portable).
Pour commencer, une brève excursion historique.
Que sont le LTE et le VoLTE ?
La base de nos normes modernes de téléphonie cellulaire a été posée en Europe dans les années 80 par la norme (Système Global pour les Communications Mobiles). Le GSM a été la première norme majeure de téléphonie cellulaire numérique, qui a introduit un certain nombre de fonctionnalités révolutionnaires, telles que l'utilisation pour protéger les appels téléphoniques. Les premiers GSM étaient conçus principalement pour les communications vocales, même si l'argent pouvait être .
À mesure que la transmission de données devenait plus importante dans les communications cellulaires, des normes d'évolution à long terme (LTE) ont été développées pour rationaliser ce type de communication. LTE est basé sur un groupe de normes plus anciennes telles que GSM, и et est conçu pour augmenter la vitesse d’échange de données. Il y a beaucoup de branding et mais le TL;DR est que le LTE est un système de transmission de données qui sert de pont entre les anciens protocoles de données par paquets et les futures technologies de données cellulaires. .
Bien entendu, l’histoire nous apprend qu’une fois qu’il y aura suffisamment de bande passante (IP) disponible, des concepts tels que « voix » et « données » commenceront à s’estomper. Il en va de même pour les protocoles cellulaires modernes. Pour rendre cette transition plus fluide, les normes LTE définissent (VoLTE), qui est une norme IP permettant de transmettre des appels vocaux directement sur le plan de données d'un système LTE, en contournant entièrement la partie commutée du réseau cellulaire. Comme pour la norme Les appels VoLTE peuvent être terminés par l'opérateur cellulaire et connectés au réseau téléphonique régulier. Ou (comme cela devient de plus en plus courant) ils directement d'un client cellulaire à un autre, et même entre différents fournisseurs.
Comme la VoIP standard, la VoLTE est basée sur deux protocoles IP populaires : Session Initiation Protocol ( – SIP) pour l’établissement des appels et protocole de transport en temps réel (, qui devrait s'appeler RTTP mais s'appelle en réalité RTP) pour le traitement des données vocales. VoLTE ajoute également des optimisations supplémentaires de la bande passante, telles que la compression d'en-tête.
D'accord, qu'est-ce que cela a à voir avec le cryptage ?
LTE, comme , dispose d'un ensemble standard de protocoles cryptographiques pour chiffrer les paquets lors de leur transmission par voie hertzienne. Ils sont principalement conçus pour protéger vos données lors de leur déplacement entre le téléphone (appelé équipement utilisateur, ou UE) et la tour de téléphonie cellulaire (ou partout où votre fournisseur décide de mettre fin à la connexion). En effet, les fournisseurs de téléphonie mobile considèrent les appareils d’écoute externes comme des ennemis. Oui bien sur.
(Cependant, le fait que les connexions VoLTE puissent se produire directement entre des clients sur des réseaux de fournisseurs différents signifie que le protocole VoLTE lui-même possède des protocoles de cryptage supplémentaires et facultatifs qui peuvent se produire au niveau des couches réseau supérieures. Cela n'est pas pertinent pour l'article actuel, sauf le fait que ils peuvent tout gâcher (nous en parlerons brièvement ensuite).
Historiquement, le cryptage du GSM a été : mauvais , protocoles dans lesquels seul le téléphone était authentifié auprès de la tour (ce qui signifie qu'un attaquant pouvait usurper l'identité de la tour, générant ) et ainsi de suite. LTE a corrigé de nombreux bugs évidents tout en conservant une grande partie de la même structure.
Commençons par le chiffrement lui-même. En supposant que la création de clé a déjà eu lieu - et nous en reparlerons dans une minute - alors chaque paquet de données est crypté à l'aide d'un cryptage de flux à l'aide de quelque chose appelé "EEA" (qui peut en pratique être implémenté en utilisant des éléments comme AES ). Essentiellement, le mécanisme de cryptage ici est comme ci-dessous :
Le principal algorithme de chiffrement des paquets VoLTE (source : ). EEA est un chiffre, « COUNT » est un compteur de 32 bits, « BEARER » est un identifiant de session unique qui sépare les connexions VoLTE du trafic Internet régulier. "DIRECTION" indique dans quelle direction circule le trafic - de l'UE à la tour ou vice versa.
Étant donné que l'algorithme de chiffrement lui-même (EEA) peut être implémenté à l'aide d'un chiffrement fort comme AES, il est peu probable qu'il y ait une attaque directe contre le chiffrement lui-même comme celle-ci. . Cependant, il est clair que même avec un chiffrement fort, ce système de cryptage est un excellent moyen de se tirer une balle dans le pied.
En particulier : la norme LTE utilise un chiffrement de flux (non authentifié) avec un mode qui sera extrêmement vulnérable si le compteur - et d'autres entrées telles que "porteur" et "direction" - sont un jour réutilisés. Dans le langage moderne, le terme désignant ce concept est « attaque de réutilisation occasionnelle », mais les risques potentiels ici ne sont pas quelque chose de moderne. Ils sont célèbres et anciens, remontant à l’époque du glam metal et même du disco.
Des attaques contre la réutilisation occasionnelle en mode CTR existaient même lorsque Poison est devenu connu
Pour être honnête, les normes LTE disent : « Veuillez ne pas réutiliser ces compteurs. » Mais les normes LTE font environ 7000 XNUMX pages, et de toute façon, c'est comme supplier les enfants de ne pas jouer avec une arme à feu. Cela se produira inévitablement, et des choses terribles se produiront. Dans ce cas, le coup de feu est une attaque de réutilisation du flux de clés, dans laquelle deux messages confidentiels différents XOR les mêmes octets du flux de clés. On sait que cela .
Qu’est-ce que ReVoLTE ?
L’attaque ReVoLTE démontre qu’en pratique, cette conception de chiffrement très vulnérable est utilisée à mauvais escient par le matériel réel. Plus précisément, les auteurs analysent les appels VoLTE réels effectués à l'aide d'équipements commerciaux et montrent qu'ils peuvent utiliser ce qu'on appelle une « attaque de réinstallation de clé ». (Une grande partie du mérite d'avoir découvert ce problème revient à (Raza & Lu), qui ont été les premiers à souligner la vulnérabilité potentielle. Mais la recherche ReVoLTE en fait une attaque pratique).
Permettez-moi de vous montrer brièvement l'essence de l'attaque, même si vous devriez regarder et .
On pourrait supposer qu'une fois que LTE établit une connexion de données par paquets, la tâche de la voix sur 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 n’existera que sur [Modèles OSI – environ.]. Ce n'est pas tout à fait vrai.
En fait, la couche liaison LTE introduit la notion de « support ». Les porteurs sont des identifiants de session distincts qui séparent les différents types de trafic de paquets. Le trafic Internet régulier (votre Twitter et Snapchat) passe par un seul support. La signalisation SIP pour la VoIP passe par un autre et les paquets de trafic vocal sont traités par un troisième. Je ne connais pas très bien les mécanismes de routage radio et réseau LTE, mais je pense que cela est fait de cette façon parce que les réseaux LTE veulent appliquer des mécanismes de QoS (qualité de service) afin que différents flux de paquets soient traités à différents niveaux de priorité : c'est-à-dire le vôtre de second ordre Les connexions TCP à Facebook peuvent avoir une priorité inférieure à vos appels vocaux en temps réel.
Ce n'est généralement pas un problème, mais les conséquences sont les suivantes. Les clés de cryptage LTE sont créées séparément à chaque fois qu'un nouveau « support » est installé. Fondamentalement, cela devrait se reproduire à chaque fois que vous passez un nouvel appel téléphonique. Cela entraînera l'utilisation d'une clé de cryptage différente pour chaque appel, éliminant ainsi la possibilité de réutiliser la même clé pour crypter deux ensembles différents de paquets d'appels vocaux. En effet, la norme LTE dit quelque chose comme "vous devez utiliser une clé différente à chaque fois que vous installez un nouveau support pour gérer un nouvel appel téléphonique". Mais cela ne veut pas dire que cela se produit réellement.
En fait, dans des implémentations réelles, deux appels différents se produisant à proximité temporelle étroite utiliseront la même clé – malgré le fait que de nouveaux porteurs du même nom soient configurés entre eux. Le seul changement pratique qui se produit entre ces appels est que le compteur de chiffrement est remis à zéro. Dans la littérature, cela est parfois appelé . On pourrait affirmer qu’il s’agit essentiellement d’une erreur de mise en œuvre, même si dans ce cas, les risques semblent provenir en grande partie de la norme elle-même.
En pratique, cette attaque aboutit à une réutilisation du flux de clés, où l'attaquant peut obtenir les paquets chiffrés $inline$C_1 = M_1 oplus KS$inline$ et $inline$C_2 = M_2 oplus KS$inline$, permettant le calcul de $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$, alors il peut immédiatement récupérer l'autre. Cela lui donne une forte incitation découvrez l'un des deux composants non chiffrés.
Cela nous amène au scénario d’attaque complet et le plus efficace. Prenons l’exemple d’un attaquant capable d’intercepter le trafic radio entre un téléphone cible et une tour de téléphonie cellulaire et qui, d’une manière ou d’une autre, a la chance d’enregistrer deux appels différents, le second ayant lieu immédiatement après le premier. Imaginez maintenant qu'il puisse d'une manière ou d'une autre deviner le contenu non crypté de l'un des appels. Avec un tel hasard notre attaquant peut décrypter entièrement le premier appel en utilisant un simple XOR entre les deux ensembles de paquets.
Bien sûr, la chance n’a rien à voir là-dedans. Les téléphones étant conçus pour recevoir des appels, un attaquant capable d’entendre le premier appel pourra lancer un deuxième appel au moment précis où le premier se termine. Ce deuxième appel, si la même clé de chiffrement est réutilisée avec le compteur remis à zéro, permettra de récupérer les données en clair. De plus, puisque notre attaquant contrôle effectivement les données lors du deuxième appel, il peut récupérer le contenu du premier appel - grâce à de nombreux outils spécifiquement mis en œuvre petites choses, jouant de son côté.
Voici une image du plan d'attaque général tirée de :
Aperçu de l'attaque de . Ce schéma suppose que deux appels différents sont effectués à l'aide de la même clé. L'attaquant contrôle le renifleur passif (en haut à gauche), ainsi qu'un deuxième téléphone, avec lequel il peut passer un deuxième appel sur le téléphone de la victime.
Alors, l’attaque fonctionne-t-elle vraiment ?
D’une part, c’est vraiment la question principale de l’article sur ReVoLTE. Toutes les idées ci-dessus sont excellentes en théorie, mais elles soulèvent de nombreuses questions. Tel que:
- Est-il possible (pour les chercheurs universitaires) d'intercepter réellement une connexion VoLTE ?
- Les vrais systèmes LTE effectuent-ils réellement une nouvelle saisie ?
- Pouvez-vous réellement lancer un deuxième appel de manière suffisamment rapide et fiable pour que le téléphone et la tour puissent réutiliser la clé ?
- Même si les systèmes refont leur clé, pouvez-vous réellement connaître le contenu non chiffré du deuxième appel - étant donné que des éléments tels que les codecs et le transcodage peuvent complètement modifier le contenu (bit par bit) de ce deuxième appel, même si vous avez accès aux "bits". " venant de ton téléphone d'attaque ?
Le travail de ReVoLTE répond à certaines de ces questions par l'affirmative. Les auteurs utilisent un renifleur de flux radio commercial reconfigurable par logiciel appelé pour intercepter un appel VoLTE du côté liaison descendante. (Je pense que le simple fait de se familiariser avec le logiciel et d'avoir une idée générale de son fonctionnement a pris des mois de vie aux pauvres étudiants diplômés - ce qui est typique pour ce type de recherche universitaire).
Les chercheurs ont découvert que pour que la réutilisation des clés fonctionne, le deuxième appel devait avoir lieu assez rapidement après la fin du premier, mais pas trop rapidement : environ dix secondes pour les opérateurs avec lesquels ils ont expérimenté. Heureusement, peu importe que l'utilisateur réponde à l'appel dans ce délai - la "sonnerie", 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 néfastes tournent autour du problème (4) : recevoir des bits du contenu non crypté d'un appel initié par un attaquant. En effet, beaucoup de choses peuvent arriver à votre contenu lorsqu'il passe du téléphone de l'attaquant au téléphone de la victime via le réseau cellulaire. Par exemple, des astuces telles que le réencodage d'un flux audio codé, qui laisse le son identique, mais change complètement sa représentation binaire. Les réseaux LTE utilisent également la compression d'en-tête RTP, ce qui peut modifier considérablement une grande partie du paquet RTP.
Enfin, les paquets envoyés par l’attaquant doivent être à peu près conformes aux paquets envoyés lors du premier appel téléphonique. Cela peut être problématique car la modification du silence lors d'un appel téléphonique entraîne des messages plus courts (c'est-à-dire un bruit de confort) qui peuvent ne pas bien correspondre à l'appel d'origine.
Cela vaut la peine d'être lu en détail. Il résout bon nombre des problèmes ci-dessus. En particulier, les auteurs ont constaté que certains codecs ne sont pas réencodés et qu'environ 89 % de la représentation binaire de l'appel cible peut être récupérée. Cela est vrai pour au moins deux opérateurs européens testés.
Il s’agit d’un taux de réussite étonnamment élevé, et franchement bien supérieur à ce à quoi je m’attendais lorsque j’ai commencé à travailler sur ce document.
Alors que pouvons-nous faire pour y remédier ?
La réponse immédiate à cette question est très simple : puisque l'essence de la vulnérabilité est une attaque de réutilisation (réinstallation) de clé, résolvez simplement le problème. Assurez-vous qu'une nouvelle clé est obtenue pour chaque appel téléphonique et ne laissez jamais le compteur de paquets remettre le compteur à zéro en utilisant la même clé. Problème résolu!
Ou peut être pas. Cela nécessitera la mise à niveau de nombreux équipements et, franchement, un tel correctif en soi n'est pas extrêmement fiable. Ce serait bien si les normes pouvaient trouver un moyen plus sûr d'implémenter leurs modes de chiffrement qui ne soit pas, par défaut, vulnérable de manière catastrophique à de tels problèmes de réutilisation des clés.
Une option possible consiste à utiliser . Cela peut être trop cher pour certains matériels actuels, mais c'est certainement un domaine auquel les concepteurs devraient réfléchir à l'avenir, d'autant plus que les normes 5G sont sur le point de conquérir le monde.
Cette nouvelle étude soulève également la question générale de savoir pourquoi , dont beaucoup utilisent des conceptions et des protocoles très similaires. Lorsque vous êtes confronté au problème de la réinstallation de la même clé sur plusieurs protocoles largement utilisés comme WPA2, ne pensez-vous pas qu'il est peut-être temps de rendre vos spécifications et vos procédures de test plus robustes ? Arrêtez de traiter les responsables de la mise en œuvre des normes comme des partenaires attentionnés et attentifs à vos avertissements. Traitez-les comme des adversaires (involontaires) qui vont inévitablement se tromper.
Ou bien, nous pouvons faire ce que des entreprises comme Facebook et Apple font de plus en plus : faire en sorte que le cryptage des appels vocaux se fasse à un niveau supérieur de la pile réseau OSI, sans dépendre des fabricants d’équipements cellulaires. Nous pourrions même faire pression pour le cryptage de bout en bout des appels vocaux, comme le fait WhatsApp avec Signal et FaceTime, en supposant que le gouvernement américain arrête de le faire. . Ensuite (à l’exception de certaines métadonnées), bon nombre de ces problèmes disparaîtraient tout simplement. Cette solution est particulièrement pertinente dans un monde où .
Ou nous pouvons simplement faire ce que nos enfants ont déjà fait : arrêter de répondre à ces appels vocaux ennuyeux.
Source: habr.com