Interception passive et décodage de flux GSM avec gr-gsm

Ce qu’on appelle GSM (pour Global System for mobile Communications) correspond aux normes encadrant la téléphonie mobile sur la bande des 900 Mhz. Elles datent des années 1980 et n’ont pas ou très peu évolué depuis. En décembre 2009, Karsten Nohl, avec quelques autres membres du Chaos Computer Club, a réussi à casser le système de chiffrement GSM : A5/1 [1]. L’attaque permet de décrypter en quasi temps réel les communications. À l’époque, la GSM Association, en charge de la norme, indiquait que cela ne posait pas particulièrement de problème dans la mesure où l’interception ou la capture et le décodage des signaux radio restaient complexes. Aujourd’hui, avec les possibilités offertes par la radio logicielle (Software Defined Radio : SDR), cela n’est plus le cas.

1. Matériel

En 2010, pour capturer les signaux GSM, Karsten Nohl utilisait une radio programmable de Ettus Research [2]. Ce genre de matériel coûtait plus de 1500 €. Aujourd’hui, une simple clé USB TNT DVB-T peut suffire. On en trouve à moins de 10 euros sur eBay. Il faut seulement qu’elle soit basée sur une puce Realtech RTL2832U [3]. Le tuner qui équipe la clé USB TNT DVB-T est également important. C’est lui qui définit la gamme de fréquences. Pour la SDR, on considère que celles qui ont un tuner Elonics E4000 sont les meilleures parce que ce tuner propose la plus grande gamme de fréquences, mais Elonics n’en fabrique plus. Elles sont, de ce fait, rares et plus chères.

Tuner	Gamme de fréquences
Elonics E4000	65 MHz à 2,2 GHz (trou de 1100 MHz à 1250 MHz)
Rafael Micro R820T	24 MHz à 1766 MHz
Rafael Micro R828D	24 MHz à 1766 MHz
Fitipower FC0013	22 MHz à 1100 MHz
Fitipower FC0012	22 MHz à 948,6 MHz

Comme le montre le tableau ci-dessus, ces clés USB TNT DVB-T peuvent également servir à intercepter d’autres bandes de fréquences. Les bandes des 433 Mhz et 868 Mhz, libres selon la règlementation européenne, sont particulièrement utilisées pour des applications sans fils. On peut notamment citer les portes de garage ou les volets roulants.

Pour le GSM, même s’il offre une gamme de fréquences sensiblement moins importante que l’Elonics E4000, le Rafael Micro R820T est recommandé. En effet, il est moins cher et réputé mieux fonctionner pour les fréquences supérieures à 450 MHz, ce qui est le cas du GSM.

Il ne s’agit pas de matériel haut de gamme et prévu pour la SDR, mais tous les tuners présentés dans le tableau ci-dessus, couplés au démodulateur Realtech RTL2832U fonctionnent normalement très bien pour intercepter des flux GSM.

La fréquence d’échantillonnage maximale de ces clés USB TNT est théoriquement de 3,2 MHz. Mais à cette fréquence, la faible qualité de certaines clés risque d’engendrer des pertes. Ainsi pour éviter cela, il est recommandé de ne pas dépasser 2,4 MHz.

Il est aussi possible d’utiliser du matériel plus avancé et surtout dédié à la SDR, mais forcément plus onéreux. Il s’agit notamment du boîtier HackFR One de Great Scott Gadgets [4] ou de la carte bladeRF de Nuand [5],ou encore des produits Airspy [6] ou SRDplay [7].

2. Rappels sur les communications GSM

Dans le cadre de la téléphonie mobile, les équipements des utilisateurs du réseau sont appelés Mobile Station (MS) et les équipements en charge de communiquer directement avec les MS sont appelés Base Transceiver Station (BTS).

Les communications GSM se font, en Europe, sur les bandes des 900 MHz et 1800 MHz. Sur la bande des 900 MHz, en fait, elles utilisent les fréquences entre 880 MHz et 915 MHz pour le lien montant, c’est-à-dire de la MS vers la BTS, et les fréquences entre 925 MHz et 960 MHz pour le lien descendant, c’est-à-dire de la BTS vers la MS.

Chacune de ces deux bandes de 35 MHz est divisée en 174 canaux de 200 kHz. Ils sont appelés Absolute Radio-Frequency Channel Number (ARFCN) et, pour la bande des 900 MHz, sont numérotés de 0 à 125 et de 975 à 1023 :

