Itinérance mobile et confiance entre opérateurs

Itinérance mobile et confiance entre opérateurs

L’itinérance mobile fait circuler des abonnés, des identités et des données entre des réseaux qui ne partagent ni administration, ni supervision, ni intérêt opérationnel immédiat. Le compromis central est brutal : l’interconnexion réduit les coûts et étend la couverture, mais elle transforme chaque partenaire accepté en chemin d’attaque potentiel vers le cœur de réseau.

Explication de la marmotte

L’itinérance ressemble à l’accès d’un client à une salle de sport partenaire dans une autre ville : l’établissement d’accueil doit reconnaître son droit d’entrée sans posséder son dossier complet. Cela permet de rester joignable loin de son réseau habituel, mais une erreur de contrôle peut donner accès à la mauvaise personne.

→ Lire l’explication complète de la marmotte

Itinérance mobile : le compromis entre couverture et souveraineté

Un réseau visité doit obtenir du réseau d’origine l’autorisation de servir un abonné, puis appliquer les politiques de facturation, de qualité de service et parfois de restriction réglementaire associées. Dans les architectures 4G (Fourth Generation), le protocole Diameter transporte notamment les échanges d’authentification et de politique. En 5G (Fifth Generation), l’interface N32 relie les fonctions de sécurité de périphérie entre domaines, avec protection applicative et contrôle de message.

La recommandation est nette : considérer l’interconnexion d’itinérance comme une frontière d’exposition équivalente à un accès interentreprises critique, pas comme un lien privé présumé sûr. Un circuit privé, un réseau IPX (IP eXchange) ou une liaison dédiée réduit l’exposition Internet ; il ne rend pas le partenaire digne de confiance par décret. Le câble n’a pas lu le contrat.

Le réseau visité doit être autorisé à demander uniquement les opérations nécessaires à l’itinérance. Une autorisation trop large permet des requêtes de localisation, de modification de profil ou de déclenchement de signalisation hors du contexte attendu. L’identité de l’opérateur émetteur, le type de message, la destination logique, l’état de l’abonné et le pays de rattachement doivent tous participer à la décision de filtrage.

Les accords commerciaux ne remplacent jamais le contrôle technique. Ils définissent qui paie, qui traite un incident et quels niveaux de service sont attendus. Ils ne prouvent ni qu’une requête a été émise par le bon équipement, ni qu’un certificat n’a pas été volé, ni qu’un partenaire compromis n’émettra pas une commande valide en apparence.

Pour les fondations réseau, voir les architectures réseau et les principes d’architecture cyber. L’itinérance ne doit pas devenir un angle mort entre la sécurité télécom et la sécurité d’entreprise, deux silos qui communiquent parfois aussi bien que des modems des années 1990.

Interconnexion SS7, Diameter et N32 : filtrer selon le protocole

SS7 (Signalling System No. 7) reste présent dans les réseaux historiques et les interfaces de transit. Son modèle initial supposait que les réseaux raccordés étaient légitimes et correctement exploités. Cette hypothèse ne résiste pas à une chaîne d’interconnexion mondiale, à la revente de capacité de signalisation ou à la compromission d’un partenaire.

Les attaques connues contre SS7 incluent la récupération de localisation, le détournement de messages courts et le déclenchement de renvois ou de mises à jour frauduleuses. Un filtrage par code d’opération seul est insuffisant : certaines opérations sont nécessaires, mais seulement depuis des plages d’adresses, des identifiants de réseau et des contextes d’itinérance déterminés. Il faut valider la cohérence entre l’origine déclarée, l’adresse source, l’abonné ciblé et la relation commerciale active.

Diameter apporte des mécanismes de transport plus modernes, sans supprimer le problème d’autorisation. Une connexion Transport Layer Security (TLS) authentifiée prouve l’identité du pair technique au moment de l’établissement de session. Elle ne prouve pas que chaque requête transportée est légitime pour chaque abonné. Le proxy Diameter doit appliquer des règles par application, par commande et par domaine de destination, avec refus explicite des extensions non attendues.

En 5G, la fonction SEPP (Security Edge Protection Proxy) protège l’interface N32 entre opérateurs. Elle assure notamment la validation de l’émetteur, la protection cryptographique de parties de message et le masquage de topologie. Elle ne remplace pas l’autorisation métier dans les fonctions du cœur de réseau. Accepter un message correctement protégé mais incohérent avec l’état de l’abonné reste une erreur, juste une erreur chiffrée.

