WO2023062095A1 - Procédé et dispositif de transfert d'une communication d'une station de base à une autre - Google Patents

Procédé et dispositif de transfert d'une communication d'une station de base à une autre Download PDF

Info

Publication number
WO2023062095A1
WO2023062095A1 PCT/EP2022/078428 EP2022078428W WO2023062095A1 WO 2023062095 A1 WO2023062095 A1 WO 2023062095A1 EP 2022078428 W EP2022078428 W EP 2022078428W WO 2023062095 A1 WO2023062095 A1 WO 2023062095A1
Authority
WO
WIPO (PCT)
Prior art keywords
base station
cryptographic key
request
transfer
key
Prior art date
Application number
PCT/EP2022/078428
Other languages
English (en)
Inventor
Emmanuel Bertin
Fariba GHAFFARI
Original Assignee
Orange
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 filed Critical Orange
Publication of WO2023062095A1 publication Critical patent/WO2023062095A1/fr

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W36/00—Hand-off or reselection arrangements
    • H04W36/0005—Control or signalling for completing the hand-off
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H04W12/037—Protecting confidentiality, e.g. by encryption of the control plane, e.g. signalling traffic

Definitions

  • the invention relates to the general field of telecommunications networks and more specifically to the technology allowing the mobility of a mobile terminal between the different base stations of a mobile network.
  • a user can for example use a mobile terminal via a mobile network.
  • a mobile network relies on a more or less dense mesh of base stations.
  • a 5G network requires a larger mesh than previous generations in order to meet the growing demand from users for data rate/volume.
  • mobile uses are increasing. Examples include autonomous driving or real-time vehicle/container tracking. Therefore, the management of the mobility of a terminal between the different base stations of a mobile network during a communication (voice or data), also called "handover" in English, plays an increasingly important role. .
  • the handover process is a source of attacks from ill-intentioned people. These can, for example, use a pirate base station which will transmit more intensely than the base station of the telecommunications operator in order to force the user's terminal to connect to it. The hacker will then be able to obtain confidential data from the user's terminal.
  • the terminal may, during a so-called roaming phase (or "roaming" in English), connect to a base station of a third-party telecommunications operator. It is therefore important that the information exchanged between the two operators allowing roaming is certified and secure.
  • the method when the target base station receives a request to transfer a communication, that is to say a request to take charge of a communication, the method obtains in the transfer request, a key of public cryptography. The method then calculates a session key as a function of two parameters obtained and of the public cryptographic key.
  • the two parameters obtained are for example parameters used in the Diffie-Hellman key exchange protocol.
  • the method then sends an acceptance request to the user's terminal in response to the request for the transfer request received.
  • the method then receives an acknowledgment request comprising data enabling the transfer to be validated.
  • this embodiment allows mutual authentication between the sender of the transfer request request and the target base station.
  • a mobile phone base station is a fixed transmitting and receiving station, consisting of one or more transmitting/receiving antennas, which are used to route cellular calls. It should also be noted that the method can be applied to a group of base stations managed by an AMF (“Access and Mobility Management Function”).
  • AMF Access and Mobility Management Function
  • identifier is meant a sequence of characters and/or binary data which is used to identify with certainty a computer service or a device.
  • Such an identifier is for example composed of an electronic address such as an IP address, a MAC address or a URI/URL.
  • a method as described above is characterized in that said public cryptographic key is encrypted and in that the first step of obtaining is followed by a step of decryption of said public cryptographic key via a symmetric cryptographic key.
  • this embodiment makes it possible to secure the exchanges via the encryption of the transfer request thanks to a symmetric cryptographic key. Encryption ensures that the data exchanged is not "in the clear", i.e. readable / intelligible by a hacker who would obtain the transfer request.
  • a method as described above is characterized in that said transfer request comes from said mobile terminal.
  • this embodiment allows a mobile terminal of a user to initiate the transfer request (“handover”) of a communication from a current base station to a target base station.
  • This embodiment is particularly suitable when the mobile network and more particularly the base stations used are shared between several telecommunications operators (roaming). Indeed, it is the mobile terminal which makes the transfer request to the target base station when the radio signal of the base station in use weakens (current base station).
  • this embodiment makes it possible to avoid data exchanges between the telecommunications operator operating the current base station and the telecommunications operator operating the target base station.
  • the user and more particularly his terminal retains control of the data exchanged with the various base stations.
  • a method as described above is characterized in that said transfer request further comprises an electronic address of at least one smart contract registered in a chain of blocks and in that said symmetric cryptographic key is obtained from said at least one smart contract.
  • this embodiment makes it possible to ensure the integrity of the symmetric cryptographic key obtained via the management mechanisms of the blockchain and its smart contracts.
  • the smart contract can create a block within the blockchain when it provides the symmetric cryptographic key to the process.
  • the transfer request includes an electronic address of at least one database and the symmetric cryptographic key is obtained from the database in question.
  • the database or the table is then accessible only via, for example, authentication of the identifier/password type or via a certificate.
  • blockchain technology is a technology for storing and transmitting information without a controlling body.
  • it is a distributed database whose information sent by users and internal links to the database are checked and grouped at regular time intervals into blocks, the whole being secured by cryptography, and thus forming chain.
  • a blockchain is a distributed database that manages a list of records protected against tampering or modification by storage nodes; it is therefore a distributed and secure register of all the transactions carried out since the start of the system.
  • Blockchains are characterized in particular in that their contents cannot be modified or deleted: information published (i.e. recorded or saved) in a blockchain remains so forever.
  • a blockchain is deemed unalterable and allows the management of sensitive data such as crypto-currencies (currency issued peer-to-peer without the intervention of a central bank).
  • crypto-currencies currency issued peer-to-peer without the intervention of a central bank
  • a smart contract is a small irrevocable computer program that allows transactions to be carried out under certain conditions (executes pre-defined instructions).
  • a method as described above is characterized in that said symmetric cryptographic key is obtained from said first base station.
  • This embodiment makes it possible, for example, in the case of a transfer of a communication between two base stations operated by the same telecommunications operator, to obtain from the network and more particularly from the current base station the cryptographic key symmetrical.
  • a method as described above is characterized in that said transfer request further comprises an identifier and in that said at least two parameters are obtained by function of said identifier.
  • the identifier is for example an email address of at least one smart contract registered in a chain of blocks belonging to the user.
  • This smart contract allows for example the storage of information relating to the user such as his profile, the subscribed offer and the associated metrics (duration of voice communication carried out, volume of data transmitted and/or received, subscribed options, thresholds, time slots related to telecommunications services, etc.).
  • This embodiment makes it possible, for example, to condition the obtaining of the parameters on the data contained in the offer subscribed by the user with his telecommunications operator.
  • the parameters may not be obtained if the data threshold or the communication duration threshold associated with the offer is exceeded.
  • the identifier can be partially or totally encrypted.
  • it can be signed by a symmetric or private cryptographic key belonging to the user.
  • the symmetric key or the public key associated with the user's private cryptographic key is known to the device which provides the two parameters.
  • a method as described above is characterized in that said at least two parameters are obtained from a digital storage space.
  • This embodiment makes it possible to obtain the at least two parameters from, for example, a database or a smart contract registered with a chain of blocks.
  • this embodiment makes it possible, in the case of a smart contract, to ensure the integrity of the data stored in the digital storage space via the management mechanisms of the blockchain and its smart contracts. .
  • each obtaining of the parameters by the process can trigger the generation, by the smart contract, of a block within the chain of blocks.
  • a method as described above is characterized in that the calculation step comprises the calculation of a second public cryptographic key according to said at least two parameters obtained and in that said acceptance request comprises at least said second public key encrypted via a symmetric cryptographic key.
  • This embodiment makes it possible to increase the security linked to the transfer of the communication. Indeed, supplying the terminal with the second public cryptographic key enables it to generate a session cryptographic key capable of encrypting future exchanges.
  • encryption ensures that the data, in this case the second public key, is not exchanged in "clear”, i.e. readable / intelligible by a hacker who would obtain the request from acceptance.
  • a method as described above is characterized in that said transfer request further comprises at least a first digital fingerprint, a second digital fingerprint of a datum derived from the initial datum of said first digital fingerprint is obtained during the second obtaining step and that a third digital fingerprint of a datum derived from the initial datum of said second digital fingerprint is included in said second datum.
  • digital fingerprint data obtained via a cryptographic function such as a hash function making it possible to identify the initial data processed by the hash function.
  • This embodiment makes it possible to increase the security of the process by ensuring that there has not been a break in the sequence of exchanges carried out by the process. Specifically that there was no man-in-the-middle attack. Indeed, only the certified devices involved in the transfer process have knowledge of the cryptographic function making it possible to generate the digital fingerprint as well as the initial data.
  • the identifier can be encrypted via a symmetric cryptographic key
  • a method as described above is characterized in that the decryption step is followed by a step of sending to a smart contract registered with a blockchain of at least one order.
  • This mode of implementation makes it possible, for example, to trigger an action executed by a smart contract registered in a blockchain (for example updating a status).
  • this embodiment makes it possible, for example, to update a status managed by the smart contract or to provide it with information necessary for carrying out the transfer / "handover" between the first base station and the second.
  • this embodiment makes it possible to ensure the integrity of the data stored via the management mechanisms of the blockchain and its smart contracts.
  • the smart contract can then be viewed in confidence by a device capable of viewing the status of the transfer / "handover", with the requests being verified and secured. Note that each order processed by the smart contract can be the subject of a block creation within the blockchain.
  • the command(s) are sent to a database.
  • the database or the table is then accessible only via, for example, authentication of the identifier/password type or via a certificate.
  • module can correspond to a software component as well as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or subroutines or more generally to any element of a program able to implement a function or a set of functions as described for the modules concerned.
  • a hardware component corresponds to any element of a hardware (or hardware) assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc. .).
  • the invention also relates to a computer program comprising instructions for implementing the above method according to any one of the particular embodiments described above, when said program is executed by a processor.
  • the method can be implemented in various ways, in particular in wired form or in software form.
  • This program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in partially compiled form, or in any other desirable form.
  • the invention also relates to a recording medium or information medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the recording media mentioned above can be any entity or device capable of storing the program.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or even a magnetic recording means, for example a hard disk.
  • the recording media may correspond to a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the programs according to the invention can in particular be downloaded from an Internet-type network.
  • the recording media may correspond to an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • This transfer device and this computer program have characteristics and advantages similar to those described above in relation to the transfer method.
  • this device has the hardware architecture of a computer. It notably comprises a processor PROC1, a random access memory MV1, a read only memory MEM1 and a non-volatile flash memory MF1. Such means are known per se and are not described in more detail here.
  • the ROM constitutes a recording medium in accordance with the invention, readable by the processor PROC1 and on which is recorded here a computer program PG1 in accordance with the invention, this program comprising instructions for implementing the steps of the transfer method as described previously, when the program is executed by the processor PROC1.
  • the code instructions of the computer program PG1 are for example loaded into a memory before being executed by the processor PROC1.
  • the processor PROC1 of the processing unit UT1 notably implements the steps of the transfer method according to any one of the particular embodiments described in relation to the , according to the instructions of the computer program PG1.
  • the device DT also comprises obtaining modules OBT1 and OBT2 respectively capable of obtaining a call transfer request from a mobile user terminal and a plurality of parameters from a digital storage space such as a database, file or blockchain.
  • the parameters correspond for example to parameters used in the Diffie-Hellman key exchange protocol.
  • the transfer request includes at least one encrypted public cryptographic key.
  • the communication modules OBT1 and OBT2 are, for example, reception modules configured to establish communications with an IP network and/or circuit.
  • the OBT2 module may be capable of publishing data linked to the steps of the transfer method in a chain of blocks.
  • OBT1 and OBT2 modules can be one and the same module.
  • the device DT also comprises two decryption modules DECRYPT1 and DECRYPT2 respectively capable of decrypting the public cryptographic key obtained via the module OBT1 and data, originating from the user mobile terminal, making it possible to validate the transfer request.
  • the device DT further comprises a calculation module CALC able to calculate cryptographic keys.
  • the calculation module generates at least one public cryptographic key according to the plurality of parameters obtained via the OBT2 module and at least one session key also according to the parameters obtained via the OBT2 module but also according to the cryptographic key public obtained via the OBT1 module.
  • DECRYPT2 module decrypts the data via the session key generated by the CALC module.
  • the DECRYPT1 module decrypts the public cryptographic key obtained via the OBT1 module using a symmetric cryptographic key obtained from a digital storage space.
  • digital storage spaces can be included in the transfer device (files, memory spaces, etc.) or hosted in the network such as a database or a chain of blocks.
  • the modules DECRYPT1 and DECRYPT2 can be one and the same decryption module.
  • TRM terminal such as, for example, a mobile terminal or a laptop capable of transmitting and receiving requests via, for example, a private or public IP network.
  • the TRM terminal is connected to a mobile network and more specifically to a base station AMF_Old (not shown).
  • the terminal TRM is for example in the process of communication with a second terminal (not represented), the communication passing through the base station AMF_Old.
  • the mobile terminal searches for a new base station (AMF) available having a radio signal able to allow the communication continuity.
  • AMF new base station
  • the transfer method is a device connected, via for example an IP network or circuit, to the AMF base station.
  • the transfer device is included in the AMF base station.
  • the devices ESN1 and ESN2 are, for example, smart contracts, blockchains or even databases.
  • the ESN1 and ESN2 devices are smart contracts registered on a blockchain and capable of performing decentralized functions in the sense of blockchain technology.
  • Block chains can be public or private operated, for example, by the mobile network manager.
  • the devices ESN1 and ESN2 are one and the same smart contract registered in a blockchain.
  • the AMF base station is capable of transmitting and receiving requests to and from a chain of blocks.
  • the AMF base station is already known and registered within the blockchain which includes smart contracts ESN1 and ESN2.
  • the terminal TRM observes that the radio signal picked up from the base station AMF_Old in use (current base station) is weakening.
  • the terminal TRM then sends a call transfer request to a base station (AMF) capable of handling the call.
  • AMF base station
  • the transfer request is sent from the base station AMF_Old to the base station AMF (not shown).
  • the communication may be a voice and/or text and/or video type communication.
  • the transfer request is received by the base station AMF during step E20.
  • This transfer request includes for example an identifier (ID1) and an encrypted public cryptographic key ( ).
  • the identifier ID1 is the first identifier within the meaning of the invention
  • the first datum within the meaning of the invention comprises the public cryptographic key .
  • the cryptographic key is a key belonging to the user.
  • the key has for example been calculated by the terminal TRM using parameters obtained from the base station AMF_Old. These parameters are for example used within the framework of a Diffie-Hellman key exchange protocol.
  • the public cryptographic key can correspond to:
  • the base station AMF transmits, to the device ESN1, a request (REQ1) comprising at least the identifier ID1 received during the step E20.
  • the identifier ID1 is for example an identifier of a data table.
  • the identifier ID1 is the electronic address of the smart contract ESN1.
  • the device ESN1 receives the request during step E31 and provides in return (E32) a cryptographic key CL2.
  • This key is for example a symmetric encryption key obtained according to the identifier ID1.
  • the CL2 key is the symmetric cryptographic key within the meaning of the invention.
  • the key CL2 is received by the base station AMF during step E22.
  • the CL2 key is then used by the AMF base station to decrypt (E23) the public cryptographic key previously obtained.
  • the CL2 key is known to the TRM terminal. It is for example obtained by the terminal TRM from the base station AMF_Old or pre-provisioned by the user's telecommunications operator for example in the user's SIM card or in a memory of the terminal TRM.
  • the key CL2 is received by the base station AMF coming from the base station AMF_Old for example during the call transfer request (not shown).
  • the base station AMF sends a request REQ2 to the device ESN2.
  • the device ESN2 transmits parameters to the base station AMF. These parameters are received by the base station AMF during step E24.
  • the parameters received (E24) are at least the parameters .
  • the base station AMF calculates a cryptographic key and a session key .
  • the cryptographic key is the second a public cryptographic key within the meaning of the invention.
  • the session key is the session cryptographic key within the meaning of the invention.
  • the AMF base station selects as the private cryptographic key and then calculates the public cryptographic key as follows:
  • the session key is calculated according to this mathematical formula:
  • session key is a symmetric cryptographic key.
  • the AMF base station can transmit to a digital storage space a storage request for the session key .
  • the base station AMF transmits to the terminal TRM a response (request for acceptance) to the transfer request received during the step E20.
  • the response is received by the terminal TRM during step E15.
  • the terminal TRM then sends an acknowledgment of receipt (E16) which includes at least one encrypted data item (acknowledgment request).
  • This acknowledgment makes it possible to ensure that the terminal TRM is ready for the transfer and that it is able to connect to the base station AMF.
  • the encrypted data obtained by the base station AMF during step E26 is for example encrypted via the session key .
  • This data is for example a Boolean or a character string.
  • the AMF base station validates the acknowledgment if the decrypted data item received conforms to what is expected.
  • the transfer request further comprises an electronic address of a smart contract belonging to the user of the TRM terminal.
  • This electronic address can comprise an electronic signature obtained via, for example, the cryptographic key CL2.
  • the base station AMF sends the request REQ2 which may also include the electronic address of the smart contract belonging to the user of the terminal TRM.
  • the ESN2 device can condition the supply, to the AMF base station, of the parameters according to data obtained from the smart contract belonging to the user of the TRM terminal.
  • the signature decryption key is known to the device ESN2.
  • the smart contract belonging to the user allows for example the storage of information relating to the user such as his profile, the subscribed offer and the associated metrics (duration of voice communication carried out, volume of data transmitted and/or received, subscribed options, thresholds, time slots related to telecommunications services, etc.).
  • the obtaining of the parameters by the AMF base station may not be done if the data threshold or the communication duration threshold associated with the offer is exceeded.
  • the base station AMF transmits to the terminal TRM a response (acceptance request) which includes the cryptographic key .
  • the issued cryptographic key ( ) can be encrypted using the CL2 cryptographic key.
  • the key thus obtained from the TRM terminal, allows the latter to calculate the session key according to the following mathematical formula: .
  • the transfer request further comprises a "nonce".
  • a "nonce” is a random or pseudo-random number such as a UUID (Universally Unique IDentifier) or a GUID (Globally Unique Identifier).
  • UUID Universally Unique IDentifier
  • GUID Globally Unique Identifier
  • the transfer request includes a digital fingerprint of the nonce produced via a hash function allowing the initial data (i.e. the nonce) processed by the hash function to be unambiguously identified.
  • the base station AMF transmits the request REQ2 which may also include the nonce or its digital fingerprint ( ) and receives during step E24 a second nonce derived from the first, for example incremented (nonce+1), or else its digital fingerprint .
  • the second nonce or its digital fingerprint is then sent to the terminal TRM during step E25 for example via the acceptance request.
  • the AMF base station receives in return a new nonce incremented by the TRM terminal (nonce+2) or its digital fingerprint .
  • the AMF base station sends a status update request to a digital storage space.
  • the digital storage space can correspond to the ESN1, ESN2 device or to a database.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé de transfert vers une deuxième station de base d'une communication réalisée via une première station de base, ladite communication faisant intervenir au moins un terminal mobile d'un utilisateur, ledit procédé étant mis en œuvre par un dispositif de transfert.

