Patent Description:
Network communication in virtualized and cloud environments is commonly based on a model referred to as software-defined networking (SDN), allowing for management flexibility and efficient utilization or network resources.

In the SDN model, communication is organized in network flows between network endpoints <NUM>, <NUM>. As shown in <FIG>, a flow - i.e. a sequence of data packets - may be established once a first network endpoint <NUM> initiates a network communication session and thus initiates a flow F1. Data plane network elements such as one or more SDN switches <NUM> located on a communication path between the two endpoints <NUM>, <NUM> match incoming flows against flow rules contained in a flow table and handle the packets accordingly. For instance, the SDN switch <NUM> may conclude from the flow table that flow F1 is to be forwarded to the second network endpoint <NUM> and thus create flow F4 comprising the data packets of flow F1.

Unmatched packets may be dropped or sent (as F2) to an SDN controller <NUM>, which may install a rule in the flow table of the SDN switch <NUM> with flow F3, thereby stipulating that the incoming flow F1 is to be forwarded to the second network endpoint <NUM> and the SDN switch <NUM> will create flow F4 accordingly.

Communication between network endpoints is commonly protected using suites for secure communication, such as Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). To implement such protocols, the network endpoints <NUM>, <NUM> require cryptographic keys, i.e. either shared symmetric keys or public/private key pairs and digital certificates.

Further, network endpoints may use a variety of application layer protocols to communicate. Examples of such protocols include CoAP (constrained application protocol), MQTT (message queueing telemetry transport), AMQP (advanced message queuing protocol), XMPP (extensive messaging and presence protocol), among others. Such application layer protocols are not mutually compatible or inter-operable. Two approaches commonly exist in order to achieve interoperability between endpoints that communicate using different application layer protocols.

In a first approach illustrated in <FIG>, a hardware or software network component <NUM> (a "middlebox") implements the logic of translating packets between two or more incompatible application layer protocols, in this example a first protocol utilized by client <NUM> and a second protocol utilized by server <NUM>. While this approach allows in-line protocol translation at a high data rate, it cannot handle secure network communication, for example network communication over TLS or DTLS; instead, it transmits the packets in plaintext.

In a second approach illustrated in <FIG>, all traffic is forwarded to a cloud back-end <NUM>, where the secure communication is terminated. The cloud back-end <NUM> translates the incoming network packets from the client <NUM> to the destination protocol of the server <NUM> and forwards the packets over a new secure channel. While this approach allows support for secure communication between the endpoints (such as TLS or DTLS), a significant communication delay is introduced. Furthermore, this introduces a single point of failure; in case the translation component in the cloud back-end <NUM> is compromised and cryptographic keys are attained, an adversary may gain access to all communication flows between all endpoints.

US patent application <CIT> is further prior art.

One objective is to solve, or at least mitigate, these problems and provide a method of a network device for enabling communication protocol translation of encrypted data traffic between a first device and a second device.

This objective is attained in a first aspect by a method of a network device of enabling communication protocol translation for encrypted data traffic between a first device and a second device. The method comprises receiving, from the first device, data intended for the second device, triggering creation of a trusted execution environment (TEE), and requesting attestation of the created TEE from a trusted central device having access to a certificate authority (CA) performing the attestation. Further, the method comprises receiving, over a secure communication channel established with the trusted central device upon successful attestation, protocol translation instructions and cryptographic credentials required for securely communicating with the first device and the second device and decrypting, in the TEE, any received encrypted data from the first device using the received cryptographic credentials, translating the decrypted data from a first protocol format utilized by the first device into a second protocol format utilized by the second device in the TEE based on the received translation instructions, and encrypting the translated data in the TEE using the received cryptographic credentials, the credentials being configured to allow the second device to decrypt the encrypted translated data. Finally, the encrypted translated data is sent to the second device.

This objective is attained in a second aspect by a network device configured to enable communication protocol translation of encrypted data traffic between a first device and a second device. The network device comprises a processing unit and a memory containing instructions executable by the processing unit, whereby the network device is operative to receive, from the first device, data intended for the second device, trigger creation of a TEE, to request attestation of the created TEE from a trusted central device having access to a certificate authority (CA) performing the attestation, and to receive, over a secure communication channel established with the trusted central device upon successful attestation, protocol translation instructions and cryptographic credentials required for securely communicating with the first device and the second device. The network device is further operative to decrypt, in the TEE, any received encrypted data from the first device using the received cryptographic credentials, translate the decrypted data from a first protocol format utilized by the first device into a second protocol format utilized by the second device in the TEE based on the received translation instructions, and to encrypt the translated data in the TEE using the received cryptographic credentials, the credentials being configured to allow the second device to decrypt the encrypted translated data. Moreover, the network device is operative to send the encrypted translated data to the second device.

Thus, by creating a TEE being attested by a CA, in which TEE encrypted received data securely is decrypted, translated into a protocol format interpretable by an intended receiver, and finally re-encrypted before being sent to the intended receiver being able to decrypt the re-encrypted data, a number of advantages are obtained over approaches utilized in the art.

Scalability - as the number of data traffic flows increases in the network, a separate TEE can be created for each flow to provide protocol translation, such that translation logic/instructions and/or cryptographic credentials are separate for each flow. With this solution, the actual protocol translation process is not performed at a central node, neither is a bottleneck caused (in the form of one specific network middlebox for protocol translation, or hardware protocol translation element).

Robustness - the protocol translation can be performed in different switches/TEEs, thus avoiding the introduction of a single point of failure. For example, in case a certain network path is not available, a new TEE may be created for the specific network flow on a different network path.

Low latency for secure communication - the protocol translation process maintains a low latency while supporting secure communication between endpoints. In particular, network communication does not need to be re-routed to a cloud back-end to perform TLS termination and protocol translation before being sent over a secure TLS channel.

Transparency - the protocol translation process is transparent to the endpoints as they do not need to be involved in the translation process.

Security - the solution enables communication over a secure channel (such as (D)TLS) between endpoints that use different network communication protocols. In order to conduct protocol translation in a secure manner, the solution enables interception of (D)TLS traffic in a secure TEE. Thus, while the solution is agnostic to the actual approach to (D)TLS interception (e.g. through trusted certificates, key shares, or any other means), it uses integrity attestation of the TEEs to ensure that cryptographic credentials for protocol conversion is provisioned to and used in a secure environment.

Resource efficiency - TEEs are created on-demand in response to a translation action in the switch, triggered whenever communication over a secure channel occurs between two endpoints that use different network protocols. The lifetime of the TEE can be limited to the lifetime of the network communication flow between the respective endpoints (which further is advantageous in terms of security since a malicious attempt to extract credentials from the TEE will not be possible after the TEE has been terminated). This enables secure ad-hoc communication between endpoints that use different network protocols while using only a minimum of network and computational resources.

In an embodiment, the network device is configured to identify the second device as an intended receiver of the data and any rules associated with sending the data to the second device.

In an embodiment, the network device is configured to forward said data received from the first device to the second device.

In an embodiment, the network device is configured to receive and forward data received from the second device to the first device in order to enable handshaking between the first device and the second device.

In an embodiment, the network device is configured to, when triggering the creation of the TEE, creating the TEE at the network device.

In an embodiment, the network device is configured to, when triggering the creation of the TEE, requesting the trusted central device to create the TEE.

In an embodiment, the network device is configured to terminate the TEE upon sending the encrypted translated data to the second device.

In an embodiment, the network device is configured to terminate the TEE after a pre-set termination timer has expired after sending the encrypted translated data to the second device.

<FIG> illustrates an SDN in which a method of enabling protocol translation for encrypted data traffic is implemented according to an embodiment.

A client <NUM> transmits and receives data over the SDN using any appropriate application layer protocol, for instance CoAP. The data is communicated over an SDN switch <NUM> to a server <NUM> using an application layer protocol being different from the protocol used by the client <NUM>, for instance MQTT. Further illustrated is an SDN controller <NUM> to be discussed in more detail in the following.

As is understood, since two endpoints - i.e. the client <NUM> and the server <NUM> - utilizes different communication protocols, a protocol translation is required for the two endpoints to be able to communicate with each other.

Further, if secure communication is required, the data traffic between the client <NUM> and the server <NUM> must be encrypted, which further must taken into account upon performing protocol translation. As discussed hereinabove, this is problematic.

<FIG> shows a flowchart illustrating the method of enabling protocol translation for encrypted data traffic according to an embodiment.

In a first step S101, the client <NUM> sends to the SDN switch <NUM> at least one data packet P1 in plaintext intended for the server <NUM> in order to establish a transport layer connection, using for instance User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) as communication protocol.

In this exemplifying embodiment, upon the SDN switch <NUM> receiving the packet P1, the switch <NUM> concludes in step S102 that the packet P1 matches a rule in its flow table and that the packet P1 in accordance with the matching rule is to be forwarded to the server <NUM>. In case another type of network than SDN is being used, it may alternatively be envisaged that a header of the packet P1 indicates its destination, i.e. the server <NUM>, to a device being used is an alternative to the SDN switch <NUM>.

In step S103, the SDN switch <NUM> triggers creation of an instance of a trusted execution environment <NUM> (TEE). The TEE <NUM> is a secure processing area, which in this embodiment is located within the SDN switch <NUM>, where data being loaded into the area is protected with respect to confidentiality and integrity. The TEE <NUM> is created for communication between these very two endpoints, i.e. the client <NUM> and the server <NUM>. If the client subsequently initiates a communication with another device, a new dedicated TEE will be created by the SDN switch <NUM> for communication between the client <NUM> and said another device. It should be noted that the creation of the TEE <NUM> is "triggered" in the sense that the SDN switch <NUM> itself may create the TEE <NUM>, or alternatively turn e.g. to the SDN controller <NUM> for creation of the TEE <NUM>.

As can be seen, the TEE <NUM> is created when the SDN switch <NUM> receives the first packet P1 from the client <NUM> intended for the server <NUM>, before a secure communication channel is established between the SDN switch <NUM> and the client <NUM> and the server <NUM>, respectively. This advantageously avoids processing delays as compared to creating the TEE <NUM> at a later point when the secure channel has already been established.

In this particular embodiment, the TEE <NUM> is instantiated within the SDN switch <NUM>, but may alternatively be instantiated as a stand-alone entity.

Thereafter, the SDN switch <NUM> sends a request in step S104 to a trusted central device having access to a certificate authority <NUM> (CA), the trusted central device in this example being embodied by the SDN controller <NUM>, to perform attestation of the created TEE <NUM> which is designated for communication between the client <NUM> and the server <NUM>. As is understood, the CA <NUM> is trusted by all involved parties, i.e. the client <NUM>, the SDN switch <NUM> and the server <NUM>. In this example, the trusted central device, i.e. the SDN controller <NUM>, hosts the CA <NUM>, but the CA <NUM> may alternatively <NUM> be an entity external from the SDN controller <NUM>.

Attestation may be performed in numerous ways and serves to authenticate the TEE <NUM> to other entities - in this case the client <NUM> and the server <NUM> - thereby allowing the client <NUM> and the server <NUM> to remotely verify the integrity of the TTE <NUM>. Typically, each manufacturer of hardware uses its own attestation approach, such as Intel Software Guard Extensions (SGX), AMD Secure Encrypted Virtualization (SEV), IBM Protected Execution Facility (PEF), Amazon Web Services (AWS) Nitro Enclaves, etc..

In one embodiment, the SDN controller <NUM> performs attestation of the TEE <NUM> in step S105 by issuing a certificate to the TEE <NUM> via the CA <NUM>. In brief, the issued certificate of the CA <NUM> of the SDN controller <NUM> certifies TEE ownership of a public key and allows other parties to rely upon signatures created with a private key that corresponds to the certified public key.

Assuming that the attestation if successful in step S105, the SDN controller <NUM> sends in step S106 to the TEE, over an established secure channel:.

As is understood, the SDN controller <NUM> (which in this example also hosts a trusted CA <NUM>) in the network has access to information identifying the protocols utilized by the client <NUM> and the server <NUM>, respectively, as well as any cryptographic keys required to communicate securely with the client <NUM> and the server <NUM>.

In an SDN network, the SDN controller <NUM> is responsible for configuring the SDN switches (for example, configuring rules regarding protocol translation). The SDN controller <NUM> may have one or more applications (or extensions), which provide other network services; a typical example of such an application is traffic measurement and traffic analysis performed based on data collected by the SDN controller <NUM> from all the switches that it controls. Further, the CA <NUM> may be one of the applications or extensions of the SDN controller <NUM>, signing and managing public key infrastructure (PKI) certificates, as well as providing other typical CA functionality.

Likewise, the SDN controller <NUM> may be configured with a dedicated application/extension that implements the functionality to perform the attestation of the TEE <NUM> (i.e. a verifier). Once the attestation is performed, the verifier requests from the CA <NUM> the necessary cryptographic material and deploys them to the TEE <NUM>.

In step S107, in a scenario where a handshake procedure is performed between the client <NUM> and the server <NUM> at the transport layer before any data is sent over the application layer, the SDN switch <NUM> forwards the packet P1 to the server <NUM> in accordance with the rule of the flow table for which a match previously occurred. Preferably, in order to avoid network delay, packet P1 is forwarded to the server <NUM> simultaneously as the creation of the TEE <NUM> in S103. That is, steps S103 and S107 are preferably performed in parallel.

In response to packet P1 received from the SDN switch <NUM>, the server <NUM> sends a handshake packet P2 to the client <NUM> in step S108 via the SDN switch <NUM>, wherein communication between the client <NUM> and the server <NUM> has been established. In practice, further packets may be exchanged (in addition to P1 and P2) between the client <NUM> and the server <NUM> at the transport layer before an application layer connection is established.

Thereafter, in step S109, the client <NUM> sends one or more encrypted data packets P3,. , Pn to the SDN switch <NUM> in order to establish an application layer connection, which packets are intended for the server <NUM>.

The SDN switch <NUM> receives the encrypted data packets P3,. , Pn and forwards the packets to the TEE <NUM> in step S110 for further processing as illustrated in step S111.

The processing in step S111 includes the TEE <NUM> decrypting the packets P3,. , Pn in step S111a, e.g. with a symmetric key shared with the client <NUM> or with a private key included in a key pair comprising a public key with which the packets were encrypted at the client <NUM>. These required keys, or any cryptographic credentials from which these required keys can be derived or created, was previously provided to the TEE <NUM> by the SDN controller <NUM> as described hereinabove in connection to step S106.

Thus, after step S111a, the data packets P3,. , Pn are in plaintext inside the secure environment of the TEE <NUM>.

In step S111b, the TEE <NUM> utilizes the previously received network packet translation instructions to translate the packets P3,. , Pn transmitted using CoAP as application layer protocol into packets complying with MQTT. In other words, the data packets P3,. , Pn that were sent by the client <NUM> using a CoAP message format have now been converted to comply with the MQTT message format in order for the server <NUM> to be able to interpret the data comprised in the packets P3,.

In order to maintain the security level in the SDN, the data packets P3,. , Pn which are now in plaintext and comply with the MQTT protocol format are re-encrypted in step S111c inside the TEE <NUM> using an encryption key, or cryptographic material from which said encryption key can be derived or created, received from the SDN controller <NUM> in step S106. In other words, the MQTT plaintext data packets P3,. , Pn are re-encrypted with an encryption key for which the server <NUM> holds a corresponding decryption key.

The processing of the received encrypted CoAP packets P3,. , Pn inside the TEE <NUM> is thus completed and the resulting encrypted MQTT packets are provided to the SDN switch <NUM> in step S112, thereby transferring the packets outside of the secure environment provided by the TEE <NUM>.

The process of decrypting the encrypted packets inside the TEE <NUM> and thereafter re-encrypting any translated packets is commonly referred to as TLS interception, while the communication between endpoints - i.e. the client <NUM> and the server <NUM> - via the SDN switch <NUM> is referred to as TLS communication.

In step S113, the encrypted MQTT data packets P3,. , Pn (belonging to the same flow of packets P1 received in step S101 and thus have already been matched to a rule in the SDN switch flow table) are forwarded to the server <NUM> which typically will use the appropriate decryption key (being based on the credentials provided to the TEE <NUM> in step S106) to produce a plaintext version of the data packets P3,. , Pn, which are now in the required MQTT format.

Optionally, in step S114, the SDN switch <NUM> will terminate the TEE <NUM> even though it may be envisaged that the SDN switch <NUM> will await further data to be communicated between the client <NUM> and the server <NUM> (i.e. from the client <NUM> to the server <NUM> or from the server <NUM> to the client <NUM>). Alternatively, the TEE <NUM> is terminated after a set termination timer has expired, or after the SDN switch <NUM> receives an external termination command for the TEE <NUM>, for example from the SDN controller <NUM>.

This embodiment provides a number of advantages over the prior art. Firstly, secure and fast in-line protocol translation of encrypted network traffic is enabled. Secondly, communication between devices using different application layer protocols is enabled while maintaining latency requirements. Thirdly, protocol translation of encrypted network traffic is enabled without creating a single point of failure. Fourthly, massive secure machine-to-machine communication may be attained by enabling a distributed protocol translation mechanism being able to dynamically adapt to new devices and network topologies, where a translation mechanism is created for each pair of endpoints being involved rather than providing a central back-end for all traffic as previously discussed with reference to <FIG>.

As illustrated in <FIG>, the created TEE <NUM> is located inside the SDN switch <NUM>, while the SDN controller <NUM> hosts an internal CA <NUM>. Many alternative variants may be envisaged.

As illustrated in <FIG>, the SDN switch <NUM> or the SDN controller <NUM> creates (S103) the TEE <NUM> as an external entity, separate from the switch <NUM>, to which external TEE <NUM> the SDN switch <NUM> forwards (S110) encrypted packets in a first protocol format for decryption (S111a), translation into a second protocol format (S111b) and re-encryption (S111c) before the packets are returned (S112) to the SDN switch <NUM>.

In the configuration of <FIG>, the CA <NUM> is arranged externally from the SDN controller <NUM>. Thus, upon successful attestation of the TEE <NUM>, the external CA <NUM> will deliver the cryptographic credentials to the SDN controller <NUM> over a secure channel, and the SDN controller <NUM> will in its turn supply the received cryptographic credentials to the TEE <NUM> over yet another secure channel.

<FIG> illustrates a network device <NUM> according to an embodiment, such as an SDN controller, where the steps of the method performed by the network device <NUM> in practice are performed by a processing unit <NUM> embodied in the form of one or more microprocessors arranged to execute a computer program <NUM> downloaded to a storage medium <NUM> associated with the microprocessor, such as a Random Access Memory (RAM), a Flash memory or a hard disk drive. The processing unit <NUM> is arranged to cause the network device <NUM> to carry out the method according to embodiments when the appropriate computer program <NUM> comprising computer-executable instructions is downloaded to the storage medium <NUM> and executed by the processing unit <NUM>. The storage medium <NUM> may also be a computer program product comprising the computer program <NUM>. Alternatively, the computer program <NUM> may be transferred to the storage medium <NUM> by means of a suitable computer program product, such as a Digital Versatile Disc (DVD) or a memory stick. As a further alternative, the computer program <NUM> may be downloaded to the storage medium <NUM> over a network. The processing unit <NUM> may alternatively be embodied in the form of a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), etc. The network device <NUM> further comprises a communication interface <NUM> (wired or wireless) over which the network device <NUM> is configured to transmit and receive data.

The network device <NUM> of <FIG>, being exemplified as an SDN controller, may be provided as a standalone device or as a part of at least one further device. For example, the network device <NUM> may be provided in a network node such as the SDN controller. Alternatively, functionality of the network device <NUM> may be distributed between at least two devices, or nodes.

Thus, a first portion of the instructions performed by the network device <NUM> may be executed in a first device, and a second portion of the of the instructions performed by the network device <NUM> may be executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the network device <NUM> may be executed.

Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a network device <NUM> residing in a cloud computational environment. Therefore, although a single processing circuitry <NUM> is illustrated in <FIG>, the processing circuitry <NUM> may be distributed among a plurality of devices, or nodes. The same applies to the computer program <NUM>. Embodiments may be entirely implemented in a virtualized environment.

The aspects of the present disclosure have mainly been described above with reference to a few embodiments and examples thereof. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

Claim 1:
A method of a network device (<NUM>) of enabling communication protocol translation for encrypted data traffic between a first device (<NUM>) and a second device (<NUM>), comprising:
receiving (S101), from the first device (<NUM>), data intended for the second device (<NUM>);
triggering creation (S103) of a trusted execution environment (<NUM>), TEE;
requesting (S104) attestation of the created TEE (<NUM>) from a trusted central device (<NUM>) having access to a certificate authority (<NUM>), CA, performing the attestation;
receiving (S106), over a secure communication channel established with the trusted central device (<NUM>) upon successful attestation (S105), protocol translation instructions and cryptographic credentials required for securely communicating with the first device (<NUM>) and the second device (<NUM>);
decrypting (S111a), in the TEE (<NUM>), any received (S109) encrypted data from the first device (<NUM>) using the received cryptographic credentials, translating (S111b) the decrypted data from a first protocol format utilized by the first device into a second protocol format utilized by the second device (<NUM>) in the TEE (<NUM>) based on the received translation instructions, and encrypting (S111c) the translated data in the TEE (<NUM>) using the received cryptographic credentials, the credentials being configured to allow the second device (<NUM>) to decrypt the encrypted translated data; and
sending (S113) the encrypted translated data to the second device (<NUM>).