EP3180931A1 - Procédé d'établissement de sessions ota entre des terminaux et un serveur ota, serveur ota et serveur proxy inverse correspondants - Google Patents

Procédé d'établissement de sessions ota entre des terminaux et un serveur ota, serveur ota et serveur proxy inverse correspondants

Info

Publication number
EP3180931A1
EP3180931A1 EP15744613.9A EP15744613A EP3180931A1 EP 3180931 A1 EP3180931 A1 EP 3180931A1 EP 15744613 A EP15744613 A EP 15744613A EP 3180931 A1 EP3180931 A1 EP 3180931A1
Authority
EP
European Patent Office
Prior art keywords
server
ota
reverse proxy
security elements
proxy server
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.)
Withdrawn
Application number
EP15744613.9A
Other languages
German (de)
English (en)
Inventor
Xavier Berard
Patrice Amiel
Ludovic Tressol
Gregory Valles
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.)
Thales DIS France SA
Original Assignee
Gemalto 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 Gemalto SA filed Critical Gemalto SA
Publication of EP3180931A1 publication Critical patent/EP3180931A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H04L67/2895—Intermediate processing functionally located close to the data provider application, e.g. reverse proxies
    • 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
    • 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
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • 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
    • H04L63/0884—Network architectures or network communication protocols for network security for authentication of entities by delegation of authentication, e.g. a proxy authenticates an entity to be authenticated on behalf of this entity vis-à-vis an authentication entity
    • 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/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/141—Setup of application sessions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • 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/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/088—Access security using filters or firewalls
    • 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/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/101—Access control lists [ACL]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services

Definitions

  • the present invention relates to the field of telecommunications and more specifically to the remote administration of security elements, such as UICCs (Universal Integrated Circuit Cards) cooperating with terminals, for example portable terminals such smartphones, PDAs or computers.
  • security elements can also be in the form of integrated circuits in machines, such as in the field of M2M (Machine to Machine). They are not necessarily physically connected to the terminals, but can communicate with them by a short-distance connection where a security element is deported and communicates via a short-distance channel with the terminal (Bluetooth or Wifi for example).
  • Such administration of security elements is conventionally carried out by OTA (over the air in English) in order to update or install data or programs in the security elements.
  • An administration of this kind uses the http protocol and is also called 'RFM' (Remote File Management in English) or 'RAM' (Remote Administration Management in English) by http (HyperText Transfer Protocol in English - Hypertext Transfer Protocol in French).
  • the first is to transmit data or programs from an OTA platform to targeted security elements, for example during update campaigns.
  • This type of administration is called "push" in English and is based on transmission in SMS mode.
  • This method is not suitable in new generation networks such as LTE networks that do not support SMS (they are fully http).
  • RAM or RFM administrations by http were set up to avoid unreliable protocols such as SMS.
  • the second is to query, for example regularly or at the occurrence of an event, the OTA platform for the existence of available updates.
  • This query is initiated by the security element and is called "polling" or "pull” in English (the security element will see if the platform has something to transmit).
  • the interrogation is done in http mode.
  • the problem with this solution is that, in general, the security element does not wait for the occurrence of an event to interrogate the OTA platform.
  • the "polling" is done regularly, for example every fortnight or monthly. And most of the time, the OTA platform has nothing to transmit to the security element ...
  • the applicant has for example observed that in 90% of OTA platform queries by security elements in the field, no update or program or data is to be transmitted to the security element.
  • the present invention is intended to overcome these disadvantages.
  • one of the objectives of the invention is to avoid unnecessary data traffic between a security element that "polls" (interrogate) a server or an OTA platform in order to know if this platform has data to transmit to it (the term "data” is here understood in the broad sense, it may be a transmission of a program, subscription data (IMSI / Ki for a new subscription with the security domains and the corresponding keys) or simple updates of data or programs.
  • data is here understood in the broad sense, it may be a transmission of a program, subscription data (IMSI / Ki for a new subscription with the security domains and the corresponding keys) or simple updates of data or programs.
  • Unnecessary data comes mainly from the establishment of TLS-PSK sessions between the security elements that come to "poll” and the OTA platform.
  • a method of establishing OTA sessions between terminals and an OTA server in a telecommunications network the terminals cooperating each with a security element able to interrogate.
  • the OTA server for establishing a secure session to download data from the OTA server via a reverse proxy server to update the security elements the method comprising:
  • the method consists in deleting the identifier of a security element in the list once this security element has been updated.
  • the identifier is a PSK-ID and the secure session is a TLS-PSK session.
  • the OTA server also provides its load level to the reverse proxy server.
  • the invention also relates to an OTA server for updating security elements cooperating with terminals in a telecommunications network, the security elements being each able to interrogate the OTA server for the establishment of a secure session in order to downloading data from the OTA server via a reverse proxy server in order to update the security elements, this OTA server comprising means for providing the reverse proxy server with a list of identifiers of the security elements for which a update is available.
  • the OTA server comprises means for providing the reverse proxy server with its load level.
  • the invention also relates to a reverse proxy server of a telecommunications network, the reverse proxy server cooperating on the one hand with terminals cooperating with security elements and on the other hand with an OTA server able to update the elements. security on demand of these security elements via the reverse proxy server, the proxy server comprising a list of identifiers of the security elements for which an update is available, the list being updated by the server OTA, the reverse proxy server comprising means for authorizing the establishment of secure sessions between the OTA server and the security elements whose identifiers are included in the list and means for prohibiting the establishment of secure sessions between the OTA server and security elements whose identifiers are not included in the list.
  • This list is preferably updated by the OTA server.
  • a security element 10 is
  • the security element 10 here represented in the form of a SIM or UICC card, cooperates with a terminal, for example a smartphone not shown. In "pull" mode, it is this security element 10 that decides, typically on a time basis (for example fifteen days), to interrogate the OTA server 12 (an application server) to find out if the latter has any problems. data to be transmitted to him.
  • OTA server 12 an application server
  • This interrogation conventionally passes through a reverse proxy server 1 1 ("reverse proxy") which, in the state of the art, serves to establish the TLS-PSK link between the security element 10 and the server.
  • reverse proxy a reverse proxy server 1 1
  • OTA 12 OTA 12.
  • the invention proposes to use this reverse proxy server 1 1 as a filter between the security element 10 and the OTA server 12.
  • the filtering function has the effect of not establishing a secure session between the security element 10 and the OTA server 12 if the latter has no data to transmit.
  • the method according to the invention operates as follows: During a step 20, the security element 10 initiates a request for "polling" with the OTA server 12. This request arrives, as in the state of the technique, to the reverse proxy server 1 1.
  • the reverse proxy server 1 1 has previously received, from the OTA server 12, in a step 21, a list or an update of a list of security elements 10 authorized to This list typically includes identifiers, preferably PSK-IDs or ICCIDs, security elements for which updates (in the broad sense of the term) are available at the OTA server.
  • the reverse proxy server 1 1 therefore knows the security elements 10 for which an update is available.
  • the reverse proxy server 1 1 checks whether the security element 10 which initiated the "polling" step 20, thanks to the identifier received, if the latter is eligible for an update. .
  • the reverse proxy server 1 1 transmits, during a step 23, information to the OTA server 12 informing it that the security element 10 is able to receive data from the OTA server 12 and a secure session, preferably a TLS-PSK session is established between the security element 10 and the OTA server 12 via the reverse proxy server 1 1.
  • the data to be transmitted from the OTA platform 12 to the security element 10 are then transmitted in a secure channel. After the end of the session, the channel is closed.
  • the reverse proxy server 1 1 transmits to the security 10, during a step 24, information informing it that there is no data to be transmitted from the OTA server 12 and no secure session is established between the security element 10 and the OTA server 12.
  • a step 25 after a data update has been performed on a security element 10, the reverse proxy server 1 1 refreshes its list to eliminate the identifier of the security element 10 that comes to be updated. This operation can also be implemented by the aforementioned step 21 (refreshing the list of security elements to be updated).
  • PSK-ID as a filtering criterion at the level of the reverse proxy 1 1 brings two advantages:
  • the filtering by the inverse proxy 1 1 is carried out before any establishment of a TLS-PSK session;
  • the PSK-ID is very representative of the entity (the security element 10) for which an action must be taken since it includes the security domain for which services are to be executed in the OTA server 12.
  • An optional step 26 consists in informing the reverse proxy server 11 of its state of charge. If its state of charge is too high, the reverse proxy server 1 1 always prohibits any secure link between the OTA server 12 and a security element 10 coming to inquire about a data availability to update or redirects the request for the security element to a server that has the ability to support this update request.
  • the present invention also relates to the OTA server 12 for updating security elements 10 cooperating with terminals in a telecommunications network, the security elements 10 being each able to interrogate the server OTA 12 for establishing a secure session in order to download data from the OTA server 12 via the reverse proxy server 1 1 in order to update the security elements 10, this OTA server 12 comprising means for providing to the reverse proxy server 1 1 a list of identifiers of the security elements 10 for which an update is available.
  • the OTA server 12 also comprises means for providing the reverse proxy server 1 1 with its load level.
  • the invention also relates to the reverse proxy server 1 1 cooperating on the one hand with terminals cooperating with the security elements 10 and on the other hand with the OTA server 12 able to update the security elements 10 at their request by via the reverse proxy server 1 1, this reverse proxy server 1 1 comprising a list of identifiers of the security elements 10 for which an update is available, this list being updated by the OTA server 12 (step 21 ), the reverse proxy server 1 1 comprising means for authorizing the establishment of secure sessions between the OTA server 12 and the security elements 10 whose identifiers are included in this list and means for prohibiting the establishment of secure sessions between the OTA server 12 and the security elements 10 whose identifiers are not included in this list.
  • the invention therefore consists in filtering upstream of the OTA server 12, at the level of the reverse proxy server 1 1, the security elements which must not be updated. This makes it possible not to overload the work of the OTA server 12 and not to generate unnecessary traffic.
  • the reverse proxy server 1 1 rejects the requests of the security elements 10 that do not need to be updated before any establishment of a TLS-PSK link. This reduces the workload of the OTA server 12 and the data centers that are connected to the operator's network by 90%.
  • the application server or the OTA server 12 updates the list of identifiers of the security elements 10 concerned at the proxy server level. inverse 1 1.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Power Engineering (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Telephonic Communication Services (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)
  • Telephone Function (AREA)

Abstract

L'invention concerne notamment un procédé d'établissement de sessions OTA entre des terminaux et un serveur OTA (12) dans un réseau de télécommunications, les terminaux coopérant chacun avec un élément de sécurité (10) apte à interroger le serveur OTA (12) pour l'établissement d'une session sécurisée afin de télécharger des données du serveur OTA (12) par l'intermédiaire d'un serveur proxy inverse (11) afin de mettre à jour les éléments de sécurité (10). Selon l'invention, le procédé consiste à : Fournir du serveur OTA (12) au serveur proxy inverse (11) une liste d'identifiants des éléments de sécurité (10) pour lesquels une mise à jour est disponible; N'établir de session sécurisée entre les éléments de sécurité (10) et le serveur OTA (12) que pour les éléments de sécurité (10) dont les identifiants sont compris dans cette liste.

Description

Procédé d'établissement de sessions OTA entre des terminaux et un serveur OTA, serveur OTA et serveur proxy inverse correspondants
La présente invention concerne le domaine des télécommunications et plus précisément celui de l'administration à distance d'éléments de sécurité, tels que des UICCs (Universal Integrated Circuit Cards) coopérant avec des terminaux, par exemple des terminaux portables tels que des téléphones, des smartphones, des PDAs ou des ordinateurs. Les éléments de sécurité peuvent également se présenter sous la forme de circuits intégrés dans des machines, tel que dans le domaine du M2M (Machine to Machine en anglais). Ils ne sont pas nécessairement physiquement connectés au terminaux, mais peuvent communiquer avec ceux-ci par une liaison courte distance où un élément de sécurité est déporté et communique par un canal courte distance avec le terminal (Bluetooth ou Wifi par exemple).
Une telle administration d'éléments de sécurité est classiquement réalisée par OTA (Over The Air en anglais - par voie radio en français) afin de mettre à jour ou installer des données ou des programmes dans les éléments de sécurité. Une administration de ce genre utilise le protocole http et est également appelée 'RFM' (Remote File Management en anglais - Administration de fichiers à distance en français) ou 'RAM' (Remote Administration Management en anglais - Administration à distance en français) par http (HyperText Transfer Protocol en anglais - protocole de transfert hypertexte en français).
Il existe deux manières pour administrer des éléments de sécurité :
La première consiste à transmettre à partir d'une plateforme OTA des données ou des programmes à des éléments de sécurité ciblés, par exemple lors de campagnes de mise à jour. Ce type d'administration est appelé « push » en anglais et est basé sur de la transmission en mode SMS. Le problème est que cette méthode ne convient pas dans les réseaux de nouvelle génération tel que les réseaux LTE qui ne supportent pas le SMS (ils sont entièrement http). De plus, les administrations de type RAM ou RFM par http ont été mises en place pour éviter des protocoles non fiables tels que le SMS.
La seconde consiste à interroger, par exemple régulièrement ou à l'occurrence d'un événement, la plateforme OTA pour connaître l'existence de mises à jour disponibles. Cette interrogation est à l'initiative de l'élément de sécurité et est appelée « polling » ou « pull » en anglais (l'élément de sécurité va voir si la plateforme a quelque chose à lui transmettre). L'interrogation s'effectue en mode http. Le problème de cette solution est qu'en général, l'élément de sécurité n'attend pas l'occurrence d'un événement pour venir interroger la plateforme OTA. Le « polling » s'effectue donc régulièrement, par exemple tous les quinze jours ou mensuellement. Et la plupart du temps, la plateforme OTA n'a rien à transmettre à l'élément de sécurité... Le demandeur a par exemple observé que dans 90% des interrogations de la plateforme OTA par les éléments de sécurité sur le terrain, aucune mise à jour ou programme ou donnée n'est à transmettre à l'élément de sécurité. Ceci se traduit par un trafic hertzien inutile et une surcharge de la plateforme OTA (une liaison TLS- PSK est instaurée entre l'élément de sécurité et la plateforme OTA à chaque interrogation de l'élément de sécurité). De plus, lorsqu'un réseau interne de centre de données est impliqué dans la mise à jour des éléments de sécurité (par exemple un centre de données d'un fabricant d'éléments de sécurité chez qui l'opérateur de téléphonie mobile aura localisé ses services) est utilisé, ce réseau sera lui aussi sollicité inutilement. De plus, lorsque ce réseau fait appel à des serveurs décentralisés physiquement, des communications supplémentaires viennent s'y ajouter.
Pour pallier à cet inconvénient de la seconde manière d'opérer, deux solutions sont possibles :
Rallonger la période entre deux interrogations (« polling ») de la plateforme OTA (une application dans l'élément de sécurité est mise à jour pour rallonger cette période). L'inconvénient est que si des mises à jour sont disponibles juste après la dernière interrogation, l'élément de sécurité ne sera mis à jour que bien plus tard.
Passer en mode « push ». On retombe alors sur les problèmes mentionnés précédemment.
On constate donc qu'une interrogation régulière d'une plateforme OTA par les éléments de sécurité n'est pas du tout satisfaisante et a un impact très négatif notamment sur la plateforme OTA qui est sollicitée en permanence pour évaluer des requêtes http qui ne mènent à aucune mise à jour de ces éléments de sécurité et génère du trafic inutile.
La présente invention a notamment pour objectif de remédier à ces inconvénients.
Plus précisément, un des objectifs de l'invention est d'éviter un trafic de données inutile entre un élément de sécurité venu « poller » (interroger) un serveur ou une plateforme OTA pour savoir si cette plateforme a des données à lui transmettre (le terme « données » est ici entendu au sens large, il peut s'agir d'une transmission d'un programme, de données d'abonnement (IMSI/Ki pour un nouvel abonnement avec les domaines de sécurité et les clés correspondants) ou de simples mises à jour de données ou de programmes. Ce trafic de données inutile provient essentiellement de l'établissement de sessions TLS-PSK entre les éléments de sécurité qui viennent « poller » et la plateforme OTA.
Cet objectif, ainsi que d'autres qui apparaîtront par la suite est atteint grâce à un procédé d'établissement de sessions OTA entre des terminaux et un serveur OTA dans un réseau de télécommunications, les terminaux coopérant chacun avec un élément de sécurité apte à interroger le serveur OTA pour l'établissement d'une session sécurisée afin de télécharger des données du serveur OTA par l'intermédiaire d'un serveur proxy inverse afin de mettre à jour les éléments de sécurité, ce procédé consistant à :
Fournir du serveur OTA au serveur proxy inverse une liste d'identifiants des éléments de sécurité pour lesquels une mise à jour est disponible ;
N'établir de session sécurisée entre les éléments de sécurité et le serveur OTA que pour les éléments de sécurité dont les identifiants sont compris dans la liste. Avantageusement, le procédé consiste à supprimer l'identifiant d'un élément de sécurité dans la liste une fois que cet élément de sécurité a été mis à jour.
Préférentiellement, l'identifiant est un PSK-ID et la session sécurisée est une session TLS-PSK.
Dans un mode de mise en œuvrer avantageux, le serveur OTA fournit également son niveau de charge au serveur proxy inverse.
L'invention concerne également un serveur OTA destiné à mettre à jour des éléments de sécurité coopérant avec des terminaux dans un réseau de télécommunications, les élément de sécurité étant chacun aptes à interroger le serveur OTA pour l'établissement d'une session sécurisée afin de télécharger des données du serveur OTA par l'intermédiaire d'un serveur proxy inverse afin de mettre à jour les éléments de sécurité, ce serveur OTA comprenant des moyens pour fournir au serveur proxy inverse une liste d'identifiants des éléments de sécurité pour lesquels une mise à jour est disponible.
Avantageusement, le serveur OTA comprend des moyens pour fournir au serveur proxy inverse son niveau de charge.
L'invention concerne également un serveur proxy inverse d'un réseau de télécommunications, le serveur proxy inverse coopérant d'une part avec des terminaux coopérant avec des éléments de sécurité et d'autre part avec un serveur OTA apte à mettre à jour les éléments de sécurité à la demande de ces éléments de sécurité par l'intermédiaire du serveur proxy inverse, ce serveur proxy comprenant une liste d'identifiants des éléments de sécurité pour lesquels une mise à jour est disponible, la liste étant mise à jour par le serveur OTA, le serveur proxy inverse comprenant des moyens pour autoriser l'établissement de sessions sécurisées entre le serveur OTA et les éléments de sécurité dont les identifiants sont compris dans la liste et des moyens pour interdire l'établissement de sessions sécurisées entre le serveur OTA et les éléments de sécurité dont les identifiants ne sont pas compris dans la liste.
Cette liste est préférentiellement mise à jour par le serveur OTA.
D'autres caractéristiques et avantages de la présente invention apparaîtront à la lecture de la description suivante d'un mode de mise en œuvre préférentiel, donné à titre illustratif et non limitatif, et de la figure unique annexée représentant les étapes essentielles de l'invention.
Dans cette figure, trois éléments sont représentés :
Un élément de sécurité 10 ;
- Un serveur proxy inverse 1 1 ;
Un serveur OTA 12.
L'élément de sécurité 10, ici représenté sous la forme d'une carte SIM ou UICC, coopère avec un terminal, par exemple un smartphone non représenté. En mode « pull », c'est cet élément de sécurité 10 qui décide, typiquement sur une base temps (par exemple quinze jours), d'interroger le serveur OTA 12 (un serveur d'applications) pour savoir si ce dernier a des données à lui transmettre.
Cette interrogation passe classiquement par un serveur proxy inverse 1 1 (« reverse proxy » en anglais) qui, dans l'état de la technique, sert à l'établissement de la liaison TLS- PSK entre l'élément de sécurité 10 et le serveur OTA 12.
L'invention propose d'utiliser ce serveur proxy inverse 1 1 en tant que filtre entre l'élément de sécurité 10 et le serveur OTA 12. La fonction de filtrage a pour effet de ne pas établir de session sécurisée entre l'élément de sécurité 10 et le serveur OTA 12 si ce dernier n'a pas de données à lui transmettre.
Plus précisément, le procédé selon l'invention fonctionne de la manière suivante : Lors d'une étape 20, l'élément de sécurité 10 initie une requête de « polling » auprès du serveur OTA 12. Cette requête parvient, comme dans l'état de la technique, au serveur proxy inverse 1 1 .
Selon l'invention, le serveur proxy inverse 1 1 a préalablement reçu, de la part du serveur OTA 12, lors d'une étape 21 , une liste ou une mise à jour d'une liste d'éléments de sécurité 10 autorisés à se connecter au serveur OTA 12. Cette liste comprend typiquement les identifiants, de préférence les PSK-ID ou les ICCID, des éléments de sécurité 10 pour lesquels des mises à jour (données au sens large du terme) sont disponibles au niveau du serveur OTA 12. Le serveur proxy inverse 1 1 connaît donc les éléments de sécurité 10 pour lesquels une mise à jour est disponible. Lors d'une étape 22, le serveur proxy inverse 1 1 vérifie si l'élément de sécurité 10 qui a initié l'étape de « polling » 20, grâce à l'identifiant reçu, si ce dernier est éligible à une mise à jour. Si l'identifiant reçu correspond à celui d'un élément de sécurité 10 pour lequel des données de mise à jour sont disponibles, le serveur proxy inverse 1 1 transmet, lors d'une étape 23 une information au serveur OTA 12 l'informant que l'élément de sécurité 10 est apte à recevoir des données de la part du serveur OTA 12 et une session sécurisée, de préférence une session TLS-PSK est établie entre l'élément de sécurité 10 et le serveur OTA 12 par l'intermédiaire du serveur proxy inverse 1 1. Les données à transmettre de la plateforme OTA 12 à l'élément de sécurité 10 sont alors transmises dans un canal sécurisé. Après la fin de la session, le canal est fermé.
En revanche, si l'identifiant reçu par le serveur proxy inverse 1 1 ne correspond pas à celui d'un élément de sécurité 10 pour lequel des données de mise à jour sont disponibles, le serveur proxy inverse 1 1 transmet à l'élément de sécurité 10, lors d'une étape 24, une information l'informant qu'il n'y a pas de données à lui transmettre de la part du serveur OTA 12 et aucune session sécurisée n'est établie entre l'élément de sécurité 10 et le serveur OTA 12.
Lors d'une étape 25, après qu'une mise à jour des données ait été réalisée sur un élément de sécurité 10, le serveur proxy inverse 1 1 rafraîchit sa liste pour en éliminer l'identifiant de l'élément de sécurité 10 qui vient d'être mis à jour. Cette opération peut également être mise en œuvre par l'étape 21 précitée (rafraîchissement de la liste des éléments de sécurité à mettre à jour).
L'utilisation de PSK-ID en tant que critère de filtrage au niveau du proxy inverse 1 1 apporte deux avantages :
Le filtrage par le proxy inverse 1 1 est réalisé avant tout établissement d'une session TLS-PSK ;
Le PSK-ID est très représentatif de l'entité (l'élément de sécurité 10) pour qui une action doit être entreprise puisqu'il inclut le domaine de sécurité pour lequel des services doivent être exécutés dans le serveur OTA 12.
Une étape facultative 26 consiste à informer le serveur proxy inverse 1 1 de son état de charge. Si son état de charge est trop important, le serveur proxy inverse 1 1 interdit systématiquement toute liaison sécurisée entre le serveur OTA 12 et un élément de sécurité 10 venant s'enquérir d'une disponibilité de données à mettre à jour ou redirige la requête de l'élément de sécurité vers un serveur qui a la capacité de prendre en charge cette requête de mise à jour.
La présente invention concerne également le serveur OTA 12 destiné à mettre à jour des éléments de sécurité 10 coopérant avec des terminaux dans un réseau de télécommunications, les élément de sécurité 10 étant chacun aptes à interroger le serveur OTA 12 pour l'établissement d'une session sécurisée afin de télécharger des données du serveur OTA 12 par l'intermédiaire du serveur proxy inverse 1 1 afin de mettre à jour les éléments de sécurité 10, ce serveur OTA 12 comprenant des moyens pour fournir au serveur proxy inverse 1 1 une liste d'identifiants des éléments de sécurité 10 pour lesquels une mise à jour est disponible.
Le serveur OTA 12 comprend également des moyens pour fournir au serveur proxy inverse 1 1 son niveau de charge.
L'invention concerne également le serveur proxy inverse 1 1 coopérant d'une part avec des terminaux coopérant avec les éléments de sécurité 10 et d'autre part avec le serveur OTA 12 apte à mettre à jour les éléments de sécurité 10 à leur demande par l'intermédiaire du serveur proxy inverse 1 1 , ce serveur proxy inverse 1 1 comprenant une liste d'identifiants des éléments de sécurité 10 pour lesquels une mise à jour est disponible, cette liste étant mise à jour par le serveur OTA 12 (étape 21 ), le serveur proxy inverse 1 1 comprenant des moyens pour autoriser l'établissement de sessions sécurisées entre le serveur OTA 12 et les éléments de sécurité 10 dont les identifiants sont compris dans cette liste et des moyens pour interdire l'établissement de sessions sécurisées entre le serveur OTA 12 et les éléments de sécurité 10 dont les identifiants ne sont pas compris dans cette liste.
L'invention consiste donc à filtrer en amont du serveur OTA 12, au niveau du serveur proxy inverse 1 1 , les éléments de sécurité qui ne doivent pas être mis à jour. Ceci permet de ne pas surcharger le travail du serveur OTA 12 et de ne pas générer du trafic inutile. Le serveur proxy inverse 1 1 rejette en amont les demandes des éléments de sécurité 10 qui n'ont pas besoin d'être mis à jour, avant tout établissement d'une liaison TLS-PSK. Ceci permet de diminuer de 90% la charge de travail du serveur OTA 12 et des centres de données qui sont connectés au réseau de l'opérateur.
A chaque fois qu'une nouvelle application doit être installée ou modifiée au niveau d'éléments de sécurité 10, le serveur d'application ou le serveur OTA 12 met à jour la liste des identifiants des éléments de sécurité 10 concernés au niveau du serveur proxy inverse 1 1 .
II est également possible de mettre en place un politique de filtrage basée sur certaines priorités (mises à jour importantes par exemple), des périodes de validité d'applications (qui seront du coup prioritaires par rapport à d'autres applications ou mises à jour) ou des périodes d'expiration de validité d'applications qui seront elles aussi prioritaires et mises à jour dans la liste fournie au serveur proxy inverse 1 1 avec leurs identifiants.

Claims

REVENDICATIONS
1 . Procédé d'établissement de sessions OTA entre des terminaux et un serveur OTA (12) dans un réseau de télécommunications, les terminaux coopérant chacun avec un élément de sécurité (10) apte à interroger le serveur OTA (12) pour l'établissement d'une session sécurisée afin de télécharger des données du serveur OTA (12) par l'intermédiaire d'un serveur proxy inverse (1 1 ) afin de mettre à jour les éléments de sécurité (10), caractérisé en ce qu'il consiste à :
Fournir du serveur OTA (12) au serveur proxy inverse (1 1 ) une liste d'identifiants des éléments de sécurité (10) pour lesquels une mise à jour est disponible ;
N'établir de session sécurisée entre les éléments de sécurité (10) et le serveur OTA (12) que pour les éléments de sécurité (10) dont les identifiants sont compris dans la liste.
2. Procédé selon la revendication 1 , caractérisé en ce qu'il consiste à supprimer l'identifiant d'un élément de sécurité (10) dans la liste une fois que l'élément de sécurité (10) a été mis à jour.
3. Procédé selon l'une des revendications 1 et 2, caractérisé en ce que l'identifiant est un PSK-ID.
4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que la session sécurisée est une session TLS-PSK.
5. Procédé selon l'une des revendications 1 à 4, caractérisé en ce que le serveur OTA (12) fournit également son niveau de charge au serveur proxy inverse (1 1 ).
6. Serveur OTA (12) destiné à mettre à jour des éléments de sécurité (10) coopérant avec des terminaux dans un réseau de télécommunications, les élément de sécurité (10) étant chacun aptes à interroger le serveur OTA (12) pour l'établissement d'une session sécurisée afin de télécharger des données du serveur OTA (12) par l'intermédiaire d'un serveur proxy inverse (1 1 ) afin de mettre à jour les éléments de sécurité (10), caractérisé en ce qu'il comprend des moyens pour fournir au serveur proxy inverse (1 1 ) une liste d'identifiants des éléments de sécurité (10) pour lesquels une mise à jour est disponible.
7. Serveur OTA (12) selon la revendication 6, caractérisé en ce qu'il comprend des moyens pour fournir au serveur proxy inverse (1 1 ) son niveau de charge.
8. Serveur proxy inverse (1 1 ) d'un réseau de télécommunications, le serveur proxy inverse (1 1 ) coopérant d'une part avec des terminaux coopérant avec des éléments de sécurité (10) et d'autre part avec un serveur OTA (12) apte à mettre à jour les éléments de sécurité (10) à la demande desdits éléments de sécurité (10) par l'intermédiaire du serveur proxy inverse (1 1 ), caractérisé en ce qu'il comprend une liste d'identifiants des éléments de sécurité (10) pour lesquels une mise à jour est disponible, la liste étant mise à jour par le serveur OTA (12), le serveur proxy inverse (1 1 ) comprenant des moyens pour autoriser l'établissement de sessions sécurisées entre le serveur OTA (12) et les éléments de sécurité (10) dont les identifiants sont compris dans la liste et des moyens pour interdire l'établissement de sessions sécurisées entre le serveur OTA (12) et les éléments de sécurité (10) dont les identifiants ne sont pas compris dans la liste.
9. Serveur proxy inverse (1 1 ) selon la revendication 8, caractérisé en ce que la liste est mise à jour par le serveur OTA (12).
EP15744613.9A 2014-08-13 2015-08-05 Procédé d'établissement de sessions ota entre des terminaux et un serveur ota, serveur ota et serveur proxy inverse correspondants Withdrawn EP3180931A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP14306272.7A EP2986043A1 (fr) 2014-08-13 2014-08-13 Procédé d'établissement de sessions OTA entre des terminaux et un serveur OTA, serveur OTA et serveur proxy inverse correspondants
PCT/EP2015/068034 WO2016023800A1 (fr) 2014-08-13 2015-08-05 Procédé d'établissement de sessions ota entre des terminaux et un serveur ota, serveur ota et serveur proxy inverse correspondants

Publications (1)

Publication Number Publication Date
EP3180931A1 true EP3180931A1 (fr) 2017-06-21

Family

ID=51987096

Family Applications (2)

Application Number Title Priority Date Filing Date
EP14306272.7A Withdrawn EP2986043A1 (fr) 2014-08-13 2014-08-13 Procédé d'établissement de sessions OTA entre des terminaux et un serveur OTA, serveur OTA et serveur proxy inverse correspondants
EP15744613.9A Withdrawn EP3180931A1 (fr) 2014-08-13 2015-08-05 Procédé d'établissement de sessions ota entre des terminaux et un serveur ota, serveur ota et serveur proxy inverse correspondants

Family Applications Before (1)

Application Number Title Priority Date Filing Date
EP14306272.7A Withdrawn EP2986043A1 (fr) 2014-08-13 2014-08-13 Procédé d'établissement de sessions OTA entre des terminaux et un serveur OTA, serveur OTA et serveur proxy inverse correspondants

Country Status (6)

Country Link
US (1) US20180219966A1 (fr)
EP (2) EP2986043A1 (fr)
JP (1) JP6377837B2 (fr)
KR (1) KR101946444B1 (fr)
CA (1) CA2957300C (fr)
WO (1) WO2016023800A1 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3264812A1 (fr) * 2016-06-28 2018-01-03 Gemalto Sa Procédé de mise à jour d'éléments de sécurité, plate-forme ota et élément de sécurité correspondants
US10728219B2 (en) * 2018-04-13 2020-07-28 R3 Ltd. Enhancing security of communications during execution of protocol flows
CN112799706A (zh) * 2019-11-14 2021-05-14 华为技术有限公司 车辆升级包处理方法和装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8767931B2 (en) * 2003-07-14 2014-07-01 Orative Corporation Provisioning in communications systems
EP2283430B1 (fr) * 2008-05-23 2018-08-01 Telefonaktiebolaget LM Ericsson (publ) Équipement utilisateur ims, son procédé de commande, dispositif hôte et son procédé de commande
CN101594614B (zh) * 2009-06-30 2011-07-13 中兴通讯股份有限公司 数据下载方法以及终端
EP2453377A1 (fr) * 2010-11-15 2012-05-16 Gemalto SA Procédé de chargement de données dans un objet portable sécurisé
JP5589983B2 (ja) * 2011-07-21 2014-09-17 三菱電機株式会社 アクセスポイント
US8631239B2 (en) * 2012-01-12 2014-01-14 Facebook, Inc. Multiple system images for over-the-air updates

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
None *
See also references of WO2016023800A1 *

Also Published As

Publication number Publication date
JP2017531358A (ja) 2017-10-19
KR20170043568A (ko) 2017-04-21
CA2957300C (fr) 2019-09-03
CA2957300A1 (fr) 2016-02-18
US20180219966A1 (en) 2018-08-02
WO2016023800A1 (fr) 2016-02-18
KR101946444B1 (ko) 2019-02-12
EP2986043A1 (fr) 2016-02-17
JP6377837B2 (ja) 2018-08-22

Similar Documents

Publication Publication Date Title
BE1023200B1 (fr) Connexions de réseau de données de paquet pour des dispositifs sans fil à priorités multiples
EP3029968B1 (fr) Procede de provisionnement d'un profil de souscripteur pour un module securise
JP5678014B2 (ja) オープンマーケット無線デバイスのネットワーク識別のための装置及び方法
EP2415294B1 (fr) Procédé et dispositif de gestion d'une authentification d'un utilisateur
EP2727414B1 (fr) D'obtention par un terminal d'une information relative à un acces à un service
US9743458B2 (en) Adaptive crowdsourced keep-alive interval determination
WO2015180364A1 (fr) Procédé et système d'hébergement de point d'accès à un réseau
CA2957300C (fr) Procede d'etablissement de sessions ota entre des terminaux et un serveur ota, serveur ota et serveur proxy inverse correspondants
FR2984050A1 (fr) Procede de gestion de la connectivite d'un terminal
EP3248326B1 (fr) Procédé de gestion de signalisation de présence d'un terminal dans un réseau de communication
EP3476145B1 (fr) Procédé de mise a jour d'éléments de sécurité, plate-forme ota et élément de sécurité correspondants
FR2993743A1 (fr) Procede de gestion de la mobilite dans un reseau de communication en fonction d'un profil d'utilisation de credits stocke dans un serveur de gestion de credits
CN117917100A (zh) 用于更新与电信终端合作的安全元件的方法
WO2015181171A1 (fr) Procede de declenchement d'une session ota entre un terminal et un serveur distant, terminal, element de securite et serveur correspondants
EP3149902A1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
FR3011418A1 (fr) Technique d'administration a distance d'un dispositif appartenant a un reseau prive
FR3069998A1 (fr) Procede d'obtention d'un profil d'acces a un reseau de communication par un terminal secondaire via un terminal principal
WO2016062750A1 (fr) Procede de telechargement d'un profil d'abonne dans un element de securite, element de securite et serveurs correspondants

Legal Events

Date Code Title Description
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

17P Request for examination filed

Effective date: 20170313

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 MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: THALES DIS FRANCE SA

RIC1 Information provided on ipc code assigned before grant

Ipc: H04W 8/24 20090101ALI20190731BHEP

Ipc: H04L 9/32 20060101ALI20190731BHEP

Ipc: H04L 29/06 20060101AFI20190731BHEP

Ipc: H04L 29/08 20060101ALI20190731BHEP

Ipc: H04W 12/08 20090101ALI20190731BHEP

INTG Intention to grant announced

Effective date: 20190905

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20200116