ARFCN	Lien Montant	Lien Descendant
975	880,2 MHz	925,2 MHz
976	880,4 MHz	925,4 MHz
977	880,6 MHz	925,6 MHz
...
1021	889,4 MHz	934,4 MHz
1022	889,6 MHz	934,6 MHz
1023	889,8 MHz	934,8 MHz
0	890 MHz	935 MHz
1	890,2 MHz	935,2 MHz
2	890,4 MHz	935,4 MHz
...
122	914,4 MHz	959,4 MHz
123	914,6 MHz	959,6 MHz
124	914,8 MHz	959,8 MHz

Les autres ARFCN (entre 125 et 974) ne sont pas utilisées ou sont utilisées sur d’autres bandes de fréquences (GSM 450, GSM 480 et DSC 1800).

Les 174 canaux comportent chacun huit time slots (TS) d’environ 577 μs. Ils sont numérotés de zéro à sept. Ce sont ces canaux physiques qui sont utilisés pour transmettre la voix ou la signalisation. Ils contiennent des données appartenant à trois catégories :

• Traffic CHannels (TCHs) :
  • Full rate Traffic CHannel (TCH/F) ;
  • Half rate Traffic CHannel (TCH/H) ;
• Dedicated Control CHannels (DCCHs) :
  • Standalone Dedicated Control CHannel (SDCCH) ;
  • Fast Associated Control CHannel (FACCH) ;
  • Slow Associated Control CHannel (SACCH) ;
• Common Control CHannels (CCCHs) :
  • Broadcast Control CHannel (BCCH) ;
  • Access Grant CHannel (AGCH) ;
  • Random Access CHannel (RACH) ;
  • Paging CHannel (PCH) ;
  • Synchronization CHannel (SCH) ;
  • Frequency Correction CHannel (FCCH).

Les TCHs sont des canaux point à point. Ils sont l’équivalent du canal B du RNIS. Ils sont utilisés pour transporter la voix ou des données.

Les DCCHs sont également des canaux point à point. Ils sont l’équivalent du canal D du RNIS. Le SDCCH est notamment utilisé pour la mise en place des appels et le transfert de SMS. Les FACCH et SACCH sont essentiellement utilisés pour la signalisation pendant les appels.

Les CCCHs sont des canaux de diffusion et point à point. Ils n’ont pas d’équivalent RNIS. Ils sont utilisés quasiment exclusivement pour gérer l’aspect radio. Le BCCH est utilisé par la BTS pour diffuser des informations sur le réseau. Le RACH est utilisé par les MS pour demander un canal à la BTS. Le AGCH est utilisé pour la BTS pour répondre aux demandes faites via le RACH. Le PCH est le canal par lequel la MS est informée qu’elle reçoit un appel.

La figure ci-dessous reprend une partie de ces informations sous forme schématique.

Afin de garantir la confidentialité des communications, ces dernières sont normalement chiffrées. L’A5/1, développé en 1987, est censé remplir ce rôle. En 2009, il a été cassé en utilisant des ressources accessibles à tous. En 1989, l’A5/2 a été développé pour les pays où la loi ne permettait pas d’utiliser l’A5/1. Du fait de sa faiblesse, il n’est pas utilisé. Publié en 1999, l’A5/3, utilisé pour les communications 3G, est censé remplacer l’A5/1. Bien que des attaques théoriques sur l’A5/3 existent, en pratique, elles ne sont pas significatives. Dans les faits, en France, l’A5/1 reste très majoritaire [8].

3. Présentation des outils de gr-gsm

Gr-gsm [9] est un projet libre développé depuis février 2014 par Piotr Krysik. Il utilise GNU Radio et est basé sur une partie du projet Airprobe : le gsm-receiver, également développé par Piotr Krysik. Gr-gsm fournit notamment des outils permettant de recevoir, décoder et déchiffrer des flux GSM.

Il est composé des cinq programmes suivants :

• grgsm_scanner ;
• grgsm_livemon ;
• grgsm_channelize.py ;
• grgsm_capture.py ;
• grgsm_decode.

Grgsm_capture.py et grgsm_decode ne sont pas traités dans ce paragraphe. Ils seront abordés dans les paragraphes suivants. Cependant, leurs noms sont plutôt explicites. Grgsm_capture.py permet de capturer les signaux et de les stocker dans un fichier afin de les analyser par la suite avec grgsm_decode.

3.1 grgsm_scanner

