Dans deux articles écrits en mai 2015, j’avais décris la procédure d’attachement au réseau 4G : http://blogs.univ-poitiers.fr/f-launay/2015/05/05/emm-procedure-initial-attach/ et http://blogs.univ-poitiers.fr/f-launay/2015/05/19/emm-procedure-initial-attach-part-2/

Je vais revenir sur ces deux articles afin de mieux expliquer les différents scénarios s’appliquant au mobile lorsque ce dernier fait une demande d’attachement.

La procédure d’attachement nécessite 2 étapes clés:

• L’identification de l’UE auprès du MME.
• Authentification de l’UE

L’identification consiste, de la part du mobile, à fournir un identifiant lequel est transmis en clair sur l’interface air jusqu’au MME. Il s’agit donc d’un message NAS. Cet identifiant est transmis en clair, c’est à dire non crypté. (Imaginez en effet que l’UE crypte son identifiant par une clé Kc connu par le MME. Le MME n’ayant pas connaissance de l’UE qui lui a transmis le message devrait tester toutes ses clés Kc pour récupérer l’identifiant).

L’identifiant permettant de connaitre l’UE peut être :

• L’identifiant IMSI
• L’identifiant GUTI.

Ces deux identifiants ont été décrits dans l’article suivant : http://blogs.univ-poitiers.fr/f-launay/2015/05/06/imsi-tmsi-gummei-guti/

Le GUTI, Global Unique Temporary Identifier permet d’identifier de manière unique l’UE. Cet identifiant est constitué d’un code unique fourni par le MME, nommé M-TMSI. Le M-TMSI permet donc de connaître l’UE au niveau du MME. En rajoutant le code d’identifiant du MME, du code identifiant le pool MME, l’identifiant du réseau opérateur (MNC) et le code pays (MCC), le GUTI permet donc de connaître le MME sur lequel était enregistré l’UE auparavant.

Ce dernier point est important, lorsque l’UE se détache du réseau 4G (lorsqu’il envoie un message DETACH request), les contextes de commutation de bearer sont supprimés au niveau du PGW et du SGW mais :

• l’UE conserve son contexte de sécurité NAS, le GUTI et le tracking area
• le MME conserve le contexte de sécurité NAS associé au GUTI.

L’authentification consiste à vérifier l’identité de l’UE, soit à partir du message d’intégrité NAS soit à partir d’une procédure d’authentification mutuelle nommée AKA. Cette procédure permet au réseau de vérifier l’UE et pour l’UE de valider le réseau. Le choix de la procédure d’authentification est dictée par la manière dont l’UE s’identifie au réseau.

Si l’UE transmet son identifiant IMSI, dans ce cas le réseau applique la procédure d’authentification AKA mais si l’UE transmet son identifiant GUTI, le réseau est alors en mesure de récupérer son contexte de sécurité NAS.

Le contexte de sécurité NAS permet de garantir un échange authentifié entre l’UE et le MME (NAS Message) en chiffrant les données via une clé de chiffrement Knasenc et de valider l’intégrité du message via une clé d’intégrité Knasinc. Ces deux clés ont été générées au cours d’un précédent attachement avec l’identité IMSI.

Détachement

Nous allons maintenant nous intéresser à la spécification 23.401. (version 8 ira très bien).

Nous avons vu précédemment que l’UE pouvait s’identifier selon son IMSI ou son GUTI. Or, pour s’identifier avec le GUTI, le téléphone doit avoir été enregistré. Ainsi, aussi étrange que celà puisse paraître, pour comprendre cette procédure d’attachement, je vais commencer par expliquer la procédure de détachement, c’est à dire lorsque l’UE se désenregistre du réseau.

La procédure de détachement (Detach procedure – section 5.3.8 p70) peut être déclenchée par l’UE ou par le réseau.

L’UE peut faire une demande de détachement lorsque l’utilisateur éteint son téléphone ou bascule en mode avion. Dans ce cas, l’UE émet une requête NAS avec un indicateur « Switch Off » et le MME répond par un Detach Accept. Les contextes de commutation sont supprimés au niveau du SGW et PGW, le MME conserve quant à lui le contexte de l’UE (GUTI et clé de chiffrement/clé d’intégrité lié avec le GUTI).

