La sécurité sur les réseaux de mobiles – Part 3

Précédents articles : 

La sécurité sur les réseaux de mobiles – Part 1

La sécurité sur les réseaux de mobiles – Part 2

2. La protocole AKA

II-1) La sécurité sur le réseau 3G :

Le protocole d’authentification GSM n’est pas fiable. D’une part, l’authentification étant unilatérale, le mobile peut s’attacher à un réseau pirate et d’autre part, l’algorithme COMP128 a été cassé en 1997 (figure 3 : attaque Narrow Pipe en 1998) :

Figure 5 : L’algorithme COMP128 [1]

De plus, le réseau pouvant négocier l’algorithme de chiffrement en 2G, il est possible de récupérer en clair les données échangées.

Afin de sécuriser l’attachement du mobile et interdire l’attachement sur un réseau pirate, le protocole AKA (Authentication and Key Agreement) exige une authentification bilatérale.

Le cœur de réseau 3G est identique au cœur de réseau 2G, l’amélioration de la sécurité est apportée au niveau du mobile par l’application USIM sur la carte UICC et d’une mise à jour de la fonction AuC du serveur d’authentification HLR. Pour réaliser l’authentification du réseau, une nouvelle clé AMF (Authentication Management Field) est inscrite dans la carte UICC et dans le HLR.

Le vecteur d’authentification généré par l’AuC contient :

  • l’aléa RAND sur 128 bits ;
  • le résultat d’authentification attendu SRES (32 bits à 128 bits);
  • le sceau d’authentification du réseau opérateur AUTN (128 bits);
  • une clé de chiffrement Ck(128 bits) ;
  • une clé d’intégrité Ik (128 bits).

Le résultat SRES, le sceau AUTN, les clés de chiffrements Ck et Ik sont calculés à partir de l’aléa RAND, de la clé privé symétrique Ki et d’une séquence SQN (figure 6).

Figure 6 : Calcul du vecteur d’authentification 3G

Le vecteur d’authentification est transmis à l’authentificateur VLR ou SGSN. Ce dernier envoie l’aléa RAND et la sceau d’authentification AUTN au mobile, lequel le transfert à la carte UICC.

Le sceau d’authentification est composé de 3 champs qui sont embrouillés par une séquence de 128 bits :

  • une clé d’anonymat Ak (Anonimity Key) sur 48 bits ;
  • la valeur AMF (Authentication Management Field) sur 16 bits ;
  • d’un message de signature d’authentification MAC.

f1 et f2 sont deux fonctions d’authentification. f3, f4 et f5 sont des fonctions de génération de clés (KDF : Key Derivation Function).

Le choix des algorithmes f1, f2, f3, f4 et f5 est spécifique à l’opérateur. Cependant un choix d’algorithmes appelé MILENAGE est proposé par la spécification 3GPP [2] [3].

A partir de sa clé Ki, et de l’aléa, l’application USIM calcule d’abord la clé d’anonymat et récupère ainsi la valeur SQN (par un OU exclusif avec AK et le premier champs AUTN).

Ensuite, le mobile calcule :

  • le message d’authentification XMAC=f1(Ki, AMF, SQN) ;
  • le résultat RES attendu par le cœur de réseau f2(Ki,RAND).

Le résultat RES calculé au niveau de la carte UICC est transmis au mobile qui l’envoie à l’authentificateur. L’authentificateur compare le résultat RES du mobile avec la valeur attendue SRES.

Enfin, la carte UICC vérifie la correspondance entre la signature XMAC calculée avec le champ MAC contenu dans le sceau d’authentification AUTN. Cela permet d’éviter les attaques de type Man In The Middle. Si les valeurs sont identiques, l’application USIM calcule le résultat d’authentification (figure 7).

Figure 7 : Les étapes d’authentification pour la 3G et détection d’une station de base pirate

Ensuite, le mobile dérive les clés de chiffrement Ck et d’intégrité Ik à partir des fonctions f3 et f4.

Alors qu’en 2G le chiffrement et le déchiffrement sont réalisés au niveau de la BTS pour les sessions téléphoniques et au niveau du SGSN pour le trafic IP, en 3G le chiffrement et le déchiffrement s’effectuent au niveau du RNC (Radio Network Controller).

Ainsi, la clé CK doit être transférée du VLR au RNC via la commande security mode command gérée par le protocole RANAP (Radio Access Network Application Part). Ensuite, le RNC active le chiffrement au niveau du mobile via le message RRC security mode command.

Figure 8 : La procédure d’authentification et de chiffrement [5]

La clé Ck est calculée à chaque processus d’authentification. Le chiffrement est réalisé par un ou exclusif entre un bloc de données et un flux de chiffrement. Le flux de chiffrement est calculé à partir de l’algorithme f8 avec comme paramètres :

  • la clé Ck;
  • un compteur COUNT-C sur 32 bits ;
  • l’identité du support radio (BEARER) sur 5 bits ;
  • la direction de transmission (UpLink =0/DownLink =1) ;
  • la longueur du flux de chiffrement (le bloc de donnée à chiffrer).

