FR3119290A1 - METHOD FOR ESTABLISHING A SECURE POST-TO-POST COMMUNICATION CHANNEL, DEDICATED TO A NETWORK APPLICATION, BETWEEN TWO REMOTE NETWORK EQUIPMENTS - Google Patents

Abstract

METHOD FOR ESTABLISHING A SECURE POST-TO-POST COMMUNICATION CHANNEL, DEDICATED TO A NETWORK APPLICATION, BETWEEN TWO REMOTE NETWORK EQUIPMENTS The invention relates to a method for establishing a peer-to-peer link, via a network (IPN), between a client application executed by a first network equipment (UT) and a server application executed by a second network equipment (SRV), the method comprising the steps of: transmitting by the first equipment a connection request ( INV) to a registration server (REGS), intended for the second equipment, the connection request containing connection data from the first equipment to the public network, to receive by the first equipment, from the registration server, a connection response (RINV) originating from the second equipment and containing connection data of the second equipment to the public network, establishing by the first equipment a peer-to-peer link (S29) between the client application and the app ication server, using the connection data of the first and second equipment. Figure for the abstract: Fig. 6

Description

METHOD FOR ESTABLISHING A SECURE POST-TO-POST COMMUNICATION CHANNEL, DEDICATED TO A NETWORK APPLICATION, BETWEEN TWO REMOTE NETWORK EQUIPMENTS

The present invention relates to the establishment of secure connections between equipment connected to the Internet network, the network equipment being able to be protected by firewalls and by network address translations.

To secure communications between remote computers or between two remote local networks, the virtual private network system VPN ("Virtual Private Network") has been developed, which makes it possible to establish a direct channel between remote computers while isolating their exchanges from the rest. traffic carried by public telecommunications networks such as the Internet. The connection between computers is handled transparently by VPN connection management software, creating a tunnel between them. The computers interconnected in VPN are thus on the same (virtual) local network, which makes it possible to bypass any restrictions on the network such as firewalls. Additionally, data transmitted in the VPN channel can be encrypted.

FIG. 1 schematically represents a VPN channel VC10 established between a user terminal UT1 and a server SRV1, via a public network IPN such as the Internet network. The user terminal UT1 is connected to the IPN network via a router or a network gateway GW1. Server SRV1 is also connected to the IPN network through a router or a network gateway GW2. Routers GW1, GW2 may include a firewall. A network interface of the user terminal UT1 can also be equipped with a firewall. VPN connections require opening ports in firewalls. It turns out that keeping ports open constitutes a security flaw that can be exploited to carry out attacks aimed at accessing the content of an SRV1 server or the equipment connected with the SRV1 server in a private local network. The establishment of the channel VC10 with the server SRV1 generally requires the supply by the terminal UT1 of confidential access data (such as an identifier associated with a password). However, there are many types of attacks targeting user terminals to obtain this access data, giving access to the SRV1 server and the private local network of the server. These attacks exploit open ports or programs loaded in user terminals without the knowledge of the users, designed to recover confidential access data to the SRV1 server.

It has also been proposed to use the NAT/PAT ("Network Address Translation/Port Address Translation") port redirection mechanism to redirect a port opened by the gateway GW2, for example, to a local port of a web server hosted by the SRV1 server. This binding also requires keeping a port open, which is also a security hole.

FIG. 2 schematically represents another type of VPN link that can be established between the user terminal UT1 and a server SRV1 (or a local network including the server), via the public network IPN. This other type of link uses a central point CP and a pre-established VPN channel VC2 between the central point and the server SRV1 via the gateway GW2 connected to the Internet network IPN. Here again, the user terminal UT1 is connected to the IPN network via the router or the network gateway GW1. The establishment of a VPN channel VC1 between the user terminal UT1 and the central point CP also requires the opening of a port on the side of the central point CP and the provision by the terminal UT1 of confidential access data.

It is therefore desirable to secure the establishment of a communication channel dedicated to the execution of a network application, such as VPN, between two devices connected to a public network, avoiding having to maintain an open port or to provide confidential data when establishing the communication channel.

Embodiments relate to a method for establishing a secure peer-to-peer communication channel, dedicated to a network application, via a public network, between a first network equipment and a second network equipment, the first and second equipment being connected to the public network, the method comprising steps consisting in: registering the presence on the public network of the first device, with a registration server, the second device being registered with the registration server, transmitting by the first equipment a connection information request to a connection analysis server, and to receive by the first equipment of the connection analysis server public connection data of the first equipment observed from the public network, to transmit by the first equipment a connection request to the recording server, intended for the second device, the connection request containing the public connection data es of the first equipment, receive by the first equipment, from the registration server, a connection response coming from the second equipment and containing public connection data of the second equipment, observed from the public network, and on reception of the connection response , establish by the first equipment a peer-to-peer communication channel with the second equipment via the public network, using the connection data of the first and the second equipment, and connect by the first equipment a client application to the channel Communication.

According to one embodiment, the connection request includes local connection data to a server application to be connected to the client application, to allow the second device to connect the server application to the communication channel.

According to one embodiment, the method comprises steps consisting in: transmitting by the first equipment a new connection request to the registration server, intended for the second equipment, the connection request containing local connection data to a new application server to connect to a new client application, and connecting by the first device the new client application to the communication channel.

Embodiments may also relate to a method of establishing a secure peer-to-peer communication channel, dedicated to an application, via a public network, between a first network equipment and a second network equipment, the first and second equipment being connected to the public network, the method comprising steps consisting in: registering the presence on the public network of the second equipment, with a registration server, the first equipment being registered with the registration server, receiving by the second equipment a connection request from the registration server, sent by the first equipment, the connection request containing public connection data of the first equipment, observed from the public network, sending by the second equipment a request for connection information to a connection analysis server, and receiving by the second equipment of the connection analysis server public connection data of the second equipment, observed from the public network, on receipt of the connection request, send by the second equipment, to the registration server, a connection response intended for the first equipment, containing the public connection data of the second equipment , upon receipt of the connection response, establishing by the second equipment a peer-to-peer communication channel with the first equipment via the public network, using the public connection data of the first and the second equipment, and connecting by the second equipment a server application to the communication channel.

According to one embodiment, the connection request received includes local connection data of the server application, the connection of the server application to the communication channel being performed using the local connection data of the server application .

According to one embodiment, the method comprises steps consisting in: receiving by the second equipment a new connection request, the connection request containing local connection data of a new server application, and connecting by the second equipment the new server application to the communication channel using the new server application's local connection data.

According to one embodiment, the connection data transmitted by the analysis server to the first and second equipment includes connection data relating to several connection points of the first equipment and several connection points of the second equipment, the establishment of the channel peer-to-peer communication between the first and second equipment, comprising steps consisting in executing by the first and second equipment a procedure for selecting connection parameters to test pairs of connection data associating connection data of a access point of the first equipment and connection data of an access point of the second equipment, and select one of the tested pairs having enabled the first and second equipment to communicate, the peer-to-peer communication channel being established based on the selected connection data pair.

According to one embodiment, the connection parameter selection procedure complies with at least one of the following protocols: the ICE protocol, the STUN protocol, and the TURN protocol.

According to one embodiment, the server application is an application for establishing a VPN connection, or an application for controlling network equipment such as a network printer or a router, or an application for accessing a database. data.

According to one embodiment, the data transmissions between the first equipment and/or the second equipment, on the one hand and on the other hand, the recording server are carried out by a secure transmission channel, and/or the transmissions of data between the first equipment and/or the second equipment, on the one hand and on the other hand, the connection analysis server are carried out by a secure transmission channel, and/or the data transmissions between the first equipment and the second equipment, by the peer-to-peer communication channel are carried out by a secure transmission channel.

According to one embodiment, the data transmissions between the first equipment and/or the second equipment, on the one hand and on the other hand, the registration server are carried out: in accordance with the SIP protocol over UDP or over TCP, secured or not by the TLS protocol, or by a VPN channel, or in accordance with the WebSocket protocol, secured or not by a VPN channel, or in accordance with the WebRTC protocol, secured or not by a VPN channel.

According to one embodiment, the registration server and the connection analysis server are implemented in a single server.

Embodiments may also relate to network equipment associated with a circuit for connecting to a public network, the equipment being configured to implement one of the methods as defined previously.

According to one embodiment, the network equipment comprises a router and a firewall, the communication channel being established through the router and the firewall.

According to one embodiment, the network equipment takes the form of a program installed in a user terminal or a server, or takes the form of a circuit that can be connected to a user terminal or to a server.

Examples of embodiments of the invention will be described in the following, on a non-limiting basis in relation to the appended figures, among which:

Figures 1 and 2 described above schematically represent two types of VPN links established between a user terminal and a server,

FIG. 3 schematically represents a communication channel established between a user terminal and a server, according to one embodiment,

FIG. 4 schematically represents different software or hardware blocks that can be requested to establish a communication channel between network applications executed respectively by a client equipment and a server equipment, according to one embodiment,

the figures 5A, 5B represent in more detail different software or hardware blocks that can be requested respectively on the client equipment side and on the server equipment side, to establish a communication channel between remote network applications, according to one embodiment,

FIG. 6 is a schematic timing diagram showing different steps of a method for establishing a communication channel between two network applications executed by remote equipment, according to one embodiment.

FIG. 3 represents a secure peer-to-peer communication channel VC established between a user terminal UT and a server SRV, via a public network IPN such as the Internet network. The user terminal UT is connected to the IPN network via a router or a network gateway GWC. The SRV server is also connected to the IPN network through a router or a GWS network gateway. The gateway GWS and/or GWC and/or the terminal UT and/or the server SRV can comprise a firewall.

The establishment of the communication channel VC involves a registration server REGS and a connection analysis server SISV, accessible by the network IPN. The SISV server is configured to provide connection information (IP addresses - "Internet Protocol"/ports) to the terminal UT and to the server SRV. Once the terminal UT and the server SRV have this connection information, they can securely establish a communication channel that does not require the maintenance of open ports or the transmission in the clear of confidential access data via the IPN network. .

The registration server REGS can be configured to allow the user terminal UT and the server SRV to connect to each other without having to know their reciprocal public connection data. To this end, the REGS server can memorize a table of correspondence between network equipment identification data and previously recorded network equipment public connection parameters.

The establishment of the connection of the terminal UT or of the server SRV to the registration server REGS may involve a secure component, hardware or software, integrated in each of the gateways GWC, GWS, or in the equipment UT, SRV, and storing confidential access data to the REGS server in a secure manner.

FIG. 4 represents different software or hardware modules involved in establishing the secure peer-to-peer communication channel VC between the user terminal UT and the server SRV, according to one embodiment. The user terminal UT and the server SRV respectively comprise a client module ECM and a server module ESM, each including a "user agent" type module ("user agent") UAC, UAS and client application modules MAPC and server MAPS . The UAC, UAS modules each include a VUPC, VUPS communication module configured to manage the VC peer-to-peer communication channel established through the IPN network and allow the MAPC client and MAPS server application modules to use this communication channel . The VC channel can be established on the basis of IP protocols such as UDP ("User Datagram Protocol") or TCP ("Transmission Control Protocol"). The communication modules VUPC, VUPS make it possible to negotiate the establishment of the communication channel VC between the user agents UAC, UAS with the help of the servers REGS and SISV, using for example the protocols SIP ("Session Initiation Protocol"), STUN ("Simple Traversal of UDP through NATs" - "Network Address Translation") and ICE negotiation ("Interactive Connectivity Establishment").

The MAPC, MAPS application modules include, for example, a VPNP module for establishing a VPN channel, or any other UUP client/server application using the VC communication channel and implementing an IP ("Internet Protocol") protocol such as UDP, TCP, IPSec ("Internet Protocol Security"), or GRE ("Generic Routing Encapsulation").

FIGS. 5A, 5B represent the client ECM and server ESM modules in more detail, and in particular the user agents UAC, UAS and the application modules MAPC, MAPS. User agents UAC, UAS respectively include modules VUPS, VUPC, abutment modules PKC, PKS data packet connection and a TIPS module implementing the IP protocol stack. Each of the PKC, PKS modules establishes and manages an internal communication channel to the UAC, UAS agent, with the MAPC, MAPS application modules based on the TIPS module. The PKC, PKS modules can also manage the setting, starting and stopping of the MAPC, MAPS application modules as needed. The UAC and UAS user agents have a link to the outside EL to communicate in particular with the REGS and SISV servers via the VUPC and VUPS modules.

It should be noted that one and/or the other of the application modules MAPC, MAPS can be implemented outside the ECM and ESM modules, for example in a local network connected to the latter.

FIG. 6 represents steps S1 to S34 of an embodiment of a method for establishing a secure peer-to-peer communication channel to connect an APPC client application executed by the terminal UT with a APPS target server application executed by the SRV server.

At step S1, the user agent UAC of the terminal UT is connected to the IPN network, and the communication module VUPC sends a registration request REG to the registration server REGS, through the router GWC / firewall. fire FWC, hardware or software (step S2). At step S3, a response REP to the registration request REG is sent by the server REGS to the module VUPC of the user agent UAC. At step S4, the REP response is retransmitted by the GWC router through the FWC firewall. The REP response provided by the REGS server indicates whether the registration requested by the UAC user agent succeeded or failed.

At steps S5, S6, S7, S8, a procedure identical to that of steps S1 to S4 is initiated by the VUPS communication module of the UAS user agent on the SRV server through the GWS router / FWS firewall.

Steps S1 to S8 can for example be performed in accordance with the SIP and UDP or TCP protocols, as described in the standardization document RFC3261, and more specifically in chapter 10 of this document. The transmission of REG requests and REP responses can be secured using the TLS ("Transport Layer Security") protocol, as described in the standardization document RFC5246 and/or if necessary by passing through an encrypted VPN channel. Other protocols such as WebSocket (RFC7118) and WebRTC ("Web Real-Time Communication") can also be used to perform steps S1 to S8.