Description

Procédé et dispositif de transfert d’une communication d’une station de base à une autre.
1. Domaine de l'invention
L'invention se rapporte au domaine général des réseaux de télécommunications et plus précisément à la technologie permettant la mobilité d’un terminal mobile entre les différentes stations de base d’un réseau mobile.
2. Art Antérieur
Pour accéder aux services digitalisés et à leurs contenus/fonctionnalités, un utilisateur peut par exemple utiliser un terminal mobile via un réseau mobile. De manière connue, un tel réseau mobile repose sur un maillage plus ou moins dense de stations de base. Par exemple, un réseau 5G demande un maillage plus important que les précédentes générations afin de répondre à la demande croissante des utilisateurs en débit/volume de données. Chaque station de base couvrant une plus faible portion du territoire, le terminal mobile d’un utilisateur en déplacement change plus souvent de station de base. En outre, les usages en mobilité augmentent. On peut par exemple citer la conduite autonome ou le suivi de véhicules/containers en temps réel. Par conséquent, la gestion de la mobilité d’un terminal entre les différentes stations de base d’un réseau mobile lors d’une communication (voix ou données), également appelé « handover » en anglais, joue un rôle de plus en plus important.
Cependant, le processus de « handover » est source d’attaques de la part de personnes mal intentionnées. Celles-ci peuvent, par exemple, utiliser une station de base pirate qui va émettre plus intensément que la station de base de l’opérateur de télécommunications dans le but de forcer le terminal de l’utilisateur à s’y connecter. Le pirate pourra ensuite obtenir des données confidentielles du terminal de l’utilisateur. En outre, dans le cas où par exemple il n’y aurait pas de station de base disponible opérée par l’opérateur de télécommunications de l’utilisateur, le terminal peut, lors d’une phase dite d’itinérance (ou « roaming » en anglais), se connecter à une station de base d’un opérateur de télécommunications tiers. Il est alors important que les informations échangées entre les deux opérateurs permettant l’itinérance soient certifiées et sûres.
3. Exposé de l'invention
L'invention vient améliorer l'état de la technique et propose un procédé de transfert vers une deuxième station de base d’une communication réalisée via une première station de base, ladite communication faisant intervenir au moins un terminal mobile d’un utilisateur, ledit procédé étant mis en œuvre par un dispositif de transfert et caractérisé en ce qu’il comprend :
  • une première étape d’obtention d’une demande de transfert de ladite communication depuis ladite première station de base vers ladite deuxième station de base, ladite demande comprenant au moins une clef cryptographique publique ;
  • une deuxième étape d’obtention d’au moins deux paramètres ;
  • une étape de calcul d’une clef cryptographique de session en fonction desdits au moins deux paramètres obtenus et de ladite clef cryptographique publique ;
  • une étape de déchiffrement, via ladite clef de session, d’une donnée permettant de valider ladite demande de transfert, ladite donnée étant comprise dans une requête d’acquittement reçue en provenance dudit au moins un terminal en réponse à l’émission d’une requête d’acceptation de ladite demande de transfert.