La position à tenir est donc la suivante : migrer vers les mécanismes 5G lorsque l’architecture le permet, mais maintenir une politique de filtrage sémantique indépendante du protocole. Le chiffrement protège le transport. La confiance se gagne requête par requête.

PKI opérateur, certificats et identité des pairs

La PKI (Public Key Infrastructure) d’interconnexion est un système d’autorité, pas un dossier de certificats posé sur un partage réseau. Chaque certificat de passerelle doit être rattaché à un opérateur, à une fonction précise et à une période de validité contrôlée. Une autorité de certification publique peut convenir pour certains usages de transport ; elle est rarement suffisante pour porter seule la relation de confiance métier entre opérateurs.

La chaîne de validation doit imposer trois contrôles : ancrage dans une autorité approuvée, correspondance entre le nom présenté et l’identité attendue, puis présence de l’identité dans le registre des partenaires autorisés. Valider seulement la signature d’un certificat revient à admettre tout détenteur d’un badge émis par le même imprimeur dans une salle technique. Le résultat est créatif, rarement souhaité.

Les clés privées de passerelle doivent résider dans un HSM (Hardware Security Module) ou dans un mécanisme matériel équivalent offrant non-exportabilité, journalisation et contrôle d’accès. Un fichier de clé copié dans une image de machine virtuelle annule largement le bénéfice d’une authentification mutuelle : l’attaquant n’a plus besoin de convaincre la passerelle, il peut la cloner.

La révocation d’un certificat ne ferme pas les sessions déjà établies. Les connexions persistantes doivent donc avoir une durée maximale, être réauthentifiées périodiquement et pouvoir être coupées depuis une liste de blocage opérationnelle. Les listes de révocation et le protocole OCSP (Online Certificate Status Protocol) doivent être testés sous perte de connectivité, car un contrôle de révocation qui échoue en mode permissif est un panneau « entrée libre » avec une police élégante.

Les principes de hiérarchie, de rotation et de vérification de certificats sont détaillés dans PKI et TLS et les contraintes de garde de clés dans les mécanismes cryptographiques.

Exemple : vérifier un certificat d’interconnexion et sa révocation

La vérification suivante contrôle une chaîne de confiance, l’usage serveur et une liste de révocation locale. Elle est reproductible avec OpenSSL (Open Secure Sockets Layer) et doit s’exécuter dans une chaîne d’intégration ou lors de l’import d’un nouveau partenaire, jamais seulement pendant une réunion de validation où tout le monde hoche la tête.

# Vérifier le certificat de la passerelle partenaire.
# partner-ca.pem contient uniquement l'autorité de confiance approuvée.
# partner.crl.pem est la liste de révocation récupérée et validée.
openssl verify \
  -CAfile partner-ca.pem \
  -CRLfile partner.crl.pem \
  -crl_check \
  -purpose sslserver \
  partner-gateway.pem

# Le code de retour doit être 0.
# Toute erreur de chaîne, d'usage ou de révocation bloque l'import.

Cette commande ne valide pas l’autorisation d’itinérance. Elle ne vérifie ni l’identifiant réseau annoncé dans les messages, ni la cohérence de la politique de routage, ni la configuration du proxy. Elle répond à une seule question : ce certificat est-il actuellement acceptable selon la politique cryptographique locale ?

L’autorité racine doit être hors ligne ou isolée, les autorités intermédiaires doivent être limitées par usage, et les certificats de passerelle doivent avoir une durée courte compatible avec l’automatisation de renouvellement. Une rotation manuelle annuelle n’est pas une stratégie : c’est un rendez-vous futur avec une indisponibilité parfaitement planifiée par personne.

Exploitation : journalisation, rotation et reprise

Les journaux doivent permettre de reconstruire une décision d’interconnexion : identité du pair, chaîne de certificats, version de politique, type de message, résultat de filtrage, identité pseudonymisée de l’abonné et corrélation de session. Conserver le contenu complet des messages sans minimisation expose des données de localisation et d’identité ; ne conserver que des compteurs empêche l’investigation. La bonne réponse est une journalisation structurée, pseudonymisée et protégée par contrôle d’accès.

Les alertes prioritaires sont les refus soudains par partenaire, les changements de certificat inattendus, les demandes de localisation hors profil, les écarts entre pays déclaré et origine réseau, les pics de messages rares et les erreurs de validation cryptographique. Une hausse de trafic n’est pas forcément une attaque. Une hausse de trafic accompagnée de commandes anormales mérite moins de philosophie et plus de blocage.

