secure communication between two communication terminals

Abstract

Method for secure communication between first and second communication terminals (T1, T2) via an authentication module of the first terminal with the second terminal and an intermediate terminal (T3), characterized in that the first terminal implements autonomously the following: - receive (E201.A) from the authentication module a command to establish communication with the intermediate terminal, - request (E202) the establishment of communication with the intermediate terminal (T3), - said request being made within a time limit set by the authentication module, receive (E204) an authorization for access to the second terminal from the authentication module, - establish (E205) a communication with the second terminal using the access authorization received. Figure for abstract: Figure 2

Description

Description of the invention: secure communication between two terminals of communication Field of invention This invention relates generally to the field of technologies used to secure digital communications. More specifically, the invention relates to securing communications between two communication terminals, in which: - an identification of the communication terminal which initiates the communication is implemented, and - an intermediate terminal is involved in charge of controlling these communications. Prior art The proliferation of online services likely to host sensitive data reinforces the need to secure access to this data. There are various solutions to resolve this problem, such as, among others, the use of passwords associated with identifiers, so-called two-factor identification (2FA) or even API management techniques ("Application Programming Interface" in English) regulating access authorizations to certain information. However, depending on their level of sophistication, existing solutions tend to present two forms of limitation. The first concerns the vulnerability of communication processes to certain forms of attack (brute force, dictionary, keyboard eavesdropping (keylogger), software (Trojan horse, authorization token interception), network eavesdropping, for example using a password sniffer or via unencrypted network protocols, such as HTTP (Hypertext Transfer Protocol), Telnet (telecommunications network), FTP (File Transfer Protocol), LDAP (Lightweight Directory Access Protocol), etc. The second limitation relates to the operational complexity of the devices for securing these communications. This limitation applies even more to so-called "strong identification" devices and double security devices, in particular those implementing processes deemed to be more robust in terms of security and addressing the first form of limitation mentioned above. Such devices generally implement authentication processes requiring specific actions from users of the terminal initiating the connection / communication request. This may involve biometric data to be communicated, the user's identity to be confirmed via a specific action to be performed on a paired terminal, a password, received by SMS (short message service in English) or generated by a third-party application, to be sent back, etc. The complexity of these authentication processes is problematic in several respects. In the case of techniques based on user biometric data, their implementation involves using specialized terminals capable of capturing such information (facial biometric data, fingerprint, iris, etc.). In the case of software-based techniques for generating one-time or time-limited passwords, this requires prior installation of a specific application and configuration of the application for each service using this form of authentication technique. In many cases, this configuration in turn involves other types of applications, for example, Code OR readers. Finally, all these techniques require specific actions from users initiating communication between two terminals, which tends to make the outcome of the communication security process more uncertain. Examples include cases where the user enters an incorrect code, cases where the user does not enter the temporary code generated by a dedicated application quickly enough, or cases where the user is simply unaware of the actions expected of him. The problem of the operational complexity of secure communication processes is reinforced by that of the digital divide and where the devices incorporating these processes are intended for an increasingly wide public, which does not necessarily master all the elements mobilized by these processes (smartphone, application, web service, password generation application, etc.). Subject matter and summary of the invention One of the aims of the invention is to remedy the drawbacks highlighted by the aforementioned state of the art by enabling a secure connection / communication between two communication terminals and without requiring any action on the part of the user of the terminal initiating the communication request. To this end, an object of the present invention relates to a method of secure communication between first and second communication terminals via an authentication module of the first terminal with the second terminal and an intermediate terminal, characterized in that the first terminal implements autonomously the following: - receive, from the authentication module, a command to establish communication with the intermediate terminal, - request the establishment of communication with the intermediate terminal, - said request being made within a time limit set by the authentication module, receive authorization for access to the second terminal from the authentication module, - establish communication with the second terminal using the access authorization received. A technical advantage of the invention is based on the simplification and autonomy of the method implemented on the side of the first terminal initiating communication with a second terminal. Indeed, the method does not require any particular action on the part of the user of the first terminal. For example, there are no passwords to enter, no biometric data to validate, and no buttons to activate. It is also not necessary to install an additional security device such as one-time password generation software enabling two-factor authentication, nor to instantiate this software by registering the second terminal to which the first terminal wishes to connect. The simplification of the communication security process, its automation, at the level of the first terminal, in the sense that it does not require manual action on the part of the user as required by the security solutions known to those skilled in the art, tends to limit the cases where the process does not succeed due to incorrect human manipulation, such as an error or a lack of responsiveness in entering a code, the lack of mastery of certain technical prerequisites relating to the instantiation of certain two-factor authentication devices, etc. The method de facto involves actions for controlling / validating secure communication between first and second communication terminals via an authentication module of the first terminal with the second terminal and an intermediate terminal. For this purpose, the intermediate terminal implements the following: - receive, from the authentication module, an authorization to accept within a given time, a request to establish a communication from the first terminal, - accept, within the time limit, the said request for the establishment of communication, - send to the authentication module information confirming the request to establish communication, to implement said secure communication. According to a particular embodiment, the secure communication method comprises the following: - the authentication of the first terminal, the reception of the communication establishment command from the authentication module and the establishment of communication between the first terminal and the second terminal are carried out on a first communication network, - the request to establish communication with the intermediate terminal is made on a second communication network separate from the first network. Using a second communication network has the advantage of complicating the process of bypassing the communication security procedure and thus making it more secure. According to another particular embodiment, the secure communication method according to the invention comprises the following: - the second communication network is a voice telecommunications network, which is accessed by the first terminal, said first terminal being associated with a call number, - the first terminal is identified by the intermediate terminal through the call number. Using the voice telephone network makes it possible to strengthen the security of the communication process. The call number, typically the MSISDN number (Mobile Station International Subscriber Directory Number) refers to a unique identifier on the telephone network, for example GSM (Global System for Mobile Communications) UMTS (Universal Mobile Telecommunications System). This number is specific to the calling terminal and is used natively in the communication process. Using this number as the identifier of the first terminal therefore allows the request to establish communication with the intermediate terminal to support the authentication of the first terminal, which limits the amount of information exchanged between the first terminal and the intermediate terminal and therefore results in a simpler and faster secure communication process. According to another particular embodiment of the secure communication method, during the request to establish communication between the first terminal and the intermediate terminal, the first terminal autonomously sends information relating to a unique characteristic specific to it, said unique characteristic being used by the intermediate terminal to confirm the request to establish communication with the authentication module. Using a unique feature specific to the first terminal strengthens greatly the security level of the communication method. By unique characteristic is meant information relating to the processor number of the first terminal, such as for example its ATPO number ("Assembly Test Process Order" in English), the MAC address ("Media Access Control" in English), etc. Said unique characteristic of the first terminal being known to the latter, the sending of this information by the first terminal to the intermediate terminal does not expose the communication method to a risk of handling error on the part of the user of the first terminal. The various embodiments or features mentioned above can be added independently or in combination with each other, to the secure communication method defined above. The invention also relates to a communication terminal adapted to establish secure communication with another communication terminal, by means of a module for authenticating the terminal to the other terminal and to an intermediate terminal, characterized in that the communication terminal is configured to autonomously implement the following: - receive from the authentication module a command to establish communication with the intermediate terminal, - request the establishment of communication with the intermediate terminal, - said request being established within a time limit set by the authentication module, receive authorization to access the other terminal from the authentication module, - establish communication with the other terminal using the access authorization received. Such a terminal is particularly suitable for implementing the secure communication method according to any of the embodiments described previously. The invention also relates to a computer program comprising program code instructions for implementing the secure communication method according to the invention, according to any one of the particular embodiments described previously, when this program is executed by a processor. Such instructions can be stored permanently in a non-transitory memory medium of a communication terminal implementing the secure communication method according to the invention. This program may use any programming language, and may be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form. The invention also relates to a recording medium or information medium readable by a computer, and comprising instructions of a computer program as mentioned above. The recording medium may be any entity or device capable of storing the program. For example, the medium may include a storage medium, such as a ROM (Read Only Memory), for example a CD ROM (Compact Disc Read-Only Memory), a synthetic DNA (deoxyribonucleic acid) or a microelectronic circuit ROM, or a magnetic recording medium, for example a mobile medium, a hard disk or an SSD (Solid State Drive). On the other hand, the 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, so that the computer program it contains is remotely executable. The program according to the invention may in particular be downloaded onto a network, for example an Internet-type network. Alternatively, the 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 aforementioned secure communication method. According to an exemplary embodiment, the present technique is implemented by means of software and / or hardware components. In this regard, the term "module" or "interface" may correspond in this document to a software component, a hardware component or a set of hardware and software components. Brief description of the drawings Other characteristics and advantages will appear on reading particular embodiments of the invention, given as illustrative and non-limiting examples, and the appended drawings, among which: [Fig.1] represents an example of architecture in which the secure communication method is implemented, [Fig.2] represents the main actions implemented in the secure communication process, [Fig.3] represents another example of architecture in which the secure communication method is implemented, [Fig.4] represents the main actions implemented in the secure communication process in accordance with the architecture illustrated in [Fig.3], [Fig.5] represents a secure communication method according to another embodiment of the invention, [Fig.6] represents a secure communication method according to another embodiment of the invention, [Fig.7] shows a communication terminal in one embodiment of the invention, [Fig.8] shows another communication terminal in one embodiment of the invention. Detailed description Description of an example of architecture in which the secure communication method is implemented With reference to [Fig. 1] an example of an architecture in which the secure communication method is implemented is described. According to this architecture, a secure communication system comprises: - a first T1 communication terminal, for example a smartphone, a tablet, a computer, etc., - a second communication terminal T2, for example a personal terminal, a server, a router, a connected disk, a decoder, etc., this terminal comprising on the one hand information accessible in the front part SF (front-end in English) such as textual data accessible without special authorization, menus and interfaces, and on the other hand information accessible under conditions in the back part SA (back-end in English), - a third communication terminal T3, called an intermediate terminal in the remainder of the description, for example a server, a smartphone, a router, - an MA authentication module responsible for authenticating terminal T1 with terminal T2. This MA authentication module can be integrated into terminals T2, T3 or be a separate entity. In this system, secure communication is implemented between terminals T1 and T2, via the intermediate terminal T3 and the authentication module MA. Such secure communication is implemented in a communication network RO such as for example voice, fiber, intranet, internet, etc. Description of the main actions implemented in the secure communication process [Fig.2] represents the main actions implemented in the secure communication process within a system similar to that described in [Fig.1]. Secure communication is initiated by the first terminal T1 in order to connect to the second terminal T2. This request is managed by the MA authentication module interfaced with the second terminal. During a step prior to the secure communication process which will be described below, the first terminal T1 authenticates itself in E200 with the authentication module MA. According to various possible embodiments, this authentication is based on the use of an access token, on the sending of an identifier and password pair or on any other form of authentication known to those skilled in the art. If the first terminal T1 fails to authenticate itself to the authentication module MA, the communication request is not successful. If the first terminal T1 manages to authenticate itself with the authentication module MA, the terminal T1 receives at E201.A, from said module MA, a command to establish communication with the intermediate terminal T3, said command comprising connection information for connecting to the intermediate terminal T3. At the same time, the intermediate terminal T3 receives in E201.B an authorization, originating from the authentication module MA, granting the intermediate terminal T3 the right to accept a communication from the first terminal T1. This authorization is valid for a period defined by the authentication module MA. For this purpose, the intermediate terminal T3 receives, from the authentication module MA, information necessary for the authentication of the first terminal T1. This may be, for example, information specific to the registration of the terminal T1 on a communication network, such as a telephone number, an IP number (“Internet Protocol” in English), etc., a predefined password or any other information specific to the identification of a terminal known to those skilled in the art. Then, the first terminal T1 requests in E202, autonomously, the establishment of a communication or a connection with the intermediate terminal T3. If the intermediate terminal T3 has not received authorization from the authentication module MA to accept the connection / communication request from the first terminal T1 or if the request to establish a connection / communication is made by the first terminal T1 outside the time limit set by the authentication module MA, the request is not successful. Otherwise, the intermediate terminal T3 sends in E203 a confirmation of the communication / connection to the authentication module MA. According to a particular embodiment, the authentication module MA can then terminate the communication between the first terminal T1 and the intermediate terminal T3. According to another embodiment, the communication can be interrupted by the terminal T3. After the authentication module MA has processed the information received by the intermediate terminal concerning the communication from the first terminal to the intermediate terminal, the first terminal T1 receives an authorization in E204, by example a token, to access the second terminal T2. Said processing of information consists of verifying that the information received by the intermediate terminal T3 corresponds to information expected by the authentication module, this information being able to be recorded in the back-end SA of the second terminal T2, for example a connection identifier, a password or any other form of data identifying the first terminal T1. This information may or may not be distinct from that communicated during the request to establish a communication carried out in E202. If the authentication module MA is not informed of the communication established between the first terminal T1 and the intermediate terminal T3 or if the information processed by the intermediate terminal differs from that expected by the authentication module MA, the communication request is not successful. Once the authorization is received in E204, the first terminal T1 establishes in E205, autonomously, a communication to the second terminal T2 using said authorization. Description of another example of architecture in which the secure communication method is implemented [Fig.3] represents a second example of architecture in which the secure communication method is implemented by involving two separate communication networks. In the example shown, a first communication network R1 is used by the first terminal T1 to communicate with the second terminal T2 and with the authentication module MA. A second communication network R2 is used by the first terminal T1 to communicate with the intermediate terminal T3. According to the embodiments, the communications between the authentication module MA and the intermediate terminal T3 take place on the network R1 or R2 Within this system, the first T1 terminal is able to connect to the two separate networks. According to various possible embodiments, the networks used can be voice, fiber, intranet, internet telecommunications networks, etc. Description of the main actions implemented in the communication method in another embodiment [Fig.4] represents the main actions implemented in the secure communication method within a system corresponding to that of [Fig.3], in which the first network RI is an IP network and the second network R2 is a voice communication network. In this embodiment, the intermediate terminal T3 is a voice server configured to receive telephone calls. During a step prior to the secure communication method which will be described below, the first terminal T1 authenticates itself in E400 with the authentication module MA, via the network R1. Such authentication is implemented according to different embodiments corresponding to those already described for the authentication F200. If the first terminal T1 fails to authenticate itself to the authentication module MA, the communication request is not successful. If the first terminal T1 manages to authenticate itself with the authentication module MA, the first terminal T1 receives at E401-A, from said module, via the network R1, a command to establish communication with the intermediate terminal T3, said command comprising connection information for connecting to the voice server T3. Due to the nature of the voice server, the command received by the first terminal may include a telephone number to be used to contact the voice server or any other form of contact information or communication address known to those skilled in the art. At the same time, the voice server T3 receives at E401-B, via the network R1, an authorization, originating from the authentication module MA, granting the intermediate terminal T3 the right to accept a communication from the first terminal T1. This authorization is valid for a period defined by the authentication module MA. The first terminal TI then independently requests in E402 the establishment of communication with the voice server T3, via the network R2, using the telephone number contained in the received command. Such a request also contains a communication identifier associated with the first terminal T1. If the communication identifier associated with the first terminal T1, typically the MSISDN number, matches a number authorized by the authentication module MA and the call occurs within the time limit provided for by the same authorization, then the voice server T3 sends in E403 to the authentication module MA, information confirming the communication request from the first terminal T1. Otherwise, the secure communication process ends. According to other embodiments, different information may be communicated in addition to or instead of the MSISDN number, such as, for example, an https address or an IP address. The use of only the call number and the time concordance between the call and the call authorization offer the particular advantage of limiting the volume of communications mobilized for the authentication of the first terminal T1 by the voice server T3. Furthermore, the sending of the call number of the first terminal T1 on the communication network R2 when requesting to establish a communication with the voice server T3 does not require memorization or entry on the part of the user of the first T1 terminal, this sending being automatic and inherent to the call process. If the authentication module MA validates the information received from the voice server T3, typically if the call number of the first terminal T1 corresponds to that known elsewhere and indicated at the backend of the second terminal T2, at E404, the first terminal T1 receives from the authentication module MA, via the network RI, an authorization to communicate with the second terminal T2. According to various possible embodiments, the authorization, which may take the form of a token or any other form of authorization known to those skilled in the art, is sent to the terminal T1 by the authorization module MA, via the network R1, or directly by the second terminal T2, via the network R2. If the MA authentication module does not validate the information received by the T3 voice server, secure communication between the first and second terminals will not be successful. Once the authorization is received in E404, the first terminal T1 autonomously establishes communication in E405 with the second terminal T2, via the network R2, using the access authorization received. In one embodiment of the invention, following validation or non-validation, by the authentication module MA, of the information received from the voice server T3, the voice server T3 does not respond to the communication request initiated by the terminal T1. The communication between the terminal T1 and the server T3 is therefore not successful. Thus, such a validation procedure remains completely transparent for the user of the terminal T1 and makes it possible to save network resources. Description of a secure communication method according to another embodiment With reference to [Fig.5], an example architecture is described in which the secure and automated communication method is implemented according to another embodiment. In the example shown, the first terminal T1 is a smartphone, the second terminal T2 is an application server, the intermediate terminal T3 is a voice server. As in the example in [Fig.4]: - the first communication network R1 is used: -- by the first terminal T1 to communicate with the second terminal T2 and with the authentication module MA, as well as -- by the authentication module MA to communicate with the intermediate terminal T3; -- the second communication network R2 is used by the first terminal T1 to communicate with the intermediate terminal T3. - The first terminal T1, which initiates secure communication, is here a smartphone comprising: -- a mobile application communicating with the application server T2 in the network R1, via an API gateway (Application Programming Interface) designated PA in [Fig.5]. - The MA authentication module, here a fully-fledged authentication server: -- is connected to the T2 application server, -- has a level 2 authorization identifier, -- controls the T3 voice server, via the R1 network, -- is protected by the PA gateway, -- provides the “classic” Token or JWT (JSON token, JSON Web Token in English) allowing, if necessary, the first terminal T1 to connect to the application server T2, via the R1 network. - The T2 application server receiving the communication initiated by the T1 terminal, via the mobile application: -- allows the mobile application to deliver its service, -- references all MSISDNs that can access the service, -- is protected by the PA gateway. - The T3 voice server: -- receives incoming calls from the first terminal T1, via the R2 network, -- is driven by the MA authentication module. The secure communication method comprises the following steps, implemented according to the IP protocol in the example shown. The mobile application installed on the T1 smartphone uses a level | authorization identifier to generate an access token to connect to the PA gateway in E500.1. This authorization identifier can be obfuscated in the mobile application. An example script of step E500.1 is shown below: curl --location --request POST 'https: / / api.orange.com / oauth / v3 / token"\ --header 'Authorization: Basic Y2dVMUFnpWM21Ec1AOVxcUI4RFVpbzF3RTGHY=="\ --header 'Content-Type: application / x-www-form-urlencoded"\ --data-urlencode 'grant_type=client_credentials' Answer: 200 OK token_type": "Bearer", access_token”: “GZtIviINhZW6HxG]1 KPjiWIhKT3UVW”, expires_in": 600 The string Y2dVMUFnpWM21EclAOVxcUl4RFVpbzF53RTGHY represents the level authorization identifier |. The string GZt1viINhZW6HxG1KPjWthKT3UVW represents the level 1 application token. In this example, "expires_in”: 600, meaning this token has a lifetime of 600 seconds. The application token at level | is used by the PA gateway to request call authorization from the MA authentication module in E500.2 via the R1 network. An example script of this request is: POST / authent / authentRequest. The smartphone T1 receives in E501.A, from the authentication module MA, via the R1 network, a technical number to call, here a URL link ("Uniform Resource Locator" in English) which will allow the mobile application to access a level 2 token. An example of the script for sending this URL link by the T2 authentication server is as follows: curl --location --request POST 'https: / / api.orange.com / authent / authentRequest'\ --header 'Authorization: Bearer GZt1viINhZW6HxGIKPjWthKT3UVW' Answer: 200 OK "serviceNumber": "+339697XXXXX" tokenUrl”: https: / / api.orange.com / authent / GZt1viINhZW6HxG1KPjWihKT3UVW In the message sent to the T1 smartphone: - “serviceNumber” is here the service number that must be called by the mobile application, - "tokenURL" is here the temporary URL that will allow the mobile application to retrieve the level 2 application token. This URL can be identified by the token linked to the level | authorization identifier. At the same time, the MA authentication module checks that the MSISDN of the smartphone T1 is properly provisioned / known on its side, i.e. that it is registered in the application server T2. If the MSISDN is not provisioned in the T2 application server, the authentication request from the T1 smartphone will not succeed and the MA authentication module will respond to the T1 smartphone with an error code, such as example: error 403: forbidden. If the MSISDN is correctly provisioned, the MA authorization module then authorizes in E501.B, the T3 voice server to accept an incoming call from this MSISDN over a short period of time (e.g. 10 seconds). The smartphone T1 requests at E502, via the network R2, to establish a communication, here in the form of a voice call, to the telephone server T3. In this embodiment, the smartphone can use APIs internal to its operating system (OS) capable of automatically triggering voice calls or use features for automatically triggering voice calls directly integrated into the application initiating the secure communication request. The telephone server T3 transmits, in E503, the MSISDN number of the smartphone T1 to the authentication module MA, via the network R1. If the MA authentication module does not recognize the MSISDN, the secure communication process ends. If the MA authentication module recognizes the MSISDN, it triggers a “POST Token” request to the PA gateway with the level 2 authorization identifier, which allows the T1 smartphone to access the T2 application server. An example script of such a trigger is as follows: curl --location --request POST 'https: / api.orange.com / oauth / v3 / token"\ --header 'Authorization: Basic A3ErcnIIYO5ShZUINhZUIR5WFowVjZDZnZmV2alVRbOFKcA=="\ --header 'Content-Type: application / x-www-form-urlencoded"\ --data-urlencode 'grant_type=client_credentials' Answer: 200 OK token_type": "Bearer", 'access_token”: "ZvOW9gx9g WmkKXZ&jmlICnIYYITGd", 'expires_in': 86400 where - A3ErcnI] YO5hZUINhZUIR5WFowVjZDZnZmV2alVRbOFKcA here represents the level 2 authorization identifier corresponding to the SA backend of the T2 application server, - ZVOW9qx98 WmKkKXZ&jmICnIYY1TGd represents the level 2 application token allowing access to the application backend. "expires_in”: 86400 indicates that the application token has a lifetime of 86400 seconds (1 day). An alternative to sending a POST Token is to use a JWT Token, as in the following example: Answer 200 OK: laccess_token": leyJOeXAiOiJKVIQiLCIhbGciOiJFUzM4NCIsImtpZCI6HhjZDIKOGMzLTVjYmYING MzOCIiY2RILTJlYmI2NDY3M:Q0ZSJ9.ey]pYXQ4RTE2NTgONjgyMDAsImV4cCI6M TYIODQ3MDAwMCwianRpljoibmZ4djlUR244am5BTEQyT2VZdUZWUSIsImlzcyl61 m9rYXBpMilsInN] Yil6ImNsaS1hbGlhc251bWJlenMidjEtcHBkliwic2NveGUiOIsiYXB pLXBhemMidjEtbnBkOmFjY2VzcyJdLCJjbGlibnRfaWQiOiJjbGktYWxpYXNudWIizXT 2LXYxLXBwZCJ9.ZLw5bVFTUKCW-nliQUP38 GxJBxZEIPRgIN9OD848NPnmCh&jDz MNCgZC3oBLaCRrto2DCaUOPJ7sM&j19NrJg_1GETMeuxKJD_duBDdYHgomg6-m KkMhZenJiWIlalF4u", token_type": "bearer”, "expires_in": 1800, “scope”: “service access” The decoded JWT Token may contain the following information: HEADER:ALGORITHM & TOKEN TYPE “typ”: “JWT”, "ale": "RS256”, kid”: “8cd9d8c3-Scbf-4c38-bcdc-2ebb6467344e” PAYLOAD:DATA "iat”: 1658468200, "exp": 1658470000, "jti": 'nfxv9TGn&8jnALD20eYuFVQ", "iss”: "okapi2", "sub": "cli-client!-v1-ppd", scope”: [api-parc-v1-npd:access”], "client_id"; “cli-client!-vI-ppd”” "contextlId":"8a1f17b7-964d-4{38-8c5b-dd3704602b27" The smartphone T1 receives at E504 a level 2 token from the authentication module MA, via the network RI. Different embodiments for receiving this level 2 token are possible: either the smartphone T1 sends a GET request containing the URL that was previously received at E501.A, or the application server T2 sends the smartphone T1 a Push OS notification that contains this level 2 token. An example of a script for a GET request to obtain such a level 2 token is as follows: curl --location --request GET 'https: / / api.orange.com / authent / GZtIviINhZW6HxG1KPjWthKT3UVW"\ header 'Authorization: Bearer GZt1viINhZW6HxG1KPjWihKT3UVW' Response: 200 OK "token_type": "Bearer”, “access_token”: “ZvOW9qx9ge WmkKXZ&jmICnIYYITGd”, "expires_in": 86400 The OS push request, for its part, is triggered by the application server T2, via a mobile platform, such as for example Android Firebase or Apple APNs. Once the level 2 token is received, the smartphone T1 establishes in ES05, ​​via the RI network, a communication with the application server T2 using the level 2 token. Description of a secure communication method according to another embodiment of the invention With reference to [Fig. 6], another example of architecture is described, in which the first terminal Tl is identifiable by a unique characteristic CU. This may for example be a unique processor number, a physical MAC (Media Access Control) address or an IMEI (International Mobile Equipment Identity) number or any other form of unique reference identifying the terminal, known to those skilled in the art. As in the previous examples, such an architecture comprises the second terminal T2, the authentication module MA, the front end SF, the back end SA and the intermediate terminal T3. Secure communication is initiated by the first terminal T1 in order to connect to the second terminal T2. This request is managed by the authentication module MA interfaced to the second terminal T2. During a step prior to the secure communication method which will be described below, the first terminal T1 authenticates itself in E600 with the authentication module MA. According to various conceivable embodiments, this authentication is based on the use of an access token, on the sending of an identifier and password pair or on any other form of authentication known to those skilled in the art. If the first terminal T1 fails to authenticate itself to the authentication module MA, the communication request is not successful. If the first terminal T1 manages to authenticate itself with the authentication module MA, the terminal T1 receives at E601.A, from said module MA, a command to establish communication with the intermediate terminal T3, said command comprising connection information for connecting to the intermediate terminal T3. At the same time, the intermediate terminal T3 receives in E601.B an authorization, originating from the authentication module MA, granting the intermediate terminal T3 the right to accept a communication from the first terminal T1. This authorization is valid for a period defined by the authentication module MA. For this purpose, the intermediate terminal T3 receives, from the authentication module MA, information necessary for the authentication of the first terminal T1. This may be, for example, information specific to the registration of the terminal T1 on a communication network, such as a telephone number, an IP number (“Internet Protocol” in English), etc., a predefined password or any other information specific to the identification of a terminal known to those skilled in the art. The first terminal T1 then requests in E602, autonomously, the establishment of a communication with the intermediate terminal T3, during which the terminal T1 sends the unique identifier CU to the terminal T3. If the intermediate terminal T3 has not received authorization for connection / communication with the first terminal T1 from the authentication module MA, or if the connection / communication request from the first terminal T1 is made outside the time limit set by the authentication module MA, the request is not successful. Otherwise, the communication request is successful and to this end, at E603, the terminal T3 sends a confirmation of the communication to the authentication module MA by attaching thereto the information relating to the unique characteristic CU of the first terminal T1. In one embodiment, the authentication module can then terminate the communication between the first terminal T1 and the intermediate terminal T3. After the authentication module MA has processed the information received by the intermediate terminal concerning the communication from the first terminal to the intermediate terminal, the first terminal T1 receives in E604 an authorization, for example a token, to access the second terminal T2. Said processing of information consists of verifying that the information received by the intermediate terminal T3, including the information relating to CU, corresponds to information expected by the authentication module, this information being able to be recorded in the back-end SA of the terminal T2, for example a connection identifier, a password or any other form of data identifying the first terminal T1. If the authentication module MA is not informed of the communication request between the first terminal T1 and the intermediate terminal T3 or if the information processed by the intermediate terminal differs from that expected by the authentication module MA, the communication request is not successful. Once the authorization is received in E604, the first terminal T1 establishes in E605, autonomously, a communication towards the second terminal T2 using said authorization. Description of a communication terminal in one embodiment of the invention [Fig.7] shows the simplified structure of the T1 communication terminal. Such a T1 communication terminal comprises according to the invention: - a COM communication module, suitable for communicating, via the RO, R1 and / or R2 communication network, - a user interface UI configured to receive information from the user UT or to return information to the user in textual, visual and / or audio form: this may be, for example, a display screen, a keyboard and / or a loudspeaker integrated into the communication terminal T1. According to a particular embodiment of the invention, the actions executed by the terminal T1, within the framework of the implementation of the secure communication method of the present invention, are implemented by instructions of a computer program PG,. For this, the terminal T1 has the conventional architecture of a computer and notably comprises a memory MEM,, a processing unit UTR,, equipped for example with a processor PROC, and controlled by the computer program PG, stored in memory MEM,. The computer program PG, comprises instructions for implementing the actions executed by the communication terminal T1, in particular the aforementioned actions: - receive a command to establish communication with the intermediate terminal, - request the establishment of communication with the intermediate terminal, - receive authorization to access the second terminal, - establish communication with the second terminal, when the program is executed by the processor PROC,, according to any of the particular embodiments of the invention which have been described above. According to a particular embodiment of the invention, the communication terminal T1 has a unique characteristic CU, such as a unique identifier specific to the terminal T1 as a whole or to one of the components of the terminal T1, such as the processor PROC, or the communication module COM. Description of another communication terminal in an embodiment of the invention [Fig.8] shows the simplified structure of the T3 communication terminal. Such a T3 communication terminal comprises according to the invention: - a COM communication module; suitable for communicating, via the network of RO, R1 and / or R2 communication. According to a particular embodiment of the invention, the actions executed by the terminal T3, within the framework of the implementation of the secure communication method of the present invention, are implemented by instructions of a computer program PG;. For this, the terminal T3 has the conventional architecture of a computer and comprises in particular a memory MEM,, a processing unit UTR,, equipped for example with a processor PROC, and controlled by the computer program PG; stored in memory MEM,. The computer program PG; comprises instructions for implementing the actions executed by the communication terminal T3, in particular the aforementioned actions: - receive authorization to accept a request to establish communication, - accept the said request to establish communication, - sending to the authentication module information confirming the request to establish communication, when the program is executed by the processor PROC, according to any one of the particular embodiments of the invention which have been described above.

Claims

Claims

1. Method for secure communication between first and second communication terminals (T1, T2) via a module authentication of the first terminal to the second terminal and from an intermediate terminal (T3), characterized in that the first terminal implements in a manner autonomous, the following: - receive (E201.A), from the authentication module, a command to establish communication with the inter- terminal mediator, - request (E202) the establishment of communication with the intermediate terminal (T3), - said request being made within a time limit set by the module authentication, receive (E204) an access authorization to the second terminal from the authentication module, - establish (E205) communication with the second terminal using of the access authorization received.

2. A secure communication method according to claim 1, in which : - authentication of the first terminal, receipt of the order establishing communication and establishing community communication between the first terminal and the second terminal are carried out on a first communication network, - the request to establish communication with the terminal in- intermediate is carried out on a second communication network distinct from the first network.

3. A secure communication method according to claim 2, in which : - the second communication network is a telecommunications network- voice communication, which is accessed by the first terminal, said first terminal being associated with a call number, - the first terminal is identified by the intermediate terminal by the through the call number.

4. A secure communication method according to any one of the claims- indications 1 to 2, in which during the application for establishment of communication with the intermediate terminal, the first terminal sends (E603) autonomously information relating to a character- unique characteristic of its own, said unique characteristic being used by the intermediate terminal to confirm with the module authentication the request to establish the communication.

5. Communication terminal (T1) adapted to establish a commu- secure communication with another communication terminal, by through a terminal authentication module with the other terminal and an intermediate terminal, characterized in that the communication terminal is configured to implement independently the following: - receive a command from the authentication module establishing communication with the intermediate terminal, - request the establishment of communication with the inter- terminal mediator, - said request being established within a time limit set by the module authentication, receive authorization to access the other terminal in origin of the authentication module, - establish communication with the other terminal using access authorization received.

6. Computer program comprising code instructions program for implementing the communication process secured according to any one of claims 1 to 4, when it is run on a computer.

7. Computer-readable information carrier comprising ins- instructions of a computer program for implementing the secure communication method according to any one of the claims- dications | to 4.