Selon l'invention, lorsque la station de base cible reçoit une demande de transfert d’une communication, c’est-à-dire une demande de prise en charge d’une communication, le procédé obtient dans la requête de transfert, une clef de cryptographique publique. Le procédé calcule ensuite une clef de session en fonction de deux paramètres obtenus et de la clef cryptographique publique. Les deux paramètres obtenus sont par exemple des paramètres utilisés dans le protocole d’échange de clefs Diffie-hellman.
Le procédé émet par la suite ensuite une requête d’acceptation à destination du terminal de l’utilisateur en réponse à la requête de la demande de transfert reçue. Le procédé reçoit ensuite une requête d’acquittement comprenant une donnée permettant de valider le transfert.
Avantageusement, ce mode de réalisation permet une authentification mutuelle entre l’émetteur de la requête de demande de transfert et la station de base cible.
A noter qu’une station de base de téléphonie mobile est une station d’émission et de réception fixe, composée d’une ou plusieurs antennes émettrices/réceptrices, qui sont utilisés pour acheminer les appels cellulaires. A noter également que le procédé peut s’appliquer à un groupement de stations de base géré par un AMF (« Access and Mobility Management Function » en anglais).
On entend par identifiant une suite de caractères et/ou de données binaires qui sert à identifier de façon certaine un service informatique ou un dispositif. Un tel identifiant est par exemple composé d’une adresse électronique telle qu’une adresse IP, une adresse MAC ou bien une URI/URL.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite clef cryptographique publique est chiffrée et en ce que la première étape d’obtention est suivie d’une étape de déchiffrement de ladite clef cryptographique publique via une clef cryptographique symétrique.
Avantageusement, ce mode de réalisation permet de sécuriser les échanges via le chiffrement de la demande de transfert grâce à une clef cryptographique symétrique. Le chiffrement permet de s’assurer que les données échangées ne sont pas en « clair », c’est-à-dire lisibles / intelligibles par un pirate qui obtiendrait la demande de transfert.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite demande de transfert est en provenance dudit terminal mobile.
Avantageusement, ce mode de réalisation permet à un terminal mobile d’un utilisateur d’être à l’initiative de la demande de transfert (« handover ») d’une communication d’une station de base courante à une station de base cible. Ce mode de réalisation est particulièrement adapté lorsque le réseau mobile et plus particulièrement les stations de base utilisées sont partagées entre plusieurs opérateurs de télécommunications (itinérance). En effet, c’est le terminal mobile qui fait la demande de transfert auprès de la station de base cible lorsque le signal radio de la station de base en cours d’utilisation s’affaiblit (station de base courante). Ainsi, dans le cas particulier de l’itinérance, ce mode de réalisation permet d’éviter les échanges de données entre l’opérateur de télécommunications opérant la station de base courante et l’opérateur de télécommunications opérant la station de base cible. L’utilisateur et plus particulièrement sont terminal conserve la maitrise des données échangées avec les différentes stations de base.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite demande de transfert comprend en outre une adresse électronique d’au moins un contrat intelligent inscrit à une chaîne de blocs et en ce que ladite clef cryptographique symétrique est obtenue depuis ledit au moins un contrat intelligent.
Avantageusement, ce mode réalisation permet de s’assurer de l’intégrité de la clef cryptographique symétrique obtenue via les mécanismes de gestion de la chaîne de blocs et de ses contrats intelligents.
A noter que le contrat intelligent peut créer un bloc au sein de la chaîne de blocs lorsque celui-ci fournit la clef cryptographique symétrique au procédé.
Alternativement, la demande de transfert comprend une adresse électronique d’au moins une base de données et la clef cryptographique symétrique est obtenue depuis la base de données en question. La base de données ou la table est alors accessible uniquement via par exemple une authentification de type identifiant / mot de passe ou bien via un certificat.
Comme indiqué dans le document (https://fr.wikipedia.org/wiki/Blockchain), la technologie des chaînes de blocs est une technologie de stockage et de transmission d'informations sans organe de contrôle. Techniquement, il s'agit d'une base de données distribuée dont les informations envoyées par les utilisateurs et les liens internes à la base sont vérifiés et groupés à intervalles de temps réguliers en blocs, l'ensemble étant sécurisé par cryptographie, et formant ainsi une chaîne. Par extension, une chaîne de blocs est une base de données distribuée qui gère une liste d'enregistrements protégés contre la falsification ou la modification par les nœuds de stockage ; c'est donc un registre distribué et sécurisé de toutes les transactions effectuées depuis le démarrage du système. Les chaînes de blocs sont notamment caractérisées en ce que leurs contenus ne peuvent pas être modifiés ou supprimés : une information publiée (c’est-à-dire enregistrée ou sauvegardée) dans une chaîne de blocs le reste pour toujours. Ainsi, une chaîne de blocs est réputée inaltérable et permet la gestion de données sensibles telles que des crypto-monnaies (monnaie émise de pair à pair sans intervention d’une banque centrale). On peut citer par exemple la monnaie électronique décentralisée Bitcoin créée en 2009.
De façon connue, la sécurité d’une chaîne de blocs réside également dans le fait que les transactions réalisées au niveau de la chaîne de blocs sont visibles par tous ceux qui ont accès à cette chaîne de blocs. Cette transparence est une propriété fondamentale de la chaîne de blocs.
Un contrat intelligent est un petit programme informatique irrévocable qui permet de réaliser des transactions sous certaines conditions (exécute des instructions pré-définies).
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite clef cryptographique symétrique est obtenue depuis ladite première station de base.
Ce mode de réalisation permet, par exemple, dans le cas d’un transfert d’une communication entre deux stations de base opérées par le même opérateur de télécommunications d’obtenir depuis le réseau et plus particulièrement depuis la station de base courante la clef cryptographique symétrique.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite demande de transfert comprend en outre un identifiant et en ce que l’obtention desdits au moins deux paramètres se fait en fonction dudit identifiant.
L’identifiant est par exemple une adresse électronique d’au moins un contrat intelligent inscrit à une chaîne de blocs appartenant à l’utilisateur. Ce contrat intelligent permet par exemple le stockage d’informations relatives à l’utilisateur telles que son profil, l’offre souscrite et les métriques associées (durée de communication voix réalisée, volume de données émises et/ou reçues, options souscrites, seuils, plages horaires liées aux services de télécommunications, etc.).
Ce mode de réalisation permet, par exemple, de conditionner l’obtention des paramètres à des données contenues dans l’offre souscrite par l’utilisateur auprès de son opérateur de télécommunications. Ainsi, l’obtention des paramètres peut ne pas se faire si le seuil de données ou le seuil de durée de communication associé à l’offre est dépassé.
A noter que l’identifiant peut être chiffré partiellement ou totalement. Dans le cas d’une adresse électronique d’un contrat intelligent, celle-ci peut être signée par une clef cryptographique symétrique ou bien privée appartenant à l’utilisateur. Bien entendu la clef symétrique ou la clef publique associée à la clef cryptographique privée de l’utilisateur est connue du dispositif qui fournit les deux paramètres.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’obtention desdits au moins deux paramètres se fait depuis un espace de stockage numérique.
Ce mode de réalisation permet d’obtenir les au moins deux paramètres depuis, par exemple une base de données ou un contrat intelligent inscrit à une chaîne de blocs. Avantageusement, ce mode de réalisation permet, dans le cas d’un contrat intelligent, de s’assurer de l’intégrité des données stockées dans l’espace de stockage numérique via les mécanismes de gestion de la chaîne de blocs et de ses contrats intelligents.
A noter que chaque obtention des paramètres par le procédé peut déclencher la génération, par le contrat intelligent, d’un bloc au sein de la chaîne de blocs.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l’étape de calcul comprend le calcul d’une seconde clef cryptographique publique en fonction desdits au moins deux paramètres obtenus et en ce que ladite requête d’acceptation comprend au moins ladite seconde clef publique chiffrée via une clef cryptographique symétrique.
Ce mode de réalisation permet d’augmenter la sécurité liée au transfert de la communication. En effet, la fourniture au terminal de la seconde clef cryptographique publique lui permet de générer une clef cryptographique de session apte à chiffrer les échanges futurs.
En outre, le chiffrement permet de s’assurer que les données, en l’occurrence la seconde clef publique ne soit pas échangée en « clair », c’est-à-dire lisible / intelligible par un pirate qui obtiendrait la requête d’acceptation.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que ladite demande de transfert comprend en outre au moins une première empreinte numérique, qu’une deuxième empreinte numérique d’une donnée dérivée de la donnée initiale de ladite première empreinte numérique est obtenue lors de la deuxième étape d’obtention et qu’une troisième empreinte numérique d’une donnée dérivée de la donnée initiale de ladite deuxième empreinte numérique est comprise dans ladite deuxième donnée.
On entend par empreinte numérique une donnée obtenue via une fonction cryptographique telle qu’une fonction de hachage permettant d’identifier la donnée initiale traitée par la fonction de hachage.
Ce mode de réalisation permet d’augmenter la sécurité du procédé en s’assurant qu’il n’y a pas eu une rupture dans la suite des échanges réalisés par le procédé. Plus précisément qu’il n’y a pas eu d’attaque du type « homme du milieu ». En effet, seuls les dispositifs certifiés impliqués dans le procédé de transfert ont la connaissance de la fonction cryptographique permettant de générer l’empreinte numérique ainsi que la donnée initiale.
A noter que l’identifiant peut être chiffré via une clef cryptographique symétrique
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est caractérisé en ce que l‘étape de déchiffrement est suivie d’une étape d’émission à destination d’un contrat intelligent inscrit à une chaîne de blocs d’au moins une commande.
Ce mode de mise en œuvre permet, par exemple, de déclencher une action exécutée par un contrat intelligent inscrit à une chaîne de blocs (par exemple mettre à jour un statut).
Concrètement, ce mode de réalisation permet par exemple de mettre à jour un statut géré par le contrat intelligent ou bien lui fournir des informations nécessaires à la réalisation du transfert / « handover » entre la première station de base et la seconde.
Avantageusement, ce mode réalisation permet de s’assurer de l’intégrité des données stockées via les mécanismes de gestion de la chaîne de blocs et de ses contrats intelligents.
Le contrat intelligent peut par la suite être consulté en toute confiance par un dispositif apte à consulter le statut du transfert / « handover », les demandes étant vérifiées et sécurisées. A noter que chaque commande traitée par le contrat intelligent peut faire l’objet d’une création de bloc au sein de la chaîne de blocs.
Alternativement, la ou les commandes sont émises à destination d’une base de données. La base de données ou la table est alors accessible uniquement via par exemple une authentification de type identifiant / mot de passe ou bien via un certificat.
L'invention concerne également un dispositif de transfert vers une deuxième station de base d’une communication réalisée via une première station de base, ladite communication faisant intervenir au moins un terminal mobile d’un utilisateur, ledit dispositif étant caractérisé en ce qu’il comprend :
  • un premier module d’obtention d’une demande de transfert de ladite communication depuis ladite première station de base vers ladite deuxième station de base, ladite demande comprenant au moins une clef cryptographique publique ;
  • un deuxième module d’obtention d’au moins deux paramètres ; 
  • un module de calcul d’une clef cryptographique de session en fonction desdits au moins deux paramètres obtenus et de ladite clef cryptographique publique ;
  • un module de déchiffrement, via ladite clef de session, d’une donnée permettant de valider ladite demande de transfert, ladite donnée étant comprise dans une requête d’acquittement reçue en provenance dudit au moins un terminal en réponse à l’émission d’une requête d’acceptation de ladite demande de transfert.
Le terme module peut correspondre aussi bien à un composant logiciel qu’à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d’ordinateur ou de manière plus générale à tout élément d’un programme apte à mettre en œuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant matériel correspond à tout élément d’un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.).
L'invention concerne également un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé ci-dessus selon l'un quelconque des modes particuliers de réalisation décrits précédemment, lorsque ledit programme est exécuté par un processeur. Le procédé peut être mis en œuvre de diverses manières, notamment sous forme câblée ou sous forme logicielle. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'enregistrement ou support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Les supports d'enregistrement mentionnés ci-avant peuvent être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, les supports d'enregistrement peuvent correspondre à un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.
Alternativement, les supports d'enregistrement peuvent correspondre à un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Ce dispositif de transfert et ce programme d'ordinateur présentent des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé de transfert.
4. Liste des figures
D’autres caractéristiques et avantages de l’invention apparaîtront plus clairement à la lecture de la description suivante de modes de réalisation particuliers, donnés à titre de simples exemples illustratifs et non limitatifs, et des dessins annexés, parmi lesquels :
La La représente l’architecture matérielle d’un dispositif de transfert selon un mode particulier de réalisation,
La représente sous forme d’organigramme les principales étapes d’un procédé de transfert selon un mode particulier de réalisation de l’invention,
5. Description d'un mode de réalisation de l'invention
La représente l’architecture matérielle d’un dispositif de transfert DT conforme à l’invention. Dans le mode de réalisation décrit ici, ce dispositif a l’architecture matérielle d’un ordinateur. Il comprend notamment un processeur PROC1, une mémoire vive MV1, une mémoire morte MEM1 et une mémoire flash non volatile MF1. De tels moyens sont connus en soi et ne sont pas décrits plus en détail ici. La mémoire morte constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC1 et sur lequel est enregistré ici un programme d’ordinateur PG1 conforme à l’invention, ce programme comportant des instructions pour mettre en œuvre les étapes du procédé de transfert tel que décrit précédemment, lorsque le programme est exécuté par le processeur PROC1.
A l'initialisation, les instructions de code du programme d'ordinateur PG1 sont par exemple chargées dans une mémoire avant d'être exécutées par le processeur PROC1. Le processeur PROC1 de l'unité de traitement UT1 met notamment en œuvre les étapes du procédé de transfert selon l'un quelconque des modes particuliers de réalisation décrits en relation avec la , selon les instructions du programme d'ordinateur PG1.
Le dispositif DT comprend également des modules d’obtention OBT1 et OBT2 respectivement aptes à obtenir une demande de transfert d’une communication en provenance d’un terminal mobile utilisateur et une pluralité de paramètre en provenance d’un espace de stockage numérique tel qu’une base de données, un fichier ou une chaîne de blocs. Les paramètres correspondent par exemple à des paramètres utilisés dans le protocole d’échange de clefs Diffie-hellman.
A noter que la demande de transfert comprend au moins une clef cryptographique publique chiffrée.
Les modules de communication OBT1 et OBT2 sont par exemple des modules des réception configurés pour établir des communications avec un réseau IP et/ou circuit.
A noter que le module OBT2 peut être apte à publier dans une chaîne de blocs des données liées aux étapes du procédé de transfert.
A noter également que les modules OBT1 et OBT2 peuvent être un seul et même module.
Le dispositif DT comprend de plus deux modules de déchiffrement DECRYPT1 et DECRYPT2 respectivement aptes à déchiffrer la clef cryptographique publique obtenue via le module OBT1 et une donnée, en provenance du terminal mobile utilisateur, permettant de valider la demande de transfert.
Le dispositif DT comprend en outre un module de calcul CALC apte à calculer des clefs cryptographiques. Concrètement, le module de calcul génère au moins une clef cryptographique publique en fonction de la pluralité des paramètres obtenus via le module OBT2 et au moins une clef de session également en fonction des paramètres obtenus via le module OBT2 mais aussi en fonction de la clef cryptographique publique obtenue via le module OBT1.
A noter que le module DECRYPT2 déchiffre la donnée via la clef de session générée par le module CALC.
A noter également que le modules DECRYPT1 déchiffre la clef la clef cryptographique publique obtenue via le module OBT1 grâce à une clef cryptographique symétrique obtenue depuis un espace de stockage numérique.
A noter que l’espaces de stockage numérique peuvent être compris dans le dispositif de transfert (fichiers, espaces mémoire, etc.) ou bien hébergés dans le réseau comme par exemple une base de données ou une chaîne de blocs.
Selon un mode particulier de réalisation de l’invention, les modules DECRYPT1 et DECRYPT2 peuvent être un seul et même module de déchiffrement.
La illustre des étapes du procédé de transfert selon un mode particulier de réalisation de l'invention.
La est constituée d’un terminal TRM comme par exemple un terminal mobile ou un ordinateur portable apte à émettre et recevoir des requêtes via par exemple un réseau IP privé ou public. Le terminal TRM est connecté à un réseau mobile et plus précisément à une station de base AMF_Old (non représentée). Le terminal TRM est par exemple en cours de communication avec un second terminal (non représenté), la communication transitant par la station de base AMF_Old.
Lorsque le signal radio de la station de base en cours d’utilisation par le terminal mobile TRM s’affaiblit (station de base courante), le terminal mobile cherche une nouvelle station de base (AMF) disponible ayant un signal radio apte à permettre la continuité de la communication.
Selon un mode particulier de réalisation de l’invention, le procédé de transfert est un dispositif connecté, via par exemple une réseau IP ou circuit, à la station de base AMF.
Dans l’exemple décrit ci-après, nous considérons que le dispositif de transfert est compris dans la station de base AMF.
Les dispositifs ESN1et ESN2 sont par exemple des contrats intelligents, des chaînes de blocs ou encore des bases de données. Dans l’exemple décrit ci-après, nous considérons que les dispositifs ESN1et ESN2 sont des contrats intelligents inscrits à une chaîne de blocs et aptes à exécuter des fonctions décentralisées au sens de la technologie des chaînes de blocs.
Les chaînes de blocs peuvent être publiques ou bien privées opérées, par exemple, par le gestionnaire du réseau mobile.
Selon un mode particulier de réalisation de l’invention, les dispositifs ESN1et ESN2 sont un seul et même contrat intelligent inscrit à une chaîne de blocs.
La station de base AMF est apte à émettre et recevoir des requêtes vers et depuis une chaîne de blocs. Bien évidement il est supposé que la station de base AMF est déjà connue et enregistrée au sein de la chaîne de blocs qui comprend des contrats intelligents ESN1et ESN2.
Au cours d’une première étape E10, le terminal TRM, constate que le signal radio capté de la station de base AMF_Old en cours d’utilisation (station de base courante) s’affaiblit. Le terminal TRM émet alors une demande de transfert de la communication vers une station de base (AMF) apte à prendre en charge la communication.
Alternativement la demande de transfert est émise depuis la station de base AMF_Old vers la station de base AMF (non représenté).
A noter que la communication peut être une communication de type voix et/ou texte et/ou vidéo. La demande de transfert est reçue par la station de base AMF lors de l’étape E20. Cette demande transfert comprend par exemple un identifiant (ID1) et une clef cryptographique publique chiffrée (
Figure pctxmlib-appb-M000001
).
L’identifiant ID1 est le premier identifiant au sens de l’invention
La première donnée au sens de l’invention comprend la clef cryptographique publique
Figure pctxmlib-appb-M000002
.
La clef cryptographique est une clef appartenant à l’utilisateur. La clef a par exemple été calculée par le terminal TRM grâce à des paramètres obtenus depuis la station de base AMF_Old. Ces paramètres sont par exemple utilisés dans le cadre d’un protocole d’échange de clefs Diffie-hellman.
Ainsi, la clef cryptographique publique peut correspondre à :
Figure pctxmlib-appb-M000003
  • Figure pctxmlib-appb-M000004
    , étant les paramètres obtenus depuis la station de base AMF_Old.
    Figure pctxmlib-appb-M000005
     étant un grand nombre premier et
    Figure pctxmlib-appb-M000006
     une de ses racines primaires (en anglais « prime roots ») ;
  • Figure pctxmlib-appb-M000007
     étant la clef privée.
