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