Method of maintaining a secure channel between a client and a server through a wireless network; Associated computer program product.

Abstract

Method of maintaining a secure channel between a client and a server across a wireless network; Associated computer program product.A method of maintaining a secure channel between a client (10) and a server (40) across a wireless network, the method comprising the steps of, a secret being shared between the client and the server: while the client is in "sleep" mode and data is to be transmitted from the client to the server, waking up the client and initiating, by the client, a procedure for reestablishing the secure channel by transmitting to the server a state change message of the "wake-up" type protected using said secret; and while the client is in "sleep" mode and data is to be transmitted from the server to the client, waking up the client by the server by means of transmitting a paging message and initiating by the client the procedure for reestablishing the secure channel by transmitting to the server a state change message of the "wake-up" type protected using said secret. Figure for abstract: Figure 1.

Description

Title of the invention: Method for maintaining a secure channel between a client and a server through a wireless network; Associated computer program product.

[0001] The present invention relates to a method for maintaining a secure channel between a mobile client and a server, through a wireless network.

[0002] A Virtual Private Network - VPN is the establishment of a secure IP tunnel, or VPN tunnel, for the exchange of data between two actors constituting the endpoints of this secure channel.

[0003] A VPN can be used between two actors, one of which (referred to as the client in the following) is mobile. This can be a mobile phone connected to a cellular (4G or other) or satellite network, a tablet connected to a Wi-Fi network, etc., or, generally speaking, any object connected via an air link to a radiocommunication network.

[0004] The mobile use of a VPN means that the context (i.e. the VPN tunnel configuration information) of the VPN tunnel endpoints (that of the VPN client application executed by the client and that of the VPN server application executed by the VPN server) must be updated according to the evolution of certain operating parameters of the client during its movement, in particular the IP address of the client which may be changed when the client attaches to a new base station of the radio communication network. It should be noted that the IP address does not necessarily change, and that this depends on the configuration of the operator network and the proximity of the base stations between which the user equipment passes.

[0005] Despite these context changes, we would like not to lose the current VPN session.

[0006] Otherwise, the VPN tunnel would have to be reset each time the context changed. This would then require repeating the authentication procedures (by username and password) for application sessions passing over the VPN channel between an application running on the client and a service server.

[0007] This is not feasible, for example, when the client is used on board a train and is likely to change its IP address frequently.

[0008] The use of a VPN across wireless networks therefore requires the implementation of persistence mechanisms in order to ensure continuity of services between a VPN client and the VPN server - also called a VPN gateway - establishing the virtual private network.

[0009] These mechanisms must guarantee continuity of service in both directions, i.e. for outgoing traffic and incoming traffic (in relation to the customer), while maintaining mobility functionalities (roaming between cells of the same network ("handover") or cells of different networks ("roaming") in the case of cellular networks).

[0010] In particular, the mechanisms provided by various "requests for comments" recommendations - RFCs ("Requests for comments") from the IETF ("Internet Engineering Task Force") consist of exchanging a heartbeat signal between the VPN client application and the VPN server application, in order to guarantee and confirm the integrity of the virtual channel - or VPN tunnel - set up between the client and the VPN server and to make it possible to respond to issues related to the mobility of the client running the embedded VPN client application.

[0011] Receiving the live signal from one VPN tunnel termination point to the other VPN tunnel termination point allows the VPN tunnel to always be kept "on" or "open". Thus, the exchange of signaling data along the VPN tunnel allows the desired continuity of service to be guaranteed.

[0012] Notably, while the client is placed in "sleep" mode, also called "idle mode", the VPN client application always keeps the VPN tunnel open.

[0013] But this implies maintaining signaling data communication on the air interface, even if no application data is circulating.

[0014] The client therefore generates constant noise on the user plane. It is not silent, even when it is in "sleep" mode and does not transfer any application data.

[0015] In addition, this requires constant use of the client's means of communication and, consequently, significant energy consumption, even when the client is in "sleep" mode. The client's batteries are therefore quickly exhausted.

[0016] The aim of the invention is thus to propose a method for maintaining a VPN tunnel by offering secure mechanisms making it possible to ensure the continuity of service associated with the use of a VPN tunnel in mobility, without having to exchange service messages to keep the VPN tunnel "open" while the client is in "sleep" mode.

[0017] To this end, the invention relates to a method for maintaining a secure channel between a client and a server through a wireless network, the method comprising the steps of, a secret being shared between the client and the server: while the client is in "sleep" mode and data must be transmitted from the client to the server, waking up the client and launching, by the client, a procedure for reestablishing the secure channel by transmitting to the server a state change message of the "wake-up" type protected using said secret; and while the client is in "sleep" mode and data must be transmitted from the server to the client, wake-up of the client by the server by means of the transmission of a paging message and initiation by the client of the procedure for reestablishing the secure channel by transmitting to the server a state change message of the "wake-up" type protected using said secret.

