La sécurité des réseaux mobiles – Part 6

Cet article est le dernier de la série – Sécurité des réseaux mobiles.

Se référer à :

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

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

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

La sécurité des réseaux mobiles – Part 4

La sécurité des réseaux mobiles – Part 5

II-3-2) La sécurité sur l’architecture SBA

L’architecture 5G SBA est définie à l’article suivant :

Architecture SBA du réseau 5G : Microservices et SOA

Figure 20 : l’architecture SBA du réseau 5G

Les fonctions réseaux NF (Network Function) doivent supporter le protocole TLS pour l’échange d’information coté serveur et client.

Le proxy SEPP implémente un niveau de sécurité sur la couche application sur l’échange d’information de signalisation échangées entre deux fonctions réseaux NF entre deux opérateurs (nominal et visité). La transaction entre les deux opérateurs est sécurisée par un certificat d’autorité.

Le rôle du SEPP est d’apporter une sécurité de bout en bout (E2E core network interconnection security) en chiffrement et en sécurité lorsque la signalisation est prise en charge par un fournisseur de transport IPX.

La confidentialité et l’intégrité sont assurées par les fonctions SEPP de bout en bout (réseau visité, réseau nominal) à travers l’interface N32.*

Figure 21 : L’architecture SBA dans le cas du Home Routing (HR)

3. Le mécanisme EAP

Pour gérer différentes méthodes d’authentification, les réseaux de mobiles utilise le protocole EAP (extensible Authentication Protocol). Ce protocole est dit extensible car il supporte différentes méthodes d’authentification.  Pour que l’authentification réussisse, il faut supporter le même type d’authentification EAP sur le client et sur le serveur d’authentification.

Différents type d’authentification supportés par le protocole EAP sont :

  • EAP-MD5 : Authentification avec un mot de passe ;
  • EAP-TLS (Transport Layer Security) : Authentification mutuelle basée sur les certificats du client et du réseau. Le client et le serveur doivent posséder un certificat numérique issue d’une autorité de certification (CA – Certificate Authority) ;
  • EAP-TTLS : Le client authentifie le serveur grâce à une infrastructure à clés publique (PKI : Public Key Infrastructure) au niveau du serveur. L’authentification mutuelle est optionnelle (l’utilisation de la clé publique au niveau client est optionnelle). Lorsque le client a authentifié le serveur, le serveur met en place un tunnel chiffré avec le client. Ce tunnel permet au serveur d’authentifier le client par un login/mot de passe au niveau du client. Le mot de passe peut en plus être chiffré par la méthode CHAP;
  • EAP-PEAP : La méthode PEAP est similaire à la méthode TTLS. Pour la méthode TTLS le mot de passe est transmis dans la payload TLS, alors que dans la méthode PEAP, le mot de passe du client est encapsulé dans l’en-tête TLS.
  • EAP-FAST : Authentification mutuelle, basée sur un certificat. L’obtention du certificat est négociée par le client lors du premier échange. Si le client n’a pas de clé PAC (Crédit d’Accès Protégé – Protected Access Credential) secrète communiquée à l’avance, il peut envoyer une requête d’échange EAP-FAST afin d’en obtenir une dynamiquement du serveur du client et du réseau par l’intermédiaire d’un canal chiffré (ou tunnel) ;
  • EAP-SIM : Authentification via l’application SIM d’un téléphone 2G;
  • EAP-AKA : Authentification mutuelle sur le réseau 3G/4G/5G ;
  • EAP-AKA’ : Authentification mutuelle sur le réseau 5G.

Dans le cas des réseaux mobiles, la méthode d’authentification s’appuie sur une clé secrète connue uniquement par le client et par le serveur d’authentification. Aucun mot de passe n’est transmis. Ainsi, seules les méthodes EAP-SIM, EAP-AKA et EAP-AKA’ sont utilisées.

La méthode EAP-SIM est définie pour le réseau 2G et dans ce cas, seul le serveur authentifie le client. Pour les méthodes EAP-AKA et EAP-AKA’, l’authentification est mutuelle (Authentication and Key Agreement), le réseau authentifie le mobile et le mobile authentifie le réseau.

Le réseau 4G supporte la méthode EAP-AKA, les réseaux 5G supportent en plus les méthodes EAP-AKA’ et EAP-TLS. Le protocole EAP-TLS est utilisé pour les réseaux privés.

Le format des messages EAP est le suivant :

Figure 22 : Le format EAP

Le champ des données utiles (payload) est constitué d’un champ type et du vecteur d’authentification.

Le champ type défini la méthode d’authentification :

Tableau 2 : Différentes valeurs des types EAP

L’implémentation du protocole EAP nécessite trois composantes :

  • Une couche basse (lower layer) est responsable de la transmission/réception des trames EAP. La couche basse peut être une connexion PPP, un modem RTC, une connexion Ethernet, une connexion WiFi, une connexion cellulaire ;
  • Une couche EAP qui transmet les paquets EAP à la couche basse ou reçoit les paquets EAP en provenance de la couche basse. La couche EAP implémente une fonction de détection des doublons et une fonction de retransmission.
  • La méthode EAP implémente l’algorithme d’authentification

Dans le cadre des réseaux de mobiles, le client EAP est situé dans la carte UICC.

Figure 23 : Le protocole EAP (cas PPP)

Les trois méthodes qui sont présentées permettent l’authentification du mobile à partir d’un point d’accès WiFi.

III-1) La méthode EAP-SIM

La méthode EAP-SIM permet au téléphone de basculer sur la connexion 2G ou 3G sur le réseau WiFi. La figure 3 présente les messages échangés entre le terminal et un point d’accès WiFi.

Figure 24 : La méthode EAP SIM

La méthode EAP SIM permet d’authentifier le mobile à partir de la clé privée symétrique située dans l’application SIM de la carte UICC et dans la base de donnée HLR.

L’objectif de la méthode EAP SIM est de permettre au mobile de se connecter automatiquement et de manière sécurisée sur un réseau WiFi communautaire. La méthode EAP SIM ne nécessité pas de login/mot de passe ni de portail captif.

Le centre d’authentification est l’entité HLR/Auc et l’authentificateur est le serveur d’authentification RADIUS AAA (Authentication Autorisation Accounting).

Figure 25 : Le protocole d’authentification par la méthode EAP-SIM (Source CISCO [4])

III-2) La méthode EAP-AKA

La méthode EAP-AKA est un mécanisme de défi-réponse basé sur une clé symétrique dans le module USIM et dans l’environnement nominal (HLR).

Le mécanisme est similaire à l’authentification 4G-AKA, le serveur EAP (authentificateur) est un serveur AAA (Authentication, Authorization and Accounting) et le centre d’authentification est l’entité HLR/AuC. Le lien radioélectrique WiFi n’étant pas protégé, le support de données (bearer) sera transmis dans un tunnel VPN sécurisé par le protocole IPSEC (Internet Protocol Security). Ce tunnel s’établit entre le mobile et l’entité ePDG (evolved Packet Data Gateway).

Figure 26 : L’architecture du réseau 4G avec le point d’accès WiFi

Le mécanisme IPsec est mis en œuvre pour l’établissement d’un tunnel à l’issue de la phase d’authentification utilisant le mécanisme 802.1x.