Grgsm_scanner est un outil en ligne de commandes qui permet de scanner, entre autres, la bande GSM. Il affiche les informations des BTS environnantes. Il peut prendre des arguments, mais fonctionne très bien sans. Voici un exemple des informations qu’il peut afficher :

Le Location Area Code (LAC) permet de grouper des cellules appartenant à une même zone, afin d’optimiser la signalisation. Le Mobile Country Code (MCC) correspond au code du pays. En France, il a toujours la valeur 208. Le Mobile Network Code (MNC) permet d’identifier le réseau d’un opérateur. Sur la bande GSM, Orange utilise les MNCs 1 et 2, SFR utilise les MNCs 10 et 13, Free utilise le MNC 15 et Bouygues Telecom utilise les MNCs 20 et 88.

Sur l’exemple ci-dessus, on constate que l’on capte des signaux de six cellules : trois cellules Orange (MNC 1) et trois cellules SFR (NMC 10).

Les cellules Orange utilisent les fréquences à 935,2MHz (ARFCN 1), à 936,6 MHz (ARFCN 8) et à 938 MHz (ARFCN 15). Elles partagent le même LAC et ont chacune un identifiant unique (CID).

Les cellules SFR utilisent les fréquences à 951 MHz (ARFCN 80), 952 MHz (ARFCN 85) et 959,2 MHz (ARFCN 121). De la même manière que pour les cellules Orange, elles partagent le même LAC et ont chacune un identifiant unique (CID).

On remarque que grgsm_scanner indique également la puissance du signal reçu pour chaque cellule. Normalement la MS se connecte à la cellule qu’il capte le mieux, c’est-à-dire celle dont la puissance du signal est la plus importante. Dans ce cas, pour un abonné Orange, elle se connectera sur la cellule 64988 et sur la cellule 24843 pour un abonné SFR.

Les arguments qu’il est possible de fournir à grgsm_scanner sont les suivants :

• la fréquence d’échantillonnage avec -s ou --samp-rate=. La valeur par défaut est 2000000.
• une correction de fréquence avec -p ou --ppm=. La valeur par défaut est zéro. Elle permet de pallier des défauts matériels du récepteur.
• le gain avec -g ou --gain=. La valeur par défaut est 24. Il peut être utile d’augmenter cette valeur en cas de mauvaise réception du signal.
• la vitesse à laquelle le logiciel scanne avec --speed= entre zéro et cinq. La valeur par défaut est quatre. Zéro correspond à la vitesse la plus lente et cinq à la plus rapide.

Avec -v, on obtient des informations supplémentaires, notamment la configuration CCCH, les ARFCNs de la cellule et des cellules environnantes.

Cet outil va donc permettre de savoir quelles ARFCNs ou fréquences sont utilisées par les BTS environnantes et ainsi de savoir quelle(s) fréquence(s) il est utile de tenter de capturer.

3.2 grgsm_livemon

Grgsm_livemon est un outil graphique qui permet de surveiller en temps réel les données transmises sur une fréquence donnée. La surveillance peut s’effectuer simplement dans la console qui a lancé le programme, mais elle peut également s’effectuer avec wireshark [10]. En effet, grgsm_livemon, envoie les données au format GSMTAP sur l’interface loopback sur le port UDP 4729. Ainsi, pour effectuer la surveillance avec wireshark, avant d’exécuter grgsm_livemon, on l’exécute avec la commande suivante :

Cette commande exécute wireshark avec les droits root (avec sudo), en lançant immédiatement la capture (avec -k) sur l’interface loopback (avec -i lo). De plus, on active un filtre de capture sur les paquets udp (avec -f udp) et un filtre d’affichage sur les paquets de type GSMTAP (avec -Y gsmtap). Le & à la fin de la commande permet simplement de garder la main sur le shell.

Une fois cette commande lancée, on peut exécuter grgsm_livemon et choisir graphiquement la fréquence qui nous intéresse. La capture ci-dessous montre ce que cela peut donner.

De la même manière que pour grgsm_scanner, il est possible de spécifier la fréquence d’échantillonnage (avec -s ou --samp-rate=), une correction de fréquence (avec -p ou –ppm=) et le gain (avec -g ou --gain=). La valeur par défaut du gain n’est pas la même que pour grgsm_scanner, elle est fixée à 30 pour grgsm_livemon. On peut également spécifier la fréquence avec laquelle le logiciel démarre avec -f ou --fc=. Il est à noter que la fréquence s’écrit en notation scientifique, c’est-à-dire avec « e » pour l’exprimer en puissance de dix. Par exemple, pour la fréquence 951 MHz, on noterait 951e6.