Lors d’une étape E21, la station de base AMF émet, à destination du dispositif ESN1, une requête (REQ1) comprenant au moins l’identifiant ID1 reçu lors de l’étape E20. L’identifiant ID1 est par exemple un identifiant d’une table de données.
Alternativement l’identifiant ID1 est l’adresse électronique du contrat intelligent ESN1.
Le dispositif ESN1 reçoit la requête lors de l’étape E31 et fournit en retour (E32) une clef cryptographique CL2. Cette clef est par exemple une clef de chiffrement symétrique obtenue en fonction de l’identifiant ID1.
La clef CL2 est la clef cryptographique symétrique au sens de l’invention.
La clef CL2 est reçue par la station de base AMF lors de l’étape E22.
La clef CL2 est ensuite utilisée par la station de base AMF pour déchiffrer (E23) la clef cryptographique publique
Figure pctxmlib-appb-M000008
 préalablement obtenue. Bien évidement la clef CL2 est connue du terminal TRM. Elle est par exemple obtenue par le terminal TRM depuis la station de base AMF_Old ou pré-provisionnée par l’opérateur de télécommunications de l’utilisateur par exemple dans la carte SIM de l’utilisateur ou dans une mémoire du terminal TRM.
Alternativement la clef CL2 est reçue par la station de base AMF en provenance de la station de base AMF_Old par exemple lors de la demande transfert de la communication (non représenté).
Lors de l’étape E23, la station de base AMF émet à destination du dispositif ESN2 une requête REQ2. En réponse à la requête REQ2 (E44), le dispositif ESN2 transmet à la station de base AMF des paramètres. Ces paramètres sont reçus par la station de base AMF lors de l’étape E24. Les paramètres reçus (E24) sont au moins les paramètres
Figure pctxmlib-appb-M000009
.
Lors de l’étape E24, la station de base AMF calcule une clef cryptographique
Figure pctxmlib-appb-M000010
 et une clef de session