Le plan de contrôle (signalisation) est mis en œuvre par le protocole de chiffrement IKEv2 qui gère l’association de sécurité SA (Security Association) pour les sessions IPsec. Le protocole IKEv2 permet d’authentifier les deux extrémités du tunnel (ePDG et le mobile). Le mobile est l’initiateur et l’entité ePDG est le répondeur. Le protocole IKEv2 négocie les algorithmes de l’association de sécurité et permet l’échange des valeurs publiques D-H (algorithme Diffie Hellman) et les nombres aléatoires Nonce.

La clé de chiffrement Ck et la clé d’intégrité Ik générées par le centre d’authentification sont transmises à la passerelle ePDG. Les clés Ck et Ik étant connues par le mobile, ces deux clés sont utilisées pour générer la clé maîtresse MSK (Master Session Key).

Une fois l’authentification réussie, le tunnel IPsec assure la protection des données. Le protocole IPsec se situe sur la couche IP et permet :

  • le chiffrement des données (payload) par le protocole ESP (Encapsuling Security Payload). C’est la totalité du paquet IP qui est chiffrée ;
  • l’intégrité et l’authentification par encapsulation de l’entête AH (Authentication Header). Le paquet chiffré est encapsulé dans un nouveau paquet IP avec un nouvel en-tête IP.

Pour plus d’information, se référer à l’article : http://blogs.univ-poitiers.fr/f-launay/2018/01/01/interfonctionnement-du-lte-et-du-wifi/

En 4G, l’accès WiFi vers le cœur de réseau est utilisé principalement pour le WiFiCalling.

Figure 27 : La mise en place d’un tunnel pour le protocole SIP

III-3) La méthode EAP-AKA’

La méthode EAP-AKA’ est proche de la méthode d’authentification 5G-AKA. La demande d’authentification est transmise selon le protocole EAP. Les messages EAP sont encapsulés dans les messages NAS entre le mobile et la fonction SEAF de l’AMF, et dans les API (JSON) entre la fonction SEAF et la fonction AUSF.

Le rôle de la fonction SEAF est néanmoins différent dans le cas de la méthode EAP-AKA’ puisque la fonction SEAF transfère de manière transparente les messages EAP sans être impliquée dans la décision comme c’est le cas pour la méthode 5G-AKA.

L’autre différence porte sur la dérivation des clés. Dans le cas de la méthode 5G-AKA, le clé KAUSF est calculée par la fonction ARPF de l’entité UDM. Dans la méthode EAP-AKA’, la clé EMSK (Extended Master Session Key) est calculée au niveau de la fonction AUSF et les 256 premiers bits de la clé EMSK forment la clé KAUSF.

 

Références :

[1] http://www-igm.univ-mlv.fr/~jyt/Crypto/3/GSM/S5.Brumley-comp128.pdf

[2] 3GPP TS 35.205 : System Aspects; 3G Security, Specification of the MILENAGE algorithm set, An example algorithm set for the 3GPP, authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*. V9.0.0

[3] 3GPP TS 35.206 – LTE; 3G Security; Specification of the MILENAGE algorithm set: An example algorithm set for the 3GPP authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*; Document 2: Algorithm specification. V9.0.0

[4] Source CISCO : Cisco SP Wi-Fi solution: use cases and call flows (Djordje Vulovic) https://www.cisco.com/c/dam/global/hr_hr/assets/ciscoconnect/2014/docs/cisco_connect_see_2014_sp_wi-fi_dvulovic.pdf

[5] 3GPP TS 33.102 3G security; Security architecture, version 11.5.1 Release 11

[6] Snow3G : https://www.gsma.com/aboutus/wp-content/uploads/2014/12/snow3gspec.pdf

[7] ZUC Specification : https://www.gsma.com/aboutus/wp-content/uploads/2014/12/eea3eia3zucv16.pdf

[8] https://www.netmanias.com/en/?m=view&id=techdocs&no=10425

[9] 3GPP TS 35.206, 3G Security, specification of the MILENAGE, Release 7 version 7.0.0

https://www.etsi.org/deliver/etsi_ts/135200_135299/135206/07.00.00_60/ts_135206v070000p.pdf

[10] https://labs.p1sec.com/2020/06/26/5g-supi-suci-and-ecies/

[11] Des failles de sécurité dans la future norme de communication mobile 5G ; https://factuel.univ-lorraine.fr/node/9972

[12] 3GPP TS 33.501 Security Architecture and Procedure – version 15.1.0 (figure 6.1.3.1.1) : https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/15.01.00_60/ts_133501v150100p.pdf

 

Autres lectures : 

https://www.open.com.au/radiator/eap-sim-whitepaper.pdf

https://www.cablelabs.com/insights/a-comparative-introduction-to-4g-and-5g-authentication

ETSI TS 102 310 V6.0.0 (2004-12) : Extensible Authentication Protocol support in the UICC, Release 6

https://github.com/mitshell/CryptoMobile

https://github.com/CellularPrivacy/Android-IMSI-Catcher-Detector/issues/926

RFC3748 : Extensible Authentication Protocol (EAP) : https://tools.ietf.org/html/rfc3748

RFC 5998 : An Extension for EAP-Only Authentication in IKEv2 : https://tools.ietf.org/html/rfc5998

La sécurité des réseaux mobiles – Part 5

Articles précédents :

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

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

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

La sécurité des réseaux mobiles – Part 4

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

Le réseau 5G exploite les protocoles de sécurité pour l’authentification et la mise en sécurité des données comme en 4G.

Toutefois, l’abandon du protocole DIAMETER au profit du protocole http2 nécessite l’ajout de nouvelles entités afin de garantir une sécurité entre le réseau home et les réseaux visités avec l’architecture SBA (se référer à l’article :

http://blogs.univ-poitiers.fr/f-launay/2021/02/26/architecture-sba-du-reseau-5g-microservices-et-soa/).

On distingue différents niveaux de sécurité :

  • sur le réseau d’accès radio, le réseau 5G va étendre la sécurité sur l’accès radioélectrique WiFi ;
  • sur le domaine réseau, le vecteur d’authentification calculé par l’entité UDM de l’opérateur Home (HE AV : Home Environment Authentication Vector) est modifié par la fonction AUSF afin d’être transmis au réseau visité ;
  • sur l’interconnexion du réseau visité et du réseau nominal, un proxy de sécurité (SEPP) est déployer pour remplacer l’agent DIAMETER DEA permettant la mise en œuvre d’un tunnel sécurisé (certificat) entre le réseau Home et le réseau Visité.

L’authentification exploite soit l’algorithme 5G-AKA soit l’algorithme EAP-AKA’.

II-3-1) Authentification 5G-AKA

La procédure d’authentification AKA repose dans un premier temps sur l’identification du demandeur.
Dans le cas du réseau 4G, le mobile transmettait son identifiant IMSI.

Pour le réseau 5G, l’identité de la carte SIM transmise est soit le SUPI (Subscriber Permanent Identifier) soit le SUCI (Subscription Concealed Identifier).

L’authentification est basée sur le protocole AKA avec une clé symétrique Ki de 128 bits ou 256 bits. La clé Ki est sauvegardée dans la fonction ARPF (Authentication credential Repository and Processing Function) de l’entité UDM.

