Sécurité 5G : pourquoi l'IMSI catcher ne fonctionne plus (SUPI, SUC...

En 2019, un journaliste d’investigation couvrant un sommet politique reçoit un appel de son rédacteur en chef. Il est sur écoute. Pas par un service de renseignement étatique disposant d’un mandat judiciaire, mais par un acteur privé utilisant un équipement disponible pour quelques milliers d’euros sur le marché gris. L’appareil en question : un IMSI catcher. Une fausse station de base qui se fait passer pour une antenne légitime, force le téléphone à s’identifier, et capture son IMSI — l’identifiant permanent de l’abonné — en clair, avant même que la première donnée ne soit échangée.

Ce scénario n’est pas hypothétique. Les IMSI catchers sont documentés dans des dizaines d’enquêtes journalistiques, des rapports parlementaires et des procédures judiciaires à travers l’Europe, les Etats-Unis et le Moyen-Orient. Ils sont utilisés par les forces de l’ordre, mais aussi par des acteurs malveillants pour le tracking de cibles, l’interception de communications et la surveillance de masse lors de manifestations.

La 5G Standalone a été conçue pour rendre cette attaque structurellement impossible. Pas par un patch logiciel ou une mise à jour de configuration, mais par une refonte architecturale de la gestion des identités. Voici comment, et pourquoi le chemin n’est pas encore terminé.

L’évolution de la sécurité des identités par génération mobile

Chaque génération de réseau mobile a apporté des améliorations en matière d’authentification et de protection de l’identité de l’abonné. Mais chaque génération a aussi conservé des failles héritées ou introduit de nouvelles surfaces d’attaque.

Génération	Authentification	Identité abonné	Vulnérabilité principale
2G (GSM)	Unidirectionnelle (réseau authentifie le terminal, pas l’inverse)	IMSI transmis en clair	Fausse BTS triviale. Aucune authentification mutuelle. Interception A5/1 démontrée depuis 2009.
3G (UMTS)	Mutuelle (AKA)	IMSI transmis en clair lors du premier attachement, puis TMSI	L’authentification mutuelle protège contre les fausses BTS, mais le fallback 2G annule cette protection. L’IMSI reste exposé à l’attachement initial.
4G (LTE)	Mutuelle (EPS AKA)	IMSI transmis en clair lors de l’Attach Request initial, puis GUTI	L’EPS AKA améliore la dérivation de clés, mais l’Identity Request de type IMSI reste possible. L’IMSI catcher exploite cette fenêtre.
5G SA	Mutuelle (5G AKA / EAP-AKA’)	SUPI jamais transmis en clair. SUCI chiffré via ECIES.	Le SUCI est un identifiant jetable chiffré. L’IMSI catcher ne voit qu’un blob cryptographique inutilisable.

Le point critique : en 2G, 3G et 4G, il existe toujours un moment où le terminal transmet son identifiant permanent en clair sur l’interface radio. En 5G SA, ce moment n’existe plus.

Comment fonctionne un IMSI catcher

Le principe d’un IMSI catcher repose sur trois étapes :

1. Usurpation de l’identité réseau. L’IMSI catcher émet un signal plus puissant que les stations de base légitimes environnantes, sur les fréquences de l’opérateur cible. Le terminal mobile, conformément aux spécifications 3GPP, sélectionne la cellule offrant le meilleur niveau de signal (critère S et R de sélection/re-sélection de cellule).

2. Demande d’identité. Une fois le terminal attaché à la fausse station, l’IMSI catcher envoie un message NAS Identity Request avec le type d’identité IMSI. En 4G, le terminal est tenu de répondre avec son IMSI dans un message Identity Response, en clair, sans vérification préalable de l’authenticité du réseau pour cette procédure spécifique.

3. Collecte et tracking. L’IMSI capturé (format : MCC + MNC + MSIN, soit 15 chiffres) identifie de manière unique l’abonné. L’attaquant peut alors suivre les déplacements du terminal (en triangulant avec plusieurs IMSI catchers), corréler l’identité réseau avec une identité physique, ou réaliser des attaques de type man-in-the-middle sur les communications.

En 4G, même si l’authentification mutuelle EPS AKA est en place, la procédure Identity Request de type IMSI est une fonctionnalité légitime du protocole NAS. Elle est prévue par les spécifications 3GPP TS 24.301 pour les cas où le MME ne dispose pas du GUTI du terminal (premier attachement, perte de contexte, etc.). L’IMSI catcher exploite cette fonctionnalité spécifiée, pas un bug d’implémentation.

SUPI : le successeur de l’IMSI en 5G

Le SUPI (Subscription Permanent Identifier) est l’identifiant permanent de l’abonné dans l’architecture 5G, défini dans la spécification 3GPP TS 23.003. Sa structure est identique à celle de l’IMSI :

MCC (Mobile Country Code) : 3 chiffres identifiant le pays (ex. : 208 pour la France)
MNC (Mobile Network Code) : 2 ou 3 chiffres identifiant l’opérateur (ex. : 01 pour Orange France)
MSIN (Mobile Subscriber Identification Number) : jusqu’à 10 chiffres identifiant l’abonné de manière unique au sein du réseau