Le MME peut aussi faire une demande de détachement pour un UE,

• soit une demande implicite (UE est implicitement détaché) qui a lieu lorsque l’UE n’a pas transmis ou reçu de données depuis un certains temps (implicit Detach Timer = T3423 + 4 mn si l’ISR – Idle Mode Signaling Reduction est activé  )
• soit une demande explicite par exemple pour réaliser de l’équilibrage de charge sur un autre UE

Jusqu’à présent, le MME a conservé le contexte NAS et le GUTI de l’UE. Au bout d’un certain temps

La fonction Purge (Purge Function cf section 5.3.9.3 p74) permet au MME d’informer le HSS qu’il a supprimé le contexte NAS et le GUTI. Ce dialogue est réalisé par le protocole Diameter via le message PUR/PUA (Purge Request/Answer). Dans le cas de cette procédure, le MME n’a plus de contexte concernant l’UE.

Attachement

Il nous reste plus qu’à étudier les différents scénarios pour la procédure d’attachement. Il y a 5 cas en tout :

1 – L’UE se connecte pour la première fois : Il transmet son identifiant IMSI

2 – L’UE se connecte avec son identifiant GUTI

1. Sa demande est transférée au MME sur lequel il était précédemment connecté
   1. Le MME a conservé son contexte
   2. Le MME n’a plus son contexte
2. Sa demande est transférée à un MME différent de son précédent MME
   1. Le MME a conservé son contexte
   2. Le MME n’a plus son contexte

Il faut bien se rappeler que quelque soit le scénario, la première étape consiste à s’identifier, donc à transmettre en clair son identifiant. Ensuite, si le mobile transmet son IMSI, la requête NAS de demande d’attachement n’est pas chiffrée.

Par contre, si le mobile transmet son GUTI, la suite du message NAS est chiffrée et une clé d’intégrité est rajoutée.

Voyons les différents cas.

CAS 1 – L’UE se connecte pour la première fois : Il transmet son identifiant IMSI. Dans ce cas, le réseau effectue une authentification AKA. J’invite le lecteur à se référer à l’article http://blogs.univ-poitiers.fr/f-launay/2015/05/05/emm-procedure-initial-attach/

2 – L’UE se connecte avec son GUTI.

CAS 2 : L’eNb analyse le GUTI, ce dernier est connecté au MME via un lien S1-MME, il peut donc relayer la requête NAS de demande d’attachement au MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajouté.

CAS 3 : L’eNb analyse le GUTI, ce dernier n’est pas connecté au précédemment MME. La requête est donc transmise à un nouveau MME, et ce dernier vient interroger l’ancien MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajoutée correspondant à l’ancien MME. Le nouveau MME transférant le tout à l’ancien MME. On suppose que ce MME n’a pas conservé le contexte ou la clé d’intégrité n’est pas correcte, dans ce cas le MME informe le nouveau MME qu’une procédure d’authentification doit être réalisée. Le nouveau MME demande à l’UE de s’identifier à nouveau via son identifiant IMSI

CAS 4 : L’eNb analyse le GUTI, ce dernier est connecté au MME via un lien S1-MME, il peut donc relayer la requête NAS de demande d’attachement au MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajouté. Le MME est capable de déchiffrer le message et la clé d’intégrité est correcte. Dans ce cas, le MME accepte la demande d’attachement.

CAS 5 : L’eNb analyse le GUTI, ce dernier n’est pas connecté au précédemment MME. La requête est donc transmise à un nouveau MME, et ce dernier vient interroger l’ancien MME. Le GUTI est envoyé en clair, la requête NAS est chiffré et une clé d’intégrité est rajouté. L’ancien MME est capable de déchiffrer le message et la clé d’intégrité est correcte. Dans ce cas, l’ancien MME informe le nouveau MME que la demande peut être acceptée.

Selon les différents cas, la procédure d’authentification AKA n’est pas nécessaire. Voici une dernière figure résumant les 5 cas possibles et le dialogue entre l’UE et le MME