METHOD AND COMMUNICATION UNIT FOR CRYPTOGHRICALLY PROTECTED UNIDIRECTIONAL DATA TRANSFER OF USER DATA BETWEEN TWO NETWORKS

Description

[0001] The invention relates to a method for cryptographically protected unidirectional data transmission of user data (e.g. data of a field device) between a first network with a first security requirement and a second network with a second security requirement that differs from the first network, as well as an associated communication unit and computer program product.

[0002] For secure communication between a safety-critical network and an open network, such as an industrial control network (or operational network) and a conventional IT network, one-way communication units, such as data diodes, can be used to enable unidirectional, non-reactive data transmission. A data diode with a feedback channel, also known as a bidirectional network guard or security gateway, enables secure data transfer between two information environments with different security levels. A network guard is typically a combination of hardware and software and offers more functionality than firewalls, thus providing a higher level of protection than conventional firewalls. In particular, non-reactive communication can be guaranteed at the hardware level, ensuring that this property is maintained even in the event of a software malfunction.

[0003] A bidirectional network guard is typically designed to implement two separate unidirectional data streams, each using a data diode, with the data streams flowing in opposite directions. This allows data exchange in both directions, ensuring one-way functionality in each direction. For example, a bidirectional network guard can transmit data from a high-security network to a second, open network with low security requirements, or vice versa. The security requirements can relate to integrity, availability, and / or confidentiality.Industrial control networks often have extremely high requirements for integrity and availability, which must be reliably met even when coupled with a factory network, an office network, or a public network.

[0004] When transferring data from a network with low security requirements to a network with high security requirements, additional checks are usually necessary to ensure the integrity and / or security of the network with high security requirements and / or network availability.

[0005] Conventional end-to-end encryption, for example using security protocols like IKEv2 / IPsec or TLS, is not feasible between a device, such as a field device in the first network, and a communication unit in the second network. This is because a session context – for example, via common handshake mechanisms – cannot be established over the unidirectional data transfer path.

[0006] On the device side, special unidirectional gateway protocols must be used. This means that previously used protocols (e.g., MQTT) must be replaced for use with the unidirectional connection and implemented via the protocol proxy. Integrating the unidirectional network connection (e.g., via a Data Capturing Unit, DCU) is therefore not possible without adapting the device's implementation and protocol stack.

[0007] From DE 10 2017 212 474 A1, a method for checking connection parameters is known, in which, during the establishment of a cryptographically protected communication connection between a first communication device and a second communication device ( i ) an attestation data structure which contains at least one connection parameter of the first and / or second communication device as attestation information, is sent from the first and / or second communication device to the second and / or first communication device, ( two ) the attestation data structure is intercepted by a monitoring device located within the data transmission path of the communication link and ( three ) the attestation information is checked against a given guideline.

[0008] From DE 10 2015 200 279 A1, a method is known for the non-reactive acquisition of data that is cryptographically protected and transmitted between devices in a first network with high security requirements and is intercepted by a one-way transmission device in a second network with low security requirements. In this process, ( i ) at least one cryptographic parameter negotiated between the communicating devices in the first network for use in subsequent communication, ( two ) a transmission structure in at least one of the devices, in which at least some of the negotiated cryptographic parameters are contained, is generated and transmitted within the first network and ( three ) the transmission data structure is intercepted by a one-way transmission device and transmitted to the second network.

[0009] It is therefore an object of the present invention to create a solution for unidirectional data transmission between two networks with different security requirements that is improved compared to the prior art mentioned at the outset.

[0010] The problem is solved by the measures described in the independent claims. Advantageous embodiments of the invention are presented in the dependent claims. The invention claims a method for cryptographically protected unidirectional data transmission of user data (e.g., data from the field device), in particular between a first network with a first security requirement and a second network with a second security requirement that differs from that of the first network, wherein one or more data packets containing the user data are transmitted on an end-to-end data transmission path from a first communication unit (e.g. client) in a first network via a one-way communication unit (e.g. DCU) located between the first network and a second network to a second communication unit in the second network, exhibiting the following procedural steps: I. Establishing or negotiating at least one cryptographic parameter between the first communication unit and a third communication unit in the first network for the cryptographically protected, preferably unidirectional, data transmission of user data from the first communication unit to the second communication unit; II. Generating at least one transmission data structure containing at least some of the negotiated cryptographic parameters for the cryptographically protected data transmission of the data packet or containing several data packets; III. Encrypting the at least one transmission data structure with a key (preferably a public key) of the second communication unit; IV. Transmitting the encrypted at least one transmission data structure to the second communication unit in the second network; V. Decrypting the encrypted at least one transmission structure; VI.Encrypting the user data to be transmitted to the second communication unit with the negotiated cryptographic parameters and transmitting the encrypted user data to the second communication unit, and VII. Decrypting the transmitted user data with the cryptographic parameters contained in the decrypted transmission structure.

[0011] Step I can be implemented between the first communication unit and a virtual communication unit in the first network, preferably on the first communication unit. The cryptographic parameter represents or comprises a session parameter, which includes a cryptographic session key.

[0012] Step VI can be routed via the one-way communication unit. Encryption refers to cryptographic protection where the integrity of the user data is protected by a cryptographic checksum (Message Authentication Code, digital signature), or where the user data is encrypted, or where the integrity and confidentiality of the user data are protected by authenticated encryption.

[0013] A third virtual communication unit can be placed upstream of the one-way communication unit, which performs steps II, III and IV of claim 1. (Steps II and / or III and / or IV can also be performed by the first communication unit).

[0014] The Datagram Transport Layer Security (DTLS) data transmission protocol can be used on the partial transmission path between the first communication unit and the third communication unit.

[0015] Another communication unit, prior to the second communication unit, can execute step V using the cryptographic parameters from the transmission structure (steps VI and VII can be performed by the second communication unit).

[0016] The at least one cryptographic parameter results from the authentication and key agreement and can include a session key, a cipher suite, a security token, a signature, and / or a certificate. The authentication and key agreement preferably takes place between the first communication unit using a credential (certificate, private, or secret key) of the first communication unit and a third or virtual communication unit using a pseudo-credential. The pseudo-credential is a generally known credential, which is also known to the second communication unit. It serves to implement a conventional bidirectional authentication and key exchange protocol locally (on the first device or at least with a device prior to the one-way communication unit).Depending on the protocol messages exchanged during the execution of the bidirectional authentication and key exchange protocol, the transmission data structure is formed and encrypted with a private credential of the second communication unit. This ensures that, after transmission via the one-way communication unit, only the second communication unit can decrypt the encrypted transmission data structure. However, the first communication unit can still use a conventional bidirectional authentication and key exchange protocol to ultimately establish a session key with the unidirectionally reachable communication unit.

[0017] The method according to the invention is preferably computer-implemented. In the context of the invention, "computer-implemented" can be understood as an implementation of the method in which, in particular, a processor performs at least one method step.

[0018] The invention provides that an IoT device / field device can perform end-to-end protected unidirectional data transmission to a target server (IoT backend, IoT edge gateway) via a one-way communication link, with a session key being dynamically established. No further adaptation of a transmission protocol is necessary. The transmitted data packets are cryptographically protected, thus enabling end-to-end protection. In addition to improved data transmission security, this has the further advantage that a very simple, and therefore inexpensive and reliable, one-way communication unit can be used. Furthermore, the same type of transmission can occur regardless of whether a one-way communication unit is present or not. Therefore, a one-way communication unit can also be easily retrofitted if required.

[0019] The DTLS security protocol can be used in such a way that it is purely unidirectional. This version of DTLS can also be referred to as UDTLS (unidirectional DTLS).

[0020] This allows user data to be transmitted cryptographically protected based on existing session context information. The challenge is that the DTLS session context (especially cryptographic session keys, selected cipher suite, protocol options) must be initialized during session establishment.

[0021] Traditional secure communication protocols can still be used to encrypt user data (especially a DTLS Record Layer or alternatively SRTP (Secure Real-time Transport Protocol) or IKEv2 / IPsec (Internet Key Exchange, IP security).

[0022] This data can be used directly, i.e. .without protocol conversion and therefore directly, via a one-way communication link (e.g. . Data diode, restrictively configured firewall that blocks, for example, all incoming data packets).

[0023] A transmission device is suitable for cryptographically protected unidirectional data transmission of user data between a first network and a second network, wherein one or more data packets containing the user data are transmitted on an end-to-end data transmission path from a first communication unit in the first network to a second communication unit in the second network, comprising: a provisioning unit for providing or generating at least one transmission data structure containing at least partially negotiated cryptographic parameters for cryptographically protected data transmission, an encryption unit for encrypting the at least one transmission data structure with a (public) key of a second communication unit in the second network, a transmission unit for transmitting the encrypted at least one transmission data structure to the second communication unit in the second network, an encryption unit for encrypting the user data to be transmitted to the second communication unit with the (with a)the cryptographic parameters negotiated by the aforementioned virtual communication unit and the transmission of the encrypted user data to the second communication unit (by a first communication unit in the first network or this virtual communication unit).

[0024] According to a further aspect, the invention relates to an arrangement comprising the transmission device of the type mentioned above and the decryption device of the type mentioned above, additionally comprising: at least one communication session unit for setting or negotiating at least one cryptographic parameter for the cryptographically protected data transmission of user data from the first communication unit to another communication unit.

[0025] An arrangement comprising the aforementioned communication unit and the aforementioned virtual communication unit additionally exhibits: at least one communication session unit for setting / negotiating at least one cryptographic parameter for the cryptographically protected data transmission of user data from the first communication unit to another communication unit.

[0026] A one-way communication unit is suitable for cryptographically protected unidirectional data transmission, via which user data is transmitted between a first network with a first security requirement and a second network with a second security requirement that differs from the first network, comprising a transmission device of the type mentioned above.

[0027] A unit or component, in particular a communication unit or network component, can be designed as a hardware component. A component can, in particular, include a processor. A processor can, in particular, be a central processing unit (CPU), a microprocessor, or a microcontroller, for example, an application-specific integrated circuit or a digital signal processor, possibly in combination with a memory unit for storing program instructions, etc. A processor can also, for example, be an integrated circuit (IC) or a multi-chip module, in particular an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit).The processor in question may be an application-specific integrated circuit (ASC), a system-on-a-chip (SoC), a graphics processing unit (GPU), a processor for evaluating a neural network such as a tensor processing unit (TPU), or a digital signal processor (DSP). The processor may have one or more processing cores (multi-core). A processor can also be a virtualized processor or a soft CPU. It may, for example, be a programmable processor equipped with configuration steps for executing the method according to the invention, or configured with configuration steps such that the programmable processor implements the features of the method or other aspects and sub-aspects of the invention. The processor may have tamper protection to protect against physical manipulation, e.g.,Tamper sensors for detecting physical attacks.

[0028] Furthermore, the invention relates to a computer program product that can be directly loaded into a programmable computer, comprising program code parts suitable for carrying out the steps of a computer-implemented method according to the invention.

[0029] A computer program product, such as a computer program tool, can be provided or delivered as a storage medium or data carrier, such as a memory card, USB stick, CD-ROM, DVD or in the form of a downloadable file from a server in a network.

[0030] Exemplary embodiments of the computer-implemented method and the transmission device according to the invention are shown in the drawings and are explained in more detail below. The drawings show: Fig. 1: a schematic representation of the interaction of the communication units or devices according to the invention and Fig. 2: a flowchart of a procedure according to the invention.

[0031] Corresponding parts are marked with the same reference symbols in all figures.

[0032] In particular, the following embodiments merely show exemplary implementation possibilities of how such implementations of the teaching according to the invention could look, since it is impossible and also not helpful or necessary for understanding the invention to name all these implementation possibilities.

[0033] Furthermore, a person skilled in the art, particularly with knowledge of the method claim(s), will of course be aware of all the possibilities for realizing the invention that are customary in the prior art, so that a separate disclosure in the description is not necessary. In particular, these common implementation variants known to the person skilled in the art can be implemented exclusively by hardware (components) or exclusively by software (components). Alternatively and / or additionally, the person skilled in the art can, within the scope of their professional expertise, choose virtually any combination of hardware (components) and software (components) according to the invention in order to implement the invention.

[0034] Figure 1 shows the interaction of the communication units according to the invention.

[0035] Two networks, NW1 and NW2, are shown as examples. Network NW1 may have different security requirements compared to the second network, NW2. Network NW1 could, for example, correspond to a factory network, while network NW2 could be a remote network for diagnostics, such as predictive maintenance, of the components / units of network NW1. Network NW1 contains a first communication unit FD, which can be configured as a field device or IoT device. This field device includes a client unit C or component, which could, for example, be configured as a type of communication session unit. This communication session unit can have at least one cryptographic parameter for cryptographically protected data transmission of payload (PL) from the first communication unit to another communication unit.The third communication unit is preferably a virtual communication unit (vSrv). Furthermore, a second communication unit, which can be configured as a remote server (rSrv), is located in the NW2 network.

[0036] Therefore, in the designated step 1, a handshake (HS) is performed (e.g., a DTLS handshake, DTLS = Datagram Transport Layer Security). This means that the communication context and / or one or more cryptographic parameters are negotiated or defined with a local, virtual communication unit (vSrv). This involves bidirectional communication. The sender, here the first communication unit (C), initiates a DTLS handshake with a virtual DTLS endpoint or server, in this example the virtual communication unit (vSrv), which is preferably implemented on the same hardware as the client (C). However, a hardware security module connected to client (C) or another communication node can also be used. A generally known pseudo-credential can be used for authenticating the virtual server.It does not serve here for the actual authentication of the DTLS endpoint, but is present virtually to enable a (bidirectional) DTLS handshake. In all embodiments, the virtual communication unit vSrc is a one-way communication unit DCU, e.g., a one-way gateway, a data diode, or a non-reactive data capture unit (DCU). http: / / www.siemens.com / dcu ), upstream, i.e., the DTLS handshake takes place locally from a technical point of view without being transmitted via the one-way communication unit.

[0037] However, a recorded handshake, or more generally, information derived from it, is transmitted as handshake information (HSInfo) via the one-way communication unit to the server rSrv, enabling the server rSrv to decrypt the encrypted payload (PL - Record Layer) also transmitted to it. A generally known key pair (public key PubK and private key PK) is used for this purpose by the virtual communication unit vSrv. Furthermore, a generally known cryptographic parameter, such as a Diffie-Hellman random value, can be used for the virtual communication unit vSrv. The virtual communication unit vServ can combine the functions of both the client C and a DTLS server, thus establishing a DTLS session "with itself." This allows existing DTLS implementations to be used without special modifications.

[0038] Information from the DTLS session (DTLS session) or DTLS handshake is now determined on client C and transmitted unidirectionally to the actual target server (rSrv), in this example the second communication unit rSrv. A communication session device, preferably implemented on client C (not explicitly shown in the figure), can generate and / or provide a transmission data structure called handshake information HSInfo. The handshake information HSInfo essentially contains the information about the key exchange (handshake) between client C and the virtual communication unit vSrv.

[0039] Preferably, the handshake information HSInfo is encrypted by an encryption unit not explicitly shown in the virtual communication unit vSrv and / or digitally signed by client C before being transmitted to the actual target server, in this example server rSrv. A public key rSrv PubK or a digital certificate of client C is used for encryption. The signature can be provided by the sending node (the sender, e.g., client C, or the virtual communication unit vSrv) or by both.

[0040] In one embodiment, the handshake information (HSInfo variant) is recorded and completely packaged into a transmission data structure and transmitted unidirectionally to the second communication unit (rSrv). In another embodiment, not the entire handshake information (HSInfo), but rather the resulting security session context (e.g., session key, cipher suite) is transmitted. Preferably, the handshake information (HSInfo) is transmitted to the second communication unit (rSrv) immediately after completion of the DTLS handshake. In one embodiment, further handshake information (HSInfo) is transmitted after a DTLS session key update. This has the advantage that the received, encrypted DTLS data (records) can be decrypted immediately using the handshake information. In another embodiment, HSInfo is transmitted to the second communication unit (rSrv) with a time delay.This can occur after the DTLS session between client C and the virtual communication unit vSrv has ended, and / or after a key update has taken place. This has the advantage that the second communication unit rSrv can only decrypt the data subsequently; that is, during the encrypted data transmission between client C and the virtual communication unit vSrv, the data cannot be intercepted or manipulated.

[0041] The actual endpoint, in this example the second communication unit, receives the handshake information and establishes the security session context agreed upon by client C with the virtual communication unit vSrv. That is, it establishes a DTLS session context that corresponds to the received handshake information HSInfo. This allows it to decrypt the received user data and verify its integrity.

[0042] The transmission of encrypted user data is preferably handled by the virtual communication unit vSrv to the second communication unit rSrv. This has the advantage that a regular, unmodified client C can be used on the first communication unit. Only a special communication unit vSrv is required on the (field) device FD, which receives the encrypted user data (DTLS Record Layer) along with the handshake information HSInfo and forwards it without processing to the actual receiver, in this example the second communication unit rSrv. Since the device FD performs both functions (client C and virtual communication unit vSrv), the encrypted transmission of a DTLS record from the sender (C) to the actual receiver (rSrv) is end-to-end protected.

[0043] The DTLS session is particularly useful for securely transmitting IoT protocol messages such as MQTT publish messages or CoAP messages.

[0044] In another embodiment, the virtual communication unit (vSrv) is implemented on a separate computer as a central component in the plant (factory network). This allows multiple field devices (FD) to send data to the second communication unit (rSrv) via the virtual communication unit (vSrv) acting as a proxy. The proxy can also implement additional useful functionality such as NAT (for forwarding to the second communication unit, rSrv). The key advantage of this embodiment is that the field device implementation does not need to be modified, and scaling effects can be achieved. Furthermore, the transmission path between the first network (e.g., the factory network) from the virtual communication unit (vSrv) and the actual receiver (second communication unit, rSrv) is end-to-end protected.

[0045] Figure 2Figure 1 shows a flowchart of a procedure according to the invention, wherein the individual steps are marked with the numbers 11 to 25.

[0046] The sending (field) device FD is configured with an address (IP address, DNS name, URL) of the target server, in this example the second communication unit rSrv, and an associated cryptographic key, in this example a public key rSrv PubK, a digital certificate vSrv cert, and a private key vSrv PK. Furthermore, the field device FD can have a client certificate FD cert and a client key FD PK.

[0047] The field device FD can implement a virtual communication unit (vSrv). This unit uses cryptographic parameters. The actual client C, acting as a DTLS client, establishes a DTLS session with its internal virtual communication unit (vSrv) (see step 11). From a protocol perspective, this session can be bidirectionally authenticated (DTLS HS) (one-way authentication or no authentication at all is also possible). As a result, a shared security session context (e.g., session key and cipher suite corresponding to the handshake information HSInfo) is established for the DTLS client and the virtual communication unit (see step 12). The handshake information HSInfo is encrypted with the public key rSrv PubK of the second communication unit rSrv (step 13) and transmitted to it (steps 14 and 15). Preferably, it is also signed by the client, i.e., with its private key FD PK.Another virtual communication unit on the second communication unit rSrv decrypts the handshake info HSInfo (step 16) and sets up the security session context with the decrypted HSInfo (step 17) (step 18).

[0048] After this setup phase, the security session context (according to HSInfo) is available on the second communication unit, rSrv, a further virtual communication unit. If the field device FD client now sends a data packet (step 19), this packet can be encrypted (step 20) and sent to the second communication unit, rSrv (steps 22, 23), where it can be decrypted (step 24) and processed (step 25). The key feature is that communication between the field device FD and the second communication unit, rSrv, is purely unidirectional. A one-way gateway (DCU, data capture unit) only forwards the data packet(s) from the field device FD (step 21) to the second communication unit, rSrv, but not in the opposite direction.

[0049] In one embodiment, a secret pre-shared key (PSK cipher suite) is used for negotiating the DTLS session (DTLS handshake). In another embodiment, an unauthenticated DTLS handshake takes place.

[0050] Although the invention has been illustrated and described in detail by the preferred embodiment, the invention is not limited by the disclosed examples and other variations can be derived by the person skilled in the art without leaving the scope of protection of the invention.

[0051] The implementation of the processes or procedures described above can be carried out using instructions stored on computer-readable storage media or in volatile computer memory (hereinafter collectively referred to as computer-readable memory). Examples of computer-readable memory include volatile memory such as caches, buffers, or RAM, as well as non-volatile memory such as removable media, hard drives, etc.

[0052] The functions or steps described above can be represented in the form of at least one instruction set in / on computer-readable memory. These functions or steps are not bound to a specific instruction set, a specific form of instruction sets, a specific storage medium, a specific processor, or specific execution schemes, and can be executed by software, firmware, microcode, hardware, processors, integrated circuits, etc., either independently or in any combination. Various processing strategies can be employed, such as serial processing by a single processor, multiprocessing, multitasking, or parallel processing, etc.

[0053] The instructions can be stored in local memory, but it is also possible to store the instructions on a remote system and access them via a network.

[0054] The transmission device may include one or more processors. The terms "processor," "central signal processing," "control unit," or "data processing device" encompass processing means in the broadest sense, such as servers, general-purpose processors, graphics processors, digital signal processors, application-specific integrated circuits (ASICs), programmable logic circuits such as FPGAs, discrete analog or digital circuits, and any combination thereof, including all other processing means known to those skilled in the art or which may be developed in the future. Processors may consist of one or more devices, units, or components. If a processor consists of multiple devices, these may be designed or configured for parallel or sequential processing or execution of instructions.

Claims

1. Method for the cryptographically protected unidirectional data transmission of user data, wherein one or more data packets comprising the user data are transmitted on an end-to-end data transmission path from a first communication unit (C) in a first network (NW1), via a one-way communication unit (DCU) arranged between the first network (NW1) and a second network (NW2), to a second communication unit (rSrv) in the second network (NW2), comprising the following method steps: I. negotiating at least one cryptographic parameter between the first communication unit (C) and a third communication unit (vSrV) in the first network (NW1) for the cryptographically protected data transmission of user data from the first communication unit to the second communication unit, II. generating at least one transmission data structure (HSinfo) containing at least partially the negotiated cryptographic parameters for the cryptographically protected data transmission of the data packet or of the plurality of data packets, III. encrypting the at least one transmission data structure with a key of the second communication unit, IV. transmitting the encrypted, at least one transmission data structure to the second communication unit in the second network, V. decrypting the encrypted, at least one transmission structure, VI. encrypting the user data to be transmitted to the second communication unit with the negotiated cryptographic parameters and transmitting encrypted user data to the second communication unit, and VII. decrypting the transmitted user data with the cryptographic parameters contained in the decrypted transmission structure.

2. Method according to the preceding claim, characterized in that a third communication unit (vSrV) is arranged upstream of the one-way communication unit and carries out steps II, III and IV of Claim 1.

3. Method according to one of the preceding claims, characterized in that the data transmission protocol Datagram Transport Layer Security, abbreviated DTLS, is used on the partial transmission path between the first communication unit and the third communication unit.

4. Method according to one of the preceding claims, characterized in that a further communication unit (vSrv) arranged upstream of the second communication unit carries out step V with the aid of the cryptographic parameters from the transmission structure.

5. Method according to one of the preceding claims, characterized in that the at least one cryptographic parameter comprises a session key, a cipher suite, signature and / or certificate.

6. Method according to one of the preceding claims, in which the method is computer-implemented.

7. Arrangement for carrying out the method according to one of Claims 1 to 6.

8. Computer program product which can be loaded directly into a programmable computer, comprising program code parts that are suitable for carrying out the steps of the computer-implemented method according to Claim 6.