Le SUPI peut aussi prendre la forme d’un NAI (Network Access Identifier) pour les abonnés non-3GPP (accès WiFi, satellite, etc.).

La différence fondamentale avec l’IMSI : le SUPI n’est jamais transmis en clair sur l’interface radio. Il est stocké dans l’USIM et dans l’UDM (Unified Data Management) du réseau coeur, mais il ne traverse jamais l’interface air sous forme lisible.

SUCI : le chiffrement de l’identité par ECIES

Pour transmettre son identité au réseau, le terminal 5G génère un SUCI (Subscription Concealed Identifier). Le SUCI est le résultat du chiffrement du MSIN contenu dans le SUPI, en utilisant le schéma cryptographique ECIES (Elliptic Curve Integrated Encryption Scheme), tel que défini dans 3GPP TS 33.501.

Le processus de génération du SUCI se déroule dans l’USIM du terminal :

1. Clé publique de l’opérateur. Lors du provisionnement de la carte USIM, l’opérateur y inscrit sa clé publique ECIES (basée sur les courbes Profile A : X25519 ou Profile B : secp256r1). Cette clé publique est stockée de manière permanente dans la carte.

2. Génération d’une clé éphémère. A chaque procédure d’enregistrement, l’USIM génère une nouvelle paire de clés éphémères. La clé privée éphémère est combinée avec la clé publique de l’opérateur via un échange Diffie-Hellman sur courbe elliptique pour produire une clé de chiffrement partagée unique et jetable.

3. Chiffrement du MSIN. Le MSIN est chiffré avec cette clé partagée. Le SUCI résultant contient : le MCC, le MNC (en clair, pour le routage réseau), la clé publique éphémère du terminal, et le MSIN chiffré.

4. Transmission. Le SUCI est envoyé dans le message NAS Registration Request. Les éléments en clair (MCC+MNC) permettent au réseau de router la demande vers le bon opérateur. Le MSIN chiffré garantit que l’identité unique de l’abonné reste protégée.

Le résultat : même si un IMSI catcher intercepte le SUCI, il ne voit que le MCC+MNC (qui identifient l’opérateur, pas l’abonné) et un blob cryptographique qui change à chaque tentative d’enregistrement. Sans la clé privée de l’opérateur (stockée dans l’UDM), le MSIN est irrécupérable.

Le flux 5G AKA : authentification et déchiffrement

Le déchiffrement du SUCI et l’authentification mutuelle s’inscrivent dans le protocole 5G AKA (Authentication and Key Agreement), défini dans 3GPP TS 33.501. Trois fonctions du coeur 5G interviennent :

SEAF (Security Anchor Function) — colocalisée avec l’AMF. Elle reçoit le SUCI du terminal et initie la procédure d’authentification en contactant l’AUSF.

AUSF (Authentication Server Function) — vérifie l’authentification. Elle transmet le SUCI à l’UDM pour déchiffrement et génération des vecteurs d’authentification.

UDM (Unified Data Management) — détient la clé privée ECIES de l’opérateur. C’est la seule entité capable de déchiffrer le SUCI pour retrouver le SUPI. L’UDM génère les vecteurs d’authentification (RAND, AUTN, XRES*, KAUSF) via son module SIDF (Subscription Identifier De-concealing Function) et ARPF (Authentication credential Repository and Processing Function).

Le flux simplifié :

Le terminal envoie un Registration Request contenant le SUCI a l’AMF/SEAF.
L’AMF/SEAF transmet le SUCI a l’AUSF (message Nausf_UEAuthentication_Authenticate).
L’AUSF transmet le SUCI a l’UDM (message Nudm_UEAuthentication_Get).
Le SIDF de l’UDM déchiffre le SUCI en SUPI, puis l’ARPF génère les vecteurs d’authentification.
L’UDM retourne les vecteurs a l’AUSF, qui les transmet a l’AMF/SEAF.
L’AMF/SEAF envoie un Authentication Request au terminal (contenant RAND et AUTN).
Le terminal vérifie AUTN (authentification du réseau), calcule RES* et le retourne.
L’AUSF vérifie RES* contre XRES* (authentification du terminal).
L’authentification mutuelle est complète. Les clés de session sont dérivées.

A aucun moment le SUPI ne circule sur l’interface radio. L’authentification est mutuelle : le terminal vérifie l’authenticité du réseau (via AUTN), et le réseau vérifie l’authenticité du terminal (via RES*/XRES*). Un IMSI catcher ne peut pas fournir un AUTN valide car il ne dispose pas des clés stockées dans l’UDM.

La faille persistante : la 5G NSA

La 5G NSA (Non-Standalone) représente la majorité des déploiements 5G commerciaux en 2026. Elle utilise la radio 5G NR pour le plan utilisateur, mais conserve le coeur réseau 4G (EPC) pour le plan de contrôle et la signalisation initiale.

C’est un problème de sécurité fondamental : en 5G NSA, la procédure d’attachement passe par le MME 4G, pas par l’AMF 5G. Le terminal s’enregistre via une procédure EPS Attach, qui utilise l’architecture de sécurité 4G. L’IMSI est transmis lors de l’Attach Request initial exactement comme en LTE pur.

