COMMUNICATION

TECHNICAL FIELD

The present invention relates generally to the field of network communications, and particularly to gateway devices and methods for transmission of data packets between, e.g., gateway devices across a network. The present invention addresses the double encryption problem, for example, by transmitting data packets based on authentication using minimal encryption. BACKGROUND

Conventionally, double encryption of data packets transmitted over a channel (which is established between two gateway devices over an existing network infrastructure) occurs, e.g., by a secure application when using encrypted tunnel technologies such as a Virtual Private Network (VPN), a Multiplexed Transport Layer Security (mTLS), etc. However, the double encryption process is computationally intensive and resource consuming, and results in a high cost of a Central Processing Unit (CPU).

For instance, in conventional communication systems, a first host in a first network (e.g., host A in network site A) may send a packet to a second host in a second network (e.g., host B in site B) via, e.g., two conventional gateway devices, which may use an encrypted tunnel technology such as the VPN, the mTLS, etc.

Furthermore, some applications such as a Hypertext Transfer Protocol Secure (HTTPS) and a Secure Shell (SSH) may also communicate using an encrypted channel, e.g., a cryptographic network protocol may be used for operating network services securely over a network (e.g., the network may be secured or unsecured). Moreover, since the conventional gateway devices use the encrypted tunnel technologies (e.g. VPN, mTLS), they provide additional encryption such as providing security (no eavesdroppers), providing authentication (the source site is known), etc. However, in the conventional devices and methods, when both systems (a combination of gateway devices and the applications using encrypted channels) are used together, the traffic is encrypted twice which results in a high cost for the Central Processing Unit (CPU), a security ramification minimal, etc.

SUMMARY

In view of the above-mentioned disadvantages, embodiments of the present invention aim to improve the conventional systems. An objective is to provide a gateway device and method for authentication using minimal encryption. In particular, the double encryption problem should be avoided. Costs for the CPU should accordingly be reduced. The gateway device and method should not add on top of existing security measures.

The objective of the present invention is achieved by the embodiments provided in the enclosed independent claims. Advantageous implementations of the embodiments of the present invention are further defined in the dependent claims.

The main advantages of the embodiments of the invention can be summarized as follows:

• Enabling an authenticated site-to-site communication.

• No need for double or redundant encryption.

• Authentication is relatively fast since encrypted payload is small.

• Secure communication, e.g., relying on application encryption (e.g., HTTPS).

• Protocol independency.

• No modification to application code (changes are only seen by the gateway devices).

A first aspect of the invention provides a gateway device configured to receive, over a secure communication link, a first data packet originated from a source host and addressing a target host; incorporate, when detecting an encrypted payload in the first data packet, a first header to the first data packet, wherein the first header comprises a first key encrypted with authentication data of another gateway device; and forward the first data packet incorporated with the first header over a communication channel to the other gateway device. The source host and/or the target host may be, or may incorporated in, a computer, a personal computer (PC), a server, a tablet, a laptop, a smartphone, a play station, a digital camera, etc.

The gateway device may be a device that acts as a gate between two networks. For example, the first gateway device and/or the second gateway device may be, or incorporated in, a router, a firewall, a server, or other device that enables transmission of data packets in and out of the network.

For example, in some embodiments, a source host (i.e., host A in site A (i.e., a first network)) sends packet to a target host (i.e., host B in Site B (i.e., a second network)) via two gateway devices including a first gateway device in site A and a second gateway device in site B. Moreover, the gateway devices (e.g., a VPN endpoint, an mTLS gateway device, etc.) detect that payload is already encrypted. The gateway device may incorporate (e.g., inject) an additional header, and may further negotiate the data packet.

The gateway device may detect the encrypted payload, e.g. by configuration, detecting encrypted packets, e.g., TLS, Encapsulating Security Payload (ESP), port inspection, etc.

In some embodiments, the first header may be incorporated, e.g., by identifying the injection point. Afterwards, the packet data from the identified injection point is moved (e.g., with “memmove”) header-length octets forwards. The first header then overwrites the old location. Note that, this is a trivial implementation, intuitive to the skilled person in the field.

The gateway device may comprise a circuitry. The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a non volatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein.

In an implementation form of the first aspect, the gateway device is further configured to receive a second data packet incorporated with a second header over the communication channel from the other gateway device, wherein the second data packet addressing the source host and comprises a second key encrypted with authentication data of the gateway device.