[0018] According to other advantageous aspects of the invention, the method comprises one or more of the following characteristics, taken in isolation or in all technically possible combinations:

[0019] - the method further comprises a step of exchanging the secret consisting, in “ connected" and while the secure channel is established, to calculate, as a secret, a reference key by an agent among the client and the server, and to transmit, via the secure channel, the secure key to the other agent.

[0020] - the reference key Kref is generated from an identifier of the current session between the client and the server along the secure channel.

[0021] - an AES 256 type algorithm is executed to calculate the reference key.

[0022] - the server maintaining a server context of the secure channel and the client maintaining updating a client context of the secure channel, the procedure for reestablishing the secure channel consists of: adapting, by the client, the client context with a plurality of modified information comprising at least one current IP address of the client; transmitting, by the client to the server, the plurality of modified information in the state change message of the “wake-up” type; and, adapting, by the server, the server context associated with the reference key, according to the plurality of information received.

[0023] - the secure channel is a VPN channel, the client running a VPN client application and the server running a VPN server application.

[0024] - a state change message of the “standby” type is transmitted by the client to the server, said sleep message being protected by the secret shared between the client and the server.

[0025] - a state change message contains: the client identifier, a counter anti-replay, the type of the state change message "sleep" or "wake up", and all or part of the client context updated for a state change message of the type "wake up".

[0026] - while client and / or server contexts have not been saved before a switching the client to "sleep" mode, following the transmission to the server of a "wake-up" type state change message, the client initiates a key negotiation to establish the secure channel.

[0027] The invention also relates to a computer program comprising software instructions which, when executed by a customer's computer or of a server communicating via a secure channel through a wireless network, implement a method in accordance with the preceding method.

[0028] The invention will appear more clearly on reading the description which follows, given solely by way of non-limiting example, and made with reference to the drawings in which:

[0029] [Fig-1] [Fig.l] is a schematic representation of an infrastructure with using a VPN; and,

[0030] [Fig.2] [Fig.2] is a schematic representation of the method according to the invention.

[0031] Generally speaking, the VPN tunnel wake-up mechanism of the method according to the invention is based on the sharing, between the VPN client application and the VPN server application, of a reference key, exchanged while the VPN channel is "open". This reference key makes it possible to validate a future request for data exchange between the two actors via the VPN channel, while the latter is "closed".

[0032] A VPN channel is said to be "open" when each correspondent has the VPN keys and the context parameters of this VPN channel. Therefore, closing a VPN channel means no longer being able to decrypt the streams transmitted in this VPN channel, i.e. no longer having either the VPN keys or the context information (or both).

[0033] To reestablish communication, the invention makes it possible to switch from the “closed” state to the “open” state securely, in particular by validating that there is no man-in-the-middle attack capable of using captured context information to reestablish the channel.

[0034] With reference to [Fig.l], an embodiment of a computer infrastructure for implementing the method according to the invention will be presented.

[0035] Infrastructure 1 includes a client 10, such as a mobile telephone.

[0036] The client 10 is a computer comprising calculation means, such as a processor 11, and storage means 12, such as a memory. The memory stores in particular the instructions of computer programs, in particular a program whose execution allows the implementation of a service application and a program whose execution allows the implementation of a VPN client application 14.

[0037] Memory 12 also stores a reference key Kref and a client context CC.

[0038] The client 10 comprises a radiocommunication module 16.

[0039] The infrastructure 1 comprises a radiocommunication network 20.

[0040] The network 20 comprises base stations, such as station 21.

[0041] The network 20 comprises a PGW (“Packet Data Network Gateway”) 22 connection to a public network 30.

[0042] For example, for an implementation conforming to the fourth generation - 4G, the network 20 comprises, in a known manner, a mobility management entity - MME ("Mobility Management Entity") 23, a mobile switching center / data recorder visitor location - MSC / VLR (Mobile Switching Center / Visitor Location Register) 24, a subscription server - HSS (Home Subscriber Server) 25 and a service capability exposure function - SCEF (Service Capability Exposure Function) 26.

[0043] The public network 30 comprises a service server 31.

[0044] The public network 30 comprises a VPN server 40.

[0045] The VPN server 40 is a computer comprising calculation means, such as a processor 41, and storage means 42, such as a memory. The memory stores in particular the instructions of computer programs, in particular a program whose execution allows the implementation of a VPN client application 44.