Figure pctxmlib-appb-M000011
.
La clef cryptographique
Figure pctxmlib-appb-M000012
 est la seconde une clef cryptographique publique au sens de l’invention.
La clef de session
Figure pctxmlib-appb-M000013
 est la clef cryptographique de session au sens de l’invention.
Pour calculer la clef cryptographique
Figure pctxmlib-appb-M000014
, la station de base AMF sélectionne
Figure pctxmlib-appb-M000015
en tant que clef cryptographique privée puis calcule la clef cryptographique publique comme suit :
Figure pctxmlib-appb-M000016
La clef de session est quant à elle calculée selon cette formule mathématique :
Figure pctxmlib-appb-M000017
A noter que la clef de session
Figure pctxmlib-appb-M000018
 est une clef cryptographique symétrique.
Selon un mode particulier de réalisation de l’invention (non représenté), la station de base AMF peut émettre à destination d’un espace de stockage numérique une requête de stockage de la clef de session
Figure pctxmlib-appb-M000019
.
Lors d’une étape E25, la station de base AMF émet à destination du terminal TRM une réponse (requête d’acceptation) à la demande de transfert reçue lors de l’étape E20. La réponse est reçue par le terminal TRM lors de l’étape E15.
Le terminal TRM émet par la suite un accusé de réception (E16) qui comprend au moins une donnée chiffrée (requête d’acquittement). Cet accusé de réception permet de s’assurer que le terminal TRM est prêt pour le transfert et qu’il est apte à se connecter à la station de base AMF. La donnée chiffrée obtenue par la station de base AMF lors de l’étape E26 est par exemple chiffrée via la clef de session
Figure pctxmlib-appb-M000020
. Cette donnée est par exemple un booléen ou une chaîne de caractères. Bien évidemment, la station de base AMF valide l’accusé de réception si la donnée reçue déchiffrée est conforme à ce qui est attendu.
Selon un mode particulier de réalisation de l’invention, la demande de transfert comprend en outre une adresse électronique d’un contrat intelligent appartenant à l’utilisateur du terminal TRM. Cette adresse électronique peut comprendre une signature électronique obtenue via par exemple la clef cryptographique CL2. Par la suite, lors de l’étape E23, la station de base AMF émet la requête REQ2 qui peut également comprendre l’adresse électronique du contrat intelligent appartenant à l’utilisateur du terminal TRM. Ainsi, le dispositif ESN2 peut conditionner la fourniture, à la station de base AMF, des paramètres en fonction de données obtenues depuis le contrat intelligent appartenant à l’utilisateur du terminal TRM. Bien évidemment, dans le cas où la requête REQ2 comprend une adresse électronique de l’utilisateur incluant une signature électronique obtenue via la clef cryptographique CL2, la clef de déchiffrement de la signature est connue du dispositif ESN2. Le contrat intelligent appartenant à l’utilisateur permet par exemple le stockage d’informations relatives à l’utilisateur telles que son profil, l’offre souscrite et les métriques associées (durée de communication voix réalisée, volume de données émises et/ou reçues, options souscrites, seuils, plages horaires liées aux services de télécommunications, etc.). Ainsi, l’obtention des paramètres par la station de base AMF peut ne pas se faire si le seuil de données ou le seuil de durée de communication associé à l’offre est dépassé.
Selon un mode particulier de réalisation de l’invention, lors d’une étape E25, la station de base AMF émet à destination du terminal TRM une réponse (requête d’acceptation) qui comprend la clef cryptographique
Figure pctxmlib-appb-M000021
. A noter que la clef cryptographique émise (
Figure pctxmlib-appb-M000022
) peut être chiffrée via la clef cryptographique CL2. La clef
Figure pctxmlib-appb-M000023
 ainsi obtenue du terminal TRM, permet à celui-ci de calculer la clef de session