Cet outil va donc permettre de vérifier que des données transitent bien sur la fréquence que l’on souhaite tenter de capturer.

3.3 grgsm_channelize.py

Grgsm_channelize.py est un outil en ligne de commandes. Il est surtout utile lorsqu’une communication vocale utilise des sauts de fréquence. Il permet de séparer une capture à large bande en plusieurs fichiers contenant chacun une ARFCN. Par exemple, la commande suivante va générer deux fichiers, un pour l’ARFCN 80 et un pour l’ARFCN 85, à partir d’une capture centrée sur la fréquence 951.5 MHz et dont la fréquence échantillonnage est de 2 MHz.

À l’issue de cette commande, on constate que deux nouveaux fichiers ont bien été créés avec une fréquence échantillonnage divisée par deux. Il est ensuite possible de les décoder avec grgsm_decode, ce qui n’était pas le cas avec la capture originale.

4. Capture

La capture s’effectue avec grgsm_capture.py. Il s’agit d’un outil en ligne de commandes. Il ne nécessite que deux arguments : la fréquence ou l’ARFCN et un fichier de sortie.

On spécifie la fréquence avec -f ou --fc=. De la même manière que pour grgsm_livemon, la fréquence s’exprime en puissance de dix. Pour utiliser un ARFCN plutôt que la fréquence, on utilise -a ou --arfcn=. Il est à noter que, dans ce cas, la fréquence du lien descendant sera sélectionnée.

Le fichier de sortie peut être écrit dans deux formats, soit sous forme de burst avec -b ou --burst-file=, soit sous forme d’un fichier ne contenant que les données avec -c ou --cfile=. Il est possible d’utiliser l’un ou l’autre ou les deux en même temps. Grgsm_decode peut décoder ces deux types de fichiers.

De la même manière que pour grgsm_scanner et grgsm_livemon, il est possible de spécifier la fréquence d’échantillonnage (avec -s ou --samp-rate=), une correction de fréquence (avec -p ou --ppm=) et le gain (avec -g ou --gain=). Le fait d’augmenter la fréquence d’échantillonnage permet d’augmenter la largeur de la bande capturée pour éventuellement ensuite utiliser grgsm_channelize.py. De plus, il est possible de spécifier la durée de la capture en seconde avec -T ou --rec-length=.

5. Décodage

Le décodage de la capture s’effectue avec grgsm_decode. Il s’agit d’un outil en ligne de commandes. Au départ, il ne nécessite que deux arguments : la fréquence (avec -f ou --fc=) ou l’ARFCN (avec -a ou --arfcn=), et un fichier de capture (avec -b ou --burst-file,ou -c ou --cfile=). Par défaut, il n’affiche rien.

Mais, de la même manière que grgsm_livemon, il envoie les données au format GSMTAP sur l’interface loopback sur le port UDP 4729. Ainsi, pour visualiser les données, avant d’exécuter grgsm_decode, on exécute wireshark avec la commande suivante :

5.1 Décodage d’un SMS

Après avoir exécuté wireshark en fond, on peut exécuter grgsm_decode. Par exemple, pour une capture réalisée sur la fréquence 936 MHz (ARFCN 5), on exécute l’une ou l’autre des deux commandes présentées ci-dessus.

Dans wireshark, on obtient essentiellement des paquets (RR) Paging Request Type 1 parmi lesquels il faut trouver un paquet (RR) Immediate Assignement (cf. filtre de la capture figure 3). Cela va permettre de trouver le time slot du SDCCH dans les paquets qui contiennent un Channel Description. La capture suivante montre que, dans notre cas, il s’agit d’un SDCCH/8 sur le time slot 1.

À partir de là, on relance wireshark et grgsm_decode en lui spécifiant que l’on souhaite décoder du SDCCH/8, sur le time slot 1.

Dans wireshark, il faut trouver un paquet (RR) Ciphering Mode Command (cf. filtre de la capture figure 4). Cela permet de déterminer le mode de chiffrement (A5/1 ou A5/3) dans Cipher Mode Setting. S’il s’agit d’A5/3, bien que grgsm_decode le prenne en charge, comme il n’est pas possible de le casser, on ne pourra pas lire le contenu du SMS sans connaître la clé. En revanche, s’il s’agit d’A5/1, on peut casser la clé avec kraken [12] et on pourra lire le contenu du SMS. La capture suivante montre que, dans notre cas, il s’agit d’A5/1 :

