WO2018234662A1

WO2018234662A1 - Method of control of the obtaining by a terminal of a configuration file

Info

Publication number: WO2018234662A1
Application number: PCT/FR2018/051404
Authority: WO
Inventors: Stéphane CAZEAUX; Julien ZIMMERMANN
Original assignee: Orange
Priority date: 2017-06-20
Filing date: 2018-06-14
Publication date: 2018-12-27
Also published as: EP3643035A1; FR3067538A1

Abstract

The method of control is intended to be implemented by a service management server and comprises: ¾ the application (E30,E40) of a default configuration according to which the management server rejects any request for obtaining a configuration file by a terminal as long as the latter is not associated with a user in a database of the server; ¾ on receipt (E20,E100) of a first request for obtaining by a terminal of a configuration file comprising a first access address of the file: the checking (E30,E110) whether the terminal is associated with a user in the database; if relevant, the generation (E120) of a secure token for the terminal and the transmission (E130) to the terminal of a second access address for the file including the token; ¾ on reception (E160) of a second request for obtaining (REQ2) by the terminal of the file comprising the second address: the checking (E170) whether the token included in the second address is valid; and if relevant, the triggering (E180) of a making available of the file to the terminal.

Description

Method for controlling the obtaining by a terminal of a configuration file

Background of the invention

The invention relates to the general field of telecommunications.

It relates more particularly to obtaining by a terminal of a configuration file allowing access to a service, for example a communication service. Such a configuration file typically comprises the technical elements enabling a user to take advantage of the communication service via his terminal such as, in particular, a login and a password assigned to the user to connect to the communication service, user parameters (ex. address book, telephone number assigned to it, etc.), and technical parameters intended to be implemented by the terminal during a communication service session (eg audio / video codecs, parameters voice over IP, etc.).

No limitation is attached to the nature of the terminal or the nature of the service. The terminal can be fixed or mobile, hardware or software; it may be for example a smartphone (or "smartphone"), a computer, a digital tablet, or a software application (eg "softphone") seeking access to a service voice over IP, video service, etc.