[0046] The memory 42 also stores a reference key Kref and a server context CS.

[0047] The VPN server 40 comprises an input / output interface 46.

[0048] With reference to [Fig.2], a preferred embodiment of the method according to the invention will be presented.

[0049] The method 100 comprises a reference key generation phase 110, a VPN client wake-up phase 120 and a VPN server wake-up phase 130. Phase 110 of generating a reference key

[0050] In “connected” mode of the client 10, a VPN tunnel is established between the two endpoints which are the VPN client application 14, executed on the mobile client, and the VPN server application 44 executed on the VPN server 40.

[0051] This allows the application 13 to access, via the VPN tunnel and the VPN server 40, the service server 31.

[0052] The VPN client application 14 stores a set of attributes of the VPN tunnel, gathered in the client context CC.

[0053] The VPN server application 44 also stores a set of attributes of the VPN tunnel, gathered in a CS server context.

[0054] During a VPN communication session, data messages are exchanged between the VPN client application 14 and the VPN server application 44, along the VPN tunnel.

[0055] Each message contains a VPN session identifier. This identifier is incremented with each message exchanged. This incrementation is consistent between the VPN server application and the VPN client application.

[0056] This VPN session identifier is part of both the client and server contexts.

[0057] Either a secret is already shared between the mobile terminal 10 and the VPN server 40 (such as a certified public key) and step 110 is summarized in step 117, or none secret is not yet shared between the mobile terminal 10 and the VPN server 40 and step 110 includes steps 112 to 116 of sharing a reference key as a secret.

[0058] Thus, in the latter case, before the client 10 switches to the “sleep” mode ", the VPN client application 14 generates (step 112) a reference encryption key, Kref.

[0059] For example, an algorithm of the type AES 256 (“Advanced Encryption Standard”) is executed by the VPN client.

[0060] Advantageously, the reference key Kref is derived from the current value of the VPN session identifier, i.e. the identifier of the last VPN session which had a positive response from the VPN server application.

[0061] The VPN client application 14 transmits (step 113), via the VPN channel, an information message to the VPN server application 44, this information message comprising the reference key Kref generated in step 112.

[0062] Upon receiving the information message, the VPN server application stores (step 114) the reference key, Kref, in association with the current server context of the VPN tunnel.

[0063] The VPN server confirms the correct reception of the reference key by transmitting (step 115) an acknowledgment message to the VPN client application.

[0064] Upon receipt of the control message, the VPN client application 14 stores (step 116) the reference key Kref in association with the current client context of the VPN tunnel.

[0065] Alternatively, it is the VPN server application that generates the reference key and transmits it to the VPN client application through the VPN tunnel. The latter sends in return an acknowledgment message of the reference key.

[0066] Then, in step 117, a standby message is transmitted by the mobile terminal 10 to the VPN server 40. This state change message is protected, by encryption, with the secret shared between the two actors, such as the reference key Kref.

[0067] This mobile terminal state change message contains: the mobile terminal identifier, an anti-replay counter for countering replay attacks, the “standby” or “wake-up” information, and, optionally, the VPN context information if it has changed during the sleep phase of the mobile terminal (in particular the IP address of the mobile terminal).

[0068] Client 10 then switches to “sleep” mode and the VPN tunnel is temporarily “closed”.

[0069] No data is then exchanged between the VPN client application and the VPN server application.

[0070] The method 100 has the capacity for recovery, at the request of one or other of the two actors.

[0071] For this, the VPN client application 14 and the VPN server application 44 must constantly be open, waiting to receive a wake-up trigger message from the other actor.

[0072] Wake-up phase 120 triggered by the VPN client application

[0073] In the event that data must be transmitted from the client, the latter switches (step 122) from “sleep” mode to “connected” mode and requests the VPN client application 14 to reestablish the VPN tunnel.

[0074] The VPN client application 14 must then rebuild the VPN tunnel while maintaining continuity of service.

[0075] To do this, it is possible to implement a mechanism derived from the so-called “Auto Reconnect” mechanism, as defined in the RFC 5723 standard.

[0076] In a step 123, the VPN client application 14 extracts from its memory the reference key Kref and the associated client context CS, corresponding to the client context before the interruption.

[0077] In a step 124, the VPN client application updates the client context CS with the information that has changed during the sleep phase, in particular the IP address of the terminal.

[0078] In a step 125, a wake-up message is sent by the terminal 10 to the VPN server 40. This state change message is protected, by encryption, with the secret shared between the two actors, such as the reference key Kref.