La rotation des clés doit distinguer les clés de transport, les certificats d’identité et les secrets d’administration. Chaque catégorie a son propriétaire, sa procédure d’urgence et sa fenêtre de chevauchement. Réutiliser la même clé pour plusieurs fonctions simplifie l’inventaire pendant exactement le temps nécessaire à une compromission pour devenir transversale.

Le plan de reprise doit prévoir la perte d’un certificat, l’indisponibilité d’une autorité de validation, la corruption d’une politique de filtrage et la rupture d’un partenaire critique. Restaurer une sauvegarde de configuration sans restaurer les versions de listes de confiance et les journaux de changement crée un état techniquement fonctionnel mais non vérifiable. C’est le genre de reprise qui marche jusqu’au premier appel d’astreinte.

🐝 Ce qui arrive si on s’en passe

Sans contrôle technique sur l’interconnexion, la porte de la ruche reste ouverte à quiconque présente un badge d’opérateur. Un partenaire compromis ou un revendeur de capacité de signalisation devient un point d’entrée direct vers le cœur de réseau : requêtes de localisation émises hors contexte d’itinérance, modifications de profil acceptées parce que la session TLS était authentifiée, messages courts redirigés sans qu’aucune règle ne compare l’origine déclarée à l’adresse source. Les conséquences dépassent l’opérateur : les codes d’authentification à usage unique transitant par SMS deviennent interceptables, ce qui fragilise des services tiers qui n’ont jamais signé d’accord d’interconnexion. Côté exploitation, l’absence de journalisation structurée et pseudonymisée empêche de dire après coup quel pair a demandé quoi, pour quel abonné, sous quelle version de politique. La reprise se fait alors à l’aveugle, sur une configuration restaurée mais invérifiable.

🦫 Explication de la marmotte 🍫

Quand un téléphone se connecte à un réseau mobile qui n’est pas celui de son abonnement, le réseau d’accueil doit demander au réseau d’origine si la personne a le droit d’utiliser le service. Le réseau d’origine fournit les informations nécessaires pour reconnaître l’abonné et appliquer ses règles, par exemple l’accès aux appels, aux messages ou aux données.

Ces échanges passent entre des équipements exploités par des entreprises différentes. Chaque côté doit donc vérifier l’identité de l’autre avant d’accepter une demande. Des certificats numériques servent à prouver cette identité. Ils sont signés par une autorité reconnue et doivent être encore valides. Si un certificat est volé ou retiré, il faut empêcher son utilisation et fermer les connexions déjà ouvertes si nécessaire.

Le réseau d’accueil ne doit pas accepter toute demande venant d’un partenaire reconnu. Il vérifie aussi le type de demande, la destination, le pays annoncé et la situation de l’abonné. Sans ces contrôles, un opérateur compromis pourrait demander une localisation, détourner des messages ou modifier un service.

Les échanges et les refus sont enregistrés pour repérer les anomalies et enquêter après un incident. Les clés secrètes doivent être protégées dans du matériel dédié, renouvelées régulièrement et sauvegardées avec leurs règles de contrôle. Si un partenaire, un certificat ou une liaison tombe en panne, des règles préparées à l’avance doivent limiter le service concerné sans ouvrir tout le réseau.

À lire aussi

• Sécuriser la signalisation ferroviaire connectéeArchitecture de sécurité pour la signalisation et les systèmes de contrôle ferroviaires connectés.
• OCSP stapling pour vérifier la révocation TLSOCSP stapling permet de fournir au client un statut de révocation de certificat sans requête supplémentaire vers l'autorité de certification.
• Accès hertziens, mobiles, satellites et small cellsComprendre les réseaux d’accès hertziens et mobiles : générations cellulaires, satellites, small cells, backhaul, handover et architectures mobiles modernes.
• Sécuriser la traçabilité RFID et IoT du fretSécuriser les chaînes d'approvisionnement logistique connectées, de la traçabilité RFID aux objets IoT de suivi de fret.

Pages voisines

La citent

• Accès hertziens, mobiles, satellites et small cells
• Brouillage et leurrage GNSS, détection, OSNMA et repli du temps
• Wi-Fi d’entreprise et sécurité radio

Itinérance mobile et confiance entre opérateurs

Elle cite

• CRL ou OCSP pour révoquer un certificat
• Cycle de vie d'une autorité de certification intermédiaire
• Déployer FIDO2 pour comptes à privilèges