II-3-1-1) Procédure d’identification : amélioration de la sécurité en masquant l’identité IMSI

L’identité SUPI est similaire à l’identifiant IMSI : elle est composée d’un code pays MCC (Mobile Country Code), d’un code opérateur MNC (Mobile Network Code) et d’un identifiant unique par opérateur MSIN (Mobile Subscriber Identification Number).

L’identité SUCI est une version chiffrée du champ MSIN du SUPI. L’identité chiffrée est calculée par une méthode de chiffrement asymétrique hybride appelée ECIES (Elliptic Curve Integrated Encryption Scheme). Ce chiffrement est réalisé par la carte UICC.

La fonction SIDF (Subscription Identifier De-concealing Function) implémentée au niveau de l’UDM à pour rôle de déchiffrer le SUCI à partir d’une clé publique. Une fois le SUCI déchiffrée, la fonction SIDF transmet l’identité SUPI à l’UDM afin de procéder à l’identification de la carte UICC.

La méthode ECIES s’appuie sur les travaux de Diffie-Hellman. Cette méthode permet de déchiffrer un message à partir de l’échange d’une clé publique (cf. figure 13).

La carte UICC crée une clé privée en générant un nombre aléatoire dA. A partir de cette clé privée dA, la carte UICC calcule une clé publique QA. La clé publique QA est calculée à partir de la clé privée et d’un gradient G correspond à la courbe elliptique (cf. paramètre secp256k1). La clé publique QA est transmise à la fonction SIDF.

La fonction SIDF calcule un nombre aléatoire r qui constitue sa clé privée. A partir de sa clé privée, la fonction SIDF calcule :

  • sa clé publique R (par la même méthode que la carte UICC c’est-à-dire par le gradient G)
  • une clé symétrique S. Cette clé est calculée à partir de son nombre aléatoire r et la clé publique QA.

La fonction SIDF transmet sa clé publique, ce qui permet à la carte UICC de dériver la clé symétrique S. Le site [10] présente l’algorithme sous Python.

Figure 17 : Le calcul de la clé de chiffrement pour le SUCI

A chaque demande d’enregistrement, l’identité privée et cachée SUCI est calculée à partir de l’identifiant SUPI mais l’algorithme de chiffrement garanti une valeur de SUCI différente à chaque fois. La méthode ECIES permet à la fois la confidentialité du demandeur mais en plus la non traçabilité. Toutefois, il a été montré qu’un attaquant pouvant identifier un téléphone et le tracer [11].

Lorsque la fonction SIDF a déchiffré le SUCI, l’entité UDM récupère l’identifiant SUPI. L’UDM démarre ainsi sa procédure d’authentification : l’UDM fournit un aléa RAND, le sceau d’authentification du réseau home AUTN, le résultat d’authentification attendue au niveau du mobile et une clé de dérivation KSEAF.

II-3-1-2) Procédure d’authentification : amélioration de la sécurité en authentifiant le client sur le réseau nominal

La procédure d’authentification en 5G est similaire à la procédure 4G, mais quelques différences permettent d’améliorer l’authentification dans le cœur de réseau.

En effet, l’authentification est contrôlée dans le réseau nominal, et le réseau nominal utilise l’identité du serveur visité SNid (Serving Network Identity) pour dériver une clé d’ancrage KSEAF. Ainsi, la clé d’ancrage est spécifique au réseau visité. La clé KSEAF joue le rôle de la clé KASME pour la 4G.

Le réseau de mobiles 5G a introduit une fonction d’ancrage de sécurité SEAF (Security Anchor Function) au niveau du réseau visité (couplée à la fonction AMF). La fonction SEAF peut rejeter l’authentification du mobile mais il fait confiance au réseau nominal du mobile pour accepter l’authentification.

L’authentificateur du réseau nominal est la fonction AUSF (Authentication Server Function). La fonction AUSF s’appuie sur le serveur d’authentification UDM (Unified Data Management) qui fournit le vecteur d’authentification dans l’environnement nominal HE AV (Home Environment Authentication Vector). Le vecteur d’authentification dans l’environnement nominal contient :

  • l’aléa RAND ;
  • le sceau d’authentification du réseau AUTN ;
  • le résultat d’authentification RES ;
  • la clé KAUSF.

Le fonction AUSF transmet à la fonction AMF (du réseau nominal ou du réseau visité) le vecteur d’authentification AV qui contient l’aléa RAND, le sceau d’authentification AUTN, le résultat d’authentification hashé XRES et la clé d’ancage KSEAF.  Cette différence par rapport à la méthode 4G-AKA constitue la méthode d’authentification 5G-AKA ou EAP-AKA’.

A l’instar des réseaux 3G/4G, le jeton d’authentification AUTN contient le numéro de séquence SQN et la clé d’anonymat AK.

La fonction AMF du réseau visité réalise une deuxième authentification. La clé d’ancrage KSEAF est également utilisée par la fonction AMF lorsque le mobile s’accroche à un point d’accès WiFi. Grâce à la clé d’ancrage, il n’est plus nécessaire de réaliser une nouvelle procédure d’authentification lorsque le mobile, préalablement attaché sur le réseau 5G via l’accès 3GPP bascule sur un accès WiFi.

Ainsi, en 5G la procédure d’authentification 5G-AKA ou EAP-AKA’ peuvent être utilisées pour authentifier le mobile sur un réseau d’accès WiFi.

Figure 18 : La procédure d’authentification 5G [12]

 

A partir de la clé privée Ki et de l’aléa RAND, la fonction ARPF calcule :

  • soit la clé de chiffrement CK’ et la clé d’intégrité IK’ si l’algorithme EAP-AKA’ est utilisée ;
  • soit la clé KAUSF si l’algorithme 5G-AKA est utilisée.

Pour l’algorithme 5G-AKA, la clé KAUSF est transmise à la fonction AUSF.

Pour l’algorithme EAP-AKA’, les clés CK’ et IK’ sont transmises à la fonction AUSF. A partir de ces deux clés, la fonction AUSF dérive la clé KAUSF.

A partir de la clé KAUSF, la fonction AUSF dérive la clé KSEAF.

Au cours de l’étape 6, la fonction AUSF effectue un hachage de la valeur d’authentification attendue. Le calcul est basé sur l’algorithme HMAC-SHA-256 et utilise l’identifiant SNid du réseau visité. Le mobile ayant connaissance de l’identifiant SNid pourra calculer la valeur hashée.

Une fois authentifié sur le réseau visité, la fonction AMF informe la fonction AUSF de la réussite de l’authentification. C’est à l’issu de cette première authentification que la clé KSEAF sera transmise à la fonction SEAF. La fonction SEAF est réalisée par l’AMF.

L’architecture protocolaire de la station de base 5G est similaire à celle de la 4G, avec l’ajout d’une fonction SDAP pour la gestion de la QoS du trafic IP.

Ainsi, le chiffrement et l’intégrité du lien radioélectrique sont gérés par le protocole PDCP.