Après avoir obtenu la clé, on relance une nouvelle fois wireshark et grgsm_decode en ajoutant le mode de chiffrement et la clé.

Dans wireshark, en recherchant un paquet (SMS) CP-DATA (cf. filtre de la capture figure 5), on peut lire le SMS en dépliant TP-User-Data. La capture suivante montre un SMS contenant un code 2FA du manager OVH :

Comme indiqué dans la note en début de paragraphe 5, il n’est actuellement pas possible de décoder le lien montant seul avec grgsm_decode. Mais, on peut noter que, lorsque que la MS envoie un SMS, sur le lien descendant la BTS en accuse réception avec un paquet (SMS) CP-ACK.

5.2 Décodage d’un appel

Le début du processus est le même que pour un SMS. On commence par rechercher un paquet (RR) Immediate Assignement. Cela permet de trouver le time slot du SDCCH puis le mode de chiffrement et la clé.

Dans wireshark en recherchant un paquet (RR) Assignement Command (cf. filtre de la capture figure 6), on obtient tous les éléments permettant d’extraire la voix. Il s’agit du type du Traffic CHannel, son time slot et le codec. Dans la capture ci-dessus, on constate qu’il s’agit d’un TCH/F utilisant un codec GSM-FR, sur le time slot 5.

Pour extraire la communication descendante, on relance grgsm_decode en lui spécifiant que l’on souhaite décoder du TCH/F, sur le timeslot 5. De plus, on lui indique le codec et un fichier de sortie :

Si wireshark est lancé, dans ce dernier, on remarque qu’on obtient, entre autres, un paquet (CC) Connect Acknowledge, marquant le début de l’appel.

Au final, on obtient un fichier audio au format GSM-FR lisible avec VLC ou tout autre lecteur audio prenant en charge le codec.

Conclusion

Il est peu onéreux et plutôt simple d’intercepter passivement et de décoder des flux GSM. Pour cela, comme on l’a vu dans les paragraphes quatre et cinq, il faut, d’une part, être capable de capturer toutes les données pertinentes et, d’autre part, pouvoir les décoder et les décrypter.

Afin de compliquer la capture, les opérateurs peuvent mettre en place des sauts de fréquence et des séquences de sauts peu prédictibles. Pour empêcher le déchiffrement des données, ils mettent progressivement en place le chiffrement A5/3, pour lequel aucune attaque pratique n’existe à l’heure actuelle.

Dans ce dernier cas, une interception passive n’est plus possible et les attaques se doivent d’être actives, c’est-à-dire qu’il faut mettre en place une fausse BTS à laquelle les MS cibles vont se connecter. Cette dernière servira de proxy entre les MS et la BTS de l’opérateur. On appelle cela un IMSI-catcher. Il est possible d’en fabriquer un avec le matériel dédié à la SDR présenté en fin de paragraphe un et des logiciels libres.

Les possibilités offertes par la SDR en terme de capture et la facilité de décodage des données avec gr-gsm, en particulier pour les SMS, permettent de dire que depuis quelques années, la téléphonie mobile est compromise. Ainsi, bien qu’un bon nombre d’acteurs de l’Internet l’utilisent comme deuxième facteur d’authentification, ou dans leurs procédures de récupération du mot de passe, aujourd’hui, elle ne devrait plus être considérée comme un canal de communication sécurisé.

Références

[1] Karsten Nohl, « Breaking GSM phone privacy », Blackhat 2010,
https://srlabs.de/wp-content/uploads/2010/07/100729.Breaking.GSM_.Privacy.BlackHat1-1.pdf et
https://www.youtube.com/watch?v=0hjn-BP8nro

[2] https://www.ettus.com

[3] http://www.realtek.com/products/productsView.aspx?Langid=1&PFid=35&Level=4&Conn=3&ProdID=257

[4] https://greatscottgadgets.com/hackrf/

[5] https://www.nuand.com

[6] http://airspy.com

[7] http://www.sdrplay.com

[8] Security Research Labs, « Mobile network security report: France », juin 2017,
https://gsmmap.org/assets/pdfs/gsmmap.org-country_report-France-2017-06.pdf

[9] https://github.com/ptrkrysik/gr-gsm

[10] https://www.wireshark.org

[11] https://ptrkrysik.github.io/

[12] https://opensource.srlabs.de/projects/a51-decrypt