Figure pctxmlib-appb-M000024
 selon la formule mathématique suivante :
Figure pctxmlib-appb-M000025
. Une fois la clef
Figure pctxmlib-appb-M000026
 générée par le terminal TRM, celui-ci peut chiffrer tout ou partie de l’accusé réception émis à destination de la station de base AMF lors de l’étape E16.
Selon un mode particulier de réalisation de l’invention, la demande de transfert comprend en outre un « nonce ». Un « nonce » est un nombre aléatoire ou pseudo aléatoire tel qu’un l’UUID (en anglais Universally Unique IDentifier) ou un GUID (en anglais Globally Unique Identifier). Le nonce permet de se prémunir des attaques par rejeu
Alternativement, la demande de transfert comprend une empreinte numérique du nonce réalisée via une fonction de hachage permettant d’identifier sans ambiguïté la donnée initiale (c’est-à-dire le nonce) traitée par la fonction de hachage.
Lors de l’étape E23, la station de base AMF émet la requête REQ2 qui peut également comprendre le nonce ou son empreinte numérique (
Figure pctxmlib-appb-M000027
) et reçoit lors de l’étape E24 un deuxième nonce dérivé du premier, par exemple incrémenté (nonce+1), ou bien son empreinte numérique
Figure pctxmlib-appb-M000028
. Le deuxième nonce ou son empreinte numérique est ensuite émis à destination du terminal TRM lors de l’étape E25 par exemple via la requête d’acceptation. La station de base AMF reçoit en retour un nouveau nonce incrémenté par le terminal TRM (nonce+2) ou son empreinte numérique
Figure pctxmlib-appb-M000029
. Ce mode de réalisation permet d’augmenter la sécurité du procédé en s’assurant qu’il n’y a pas eu une rupture dans la suite des échanges réalisés par le procédé.
En effet, seuls les dispositifs certifiés impliqués dans le procédé de transfert (ENS2, EMF et TRM) ont la connaissance de la fonction cryptographique permettant de générer l’empreinte numérique ainsi que la donnée initiale (le nonce). L’incrémentation du « nonce » au fil des échanges permet de vérifier que chaque étape a bien eu lieu via des dispositifs licites et qu’il n’y a pas eu de rejeu d’anciennes requêtes.
Selon un mode particulier de réalisation de l’invention (non représenté), la station de base AMF émet à destination d’un espace de stockage numérique une requête de mise à jour d’un statut. A noter que l’espace de stockage numérique peut correspondre au dispositif ESN1, ESN2 ou à une base de données.
Le statut permet par exemple de connaitre l’état de la demande de transfert de communication. Par exemple, le statut peut être représenté par un paramètre numérique :
  • Si le paramètre est égal à 1 alors cela peut indiquer que l’AMF_Old a envoyé l’ensemble des informations permettant le transfert au terminal TRM ou à l’AMF. Ce statut est par exemple mis à jour lors d’une étape préalable à l’étape E10.
  • Si le paramètre est égal à 2 alors cela peut indiquer que l’AMF accepte la demande de transfert de la communication. La requête de mise à jour du statut peut, par exemple, être émise à la suite des étapes E20, E22 ou E24.
  • Si le paramètre est égal à 3 cela peut signifier que l’authentification de l’utilisateur est valide, par exemple lorsque la station de base AMF déchiffre (E23) la clef cryptographique publique
    Figure pctxmlib-appb-M000030
     ou bien lorsque la signature de l’adresse électronique du contrat intelligent appartenant à l’utilisateur du terminal TRM est vérifiée (obtention des paramètres lors de l’étape E24). Ainsi, la requête de mise à jour du statut peut, par exemple, être émise à la suite des étapes E23 ou E24
  • Si le paramètre est égal à 4 cela peut signifier que l’authentification mutuelle a été réalisée avec succès entre l’AMF et le terminal et que l’AMF a obtenu en provenance du terminal TRM un accusé de réception pour la demande de connexion (E26). Ainsi, la requête de mise à jour du statut peut, par exemple, être émise à la suite de l’étape E26.
Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l’homme de l’art sans pour autant sortir du cadre de l’invention.