A l’issu de la phase d’authentification, à partir de la clé privée Ki et de l’aléa RAND :

  • la fonction ARPF de l’entité UDM génère un aléa RAND, le résultat attendu XRES et le sceau d’authentification pour former le vecteur d’authentification HE AV
  • la fonction ARPF de l’entité UDM calcule les clés CK’ et IK’ ou la clé KAUSF à partir de la clé Ki et de l’aléa RAND;
  • l’entité AUSF dérive la clé KSEAF. La clé KSEAF ne sera transmis uniquement à la fonction SEAF de l’AMF après que l’authentification ait abouti sur le réseau visité ;
  • la fonction SEAF dérive la clé KAMF;
  • à partir de la clé KSEAF, la fonction AMF dérive les clés KNASenc, KNASInt, KgNB et la clé KN3IWF;
  • la clé KgNB est transmise à l’entité gNB qui dérive les clés Kupint, Kupenc, kRRCint, KRRCenc.

Les clés de chiffrements utilisées sont :

  • KNASenc pour le chiffrement des messages NAS (UE <-> MME) ;
  • Kupenc pour le chiffrement des messages de données sur l’interface radioélectrique ;
  • KRRCenc pour le chiffrement des messages de contrôle (signalisation) sur l’interface radioélectriques.

Les clés d’intégrités utilisées sont :

  • KNASint pour la signature MAC des messages NAS (UE <-> MME) ;
  • KRRCint pour la signature des messages de contrôle (signalisation) sur l’interface radioélectriques ;
  • Optionnellement (non mis en œuvre en 4G et optionnel en 5G), Kupint pour la signature des messages de données.

Figure 19 : La procédure d’authentification sur le réseau 5G

 

 

La sécurité des réseaux mobiles – Part 4

Les précédents articles sur le même sujet :

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

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

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

II-2) La sécurité sur le réseau 4G

Le réseau en 4G est en réseau en tout IP, et par conséquent, plus sensible sur la sécurité IP. Au niveau de l’accès radioélectrique, la station de base 4G, nommé eNB, rassemble le contrôleur RNC avec la station de base.

Ainsi, le protocole PDCP se situe au niveau de l’eNB. Le chiffrement et l’intégrité sont réalisés par l’eNB en 4G.

Les algorithmes de chiffrement et d’intégrité ont été partiellement redéfinis dans le cas des réseaux de quatrième génération. Ils s’appuient sur deux algorithmes, respectivement fondés sur Snow 3G et AES.

Ainsi, deux standards ont été proposés pour la 4G :

  • chiffrement : Algorithme EEA (EPS Encryption Algorithm) ;
  • intégrité : Algorithme EIA (EPS Integrity Algorithm).

A partir de l’algorithme SNOW3G [6], la 3GPP propose les algorithmes 128-EEA1/128-EIA1.

A partir de l’algorithme AES (Advanced Encryption Standard), la 3GPP propose les algorithmes 128-EEA2/128-EIA2.

A partir de l’algorithme ZUC [7], la 3GPP propose les algorithmes 128-EEA3/128-EIA3.

Tableau 1 : La méthode de chiffrement et la complexité

Les clés de chiffrement et d’intégrité sont calculées à partir de la clé Ki privée et du numéro aléatoire (aléa RAND) fournit au mobile pour l’authentification. Nous allons donc revenir sur la procédure d’authentification en 4G.

Figure 12 : La procédure d’authentification 4G

Se référer aux articles :

La figure 12 présente la procédure d’attachement avec le calcul des clés et les algorithmes associés :

Figure 13 : Procédure d’authentification 4G [8]

Comme en 3G (se référer à la figure 6), le jeton d’authentification contient trois champs :

  • le numéro de séquence SQN embrouillé avec la clé d’anonymat A;
  • la valeur du champ d’authentification AMF ;
  • la signature MAC du message.

La signature est calculée par l’algorithme f1.

Les clés Ck, IK, AK et le résultat d’authentification du mobile RES sont calculés par les algorithmes f2, f3, f4 et f5. La spécification [9] fournit les algorithmes en langage de programmation C.

Figure 14 : le calcul des clés pour la procédure d’authentification en 4G

La carte USIM contient la clé privé Ki, la valeur AMF et une valeur OP. OP est une valeur codée sur 128 bits qui est définie par l’opérateur nominal. La clé peut être publique ou secrète. La clé OPc est dérivée de la clé OP à partir de la clé Ki. La clé OPc est stockée dans la carte UICC.

La carte UICC stocke la valeur SQN (cette valeur change à chaque authentification).

Figure 15 : L’algorithme MILENAGE [9]

A l’issu de la phase d’authentification, à partir de la clé privée Ki et de l’aléa RAND :

  • L’entité HSS dérive les clés CK et IK;
  • l’entité HSS dérive la clé KASME à partir de Ck et Ik;
  • l’entité MME dérive les clés KNASenc, KNASInt, KeNB à partir de la clé KASME;
  • l’entité eNB dérive les clés Kupint, Kupenc, kRRCint, KRRCenc.

Les clés de chiffrements utilisées sont :

  • KNASenc pour le chiffrement des messages NAS (UE <-> MME) ;
  • Kupenc pour le chiffrement des messages de données sur l’interface radioélectrique ;
  • KRRCenc pour le chiffrement des messages de contrôle (signalisation) sur l’interface radioélectriques.

Les clés d’intégrités utilisées sont :

  • KNASint pour la signature MAC des messages NAS (UE <-> MME) ;
  • KRRCint pour la signature des messages de contrôle (signalisation) sur l’interface radioélectriques ;
  • Optionnellement (non mis en œuvre en 4G et optionnel en 5G), Kupint pour la signature des messages de données.

La fonction USIM sur la carte UICC réalise l’étape 1 (dérive les clés CK et IK ). Le mobile dérive toutes les autres clés (étapes 2 à 4).

Figure 16 : Le calcul des clés en 4G

Si le mobile fait une procédure d’accès sur le réseau WiFi, le cœur de réseau 4G réalise une nouvelle procédure d’authentification par la méthode EAP-AKA. Celle-ci est décrite en section 3.

Les deux faiblesses de la méthode d’authentification EPS-AKA sont :

  • la transmission en clair de l’identité IMSI. Même si un identifiant temporaire GUTI (Globally Unique Temporary Identity) est ensuite utilisé pour cacher l’identité IMSI sur l’interface radioélectrique LTE, cette identifiant n’est pas modifié assez fréquemment, et l’identité est prédictible. De plus, un réseau pirate peut demander au mobile de retransmettre son identité IMSI en clair ;
  • le réseau nominal fournit au réseau visité le vecteur d’authentification. Il délègue la décision d’authentification au réseau visité.

 

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.

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

  1. L’authentification sur le réseau 2G

Sur le réseau 2G, le serveur d’authentification est l’entité HLR (Home Location Register). La fonction AuC (Authentification Center, fonction d’authentification du HLR), génère un numéro aléatoire aléa RAND sur 128 bits qui constitue le défi (figure 1).

Le protocole d’authentification utilisé dans les réseaux GSM repose sur l’algorithme COMP128. L’algorithme COM128 implémente deux fonctions : la fonction A3 pour l’authentification et la fonction A8 permettant de dériver la clé de chiffrement. Les fonctions A3 et A8 ne sont pas normalisées, ce qui signifie que les opérateurs sont libres d’utiliser des algorithmes propriétaires non publics.