In a further implementation form of the first aspect, the gateway device is further configured to extract the second header from the second data packet, after verifying its authentication data; store the second header on connection metadata on the gateway device; and forward the second data packet, in particular its payload, to the source host.

In particular, the payload of the second data packet may be forwarded to the source host.

In a further implementation form of the first aspect, the gateway device is further configured to generate a token based on the first key, the second key and the authentication data of the other gateway device.

In particular, the first key and/or the second key may be a random seed, or an additional seed. The first key (e.g., the random seed) may have any function (e.g., since anything can be used).

In some embodiments, the token may be generated and may further be negotiated.

For example, the gateway device may inject the first header (e.g., an additional header). Moreover, it may negotiate the data packet. For example, it may encrypt and send a random seed. The gateway device may receive a response from the other gateway device which may include the additional seed. Furthermore, the token may be generated using both seeds and a timestamp. Moreover, during a general case step, the gateway device may encrypt and may further send the token. Furthermore, the gateway device may renegotiate every short time (e.g., one hour).

The negotiation of data packet may be performed during session negotiation and the general case may be performed during transmitting data over the session.

The encryption may be done using peer’s public keys, e.g., Rivest-Shamir-Adleman (RSA). In a further implementation form of the first aspect, the gateway device is further configured to perform a Site-To-Site communication with the other gateway based on the generated token.

In a further implementation form of the first aspect, the gateway device is further configured to incorporate, to the first data packet, the token encrypted with authentication data of the other gateway device; and forward the first data packet incorporated with the encrypted token, over the communication channel to the other gateway device.

In a further implementation form of the first aspect, the gateway device is further configured to receive the second data packet incorporated with the encrypted token, over the communication channel from the other gateway device, wherein the second data packet addressing the source host.

In a further implementation form of the first aspect, the gateway device is further configured to extract the token from the second data packet, after verifying its authentication data; store the token on the connection metadata of the gateway device; and forward the second data packet to the source host.

In particular, the payload of the second data packet may be forwarded to the source host.

In a further implementation form of the first aspect, a first key and/or a second key comprises a random seed.

In a further implementation form of the first aspect, the incorporated first header further comprises a certificate of the gateway device and/or authentication data of the gateway device.

In a further implementation form of the first aspect, the authentication data of a respective gateway device comprises: a public key of the respective gateway device; and/or a private key of the respective gateway device.

In a further implementation form of the first aspect, the gateway device is further authenticated to the other gateway device based on one or more of: a centralized management system; a performed communication over the communication channel; an existing communication channel between the gateway device and the other gateway device.

In a further implementation form of the first aspect, a first header and/or a second header and/or a token has a structure determined based on a Transport Layer Security, TLS, record.

In a further implementation form of the first aspect, the first header and/or the second header and/or the token is incorporated to one or more of: a TLS payload; a TLS payload of a single TLS record type; a TLS payload of multiple TLS record types; the end of the first data packet and/or the second data packet.

A second aspect of the invention provides a gateway device configured to receive a first data packet incorporated with a first header over a communication channel from another gateway device, wherein the first data packet originated from a source host and addressing a target host, and wherein the first header comprises a first key encrypted with authentication data of the gateway device; extract the first header from the first data packet, after verifying its authentication data; store the first header on connection metadata on the gateway device; and forward the first data packet, in particular its payload, to the target host.

The gateway device may be a device that acts as a gate between two networks. For example, the first gateway device and/or the second gateway device may be, or incorporated in, a router, a firewall, a server, or other device that enables transmission of data packets in and out of the network.

The gateway device may comprise a circuitry. The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a non volatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein.

In an implementation form of the second aspect, the gateway device is further configured to receive, over a secure communication link, a second data packet originated from the target host and addressing the source host; incorporate, when detecting an encrypted payload in the second data packet, a second header to the second data packet, wherein the second header comprises a second key encrypted with authentication data of the other gateway device; and forward the second data packet incorporated with the second header over the communication channel to the other gateway device.

A third aspect of the invention provides a method for a gateway device, the method comprising receiving, over a secure communication link, a first data packet originated from a source host and addressing a target host; incorporating, when detecting an encrypted payload in the first data packet, a first header to the first data packet, wherein the first header comprises a first key encrypted with authentication data of another gateway device; and forwarding the first data packet incorporated with the first header over a communication channel to the other gateway device.

In an implementation form of the third aspect, the method further comprises receiving a second data packet incorporated with a second header over the communication channel from the other gateway device, wherein the second data packet addressing the source host and comprises a second key encrypted with authentication data of the gateway device.

In a further implementation form of the third aspect, the method further comprises extracting the second header from the second data packet, after verifying its authentication data; storing the second header on connection metadata on the gateway device; and forwarding the second data packet to the source host.

In a further implementation form of the third aspect, the method further comprises generating a token based on the first key, the second key and the authentication data of the other gateway device. In a further implementation form of the third aspect, the method further comprises performing a Site-To-Site communication with the other gateway based on the generated token.

In a further implementation form of the third aspect, the method further comprises incorporating, to the first data packet, the token encrypted with authentication data of the other gateway device; and forwarding the first data packet incorporated with the encrypted token, over the communication channel to the other gateway device.

In a further implementation form of the third aspect, the method further comprises receiving the second data packet incorporated with the encrypted token, over the communication channel from the other gateway device, wherein the second data packet addressing the source host.

In a further implementation form of the third aspect, the method further comprises extracting the token from the second data packet, after verifying its authentication data; storing the token on the connection metadata of the gateway device; and forwarding the second data packet to the source host.

In a further implementation form of the third aspect, a first key and/or a second key comprises a random seed.

In a further implementation form of the third aspect, the incorporated first header further comprises a certificate of the gateway device and/or authentication data of the gateway device.

In a further implementation form of the third aspect, the authentication data of a respective gateway device comprises: a public key of the respective gateway device; and/or a private key of the respective gateway device.

In a further implementation form of the third aspect, the gateway device is further authenticated to the other gateway device based on one or more of: a centralized management system; a performed communication over the communication channel; an existing communication channel between the gateway device and the other gateway device.

In a further implementation form of the third aspect, a first header and/or a second header and/or a token has a structure determined based on a Transport Layer Security, TLS, record.

In a further implementation form of the third aspect, the first header and/or the second header and/or the token is incorporated to one or more of:

- a TLS payload; a TLS payload of a single TLS record type; a TLS payload of multiple TLS record types; the end of the first data packet and/or the second data packet.

A fourth aspect of the invention provides a method for a gateway device, the method comprising receiving a first data packet incorporated with a first header over a communication channel from another gateway device, wherein the first data packet originated from a source host and addressing a target host, and wherein the first header comprises a first key encrypted with authentication data of the gateway device; extracting the first header from the first data packet, after verifying its authentication data; storing the first header on connection metadata on the gateway device; and forwarding the first data packet, in particular its payload, to the target host.

In particular, the payload of the first data packet may be forwarded to the target host.

In an implementation form of the fourth aspect, the method further comprises receiving, over a secure communication link, a second data packet originated from the target host and addressing the source host; incorporating, when detecting an encrypted payload in the second data packet, a second header to the second data packet, wherein the second header comprises a second key encrypted with authentication data of the other gateway device; and forwarding the second data packet incorporated with the second header over the communication channel to the other gateway device.

A fifth aspect of the invention provides a computer program product including computer program code, which, when executed by a processor, causes the method according to the third aspect and/or the fourth aspect and/or one of the implementation form of the third aspect and/or one of the implementation form of the fourth aspect to be performed.

A sixth aspect of the invention provides a non-transitory computer-readable recording medium that stores therein a computer program product which, when executed by a processor, causes the method according to the third aspect and/or the fourth aspect and/or one of the implementation form of the third aspect and/or one of the implementation form of the fourth aspect to be performed.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above described aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 is a schematic view of a gateway device, according to an embodiment of the present invention;

FIG. 2 is a schematic view of another gateway device, according to an embodiment of the present invention; FIG. 3 is a schematic view of the gateway device of FIG. 1 communicating with the gateway device of FIG. 2;

FIG. 4 is a schematic view of a method for incorporating a first header to data packet and negotiating the data packet between two gateway devices; FIG. 5 is a schematic view of a method for performing a Site-to-Site communication between two gateway devices;

FIG. 6 is a schematic view of a method for data transmission between two gateway devices when they are pre-authenticated to each other;

FIG. 7 is a schematic view of incorporating the first header to the first data packet in a TLS payload;

FIG. 8 is a schematic view of incorporating the first header to the first data packet as piggyback on TLS application data;

FIG. 9 is a flowchart of a method for a gateway device, according to an embodiment of the invention; FIG. 10 is a flowchart of another method for a gateway device, according to an embodiment of the invention.

DETAILED DESCRIPTION OF EMBODIMENTS

Illustrative embodiments are now described with reference to the figures. Although this description provides a detailed example of possible implementations, it should be noted that the details are intended to be exemplary and in no way limit the scope of the application.

Moreover, an embodiment/example may refer to other embodiments/examples. For example, any description including but not limited to terminology, element, process, explanation and/or technical advantage mentioned in one embodiment/example is applicative to the other embodiments/examples. FIG. 1 is a schematic view of a gateway device 100, according to an embodiment of the present invention.

The gateway device 100 is configured to receive, over a secure communication link 111, a first data packet 101 originated from a source host 110 and addressing a target host 210.

The gateway device 100 is further configured to incorporate, when detecting an encrypted payload in the first data packet 101, a first header 102 to the first data packet 101, wherein the first header 102 comprises a first key encrypted with authentication data of another gateway device 200.

The gateway device 100 is further configured to forward the first data packet 101a incorporated with the first header 102 over a communication channel 112 to the other gateway device 200.

The gateway device is based on, for example, a router, a firewall, a server, or any other device that enables transmission of data packets in and out of the network. The source host and/or the target host may a computer, a PC, a server, a tablet, a laptop, a smartphone, a play station, a digital camera, etc.

For example, when using an encrypted channel on top of the VPN, the gateway device may be configured to add data providing gateways authentication without payload manipulation. The added data may be small (tens of bytes) compared to the whole packet and may be easier manipulated.

The incorporated first header (i.e., the added data) may prove authentication, e.g., without payload manipulation. The first header may have a smaller size (tens of bytes) compared to the whole packet.

The gateway device may comprise a circuitry (not shown in FIG. 1). The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a non-volatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein. Reference is now made to FIG. 2 which is a schematic view of another gateway device 200, according to an embodiment of the present invention;

The gateway device 200 is configured to receive a first data packet 101a incorporated with a first header 102 over a communication channel 112 from another gateway device 100, wherein the first data packet 101 is originated from a source host 110 and addressing a target host 210, and wherein the first header 102 comprises a first key encrypted with authentication data of the gateway device 200.

The gateway device 200 is further configured to extract the first header 102 from the first data packet 101a, after verifying its authentication data; store the first header 102 on connection metadata on the gateway device 200; and forward the first data packet 101, in particular its payload, to the target host 210.

The gateway device is based on, for example, a router, a firewall, a server, or any other device that enables transmission of data packets in and out of the network. The source host and/or the target host may a computer, a PC, a server, a tablet, a laptop, a smartphone, a play station, a digital camera, etc.

The gateway device may comprise a circuitry (not shown in FIG. 2). The circuitry may comprise hardware and software. The hardware may comprise analog or digital circuitry, or both analog and digital circuitry. In some embodiments, the circuitry comprises one or more processors and a non-volatile memory connected to the one or more processors. The non-volatile memory may carry executable program code which, when executed by the one or more processors, causes the device to perform the operations or methods described herein.

Reference is now made to FIG. 3, which is a schematic view of the gateway device 100 communicating with the gateway device 200.

In FIG. 3, the gateway device 100 is exemplarily illustrated as gateway A, and the source host 110 is illustrated as host A. Moreover, the gateway device 200 is exemplarily illustrated as gateway B, and the target host 210 is illustrated as host B.

The gateway device 100 and the source host 110 are located in a first network. Moreover, the gateway device 200 and the target host 210 are located in a second network. The gateway device 100 may be authenticated with the gateway device 200, and may further perform a Site-To-Site communication based on the generated token, adding a header to the data packets, etc.

Reference is now made to FIG. 4, which is a schematic view of a method for incorporating the first header to data packet and negotiating the data packet between two gateway devices.

The method 400 may be (e.g., fully or partially) performed by the gateway device 100 and/or the gateway device 200.

Without limiting the present disclosure, in the description of FIG. 4, it is assumed that the gateway device 100 performs some steps of the method 400. Moreover, some other steps are performed by the gateway device 200, the source host 110 and the target host 210.

In the embodiment of FIG. 4, the gateway device 100 is exemplarily illustrated as gateway A, and the source host 110 is illustrated as host A. Moreover, the gateway device 200 is exemplarily illustrated as gateway B, and the target host 210 is illustrated as host B. At step 401, the source host 110 (Host A in FIG. 4) begins a secure communication. For example, the source host 110 may send the first data packet 101 to the gateway device 100. The first data packet 101 is originated from the source host 110 and addressing the target host 210. Moreover, the gateway device 100 may receive the first data packet 101, over the secure communication link 111. For example, if the gateway devices are pre-authenticated (e.g., using a centralized controller), the first step may be avoided.

At step 402, the gateway device 100 adds data to the first data packet including the authentication data of the other gateway device 200. For example, the gateway device 100 detects an encrypted payload in the first data packet 101. Moreover, the gateway device 100 incorporates the first header 102 to the first data packet 101, and the first header 102 comprises the first key encrypted with authentication data of the other gateway device 200. At step 403, the gateway device 100 forwards the first data packet with additional data (i.e., the gateway device 100 forwards the first data packet 101a comprising the first header 102).

At step 404, the gateway device 200 verifies and removes authentication data. For example, it may throw the client off.

At step 405, the gateway device 200 begins a secure communication and forwards the first data packet 101 (original packet) to the target host 210.

At step 406, the target host 210 continues the secure communication. For example, it may send the second data packet.

At step 407, the gateway device 200 adds data to the second data packet, the data including authentication data and/or the token negotiation data.

At step 408, the gateway device 200 continues secure communication with the gateway device 100.

At step 409, the gateway device 100 verifies its authentication data, stores token negotiation data and it further restores packet to its original state.

Moreover, from this point on, both gateway devices are authenticated.

At step 410, the gateway device 100 continues secure communication, for example, the gateway device 100 forwards the second data packet (original packet from Host B) to the source host 110.

For instance, the gateway device 100 may extract the second header from the second data packet, after verifying its authentication data. Moreover, the gateway device 100 may further store the second header on connection metadata on the gateway device 100, and forward the second data packet, in particular, its payload, to the source host 110.

At step 411, the source host 110 continues secure communication with the gateway device 100. For example, it may send a first data packet 101 to the gateway device 100. At step 412, the gateway device 100 adds data to the packet, the data including token negotiation.

At step 413, the gateway device 100 continues secure communication with the other gateway device 200. Moreover, from this point on, the token has been negotiated.

At step 414, the gateway device 200 removes the added data.

At step 415, the gateway device 200 continues the secure communication with the target host 210.

At step 416, the target host 210 continues the secure communication with the other gateway device 200.

At step 417, the gateway device 200 adds the calculated token that is encrypted such that only the gateway device 100 (gateway A in FIG. 4) can decrypt it (e.g., by using public/private keys).

At step 418, the gateway device 200 continue secure communication with the gateway device 100.

At step 419, the gateway device 100 verifies and it further removes the token.

At step 420, the gateway device 100 continues the secure communication with the source host 110.

Reference is now made to FIG. 5, which is a schematic view of a method 500 for performing a Site-to-Site communication between two gateway devices.

The method 500 may be (e.g., fully or partially) performed by the gateway device 100 and/or the gateway device 200.

Without limiting the present disclosure, in the description of FIG. 5, it is assumed that the gateway device 100 performs some steps of the method 500. Moreover, some other steps are performed by the gateway device 200, the source host 110 and the target host 210. In the embodiment of FIG. 5, the gateway device 100 is exemplarily illustrated as gateway A, the source host 110 is illustrated as host A. Moreover, the gateway device 200 is exemplarily illustrated as gateway B, and the target host 210 is illustrated as host B.

At step 501, the source host 110 (Host A in FIG. 5) begins a secure communication. For example, the source host 110 may send the first data packet 101 to the gateway device 100. The first data packet 101 originated from the source host 110 and addressing the target host 210. Moreover, the gateway device 100 may receive the first data packet 101, over the secure communication link 111.

At step 502, the gateway device 100 injects the first header 102 to the first data packet 101. For example, the gateway device 100 detects an encrypted payload in the first data packet 101. Moreover, the gateway device 100 incorporates the first header 102 to the first data packet 101, and the first header 102 comprises the random seed encrypted with the public key of the gateway device 200 (e.g., the gateway B’s public key).

At step 503, the gateway device 100 begins a secure communication with the gateway device 200.

At step 504, the gateway device 200 removes the injected header 102. For example, the gateway device 200 stores the injected header data on the connection metadata.

At step 505, the gateway device 200 begins a secure communication to the target host 210, for example, it forwards the first data packet 101 (original packet) to the target host 210.

At step 506, the target host 210 continues the secure communication. For example, it may send the second data packet.

At step 507, the gateway device 200 injects header to the second data packet received from the target host 210. The injected header comprises a different random seed encrypted with the public key of the gateway device 100 (i.e., gateway A’s public key).

Moreover, from this point on, both gateway devices 100 and 200 can compute token.

At step 508, the gateway device 200 continues secure communication with the gateway device 100. At step 509, the gateway device 100 removes the injected header and stores it.

At step 510, the gateway device 100 continues secure communication, for example, the gateway device 100 forwards the second data packet (original packet from Host B) to the source host 110.

At step 511, the source host 110 continues secure communication with the gateway device 100.

At step 512, the gateway device 100 inject header to the data packet received from the source host 110. For example, the injected header includes a calculated token encrypted with the public key of the other gateway device 200 (i.e., the gateway B’s public key).

At step 513, the gateway device 100 continues secure communication with the other gateway device 200.

At step 514, the gateway device 200 verifies the token and removes the injected header.

At step 515, the gateway device 200 continues the secure communication with the target host 210.

Reference is now made to FIG. 6, which is a schematic view of a method for data transmission between two gateway devices 100 and 200 when they are pre-authenticated to each other.

The method 600 may be (e.g., fully or partially) performed by the gateway device 100 and/or the gateway device 200.

Without limiting the present disclosure, in the description of FIG. 6, it is assumed that the gateway device 100 performs some steps of the method 600. Moreover, some other steps are performed by the gateway device 200, the source host 110 and the target host 210.

In the embodiment of FIG. 6, the gateway device 100 is exemplarily illustrated as gateway A, the source host 110 is illustrated as host A. Moreover, the gateway device 200 is exemplarily illustrated as gateway B, and the target host 210 is illustrated as host B. The gateway devices 100 and 200 are already authenticated with one another, for example, based on at least one of:

• with a centralized management system,

• from a previous communication,

• from an existing tunnel.

The method 600 of FIG. 6 is similar to method 400 of FIG. 4 and/or the method 500 of FIG. 5. However, the authentication data (e.g., the certificates) are also sent. Moreover, the public keys (e.g., the RSA, the Diffie-Hellman) are also transmitted.

The authentication itself may be performed with a third-party trusted authority, in such a case, only public keys have to be exchanged. Additionally, a challenge may be sent between the two gateway devices 100 and 200, to verify that each gateway device has the matching private key it claims.

At step 601, the source host 110 (Host A in FIG. 6) begins a secure communication. For example, the source host 110 may send the first data packet 101 to the gateway device 100. The first data packet 101 originated from the source host 110 and addressing the target host 210. Moreover, the gateway device 100 may receive the first data packet 101, over the secure communication link 111.

At step 602, the gateway device 100 injects the first header 102 to the first data packet 101. For example, the gateway device 100 detects an encrypted payload in the first data packet 101. Moreover, the gateway device 100 incorporates the first header 102 to the first data packet 101, and the first header 102 comprises the certificate and the public key of the gateway device 100 (e.g., the gateway A’s certificate and/or the gateway A’s public key).

At step 603, the gateway device 100 forwards the first data packet with additional data to the gateway device 200.

At step 604, the gateway device 200 removes the injected header 102. For example, the gateway device 200 stores the injected header data on the connection metadata.

At step 605, the gateway device 200 begins a secure communication to the target host 210, for example, it forwards the first data packet 101 (original packet) to the target host 210. At step 606, the target host 210 continues the secure communication. For example, it may send the second data packet.

At step 607, the gateway device 200 adds data to the second data packet, the data includes the certificate and the public key of the gateway device 200 (e.g., the gateway B’s certificate and/or the gateway B’s public key) and a random seed encrypted with the public key of the gateway device 100 (i.e., gateway A’s public key).

At step 608, the gateway device 200 continues secure communication with the gateway device 100.

At step 609, the gateway device 100 updates the stored data and removes the injected header.

At step 610, the gateway device 100 continues secure communication, for example, the gateway device 100 forwards the second data packet (original packet from Host B) to the source host 110.

At step 611, the source host 110 continues secure communication with the gateway device 100.

At step 612, the gateway device 100 inject header data to the packet received from the source host 110. For example, the injected header includes a random seed encrypted with the public key of the other gateway device 200 (i.e., the gateway B’s public key).

At step 613, the gateway device 100 continues secure communication with the other gateway device 200.

Moreover, from this point on, both gateways (i.e., the gateway device 100 and the gateway device 200) can compute token.

At step 614, the gateway device 200 calculates token and removes injected header.

At step 615, the gateway device 200 continues the secure communication with the target host 210. At step 616, the target host 210 continues the secure communication with the other gateway device 200.

At step 617, the gateway device 200 inject the header comprising the calculated token that is encrypted such the public key of the gateway device 100 (the gateway A’s public key).

At step 618, the gateway device 200 continue secure communication with the gateway device 100.

At step 619, the gateway device 100 verifies the token and removes the injected header.

At step 620, the gateway device 100 continues the secure communication with the source host 110.

Reference is made to FIG. 7 which is a schematic view is a schematic view of incorporating the first header 102 to the first data packet 101 in a TLS payload 700.

The gateway device 100 and/or the gateway device 200 may incorporate the first header 102 to the first data packet 101.

Without limiting the present disclosure, in FIG. 7, it is assumed that the gateway device 100 adds a new header with the necessary data to the first data packet 101 and only one inserted first header 102 is needed. However, there are two options for its location. The first header 102 may be incorporated at a first location indicated with the reference 102a and/or at a second location indicated with the reference 102b. The first header structure can be similar to TLS records.

TLS records can carry certificates, public keys, negotiation data, and next-header data

The first data packet 101 includes the L2 (e.g., MAC) 702, the L3 (e.g. IPv4 or IPv6) 703, the L4 (e.g. TCP or UDP) 704 and the L5-7 (Application data) 705.

The first header 102 may be incorporated at the first location as indicated with reference 102a, i.e., authentication using minimal encryption data above L3, or at the second location indicated with reference 102b, i.e., authentication using minimal encryption above L4. In FIG. 7, for example, the TLS record with a new type is added to the TLS payload. Moreover, only TLS tunnels and TLS based communications are supported in this embodiment. The new TLS record may comprise the gateway certificates, token negotiation, and encrypted tokens, etc. Optionally, it can be a single TLS record type or multiple TLS record types for each type of data. Moreover, the new TLS record may also be added at the end of the packet, which may improve performance (no shimming).

Reference is now made to FIG. 8, which is a schematic view of incorporating the first header 102 to the first data packet 101 as piggyback on TLS application data 800.

Without limiting the present disclosure, in FIG. 8, it is assumed that the gateway device 100 incorporate a first header 102 to the first data packet 101.

For example, the gateway device 100 may modify the TLS application data, append (or prepend) the additional data (i.e., the first header 102) to the TLS record 800 comprising the original application data 801. The data size of the first header 102 can be encoded as well, for example, in case of prepend, or it may be noted as the difference between the size noted by the TLS record and the L4 (UDP/TCP) record, etc.

In the example of the TLS record, the first header 102 is added as a piggy -backed data at the end of the first data packet 101.

FIG. 9 shows a method 900 according to an embodiment of the invention for a gateway device. The method 900 may be carried out by the gateway device 100, as it described above.

The method 900 comprises a step 901 of receiving, over a secure communication link 111, a first data packet 101 originated from a source host 110 and addressing a target host 210.

The method 900 further comprises a step 902 of incorporating, when detecting an encrypted payload in the first data packet 101, a first header 102 to the first data packet 101, wherein the first header 102 comprises a first key encrypted with authentication data of another gateway device 200. The method 900 further comprises a step 903 of forwarding the first data packet 101a incorporated with the first header 102 over a communication channel 112 to the other gateway device 200.

FIG. 10 shows a method 1000 according to an embodiment of the invention for a gateway device. The method 1000 may be carried out by the gateway device 200, as it described above.

The method 1000 comprises a step 1001 of receiving a first data packet 101a incorporated with a first header 102 over a communication channel 112 from another gateway device 100, wherein the first data packet 101 originated from a source host 110 and addressing a target host 210, and wherein the first header 102 comprises a first key encrypted with authentication data of the gateway device 200.

The method 1000 further comprises a step 1002 of extracting 1002 the first header 102 from the first data packet 101a, after verifying its authentication data.

The method 1000 further comprises a step 1003 of storing the first header 102 on connection metadata on the gateway device 200.

The method 1000 further comprises a step 1004 of forwarding the first data packet 101, in particular its payload, to the target host 210.

The present invention has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.