At step S9, the VUPC module of the UAC user agent communicates with the SISV server by transmitting a CEQ request to it to determine with which public IP address and by which port, it is connected to the IPN network. The CEQ request contains for example a transaction number. At steps S9, S10, the CEQ request is transmitted to the server SISV through the router GWC/firewall FWC. To this end, the router GWC opens a port and carries out, if necessary, a translation of the NAT address ("Network Address Translation) and/or of the port PAT ("Network Address and Port Translation"). In step S11, the server SISV receives the CEQ request and sends to the VUPC communication module of the UAC user agent a CER response message containing for example the same transaction number in order to allow the VUPC module to establish the link between the CEQ request and the CER response The CER response is received with encapsulated data containing a public Internet Protocol ("IP") address of the requester and a port number opened by the GWC router/firewall to communicate with the SISV server. step S12, the CER response message passes through the FWC firewall through the open port to reach the UAC user agent From step S10, the UAC agent is accessible directly from the public network IPN to the public IP address and port number indicated in the response message CER, for a limited time, typically a few seconds.

At step S13, the communication module VUPC transmits to the server REGS a connection request INV intended for the server SRV. The connection request contains in particular the identifiers of the UAC and UAS agents, as recorded with the REGS server in steps S1 to S4 and S5 to S8. At step S14, the request passes through the GWC router / FWC firewall on the terminal side UT to reach the REGS server. At step S15, the REGS server locates the SRV server using the information contained in the INV request, then transmits the INV request to the SRV server. The routing of the INV request by the REGS server to the SRV server assumes that the two agents UAC and UAS have been previously registered with the REGS server. At step S16, the INV request passes through the GWS router / FWS firewall, SRV server side, to reach the VUPS communication module of the UAS agent.

According to one embodiment, the INV request comprises application data relating to an APPS server application to be executed on the server or in the local network of the server SRV. The application data includes for example a type and identification data of the APPS application, connection data to the server application including a local IP address, a port number and a designation of the communication protocol to be used . Application data may also include additional data such as operating parameters, to be transmitted for the proper functioning of the APPS application. The request INV also includes identifiers of the terminal UT and of the server SRV as recorded by the server REGS.

An example of an INV request is presented in Appendix I. In this example, the INV request corresponds to an “INVITE” message defined and transmitted in accordance with the SIP (“Session Initiation Protocol”) protocol. The body of the message includes data relating to the SDP protocol ("Session Description Protocol").

According to one embodiment, the INV request includes an extension of the SIP and SDP protocols, including the following tags:

- "m=<APP>" used to define the type of target network application APPS ("VPN" in the example in Appendix I) to be run on the SRV server or in the local network of the server,

- "a=<APP>-dst-ip" and "a=<APP>-dst-port" allowing to locate the APPS application in the local environment of the SRV server,

- "a=<APP>-dst-proto" defining an IP network protocol compatible with the server application, such as UDP or TCP.

Other tags could be used to pass parameters to the APPS application, for example such as "a=<APP>-param-1" … "a=<APP>-param-n" (n representing the number of parameters to transmit).

In the example in Appendix I, the INV request is a message comprising a header and a body. The header contains the following data:

- the "INVITE" command associated with an identifier of the intended destination server "<siteXX@REGS>" as recorded by the REGS server, and an identifier of the signaling protocol concerned, namely SIP version 2.0, - a "Via :" again defining the signaling protocol and its version, as well as the "SIP/2.0/UDP" network protocol, the IP address and the local port of the sender of the request “<IP_Local:port>”, a "branch" tag associated with a transaction identifier to be used for each exchange of the transaction,

- "From" and "To:" tags which define the identifiers of the sender and recipient of the request "<Nomade1@REGS>", “<siteXX@REGS>” as recorded by the REGS server, the "from" tag being accompanied by a randomly generated "tag" label for identification purposes,

- a "Call-ID:" tag used to identify the connection,

- a "CSeq:" tag introducing a sequence number associated with the SIP command and incremented with each new command,

- a "Max-Forwards:" tag defining a maximum number of redirections which is decremented with each redirect carried out during the transmission of the INV command,

- a "Date:" tag introducing the date and time the order was sent,

- a "content-type:" tag defining the protocol used in the body of the request, here the SDP protocol, and

- a "content-length" tag defining the length in number of bytes of the body of the request.

The INV message body includes a number of tags defined in accordance with the SDP protocol. These tags are described in more detail in the standardization document RFC4566, and more precisely in chapter 5 of this document. The message body includes the following tags:

- "v=0" indicating a version number of the SDP protocol.

- "o= …." indicating the identifier of the initiator of the transaction ("<Nomade1@REGS>"), as defined during steps S1 to S4, as well as an identifier and a session version number ("1590676221" and "1590676223 "), the type of network to which the sender of the request is connected ("IN" for Internet), the type of address in the network ("IP4" for Internet Protocol v4), and the IP address of the sender ("86.203.229.181"),

- "c=IN IP4 86.203.229.181" again indicating the type of network to which the sender of the request is connected ("IN" for Internet), the type of address in the network ("IP4"), and l 'IP address ("86.203.229.181"),

- "m=<APP> 4003 UDP 0" normally defining a type of media used, but which is here redefined to identify a target server application "<APP>" (identifying the APPS application in the example of figure 6 ), and identify a "UDP" protocol to be used for exchanging data packets with the application, a first public port number likely to be used to establish the communication channel, and a protocol version number " 0" targeted by the request.

The body of the INV request also includes “a=…” tags each including a label associated with parameters, in particular network connection parameters to be used to select with the SRV server the “best” connection. Thus, the "a=…" tags include "ice-ufrag" and "ice-pwd" parameters making it possible to specify a randomly chosen identifier and password used to ensure the integrity of the content of the messages exchanged.

The “a=…” tags also include “candidate” parameters each defining a connection point obtained in steps S9-S12. The "a =candidate" tags have the following syntax:

a=candidate:<foundt> <compID> <transp> <prio> <connect-add> <port> <cand-typ> <rel-add> <rel-port>

in which :

- <foundt> identifies several candidates of the same type, sharing the same database and coming from the same SISV server,

- <compID> identifies a specific component of the data stream to be transmitted by the connection,

- <transp> indicates the protocol to use,

- <prio> indicates a priority number,

- <connect-add> indicates a possible address for accessing the UAC agent,

- <port> indicates a possible port number for accessing the UAC agent

- <cand-type> indicates a type of the connection point, for example "typ host" or "typ srflx" respectively for a point coming from the local machine or from a reflexive server of the STUN type for example,

- <rel-add> and <rel-port> indicate addresses and ports of the connection point, useful in particular for diagnostic purposes.

The network connection data received at step S12 is used to specify the INV request and in particular the "a=candidate" tags. The first "a=candidate" tag presented in Appendix I contains the public IP addresses / ports opened in the FWC firewall at step S10.

Following receipt of the INV request in step S16, the VUPS module of the UAS agent sends to the PKS abutment module a request with information making it possible to identify, locate and configure the targeted APPS application. In response to this request, the PKS abutment module transmits an acceptance or refusal status code, possibly accompanied by parameters specific to the APPS application. The VUPS module of the UAS agent communicates (steps S17 to S20) with the SISV server by transmitting a CEQ request to it to determine with which public IP address and which port it communicates with the SISV server. Thus at steps S17 to S20, identical to steps S9 to S12, but carried out between the servers SISV and SRV, a CEQ request is sent by the UAS agent to the server SISV through the router GWS / firewall FWS. At step S19, the SISV server issues a CER response which passes through the GWS router / FWS firewall at step S20. From step S18, the UAS agent is accessible directly from the public network IPN at the public IP address and on the public port number indicated in the response message CER. The response message CER received by the server SRV at step S20 contains the connection information to the IPN network relating to the UAS agent, provided by the server SISV.

According to one embodiment, the communications carried out in steps S9 to S12 and S17 to S20 are carried out in a secure channel, for example in accordance with the TLS protocol.

The following steps S21 to S24 comprise the transmission of a response message RINV to the request INV, from the server SRV to the terminal UT via the server REGS. The RINV response message contains substantially the same structure and type of information as the INV request message. However, the response message contains the information relating to the server SRV and in particular that transmitted by the server SISV in the message CER at step S20, and possibly the information relating to the targeted application APPS provided by the abutment module PKS . The RINV response message further contains a status code which may indicate connection accepted, connection accepted to another address specified in the RINV response message, or connection denied due to the occurrence of an error. The status code can be the one defined in the RFC3261 specifications, section 13.2.2. In steps S22, S23, the response message RINV is relayed by the server REGS to the terminal UT using the information contained in the request RINV. For example, in the case where the REGS server is a registrar server conforming to the SIP protocol, it uses the information contained in the SIP header of the RINV message to define where to forward the message. The VUPC module can then transmit to the PKC abutment module the parameter information provided by the PKS module. The PKC module returns to the VUPC module an acceptance or failure status code.

At step S24, if the status codes provided in the response message RINV and by the PKC module specify acceptance of the connection, the VUPC module of the UAC agent transmits at step S25 to the REGS server, at destination of the server SRV an acknowledgment message ACK. At step S26, the ACK message passes through the GWC router / FWC firewall and is received by the REGS server. At steps S27, S28, the ACK message is routed from the REGS server to the SRV server, through the GWS router/firewall, using the connection information contained in the header of the ACK response message.

The INV, RINV and ACK messages transmitted in steps S13 to S16, S21 to S24 and S25 to S28 may be those specified by the SIP protocol and described in more detail in chapter 13 of the standardization document RFC3261.

According to one embodiment, the transmissions of the messages INV, RINV and ACK in steps S13 to S16, S21 to S24 and S25 to S28 are carried out in a secure channel, for example in accordance with the TLS protocol.

Upon receipt of the RINV and ACK messages, the modules VUPC, VUPS of the UAC and UAS agents execute in step S29 a connection data selection procedure. This procedure aims to test the peer-to-peer connection paths based on the connection data (IP addresses/ports) provided by the SISV server and inserted in the INV and RINV messages. To this end, the VUPC, VUPS modules of the UAC, UAS agents use, for example, the connection points specified by the “a=candidate” tags in the INV request and the RINV response. These connection points are used by UAC, UAS agents by forming pairs of sender and receiver connection points. Each pair is then tested by the UAC, UAS agents. For this, the VUPC module transmits a test request through the connection point of the GWS router / FWS firewall, on the SRV side, to reach the VUPS module. The VUPS module responds by transmitting a test request through the connection point of the GWC router / FWC firewall, terminal side UT to reach the VUPC module. The pair finally retained by the VUPC, VUPS modules then forms a connection path which may be the one which has been the most efficient in terms of latency. This procedure is for example carried out in accordance with the ICE protocol described in the RFC8445 document, in particular in chapter 6. At the end of this procedure, each of the UAC agents, UAS has a destination IP address/port to be used to transmit data to the other agent. Thus, the UAC, UAS agents are connected to each other by a peer-to-peer communication channel, and can exchange any data in accordance with the selected IP protocol (for example UDP ). The public IP addresses/ports thus defined for accessing the terminal UT and the server SRV may be different from those opened in steps S10 and S18.

The peer-to-peer communication channel can be used by the terminal UT to connect any APPS server application among the MAPS application modules on the server SRV, to an APPC client application among the MAPC application modules on the terminal UT ( step S32). However, the PKC, PKS abutment modules limit the use of this connection to the <APP> application specified by the "m=" and "a=<APP>…" tags. To achieve this connection, a communication tunnel is established on the side of the terminal UT in step S30 by providing an entry point for the client application APPC and connecting to the peer-to-peer link VC. At step S31, a communication tunnel is also established on the side of the server SRV by connecting to the peer-to-peer link VC and waiting for data from the UAC arriving from the tunnel VC. At step S32, the APPC client application is configured and activated by the PKC module, and begins to send data. This data is transmitted through the VC tunnel in step S33. Upon receipt of these, in step S34, the APPS server application is then configured and started by the PKS module. Therefore, the APPC and APPS applications are interconnected and can communicate freely via the communication channel VC (S33).

The APPC client and APPS server applications can for example allow the establishment of a VPN channel between the terminal UT and the server SRV to give the terminal access to resources of the server or of the local network to which the server is connected. The APPS server application can be, for example, a Web server for controlling network equipment such as a network printer or a router connected to the local network of the SRV server, or even a specific application installed on the server. In this case, the APPC client application may for example be an Internet browser equipped with a specific extension to communicate through the communication tunnel VC thus established.

It should be noted that, by this method, it is possible to communicate a network application through protected network equipment (not accessible from the public network because protected by a router and a firewall). However, the network applications likely to use the communication channel VC are strictly limited to those defined in the command INV transmitted at steps S13 to S16.

According to one embodiment, it is possible to use the communication channel VC previously established for a network application, to make other APPC/APPC network applications communicate. To this end, the communication modules VUPC, VUPS of the agents UAC, UAS can once again execute steps S13 to S16, S21 to S28 and S30 to S34. In steps S13 to S16, a new request INV is sent to the server SRV. This new INV request contains all the parameterization and identification information of the target APPS server application. The VUPS module is thus informed of the new server application to be activated. Since the communication tunnel is already established (S29), the information necessary for establishing the latter is not useful in the request INV. According to one embodiment, the PKC, PKS modules are capable of executing several applications by using, for example, a data multiplexing method allowing identification of data packets. According to another embodiment, the PKC, PKS modules can stop the execution of a network application, to replace it with a new one, when sending or receiving an activation request from another application. .

When the user closes the APPC or APPS application, the UAC or UAS agent transmits to the other agent (UAS or UAC) a closing message, for example a BYE message according to the SIP protocol and the other agent responds by sending a closing confirmation message. The PKC and PKS abutment modules activated by the UAC and UAS agents are then closed, which causes the closure of the VC channel. If several applications are running, a closure notification message is sent each time the application is closed, for example a NOTIFY or UPDATE message according to the SIP protocol. If the last active network application is closed, the VC channel is closed, as well as the butting modules PKC, PKS.

Thus, the method which has just been described makes it possible to put network applications executed by network equipment protected by a router and a firewall into communication, without having to keep open ports that are freely accessible from the public network.

In accordance with security mechanisms implemented in current firewalls, the ports opened at steps S10, S18 and possibly S29 remain open for a very short period of a few tens of seconds. A potential hacker therefore does not have time to examine all the ports likely to be used to penetrate the local networks of the UT terminal or the SRV server. At the end of this period, if the port is still in use, it remains open but only for the sending IP address of the last data packet received. Thus, at step S33, the ports selected at step S29 remain open only for data packets originating from the public IP addresses selected at step S29. These ports can be kept open for a long time by an autonomous mechanism (ICE protocol "keep-alive" mechanism for example), as long as the VUPC and VUPS modules are running. These ports cannot therefore be used to penetrate the local networks of the terminal UT and of the server SRV.

It will clearly appear to those skilled in the art that the present invention is capable of various variant embodiments and various applications. In particular, it may not be necessary to execute the connection data selection procedure at step S29, knowing that steps S9-S12 and S17-S20 make it possible to obtain at least one public IP address and one port connection for the terminal UT and the server SRV.

PKC, PKC butting modules can be dedicated to a network application. In this case, they do not need credentials and local connection data to determine how to connect the client and server applications at each end of the communication channel.

Furthermore, all the steps of FIG. 6 executed by the UAC agent or by the UAS agent can be implemented in specific network equipment distinct from the terminal UT or from the server SRV. These steps can also be partly or totally implemented by a program installed in the terminal UT and/or the server SRV.

The protocols mentioned previously, likely to be used in the context of the execution of the steps of f igure 6, have the advantage of being standardized protocols and implemented in available modules, which makes it possible to facilitate the realization and the interoperability of UAC and UAS agents, as well as REGS and SISV servers. However, it goes without saying that it is not necessary to implement these protocols to carry out the steps of f igure 6, and that specific protocols can be developed for this purpose, the functions provided by the REGS servers and SISV that can be adapted to these specific or dedicated protocols. The development of such protocols can indeed make it possible to lighten the treatments to be carried out and to adapt them more specifically to the required needs. In particular, protocols other than UDP and TCP can be used for the transport layer of the OSI ("Open Systems Interconnection") model, such as SCTP ("Stream Control Transmission Protocol").

Furthermore, the REGS and SISV servers have been described as separate equipment. It also goes without saying that the functions performed by these two servers and implemented in the steps of FIG. 6 can be performed by a single physical server or a server accessible at a single public IP address.

It also goes without saying that the terminal UT can also be a server connected to a local network and that the APPC/APPS application executed in steps S32-S34 can make it possible, for example, to establish a VPN link between this local network and the network local connected to the SRV server. The SRV server can also be a simple user terminal. In this case, the APPC/APPS application can be used, for example, to establish a VPN link between two remote terminals. Thus, the expression "network equipment" as used in the appended claims therefore designates either a user terminal, a server or a local network.

Annex I

Sample INV Query (Step S13)

INVITE sip:<siteXX@IREGS> SIP/2.0

Via: SIP/2.0/UDP <IP_Local:port>;branch=z9hG4bKnashds8

To: SiteXX <siteXX@REGS>

From: Nomad1 <Nomade1@REGS>;tag=1928301774

Call ID: a84b4c76e66710

CSeq: 314159 PROMPT

Max Forwards: 70

Date: Thu, 21 Feb 2020 13:02:03 GMT

Contact: sip:<Nomade1@IP_Local:port>

Content-Type: application/sdp

Content Length: 105

v=0

o=<Nomade1@REGS> 1590676221 1590676223 IN IP4 82.203.229.181

c=IN IP4 86.203.229.181

m=<APP> 4003 UDP 0

a=<APP>-dst-IP:192.168.100.20

a=<APP>-dst-port:4242

a=<APP>-dst-proto:TCP

a=ice-ufrag:6abdfa9b

a=ice-pwd:7792893930440d10070f2f6e

a=candidate:Sc0a8006a 1 UDP 1862270975 86.203.229.181 4003 typ srflx raddr 192.168.0.106 report 4003

a=candidate:Hc0a8006a 1 UDP 1694498815 192.168.0.106 4003 typhost

a=candidate:Hc0a86302 1 UDP 1694498815 192.168.99.2 4003 type host

a=candidate:Hac107201 1 UDP 1694498815 172.16.114.1 4003 typhost

a=candidate:Hac101001 1 UDP 1694498815 172.16.16.1 4003 typhost

a=candidate:Sc0a8006a 2 UDP 1862270974 86.203.229.181 4026 typ srflx raddr 192.168.0.106 report 4026

a=candidate:Hc0a8006a 2 UDP 1694498814 192.168.0.106 4026 typ host

a=candidate:Hc0a86302 2 UDP 1694498814 192.168.99.2 4026 typ host

a=candidate:Hac107201 2 UDP 1694498814 172.16.114.1 4026 typhost

a=candidate:Hac101001 2 UDP 1694498814 172.16.16.1 4026 typ host

Claims (15)

Method for establishing a secure peer-to-peer communication channel, dedicated to a network application, via a public network (IPN), between a first network device (UT) and a second network device (SRV), the first and second equipment being connected to the public network, the method comprising steps consisting in:
register the presence on the public network of the first device, with a registration server (REGS), the second device being registered with the registration server,
send by the first device a connection information request (CEQ) to a connection analysis server (SISV), and receive by the first device from the connection analysis server public connection data (CER) from the first equipment observed from the public network,
transmit by the first equipment a connection request (INV) to the registration server, intended for the second equipment, the connection request containing the public connection data of the first equipment,
receive by the first equipment, from the registration server, a connection response (RINV) originating from the second equipment and containing public connection data (CER) of the second equipment, observed from the public network, and
upon receipt of the connection response, establish by the first equipment a peer-to-peer (VC) communication channel with the second equipment via the public network, using the connection data of the first and of the second equipment, and connecting by the first device a client application (APPC) to the communication channel. Method according to claim 1, in which the connection request (INV) comprises local connection data to a server application (APPS) to be connected to the client application (APPC), to allow the second equipment (SRV) to connect the server application to the communication channel (VC). A method according to claim 2, comprising the steps of:
transmit by the first equipment (UT) a new connection request (INV) to the registration server (REGS), intended for the second equipment (SRV), the connection request containing local connection data to a new server application ( APPS) to connect to a new client application (APPC), and
connecting by the first device the new client application (APPC) to the communication channel. Method for establishing a secure peer-to-peer communication channel, dedicated to an application, via a public network (IPN), between a first network equipment (UT) and a second network equipment (SRV), the first and second equipment being connected to the public network, the method comprising steps consisting in:
register the presence on the public network of the second device, with a registration server (REGS), the first device being registered with the registration server,
receive by the second equipment a connection request (INV) from the registration server, sent by the first equipment, the connection request containing public connection data of the first equipment, observed from the public network,
send by the second equipment a connection information request (CEQ) to a connection analysis server (SISV), and receive by the second equipment from the connection analysis server public connection data (CER) of the second equipment, observed from the public network,
on receipt of the connection request, send by the second equipment, to the registration server, a connection response (RINV) intended for the first equipment, containing the public connection data of the second equipment,
upon receipt of the connection response, establish by the second equipment a peer-to-peer (VC) communication channel with the first equipment via the public network, using the public connection data of the first and of the second equipment, And
connecting by the second device a server application (APPS) to the communication channel (VC). Method according to claim 4, in which the connection request (INV) received comprises local connection data of the server application (APPS), the connection of the server application to the communication channel (VC) being carried out at the using the server application's local login data. A method according to claim 5, comprising the steps of:
receive by the second equipment (SRV) a new connection request (INV), the connection request containing local connection data of a new server application (APPS), and
connecting by the second device the new server application to the communication channel (VC) using the local connection data of the new server application. Method according to one of Claims 1 to 6, in which the connection data transmitted by the analysis server (SISV) to the first and second equipment (UT, SRV) comprise connection data relating to several connection points of the first equipment and several connection points of the second equipment, the establishment of the peer-to-peer (VC) communication channel between the first and second equipment, comprising steps consisting in executing by the first and second equipment a parameter selection procedure of connection to test pairs of connection data associating connection data of an access point of the first equipment and connection data of an access point of the second equipment, and to select one of the pairs tested having enabled the first and second equipment to communicate, the peer-to-peer communication channel being established based on the selected connection data pair. Method according to claim 6 or 7, in which the connection parameter selection procedure (S29) complies with at least one of the following protocols:
the ICE protocol,
the STUN protocol, and
the TURN protocol. Method according to claim 8, in which the server application (APPS) is an application for establishing a VPN connection, or an application for controlling network equipment such as a network printer or a router, or an application for access to a database. Process according to one of Claims 1 to 9, in which:
the data transmissions between the first equipment (UT) and/or the second equipment (SRV), on the one hand and on the other hand, the registration server (REGS) are carried out by a secure transmission channel, and/ Or
the data transmissions between the first equipment and/or the second equipment, on the one hand and on the other hand, the connection analysis server (SISV) are carried out by a secure transmission channel, and/or
the data transmissions between the first device and the second device, via the peer-to-peer (VC) communication channel, are carried out by a secure transmission channel. Method according to one of Claims 1 to 10, in which the data transmissions between the first equipment (UT) and/or the second equipment (SRV), on the one hand, and on the other hand, the recording server ( REGS) are performed:
in accordance with the SIP protocol over UDP or over TCP, whether or not secured by the TLS protocol, or by a VPN channel, or else
in accordance with the WebSocket protocol secured or not by a VPN channel, or else
in accordance with the WebRTC protocol secured or not by a VPN channel. Method according to one of Claims 1 to 11, in which the registration server (REGS) and the connection analysis server (SISV) are implemented in a single server. Network equipment (UT, SRV) associated with a circuit for connecting to a public network (IPN), the equipment being configured to implement the method according to one of Claims 1 to 12. Network equipment according to claim 13, comprising a router (GWC, GWS) and a firewall (FWC, FWS), the communication channel (VC) being established through the router and the firewall. Network equipment according to claim 13 or 14, wherein the network equipment is in the form of a program installed in a user terminal (UT) or a server (SRV), or is in the form of a circuit connectable to a user terminal or to a server.