Les conséquences sont directes :

Pas de SUCI. Le chiffrement ECIES de l’identité n’existe que dans l’architecture 5GC (coeur 5G SA). Le coeur 4G ne gère pas le SUCI.
Pas de 5G AKA. L’authentification repose sur EPS AKA, avec les mêmes limitations qu’en LTE.
IMSI catchers opérationnels. Les équipements de surveillance conçus pour la 4G fonctionnent sans modification sur les réseaux 5G NSA.

Pour un opérateur ou une entreprise, la distinction est critique : déployer la radio 5G NR n’améliore pas la protection de l’identité des abonnés si le coeur réseau reste en 4G. Seul le passage au coeur 5G SA active les mécanismes SUPI/SUCI/ECIES.

En Europe, le taux de déploiement 5G SA reste inférieur à 10 % des réseaux commerciaux. Cela signifie que pour plus de 90 % des abonnés 5G européens, l’IMSI catcher reste une menace opérationnelle. Le label “5G” affiché sur le téléphone ne garantit pas la protection de l’identité.

Ce que définit la spécification 3GPP TS 33.501

La spécification 3GPP TS 33.501 (Security architecture and procedures for 5G System) est le document de référence pour l’architecture de sécurité 5G. Les sections pertinentes pour la protection de l’identité :

Section 6.12 : Subscription privacy. Définit le mécanisme SUPI/SUCI et les exigences de chiffrement.
Section 6.1 : Security features. Spécifie que le SUPI ne doit jamais être transmis en clair sur les interfaces radio et de transport.
Annex C : Profils de protection ECIES. Détaille Profile A (X25519 + AES-128-CTR + HMAC-SHA-256) et Profile B (secp256r1 + AES-128-CTR + HMAC-SHA-256).
Section 6.1.3 : 5G AKA et EAP-AKA’. Définit les deux méthodes d’authentification supportées.

La spécification impose que le null-scheme (SUCI = SUPI en clair, scheme ID 0x00) ne soit utilisé que pour les tests en laboratoire et les situations d’urgence. En production, un schéma ECIES est obligatoire.

Implications pour les ingénieurs sécurité et les testeurs terrain

Pour les professionnels de la sécurité réseau et les ingénieurs terrain, la transition IMSI vers SUPI/SUCI implique plusieurs changements pratiques :

Audit de sécurité. Lors d’un audit 5G, vérifier que le réseau utilise effectivement le coeur 5G SA et pas seulement la radio NR sur coeur 4G. Un terminal affichant “5G” peut toujours être vulnérable aux IMSI catchers en configuration NSA. L’analyse des messages NAS sur l’interface radio révèle la procédure utilisée : Registration Request (5G SA) vs Attach Request (4G/NSA).

Analyse de signalisation. Dans les traces L3, le SUCI apparait dans le champ 5GS Mobile Identity du message Registration Request. Le champ contient le type d’identité (SUCI), le schéma de protection (ECIES Profile A ou B), et le MSIN chiffré. Si le type d’identité indique un null-scheme en environnement de production, c’est une alerte de sécurité critique.

Tests de conformité. Les tests de conformité 3GPP incluent la vérification du comportement du terminal face à un Identity Request de type SUPI. En 5G SA, le terminal doit refuser de transmettre son SUPI en clair si le réseau le demande via une procédure non conforme.

Sensibilisation opérateur. Pour les opérateurs en phase de migration NSA vers SA, documenter explicitement que la protection SUPI/SUCI n’est pas active tant que le coeur 5G SA n’est pas opérationnel. Les communications marketing mentionnant la “sécurité 5G” en contexte NSA sont techniquement inexactes concernant la protection de l’identité.

Ce qu’il faut retenir

La protection de l’identité de l’abonné en 5G SA n’est pas un ajout de sécurité périphérique. C’est un changement architectural fondamental qui élimine une classe entière d’attaques (IMSI catching, tracking passif, corrélation d’identité) par conception cryptographique. Le chiffrement ECIES du MSIN dans le SUCI, combiné à l’authentification mutuelle 5G AKA et au déchiffrement exclusif par l’UDM, crée un système où l’identité permanente de l’abonné n’est jamais exposée sur l’interface radio.

Mais cette protection n’existe que si le réseau est en 5G SA. Tant que le coeur 4G gère la signalisation, l’IMSI circule en clair, et les IMSI catchers fonctionnent. Pour un ingénieur terrain, la question pertinente n’est pas “le terminal affiche-t-il 5G ?” mais “la procédure d’enregistrement passe-t-elle par un coeur 5G SA ?”

Les termes techniques de cet article (SUPI, SUCI, ECIES, 5G AKA, UDM, AMF, AUSF) sont détaillés dans le glossaire HiCellTek. Pour approfondir la sécurité du network slicing 5G et les obligations NIS2, consultez notre article dédié sur le network slicing et NIS2.

Sécurité 5G : pourquoi l'IMSI catcher ne fonctionne plus (SUPI, SUCI, ECIES)