Figure 9: Le chiffrement des données

L’algorithme f9 est utilisé pour le calcul d’intégrité :

Figure 10 : La signature d’intégrité des données

La valeur FRESH est une variable aléatoire généré par le RNC. La clé IK étant générée lors de l’enregistrement, celle-ci n’est pas modifiée tant que le mobile ne se détache pas. La valeur FRESH permet de modifier régulièrement la signature. Cette valeur est transmise au mobile au cours de la demande de connexion RRC.

D’un point de vue implémentation algorithmique, la valeur FRESH n’est pas réellement aléatoire, elle est souvent prise égale à la valeur du BEARER.

Le compteur COUNT-I protège le récepteur d’une attaque Man In The Middle : le prochain message, le compteur est incrémenté et la signature MAC pour le même message sera différente.

Les algorithmes d’authentification sont connus sous le nom de MILENAGE.

Les algorithmes de chiffrement f8 et f9 sont des algorithmes de KASUMI (déjà utilisé en 2G pour l’algorithme A5/3). Plus récemment, l’algorithme Snow 3G est un algorithme de chiffrement à flot pouvant remplacer l’algorithme KASUMI. L’algorithme SNOW3G est aussi utilisé pour fournir un message d’intégrité MAC (aussi nommé algorithme UIA2).

Figure 11 : Le calcul des clés en 3G

Le chiffrement et l’intégrité sont réalisés par le protocole PDCP au niveau du RNC.

SRVCC – Single Radio Voice Call Continuity – Suite

Nous allons maintenant étudier le mécanisme SRVCC et ses évolutions eSRVCC et rSRVCC en illustrant le concept par une approche pratique.

On suppose que l’UE1 souhaite contacter l’UE2. L’UE1 est sur un réseau 4G, vis à vis du réseau IMS, qui est le réseau home, l’UE1 est dans un réseau visité.

L’UE1 souhaite appeler l’UE2. L’UE1 est compatible avec le mécanisme SRVCC et l’appel est évidemment contrôlé par le réseau IMS. Ainsi, après un échange de signalisation SIP, après avoir construit les bearers, l’appel s’effectue. L’UE1 se déplace dans le réseau visité et s’éloigne du eNB, la puissance reçue s’affaiblit.

  1. L’eNb décide alors de mettre en oeuvre le mécanisme SRVCC en envoyant une requête au MME
  2. A partir de cette requete, le MME transmet la demande au MSC afin que ce dernier alloue les ressources au niveau du domaine CS autrement dit avec le RNC puis le Nb.
  3. Le MSC demande la création d’une connexion avec le SCC AS dans l’objectif de transférer la voix (paquet IP) du réseau LTE vers le réseau 3G donc pour transférer la session du PGW vers le MSC.

SRVCC

A ce stade, pour le mécanisme SRVCC définit dans la R8, la procédure est la suivante :

  • Le SCC demande à l’UE2 de changer la destination de ses messages SIP de l’UE1 vers le MSC.

En parallèle,

  • Le MSC informe le MME de la réservation de ressource dans le domaine CS.

A partir de ce moment, le MME peut demander à l’UE1 de basculer vers le réseau 3G (Handover). Après le Handover, la signalisation SIP est transmise du SCC vers le MSC, le SCC est le point d’ancrage pour la signalisation, et le média pour la voix est envoyé de l’UE2 vers le MSC. L’UE2 est donc le point d’ancrage pour le média.

Or, la modification de l’adresse IP de destination (UE1 vers MSC) pour le média de la voix provoque de nombreuses pertes de paquets et une latence puisque toutes les entités du réseau IMS de l’UE2 et l’UE2 doivent modifier leur chemin de requêtes SIP

En simplifiant la figure avec les entités concernés, le chemin de signalisation et d’appel est représenté par la figure ci-dessous.

SRVCC_fig4

eSRVCC

Le principal défaut  du SRVCC est le suivant : Lorsqu’un HandOver affecte l’UE1 dans son réseau visité (ou en roaming), cela impacte les messages SIP et RTP de l’UE2. Le mécanisme eSRVCC consiste à rajouter des points d’ancrage au niveau du réseau visité de l’UE1 afin que tout handover de l’UE1 soit transparent pour l’UE2.

Ainsi, au niveau du eSRVCC, 2 nouvelles entités ont été rajoutées pour avoir un point d’ancrage dans le réseau visité à savoir :

  • ATCF : Point d’ancrage pour la signalisation
  • ATGW : Point d’ancrage pour le média

SRVCC_fig5

 

 

 

 

 

 

Evolution du réseau pour préparer l’IMS (Partie 5)

Dans le cas de la téléphonie 2G, le réseau mobile était connecté au réseau fixe via une passerelle nommée GMSC

Auparavant Le VLR était connecté au HLR via le réseau en mode paquet X.25, un réseau privé. Le réseau X.25 devrait être définitivement arrêté le 30 juin 2012.