A partir du numéro aléatoire RAND et de la clé privée Ki, la fonction A3 calcule un résultat nommé SRES sur 32 bits, et la fonction A8 calcule une clé Kc de longueur 64 bits (figure 1).

Figure 1 : L’algorithme COMP128

L’entité HLR transmet le triplet d’authentification (RAND, SRES, Kc) à l’authentificateur VLR/MSC (Visitor Local Register/Mobile Switch Center – commutateur mobile). L’authentificateur MSC transmet l’aléa RAND à la carte UICC du mobile pour que ce dernier calcule le code d’authentification MAC (Message Authentication Code). La carte UICC (application SIM) calcule également la clé de chiffrement Kc. Le résultat du code d’authentification RES obtenu au niveau de la carte UICC est transmise par le mobile à l’authentificateur VLR/MSC. Ce dernier compare alors les deux codes d’authentification RES et SRES. Si les résultats sont identiques, l’authentificateur VLR/MSC transmet un message de réussite au terminal et transmet la clé Kc à la station de base.

Figure 2 : Le protocole d’authentification et de chiffrement sur le réseau GSM

Le chiffrement est basé sur la clé Kc et l’algorithme A5. Il s’agit d’un algorithme de chiffrement par bloc. Cet algorithme est normalisé et pour assurer le Roaming, l’algorithme est utilisé par tous les opérateurs mobiles. Le chiffrement est réalisé au niveau de la station de base (BTS) et du mobile (figure 2).

Il existe quatre algorithmes de chiffrement nommé A5/1 à A5/4,le choix de l’algorithme est négocié par le réseau en fonction de la liste des algorithmes que dispose le mobile. Les algorithmes A5/3 et A5/4 sont aussi connus sous le nom KASUMI et sont apparus plus tard et ils sont également utilisés en 3G.

Dans le cas du GPRS, l’algorithme de chiffrement GEA (GPRS Encryption Algorithm) est mis en œuvre au niveau de l’entité SGSN.

Figure 3 : Le calcul des clés en 2G mode CS

Figure 4 : Le calcul des clés en 2G mode PS

Le chiffrement est mis en œuvre par le protocole LLC situé dans l’entité SGSN 2G

 

 

 

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

Merci à Tony Boucheau pour la relecture de l’article

 Introduction

A l’exception des appels d’urgence, le client mobile n’a accès à aucun des services offerts par le cœur de réseau mobile tant que celui-ci n’est pas authentifié.

Les échanges liés au processus d’authentification sont relayés par le point d’accès vers le serveur d’authentification. Le point d’accès est en général une station de base 2G/3G/4G/5G. Toutefois, le point d’accès WiFi est également vu comme une passerelle radioélectrique permettant de connecter l’utilisateur mobile au cœur de réseau 5G.

Une fois le client authentifié, le point d’accès laisse passer le trafic. Afin de garantir le secret des informations échangées, les données sont chiffrées et un contrôle d’intégrité par une signature MAC (Message Authentication Code) permet de vérifier l’authenticité de l’émetteur.

Le chiffrement est mis en place entre les acteurs de la transaction ce qui garantit que la session devient inintelligible aux autres personnes. Enfin, pour se prémunir des attaques de type Man in the Middle (IMSI Catcher), l’intégrité des données permet de vérifier que les données de signalisation échangées n’ont pas été altérées (de manière fortuite ou intentionnelle). Le chiffrement et l’intégrité sont réalisés au niveau du terminal et :

  • si le point d’accès est une station de base 4G ou 5G, celle-ci apporte un chiffrement sur le trafic de données et sur le trafic de signalisation ainsi qu’un contrôle d’intégrité sur la signalisation. Optionnellement, pour le réseau 5G, le contrôle d’intégrité peut aussi s’appliquer sur le trafic des données. Les clés de chiffrement et d’intégrité sont dérivées à partir d’une clé secrète et à partir des paramètres échangés lors du processus d’authentification ;
  • si le point d’accès est une station de base 2G, le chiffrement est réalisé au niveau de la station de base pour les communications téléphoniques et au niveau du SGSN pour les sessions IP ;
  • si le point d’accès est une station de base 3G, le chiffrement est réalisé au niveau du contrôleur RNC ;
  • si le point d’accès est un point WiFi, un tunnel est mis en œuvre entre le mobile et une entité de passerelle WAG (Wireless Access Gateway). Cette entité se nomme ePDG (evolved Packet Data Gateway) pour le réseau 4G et N3IWF pour le réseau 5G.

 

Le processus d’authentification a pour objectif de vérifier l’identité d’un client (aussi nommé pair ou supplicant). Le protocole d’authentification spécifie le format des messages échangés (requêtes/réponses) entre le client et l’authentificateur. En se basant sur l’identité présumée du client, l’authentificateur transmet au client un défi (un challenge). A partir du défi, le client calcule sa réponse qu’il transmet à l’authentificateur. Cette réponse permettra à l’authentificateur soit d’authentifier le client soit de démasquer un usurpateur d’identité.

L’architecture d’authentification est composée d’un point d’accès, d’un authentificateur et d’un serveur d’authentification. Dans le cas des réseaux de mobiles, l’authentificateur et le serveur d’authentification sont deux entités distinctes : le serveur d’authentification correspond à l’entité HSS pour les réseaux de mobiles 4G ou à l’entité UDM pour les réseaux de mobiles 5G. Le serveur d’authentification (HSS/UDM) est situé en back-end de l’authentificateur. La fonction d’authentificateur est gérée par l’entité MME en 4G ou par la fonction AMF en 5G.

Les étapes d’authentification sont les suivantes :

  • L’authentificateur reçoit une demande d’identification de la part d’un client comprenant l’identité du client. Cette requête peut être initiée par le client ou par l’authentificateur. A partir de cette demande d’identification, l’authentificateur transmet un défi au client ;
  • Le client calcule la réponse au défi et transmet la réponse à l’authentificateur ;
  • L’authentificateur contrôle la réponse en comparant la réponse du client à la réponse attendue.

L’authentificateur interroge le serveur d’authentification en lui fournissant l’identité du client. Le serveur d’authentification vérifie l’existence de l’identité du client, et le cas échéant génère un défi. Le client peut supporter plusieurs méthodes d’authentification. Le défi est choisi selon la méthode d’authentification supportée par le client. Le défi et la réponse sont transmises à l’authentificateur.

Pour les réseaux de mobiles, le client est la carte UICC et les méthodes d’authentifications sont définies dans l’application USIM (et dans l’application ISIM pour l’authentification avec le réseau IMS).

La carte UICC contient une identité IMSI unique et une clé d’authentification Ki. Ces deux informations sont stockées au niveau du serveur d’authentification.

5G – DSS – Partie 4

suite de l’article 

III) Conclusion

Le partage dynamique de la bande 4G/5G permet d’apporter de la 5G au niveau des cellules 4G sans avoir besoin de recourir au refarming. Les opérateurs planifient néanmoins l’allocation de la bande 4G aux usages 5G dans les années à venir (figure 20).

Figure 20 : L’usage de la bande 4G/5G dans les années à venir

En contrepartie, la méthode DSS complexifie la gestion radioélectrique entre les signaux 4G et les signaux 5G.