In the current state of the art, the configuration of a terminal to access a communication service offered by a network is done via the download by the terminal of a configuration file hosted on a remote configuration server (ex. SFST (Secure Shell File Transfer Protocol) or HTTP (HyperText Transfer Protocol) server, using an access address to this file that is configured at the factory in the terminal, this address includes, generically, the address (ex. URL (Uniform Resource Locator)) of the remote server, and the name of the configuration file, which is generated from a technical parameter of the terminal, typically its MAC (Medium Access Control) address.This address is very easy to generate once you know the MAC address of the terminal.

When the download of the configuration file is implemented via a secure access network by nature (eg virtual private network or VPN (Virtual Private Network) or network operator), the security measures implemented by the network of Access is usually sufficient to ensure that only a given terminal of a user accesses the configuration file intended for him and no other.

However, today there are more and more offers on the market for communication services that are not members of such an access network and which rely on the public Internet network directly for terminal configuration.

To secure these offers, various techniques can be considered.

A first technique may consist in particular of implementing, prior to obtaining the configuration file by the terminal, mutual authentication between the terminal and the communication service provider, via, for example, the TLS protocol. (Transport Layer Security) conventionally used to secure the transport of information within computer networks. For this purpose, a TLS certificate can be supplied at the factory to the terminal. Unfortunately, this TLS certificate can be easily extracted from the terminal and thus compromised for use by a malicious third party device.

A second technique may consist in imposing the entry by the user of the terminal, for example at the start of the terminal and prior to its configuration, an identifier and a password specific to the communication service and the user. This second technique, however, imposes a constraint of use on the user which may be difficult to accept in practice by the latter.

There is therefore a need for a technique for securing access by terminals to their configuration files in particular when they use to download these configuration files an unsecured network such as the public Internet network.

Object and summary of the invention

The invention makes it possible to respond in particular to this need by proposing an automatic configuration mechanism of a terminal which advantageously relies on the existing procedures and reinforces their security via the generation of a secure token specifically for the terminal, triggered as soon as possible. when it is clearly associated with a user, this token used to define a secure address from which the terminal can access its configuration file.

More specifically, the invention relates, according to a first aspect, to a method of controlling the obtaining by a terminal of a configuration file enabling it to access a service, this method being intended to be implemented by a server service management and comprising:

A step of applying a default configuration according to which the management server rejects any request to obtain a configuration file by a terminal as long as this terminal is not associated with a user in a database the management server;

On receipt of a first request from a terminal for obtaining a configuration file comprising a first access address to the configuration file:

o a verification step if the terminal is associated with a user in the database;

o if the terminal is associated with a user in the database,

^■ a step of generating a secure token to the terminal; and

^■ to a step of transmitting the terminal to a second access address to the configuration file including the secure token;

On receipt of a second request from the terminal for obtaining the configuration file comprising the second address: o a verification step if the secure token included in the second address included in the second obtaining request is valid; and

o if the token is valid, a step of triggering a provision of the terminal of the configuration file.

In a particular embodiment, the service is a communication service.

Correlatively, the invention also relates to a management server of a service, configured to control the obtaining by a terminal of a configuration file allowing it to access the service, the management server comprising:

An application module of a default configuration according to which the management server rejects any request to obtain a configuration file by a terminal as long as this terminal is not associated with a user in a database the management server;

Modules, activated on receipt of a first request for obtaining the configuration file by a terminal comprising a first access address to the configuration file, and comprising:

o a first verification module, configured to check whether the terminal is associated with a user in the database;

a module for generating a secure token for the terminal and a transmission module for the terminal of a second configuration file access address including the secure token, the generation module and the transmission module being activated if the first verification module determines that the terminal is associated with a user in the database;

Modules, activated upon receipt of a second request from the terminal for obtaining the configuration file comprising the second address, and comprising:

a second verification module, configured to check whether the secure token included in the second address included in the second obtaining request is valid; and

o a module for triggering a provision of the terminal of the activated configuration file if the second verification module determines that the token is valid.

Thus, in accordance with the invention, the terminal attempts a first time to access its configuration file in a conventional manner, by sending a request to the predefined address, "generic" (first address in the sense of the invention) with which it has been previously configured. This first predefined address is for example configured with the MAC (Medium Access Control) address of the terminal, as in the current state of the art.

According to the invention, this first predefined address is closed by default: the management server rejects all access requests to its configuration file formulated by the terminal to this address until it has been declared and associated with a user in the management server database, that is, as long as the management server is not able to ensure the legitimacy of the terminal that sends him a request to obtain a configuration file. As soon as the management server detects that the terminal is assigned to an identified user in its database, it specifically allocates a secure token from which it advantageously generates a second address, this time specific and therefore also secure that the terminal can then use to access its configuration file.

Thanks to the presence of the token in the second address, it is ensured that only the terminal to which the token has been allocated and communicated can access the configuration file, and no other. In the absence of prior knowledge of the second address, it is impossible to access the configuration file of a terminal. Or the second address depends on the secure token that has been generated specifically by the management server for the terminal: the very way it is generated, from a secure parameter kept secret except the terminal concerned and not from a deterministic parameter such as the MAC address of the terminal, is enough to secure access to the configuration file. The invention is therefore very simple to implement.

It should also be noted that the security mechanism proposed by the invention comes in "overlay" of the existing configuration mechanism which consists of the terminal to fetch its configuration file to a predefined address with which it was previously configured. The invention does not require any additional configuration of the terminals. The second address is provided on the fly to the terminal once it has been checked that it was the terminal concerned by the required configuration file. The invention is therefore compatible with any existing industrial solution and does not require any proprietary evolution of the terminals.

In addition, the implementation of the invention is transparent to the users of the terminals.

In a particular embodiment, the secure token is generated for the terminal if the terminal is associated in the database with a parameter allowing access to the configuration file by the terminal.

Obtaining a configuration file is necessary when acquiring a new terminal by a user, but it can also be useful during the lifetime of the terminal (for example after a complete reset). An additional parameter provided in the database and allowing or not access to the configuration file by the terminal can easily handle such a situation.

In addition, the use of such a parameter in the database makes it easy to close the access to the configuration file, for example after a first access to it by the terminal.

As mentioned above, the token generated for a terminal is secure. For this purpose, in a particular embodiment, the token can be unpredictably generated. No limitation is attached to how the token is generated unpredictably. Typically, an Advanced Encryption Standard (AES) symmetric encryption algorithm can be used which, applied to a string containing for example the MAC address of the terminal and a random key, makes it possible to generate a random and unpredictable token. The unpredictability of the token also ensures that the second address generated from the token and allowing the terminal to access its configuration file.

Furthermore, the generated secure token can advantageously be self-contained (or "self-contained" in the sense that it contains various information making it possible to process the request for obtaining the configuration file, for example a reference time, a user ID, etc.

In addition, to enhance the security of the mechanism implemented by the invention, the secure token generated for the terminal may have a predetermined period of validity.

Beyond this period of validity, it is revoked by the management server, so that any terminal using the second address to obtain the configuration file including the presentation of the token that has been allocated sees its request rejected. after the period of validity.

In another embodiment, the method further comprises following the triggering step, a step of rejecting any new request to obtain the received configuration file comprising the secure token.

In other words, the management server is configured to accept only one access request to the configuration file. Any subsequent request is rejected. This further increases the security of the configuration mechanism implemented.

Alternatively, to close any subsequent access to the configuration file, a parameter denying the terminal access to the configuration file can be positioned in the database.

In addition, this embodiment makes it possible to guard against attacks that would consist of repeatedly sending the same request to the second address.

In a particular embodiment, the triggering step comprises a step of sending a message to a reverse proxy server placed between the terminal and the management server, this message comprising an address of a configuration server adapted to generating or hosting the configuration file, this message being able to trigger a redirection by the inverse proxy server of the second obtaining request to the configuration server to make the configuration file available to the terminal.

The reverse proxy server makes it possible to protect the management server and the configuration server, particularly when the terminal uses an unsecured network, such as the public Internet network, to access its configuration file. It is advantageously in a flow cut between the terminal and the management and configuration servers, and intercepts in this respect in particular all requests issued by the terminal. In this embodiment, the inverse proxy server also manages access to the configuration file by interacting on the request. the management server, with the configuration server that hosts the terminal configuration file. This avoids direct access to the management server and the configuration server by the terminal, and this in a manner completely transparent to the terminal.

It should be noted that the use of such a proxy proxy also makes it easy to implement load balancing solutions for the automatic configuration of the terminals: the inverse proxy may, depending on the unavailability of such or such a configuration server, redirect the terminal's request to a more available and less loaded configuration server.

In another embodiment, the triggering step comprises redirecting the second obtaining request to a configuration server adapted to generate or hosting the configuration file to make available to the terminal said configuration file.

In other words, in this alternative embodiment, the redirection of the request to the configuration server is performed directly by the management server of the service, without the intervention of the reverse proxy server.

The security mechanism proposed by the invention is based, as it is clear from the foregoing, on the service management server which implements the control method according to the invention, but also on the terminal and , in some embodiments, on a reverse proxy server located between the terminal and the management server.

According to a second aspect, the invention also relates to a method for obtaining by a terminal a configuration file enabling it to access a service, this method comprising:

At least one step of transmitting a first request for obtaining the configuration file comprising a first access address to the configuration file;

A step of issuing a second request for obtaining the configuration file, triggered following reception in response to the first request for obtaining a second configuration file access address including a secure token generated for the terminal by a service management server, said second obtaining request comprising said second address;

A step of receiving the configuration file from a configuration server able to generate or host the configuration file.

Correlatively, the invention also provides a terminal comprising:

A first transmission module configured to transmit at least a first request for obtaining a configuration file to access a service, said at least one first obtaining request comprising a first access address to the configuration file; ;

A second transmission module, activated on reception in response to the first request for obtaining a second configuration file access address including a token secure generated for the terminal by a service management server, and configured to issue a second request to obtain the configuration file including the second address; and

- A receiving module adapted to receive the configuration file from a configuration server capable of generating or hosting the configuration file.

According to a third aspect, the invention relates to a method of processing requests for obtaining by a terminal of a configuration file to access a service, this method being intended to be implemented by a reverse proxy server placed between the terminal and a service management server, the method comprising:

At least one first step of redirection towards the service management server, of a first request from the terminal for obtaining the configuration file, said first obtaining request comprising a first access address to the configuration file; and

A second step of redirecting a second request from the terminal for obtaining the configuration file, said second obtaining request comprising a second configuration file access address provided by the management server to the terminal by the intermediate of the reverse proxy server and including a secure token generated by the management server for the terminal.

Correlatively, the invention also proposes a reverse proxy server placed between a terminal and a management server of a service, this inverse proxy server comprising:

A first redirection module, configured to redirect to the management server at least a first request from a terminal for obtaining a configuration file intended to enable said terminal to access the service, said at least a first request for access to the service; obtaining comprising a first access address to the configuration file; and a second redirection module, configured to redirect to the management server a second request from the terminal for obtaining the configuration file, said second obtaining request comprising a second configuration file access address provided by the server; management server to the terminal through the reverse proxy server and including a secure token generated by the management server for the terminal.

In other words, the inverse proxy server according to the invention is configured to manage two separate access addresses to the configuration file of the terminal, and redirect the requests relating to these two addresses to the service management server.

In a particular embodiment, the method of processing comprises a third step of redirecting the second obtaining request to a configuration server adapted to generate or hosting the configuration file, said third redirection step being triggered following reception. a message from the management server triggering provision of the terminal of the configuration file and including a configuration server address. This third redirection step is totally transparent for the terminal.

Correlatively, in this embodiment, the server further comprises a third redirection module configured to redirect the second obtaining request to a configuration server adapted to generate or hosting the configuration file, this third redirection module being activated on receiving a message from the management server triggering provision of the terminal of the configuration file and including an address of the configuration server.

The invention also aims at a system for controlling the obtaining of a configuration file by a terminal for accessing a service, said system comprising:

A service management server according to the invention;

An inverse proxy server according to the invention, placed between the terminal and the management server; and

A configuration server capable of generating or hosting the configuration file, and configured to supply the configuration file to the terminal on receipt of a message from the management server or the inverse proxy server.

The terminal, the inverse proxy server, the processing method, the method of obtaining and the system according to the invention have advantages similar to those described above for the control method and the management server according to the invention.

In a particular embodiment, the different steps of the control method, and / or the method of obtaining and / or the processing method are determined by instructions of computer programs.

Accordingly, the invention also relates to a computer program on an information medium, this program being capable of being implemented in a management server or more generally in a computer, this program comprising instructions adapted to the implementing the steps of a control method as described above.

The invention also relates to a computer program on an information medium, this program being capable of being implemented in a terminal or more generally in a computer, this program comprising instructions adapted to the implementation of the steps a method of obtaining as described above.

The invention also relates to a computer program on an information medium, this program being capable of being implemented in a reverse proxy server or more generally in a computer, this program comprising instructions adapted to the implementation steps of a method of treatment as described above.

Each of the aforementioned programs can 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 what other form is desirable. The invention also relates to a computer readable information or recording medium, and comprising instructions of a computer program as mentioned above.

The information or recording medium may be any entity or device capable of storing the program. For example, the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.

On the other hand, the information or recording medium may be 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 program according to the invention can be downloaded in particular on an Internet type network.

Alternatively, the information or recording medium may be 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.

It may also be envisaged, in other embodiments, that the control method, the processing method, the method of obtaining, the management server, the terminal, the inverse proxy server and the system according to the invention in combination all or some of the aforementioned features.

Brief description of the drawings

Other features and advantages of the present invention will emerge from the description given below, with reference to the accompanying drawings which illustrate an embodiment having no limiting character. In the figures:

- Figure 1 shows, in its environment, a control system according to the invention;

FIG. 2 schematically illustrates the hardware architecture of the various elements of the control system represented in FIG. 1; and

FIG. 3 represents, in the form of a flow diagram, the different steps of a control method, a processing method and a method of obtaining according to the invention as they are implemented respectively. by the management server and the inverse proxy server of the control system of FIG. 1, and by the terminal seeking access to its configuration file.

Detailed description of the invention FIG. 1 represents, in its environment, a control system 1 according to the invention, in a particular embodiment.

In this embodiment, the service is a communication service. In the example envisaged in FIG. 1, the control system 1 is adapted to securely frame the automatic configuration of a terminal 2 of a user U, in accordance with the invention, and more particularly to control the obtaining of by this terminal 2 of a configuration file CFG2 allowing it to access a communication service S. The service S is for example here a telephone service or voice over IP provided by a service provider 3.

In a known manner, a configuration file CFG2 making it possible to access such a communication service typically groups together the technical elements enabling the user U to take advantage of the communication service S via his terminal 2, such as in particular a login and a password. pass assigned to the user U to connect to the communication service S, user parameters (eg his address book, the telephone number assigned to him to communicate on the service S, SIP password (Session Initiation Protocol), etc.), as well as technical parameters intended to be implemented by the terminal 2 during a session of the communication service S (eg audio / video codecs, voice over IP parameters, etc.) . It can also contain software or firmwares useful for the benefit of the communication service S. Once the configuration file CFG2 has been obtained by the terminal 2, the terminal 2 applies the technical elements contained in the configuration file CFG2 during its sessions. use of the communication service S.

It is noted that obtaining a configuration file is necessary when a user acquires a new terminal, but it may also be necessary during the lifetime of the terminal (for example after a complete reset of the terminal). this one).

No limitation is attached to the nature of the service S or the nature of the terminal 2. It may be a smartphone-type phone (or "smartphone"), a software application (or "softphone" "), A computer on which is installed such a software application, a digital tablet, etc.

To frame the configuration of the terminal 2 to enable it to access the communication service S, the control system 1 is based, in the embodiment described here, on an architecture comprising various entities, namely:

A management server 4 of the communication service S, in accordance with the invention, and associated with a database 5, comprising activation data of the service S such as, for example, the users of the service, their telephone numbers; and the terminals associated with them (identified for example via their MAC address), etc. ;

A configuration server 6, able to generate or host configuration files enabling terminals and their users to access the communication service S, in particular the terminal 2's CFG2 configuration file; and A reverse proxy server 7 (also commonly called "reverse proxy"), in accordance with the invention, placed in a flow cut between the terminal 2 and the management server 4 on the one hand, and between the terminal 2 and the server configuration 5 on the other hand. In a known manner, a reverse proxy server is conventionally used in computer networks to secure access from outside and in particular from the public Internet network to one or more servers located in an "internal" network. Any message coming from outside and intended for a server of the internal network protected by the inverse proxy server transits through it, which then redirects to the server of the internal network concerned. In this way it is avoided that the internal servers are in direct access from the outside. In the example envisaged in FIG. 1, the inverse proxy server 7 protects access to the management server 4 and the configuration server 6. It intercepts all the requests sent by the terminal 2 to the management server 4 in particular, and redirects them to this one. In addition, in the embodiment described here, the inverse proxy server 7 also acts as an intermediary between the management server 4 and the configuration server 6 as further detailed.

In the embodiment described here, the terminal 2, the management server 4 and the inverse proxy server 7 all have the hardware architecture of a computer 8 as shown schematically and generically in FIG.

The computer 8 comprises in particular a processor 9, a read-only memory 10, a random access memory 11, a non-volatile memory 12 and communication means 13 on one or more communication networks interconnecting the terminal 2, the management server 4 , the configuration server 6 and the inverse proxy server 7. In addition, in the embodiment described here, the terminal 2, the management server 4, the configuration server 6 and the inverse proxy server 7 communicate with each other by using the http protocol or the HTTPS protocol (between the terminal 2 and the inverse proxy server 7), so that the communication means 13 comprise an http and / or HTTPS protocol stack.

As a variant, any other type of protocol making it possible to access a resource identified by an address (such as a URL (Uniform Resource Locator)) or a path or a route pointing to this resource can be used by the terminal 2, the server management 4, the configuration server 6 and the reverse proxy server 7, such as FTP (File Transfer Protocol).

The ROM 10 of the computer 8 constitutes a recording medium or information according to the invention, readable by the processor 9 and on which is recorded a computer program according to the invention, referenced generically in Figure 2 by PROG. This PROG computer program differs depending on the entity in the ROM from which it is stored.

Thus, when the computer 8 is the management server 4, the computer program is a PROG4 program comprising instructions for executing a control method according to the invention of obtaining by the terminal 2 configuration file CFG2 allowing it to access the communication service S. This program PROG4 defines, through its instructions, functional modules of the management server 4 which s' press on and / or control the hardware elements 9-13 of the computer 8 described previously, and which include in particular here as illustrated in FIG.

An application module 4A with a default configuration DEF according to which the management server 4 rejects any request to obtain a configuration file by a received terminal until it is associated with a user in its database 5;

4B-4D modules, activated on receipt of a request for obtaining by a terminal (for example by the terminal 2) of a configuration file allowing access to the service S, this request called "first request of obtaining "comprising a first URL1 access address to the configuration file. These modules are more particularly:

o a first verification module 4B, configured to check if the terminal at the origin of the first request is associated with a user in the database 5; and o a generation module 4C of a secure token (or token) for the terminal (referenced by TOK2 for the terminal 2); and

a 4D transmission module destined for the terminal of a second URL2 access address to the configuration file including the secure token generated for the terminal.

The generation module 4C and the transmission module 4D are activated if the first verification module 4B determines that the terminal is associated with a user in the database 5;

Modules 4E and 4F, activated on receipt of a second request from the terminal for obtaining the configuration file comprising the second URL2. These modules 4E and 4F are more particularly:

a second verification module 4E, configured to check whether the secure token included in the second address included in the second obtaining request is valid; and

a triggering module 4F configured to trigger a provision of the terminal of the configuration file, this 4F module being activated if the second verification module 4E determines that the token is valid.

The modules 4A-4F and their respective functions are described in more detail later with reference to the steps of the control method according to the invention.

When the computer 8 is the terminal 2, the computer program is a program PROG2 comprising instructions for the execution of a method of obtaining according to the invention by the terminal 2 of the configuration file CFG2 allowing it to access to the communication service S. This program PROG2 defines, by means of its instructions, functional modules of the terminal 2 which rely on and / or control the hardware elements 9-13 of the computer 8 described above, and which include in particular here as illustrated in FIG.

A first transmission module 2A configured to transmit at least a first request for obtaining a configuration file to access a communication service, said at least one first obtaining request comprising the first URL access address1 ;

A second transmission module 2B, activated on reception in response to the first request for obtaining the second URL2 access address including the TOK secure token generated for the terminal by the management server 4, the second module of emission 2B being configured to issue a second request to obtain the configuration file including the second address URL2; and

A reception module 2C adapted to receive the configuration file CFG2 from the configuration server 6.

The modules 2A-2C and their respective functions are described in more detail later with reference to the steps of the method of obtaining according to the invention.

Finally, when the computer 8 is the inverse proxy server 7, the computer program is a program PROG7 comprising instructions for the execution of a processing method according to the invention requests to obtain the configuration file CFG2 transmitted by the terminal 2 to be able to access the communication service S. This program PROG7 defines, by means of its instructions, functional modules of the inverse proxy server 7 which rely on and / or control the hardware elements 9-13 of the computer 8 described above, and which include in particular here as illustrated in FIG.

A first redirection module 7A configured to redirect to the management server 4 the obtaining requests (first obtaining requests in the sense of the invention) sent by the terminal 2 and comprising the first access address URL1; and

A second redirection module 7B configured to redirect to the management server 4 the obtaining requests (second obtaining requests in the sense of the invention) sent by the terminal 2 and comprising the second URL2 access address.

In addition, in the embodiment described here, the program PROG7 also defines by means of its instructions a third redirection module 7C configured to redirect a second obtaining request received from the terminal 2 to the configuration server 6 on receipt of the data. a message from the management server 4 triggering a provision of the terminal 2 of the configuration file CFG2.

The modules 7A-7C and their respective functions are described in more detail later with reference to the steps of the treatment method according to the invention.

FIG. 3 represents, in the form of a flow diagram, the main steps implemented, in accordance with the invention, by the terminal 2 and by the control system 1, to secure the automatic configuration of the terminal 2 in order to enable it to access to the communication service S offered by the service provider 3. These steps include the steps of the control method implemented by the management server 4 of the communication service S, the steps of the processing method implemented by the inverse proxy server 7, and the steps of the obtaining method implemented by the terminal 2.

In the embodiment described here, it is assumed that the terminal 2 is delivered to its user U, configured with the first address URL1 (step E00). This first address URL1 is an access address to the configuration file CFG2 of the terminal 2 within the meaning of the invention. It is predefined generically as in the state of the art, that is to say from a "static" reachability address of the configuration server 6 and the MAC address of the terminal 2, noted here. @ MAC2. The first access address URL1 thus makes it possible to access the configuration server 6 which hosts or generates the configuration files making it possible to access the service S, and to identify on this server the configuration file CFG2 which is adapted to the terminal 2 and its user U (typically which is adapted to the capabilities of the terminal 2, the options subscribed if necessary by the user U as part of the service S, etc.).

When the user U starts his terminal 2, the latter is configured to transmit via its first transmission module 2A and its communication means 13, a first request REQ1 for obtaining the configuration file of the terminal 2 on the first predefined address URL1 with which it was configured at the factory (step E10). This REQ1 request is for example a HTTPS request sent on the URL address1 configured with the address of the configuration server 6 and the @ MAC2 address of the terminal 2.

The request REQ1 is intercepted by the inverse proxy server 7, which is configured to redirect, through its first redirection module 4A, the requests comprising the URL1 to the management server 4 (step E20).

As mentioned above, the management server 4 is configured by default with a rule DEF according to which it rejects any request to obtain by a terminal of a received configuration file (a fortiori, a request for obtaining including the first address URL1 ) as long as this terminal is not associated with a user in its database 5. In other words, access to the configuration is closed to the terminals as they are not declared to the database 5. This default configuration DEF is applied by the application module 4A of the management server 4.

Upon receipt of the request REQ1, the management server 4 thus verifies, through its first verification module 4B, whether the terminal 2 at the origin of the request REQ1 is identified in its database 5 and associated with a user (step E30). It uses for this purpose the address @ MAC2 of the terminal 2, present in a standard way in the request REQ1. As a variant, another identifier of the terminal 2 may be used as long as it corresponds to the identifiers used to inform the database 5 or is linked to such an identifier.

In the example envisaged here, it is assumed that the first verification module 4B of the management server 4 can not find the MAC MAC2 address of the terminal 2 in its database 5. In accordance with the DEF rule, the management server 4 rejects the REQ1 request from Terminal 2, by example by sending a Forbidden http 403 response message (step E40). This message passes through the inverse proxy server 7 which relays it to the terminal 2 (step E50).

As a variant, the rejection of the request REQ1 can be done via the sending to the terminal 2 of a predefined configuration file making it possible to display on the terminal 2 a message inviting it to configure its communication service S and to declare its terminal 2 to the service provider 3, via for example an administration portal provided for this purpose.

It is now assumed that the user U connects to such a communication service administration portal S to declare his terminal 2 (step E60): he provides during this declaration a user identifier and an identifier of his terminal 2 , here the MAC @ MAC2 address of the terminal 2. Alternatively, another type of identifier can be envisaged since it allows to identify and recognize the terminal 2 from its requests.

This event triggers an update of the database 5 of the management server 4 (step E70); more precisely, following this declaration, the terminal 2 is associated, via its MAC @ MAC2 address, with the user U who has registered with the service provider 3 to benefit from the communication service S. This update triggers the regeneration of a SIP password for the terminal 2.

In the example envisaged here, following this declaration, the user U is prompted to restart his terminal 2 to begin his configuration in order to access the communication service S.

Following the restart of the terminal 2 (step E80), the terminal 2 sends via its transmitting module 2A and its communication means 13, a new request for obtaining REQ1 'of its configuration file. This configuration request REQ1 'includes the first URL1 address with which the terminal 2 has been configured at the factory (step E90). This request REQ1 'is a first request within the meaning of the invention.

The request REQ1 'is intercepted by the inverse proxy server 7 which, via its redirection module 7A, redirects it to the management server 4 (step E100).

On receiving the request REQ1 ', the management server 4 checks, through its first verification module 4B, if the terminal 2 at the origin of the request REQ1' is identified in its database 5 and associated to a user (step E110). It uses for this purpose the address @ MAC2 of the terminal 2, contained in the request REQ1 '.

Following the declaration made by the user U in step E60, the terminal 2 is registered in the database 5 in association with the user U. The verification module 4B thus determines, during its interrogation of the base 5, the terminal 2 is associated with a user (U) in the database 5 and can be configured.

The management server 4, through its generation module 4C, then generates a TOK2 secure token for the terminal 2 (step E120). Such a token is in the form of a character string having a predefined dimension. This dimension may vary typically between 50 and 300 characters depending on the implementations. However, these values are given for illustrative purposes only and are not limiting in themselves.

To generate the TOK2 secure token, the generation module 4C uses, for example, the AES encryption algorithm, applied to a string of characters consisting of the MAC @ MAC2 address of the terminal 2 and a random event which may include a time stamp ( or "timestamp" in English) to ensure the uniqueness of the generated token and prevent its reuse.

The secure token thus generated is advantageously random and unpredictable. It is dedicated to terminal 2 and only to this terminal. For example :

TOK2 = 'EkRooesmoe56razazeg87ARu ii prea pr'

The management server 4 stores it in its database 5, in association with the identifier @ MAC2 of the terminal 2. In the embodiment described here, it allocates the TOK2 token a limited, predefined validity period (for example 1h). ).

In a variant, the token TOK2 can be stored in another storage space than the database 5 in association with the address @ MAC2 of the terminal 2, for example in the non-volatile memory 12 of the management server 4.

In yet another variant, the management server 4 stores only the hazard that made it possible to generate the token TOK2 in association with the address @ MAC2, the token TOK2 being able to be easily regenerated from this randomness.

Then the generation module 4C of the management server 4 generates from the TOK2 token a second URL2 access to the configuration file of the terminal 2. This URL2 address is here of the following form:

[protocol]: // [Domain] / Ueton TOK2] / [@ MAC2] .cfg

As an illustration, the second address URL2 is for example:

URL2 = https: //configuration.serviceS.com/EkRooesmoe56razazeg87ARuiipreapr/@MAC2.cfg The management server 4, via its 4D transmission module and its communication means 13, sends the second URL2 address thus generated to destination of the terminal 2, in a response message http 200 to its request REQ1 '(step E130). The address URL2 is a second access address to the configuration file of the terminal 2 within the meaning of the invention.

The response message http 200 containing the second URL2 including the token

TOK2 passes through the inverse proxy server 7, which relays it to the terminal 2 (step E140).

The reception of the second URL2 triggers the sending by the terminal 2 via its second transmission module 2B and its communication means 13, a new request to obtain REQ2 of its configuration file, this time including the URL2 and token TOK2 included in this address (step E150). The REQ2 request is for example here a GET request on the URL2 address. The REQ2 request is intercepted by the inverse proxy server 7, which upon detection of the URL2 addresses it via its second redirection module 7A to the management server 4 (step El 60).

On receipt of the REQ2 request, the management server 4, via its second verification module 4E, extracts the TOK2 token from the URL2 address. Then the verification module 4E interrogates the database 5 to check the validity of the TOK2 token, ie if it exists, is well associated with the terminal 2 (that is to say at its MAC @ MAC2 address present in the URL2), and is valid (step E170). It is assumed here that the tokens that are no longer valid are deleted from the database 5.

If the TOK2 token is valid and well associated with the terminal 2 (it is assumed that this is the case here), the management server 4, via its trigger module 4F, triggers the provision of the terminal 2 of its configuration file CFG2 to access the communication service S (step E180).

Otherwise, the obtaining request REQ2 is rejected: the management server 4 for example sends to the terminal 2 a Forbidden HTTP 403 message as described previously in step E40.

In the embodiment described here, the provision of the terminal 2 of its configuration file results in the sending by the management server 4 via its trigger module 4F and its communication means 13, a message http 302 to the inverse proxy server 7. This message requires the redirection of the REQ2 request sent by the terminal 2 to the configuration server 6 so that the terminal 2 can access its configuration file CFG2. It contains, in the "Location" field of its header, a URL6-CFG2 address comprising a static part corresponding to the reachability address denoted URL6 of the configuration server 6, and a dynamic part corresponding to the MAC @ MAC2 address of the terminal 2.

In an alternative embodiment, the provision of the terminal 2 of its configuration file results in the redirection by the management server 4, via its trigger module 4F and its communication means 13, from the REQ2 request to the server configuration 6 so that it makes available to the terminal 2 its CFG2 configuration file.

Therefore, in the embodiment described here, the management server 4 is configured to reject any new receive request received containing the TOK2 secure token allocated to the terminal 2. This step is however optional.

In an alternative embodiment, a parameter indicating whether the obtaining of a configuration file is authorized or not can be recorded in the database 5 in association with the identifier of the terminal 2 and that of the associated user U. This parameter can be typically updated manually via a human-machine interface (HMI). If obtaining the configuration file is not allowed, everything happens as if the terminal was not associated with the user. Reception by the inverse proxy server 7 of the message http 302 containing the URL6-CFG2 triggers the redirection by the third redirection module 7C of the inverse proxy server 7 of the obtaining request REQ2 of the terminal 2 to the configuration server 6 (step 190). More particularly, this redirection is carried out here by sending by the redirection module 7C, to the configuration server 6, the request REQ2 in which the URL2 has been replaced by the URL6-CFG2 (referenced by REQ2 '(URL6-CFG2) in Figure 3) to obtain the CFG2 configuration file.

Upon receipt of the obtaining request REQ2 ', the configuration server 6 dynamically generates, in a manner known per se, the configuration file CFG2 adapted to the terminal 2 and allowing it to access the communication service S (step E200). To generate such a file, the configuration server 6 has, for example templates ("templates") or programs pre-generated and pre-registered for different types of terminals. It uses the model or the program corresponding to the terminal 2, as well as the parameters of the user U and the terminal 2.

As a variant, such a configuration file 2 is generated in advance and hosted by the configuration server 6.

The configuration server 6 supplies the inverse proxy server 7, in response to the request REQ2, the configuration file CFG2 thus generated, for example in an http 200 OK message (step E210).

The inverse proxy server 7 transmits the configuration file CFG2 received from the configuration server 6 to the terminal 2 (step E220).

Upon receipt of the configuration file CFG2 by its reception module 2C and via its communication means 13, the terminal 2 proceeds to its automatic configuration in a manner known per se (step E230). It is now configured to allow its user U to access the communication service S.

In the embodiment described, the service is a communication service.

As an alternative, the service is not a communication service. The service is for example a service in the field of home automation.

For example, the terminal is a connected object able to communicate with a management server.

The connected object is for example a room light or a sensor, for example a temperature sensor.

There is no limit to the nature of the connected object.

The connected object is for example initially configured with a first address allowing access to the management server.

If the connected object is associated with a user in a database accessible by the management server, a secure token is generated for this connected object and a second access address to a configuration file including the secure token is transmitted to the connected object.

With the second address, the connected object can obtain a configuration file.

For example, the configuration file contains user-specific settings. For example, if the connected object is a sensor, the configuration file can have one or more parameters specifying the frequency of the data to be traced back to the server. This data is for example chosen according to the preferences of the user.

Also by way of example, if the connected object is a room light, the configuration file contains parameters specifying the operating rules of the luminaire, for example operating hours chosen by the user.

As an alternative, the configuration file contains coordinates of a mobile phone of the user authorized to communicate with the connected object.

Claims

1. A method of controlling the obtaining by a terminal (2) of a configuration file (CFG2) allowing it to access a service (S), this method being intended to be implemented by a management server (4) of the service and comprising:

An application step (E30, E40) of a default configuration according to which the management server rejects any request to obtain a configuration file by a terminal as long as this terminal is not associated with a user in a database of the management server;

On reception (E20, E100) of a first obtaining request (REQ1, REQ1 ') by a terminal of a configuration file comprising a first access address (URL1) to the configuration file:

o a verification step (E30, E110) if the terminal is associated with a user in the database;

o if the terminal is associated with a user in the database,

^■ a generation step (E120) of a secure token (tok2) to the terminal; and

^■ a transmission step (E130) to the terminal of a second access address (URL2) to the configuration file including the secure token; On reception (E160) of a second obtaining request (REQ2) by the terminal of the configuration file comprising the second address:

o a verification step (E170) if the secure token included in the second address included in the second obtaining request is valid; and

o if the token is valid, a triggering step (E180) of a provision of the terminal of the configuration file.

2. Control method according to claim 1 wherein the service is a communication service. 3. Control method according to claim 1 or 2 wherein the secure token

(TOK2) is generated for the terminal if the terminal is associated in the database with a parameter allowing access to the configuration file by the terminal.

4. Control method according to one of claims 1 to 3 wherein the secure token generated for the terminal has a predetermined period of validity.

5. Control method according to any one of claims 1 to 4 further comprising following the triggering step, a step of rejecting any new request to obtain the received configuration file comprising the secure token. 6. Control method according to any one of claims 1 to 5 wherein the first access address (URL1) is configured with a MAC (Medium Access Control) address of the terminal.

7. Control method according to any one of claims 1 to 6 wherein the triggering step comprises a step of sending (E180) a message to a reverse proxy server placed between the terminal and the management server, said message comprising an address (URL6-CFG2) of a configuration server (6) adapted to generate or hosting the configuration file, this message being able to trigger a redirection by the inverse proxy server of the second request to obtain the configuration server for providing the terminal with said configuration file.

8. Control method according to any one of claims 1 to 7 wherein the triggering step comprises redirecting the second obtaining request to a configuration server adapted to generate or hosting the configuration file to make available of the terminal said configuration file.

9. A method for obtaining by a terminal (2) a configuration file enabling it to access a service, this method comprising:

At least one transmission step (E10, E90) of a first obtaining request (REQ1, REQ1 ') of the configuration file comprising a first access address to the configuration file;

A transmission step (E150) of a second obtaining request (REQ2) of the configuration file, triggered following reception (E140) in response to the first request for obtaining a second access address; (URL2) the configuration file including a secure token generated for the terminal by a management server of the service, said second obtaining request comprising said second address;

A step of receiving (E220) the configuration file from a configuration server (6) able to generate or host the configuration file.

10. Method for processing obtaining requests (REQ1, REQ1 ', REQ2) by a terminal of a configuration file to access a service, this method being intended to be implemented by a reverse proxy server (7) placed between the terminal (2) and a management server (4) of the service, the method comprising: At least a first redirection step (E20, E100) to the service management server, of a first obtaining request (REQ1, REQ1 ') by the terminal of the configuration file, said first obtaining request comprising a first address (URL1) for access to the configuration file; and

A second step of redirection (E160) of a second obtaining request (REQ2) by the terminal of the configuration file, said second obtaining request comprising a second address (URL2) of access to the configuration file provided by the management server to the terminal via the reverse proxy server and including a secure token generated by the management server for the terminal.

11. Processing method according to claim 10 further comprising a third redirection step (E190) of the second obtaining request to a configuration server adapted to generate or hosting the configuration file, said third redirection step being triggered further upon receipt of a message from the management server triggering provision of the terminal of the configuration file and including a configuration server address.

12. A management server (4) for a service, configured to control a terminal obtaining a configuration file enabling it to access the service, the management server comprising:

An application module (4A) of a default configuration according to which the management server rejects any request to obtain a configuration file by a terminal as long as this terminal is not associated with a user in a management server database;

a first verification module (4B) configured to check whether the terminal is associated with a user in the database;

a generation module (4C) for a secure token for the terminal and a transmission module (4D) for the terminal of a second configuration file access address including the secure token, the generation module and the transmission module being activated if the first verification module determines that the terminal is associated with a user in the database;

Modules, activated upon receipt of a second request from the terminal for obtaining the configuration file comprising the second address, and comprising: a second verification module (4E), configured to check whether the secure token included in the second address included in the second obtaining request is valid; and

o a trigger module (4F) of a provision of the terminal of the activated configuration file if the second verification module determines that the token is valid.

Terminal (2) comprising:

A first transmission module (2A) configured to transmit at least a first request for obtaining a configuration file to access a service, said at least one first obtaining request comprising a first access address to configuration file;

A second transmission module (2B), activated on reception in response to the first request for obtaining a second configuration file access address, including a secure token generated for the terminal by a service management server; , and configured to issue a second request to obtain the configuration file including the second address; and

- A receiving module (2C) adapted to receive the configuration file from a configuration server capable of generating or hosting the configuration file.

14. Proxy server (7) placed between a terminal and a management server of a service, this inverse proxy server comprising:

A first redirection module (7A), configured to redirect to the management server at least a first request from a terminal for obtaining a configuration file intended to enable said terminal to access the service, said at least one first obtaining request comprising a first access address to the configuration file; and

A second redirection module (7B), configured to redirect to the management server a second request from the terminal for obtaining the configuration file, said second obtaining request comprising a second access address to the configuration file provided; by the management server to the terminal via the reverse proxy server and including a secure token generated by the management server for the terminal.

15. Proxy server according to claim 14 further comprising a third redirection module (7C) configured to redirect the second obtaining request to a configuration server adapted to generate or hosting the configuration file, said third redirection module being activated. upon receipt of a message from the management server triggering provision of the terminal of the configuration file and including a configuration server address.

16. Control system (1) for obtaining a configuration file by a terminal to access a service, said system comprising:

A management server (4) of the service according to claim 11;

- A proxy server (7) according to claim 13 or claim 14, placed between the terminal and the management server; and

- A configuration server (6) able to generate or hosting the configuration file, and configured to provide the configuration file to the terminal on receipt of a message from the management server or the reverse proxy server.