EP4740119A1 - Procédé de gestion de la sécurité d'une connexion et dispositif électronique associé - Google Patents

Procédé de gestion de la sécurité d'une connexion et dispositif électronique associé

Info

Publication number
EP4740119A1
EP4740119A1 EP24734910.3A EP24734910A EP4740119A1 EP 4740119 A1 EP4740119 A1 EP 4740119A1 EP 24734910 A EP24734910 A EP 24734910A EP 4740119 A1 EP4740119 A1 EP 4740119A1
Authority
EP
European Patent Office
Prior art keywords
module
user terminal
security
avs
telecommunications network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24734910.3A
Other languages
German (de)
English (en)
Inventor
Charles Hartmann
Antoine Mouquet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of EP4740119A1 publication Critical patent/EP4740119A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
    • H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
    • H04L9/0844—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols with user authentication or key authentication, e.g. ElGamal, MTI, MQV-Menezes-Qu-Vanstone protocol or Diffie-Hellman protocols using implicitly-certified keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Multimedia (AREA)
  • Technology Law (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé de gestion de la sécurité d'une connexion entre un terminal utilisateur et un réseau de télécommunications, le procédé comprenant les étapes suivantes, mises en œuvre par un module de sécurité (AVS) du terminal utilisateur (UE) : une génération d'un historique d'évènements relatifs à la sécurité de ladite connexion; une analyse de l'historique généré; une transmission, à destination d'un module de contrôle (AVSC) du réseau de télécommunications, d'un résultat de l'analyse au travers d'une session sécurisée.

Description

    Procédé de gestion de la sécurité d’une connexion et dispositif électronique associé
  • La présente invention appartient au domaine général des télécommunications, et notamment des communications sans fil mises en œuvre sur des réseaux de type radio tels que des réseaux mobiles (ex. 2G, 3G, 4G, 5G, B5G – l’acronyme de « Beyond 5G » – etc.), etc. Elle concerne plus particulièrement un procédé de gestion de la sécurité d’une connexion entre un terminal utilisateur et un réseau de télécommunications. Elle concerne également un dispositif électronique configuré pour mettre en œuvre un tel procédé.
    •
  • Afin de s'adapter à la croissance continue et toujours plus rapide du trafic de données émises par les systèmes de télécommunications sans fil, différentes technologies sont aujourd'hui mises en œuvre, et font encore l'objet de perfectionnements en vue d'une exploitation optimale dans les années à venir.
  • L’architecture des réseaux de télécommunications sans fil actuellement déployés ou en cours de déploiement est définie par le consortium de standardisation connu sous le nom de 3GPP (Third Generation Partnership Project). C’est le cas notamment des réseaux sans fil dits de deuxième génération (« 2G ou GSM »), de troisième génération (« 3G »), et de quatrième génération (« 4G »).
  • Jusqu’à la quatrième génération, les architectures de réseau définies par le consortium 3GPP reposent le plus souvent sur des équipements spécifiques, dédiés à des fonctionnalités précises, que ce soit au niveau du réseau d’accès ou du cœur de réseau, notamment en ce qui concerne la transmission de paquets depuis ou à destination d’un terminal mobile.
  • Le manque de flexibilité et d’évolutivité inhérent à ce type d’architecture a conduit le consortium 3GPP à envisager l’adoption d’architectures plus flexibles pour la génération de réseaux sans fil dite « 5G », afin de pouvoir répondre rapidement à des demandes extrêmement diverses en termes de trafic et/ou de qualité de service.
  • Pour répondre à ces contraintes extrêmement diverses, la 5G s’appuie notamment sur le découpage des fonctions réseaux en services, et sur la virtualisation de ces fonctions réseaux. La virtualisation des fonctions réseaux consiste à déployer des fonctions habituellement satisfaites par des équipements dédiés et spécifiques sur des serveurs génériques situés dans des centres de données (« data center » selon la terminologie anglo-saxonne). Ces fonctions sont alors mises en œuvre sous la forme de programmes informatiques pouvant être facilement activés, désactivés et paramétrés en fonction des besoins. Les ressources en mémoire ou capacité de calcul peuvent alors être allouées de manière dynamique.
  • Ce découpage des fonctions réseaux en services vise, à terme, à faciliter le déploiement de la virtualisation du réseau cœur (CN) et du réseau d’accès radio (RAN). Plus généralement, un des objectifs du consortium 3GPP vise notamment à définir une architecture de réseau mobile qui permette aux équipements et/ou modules logiciels de différents fournisseurs de communiquer.
  • L’implication de différents fournisseurs de services pour mettre en œuvre une connexion entre un terminal utilisateur et un réseau de télécommunications engendre une perte de contrôle de la part de l’opérateur d’un réseau de télécommunications auquel un client a souscrit un abonnement. Cependant, il est important pour l’opérateur de pouvoir s'assurer de la mise en œuvre effective, sur l'ensemble du réseau, d’une politique de sécurité préalablement déterminée.
  • Par ailleurs, même si un opérateur configure de manière correcte les différents équipements de son réseau de télécommunication, un équipement ou une fonction réseau peut être compromis et sa sécurité altérée sans que l'opérateur n'en soit alerté. Dans le cadre de la 5G, ce risque est accru par l’augmentation du nombre de stations de base nécessaires afin de pouvoir prendre en charge des niveaux plus élevés de trafic de données, et par la complexité croissante des modèles opérationnels.
  • Enfin, un utilisateur d’un terminal en itinérance (“roaming” selon la terminologie anglo-saxonne) est typiquement tributaire de la politique de sécurité définie par l’opérateur de réseau en charge du réseau de télécommunications visité. Un accord d’itinérance dans lequel sont définies des mesures de sécurité est généralement établi entre l’opérateur auprès duquel l’utilisateur a souscrit un abonnement et l’opérateur en charge du réseau de télécommunications visité, mais dans cette situation, il est également important pour l’opérateur auprès duquel l’utilisateur a souscrit un abonnement de pouvoir s'assurer de la mise en œuvre effective, sur l'ensemble du réseau, d’une politique de sécurité préalablement déterminée.
  • La présente invention a pour objectif de remédier à tout ou partie des inconvénients de l’art antérieur, notamment ceux exposés ci-avant, en proposant une solution qui permette à un opérateur de réseau de télécommunications auprès duquel un client a souscrit un abonnement, de vérifier si une politique de sécurité donnée est effectivement mise en œuvre sur un réseau utilisé par ce client, quand bien même certaines fonctions et/ou équipements dudit réseau ne sont pas directement sous le contrôle dudit opérateur.
  • L'invention peut également contribuer à l'automatisation des tests de sécurité, pendant les phases d'expérimentation (vérification d'aptitude au bon fonctionnement réalisée sur une configuration représentative du réseau, tests dans des zones expérimentales avec des terminaux de tests ou commerciaux) ou être utilisée pour le suivi des phases de mise en production de nouvelles fonctionnalités ou de nouveaux équipements.
  • Dans certains cas d'usage, l'invention est également mise en œuvre à des fins de diagnostic ou de résolution d'un ticket d'incident de sécurité ouvert par un client.
  • À cet effet, et selon un premier aspect, l’invention concerne un procédé de gestion de la sécurité d’une connexion entre un terminal utilisateur et un réseau de télécommunications géré par un opérateur de télécommunications, le procédé comprenant :
    • une génération, par un module de sécurité du terminal utilisateur, d’un historique d’évènements relatifs à la sécurité de ladite connexion, le module de sécurité étant géré par l’opérateur de télécommunications;
    • une analyse, par le module de sécurité, de l’historique généré ; et,
    • une transmission, par le module de sécurité et à destination d’un module de contrôle du réseau de télécommunications, d’un résultat de l’analyse au travers d’une session sécurisée, le module de contrôle étant géré par l’opérateur de télécommunications.
  • De manière générale, on considère que les étapes d’un procédé ne doivent pas être interprétées comme étant liées à une notion de succession temporelle.
  • Dans des modes particuliers de mise en œuvre, le procédé de gestion peut comporter en outre l’une ou plusieurs des caractéristiques suivantes, prises isolément ou selon toutes les combinaisons techniquement possibles.
  • Dans des modes particuliers de mise en œuvre, la sécurité n’est gérée que sur une portion de la connexion entre le terminal utilisateur et le réseau de télécommunications. Ainsi, selon un premier exemple, la sécurité est gérée sur la connexion entre le terminal utilisateur et une station de base à laquelle ledit terminal utilisateur est accroché. Selon un deuxième exemple, la sécurité est gérée sur la connexion entre le terminal utilisateur et une unité – e.g., distribuée (O-DU) ou centralisée (O-CU) – du réseau d’accès radio du réseau de télécommunications ou d’un réseau de télécommunications visité. Selon un troisième exemple, la sécurité est gérée sur la connexion entre le terminal utilisateur et un module « fonction de plan utilisateur » ( « User Plane Function », UPF, selon la terminologie anglo-saxonne) du réseau cœur du réseau de télécommunications.
  • Ce module « fonction de plan utilisateur » agit alors comme une passerelle entre le réseau d’accès radio (RAN) et un réseau de données (DN), tel que l’Internet ou un réseau local/privé.
  • Dans des modes particuliers de mise en œuvre, le terminal utilisateur est connecté au réseau de télécommunications au travers d’un réseau de télécommunications visité géré par un autre opérateur de télécommunications, et l’historique d’évènements comprend des données relatives à la sécurité dudit réseau de télécommunications visité.
  • Ledit réseau de télécommunication correspond alors au réseau dit « nominal » ou  « home » selon la terminologie anglo-saxonne.
  • Cette caractéristique offre l’avantage de permettre de détecter d'éventuelles anomalies dans les contrôles de sécurité relevant de la responsabilité de l'autre opérateur. En effet, cet autre opérateur (dit opérateur partenaire) gère la configuration de ses équipements (version matérielles et logicielles, paramètres de configuration des équipements), mais certains paramètres peuvent être mal configurés et devenir inopérants dans leurs effets (e.g., incompatibilités des paramètres, incompatibilités avec les logiciels installés, etc.).
  • Dans des modes particuliers de mise en œuvre, lesdites données incluent des données relatives au chiffrement et/ou au contrôle d’intégrité de la connexion entre ledit terminal utilisateur et une station de base du réseau de télécommunications visité et à laquelle ledit terminal utilisateur est connecté.
  • Dans des modes particuliers de mise en œuvre, le procédé comprend en outre une transmission, par le module de sécurité, d’une pluralité de requêtes de test de paramètres de sécurité à destination du réseau de télécommunications ou d’un réseau de télécommunications visité géré par un autre opérateur de télécommunications, et l’analyse comprend une détermination d’un comportement du réseau de télécommunications ou du réseau de télécommunications visité en réponse aux transmissions.
  • Dans des modes particuliers de mise en œuvre, l’analyse comprend la détermination d’un score représentatif d’un degré de sécurité de ladite connexion en fonction de l’historique généré.
  • Dans des modes particuliers de mise en œuvre, le procédé comprend en outre :
    • une réception, par un module radio du terminal utilisateur, d’un message de signalisation en provenance du réseau de télécommunications ou d’un réseau de télécommunications visité géré par un autre opérateur de télécommunications ; et,
    • un accès, par le module de sécurité, au message de signalisation au travers d’une interface de programmation d'application fournie par le module radio.
  • Dans des modes particuliers de mise en œuvre, l’accès à l’API est sécurisé par un algorithme de chiffrement.
  • Dans des modes particuliers de mise en œuvre, le terminal utilisateur comprend un deuxième module de sécurité, le module de sécurité – dit premier module de sécurité – et le deuxième module de sécurité étant isolés l’un de l’autre, le procédé comprenant en outre, suite à une réception, par un module radio du terminal utilisateur d’un message de signalisation, une détermination, par le module radio, d’un module de sécurité destinataire parmi le premier module de sécurité et le deuxième module de sécurité.
  • Dans des modes particuliers de mise en œuvre, les premier et deuxième modules de sécurité sont gérés par un même opérateur de télécommunications. En variante, les premier et deuxième modules de sécurité sont gérés par des opérateurs de télécommunications distincts.
  • Dans des modes particuliers de mise en œuvre, la session est sécurisée par une utilisation de protocoles « Non Access Stratum » entre le module de sécurité et un module de gestion d’accès et de mobilité dudit réseau de télécommunications ou d’un réseau de télécommunications visité ; ou une utilisation d’un protocole de transfert hypertextuel sécurisé entre le module de sécurité et le module de contrôle.
  • Dans des modes particuliers de mise en œuvre, le module de gestion d’accès et de mobilité est configuré pour enregistrer les terminaux utilisateurs, et pour gérer une localisation desdits terminaux utilisateurs sur ledit réseau de télécommunications (3GPP et/ou non 3GPP).
  • Dans des modes particuliers de mise en œuvre, le réseau de télécommunications est conforme à la cinquième génération (5G ou 5GS), et le module de gestion d’accès et de mobilité du réseau de télécommunications correspond à l’entité AMF (acronyme de « Access and Mobility Management Function »).
  • Dans des modes particuliers de mise en œuvre, le module de sécurité inclut une interface de programmation d'application (ou API) comprenant une fonction d’accès à l’historique d’évènements et/ou au résultat de l’analyse, ladite interface de programmation d'application étant accessible par une application informatique du terminal utilisateur.
  • Ces caractéristiques sont avantageuses en ce qu’elles permettent à une application informatique du terminal utilisateur de communiquer avec le module de sécurité, sans avoir à connaître les détails de mise en œuvre des fonctions de ce module. En outre, ces caractéristiques permettent de présenter les fonctions mises en œuvre par le module de sécurité comme des services accessibles au travers du protocole HTTP/1.1 ou HTTP/2.
  • Dans des modes particuliers de mise en œuvre, l’interface de programmation d’application est de type REST.
  • L’utilisation d’une API de type REST (l’acronyme de « REpresentational State Transfer », ou transfert d’état de représentation en français) est avantageuse en ce qu’elle constitue un moyen de communication standardisé utilisant le protocole HTTP entre le module de sécurité et l’application informatique du terminal utilisateur.
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’au moins une parmi :
    • une donnée relative à une utilisation d’un protocole d’authentification pour au moins une portion de la connexion entre le terminal utilisateur et ledit réseau de télécommunications, telle que la portion de connexion entre le terminal utilisateur et une station de base à laquelle ledit terminal utilisateur est connecté ;
    • une donnée relative à une utilisation d’un algorithme de chiffrement pour au moins une portion de la connexion entre le terminal utilisateur et le réseau de télécommunications, telle que la portion de connexion entre le terminal utilisateur et une station de base à laquelle ledit terminal utilisateur est connecté ;
    • une donnée relative au contrôle d’intégrité mis en œuvre par le terminal utilisateur et/ou une station de base à laquelle ledit terminal utilisateur est connecté ;
    • une donnée relative à une utilisation d’un algorithme de chiffrement pour chiffrer des données de contexte du terminal utilisateur ;
    • une modification d’un identifiant temporaire du terminal utilisateur ;
    • une transmission, par le terminal utilisateur, d’un identifiant IMSI (l’acronyme de « International Mobile Subscriber Identity »), ou d’un identifiant SUCI (l’acronyme de « Subscription Concealed Identifier »);
    • une donnée relative à un chiffrement ou à un contrôle d’intégrité d’une couche PDCP ;
    • une donnée relative à une commutation de contexte dans le cadre d’un transfert intercellulaire (ou « handover » selon la terminologie anglo-saxonne) ;
    • une donnée relative à la sécurité des protocoles « Non Access Stratum » employés entre le terminal utilisateur et le réseau de télécommunications ;
    • une donnée relative au basculement d’une connexion vers une connexion de génération antérieure ; et,
    • une donnée issue de la réception de messages en provenance d’une cellule voisine de la cellule dans laquelle se situe ledit terminal utilisateur ;
  • Selon un deuxième aspect, l’invention concerne un programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé de gestion, lorsque ledit programme est exécuté par un processeur.
  • Selon un troisième aspect, l’invention concerne un support d’enregistrement lisible par un ordinateur sur lequel est enregistré le programme d’ordinateur selon l’invention.
  • Selon un quatrième aspect, l’invention concerne un dispositif électronique apte à gérer la sécurité d’une connexion entre un terminal utilisateur et un réseau de télécommunications géré par un opérateur de télécommunications,
  • le dispositif électronique comprenant un module de sécurité géré par l’opérateur de télécommunications, le module de sécurité comprenant :
    • un sous-module de génération d’un historique d’évènements relatifs à la sécurité de ladite connexion ;
    • un sous-module d’analyse de l’historique généré ;
    • un sous-module de transmission, à destination d’un module de contrôle géré par ledit opérateur de télécommunications et appartenant audit réseau de télécommunications, d’un résultat de ladite analyse au travers d’une session sécurisée.
  • Dans des modes particuliers de mise en œuvre, le dispositif électronique est un élément sécurisé incluant une application gérée par l’opérateur de télécommunications, et l’application comprend le module de sécurité.
  • Dans des modes particuliers de mise en œuvre, le dispositif électronique est un terminal utilisateur et le module de sécurité est déployé dans un environnement d’exécution sécurisé dudit terminal utilisateur.
  • Selon un cinquième aspect, l’invention concerne un système de communication comprenant un dispositif électronique selon l’invention, et un autre dispositif électronique comprenant un module de contrôle, le module de contrôle comprenant :
    • un sous-module de réception, en provenance du module de sécurité du premier dispositif électronique, d’un résultat de ladite analyse au travers d’une session sécurisée ; et,
    • un sous-module de vérification de la sécurité de la connexion en fonction dudit résultat.
  • D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
  • la est un premier exemple de système de communication sans fil dans lequel un procédé de gestion selon l’invention est mis en œuvre ;
  • la est un deuxième exemple de système de communication sans fil dans lequel un procédé de gestion selon l’invention est mis en œuvre ;
  • la est un troisième exemple de système de communication sans fil dans lequel un procédé de gestion selon l’invention est mis en œuvre ;
  • la représente schématiquement des sous-modules d’un module de sécurité embarqué dans un terminal utilisateur, selon un exemple de mise en œuvre de l’invention ;
  • la représente un exemple d’architecture matérielle d’un dispositif électronique dans lequel est embarqué un module de sécurité ;
  • la représente schématiquement des sous-modules d’un module de contrôle, selon un exemple de mise en œuvre de l’invention ;
  • la représente un exemple d’architecture matérielle d’un dispositif électronique comprenant un module de contrôle ; et,
  • la illustre, sous forme d’ordinogramme, un exemple de gestion de la sécurité d’une connexion entre un terminal utilisateur et un réseau de télécommunications.
    •
  • La est un exemple de système de communication sans fil dans lequel un procédé de gestion selon l’invention est mis en œuvre.
  • Ce système comprend un réseau de télécommunications (HPMN) – également nommé « réseau de télécommunications nominal » dans la suite de la description – incluant un réseau d’accès radio (RAN) et un réseau cœur (CN) connecté au réseau d’accès radio (RAN). Le réseau d’accès radio (RAN) comprend au moins une station de base. Le système de communication comprend en outre au moins un terminal utilisateur (UE) connecté au réseau d’accès radio (RAN).
  • Dans le présent mode de réalisation, et à des fins de simplification de la description, il est considéré que le système de communication sans fil comporte un unique terminal utilisateur (UE), ainsi qu’un réseau d’accès radio (RAN) comprenant un unique dispositif émetteur (gNB). Il convient cependant de noter qu'aucune limitation n'est attachée au nombre de dispositifs émetteurs (gNB) ou au nombre de terminaux utilisateurs (UE). Les développements qui suivent sont en effet généralisables sans difficulté par l'homme du métier au cas où plus d’un dispositif émetteur (gNB) et un terminal utilisateur (UE) sont considérés.
  • Le terminal utilisateur (UE), le réseau d’accès radio (RAN) et le réseau cœur (CN) appartiennent à un réseau de télécommunications sans fil et sont aptes à communiquer entre eux dans une bande fréquentielle associée à ce réseau de télécommunications sans fil. Pour la suite de la description, on considère de manière non limitative que ledit réseau de télécommunications est un réseau mobile de type 5G ou 5GS (la cinquième génération de normes de réseau de téléphonie mobile). Il convient toutefois de préciser que l'invention reste applicable à d'autres types de réseau de télécommunications, comme par exemple un réseau mobile 4G (la quatrième génération de normes de réseau de téléphonie mobile), et/ou B5G (acronyme de "Beyond 5G").
  • A titre d’exemple, le réseau d’accès radio (RAN) est par exemple conforme à la spécification 3GPP TS 38.401, « NG-RAN; Architecture description », version 17.4.0 publiée le 3 avril 2023. L’architecture de réseau d’accès radio définie par le consortium 3GPP vise à faciliter le déploiement de la virtualisation du réseau d’accès radio (RAN), et à permettre aux équipements et/ou modules logiciels de différents fournisseurs de communiquer entre eux.
  • En variante, le réseau d’accès radio (RAN) est par exemple conforme au paradigme C-RAN (« Cloud-RAN »). Cette architecture combine la virtualisation et la centralisation des fonctionnalités d’une station de base au moyen de l’informatique en nuage (« cloud computing » selon la terminologie anglo-saxonne). Dans une architecture C-RAN, les unités de traitement (« baseband units » selon la terminologie anglo-saxonne) ne sont plus situées à proximité immédiate de la station de base, mais sont délocalisées et centralisées au sein d’un ensemble centralisé (« BBU pool » selon la terminologie anglo-saxonne).
  • En variante, le réseau d’accès radio (RAN) est par exemple conforme au paradigme V-RAN (« Virtual-RAN »). Un réseau d'accès radio virtuel (vRAN) est un réseau d’accès radio (RAN) dont les fonctions réseau sont déployées comme des instances virtualisées situées à différents endroits sur le réseau, par exemple en fonction d’une stratégie de déploiement de l’opérateur de télécommunications. Cette approche offre l’avantage de limiter l’utilisation d’équipements coûteux, et permet de créer des sous-réseaux isolés (« slices » selon la terminologie anglo-saxonne), qui coexistent simultanément sur les mêmes équipements matériels.
  • Ainsi, ce réseau d’accès radio (RAN) comprend au moins une station de base dont les fonctions réseaux sont déployées sur – ou à proximité immédiate – d’un même équipement, ou virtualisées et déployées sur des équipements distants. Une station de base est parfois nommée "nodeB" dans les réseaux 3G, "eNodeB" selon la norme LTE (acronyme de "Long Term Evolution") et "gNB" dans les réseaux 5G.
  • Tel qu'illustré par la , le réseau cœur (CN) comprend un module “fonction de plan utilisateur” (UPF) connecté au réseau d’accès radio RAN au travers d’une interface N3. Ce module “fonction de plan utilisateur” (UPF) est également connecté à un réseau de données DN (tel que l’Internet ou un réseau local/privé) au travers d’une interface N6.
  • Le module “fonction de plan utilisateur” correspond par exemple au module UPF défini par la spécification 3GPP 23.501 « System architecture for the 5G System (5GS) », version 18.1.0, publiée le 5 avril 2023. Dans ce cas, le module “fonction de plan utilisateur” (UPF) est configuré pour acheminer des données en provenance du terminal utilisateur (UE) à travers le réseau cœur (CN). Plus spécifiquement, ce module “fonction de plan utilisateur” agit comme une passerelle entre le réseau d’accès radio (RAN) et un réseau de données (DN) du réseau cœur (CN).
  • Le réseau cœur (CN) comprend en outre un module (AMF) de gestion d’accès et de mobilité du réseau de télécommunications connecté au réseau d’accès radio (RAN) au travers d’une interface N2. Ce module (AMF) de gestion d’accès et de mobilité correspond par exemple au module AMF défini par la spécification 3GPP TS 23.501 « System architecture for the 5G System (5GS) », version 18.1.0 publiée le 5 avril 2023 et/ou par la spécification TS 33.501 «Security architecture and procedures for 5G System », version 18.1.0, publiée le 30 mars 2023. Dans ce cas, le module (AMF) de gestion d’accès et de mobilité est configuré pour contrôler les terminaux utilisateurs (UE) souhaitant accéder au réseau de télécommunications (HPMN) pour échanger des données au travers du réseau de données DN.
  • Dans le cas où les terminaux utilisateurs sont mobiles, ce module AMF est également en charge de gérer un changement de cellule (e.g., un basculement d’une station de base à une autre), tout en veillant à ce que le transfert de données ne soit pas interrompu.
  • Ce module AMF est connecté au travers d’une interface N8 à un module (UDM) de gestion de profils d’utilisateurs. Ce module de gestion de profils d’utilisateurs correspond par exemple au module UDM défini par la spécification 3GPP TS 29.503, « 5G System; Unified Data Management Services; Stage 3 », version 18.1.0, publiée le 29 mars 2023. Dans ce cas, le module UDM (acronyme de « Unified Data Management ») est configuré pour gérer le profil associé au terminal utilisateur UE.
  • Le réseau cœur comprend également un module (AVSC) de contrôle de la sécurité d’une connexion entre le terminal utilisateur (UE) et le réseau cœur (CN) dont les fonctionnalités sont décrites en référence à la . Ce module (AVSC) de contrôle est géré par l’opérateur de télécommunications auprès duquel l’utilisateur du terminal utilisateur (UE) a souscrit un abonnement, c’est-à-dire l’opérateur nominal en charge du réseau de télécommunications dit « réseau home » en cas d’itinérance.
  • Tel qu’illustré par la , le système de communication comprend en outre un terminal utilisateur (UE). Le terminal utilisateur (UE) correspond par exemple à un ordinateur portable, un assistant personnel, un objet connecté, ou un téléphone mobile de type « smartphone ».
  • Ce terminal utilisateur (UE) comprend un élément sécurisé de type carte UICC (l’acronyme de « Universal Integrated Circuit Card ») dans laquelle est déployée une application USIM (l’acronyme de « Universal Subscriber Identity Module ») comprenant les paramètres d’un abonnement souscrit auprès de l’opérateur de télécommunications en charge du réseau de télécommunications HPMN. Cet élément sécurisé (UICC) est connecté à un module radio (BP) également nommé « processeur de bande de base » et fournissant des interfaces de programmation d'application (API) afin de permettre aux applications du terminal utilisateur (UE) d’accéder à des données contrôlées – voire stockées – par ce module radio. Ces API sont par exemple de type REST, et leur accès est sécurisé par l’utilisation de clefs de chiffrement.
  • Le terminal utilisateur (UE) comprend également un environnement sécurisé et référencé TEE, l’acronyme de « Trusted Execution Environment ». Cet environnement sécurisé est isolé d’autres environnements d’exécutions, et typiquement exécuté en parallèle d’un environnement d’exécution standard (e.g., Android ou iOS (marques déposées)). Cet environnement sécurisé offre un ensemble de garanties telles que l’intégrité du code exécuté, l’utilisation de communications sécurisées, un stockage sécurisé. Cet environnement est par exemple basé sur la technologie TrustZone d’ARM (marques déposées), ou sur la technologie « Trusted Foundations » développée par Trusted Logic (marques déposées).
  • Cet environnement sécurisé (TEE) inclut un module de sécurité (AVS) géré par l’opérateur de télécommunications auprès duquel l’utilisateur du terminal utilisateur (UE) a souscrit un abonnement, et dont les fonctionnalités sont décrites en référence à la . Ce module de sécurité (AVS) comprend au moins une application (APP). Dans des modes particuliers de mise en œuvre, le module de sécurité (AVS) fournit au moins une interface de programmation d’application (API) afin de pouvoir exposer des fonctions aux autres applications du terminal utilisateur (UE), sans que ces dernières n’aient à connaître les détails d’implémentation de ces fonctions. Ces fonctions exposées visent par exemple à permettre l’accès à un historique d’évènements et/ou au résultat d’analyse de la sécurité d’au moins une portion de connexion, voire à permettre un affichage de ces données sur le terminal utilisateur (UE) au travers d’une interface graphique.
  • La est un deuxième exemple de système de communication sans fil dans lequel un procédé de gestion selon l’invention est mis en œuvre. Le réseau de télécommunications HPMN est similaire à celui décrit en référence à la , et n’est donc pas redécrit, par soucis de concision.
  • Tel illustré en , le terminal utilisateur (UE) comprend un élément sécurisé de type carte UICC (l’acronyme de « Universal Integrated Circuit Card ») dans lequel est déployée une application USIM (l’acronyme de « Universal Subscriber Identity Module ») comprenant les paramètres d’un abonnement souscrit auprès de l’opérateur de télécommunications en charge du réseau de télécommunications HPMN.
  • Cet élément sécurisé (UICC) inclut également un module de sécurité (AVS) géré par l’opérateur de télécommunications auprès duquel l’utilisateur du terminal utilisateur (UE) a souscrit un abonnement, et dont les fonctionnalités sont décrites en référence à la . Ce module de sécurité (AVS) comprend au moins une application (APP). Dans des modes particuliers de mise en œuvre, le module de sécurité (AVS) fournit au moins une interface de programmation d’application (API), afin de pouvoir exposer des fonctions aux autres applications du terminal utilisateur (UE), sans que ces dernières n’aient à connaître les détails d’implémentation de ces fonctions.
  • Cet élément sécurisé (UICC) est connecté à un module radio (BP) également nommé « processeur de bande de base » et fournissant des interfaces de programmation d'application (API) afin de permettre aux applications du terminal utilisateur (UE) d’accéder à des données contrôlées – voire stockées – par ce module radio.
  • Jusqu’à présent, l’élément sécurisé a été décrit comme une carte de type UICC. L’invention n’en reste pas moins applicable dans le cas où cet élément sécurisé est un élément sécurisé dit « embarqué » (« embedded secure element » selon la terminologie anglo-saxonne), c’est-à-dire une puce distincte du processeur du terminal utilisateur (UE) et qui contient un processeur sécurisé et un stockage inviolable. L’invention n’en reste pas moins également applicable dans le cas où cet élément sécurisé est un élément sécurisé dit « intégré », iUICC, actuellement en cours de développement par l'industrie et la GSMA (acronyme de GSM Association).
  • La est un troisième exemple de système de communication sans fil dans lequel un procédé de gestion selon l’invention est mis en œuvre.
  • Tel qu’illustré par la , le système comprend un terminal utilisateur (UE). Ce terminal est similaire à celui décrit en référence à la ou à la , et n’est donc pas redécrit, par soucis de concision.
  • Ce terminal utilisateur (UE) est connecté à un réseau de données (DN) géré par l’opérateur du réseau de télécommunications au travers d’un réseau de télécommunications dit « visité » et référencé VPMN. Ce réseau visité VPNM comprend un réseau d’accès radio (RAN) incluant au moins une station de base (gNB), ainsi qu’un réseau cœur visité (VCN). Le réseau d’accès radio (RAN) et ce réseau cœur visité (VCN) sont connectés entre eux au travers d’une interface N3. Le réseau cœur visité (CNV) comprend un module “fonction de plan utilisateur” VUPF. Le module “fonction de plan utilisateur” VUPF correspond par exemple à un module UPF tel que défini par la spécification 3GPP 23.501 « System architecture for the 5G System (5GS) », version 18.1.0, publiée le 5 avril 2023. Dans ce cadre, le module “fonction de plan utilisateur” VUPF est par exemple configuré pour acheminer des données entre le terminal utilisateur (UE) et un module “fonction de plan utilisateur” (HUPF) du réseau cœur (HCN) du réseau de télécommunications (HPMN) au travers d’une interface N9.
  • Le réseau cœur visité (VCN) comprend en outre un module (AMF) de gestion d’accès et de mobilité du réseau de télécommunications visité (VPMN), ce module étant similaire à celui du même nom décrit en référence à la .
  • Le réseau de télécommunications visité (VPMN) est également connecté au réseau de télécommunications (HPMN) auprès duquel l’utilisateur du terminal utilisateur (UE) a souscrit un abonnement au travers d’un réseau IPX. Ce réseau IPX est par exemple conforme à la spécification IR.34, «  Guidelines for IPX Provider networks », version 17.0, publiée le 18 mai 2021 par la GSM Association. Ce réseau IPX est typiquement de type IP et permet d’interconnecter plusieurs opérateurs de télécommunications, dont les conditions de raccordement et service sont définis dans le cadre d’accords commerciaux.
  • Comme évoqué précédemment, le réseau de télécommunications HPMN comprend un réseau cœur (HCN) incluant un module “fonction de plan utilisateur” (HUPF). Le module “fonction de plan utilisateur” (HUPF) correspond par exemple à un module UPF tel que défini par la spécification 3GPP 23.501 « System architecture for the 5G System (5GS) », version 18.1.0, publiée le 5 avril 2023. Dans ce cadre, le module “fonction de plan utilisateur” (HUPF) est configuré pour acheminer des données entre le réseau visité (VPMN) et un réseau de données (DN) du réseau de télécommunications (HPMN) au travers d’une interface N6.
  • Le réseau cœur (HCN) du réseau de télécommunications HPMN comprend en outre un module AVSC et un module (UDM) de gestion de profils utilisateurs, ces modules étant similaires à ceux du même nom décrit en référence à la .
  • En variante, les données en provenance du terminal utilisateur (UE) ne sont plus acheminées vers un réseau de données (DN) du réseau de télécommunication HPMN, mais le module “fonction de plan utilisateur” VUPF du réseau de télécommunications visité est alors configuré pour acheminer des données entre le terminal utilisateur (UE) et un réseau de données (non représenté) connecté audit réseau de télécommunications visité VPMN.
  • La représente schématiquement des sous-modules d’un module de sécurité (AVS) embarqué dans un terminal utilisateur (UE), selon un exemple de mise en œuvre de l’invention.
  • Tel qu’illustré par la , le terminal utilisateur (UE) embarque un module de sécurité (AVS). Ce module de sécurité (AVS) est géré par l’opérateur du réseau de télécommunications, et comprend les sous-modules MOD_GEN, MOD_DET et MOD_TX dont les fonctionnalités sont décrites en référence à la .
  • La représente un exemple d’architecture matérielle d’un dispositif électronique, tel qu’un terminal utilisateur (UE) ou un élément sécurisé de type carte UICC ou eSE, dans lequel est embarqué un module de sécurité (AVS).
  • Tel qu’illustré par la , le dispositif électronique dispose de l’architecture matérielle d’un ordinateur. Ainsi, le dispositif électronique comporte, notamment, un processeur 1, une mémoire vive 2, une mémoire morte 3 et une mémoire non volatile 4. Il comporte en outre un module de communication 5.
  • La mémoire morte 3 ou la mémoire non-volatile 4 du dispositif électronique constitue un support d’enregistrement tel que proposé, lisible par le processeur 1 et sur lequel est enregistré un programme d’ordinateur PROG_AVS conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé de gestion tel que proposé ci-après. Le programme PROG_AVS définit un ou plusieurs sous-modules fonctionnels du terminal utilisateur, qui s’appuient sur ou commandent les éléments matériels 1 à 5 cités précédemment, et qui comprennent notamment :
    • un sous-module MOD_GEN de génération d’un historique d’évènements relatifs à la sécurité d’une connexion ;
    • un sous-module MOD_DET d’analyse de l’historique généré ;
    • un sous-module MOD_TX de transmission, à destination d’un module de contrôle (AVSC) géré par l’opérateur du réseau de télécommunications et appartenant audit réseau de télécommunications, d’un résultat de ladite analyse au travers d’une session sécurisée.
  • Par ailleurs, le dispositif électronique peut encore comporter d’autres modules, notamment pour mettre en œuvre des modes particuliers du procédé de gestion, comme cela est décrit plus en détail ultérieurement.
  • La représente schématiquement des sous-modules d’un module de contrôle (AVS) d’un dispositif électronique, selon un exemple de mise en œuvre de l’invention.
  • Tel qu’illustré par la , un dispositif électronique (DE) embarque un module de contrôle (AVSC). Ce dispositif électronique (DE) correspond par exemple à un serveur contrôlé par l’opérateur auprès duquel l’utilisateur a souscrit un abonnement. Le module de contrôle (AVSC) est géré par l’opérateur du réseau de télécommunications auprès duquel l’utilisateur a souscrit un abonnement, et comprend les sous-modules MOD_RX et MOD_VER dont les fonctionnalités sont décrites en référence à la .
  • La représente un exemple d’architecture matérielle d’un dispositif électronique (DE) comprenant un module de contrôle (AVSC).
  • Tel qu’illustré par la , le dispositif électronique (DE) dispose de l’architecture matérielle d’un ordinateur. Ainsi, le dispositif électronique (DE) comporte, notamment, un processeur 1, une mémoire vive 2, une mémoire morte 3 et une mémoire non volatile 4. Il comporte en outre un module de communication 5.
  • La mémoire morte 3 ou la mémoire non volatile 4 du dispositif électronique (DE) constitue un support d’enregistrement tel que proposé, lisible par le processeur 1 et sur lequel est enregistré un programme d’ordinateur PROG_AVSC conforme à l’invention, comportant des instructions pour l’exécution d’étapes du procédé de gestion tel que proposé ci-après. Le programme PROG_AVSC définit un ou plusieurs sous-modules fonctionnels du dispositif électronique (DE), qui s’appuient sur ou commandent les éléments matériels 1 à 5 cités précédemment, et qui comprennent notamment :
    • un sous-module MOD_RX de réception, en provenance d’un module de sécurité (AVS) d’un autre dispositif électronique, d’un résultat de ladite analyse au travers d’une session sécurisée; et,
    • un sous-module MOD_VER de vérification de la sécurité de la connexion en fonction dudit résultat.
  • Par ailleurs, le dispositif électronique (DE) peut encore comporter d’autres modules, notamment pour mettre en œuvre des modes particuliers du procédé de gestion, comme cela est décrit plus en détail ultérieurement.
  • La illustre, sous forme d’ordinogramme, un exemple de gestion de la sécurité d’une connexion entre un terminal utilisateur (UE) et un réseau de télécommunications.
  • Les étapes S100 à S240 correspondent à des étapes de configuration d’un module de sécurité (AVS) au sein d’un terminal utilisateur (UE). Lors de cette configuration, le module (UDM) de gestion de profils d'utilisateurs utilise par exemple la procédure « UE Parameters Update ». Cette procédure est notamment définie dans la spécification 3GPP TS 33.501, version 18.1.1 publiée le 30 mars 2023, pour fournir au terminal utilisateur (UE) des données de configurations.
  • Dans des modes particuliers de mise en œuvre, ces données de configuration incluent un « nom de domaine pleinement qualifié » (« fully qualified domain name », FQDN, selon la terminologie anglo-saxonne) ou un identifiant uniforme de ressource (« Uniform Resource Identifier » selon la terminologie anglo-saxonne) associé au module de contrôle (AVSC).
  • Dans des modes particuliers de mise en œuvre, ces données de configuration incluent des données permettant d’instancier un module de sécurité (AVS) sur un terminal utilisateur (UE).
  • Dans des modes particuliers de mise en œuvre, ces données de configuration incluent un nom de réseau de données (« Data Network Name, DNN » selon la terminologie anglo-saxonne), ainsi qu’un identifiant de type S-NSSAI, les DNN et S-NSSAI fournissant à eux deux l’accès à un réseau de données permettant d’accéder à un module de contrôle (AVSC). Ainsi, les DNN et S-NSSAI sont utilisés pour initier une session PDU (acronyme de « Protocol Data Unit », « unité de données de protocole » en français) connectant le module de sécurité (AVS) et le module de contrôle (AVSC).
  • Tel qu’illustré par la figure 6, le procédé comprend une première étape S10 au cours de laquelle le terminal utilisateur (UE) transmet, à destination du module AMF, une requête d’enregistrement REG REQ reçue lors d’une étape référencée S20. Cette étape S20 déclenche la transmission S30, par le module AMF et à destination du module UDM, d’une requête d’enregistrement par exemple conforme au protocole « Nudm_UECM_Registration » tel que décrit dans la spécification ETSI TS 129 503, « 5G; 5G System; Unified Data Management Services; Stage 3 », v17.10.0, publiée en avril 2023 (3GPP TS 29.503 version 17.10.0 Release 17). Cette requête d’enregistrement est alors reçue lors d’une étape S40 par le module UDM, qui déclenche une étape S100 d’initialisation. Au cours de cette étape S100, il est déterminé si des données de configuration d’un module de sécurité (AVS) doivent être envoyées à l’UE, par exemple parce que le terminal utilisateur (UE) se connecte pour la première fois au réseau de télécommunications, ou bien parce qu’il n’a jamais reçu les données de configuration ou encore parce que ces données ont été modifiées depuis le dernier envoi à l’UE. Cette étape est mise en œuvre par le module (UDM) de gestion de profils utilisateurs appartenant au réseau de télécommunications.
  • Lors de cette étape S100 d’initialisation, le module (UDM) de gestion de profils utilisateurs obtient ces données de configuration associées à un module de sécurité (AVS). Ces données de configuration sont par exemple reçues en provenance d’un module de contrôle (AVSC) du réseau de télécommunications, suite à la transmission d’une requête transmise par le module UDM à destination du module AVSC et visant à obtenir de telles données.
  • Le procédé de gestion comprend en outre une étape S110 au cours de laquelle le module (UDM) de gestion de profils utilisateurs transmet ces données de configuration à destination d’un module (AMF) de gestion d’accès et de mobilité du réseau de télécommunications, au travers d’une interface N8. Ces données sont reçues par le module (AMF) de gestion d’accès et de mobilité lors d’une étape S120, puis retransmises à destination du module radio (BP) du terminal utilisateur (UE) en utilisant par exemple les protocoles « Non Access Stratum » (NAS), lors d’une étape S130.
  • Les données de configuration transmises en utilisant par exemple les protocoles NAS sont reçues par le module radio (BP) du terminal utilisateur (UE) lors d’une étape S140.
  • L’étape S150 correspond à un test au cours duquel il est déterminé si un module de sécurité (AVS) a préalablement été instancié sur ledit terminal utilisateur (UE) par l’opérateur de télécommunications. Si tel est le cas, les données de configuration sont transmises à destination du module de sécurité (AVS), lors d’une étape S160, puis reçues par ce même module de sécurité (AVS) lors d’une étape S170. Puis, lors d’une étape S180-1 de configuration, le module de sécurité (AVS) adapte ses paramètres de configuration à l’aide des données reçues à l’étape S170, de sorte à pouvoir établir une session sécurisée avec le module de contrôle (AVSC).
  • De retour à l’étape S150, si par contre aucun module de sécurité (AVS) n’a préalablement été instancié sur ledit terminal utilisateur (UE) par ledit opérateur de télécommunications (auprès duquel l’utilisateur a souscrit un abonnement), l’étape S180-2 de configuration est mise en œuvre au cours de laquelle un nouveau module de sécurité (AVS) est instancié. Dans ce cas, les données correspondent par exemple à une adresse web (Uniform Resource Locator, URL, selon la terminologie anglo-saxonne) identifiant la localisation d’un package à installer. L’étape S180-2 de configuration comprend alors le téléchargement en utilisant par exemple une connexion IP dans le plan utilisateur puis l’installation, par le module AVS, de ce package.
  • Une fois la configuration ou l’initialisation réalisée, une étape S190 est mise en œuvre au cours de laquelle le module de sécurité (AVS) transmet un acquittement à destination du module (AMF) de gestion d’accès et de mobilité, en utilisant par exemple les protocoles NAS. Cet acquittement comprend par exemple une information caractérisant que la configuration ou l’initialisation d’un module de sécurité AVS s’est déroulée de manière correcte, sans générer d’erreur ou d’avertissement. En variante, cet acquittement inclut des données relatives aux erreur(s) et/ou avertissement(s) générés lors de la configuration ou de l’initialisation. Cet acquittement est reçu par le module (AMF) de gestion d’accès et de mobilité lors d’une étape S200, puis retransmis à destination du module UDM lors d’une étape S210. Cet acquittement est reçu par le module UDM lors d’une étape S220, puis retransmis à destination du module (AVSC) de contrôle lors d’une étape S230. Cet acquittement est alors reçu par le module (AVSC) de contrôle lors d’une étape S240.
  • Le procédé de gestion comprend en outre une étape S250 de génération, par le module de sécurité (AVS) du terminal utilisateur (UE), d’un historique d’évènements relatifs à la sécurité d’au moins une portion de connexion. Cette étape est par exemple mise en œuvre par le sous-module MOD_GEN du module de contrôle (AVS).
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est construit à partir de messages reçus d’un équipement distant par le module radio (BP) du terminal utilisateur (UE) ou transmis par ce même module radio (BP) à destination d’un équipement distant.
  • Ainsi, en cas de réception d’un message – tel qu’un message de signalisation –, le module radio (BP) rend le message accessible audit module de sécurité (AVS). L’accès à ce message est par exemple rendu possible au travers d’interfaces de programmation d'application (API) fournies par le module radio (BP).
  • Les API permettent par exemple au module de sécurité (AVS) ou à une application (APP) dudit module de s’abonner à la réception de nouveaux messages relatifs à la sécurité de la au moins une portion de connexion. Les messages reçus et destinés à être traités par le module de sécurité (AVS) sont alors rendus accessibles au module de sécurité (AVS) ou à ladite application (APP), selon un mécanisme de type « push » ou « pull ».
  • De manière relativement symétrique, dans des modes particuliers de mise en œuvre, l’historique d’évènements est construit à partir d’évènements générés par le processeur du terminal utilisateur (UE). L’accès à ces évènements est par exemple rendu possible au travers d’interfaces de programmation d'application (API) fournies par le processeur.
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’une donnée relative à une utilisation d’un protocole d’authentification pour au moins une portion de la connexion entre le terminal utilisateur (UE) et ledit réseau de télécommunications, telle que la portion de connexion entre le terminal utilisateur (UE) et une station de base (gNB) à laquelle ledit terminal utilisateur (UE) est connecté ;
  • De manière plus spécifique, si le protocole EAP (acronyme de « Extensible Authentication Protocol ») est utilisé, le terminal utilisateur reçoit du module AMF (et via la station de base gNB) un message « AUTHENTICATION REQUEST » contenant un message « EAP-request » (cf. TS 24.501, Non-Access-Stratum (NAS) protocol for 5G System (5GS); Stage 3, version 18.2.1, publiée le 6 avril 2023, § 5.4.1.2.1). Le message « AUTHENTICATION REQUEST » est par exemple spécifié dans ce même document au paragraphe 8.2.1.1. Le message « EAP-request » est par exemple spécifié dans le standard IETF RFC 3748, « Extensible Authentication Protocol (EAP) » publié en juin 2004.
  • En variante, si le protocole 5G AKA est utilisé, le terminal utilisateur (UE) reçoit de l’AMF un message « AUTHENTICATION REQUEST » ne contenant pas de message « EAP-request » (cf. par exemple le document TS 24.501 précédemment évoqué, paragraphe 5.4.1.3.2).
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’une donnée relative à une utilisation d’un algorithme de chiffrement pour au moins une portion de la connexion entre le terminal utilisateur (UE) et le réseau de télécommunications, telle que la portion de connexion entre le terminal utilisateur (UE) et une station de base (gNB) à laquelle ledit terminal utilisateur (UE) est connecté.
  • De manière plus spécifique, pour le chiffrement au niveau NAS (acronyme de « Non Access Stratum ») entre le terminal utilisateur et le module AMF, un message SECURITY MODE COMMAND est envoyé par l’AMF à destination du terminal utilisateur UE (via la station de base gNB). Ce message est par exemple spécifié dans le document TS 24.501 (paragraphe 8.2.25) précédemment évoqué.
  • De manière plus spécifique, pour le chiffrement au niveau AS (acronyme de « Access Stratum ») entre le terminal utilisateur et la station de base gNB, le terminal utilisateur UE reçoit de la station de base gNB un message « SecurityModeCommand », par exemple défini dans le document TS 38.331 “NR; Radio Resource Control (RRC); Protocol specification”, version 17.4.0, publié le 30 mars 2023), ou un message « RRC reconfiguration » également défini dans le document TS 38.331 et contenant un élément d’information « SecurityAlgorithmConfig » indiquant les algorithmes à utiliser pour la protection en intégrité (IntegrityProtAlgorithm) et le chiffrement (CipheringAlgorithm).
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’une donnée relative au contrôle d’intégrité mis en œuvre par le terminal utilisateur (UE) et/ou une station de base (gNB) à laquelle ledit terminal utilisateur (UE) est connecté (e.g., « IntegrityProtAlgorithm » précédemment évoqué) ;
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’une donnée relative à une utilisation d’un protocole de chiffrement pour chiffrer des données de contexte du terminal utilisateur (UE) ;
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’une modification d’un identifiant temporaire (e.g., le 5G-GUTI, l’acronyme de « Global Unique Temporary Identifier ») du terminal utilisateur (UE). Le 5G-GUTI est par exemple fourni par le module AMF au terminal utilisateur UE dans un message « Registration Accept », ce message étant par exemple défini dans le document TS 23.502, « Procedures for the 5G System (5GS) », version 18.1.1, publié le 5 avril 2023.
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’une transmission, par le terminal utilisateur (UE), d’un identifiant IMSI ou d’un identifiant SUCI. De manière plus spécifique, ces identifiants peuvent être transmis dans le champ « Mobile identity », « EPS Mobile identity » ou « 5GS Mobile identity » d’un des messages suivants :
    • « IDENTITY RESPONSE », par exemple défini dans le document TS 24.501 § 8.2.22 pour 5GS.
    • « ATTACH REQUEST », par exemple défini dans le document TS 24.301, “Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3”, version 18.2.1, publié le 6 avril 2023 pour EPS, et le document TS 24.008 «  Mobile radio interface Layer 3 specification; Core network protocols; Stage 3 », version 18.2.0, publié le 1er avril 2023 pour les technologies 2G/3G.
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’une donnée relative à un chiffrement ou à un contrôle d’intégrité d’une couche PDCP (acronyme de « Packet Data Convergence Protocol »). De manière plus spécifique, le terminal utilisateur UE reçoit par exemple du gNB un message « RRC reconfiguration » (par exemple défini dans le document TS 38.331 précédemment évoqué) contenant l’élément d’information « PDCP-Config » indiquant dans le champ « IntegrityProtection » si la protection en intégrité du plan utilisateur doit être activée ou pas.
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’une donnée relative à une commutation de contexte dans le cadre d’un transfert intercellulaire (ou « handover » selon la terminologie anglo-saxonne) ;
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’une donnée relative à la sécurité des protocoles « Non Access Stratum » (NAS) employés entre le terminal utilisateur (UE) et le réseau de télécommunications ;
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’une donnée relative au basculement vers une connexion de génération antérieure. De manière plus spécifique, il s’agit d’observer la génération en cours d’utilisation pour détecter un basculement, par exemple au travers des messages NAS échangés entre le terminal utilisateur UE et le réseau. Ainsi, si les messages échangés sont conformes à la spécification TS 24.501 préalablement évoquée, alors la génération est 5G (5GS), si les messages échangés sont conformes à la spécification TS 24.301 préalablement évoquée, alors la génération est 4G (EPS) et si les messages échangés sont conformes à la spécification TS 24.008 préalablement évoquée, alors la génération est 2G (GSM) ou 3G (UMTS).
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’une donnée issue d’une réception de messages en provenance d’une cellule voisine de la cellule dans laquelle se situe ledit terminal utilisateur (UE). De manière plus spécifique, le terminal utilisateur reçoit par exemple d’une cellule voisine l’information « SIB1 (SystemInformationBlockType1) » dans le canal « DL-SCH ». Cette information est par exemple définie dans le document TS 36.331, “Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification”, version 17.4.0, publiée le 30 mars 2023. Cette information SIB1 contient notamment un champ « CellAccessRelatedInfo », qui contient un sous-champ « plmn-IdentityList », qui contient lui-même un sous-champ « PLMN-IdentityInfo », qui contient qui contient lui-même un sous-champ « cellIdentity ».
  • Dans des modes particuliers de mise en œuvre, l’historique d’évènements est généré à partir d’une combinaison d’au moins deux desdites données précédemment évoquées.
  • Dans des modes particuliers de mise en œuvre, le procédé de gestion comprend une transmission, par le module de sécurité (AVS), d’une pluralité de requêtes de test de paramètres de sécurité à destination du réseau de télécommunications (HPMN) ou d’un réseau de télécommunications visité (VPMN) géré par un autre opérateur de télécommunications, et l’historique d’évènements est construit à partir de réactions – ou d’absence de réaction – du réseau en réponse à cette transmission de tout ou partie de ces requêtes.
  • De retour à la , le procédé comprend en outre une étape S260 de traitement de l’historique d’évènements généré à l’étape 250. Cette étape est par exemple mise en œuvre par le sous-module MOD_DET du module de sécurité (AVS).
  • Dans des modes particuliers de mise en œuvre, l’étape S260 de traitement comprend la détermination d’une périodicité de modification d’un identifiant temporaire, tel qu’un GUTI. Si la périodicité de modification est supérieure à une valeur seuil donnée, par exemple 6 minutes, il peut alors être considéré que la sécurité de la connexion est potentiellement compromise ou sur le point de l’être, ou que le niveau de sécurité est moindre qu’escompté.
  • En variante, l’étape S260 comprend la détermination d’une fréquence de modification d’un identifiant temporaire. De manière plus spécifique, le nombre de procédures « Registration Update » entre deux modifications de l’identifiant 5G- GUTI est déterminé (e.g., par incrémentation d’un compteur).
  • Dans des modes particuliers de mise en œuvre, l’étape S260 de traitement comprend la détermination d’une fréquence de transmission, par le terminal utilisateur (UE), d’un identifiant IMSI du terminal utilisateur (UE). Ainsi, si le nombre de transmissions d’un identifiant « en clair » au cours d’une période de temps donnée est supérieure à une valeur seuil, par exemple une fois par jour, il peut alors être considéré que la sécurité de la connexion est potentiellement compromise ou sur le point de l’être, ou que le niveau de sécurité est moindre qu’escompté.
  • Dans des modes particuliers de mise en œuvre, l’étape S260 de traitement comprend la détermination d’un nombre de tentatives de connexion au réseau de télécommunications. Ainsi, si le nombre de tentatives est supérieur à une valeur seuil, par exemple 3, il peut alors être considéré que la sécurité de la connexion est potentiellement compromise ou sur le point de l’être.
  • Dans des modes particuliers de mise en œuvre, l’étape S260 de traitement comprend la détermination d’un score représentatif d’un degré de sécurité d’au moins une portion de connexion entre le terminal utilisateur (UE) et le réseau de données (DN) du réseau de télécommunications (HPMN).
  • De manière plus spécifique, ce score correspond par exemple à une valeur de l’intervalle [0 ;1] issue d’une moyenne pondérée d’un ensemble de sous-scores, chaque sous-score ayant une valeur dans l’intervalle [0 ;1] et étant associé à l’une des déterminations préalablement évoquées.
  • Dans des modes particuliers de mise en œuvre, l’étape S260 de traitement comprend la génération d’indicateurs de performance relatifs à la sécurité de la au moins une portion de connexion.
  • Dans des modes particuliers de mise en œuvre, l’étape S260 de traitement comprend la génération d’une alarme de sécurité, qui peut être déclenchée quand le score représentatif d’un degré de sécurité est inférieur à une première valeur seuil prédéterminée, par exemple 0.50, ou quand la valeur d’un des indicateurs de performance est inférieure à une deuxième valeur seuil inférieure à la première valeur seuil (e.g., 0.30).
  • Dans des modes particuliers de mise en œuvre, l’étape S260 de traitement comprend la transmission de données brutes de l’historique d’évènements ou de données issues d’une analyse de cet historique à des applications dudit terminal utilisateur (UE) ou vers des serveurs applicatifs distants.
  • De retour à la , le procédé comprend en outre une étape S270 de transmission, par le module de sécurité (AVS) et à destination d’un module de contrôle (AVSC) du réseau cœur (CN), d’un résultat de l’analyse au travers d’une session sécurisée. Cette étape S270 est par exemple mise en œuvre par le sous-module MOD_TX du module de sécurité (AVS). Elle peut être réalisée de manière immédiate, périodique – ce qui permet de prévenir une possible attaque par rétention de la part d’une station de base du réseau d’accès radio –, ou conditionnelle.
  • Le résultat est ensuite reçu par le module (AVSC) de contrôle lors de l’étape S280. Cette étape S280 est par exemple mise en œuvre par le sous-module MOD_RX du module de contrôle (AVSC).
  • Dans des modes particuliers de mise en œuvre, la session est sécurisée de bout-en-bout par application du protocole de transfert hypertextuel sécurisé HTTPS entre le module de sécurité (AVS) et le module de contrôle (AVSC). En variante, la session est sécurisée par application de protocoles NAS entre le module de sécurité (AVS) et le module (AMF) de gestion d’accès et de mobilité du réseau de télécommunications (HPMN).
  • Enfin, lors d’une étape S290, la sécurité de la connexion est vérifiée en fonction du résultat obtenue à l’étape précédente. Cette étape est par exemple mise en œuvre par le sous-module MOD_VER du module de contrôle (AVSC).
  • Dans des modes particuliers de mise en œuvre, le résultat reçu à l’étape S270 est présenté à un opérateur de télécommunications ou à un gestionnaire d’un réseau au travers d’une interface graphique. Dans des modes particuliers de mise en œuvre, le réseau de télécommunications est représenté sur une interface graphique, et la portion de connexion pour laquelle la sécurité est compromise est mise en évidence sur ladite représentation. Dans des modes particuliers de mise en œuvre, le résultat d’analyse comprend des paramètres de sécurité effectivement mis en œuvre, et la vérification comprend une comparaison des paramètres de sécurité effectivement mis en œuvre avec ceux d’une politique de sécurité préalablement établie par l’opérateur de télécommunications. Dans des modes particuliers de mise en œuvre, la vérification comprend la transmission, à destination d’une station de base ou d’un dispositif électronique mettant en œuvre une fonction réseau propre à une station de base, d’une instruction visant à adapter au moins un paramètre de sécurité de la station de base.
  • L’invention a jusqu’à présent été décrite dans le cas où l’utilisateur n’a souscrit qu’à un unique abonnement auprès d’un unique opérateur de réseaux de télécommunications. Cependant, l’invention n’en reste pas moins applicable dans le cas où le terminal utilisateur comprend plusieurs abonnements. Dans ce cas particulier, le terminal utilisateur (UE) comprend plusieurs modules de sécurité (AVS) isolés les uns des autres. Dans ce cas, lors de la réception d’un message – tel qu’un message de signalisation – par le module radio (BP), ce dernier détermine si le terminal utilisateur (UE) comprend un module de sécurité (AVS) géré par l’opérateur auprès duquel l’utilisateur a souscrit un abonnement. Ce module radio BP est alors capable de gérer une pluralité de contextes, et d’associer chaque message reçu du réseau au bon contexte. Ainsi, lorsqu’il reçoit par exemple du réseau une demande de réauthentification, le module radio BP est alors configuré pour déterminer avec quelle carte SIM la réauthentification doit être mise en œuvre.
  • De manière plus spécifique, suite à l’étape S190, le module AVS fait appel à l’API offerte par le module radio BP, afin d’être par exemple informé de l’occurrence des messages qui l’intéressent. Le module radio BP associe alors cette souscription au bon contexte d’attachement en comparant l’identifiant PLMN ID de l’AVS et l’identifiant PLMN ID du profil USIM utilisé pour l’attachement, et mémorise l’identité de l’AVS à l’origine de la souscription. Lors de la réception d’un message, le module radio BP détermine le contexte d’attachement, puis vérifie si ce message est pertinent pour une souscription en cours dans ce contexte. Si c’est le cas, l’AVS destinataire est celui qui est à l’origine de la souscription.
    •