La spécification 3GPP propose 3 méthodes (figure 21) :

  • basée sur la sous-trame MBSFN,
  • basée sur le mini-slot ;
  • basée sur l’adaptation de bloc de ressource.

Figure 21 : Les options de déploiement DSS [2]

  1. L’option 1 est basée sur la sous-trame MBSFN. Les 12 symboles de la sous-trame est dédiée aux communication 5G. Aucun trafic 4G n’est possible sur cette sous-trame. L’option 1 permet d’utiliser sans contrainte les 12 symboles de la sous-trame pour émettre en 5G quelle que soit la numérologie µ.
  2. L’option 2 utilise la notion de mini-slot standardisée pour les transmission 5G. Un mini-slot exploite 2, 4 ou 7 symboles OFDM. La transmission mini-slot a été spécifiée par la 3GPP pour les cas d’usage URLLC en proposant de transmettre à tout moment pour réduire la latence. Pour ne pas interférer avec les signaux CRS, les mini-slot sont transmis lorsqu’il n’y pas de signaux de référence à émettre.
  3. L’option 3 est généralement celle déployée par les opérateurs. Cette option s’appuie sur le procédé de poinçonnage (puncturing). La station de base peut du trafic 5G sur l’ensemble du canal de trafic PDSCH sauf sur les éléments de ressource utilisée pour la transmission des signaux de référence. L’allocation de ressource peut être réalisée par élément de ressource ou par ressource bloc. Par élément de ressource, seul l’élément de ressource RE (Resource Element = 1 symbole) contenant le signal CRS est exclu. Dans le cas d’adaptation par bloc de ressource RB (Resource Bloc), c’est le RB en entier qui est exclu pour la transmission 5G.

L’efficacité spectrale est meilleure dans le cas de l’adaptation par élément de ressource (RE) néanmoins elle n’est possible que lorsque la station de base 5G fonctionne avec un écart entre sous-porteuse de 15 kHz comme dans le cas de la station de base 4G.

Si l’espacement entre sous-porteuses 5G est de 30 kHz, alors seul le procédé de poinçonnage par bloc est possible.

La transmission par mini-slot était initialement prévue pour ne pas faire de poinçonnage.

Parmi ces 3 options, la 3ème option est la plus efficace spectralement mais elle est limitée au cas ou l’espacement entre sous-porteuses 5G est de 15 kHz. Lorsque l’espacement est de 30 kHz, l’option 1 ou 2 peuvent être utilisées avec une préférence pour l’option 2. Celle-ci se révèle moins efficace comme le montre la table 2.

Table 2 : L’adaptation de débit RE (par slot) /RB (par mini-slot)

Pour le lien montant, le terminal 4G utilise la méthode SC-FDMA pour réduire la consommation énergétique. La spécification 4G a imposé un décalage fréquentiel de 7,5 kHz par rapport au signal descendant. Pour la 5G, le terminal utilise soit la méthode SC-FDMA soit la méthode OFDMA. Ce décalage de fréquence ne permet plus d’assurer l’orthogonalité entre les sous-porteuses 4G et 5G. Pour pallier à ce décalage, la 5G DSS sur le lien montant est décalé de 7,5 kHz afin d’être aligné sur la transmission montante LTE.

Figure 22 : L’alignement des fréquences 4G/5G sur le lien UL

La table 3 résume les caractéristiques DSS avec les différentes versions de la spécification 3GPP

Table 3 : Les caractéristiques DSS

Références

[1] https://images.samsung.com/is/content/samsung/p5/global/business/networks/insights/white-papers/0122_dynamic-spectrum-sharing/Dynamic-Spectrum-Sharing-Technical-White-Paper-Public.pdf

[2] https://www.sharetechnote.com/html/Handbook_LTE_MBSFN.html

[3]https://newsletter.mediatek.com/hubfs/mediatek5gprogress/Dynamic-Spectrum-Sharing-WhitePaper-PDFDSSWP-031320.pdf

[4] https://www.keysight.com/fr/en/assets/7120-1249/application-notes/Dynamic-Spectrum-Sharing-DSS-Functional-and-Performance-Verification-with-Keysight-Nemo-Tools.pdf?success=true

5G – DSS – Partie 3

Suite de l’article DSS

II-2) Les sous-trames MBSFN

Initialement, la transmission MBSFN a été standardisée dans la spécification R.9 pour des contenus télévisuels : le terminal mobile reçoit un flux IP en provenance de plusieurs stations de bases. Celles-ci émettent simultanément le même flux et sur la même fréquence.

Figure 14 : La synchronisation des zones de services MBSFN [2]

Cela nécessite une synchronisation des stations de base. On synchronise les stations de base dans une aire MBSFN. Une station de base peut appartenir à deux aires MBSFN.

La présence de canaux physiques PMCH est indiquée au mobile via les messages d’informations systèmes LTE SIB2/SIB13 (System Information Block).

Une trame 4G en mode FDD est composée de 10 sous-trames. La sous-trame 0 et la sous-trames 5 émettent le canal de synchronisation. Les sous-trames 0, 4, 5 et 9 sont réservées pour transmettre des notifications (paging). Ainsi, les sous-trames MBSFN candidates sont les sous-trames 1, 2, 3, 6, 7 et/ou 8.

L’information SIB2 indique la position des sous-trames MBSFN.

 

Figure 15 : La position des trames MBSFN [2]

La valeur OneFrame positionnée à 1 indique la présence d’une sous-trame MBSFN.

L’information portée par le canal SIB13 concerne le paramétrage radio du canal de contrôle MCCH (MBSFN Control Channel).

La sous-trame MBSFN est découpée en deux région :

  • une région Non-MBSFN qui correspond au canal de contrôle PDCCH. Ce dernier est imposé sur toute la largeur de bande 4G et sur un ou deux symboles OFDM. La région Non-MBSFN porte les canaux PHICH, PCFICH et PDCCH ;
  • une région MBSFN qui a pour objectif de porter les données utiles de diffusion PMCH (Physical Multicast Channel) et des signaux de références.

L’évolution eMBSFN rajoute des signaux de références afin de pallier aux différences sources de transmissions qui sont reçues de la part du mobile comme des échos (le même signal est transmis simultanément et sur les mêmes fréquences mais à des endroits différents).

Le signal est transmis sur des sous-porteuses OFDM espacées de 15 kHz ou 7,5 kHz ou 1,25 kHz.

Figure 16 : Les signaux de références MBSFN

La méthode DSS peut exploiter une ou plusieurs trames MBSFN, en profitant des 12 symboles de la sous-trame pour diffuser le canal 5G SSB espacée de 15 kHz ou 2*12 symboles si l’espacement est de 30 kHz. La sous-trame MBSFN peut également être utilisée pour transmettre à la fois le canal de contrôle (CORESET) et de trafic.

La figure 17 présente un exemple de trame émise avec une sous-trame MBSFN (3ème sous-trame). Les autres sous-trames sont nommées sous-trame non-MBSFN.

Figure 17 : La transmission 4G-LTE avec une sous-trame MBSFN

La transmission DSS par sous-trame MBSFN est plus efficace à la méthode par slot comme le montre la figure 18 pour le cas de la R16 (correspondance type B avec 9 symboles)