Initialement, le réseau mobile était construit autour des équipements suivants :

La téléphonie mobile de 3ème Génération (UMTS) a évolué en parallèle en suivant dans un premier temps le principe de séparation de la signalisation et du transport des informations. Il s’agit de la Release 4 de la 3GPP (UMTS R4) défini en mars 2001. Le MSC (et le GMSC) sont découpés en 2 entités distinctes : Un serveur traitant de la signalisation et d’un commutateur. On passe ainsi :

  • Au niveau signalisation :
    • D’un MSC en un MSC server
    • D’un GMSC en un GMSC server et un CS-MGW
    • Au niveau transport
      • D’un MSC et d’un GMSC en un CS-MGW (Circuit Switched Media Gateway)

Les Releases 5 et 6 de l’UMTS permettent l’établissement de sessions multimédias. Il s’agit de l’IMS,  un nouveau réseau qui se superpose au CS et au PS.

Dans le réseau mobile :  Le MSC-Server  s’occupe des fonctions de contrôle d’appel. Il commande ainsi le CS-MGW permettant l’établissement, le maintien et la libération de sessions afin d’assurer le trafic (la bande passante) des informations à transmettre et le choix des protocoles sur le CS-MGW : Il est possible de passer une communication en mode circuit sur une interface A vers une communication en IP sur du SCTP. Le MSC-Server contrôle également la mobilité du MSC et de ce fait, il est connecté au VLR.

A l’interface du réseau fixe, afin de permettre l’interconnexion entre le réseau mobile et le réseau fixe, l’équipement MSC-Server se nomme GMSC-Server, indiquant ainsi son rôle de passerelle (G = Gateway ou passerelle). Son rôle est donc identique au MSC-Server, c’est-à-dire il s’occupe des fonctions de contrôle d’appel. Il commande ainsi le CS-MGW permettant l’établissement, le maintien et la libération de sessions. Par contre, il est connecté au HLR pour savoir dans quelle région géographique est situé le mobile (autrement dit dans quel VLR est sauvegardé le profil de l’abonné)

Le CS-MGW est un commutateur et une passerelle de média, il permet de router les communications (Information : Média ou Données) du réseau téléphonique (2G/3G) vers le réseau IP (IP/Ethernet, IP/ATM/SDH, IP/SDH). Il est contrôle par le MSC-Server ou MGSC-Server selon le protocole MEGACO/H.248

Avantage en terme de débit : L’évolution de l’architecture a permis d’optimiser les débits entre les équipements (TRAU : Transcodeur). Initialement, la station mobile encode la voix selon le protocole AMR (Adaptative Multi Rate Codec), avec un débit de 5 à 12 kbit/s. Le MSC utilisait la technologie : TDM, la voix était décodée et re-codée à un débit de 64 kbps (G.711). En utilisant le réseau IP (RTP/UDP/IP), la voix peut être transportée de bout en bout avec le codec AMR sur le backbone IP/ATM.

Evolution du réseau pour préparer l’IMS (Partie 3)

NGN : Architecture à 3 niveaux

Comme décrit précédemment, le  NGN se définit par une architecture réseau en 3 couches : Transport (Réseau), Contrôle et Services avec des interfaces ouvertes et normalisées entre chaque couche.

L’architecture très simplifiée est décrite par le schéma suivant :

Les Gateways sont aussi nommées passerelles, elles permettent l’interconnexion avec les réseaux externes et l’acheminement du trafic.

Les MGW ou MG (Media Gateway) sont situées au niveau du transport des flux média entre le réseau RTC et les réseaux en mode paquets.  Elles ont pour rôle :

  • Le codage et la mise en paquet des flux médias
  • La transmission de ces flux selon le MGC

Les MGW permettent donc de relier les équipements existants (CAS, BTS/BSC) à une couche de transport IP ou ATM. Différentes solutions peuvent être envisagées et gérées : IP/ATM/SDH ou IP/Ethernet ou IP/SDH (Pour aller plus loin, dans le cas de la gestion de flux multimédia, l’ajout de nouveaux mécanismes de QoS avec MPLS, DiffServ ou RSVP ont été nécessaires, mais nous y reviendront dans un autre article).

Bien souvent, la fonction SG Signaling Gateway est aussi implémentée dans la Média Gateway. La SG a pour rôle de convertir la signalisation échangée entre le réseau NGN sans l’interprétée. On parle d’adaptation de la signalisation vers le protocole utilisé (TDM/IP) : Il s’agit du protocole SIGTRAN.

Le MGW est aussi nommée Couche Adaptation et il est sous la responsabilité du SoftSwitch, c’est-à-dire du MGC dans la couche contrôle. Il échange ainsi de la signalisation via le protocole MGCP (ou MEGACO).  Le MGC est l’entité intelligente du réseau.

Le MGC gère :

  • L’échange des messages de signalisation
  • Le traitement des appels (avec les terminaux H.323, SIP, MGCP)
  •  Le choix du MGW, la prise en charge de l’appel, la réservation des ressources