[0079] The optional part of this state change message includes the VPN context information that has changed during the sleep phase of the mobile terminal (in particular the IP address of the mobile terminal).

[0080] Upon receiving the VPN tunnel reestablishment message, the VPN server application 44 decrypts (step 126) the state change message using the shared secret and extracts the operational information. This cryptographic verification of the message makes it possible to validate its integrity and authenticity.

[0081] Advantageously, the VPN application 44 also checks the validity of the anti-replay counter, to detect whether the wake-up message is not a replay.

[0082] If these checks lead to errors, the message is deleted.

[0083] Otherwise, in a step 127, the VPN server application 44 possibly transmits a confirmation of the reception of the message, but above all updates the server context CS with the information received in the state change message.

[0084] The VPN server application 44 thus reestablishes the VPN tunnel previously set up before going into standby, without requiring negotiation between the actors (in particular new VPN encryption keys).

[0085] Hence faster commissioning of the VPN tunnel upon waking.

[0086] Thus, both actors have updated contexts allowing them to resume the VPN communication session where it left off. Secure messages can then be transmitted.

[0087] In some use cases, the ability to put a terminal into "sleep" mode so that it is silent is more important than keeping the VPN context. In this case, the mobile terminal goes into "sleep" mode, deletes its VPN context (the server also deletes it on its side) and, at the moment a wake-up is requested (either by the terminal or by the server), the terminal initiates a new VPN key negotiation to establish a new VPN context.

[0088] What is kept in memory by the server and the terminal during a standby phase is the protection secret (in particular the reference key) of the standby / wake-up messages and, advantageously, the anti-replay counter, which is unique between each mobile terminal / VPN server pair.

[0089] Wake-up phase 130 triggered by the VPN server application

[0090] In the event that data must be transmitted from the server to the client, the client must be able to be informed that it must switch from "sleep" mode to "connected" mode and request the VPN client application to initiate the VPN tunnel reestablishment procedure (phase 120).

[0091] For this, a paging mechanism is implemented for the transmission of a wake-up message from the VPN server application to the client.

[0092] The wake-up message includes all or part of the server's CS context information.

[0093] In step 138, once awakened, the terminal updates its CS context. If there is a discrepancy between the updated CC context of the terminal and the CS context information communicated by the server, the terminal 10 initiates the procedure of step 120 so that the VPN client application and the VPN server application reconstruct the VPN tunnel by updating the contexts before the interruption with the client's roaming information, and thus ensure the continuity of the VPN communication by continuing the VPN session.

[0094] From then on, the VPN context is again active and operational.

[0095] In the case where the context has not been memorized before sleep, the The wake-up message does not contain any context information on the VPN server side. Then phase 120 involves a VPN key negotiation to establish a new VPN context.

[0096] In a preferred embodiment, the paging mechanism for transmitting a wake-up message from the server to the client is derived from the procedure, presented in ETSI Technical Recommendation TS 29 337 VI 1.7.0 (2016-01), allowing a connected object - loT (“Internet of Things”) to respond to a request from a customer portal (SCS).

[0097] Thus, for the VPN server application 44 to be able to use the paging functionality, it must first be registered (step 131) with the SCEF (or MTC-IWF) entity 26, to obtain the right to send wake-up messages by paging.

[0098] The purpose of recording is to create a transaction identifier and the request rights, thus forming an entry in the context table of the SCEF entity, to which is added the identifier of the client to be woken up.

[0099] The client can be identified from its MSISDN number, an external identifier saved on an operator's MTC AAA authentication server or a group identifier.

[0100] To wake up the client, the VPN application 44 first contacts (step 132) the SCEF entity 26 via a DIAMETER request. The DIAMETER request includes the client's public identity and the reference key Kref.

[0101] When the SCEF entity receives a wake-up request, it first contacts (step 133) the HSS database (or the HLR) 25 in order to convert the client's public identity into an identity internal to the operator network (IMSI identifier).

[0102] The HSS / HLR entity 25 may optionally contact an authentication server to convert an external identity into an IMSI number.

[0103] If the client's identity is recognized, the SCEF entity retrieves the client's subscription information in order to connect the VPN application with the client.

[0104] The SCEF entity 26 defines the most suitable wake-up method on the control plane to trigger a client action, based on the following information: - Current customer accessibility information (on which network the customer is located, and in which area); - Service triggering methods supported by the HPLMN or VPLMN network; - Trigger methods supported by the client; - Operator wake-up trigger policies; - Other information received from the VPN server application, including potentially the client's location if known. Location allows paging to be optimized to the cell and not to the location area - TAI ("Tracking Area Identifier") which groups together a large number of cells.