Figure 18 : Comparaison de la méthode DSS par mini-slot et par sous-trame MBSFN

Toutefois, l’intérêt principal de la sous-trame MBSFN est la possibilité de transmettre le bloc SSB et les canaux PDCCH.

Figure 19 : La sous-trame MBSFN et la transmission des blocs SSB [3]

En général, la sous-trame MBSFN est utilisée pour émettre le bloc de synchronisation SSB avec un espacement entre sous-porteuses de 30 kHz.

5G – DSS – Partie 2

Suite de l’article DSS

2. Les options DSS

La méthode DSS permet de partager de manière dynamique la bande radioélectrique pour émettre des signaux RF vers des mobiles 4G et en même temps, sur d’autres éléments de ressources disponibles des signaux RF vers des mobiles 5G.

La spécification 3GPP propose 3 méthodes mais l’implémentation est laissée libre à l’équipementier. Les 3 options sont :

  • Option 1 : sous-trames MBSFN (Multicast-Broadcast Single Frequency Network) ;
  • Sous-trames basées sur l’adaptation de débit :
    • option 2 : de type-B (par mini-slot) ;
    • option 3 : de type-A (adaptation CRS – CRS rate matching)

La sous-trame MBSFN est une technologie 4G pour transmettre des informations vers plusieurs mobiles simultanément et s’insère de manière transparente dans une transmission 4G. Dans le cas de la transmission MBSFN (à partir de la R.9), le canal de contrôle 4G-PDCCH exploite deux symboles pour libérer 12 symboles eMBMS (enhanced MBMS). L’inconvénient de cette méthode est la réduction du débit 4G notamment lorsque les sous-trames MBMS sont fréquemment transmises.

Ainsi, les sous-trames basées sur l’adaptation de débit sont plus flexibles et exploitent de manière plus efficace les éléments de ressources non exploités 4G-LTE.

L’option 3 consiste à transmettre le signal 5G sur les slots 4G mais en supprimant (puncturing) les éléments de ressources 5G lorsque le signal 4G doit émettre des signaux de références 4G-CRS. L’option 3 est ainsi la méthode la plus efficace spectralement. Mais, celle-ci n’est possible que lorsque l’espacement entre sous-porteuses 5G est de 15 kHz.

II-1) L’adaptation de débit

La transmission NR est définie par la notion de slot dans le domaine temporel. Un slot est composé de 14 symboles. Le canal de données PDSCH est transmis dans un slot, mais n’occupe pas obligatoirement le slot en entier.

La 3GPP a spécifié deux types de transmissions NR PDSCH, nommée Type A et Type B qui définit l’association du canal NR PDSCH avec le signal de référence NR DMRS :

  • La transmission basée sur un slot : Transmission de type A. Le signal de référence NR DMRS est positionné sur le symbole 2 ou 3, et le canal NR PDSCH est défini par deux paramètres : Le début du canal dans le slot (Start) et la longueur en nombre de symboles occupés dans le slot (Length). Ce paramètre nommé SLIV (Start Length Indicator Value).
  • La transmission basée sur un mini-slot : Transmission de type B. Le mini-slot correspond à 2, 4 ou 7 symboles et le signal de référence NR DMRS est positionné sur le premier symbole dans le domaine temporel du mini-slot.

La table 5.1.2.1-1 de la spécification 38.214 spécifie les valeurs SLIV possibles :

Table 1 : Les valeurs possibles pour la position du canal 5G-PDSCH dans un slot

Se référer à l’article précédent pour la compréhension du SLIV.

Pour la transmission de type A, le canal NR PDSCH démarre au symbole 0,1,2 ou 3.

Sur la figure 5, pour la transmission de type A, le canal NR PDSCH démarre à la position 0 et pour la transmission de type B, le canal NR PDSCH démarre au slot 7.

Figure 5 : La transmission NR-PDSCH (à gauche par slot, à droite, mini slot)

Le mode de duplexage TDD de l’interface 5G-NR est basée sur le temps d’un symbole, pour la transmission descendante NR-PDSCH de type A, il est également possible de transmettre moins de 12 symboles. A titre d’exemple, la figure 6 présente une transmission sur 5 symboles.

Figure 6 : La transmission du canal NR-PDSCH sur 9 symboles, canal associé au signal de référence DM-RS sur le symbole 2 uniquement (dmrs_additionnal=0)

Pour améliorer la démodulation, il est possible d’associer plusieurs signaux de références NR DMRS (figure 7).

Figure 7 : La transmission NR-PDSCH sur 14 symboles avec l’ajout de signaux de référence

L’adaptation de débit consiste à exploiter l’allocation radioélectrique LTE et d’insérer le canal NR PDSCH et les signaux de références 5G sans interférer avec les signaux de références 4G CRS.

Il est donc nécessaire de poinçonner le canal NR-PDSCH car il n’est pas possible de poinçonner les signaux de références DMRS.

II-1-a) Adaptation de débit par slot

L’adaptation de débit par slot s’appuie sur la transmission du canal NR PDSCH avec le signal de référence NR DMRS associé sur le slot 2 ou 3 (Mapping type A).

La figure 8 reprend l’allocation de ressources LTE et les schémas d’allocation de ressource NR.

Figure 8 : L’adaptation de débit par slot (NR-PDSCH de type A) [3]

Sur la figure 8, les deux premiers symboles sont réservés pour la transmission du canal de contrôle 4G- PDCCH. Ainsi, la position du signal NR-DMRS est située sur le symbole 3 avec éventuellement un ajout du signal de référence NR-DMRS sur le symbole 12 ou deux ajouts du signal de référence NR DMRS sur les symboles 7 et 11.

Sur la figure 8, on prend comme hypothèse que le signal de référence 4G-CRS est transmis sur 2 ports d’antennes. Dans l’hypothèse ou 4 ports seraient utilisés, il faut reprendre la figure 2. En effet, les signaux de références CRS sont transmis sur deux sous-porteuses et 4 symboles (position 0, 4, 7 et 11) pour deux ports d’antennes. Avec 2 ports d’antennes supplémentaires, deux symboles additionnels à la position 1 et 8 portent le signal de référence par sous-porteuses.

Le signal de référence NR-DMRS ne pouvant pas être poinçonné, il ne peut pas être transmis lorsque les signaux de référence 4G-CRS sont émis.

Par contre, le canal NR-PDSCH peut être poinçonné. Ainsi dans le cas de la figure 8, celui peut être transmis sur symboles 7 et 11 sauf sur les sous-porteuses qui transportent le signal de référence 4G-CRS.

II-1-b) Transmission DSS par mini-slot

La transmission DSS par mini-slot s’appuie sur la transmission du canal NR PDSCH correspond à 2, 4 ou 7 symboles associé au signal DMRS en début de transmission du canal NR PDSCH (Mapping type B).

Figure 9 : La transmission DSS par mini-slot (R.15)

La spécification R.16 propose d’étendre la taille du canal NR PDSCH à 10 symboles.

Figure 10 : La transmission DSS par mini-slot (R.16)

Il est à noter que dans cette proposition, le signal de référence NR DMRS associé au canal NR PDSCH n’est plus positionné en début de transmission mais après le slot poinçonné.

II-1-c) Transmission du bloc SSB

Un bloc de synchronisation et de diffusion 5G (SSB) est transmis sur 4 symboles consécutifs. Si l’espacement entre sous-porteuses est de 15 kHz, alors on ne peut pas utiliser la méthode précédente pour transmettre le bloc SSB. Si par contre l’espacement entre sous-porteuses est de 30 kHz, dans ce cas il est possible d’émettre un seul bloc SSB.

En effet, comme le montre la figure 11, la durée d’un symbole est inversement proportionnelle à l’espacement entre sous porteuses.

 

 

Figure 11 : La relation entre espacement fréquentielle et durée d’un symbole

Ainsi, la durée de deux symboles de la zone 4G correspond à la durée de :

  • 2 symboles NR pour espacement de 15 kHz ;
  • 4 symboles NR pour un espacement entre sous-porteuses de 15 kHz.

Cependant, dans le cas où l’on souhaiterait émettre plusieurs blocs SSB consécutifs (Beamforming Sweeping), la seule solution est d’utiliser des sous-trame MBSFN.

Figure 12 : La transmission de bloc SSB

La figure 13 présente les opportunités pour transmettre des blocs SSB avec la contrainte de ne pas interférer les signaux de références.

 

Figure 13 : La transmission simultanée du bloc SSB et des signaux de références 4G-CRS

 

 

5G – DSS – Partie 1

1. Introduction

Le déploiement de la 5G actuellement en cours par les opérateurs s’effectue soit sur la nouvelle bande de 3,5 GHz, soit sur une bande 4G à 700 MHz ou 2100 MHz. Seule l’exploitation de la nouvelle bande à 3,5 GHZ permet d’augmenter les débits de transmission. L’utilisation de la bande à 700 MHz ou 2100 MHz permet d’émettre un signal 5G en exploitant une partie de la bande 4G. Ainsi le débit obtenu en 5G s’obtient en réduisant en contrepartie le débit 4G (dans un ordre de grandeur assez proche).

Dans ce cas de déploiement de la 5G sur une bande actuellement utilisée par la 4G, il ne s’agit pas de refarming car on ne ré-affecte pas le spectre 4G pour la 5G mais la station de base procède à la gestion dynamique de spectre.

Figure 1 : La différence entre re-farming et DSS [1]

Le re-farming n’est pas possible car d’une part dans le fonctionnement de la 5G-NSA il est nécessaire de conserver la connexion radioélectrique 4G mais en plus, le nombre d’utilisateurs 4G est trop élevé pour basculer une partie du spectre 4G vers la 5G. Il faut ainsi attendre plusieurs années avant d’envisager du re-farming (cet argument est valable quelle que soit la technologie).

Figure 2 : Le déploiement de la 5G et les bandes allouées

Les opérateurs déploient donc une autre technologie, nommée DSS (Dynamic Spectrum Sharing) qui consiste à partager en temps réel les allocations de ressources radioélectriques entre une allocation 4G-LTE et une allocation 5G-NR sans impacter les utilisateurs 4G, c’est-à-dire en permettant aux terminaux 4G de pouvoir toujours exploiter la bande de fréquence LTE.

La technologie DSS est possible car la 5G se repose sur le LTE (beaucoup de similitudes : OFDM avec un espacement entre sous-porteuses identiques ou multiples de 2, précodage identique, modulation identique, …) toutefois cela impose le respect des contraintes suivantes :

  • pas d’interférence sur les signaux de références 4G : CRS et CSI-RS ;
  • pas d’interférence sur le canal de contrôle 4G-PDCCH ;
  • séparation des signaux de synchronisation PSS/SSS en 4G et du signal de synchronisation SSB en 5G. L’un et l’autre doivent être transmis sans interférence.

L’allocation des ressources 4G-LTE est gérée toute les 1 ms, les informations de contrôles 4G-PDCCH sont allouées sur toute la bande et l’allocation des signaux de références CRS et CSI-RS est assignée par un paramétrage statique qui dépend du nombre de port d’antennes supporté par la station de base 4G eNB.

Les signaux de références CRS sont transmis sur chaque bloc de ressources (12 sous porteuses) à raison de (figure 2) :

  • 4 éléments de ressources (RE) sur un slot (0,5 ms en 4G) pour une antenne ;
  • 8 RE sur un slot (0,5 ms en 4G) pour deux antennes ;
  • 12 RE sur un slot pour quatre antennes.

Pour plus d’information, se référer à l’article http://blogs.univ-poitiers.fr/f-launay/2021/02/18/cours-2-niveau-master-chap-1-part-3/

Figure 3 : La position des éléments de ressources 4G-CRS

Les signaux de références 4G-CRS permettent au mobile de mesurer le niveau de puissance de chaque cellule (serveuse et voisines) et d’en déduire ainsi la qualité du lien radioélectrique (RSRP, RSRQ). Pour ne pas fausser les mesures, il est proscrit de transmettre des données sur le même élément de ressource (allocation dans le domaine fréquentiel – sous porteuse – et temporel –symbole-) qu’un signal de référence. La configuration des signaux de références CRS dépendent du numéro PCI (Physical Cell Identifier) de la cellule et du nombre de ports d’antennes (permettant de faire du MIMO). L’ingénierie radioélectrique va s’assurer que les stations de base voisine (PCI) respectent cette contrainte.

Les signaux de référence 4G-CRS utilise 4,76% des ressources 4G-LTE pour un seul port d’antenne et atteint 14,29% de ressources LTE pour 4 ports d’antennes. Au-delà de 4 antennes, le signal de référence émis est le CSI-RS qui nécessite moins de ressources.

Le canal de contrôle PDCCH est transmis sur toute la bande 4G-LTE dans le domaine fréquentiel et sur un, deux ou trois symboles dans le domaine temporel. Le nombre de symboles du canal PDCCH est défini par la station de base eNB en fonction du trafic. Le mobile prend connaissance du nombre de symboles de la zone du canal de contrôle PDCCH à partir de l’information portée par le canal PCFICH (figure 4).

L’allocation des ressources pour la 5G-NR est plus flexible, les informations de contrôle 5G-PDCCH sont transmises dans des bloc CORESET (COntrol REsource SET). Toutefois, les signaux de référence 5G-NR ne doivent pas non plus être interférés par la transmission 4G.

Figure 4 : L’allocation des canaux sur le réseau LTE

Enfin, les signaux de synchronisation 4G PSS/SSS sont transmis avec une périodicité de 5 ms en milieu de bande et le canal de diffusion 4G PBCH est transmis en milieu de bande toutes les 10 ms.

Pour qu’un terminal mobile 4G ne soit pas perturbé par la méthode DSS, il faut obligatoirement respecter les contraintes précédentes : le partage de la bande radioélectrique 4G/5G ne peut se faire simultanément et sur les mêmes fréquences que les signaux 4G : CRS, PSS, SSS, PBCH et PDCCH.

La méthode DSS permet donc d’utiliser des éléments de ressources 4G-LTE sans interférer avec les canaux de contrôles et les signaux de références 4G pour transmettre un signal 5G sur les ressources non-utilisées. Toutefois, les ressources 4G non-exploitées doivent permettre la transmission des canaux de contrôle, du bloc de synchronisation 5G-SSB et des signaux de référence 5G.