Claims (15)

  1. Procédé de gestion de la sécurité d’une connexion entre un terminal utilisateur (UE) et un réseau de télécommunications (HPMN) géré par un opérateur de télécommunications, le procédé comprenant :
    • une génération (S250), par un module de sécurité (AVS) du terminal utilisateur (UE), d’un historique d’évènements relatifs à la sécurité de ladite connexion, le module de sécurité (AVS) étant géré par l’opérateur de télécommunications ;
    • une analyse (S260), par le module de sécurité (AVS), de l’historique généré ; et,
    • une transmission (S270), par le module de sécurité (AVS) et à destination d’un module de contrôle (AVSC) du réseau de télécommunications, d’un résultat de l’analyse au travers d’une session sécurisée, le module de contrôle (AVSC) étant géré par l’opérateur de télécommunications. 
  2. Procédé de gestion selon la revendication 1, dans lequel le terminal utilisateur (UE) est connecté au réseau de télécommunications (HPMN) au travers d’un réseau de télécommunications visité (VPMN) géré par un autre opérateur de télécommunications, et l’historique d’évènements comprend des données relatives à la sécurité dudit réseau de télécommunications visité.
  3. Procédé de gestion selon la revendication 1, comprenant en outre une transmission, par le module de sécurité (AVS), d’une pluralité de requêtes de test de paramètres de sécurité à destination du réseau de télécommunications ou d’un réseau de télécommunications visité géré par un autre opérateur de télécommunications, et l’analyse (S260) comprend une détermination d’un comportement du réseau de télécommunications ou du réseau de télécommunications visité en réponse aux transmissions.
  4. Procédé de gestion selon l’une des revendications 1 à 3, dans lequel l’analyse (S260) comprend la détermination d’un score représentatif d’un degré de sécurité de ladite connexion en fonction de l’historique généré.
  5. Procédé de gestion selon l’une des revendications 1 à 4, comprenant en outre :
    • une réception, par un module radio (BB) du terminal utilisateur (UE) d’un message de signalisation en provenance du réseau de télécommunications (HPMN) ou d’un réseau de télécommunications visité (VPMN) géré par un autre opérateur de télécommunications ; et,
    • un accès, par le module de sécurité (AVS), au message de signalisation au travers d’une interface de programmation d'application (API) fournie par le module radio.
  6. Procédé de gestion selon l’une des revendications 1 à 5, dans lequel le terminal utilisateur (UE) comprend un deuxième module de sécurité, le module de sécurité (AVS), dit premier module de sécurité, et le deuxième module de sécurité étant isolés l’un de l’autre, le procédé comprenant en outre, suite à une réception, par un module radio (BB) du terminal utilisateur (UE) d’un message de signalisation, une détermination, par le module radio (BB), d’un module de sécurité destinataire parmi le premier module de sécurité (AVS) et le deuxième module de sécurité (AVS).
  7. Procédé de gestion selon l’une des revendications 1 à 6, dans lequel la session est sécurisée par une utilisation de protocoles « Non Access Stratum » entre le module de sécurité (AVS) et un module (AMF) de gestion d’accès et de mobilité du réseau de télécommunications; ou une utilisation d’un protocole de transfert hypertextuel sécurisé (HTTPS) entre le module de sécurité (AVS) et le module de contrôle (AVSC).
  8. Procédé de gestion selon l’une des revendications 1 à 7, dans lequel le module de sécurité (AVS) inclut une interface de programmation d'application (API) comprenant une fonction d’accès à l’historique d’évènements et/ou au résultat de l’analyse, ladite interface de programmation d'application étant accessible par une application informatique du terminal utilisateur (UE).
  9. Procédé de gestion selon l’une des revendications 1 à 8, dans lequel l’historique d’évènements est généré à partir d’au moins une parmi :
    • une donnée relative à une utilisation d’un protocole d’authentification pour au moins une portion de la connexion entre le terminal utilisateur (UE) et ledit réseau de télécommunications, telle que la portion de connexion entre le terminal utilisateur (UE) et une station de base (gNB) à laquelle ledit terminal utilisateur (UE) est connecté ;
    • une donnée relative à une utilisation d’un algorithme de chiffrement pour au moins une portion de la connexion entre le terminal utilisateur (UE) et le réseau de télécommunications, telle que la portion de connexion entre le terminal utilisateur (UE) et une station de base (gNB) à laquelle ledit terminal utilisateur (UE) est connecté ;
    • une donnée relative au contrôle d’intégrité mis en œuvre par le terminal utilisateur (UE) et/ou une station de base (gNB) à laquelle ledit terminal utilisateur (UE) est connecté ;
    • une donnée relative à une utilisation d’un algorithme de chiffrement pour chiffrer des données de contexte du terminal utilisateur (UE) ;
    • une modification d’un identifiant temporaire (GUTI) du terminal utilisateur (UE) ;
    • une transmission, par le terminal utilisateur (UE), d’un identifiant IMSI ou d’un identifiant SUCI;
    • une donnée relative à un chiffrement ou à un contrôle d’intégrité d’une couche PDCP ;
    • une donnée relative à une commutation de contexte dans le cadre d’un transfert intercellulaire ;
    • une donnée relative à la sécurité des protocoles « Non Access Stratum » (NAS) employés entre le terminal utilisateur (UE) et le réseau de télécommunications ;
    • une donnée relative au basculement vers une connexion de génération antérieure ; et,
    • une donnée issue d’une réception de messages en provenance d’une cellule voisine d’une cellule dans laquelle se situe ledit terminal utilisateur (UE).
  10. Programme d’ordinateur comportant des instructions pour la mise en œuvre d’un procédé de gestion selon l’une quelconque des revendications 1 à 9, lorsque ledit programme est exécuté par un ordinateur.
  11. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon la revendication 10.
  12. Dispositif électronique (UE, UICC) apte à gérer la sécurité d’une connexion entre un terminal utilisateur (UE) et un réseau de télécommunications (HPMN) géré par un opérateur de télécommunications,
    le dispositif électronique (UE, UICC) comprenant un module de sécurité (AVS) géré par l’opérateur de télécommunications, le module de sécurité (AVS) comprenant :
    • un sous-module (MOD_GEN) de génération d’un historique d’évènements relatifs à la sécurité de ladite connexion ;
    • un sous-module (MOD_DET) d’analyse de l’historique généré ; et,
    • un sous-module (MOD_TX) de transmission, à destination d’un module de contrôle (AVSC) géré par ledit opérateur de télécommunications et appartenant audit réseau de télécommunications, d’un résultat de ladite analyse au travers d’une session sécurisée.
  13. Dispositif électronique selon la revendication 12, le dispositif électronique étant un élément sécurisé (UICC) incluant une application (USIM) gérée par l’opérateur de télécommunications, ladite application (USIM) comprenant le module de sécurité (AVS).
  14. Dispositif électronique selon la revendication 12, le dispositif électronique étant un terminal utilisateur (UE), et le module de sécurité (AVS) étant déployé dans un environnement d’exécution sécurisé (TEE) dudit terminal utilisateur (UE).
  15. Système de communication comprenant un premier dispositif électronique (UE, UICC) selon l’une quelconque des revendications 12 à 14, et un deuxième dispositif électronique (DE) comprenant un module de contrôle (AVSC), le module de contrôle (AVSC) comprenant :
    • un sous-module (MOD_RX) de réception, en provenance du module de sécurité (AVS) du premier dispositif électronique, d’un résultat de ladite analyse au travers d’une session sécurisée; et,
    • un sous-module (MOD_VER) de vérification de la sécurité de la connexion en fonction dudit résultat.
EP24734910.3A 2023-06-27 2024-06-26 Procédé de gestion de la sécurité d'une connexion et dispositif électronique associé Pending EP4740119A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2306701A FR3150674A1 (fr) 2023-06-27 2023-06-27 Procédé de gestion de la sécurité d’une connexion et dispositif électronique associé
PCT/EP2024/067890 WO2025003181A1 (fr) 2023-06-27 2024-06-26 Procédé de gestion de la sécurité d'une connexion et dispositif électronique associé

Publications (1)

Publication Number Publication Date
EP4740119A1 true EP4740119A1 (fr) 2026-05-13

Family

ID=89473936

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24734910.3A Pending EP4740119A1 (fr) 2023-06-27 2024-06-26 Procédé de gestion de la sécurité d'une connexion et dispositif électronique associé

Country Status (4)

Country Link
EP (1) EP4740119A1 (fr)
CN (1) CN121420294A (fr)
FR (1) FR3150674A1 (fr)
WO (1) WO2025003181A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11184756B2 (en) * 2018-02-19 2021-11-23 Apple Inc. Steering of roaming in 5G systems
WO2021097253A1 (fr) * 2019-11-14 2021-05-20 Intel Corporation Technologies pour la mise en œuvre de la directive relative à l'équipement radio

Also Published As