[0105] The possible wake-up methods are: - MT SMS: the client must be able to recognize in the wake-up message, an MT SMS coming from the VPN server application; - Cell Broadcast: The Cell Broadcast procedure allows the client to be woken up by transmitting information on the SIBs carried by the beacon channel; - NAS signaling; - IMS messages.

[0106] Then the SCEF 26 transmits (step 134) a wake-up message to the MSC 24, which retransmits it (step 135) in turn to the MME 23, which retransmits it (step 136) in turn to the base station 21, which broadcasts it (step 137) in the cell where the client is located.

[0107] The client 10 listening to its radio environment, it picks up the wake-up message. It compares (step 138) the reference key indicated in this wake-up message, with the reference key Kref that it memorizes.

[0108] In case of correlation, the client10 switches (step 122) from “sleep” mode to “connected” mode and launches the VPN tunnel reestablishment procedure. Steps 121 to 127 are performed to reopen the VPN tunnel. Benefits

[0109] With this automated mechanism for reconstructing the VPN tunnel between a mobile client and a VPN server, the method according to the invention guarantees continuity of service after a period of silence. It allows all security means to be restored instantly without loss of service or the need to re-establish authentication (costly in terms of time and operations).

[0110] It should be noted that the wake-up message broadcast (“broadcated”) on a cell is intercepted by all the terminals on this cell. With the mechanism according to the invention, the only terminal actually woken up is the one that is capable of validating all the keys present in the message. There is therefore no abusive wake-up of the terminals, but wake-up of only the terminal concerned.

[0111] The method according to the invention provides a mechanism allowing a client to remain silent when it does not transmit or receive any application data, since no persistent communication channel is maintained when there is no communication of application data. In particular, it makes it possible to avoid the exchange of a live signal.

[0112] It provides both a mechanism for establishing a VPN tunnel and a mechanism for putting the mobile client to sleep that does not signal the existence of this VPN tunnel.

[0113] This helps increase the security of the VPN tunnel between the client and the VPN server.

Claims

Claims

1. A method (100) of maintaining a secure channel between a client (10) and a server (40) across a wireless network, the method comprising the steps of, a secret being shared between the client and the server: - while the client is in "sleep" mode and data is to be transmitted from the client (10) to the server (40), waking up the client and initiating (120), by the client, a procedure for reestablishing the secure channel by transmitting to the server a state change message of the "wake-up" type protected using said secret; and, - while the client is in "sleep" mode and data is to be transmitted from the server to the client, waking up (130) the client by the server by means of the transmission of a paging message and initiating (120) by the client the procedure for reestablishing the secure channel by transmitting to the server a state change message of the "wake-up" type protected using said secret.

2. Method according to claim 1, further comprising a step (110) of exchanging the secret consisting, in "connected" mode and while the secure channel is established, of calculating, as a secret, a reference key by an agent among the client (10) and the server (40), and of transmitting, via the secure channel, the secure key to the other agent.

3. The method of claim 2, wherein the reference key (Kref) is generated from an identifier of the current session between the client and the server along the secure channel.

4. A method according to claim 2 or claim 3, wherein an algorithm of the AES 256 type is executed to calculate the reference key.

5. Method according to any one of the preceding claims, in which the server (40) maintains a server context (CS) of the secure channel and the client maintains a client context (CC) of the secure channel, the procedure for reestablishing the secure channel consists of: - adapting (124), by the client (10), the client context (CS) with a plurality of modified information comprising at least one current IP address of the client; - transmitting (125), by the client (10) to the server (40), the plurality of modified information in the state change message of the “wake-up” type; and, - adapting (127), by the server, the server context (CS) associated with the reference key, according to the plurality of information received.

6. A method according to any preceding claim, wherein the secure channel is a VPN channel, the client (10) running a VPN client application (14) and the server (40) running a VPN server application (44).

7. Method according to any one of the preceding claims, in which a state change message of the "standby" type is transmitted by the client (10) to the server (40), said standby message being protected by the secret shared between the client and the server.

8. Method according to any one of the preceding claims, in which the state change message contains: the client identifier, an anti-replay counter, the type of the state change message "sleep" or "wake up", and all or part of the client context updated for a state change message of the "wake up" type.

9. Method according to any one of the preceding claims, in which, while client and / or server contexts have not been saved before a switch of the client into the "sleep" mode, following the transmission to the server of the state change message of the "wake-up" type, the client initiates a key negotiation to establish the secure channel.

10. A computer program comprising software instructions which, when executed by the computer of a client (10) or a server (20) in communication via a secure channel through a wireless network, implement a method (100) according to any one of the preceding claims.

Images