Archives du mot-clef HLR

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

Posté le by - 3 422 vues
2

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

L’intégrité est calculé au niveau de la couche RRC, le chiffrement est réalisé au niveau de la couche RLC (sauf pour le mode transparent ou le chiffrement est réalisé par la couche MAC)

Panne chez SFR – Rappel d’une autre panne en 2012

Posté le by - 4 039 vues
2

Le 6 juillet 2012, Orange était affecté par une panne nationale, l’équioement en défaut avait été identifié : le HLR/HSS  lors de la mise à jour de ce dernier via Alcatel Lucent. Se référer à l’article : http://4glte.over-blog.com/article-panne-chez-orange-107869233.htm

Dans cet article, un ensemble d’hypothèse avait été faite pour lancer des pistes sur les pannes possible.

Aujourd’hui, jeudi 24 juillet, SFR fait façe à une panne nationale, les résultats de l’enquète incrime à nouveau la mise à jour du (d’un?) HLR par Alcatel Lucent,.

On peut alors se poser la question sur les procédures de mises à jour du HLR et pourquoi l’équipe Alcatel-Lucent est prise à défaut 2 ans près sur la mise à jour du HLR, d’autant plus  que chaque HLR dispose d’un système de backup comme solution de secours. C’est ce qui avait d’ailleurs été fait en 2012 par Orange : Le logiciel NG HLR (Lew Generation HLR) avait été mis à jour la veille. Vers 17h30, le réseau a rebasculer sur des bases non mises à jour mais sans effet et pourtant, il s’agissait bien de l’équipement défectueux. Le NG-HLR contient une base de données définissant le type d’abonnement de tous les clients de l’opérateur et qui contient aussi la localisation des abonnés. Ces éléments sont stockés dans la partie Back End du NG-HLR et mise à jour chaque fois qu’un client se déplace dans une nouvelle zone de localisation (LAC). La mémoire de cette base de données était saturée. Pour résoudre ce problème, il a néanmoins fallu d’un grande concertation entre Orange et Alcatal Lucentet un travail remarquable de toutes les équipes.

Malgré l’analogie entre ces deux pannes, est ce la même panne?

Orange avait publié une vidéo didactique présentant la panne : http://www.dailymotion.com/video/xs4bs8_resolution-de-l-incident-reseau-le-deroule-en-details_tech

A priori il y a deux ans la panne touchait tous les abonnés, hors l’opérateur possède plusieurs HLR. Pour SFR, un ensemble de clients sont affectés (les nouveaux clients 3G et 4G). Un HLR peut on être incriminé par contre en 2012, un seul HLR ne pouvait pas être responsable de la panne des 26 millions de clients. Une autre hypothèse était de supposer que le HLR en question était le V-HLR, un HLR virtualisé jouant le rôle d’administration et d’interconnexion des HLR. Mais, cela n’a pas été évoqué ni par Orange, ni par Alcatel.

Pour anecdote, le site Presse-citron terminait l’article en relatant la vidéo par cette conclusion « Reste à savoir si Orange et ses concurrents sauront tirer toutes les conséquences de ce dysfonctionnement pour faire en sorte que cela n’arrive plus. »

 

Diameter ou HLR, Orange confirme que le problème viendrait du HLR

Posté le by - 3 481 vues
Répondre

Alors que dans les articles précédents, nous avions évoqués deux éléments essentiels, le HLR et Diameter, il s’avère selon les dernières informations que l’équipement incriminé serait effectivement le HLR. Certaines sources évoquent même qu’Orange aurait confirmé cette panne.

Le HLR est le seul composant qu’on ne peut pas remplacer par un autre en quelques minutes ». « Quand le HLR revient, il y a un rush de demandes depuis les mobiles pour se réenregistrer. […] D’où probablement une remise en route partielle, par morceaux, d’abord 2G… » explique enfin le message sur la liste.