Publication number Publication date
CN121420294A (zh) 2026-01-27
WO2025003181A1 (fr) 2025-01-02
FR3150674A1 (fr) 2025-01-03

Similar Documents

Publication Publication Date Title
US12349055B2 (en) Method and apparatus for handling non-integrity protected reject messages in non-public networks
US12615513B2 (en) Updating a subscriber identity module
EP3029968B1 (fr) Procede de provisionnement d'un profil de souscripteur pour un module securise
CN109076102B (zh) 用户设备容器和网络切片
US12317077B2 (en) Communication system
US20250063364A1 (en) Communication method and network element device
US9210574B2 (en) Method and apparatus for verifying the authenticity of mobile device information
US11463364B2 (en) Methods, nodes and operator network for enabling filtering of traffic from an application
US20200336335A1 (en) Network caching of outbound content from endpoint device to prevent unauthorized extraction
EP4443922A1 (fr) Notification de pousser de module d'identité d'abonné par radio
US20240314568A1 (en) System and method for facilitating mobile device access to web applications
WO2025003181A1 (fr) Procédé de gestion de la sécurité d'une connexion et dispositif électronique associé
EP3342121B1 (fr) Évaluation fiable d'un espace intelligent en nuage au moyen d'une collecte de données répartie
EP3806517A1 (fr) Chargement d'informations de sécurité à accès restreint
EP3545711B1 (fr) Sélection d'une infrastructure de télécommunication
CN117083893A (zh) 用于处置通信网络中的已加密业务的第一节点、第二节点、第三节点及其执行的方法
EP4322480A1 (fr) Identification sécurisée d'applications dans un réseau de communication
US20260032556A1 (en) Communication method and communication apparatus
US12418797B2 (en) Systems and methods for securing applications executed on communication systems
US20250142507A1 (en) End-to-End (E2E) Secure Edge Application Service
US20230269588A1 (en) Operating System Integrity Measurement and Attestation
FR3014630A1 (fr) Procede de test de qualite de service, module d'identite de souscripteur, terminal mobile et systeme correspondants
FR3147923A1 (fr) Système d’authentification d’un équipement utilisateur, procédé mis en œuvre dans un tel système et ensemble de programmes d’ordinateur
EP4430870A1 (fr) Procédé de recherche de données sensibles dans au moins un paquet de données, dispositif et système associés

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20260116

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR