FR3136329A1 - Method and device for registering a user with a telecommunications operator. - Google Patents

Abstract

The invention relates to a method for registering a user with a telecommunications operator, said method being implemented by a registration device and characterized in that it comprises: - a first step of receiving a registration request coming from a terminal of said user, said registration request comprising at least one electronic address and at least one transaction data; - a step of storing within a digital storage space at least one personal data of said user obtained from said terminal, obtaining said at least one personal data being carried out according to a result of a test involving said at least one transaction data; - a step of issuing a notification to said at least one address, said notification comprising at least one piece of data relating to the registration status of said user with said operator. Figure for abstract: Figure 2

Description

Method and device for registering a user with a telecommunications operator.

1. Field of the invention

The invention relates to the general field of telecommunications networks, and more specifically to the technology allowing a user to subscribe to a mobile telecommunications offer.

2. Prior Art

To access digital services and their content/functionalities, a user can for example use a mobile terminal via a mobile network. To do this, the user must first register with a mobile telecommunications operator, for example by subscribing to an offer. This registration is generally carried out in stores or digitally (Internet, telephone, etc.) via a process (subscription process) specific to each mobile telecommunications operator. Please note that this subscription may, when the user wishes to change telecommunications operator, result in the termination of a previously subscribed offer. In addition, the user's personal data collected by the mobile telecommunications operator during this operation is rarely accessible to the user.

Thus, the invention proposes a method and a recording device alternative to what is known from the state of the art making it possible to standardize the customer subscription journey regardless of the operator chosen and the possibility for the user to maintain control of their personal data (consultation and/or modification).

3. Presentation of the invention

The invention improves the state of the art and proposes a method of registering a user with a telecommunications operator, said method being implemented by a registration device and characterized in that it comprises :

- a first step of receiving a registration request from a terminal of said user, said registration request comprising at least one electronic address and at least one transaction data;

- a step of storing within a digital storage space at least one personal data of said user obtained from said terminal, obtaining said at least one personal data being carried out according to a result of a test involving said at least one transaction data;

- a step of issuing a notification to said at least one address, said notification comprising at least one piece of data relating to the registration status of said user with said operator.

According to the invention, the method allows a user to register with a telecommunications operator, for example a mobile telecommunications operator. Concretely, the method receives a registration request/request from a mobile terminal of the user which includes an electronic address and transaction data then obtains the result of a test involving the transaction data (use of the data for carrying out the test and/or data deriving from the transaction data, for example a digital fingerprint of the transaction data). When the test is positive (that is to say the transaction data is valid), the method stores personal data of the user obtained previously within a digital storage space (database, file, memory card, etc.). The process then sends to the address obtained a confirmation of the user's registration with the telecommunications operator.

The transaction data may include an arbitrary number (random or pseudo-random) intended to be used only once and to prevent the replay of a transaction (i.e. a “nonce”).

As indicated in the document (https://fr.wikipedia.org/wiki/Blockchain), blockchain technology is a technology for storing and transmitting information without a controlling body. Technically, it is a distributed database whose information sent by users and internal links to the base are verified and grouped at regular time intervals into blocks, the whole being secured by cryptography, and thus forming chain. By extension, 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 transactions carried out since the system was started. 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 there forever. Thus, a blockchain is deemed unalterable and allows the management of sensitive data such as cryptocurrencies (currency issued peer-to-peer without intervention from a central bank). For example, we can cite the decentralized electronic currency Bitcoin created in 2009.

As is known, the security of a blockchain also lies in the fact that transactions carried out on the blockchain are visible to all those who have access to this blockchain. This transparency is a fundamental property of the blockchain.

Furthermore, a smart contract is a small irrevocable computer program that allows transactions within the blockchain to be carried out under certain conditions (executes predefined instructions).

By electronic address we mean a sequence of characters and/or binary data which serves to positively identify a computer service or a device. Such an address is for example composed of an IP address, a MAC address or a URI/URL.

The email address is for example an address of a smart contract registered in a blockchain belonging to the user. The email address can also be the user's address within the blockchain.

According to a particular mode of implementation of the invention, a method as described above is characterized in that said at least one piece of personal data is previously encrypted via a first encryption key before being stored within said space digital storage.

This embodiment makes it possible to add a level of security to the stored personal data. Indeed, only trusted entities having in their possession the decryption key (symmetric or asymmetric key) have the possibility of decrypting the user's personal data.

According to a particular mode of implementation of the invention, a method as described above is characterized in that said test result is obtained from a smart contract belonging to the telecommunications operator in response to the transmission of 'a test request comprising said at least one piece of transaction data and said at least one electronic address.

This embodiment makes it possible to verify the validity of the transaction data with a smart contract of the telecommunications operator. Concretely, the smart contract of the telecommunications operator processes the transaction data obtained from the test request issued by the method then returns the result of the processing (for example in the form of a Boolean, 1 if the data is identical, 0 otherwise) to the process. More broadly, this embodiment allows the telecommunications operator to validate or not the registration request issued by the user.

According to a particular mode of implementation of the invention, a method as described above is characterized in that said test comprises a step of obtaining at least one digital fingerprint by applying a cryptographic function to said at least one transaction data and a step of comparing said at least one digital fingerprint with at least one reference data obtained from a smart contract belonging to the telecommunications operator.

This embodiment makes it possible to add a level of security to the transaction. Indeed, if the digital fingerprint of the transaction data does not correspond to the reference data then the request received from the user's terminal is considered invalid. Obviously this assumes that only trusted entities have access to the cryptographic function (for example the user and/or their terminal or the telecommunications operator via for example a smart contract belonging to them.). Concretely, the process compares the digital fingerprint of the transaction data obtained by the process with reference data, for example obtained from a smart contract of the telecommunications operator. The reference data may correspond to the digital fingerprint of the transaction data previously obtained from a smart contract of the user by the smart contract of the telecommunications operator.

By digital fingerprint we mean data obtained via a cryptographic function such as a hash function making it possible to identify the initial data processed by the hash function.

According to a particular mode of implementation of the invention, a method as described above is characterized in that the storage step is preceded by a step of comparing said at least one piece of personal data with at least one certified data obtained and in that the storage step is further conditioned by the result of said comparison.

This embodiment makes it possible to ensure the accuracy of personal data before it is stored. For example, the method can obtain the user's up-to-date personal data (certified data within the meaning of the invention) of the user from a trusted third party and then compare them with the personal data obtained from the user's terminal. When the comparison is positive, that is to say the data corresponds, the process stores the personal data within a digital storage space (database, file(s), memory card, etc. ). Otherwise, the process does not store any personal data.

According to a particular mode of implementation of the invention, a method as described above is characterized in that the storage step is preceded by a step of comparing a digital fingerprint with at least one certified piece of data obtained, said digital fingerprint being obtained by application of a cryptographic function to said at least one piece of personal data, and in that the storage step is further conditioned by the result of said comparison.

This embodiment makes it possible to ensure the accuracy of personal data before it is stored. Using a digital fingerprint adds a level of security. Indeed, only trusted entities with access to the cryptographic function can generate a digital fingerprint of the user's personal data (for example the user's telecommunications operator, the user himself, a trusted authority , etc.).

According to a variant of the two previous particular modes of implementation of the invention, a method as described above is characterized in that said at least one piece of certified data is obtained from said at least one electronic address.

This embodiment makes it possible to obtain the certified data(s) from an electronic address obtained during the reception step. This email address is for example the address of a smart contract belonging to the user. Note that the intrinsic properties of the blockchain allow data certification.

According to a particular mode of implementation of the invention, a method as described above is characterized in that the storage step is followed by a second step of receiving at least one electronic storage address in coming from the digital storage space and in that said at least one recording status data item further comprises said at least one received storage electronic address.

This embodiment makes it possible to share the electronic address for storing the user's personal data. For example, when the email address obtained in the registration request corresponds to an address in a smart contract of the user, the user is then notified of the storage of his personal data within the digital storage space and their locations.

According to a particular mode of implementation of the invention, a method as described above is characterized in that said at least one registration status data item further comprises at least one second cryptographic key encrypted via said first cryptographic key .

This embodiment makes it possible to share the cryptographic material necessary for decrypting the user's personal data. The encrypted cryptographic key(s) are for example issued to a smart contract of the user. The cryptographic keys are for example encrypted via a symmetric encryption key shared between the user and the operator or via a public cryptographic key of the user. Thus, only the telecommunications operator and the user have the possibility of decrypting the cryptographic keys and consequently the user's personal data (data confidentiality).

The invention also relates to a device for registering a user with a telecommunications operator, characterized in that it comprises:

- a first module for receiving a registration request coming from a terminal of said user, said registration request comprising at least one electronic address and at least one transaction data;

- a storage module within a digital storage space for at least one personal data of said user obtained from said terminal, obtaining said at least one personal data being carried out according to a result of a test involving said at least one transaction data;

- a module for issuing a notification to said at least one address, said notification comprising at least one piece of registration status data for said user with said operator.

According to a particular mode of implementation of the invention, a device as described above is characterized in that it is understood by a computer server of the telecommunications operator.

The term module can correspond as well to a software component 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 subprograms or more generally to any element of a program capable of implementing a function or a set of functions as described for the modules concerned. In the same way, a hardware component corresponds to any element of a 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 of the particular embodiments described above, when said program is executed by a processor. The method can be implemented in various ways, notably in hardwired 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 a partially compiled form, or in any other desirable shape.

The invention also relates to a recording medium or information medium readable by a computer, and comprising instructions for a computer program as mentioned above. The recording media mentioned above can be any entity or device capable of storing the program. For example, the support 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. On the other hand, 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 over an Internet type network.

Alternatively, 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 recording device and this computer program have characteristics and advantages similar to those described previously in relation to the recording process.

4. List of figures

Other characteristics and advantages of the invention will appear more clearly on reading the following description of particular embodiments, given as simple illustrative and non-limiting examples, and the appended drawings, among which:

There represents the hardware architecture of a recording device according to a particular embodiment,

There represents in flowchart form the main stages of a recording process according to a particular embodiment of the invention,

There represents in flowchart form the main stages of a recording process according to a second particular embodiment of the invention.

5. Description of an embodiment of the invention

5.1 General principle of the invention

The objective of the invention is to allow a user to manage their identity(ies)/personal data within a mobile telecommunications network. The objective is also to offer a method that allows the user to easily choose/change mobile telecommunications operator.

5.2 Particular modes of carrying out the invention.

There represents the hardware architecture of a DE recording device according to the invention. In the embodiment described here, this device has the hardware architecture of a computer. It notably includes a PROC1 processor, an MV1 RAM, a MEM1 read-only memory and an MF1 non-volatile flash memory. Such means are known per se and are not described in more detail here. The read-only memory 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 recording method as described previously, when the program is executed by the processor PROC1.

At initialization, 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 implements in particular the steps of the recording process according to any one of the particular embodiments described in relation to the , according to the instructions of the computer program PG1.

The DE device also includes reception modules (RECV1, RECV2) respectively capable of receiving from a user's terminal a user registration request and the user's personal data. Note that the user registration request includes at least one email address and at least one transaction data.

According to a particular embodiment, the RECV1, RECV2 modules are one and the same module.

The DE device further comprises a STOCK1 storage module capable of storing the user's personal data within a digital storage space (file(s), database, memory card, etc.).

In addition, the DE device comprises a transmission module (SND1) capable of issuing a notification to the received electronic address including a status of the user's registration with a telecommunications operator.

The DE device also includes a TEST module capable of carrying out tests with data obtained such as the transaction data received. The test can also be carried out with data derived from the transaction data, for example a digital fingerprint of the transaction data.

The DE device may include an encryption module (not shown) capable of encrypting data such as personal data obtained by the RECV2 module.

There illustrates steps of the recording process according to a particular embodiment of the invention. The embodiment described here corresponds to a first registration of a user. There consists of a terminal (UE), for example a mobile terminal, an electronic tablet or a laptop computer capable of sending and/or receiving requests via for example a private or public IP network. The UE terminal is also capable of using the services provided by a mobile telecommunications operator. The UE terminal may include a secure element such as a Subscriber Identity/Identification Module SIM card, eSIM (embedded SIM), iSIM (integrated SIM), a TEE (Trusted Execution Environment), etc. The secure element includes user data such as a user's public/private cryptographic key pair, a user's blockchain address, and potentially a user's smart contract (wallet) address. cryptography associated with the blockchain).

According to a particular embodiment, the user's public/private cryptographic key pair, the user's blockchain address and potentially the address of a user's smart contract are stored in the memory of the UE terminal for example in a cryptographic wallet associated with the blockchain (in English Wallet).

According to a particular embodiment, the secure element is not included in the terminal UE but is connected to the terminal UE.

There also includes a digital storage space (ESN), for example a database (distributed or not), a blockchain (BC) and a server operated by a telecommunications operator (NP). According to a particular embodiment of the invention, the digital storage space (ESN) can be implemented in accordance with IPFS (InterPlanetary File System) technology.

In the example described below, the recording process is executed by the NP server.

The blockchain is for example deployed by a root entity such as a regulatory authority for the needs of a country's telecommunications operators, with the telecommunications operators having the role of validator/miner of the blockchain consensus process. The blockchain can include several smart contracts (SC _reg , SC _UE , SC _UB , SC _NPB , SC _NP ).

The SC smart contract_reg manages the user's registration request with a telecommunications operator.

The SC _UE smart contract is a smart contract that is owned by the user. This contract allows certain user data to be saved (link to a digital storage space, encrypted cryptographic keys, etc.). Please note that all data is stored privately, i.e. not visible to other users of the blockchain.

The SC _UB smart contract saves the “user identifier / user smart contract address” pairs. The user identifier can be an IMSI (International Mobile Subscriber Identity), the identifier used by the user to access the BC blockchain (their address within the blockchain) or any other element allowing access to the BC blockchain. unambiguously identify the user.

The SC _NPB smart contract saves the list of telecom operators approved by the “root” entity that deployed the blockchain.

The SC _NP smart contract belongs to a telecommunications operator and saves registration or termination requests from users.

According to a particular embodiment of the invention, smart contracts can be distributed within a plurality of blockchains.

According to a particular embodiment of the invention, the functionalities of smart contracts (SC _reg , SC _UE , SC _UB , SC _NPB , SC _NP ) can be grouped within one or a plurality of smart contracts.

During a first step E101, the terminal UE sends a request to the smart contract SC_reg. This request may contain the name (NP) of the telecommunications operator to which the user wishes to subscribe, a digital fingerprint of a “nonce” and an identifier of the user and/or their terminal. The “nonce” is for example a random number generated by an application executed by the user’s UE terminal. The digital fingerprint is for example calculated using a cryptographic function H (for example the “Keccak-256” algorithm). The request is received by the smart contract SC_regduring step E102. At step E103a the smart contract SC_reg checks whether a smart contract belonging to the user has previously been deployed within the BC blockchain. If not, the SC smart contract_regdeploys SC smart contract_EUof the user (E104). Once the smart contract SC_EUdeployed, the SC smart contract_regregisters the user (E103b) by adding (E105) the pair “user identifier / user smart contract address” within the smart contract SC_UB.

• l’identifiant reçu lors de l’étape E102 ;
• l’adresse du contrat intelligent SC_UE(AddrSC_UE) ;
• l’empreinte numérique du nonce reçue lors de l’étape E102 ;
• un paramètre Type_reqindiquant le type de requête, par exemple positionné à la valeur 1 pour un premier enregistrement (le contrat intelligent SC_UEn’existait pas préalablement) ou bien à la valeur 2 pour une demande de changement d’opérateur de télécommunications de la part de l’utilisateur.

In step E106a, the smart contract SC _reg sends a request to the smart contract SC _NPB in order to check whether the name of the telecommunications operator received (E102) is indeed a telecommunications operator known and approved by the entity who deployed the BC blockchain (i.e. the entity that manages the system). The request is received by the smart contract SC _NPB during step E107a. A response is then sent (E107b) to the smart contract SC _reg then received during step E106b. If the name of the telecommunications operator is not validated by the SC _NPB smart contract then the process ends. An error message is sent by the smart contract SC _reg to the terminal UE (not shown). Otherwise, during step E108, the smart contract SC _reg sends a request to the smart contract of the operator SC _NP comprising for example, alternatively or cumulatively, the following data:

• the identifier received during step E102;
• the address of the SC _UE smart contract (AddrSC _UE );
• the digital fingerprint of the nonce received during step E102;
• a Type _req parameter indicating the type of request, for example positioned at the value 1 for a first recording (the SC _UE smart contract did not previously exist) or at the value 2 for a request to change the telecommunications operator of on the part of the user.

The data is received (E110) then stored by the smart contract of the operator SC _NP .

During step E111, the smart contract SC _reg sends a response to the terminal UE which may include the address of the smart contract SC _UE (AddrSC _UE ) and/or a link (for example a URL) of a page internet operated by the telecommunications operator allowing the user to register. The user terminal UE receives the response (E112) then sends (E113) to the URL (i.e. the website of the telecommunications operator NP) a request (registration request within the meaning of the invention) which alternately or cumulatively includes the user identifier, the “nonce” (transaction data within the meaning of the invention) and the address of the smart contract SC _UE (AddrSC _UE ). In the example described below, the user identifier corresponds to the identifier that the user uses to authenticate at the BC blockchain level (their address within the Addr _ue blockchain ).

According to a particular mode of implementation of the invention, steps E111, E112, E113 correspond to the transmission by the smart contract SC _reg of a redirection request to the terminal UE towards the operator's URL telecommunications, the redirection request being a registration request within the meaning of the invention and enriched by the terminal UE with alternately or cumulatively the address of the smart contract SC _UE (AddrSC _UE ), the “nonce” and the identifier of the user within the blockchain (Addr _ue ).

The registration request is received by the telecommunications operator NP during step E114. The operator NP then verifies the validity of the registration request via a verification request sent (E115) to its smart contract SC _NP . This verification request alternately or cumulatively includes the address of the SC _UE smart contract (AddrSC _UE ), the “nonce” and the user identifier within the blockchain (Addr _ue ). The request is received by the smart contract SC _NP in step E116. Thanks to the address of the smart contract SC _UE (AddrSC _UE ) and/or the user identifier (Addr _ue ) obtained, the smart contract SC _NP obtains (E117) the digital fingerprint of the “nonce » of the user stored during step E110. The smart contract SC _NP which holds the cryptographic function H calculates the digital fingerprint of the “nonce” received during step E116 and compares it (E117) to that obtained during step E110. In the case where the digital fingerprints correspond then the registration request is validated and the smart contract SC _NP responds (E118) positively to the verification request issued during step E115.

Otherwise, the smart contract SC _NP responds (E118) negatively to the verification request issued during step E115. During step E119, the telecommunications operator NP receives the response to the request for verification of the registration request and sends the status of the registration (for example valid or invalid) to the terminal UE (E120 ). The status is then received by the terminal UE during step E121. In case the status is negative, the process stops (not shown). Otherwise, the request sent by the NP operator also includes a URL of a form.

According to a particular mode of implementation of the invention, the method can during step E115 send to the smart contract SC _NP a request for reference data. This request may include the address of the SC _UE smart contract (AddrSC _UE ) and/or the user identifier within the blockchain (Addr _ue ). The request is received by the smart contract SC _NP in step E116. Thanks to the address of the smart contract SC _UE (AddrSC _UE ) and/or the user identifier (Addr _ue ) obtained, the smart contract SC _NP obtains (E117) the digital fingerprint of the “nonce » of the user stored during step E110. The SC _NP smart contract sends a response (E118) to the NP server, a response which may include the digital fingerprint of the “nonce” stored during step E110. In this case the digital fingerprint of the “nonce” (H(nonce)) stored during step E110 corresponds to the reference data within the meaning of the invention. The reference data is received by the server NP during step E119. The smart contract SC _NP then compares (E119) the reference data with a digital fingerprint obtained via the application of a cryptographic function H to the “nonce” obtained during step E114. Note that the cryptographic function H is obtained by the method (ie by the server NP) prior to step E115. If the digital fingerprints match then the registration request is validated. The telecommunications operator NP then sends the status of the registration (for example valid or invalid) to the terminal UE (E120). The status is then received by the terminal UE during step E121. In case the status is negative, the process stops (not shown). Otherwise, the request sent by the NP operator also includes a URL of a form.

During step E122, the user of the UE terminal completes the form with his personal data (M) then sends the completed form as well as a Pub _UE public encryption key belonging to him, for example obtained from the secure element of the EU terminal, intended for the telecommunications operator NP. The personal data (M) and the key (Pub _UE ) are received by the telecommunications operator NP during step E123.

According to a particular mode of implementation of the invention, the user's personal data can be obtained by the NP server via a trusted third party. In this case, the URL of the form is not sent to the UE terminal during step E120 and only a public encryption key belonging to the user/user terminal (Pub _UE ) is sent to the the telecommunications operator NP during step E122.

During step E124, the telecommunications operator NP generates a symmetric encryption key (S _k ) and encrypts this key via the user's encryption key obtained (Pub _UE ).

Then, the user's personal data (M) is encrypted via the encryption key S _k .

During step E125, the telecommunications operator NP sends the user's personal data encrypted intended for an ESN digital storage space.

Alternatively, the personal data M are not encrypted and are stored within the digital storage space ESN during step E126.

The data are received and stored during step E126 by the ESN entity. In response, the ESN entity sends (E127) to the NP server a data storage address (for example a (Content IDentifier) CID ( )) allowing unambiguous retrieval of data within the ESN digital storage space. THE is received by the process during step E128.

During step E129, the method transmits to the smart contract SC _UE (alternatively or cumulatively to the terminal UE and/or the Addr _ue address), thanks for example to the AddrSC _UE address obtained during the step E114, an end of recording request (notification within the meaning of the invention) comprising recording status data. The registration status data may alternately or cumulatively include the CID ( ), , a digital fingerprint of the data M (Hash(M)) and the data M. Note that the digital fingerprint of the data M can be the result of the application of the cryptographic function H to the personal data M or of a another cryptographic function H' known for example to the telecommunications operator NP.

• la suppression des contrats intelligents SC_reg, SC_npet SC_UB;
• l’opérateur de télécommunications est un nouvel opérateur (NP_new) et possède un contrat intelligent SC_NPnew;
• l’ajout du contrat intelligent SC_AM.

There illustrates steps of the recording process according to a second particular embodiment of the invention. The embodiment described here corresponds to a change of operator on the part of the user. Obviously this assumes that the user has previously registered via the procedure described in support of the . The environment of the is identical to that of the except:

• the removal of smart contracts SC _reg , SC _np and SC _UB ;
• the telecommunications operator is a new operator (NP _new ) and has a smart contract SC _NPnew ;
• the addition of the SC _AM smart contract.

The SC _AM smart contract is a smart contract that allows you to manage the delegation of access rights to the user's personal data.

During step E201 the user (ie the terminal UE) sends, via the AddrSC _UE address obtained during step E112, a request to his smart contract SC _UE in order to change telecommunications operator. Concretely, the user wishes to switch from the telecommunications operator NP to NP _new . This request may contain the name (NP _new ) of the new telecommunications operator to which the user wishes to subscribe, a digital fingerprint of a “nonce” and an identifier of the user and/or their terminal. The “nonce” is for example a random number generated by an application executed by the user's terminal UE. The digital fingerprint is for example calculated using a cryptographic function H (for example the “Keccak-256” algorithm). Note that in this embodiment, the “nonce” may be different from that used in the embodiment described in support of the . Likewise, the cryptographic function H may be different from that used to support the .

The request is received by the SC contract_EUduring step E202. At step E203 the smart contract SC_EU issues a telecommunications operator change management request to the smart contract SC_A.M.comprising for example, alternatively or cumulatively, the following data:

- the digital fingerprint of the nonce received during step E202;

- the identifier of the user and/or their terminal;

- the name (NP _new ) of the new telecommunications operator.

The management request is received by the smart contract SC _AM during step E204. The smart contract SC _AM then sends, to the smart contract SC _NPB, a request including at least the name of the new telecommunications operator (NP _new ) obtained in order to check whether it is indeed a telecommunications operator known and approved by the entity that deployed the BC blockchain (i.e. the entity that manages the system). The request is received by the smart contract SC _NPB during step E205. A response is then sent (E206) to the smart contract SC _AM then received during step E207. If the name of the telecommunications operator is not validated by the SC _NPB smart contract then the process ends. An error message is sent by the smart contract SC _AM to the terminal UE via for example the smart contract SC _UE (not shown).

• l’identifiant de l’utilisateur et/ou de son terminal ;
• l’adresse du contrat intelligent SC_UE(AddrSC_UE) ;
• l’empreinte numérique du nonce reçue lors de l’étape E204 ;
• un paramètre Type_reqindiquant le type de requête, par exemple positionné à la valeur 1 pour un premier enregistrement (le contrat intelligent SC_UEn’existait pas préalablement) ou bien à la valeur 2 pour une demande de changement d’opérateur de télécommunications de la part de l’utilisateur.

Otherwise, during step E208, the smart contract SC _AM sends a request to the smart contract of the operator SC _{NP new} comprising for example, alternatively or cumulatively, the following data:

• the identifier of the user and/or their terminal;
• the address of the SC _UE smart contract (AddrSC _UE );
• the digital fingerprint of the nonce received during step E204;
• a Type _req parameter indicating the type of request, for example positioned at the value 1 for a first recording (the SC _UE smart contract did not previously exist) or at the value 2 for a request to change the telecommunications operator of on the part of the user.

The data is received (E210) then stored by the smart contract of the operator SC _{NP new} . During step E211, the smart contract SC _AM sends a response to the smart contract SC _UE validating the telecommunications operator. This response may include the Type _req parameter and/or a link (for example a URL) of a web page operated by the new telecommunications operator NP _new allowing the user to register. The response is received by the smart contract SC _UE during step E212.

In step E213, the smart contract SC _UE sends a response to the terminal UE which includes the link obtained during step E212. The user terminal UE receives the response (E214) then sends (E215) to the link (for example the URL of the website of the telecommunications operator NP _new ) a request (registration request within the meaning of the invention ) which alternately or cumulatively includes the user identifier, the “nonce” (transaction data within the meaning of the invention) and the address of the smart contract SC _UE (AddrSC _UE ). In the example described below, the user identifier corresponds to the identifier that the user uses to authenticate at the BC blockchain level (their address within the Addr _ue blockchain ).

According to a particular mode of implementation of the invention, steps E213, E214, E215 correspond to the transmission by the smart contract SC _UE of a redirection request to the terminal UE towards the operator's URL telecommunications, the redirection request being a registration request within the meaning of the invention and enriched by the terminal UE with alternately or cumulatively the address of the smart contract SC _UE (AddrSC _UE ), the “nonce” and the identifier of the user within the blockchain (Addr _ue ).

The registration request is received by the telecommunications operator NP _new during step E216. The NP _new operator then verifies the validity of the registration request via a verification request issued (E217) to its smart contract SC _NPnew . This verification request alternately or cumulatively includes the address of the SC _UE smart contract (AddrSC _UE ), the “nonce” and the user identifier within the blockchain (Addr _ue ). The request is received by the smart contract SC _NPnew in step E218. Thanks to the address of the smart contract SC _UE (AddrSC _UE ) and/or the user identifier (Addr _ue ) obtained, the smart contract SC _NP obtains (E219) the digital fingerprint of the “nonce » of the user stored during step E210. The smart contract SC _{NP new} which holds the cryptographic function H calculates the digital fingerprint of the “nonce” received during step E218 and compares it (E219) to that obtained during step E210. In the case where the digital fingerprints correspond then the registration request is validated and the smart contract SC _{NP new} responds (E220) positively to the verification request issued during step E217.

Otherwise the smart contract SC _{NP new} responds (E220) negatively to the verification request issued during step E217.

During step E221, the telecommunications operator NP _new receives the response to the request for verification of the registration request and sends the status of the registration (for example valid or invalid) to the terminal UE ( E222). The status is then received by the terminal UE during step E223. In case the status is negative, the process stops (not shown). Otherwise, the request issued by the NP _new operator also includes a request for personal data (M) of the user.

According to a particular mode of implementation of the invention, the method can during step E217 transmit to the smart contract SC_{NP new} a request for reference data. This request may include the address of the smart contract SC_EU(AddrSC_EU) and/or the user identifier within the blockchain (Addr_eu). The request is received by the smart contract SC_{NP new}in step E218. Thanks to the address of the smart contract SC_EU(AddrSC_EU) and/or the user identifier (Addr_eu) obtained, the smart contract SC_{NP new} obtains (E219) the digital fingerprint of the user’s “nonce” stored during step E210. The SC smart contract_{NP new} sends a response (E220) to the NP server_new, response which may include the digital fingerprint of the “nonce” stored during step E210. In this case the digital fingerprint of the “nonce” (H(nonce)) stored during step E210 corresponds to the reference data within the meaning of the invention. The reference data is received by the NP server_newduring step E221. The SC smart contract_{NP new}then compares (E221) the reference data with a digital fingerprint obtained via the application of a cryptographic function H to the “nonce” obtained during step E216. Note that the cryptographic function H is obtained by the process (i.e. by the server NP_new) prior to step E217. If the digital fingerprints match then the registration request is validated by the NP server_new. The telecommunications operator NP_newthen transmits the status of the registration (for example valid or invalid) to the UE terminal (E222). The status is then received by the terminal UE during step E223. In case the status is negative, the process stops (not shown). Otherwise, the request issued by the operator NP_newfurther includes a request for personal data (M) of the user.

During step E224, the terminal UE sends a request to the ESN server (via the CID obtained during step E130) in order to obtain the encrypted data of the user. The request is received by the ESN server during step E225. The data are obtained by the ESN server then sent (E226) to the UE terminal. The data are then received by the terminal UE during step E227. In step E228, the terminal calculates the symmetric encryption key S _k ( , then decrypts the data in order to obtain his unencrypted personal data M ( ).

Note that the user's personal data M may be identical or different from that stored during step E124. Indeed, the personal data (M) may have been modified in the meantime, for example, by the telecommunications operator NP. In this case, when the user's personal data is also stored within their SC _UE smart contract, these can also be updated/modified.

During step E229 the terminal UE sends a response to the server NP _new which can include the data M obtained as well as a public encryption key belonging to the user (Pub _UE ). The personal data M and the Pub _UE key are received by the telecommunications operator NP _new during step E230.

Alternatively, during step E229, the terminal UE can send to the server NP _new the encryption key S _k , the Pub _UE key and the CID . The ESN server then obtains from the CID the data then decrypts them via the key S _k obtained (not shown). In this case, steps E224, E225, E226 and E227 are not carried out. In addition, only the calculation of the symmetric encryption key S _k is carried out during step E228.

Once the data M has been obtained by the server NP _new , the server NP _new verifies that the data has not been corrupted. For this, the NP _new server can issue a request (E231) to the smart contract SC _UE in order to obtain the user's personal data stored during step E130 (certified data within the meaning of the invention). The request is received by the smart contract SC _UE during step E232. The SC _UE smart contract issues a response (E233) including the previously stored data. The response is received by the NP _new server during step E234. The method then compares the personal data received from the smart contract (E234) of the user with the personal data received from the user terminal (E230). When the comparison is positive, that is to say the data matches, the process continues. Otherwise, the process stops and an error message is sent to the user's terminal (not shown).

Alternatively, the process can obtain certified data from a trusted third party, for example via a smart contract belonging to the entity that deployed the BC blockchain.

According to a particular mode of implementation of the invention, the NP _new server can issue a request (E231) to the smart contract SC _UE in order to obtain a digital fingerprint of the user's personal data stored during the step E130 (certified data within the meaning of the invention). The request is received by the smart contract SC _UE during step E232. The SC _UE smart contract issues a response (E233) including the previously stored digital fingerprint. The response is received by the NP _new server during step E234. The method then compares the digital fingerprint received from the smart contract (E234) of the user with a digital fingerprint obtained via the application of a cryptographic function H' to the personal data M obtained during step E230. Note that the cryptographic function H' is obtained by the process (ie by the NP _new server) beforehand. According to a particular mode of implementation of the invention, the cryptographic function H' corresponds to the cryptographic function H.

When the comparison is positive, that is to say the data matches, the process continues. Otherwise, the process stops and an error message is sent to the user's terminal (not shown).

During step E235, the telecommunications operator NP _new generates a symmetric encryption key ( ) and encrypts this key via the user's encryption key obtained (Pub _UE ).

Then, the user's personal data (M) is encrypted via the encryption key .

During step E236, the telecommunications operator NPnew sends the user's personal data encrypted destined for the ESN digital storage space.

Alternatively, the personal data M are not encrypted and are stored within the digital storage space ESN during step E237.

The data are received and stored during step E237 by the ESN entity. In response, the ESN entity sends (E238) to the NP _new server a data storage address (for example a CID ( )) allowing unambiguous retrieval of data within the ESN digital storage space. The Cid is received by the process during step E239.

During step E240, the method sends to the smart contract SC _UE (alternatively or cumulatively to the terminal UE and/or the Addr _UE address), thanks for example to the AddrSC _UE address obtained during the step E216, an end of recording request (notification within the meaning of the invention) comprising recording status data. The registration status data may include the CID ( ), and/or a digital fingerprint of the data M (Hash(M)). Note that the digital fingerprint of the data M can be the result of the application of the cryptographic function H to the personal data M or of another cryptographic function H'' known for example to the telecommunications operator NP _new .

It goes without saying that the embodiment which has been described above has been given for purely indicative purposes and is in no way limiting, and that numerous modifications can easily be made by those skilled in the art without departing from the scope. of the invention.

Claims (11)

Method for registering a user with a telecommunications operator, said method being implemented by a registration device and characterized in that it comprises:
- a first step of receiving (E114, E216) a registration request coming from a terminal of said user (UE), said registration request comprising at least one electronic address (AddrSC _{UE ,} Addr _ue ) and at minus one transaction data (nonce);
- a step of storing (E125, E236) within a digital storage space (ESN) of at least one personal data of said user (M) obtained (E123, E230) from said terminal (UE), obtaining said at least one piece of personal data being produced as a function of a result of a test (E117, E219) involving said at least one piece of transaction data (nonce);
- a step of transmitting (E129, E240) a notification to said at least one address (AddrSC _{UE ,} Addr _{ue )} , said notification comprising at least one piece of registration status data for said user with said operator. Recording method according to claim 1 in which said at least one piece of personal data (M) is previously encrypted via a first encryption key (S _k , ₎ before being stored in said digital storage space. Recording method according to claim 1 in which said test result is obtained (E119, E221) from a smart contract belonging to the telecommunications operator (SC _NP , SC _NPnew ) in response to the transmission (E115, E217) of a test request comprising said at least one transaction data (nonce) and said at least one electronic address (AddrSC _{UE ,} Addr _ue ). Recording method according to claim 1 in which said test comprises a step of obtaining (E119, E221) at least one digital fingerprint (H(nonce)) by applying a cryptographic function (H) to said at least transaction data (nonce) and a step of comparing said at least one digital fingerprint with at least one reference data obtained from a smart contract belonging to the telecommunications operator (SC _NP, SC _NPnew ). Recording method according to claim 1 in which the storage step (E236) is preceded by a step of comparing said at least one personal data (M) with at least one certified data obtained and in that the step storage is further conditioned by the result of said comparison. Recording method according to claim 1 in which the storage step (E236) is preceded by a step of comparing a digital fingerprint with at least one certified data obtained, said digital fingerprint being obtained by application of a function cryptographic (H') to said at least one personal data (M), and in that the storage step (E125) is further conditioned by the result of said comparison. Registration method according to claims 5 and 6 in which said at least one piece of certified data is obtained from said at least one electronic address. Recording method according to claim 1 in which the storage step (E125, E236) is followed by a second step of receiving (E128, E239) of at least one electronic storage address coming from the storage space. digital storage (ESN) and in that said at least one registration status data item further comprises said at least one received storage electronic address. Registration method according to claim 2 in which said at least one registration status data item further comprises at least one second cryptographic key (Pub _UE ) encrypted via said first cryptographic key (S _k , ₎ . Device for registering a user with a telecommunications operator, characterized in that it comprises:
- a first module (RECV1) for receiving a registration request from a terminal of said user, said registration request comprising at least one electronic address and at least one transaction data;
- a storage module (STOCK1) within a digital storage space of at least one personal data of said user obtained (RECV2) from said terminal, obtaining said at least one personal data being carried out as a function of a result of a test (TEST) involving said at least one piece of transaction data;
- a module for transmitting (SND1) a notification to said at least one address, said notification comprising at least one piece of registration status data for said user with said operator. Computer program comprising instructions for implementing the method according to any one of claims 1 to 9, when the program is executed by a processor.