Opération de maintenance deux jours avant

Sur un autre site, on apprend que le HLR avait fait l’objet d’une opération de maintenance deux jours auparavant. Le suédois Ericsson et le français Alcatel-Lucent, les deux fournisseurs de ce type d’équipement pour France Télécom, ont travaillé en coopération étroite avec l’opérateur. «Une centaine de personnes d’Alcatel-Lucent sont mobilisées, dont une dizaine chez l’opérateur», précise l’industriel.

Nous allons donc abandonner la piste du protocole Diameter pour ne retenir plus que le HLR (à moins que le problème vient du protocole d’échange entre le HLR et les autres équipement du réseau). J’ai donc perdu mon pari du post précédent, en focalisant surtout sur la piste lié à la signalisation (selon les propos de Stéphane Richard :  » La panne est lié à un «dysfonctionnement logiciel» dans des équipements gérant «la signalisation des appels. « .

Rectification étant faîtes, nous connaissons maintenant la cause (sauf rebondissement …)

 

 

 

 

Origine de la panne chez Orange : Des hypothèses

Posté le by - 2 598 vues
Répondre

Suite à la panne d’Orange depuis 15h00 (officielle), il semblerait que les difficultés ait commencé dès 14h15, je reçois quelques mails pour connaitre l’origine de la panne et malheureusement je serai incapable de vous expliquer, par simple lecture des communiqués de presse, ou se situe la panne. L’équipe d’intervention mis en place par orange sauront nous l’expliquer.

Cependant, je profite de cette panne pour donner quelques pistes et revoir ainsi la structure du réseau mobile.Le premier indice est un réseau en panne au niveau national, le premier élément concerné est soit le AuC, soit le HLR, la base de donnée qui contient l’enregistrement de tous les abonnements.

Cependant, il y a plusieurs HLR, est ce que tous les abonnés d’Orange sont affectés?

Si non, on peut supposer qu’un HLR soit tombé en panne et qu’il n’y donc pas de répartition de charges ni de duplication active entre HLR (sauf si la duplication est elle aussi en panne, mais cette probabilité est plus faible).

Une autre panne possible est l’AuC, le centre d’authentification qui opère en amont du HLR. Mais dans cette hypothèse, ce n’est pas en soit l’authentification qui serait la cause car les abonnés enregistrés restent reconnus dans le réseau si celui tombe en panne ( sur une durée de 12h à 24h) mais ce serait la partie cryptage qui est utilisée dans la sécurisation via une clé (Ki et Kc) des appels. Sans ce procédé de décryptage/cryptage, impossible pour le réseau de récupérer de rendre les sessions claires (chiffrement). Le processus de chiffrement s’appuie sur plusieurs algorithmes, A3 et A8 au niveau de ll’AuC (lequel communique avec le HLR) et de l’algorithme A5 au niveau du mobile et de la station de base. Si l’AuC est injoignable, la clé de chiffrement n’est pas émise au mobile.

D’autres sources peuvent aussi être évoquées :

Est ce les serveurs DNS d’Orange qui ont été attaqué, serveurs qui permettaient aux équipements de joindre le/les HLR?

Est ce une Fibre Optique coupée ou déconnectée (toujours au niveau du HLR)?

Lorsqu’une panne importante affecte les abonnés au niveau national, il est préférable de mettre l’équipement en route la nuit afin d’éviter une masse critique de signalisation correspondant à la mise sous tension d’un nombre important de mobile. Ce n’est pas une raison suffisante néanmoins pour expliquer le fonctionnement normal du réseau, mais …

Est ce le réseau 4G, avec le basculement d’un HLR vers le HSS, d’une configuration d’un routeur avec le nouvel équipement HSS, la création d’une boucle (spanning tree) ne permettant plus l’accès au HSS ou HLR?

Espérons avoir des informations sur l’origine de la panne, par simple curiosité, je n’y crois cependant pas trop.