Claims (12)

  1. Procédé de transfert vers une deuxième station de base d’une communication réalisée via une première station de base, ladite communication faisant intervenir au moins un terminal mobile d’un utilisateur, ledit procédé étant mis en œuvre par un dispositif de transfert et caractérisé en ce qu’il comprend :
    - une première étape d’obtention (E20) d’une demande de transfert de ladite communication depuis ladite première station de base vers ladite deuxième station de base, ladite demande comprenant au moins une clef cryptographique publique ;
    - une deuxième étape d’obtention (E24) d’au moins deux paramètres ;
    - une étape de calcul (E24) d’une clef cryptographique de session en fonction desdits au moins deux paramètres obtenus et de ladite clef cryptographique publique ;
    - une étape de déchiffrement (E26), via ladite clef de session, d’une donnée permettant de valider ladite demande de transfert, ladite donnée étant comprise dans une requête d’acquittement reçue (E16) en provenance dudit au moins un terminal en réponse à l’émission d’une requête d’acceptation (E25) de ladite demande de transfert.
  2. Procédé de transfert selon la revendication 1 dans lequel ladite clef cryptographique publique est chiffrée et en ce que la première étape d’obtention est suivie d’une étape de déchiffrement de ladite clef cryptographique publique via une clef cryptographique symétrique.
  3. Procédé de transfert selon la revendication 1 dans lequel ladite demande de transfert est en provenance dudit terminal mobile.
  4. Procédé de transfert selon la revendication 2 dans lequel ladite demande de transfert comprend en outre une adresse électronique d’au moins un contrat intelligent inscrit à une chaîne de blocs et en ce que ladite clef cryptographique symétrique est obtenue depuis ledit au moins un contrat intelligent.
  5. Procédé de transfert selon la revendication 2 dans lequel ladite clef cryptographique symétrique est obtenue depuis ladite première station de base.
  6. Procédé de transfert selon la revendication 1 dans lequel ladite demande de transfert comprend en outre un identifiant et en ce que l’obtention desdits au moins deux paramètres se fait en fonction dudit identifiant.
  7. Procédé de transfert selon la revendication 1 dans lequel l’obtention desdits au moins deux paramètres se fait depuis un espace de stockage numérique.
  8. Procédé de transfert selon la revendication 1 dans lequel l’étape de calcul comprend le calcul d’une seconde clef cryptographique publique en fonction desdits au moins deux paramètres obtenus et en ce que ladite requête d’acceptation comprend au moins ladite seconde clef publique chiffrée via une clef cryptographique symétrique.
  9. Procédé de transfert selon la revendication 1 dans lequel ladite demande de transfert comprend en outre au moins une première empreinte numérique, qu’une deuxième empreinte numérique d’une donnée dérivée de la donnée initiale de ladite première empreinte numérique est obtenue lors de la deuxième étape d’obtention et qu’une troisième empreinte numérique d’une donnée dérivée de la donnée initiale de ladite deuxième empreinte numérique est comprise dans ladite deuxième donnée.
  10. Procédé de transfert selon la revendication 1 dans lequel la deuxième étape de déchiffrement est suivie d’une étape d’émission à destination d’un contrat intelligent inscrit à une chaîne de blocs d’au moins une commande.
  11. Dispositif de transfert vers une deuxième station de base d’une communication réalisée via une première station de base, ladite communication faisant intervenir au moins un terminal mobile d’un utilisateur, ledit dispositif étant caractérisé en ce qu’il comprend :
    - un premier module d’obtention (OBT1) d’une demande de transfert de ladite communication depuis ladite première station de base vers ladite deuxième station de base, ladite demande comprenant au moins une clef cryptographique publique ;
    - un deuxième module d’obtention (OBT2) d’au moins deux paramètres ;
    - un module de calcul (CALC) d’une clef cryptographique de session en fonction desdits au moins deux paramètres obtenus et de ladite clef cryptographique publique ;
    - un module de déchiffrement (DECRYPT2), via ladite clef de session, d’une donnée permettant de valider ladite demande de transfert, ladite donnée étant comprise dans une requête d’acquittement reçue en provenance dudit au moins un terminal en réponse à l’émission d’une requête d’acceptation de ladite demande de transfert.
  12. Programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 10, lorsque le programme est exécuté par un processeur.
PCT/EP2022/078428 2021-10-13 2022-10-12 Procédé et dispositif de transfert d'une communication d'une station de base à une autre WO2023062095A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2110858A FR3128088B1 (fr) 2021-10-13 2021-10-13 Procédé et dispositif de transfert d’une communication d’une station de base à une autre.
FRFR2110858 2021-10-13

Publications (1)

Publication Number Publication Date
WO2023062095A1 true WO2023062095A1 (fr) 2023-04-20

Family

ID=80225619

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/078428 WO2023062095A1 (fr) 2021-10-13 2022-10-12 Procédé et dispositif de transfert d'une communication d'une station de base à une autre

Country Status (2)

Country Link
FR (1) FR3128088B1 (fr)
WO (1) WO2023062095A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150319665A1 (en) * 2012-09-03 2015-11-05 Mitsubishi Electric Corporation Method and system for performing a handover of a mobile terminal, and mobile terminal intended to be used in a wireless cellular communications network
WO2018222133A2 (fr) * 2017-06-01 2018-12-06 华为国际有限公司 Procédé, appareil, et système de protection de données
CN110149214A (zh) * 2019-06-06 2019-08-20 西南交通大学 无证书聚合签名的lte-r网络群组认证密钥协商方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150319665A1 (en) * 2012-09-03 2015-11-05 Mitsubishi Electric Corporation Method and system for performing a handover of a mobile terminal, and mobile terminal intended to be used in a wireless cellular communications network
WO2018222133A2 (fr) * 2017-06-01 2018-12-06 华为国际有限公司 Procédé, appareil, et système de protection de données
CN110149214A (zh) * 2019-06-06 2019-08-20 西南交通大学 无证书聚合签名的lte-r网络群组认证密钥协商方法

Also Published As

Publication number Publication date
FR3128088A1 (fr) 2023-04-14
FR3128088B1 (fr) 2024-07-05

Similar Documents

Publication Publication Date Title
EP2884716B1 (fr) Mécanisme d'authentificaiton par jeton
EP1427231B1 (fr) Procédé d'établissement et de gestion d'un modèle de confiance entre une carte à puce et un terminal radio
EP1903746B1 (fr) Procédé de sécurisation de sessions entre un terminal radio et un équipement dans un réseau
EP3010175B1 (fr) Rejeu d'un batch de commandes sécurisees dans un canal sécurisé
EP2767111B1 (fr) Procédé de transfert du contrôle d'un module de sécurité d'une première entité à une deuxième entité
WO2006021661A2 (fr) Procede d'authentification securisee pour la mise en œuvre de services sur un reseau de transmission de donnees
EP3732818A1 (fr) Procédé et système d'activation cryptographique d'une pluralité d'équipements
WO2019115943A1 (fr) Technique de protection d'une clé cryptographique au moyen d'un mot de passe utilisateur
WO2016102833A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée
WO2017182747A1 (fr) Procédé d'obtention par un terminal mobile d'un jeton de sécurité
EP1958371A2 (fr) Recouvrement de cles de dechiffrement perimees
EP1949590A1 (fr) Procede de depot securise de donnees numeriques, procede associe de recuperation de donnees numeriques, dispositifs associes pour la mise en uvre des procedes, et systeme comprenant les dits dispositifs
WO2023062095A1 (fr) Procédé et dispositif de transfert d'une communication d'une station de base à une autre
CA3047855A1 (fr) Procede de transmission d'une information numerique chiffree de bout en bout, application de ce procede et objet connecte mettant en oeuvre ce procede
EP4024239A1 (fr) Procede et systeme de stockage et de partage de donnees
WO2022096824A1 (fr) Procede de delegation d'acces a une chaine de blocs
WO2006072746A1 (fr) Procede de securisation d’une communication entre une carte sim et un terminal mobile
FR3086417A1 (fr) Procede cryptographique de comparaison securisee de deux donnees secretes x et y
FR3128089A1 (fr) Procédé et dispositif de sélection d’une station de base
EP3503500B1 (fr) Procédé pour créer une signature électronique à distance au moyen du protocole fido
FR2943198A1 (fr) Procede de production de donnees de securisation, dispositif et programme d'ordinateur correspondant
EP3829204A1 (fr) Procédé et système de contrôle d'accès à des objets connectés, procédés associés de distribution et de réception de données, et produit programme d'ordinateur associé
FR3108818A1 (fr) Procédé et dispositif d’authentification d’un utilisateur auprès d’une application.
WO2021165625A1 (fr) Procede de calcul d'une cle de session, procede de recuperation d'une telle cle de session
FR3112056A1 (fr) Procédé de protection d’un profil d’accès à un réseau contre le clonage

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22800695

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE