EP3767909B1 - Method and communication unit for cryptographically protected unidirectional data transmission of useful data between two networks - Google Patents

Description

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 is different from the first network, as well as an associated communication unit and computer program product.

For secure communication between a safety-critical and an open network, such as an industrial control network (or operational network) and a classic IT network, one-way communication units such as data diodes can be used to enable unidirectional, non-interference-free 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 areas with different security levels. A network guard is usually a combination of hardware and software and enables more functionality than firewalls, which means a higher level of protection can be achieved than with conventional firewalls. In particular, the non-interference-free nature can be guaranteed on a hardware basis, so that this property is retained even in the event of a software malfunction.

A bidirectional Network Guard is usually designed to realize 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, whereby the one-way function is guaranteed in each case. For example, with a bidirectional Network Guard, data can be transmitted from a first network with high security requirements to a second open network with low security requirements or from a network with low security requirements to a network with high security requirements. The security requirement can particularly relate to integrity and/or availability and/or confidentiality. Industrial control networks often have extremely high requirements for integrity and availability, which must also be reliably met when coupled to a factory network, an office network or a public network.

When transferring data from the network with low security requirements to the network with high security requirements, additional testing is usually necessary to ensure the integrity and/or security of the network with high security requirements and/or the network availability.

Conventional end-to-end encryption, for example with security protocols such as IKEv2/IPsec or TLS, cannot be implemented between a device, e.g. a field device in the first network, and a communication unit in the second network. The reason for this is that a session context cannot be established over the unidirectional transfer path - for example using common handshake mechanisms.

Special unidirectional gateway protocols must be used on the device side. This means that previously used protocols (e.g. MQTT) must be replaced for the use of the unidirectional route and implemented via the protocol proxy. An integration of the unidirectional network connection (e.g. via a data capturing unit, DCU) is therefore not possible without adapting the implementation and the protocol stack of the device.

From the 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 containing at least one connection parameter of the first and/or second communication device as attestation information is received from the first and/or
or second communication devices to the second and/or first communication device, ( ii ) the attestation data structure is monitored by a monitoring device arranged within the data transmission path of the communication connection and ( iii ) the attestation information is checked against a predetermined guideline.

From the DE 10 2015 200 279 A1 A method is known for the non-reactive detection of data that is transmitted in a cryptographically protected manner between devices in a first network with high security requirements and is monitored by a one-way transmission device in a second network with low security requirements. In this case, ( i ) at least one cryptographic parameter is negotiated between the communicating devices in the first network for use in subsequent communication, ( ii ) a transmission structure in at least one of the devices, which at least partially contains the negotiated cryptographic parameters, is generated and transmitted within the first network and ( iii ) the transmission data structure is monitored by a one-way transmission device and transmitted to the second network.

It is therefore an object of the present invention to provide a method for the production of improved solution for unidirectional data transfer between two networks with different security requirements.

• ein oder mehrere die Nutzdaten umfassenden Datenpakete auf einer Ende-zu-Ende-Datenübertragungsstrecke von einer ersten Kommunikationseinheit (z.B. Client) in einem ersten Netzwerk über eine Einwegkommunikationseinheit (z.B. DCU), die zwischen dem ersten Netzwerk und einem zweiten Netzwerk angeordnet ist, an eine zweite Kommunikationseinheit im zweiten Netzwerk übertragen werden,

aufweisend folgende Verfahrensschritte:

1. I. Festlegen bzw. Aushandeln von mindestens einem kryptographischen Parameter zwischen der ersten Kommunikationseinheit und einer dritten Kommunikationseinheit im ersten Netzwerk für die kryptographisch geschützte, vorzugsweise unidirektionale Datenübertragung von Nutzdaten von der ersten Kommunikationseinheit zur zweiten Kommunikationseinheit,
2. II. Erzeugen zumindest einer Übertragungsdatenstruktur, in der zumindest teilweise die ausgehandelten kryptographischen Parameter für die kryptographisch geschützte Datenübertragung des Datenpakets oder in der mehreren Datenpakete enthalten sind,
3. III. Verschlüsseln der zumindest einen Übertragungsdatenstruktur mit einem Schlüssel (vorzugsweise öffentlichen Schlüssel) der zweiten Kommunikationseinheit,
4. IV. Übertragen der verschlüsselten, zumindest einen Übertragungsdatenstruktur zur zweiten Kommunikationseinheit im zweiten Netzwerk,
5. V. Entschlüsseln der verschlüsselten, zumindest einen Übertragungsstruktur,
6. VI. Verschlüsseln der zur zweiten Kommunikationseinheit zu übertragenden Nutzdaten mit den ausgehandelten kryptographischen Parametern und Übertragen der verschlüsselten Nutzdaten zur zweiten Kommunikationseinheit, und
7. VII. Entschlüsseln der übertragenen Nutzdaten mit den in der entschlüsselten Übertragungsstruktur enthaltenen kryptographischen Parametern.

The object is achieved by the measures described in the independent claims. Advantageous developments of the invention are presented in the dependent claims. The invention claims a method for cryptographically protected unidirectional data transmission of user data (eg data of the field device), in particular between a first network with a first security requirement and a second network with a second security requirement that is different from the first network, wherein

• one or more data packets comprising the payload 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) arranged between the first network and a second network to a second communication unit in the second network,

comprising the following process steps:

1. I. Specifying 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,
2. II. Generating at least one transmission data structure which at least partially contains the negotiated cryptographic parameters for the cryptographically protected data transmission of the data packet or in which several data packets are contained,
3. III. Encrypting the at least one transmission data structure with a key (preferably public key) of the second communication unit,
4. IV. Transmitting the encrypted, at least one transmission data structure to the second communication unit in the second network,
5. V. Decrypting the encrypted, at least one transmission structure,
6. VI. Encrypting the payload data to be transmitted to the second communication unit with the negotiated cryptographic parameters and transmitting the encrypted payload data to the second communication unit, and
7. VII. Decrypting the transmitted payload data using the cryptographic parameters contained in the decrypted transmission structure.

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 that comprises a cryptographic session key.

Step VI can be routed via the one-way communication unit. Encryption refers to cryptographic protection in which the integrity of the payload is protected by a cryptographic checksum (message authentication code, digital signature) or in which the payload is encrypted or in which the integrity and confidentiality of the payload is protected by authenticated encryption.

A third virtual communication unit can be arranged upstream of the one-way communication unit, which carries out steps II, III and IV of claim 1. (Step II and/or III and/or IV can also be carried out by the first communication unit).

The data transmission protocol Datagram Transport Layer Security, abbreviated DTLS, can be used on the partial transmission path between the first communication unit and the third communication unit.

A further communication unit arranged upstream of the second communication unit can carry out step V using the cryptographic parameters from the transmission structure (steps VI and VII can be carried out by the second communication unit).

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 certificate. The authentication and key agreement is preferably made 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 that is also known in particular to the second communication unit. It is used to carry out a conventional bidirectional authentication and key exchange protocol locally (on the first device or at least with a device in front of the one-way communication unit). Depending on the protocol messages exchanged when carrying out 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. Nevertheless, the first communication unit can use a conventional bidirectional authentication and key exchange protocol to ultimately to establish a session key with the communication unit that can only be reached unidirectionally.

The method according to the invention is preferably designed to be 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 carries out at least one method step.

The invention provides that an IoT device/field device can carry out an end-to-end protected unidirectional data transmission via a one-way communication link to a target server (IoT backend, IoT edge gateway), whereby a session key is set up dynamically. No further adaptation of a transmission protocol is necessary. The transmitted data (packets) are cryptographically protected so that end-to-end protection can be implemented. In addition to the improved security of the data transmission, 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 take place 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.

For this purpose, the DTLS security protocol (DTLS Security Protocol) can be used in such a way that it can be used purely unidirectionally. This form of DTLS can also be referred to as UDTLS (unidirectional DTLS).

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

Conventional secure communication protocols can continue to be used to encrypt user data (in particular a DTLS record layer or alternatively SRTP (Secure Real-time Transport Protocol) or IKEv2/IPsec (Internet Key Exchange, IP security).

This data can be transmitted directly, i.e. without protocol conversion and thus directly, over a one-way communication path ( e.g. data diode, restrictively configured firewall that blocks all incoming data packets, for example).

• eine Bereitstellungseinheit zum Bereitstellen oder Erzeugen zumindest einer Übertragungsdatenstruktur, in der (die) zumindest teilweise ausgehandelten kryptographischen Parameter für die kryptographisch geschützte Datenübertragung enthalten sind,
• eine Verschlüsselungseinheit zum Verschlüsseln der zumindest einen Übertragungsdatenstruktur mit einem (öffentlichen) Schlüssel einer zweiten Kommunikationseinheit im zweiten Netzwerk,
• eine Übertragungseinheit zum Übertragen der verschlüsselten, zumindest einen Übertragungsdatenstruktur zur zweiten Kommunikationseinheit im zweiten Netzwerk,
• eine Verschlüsselungseinheit zum Verschlüsseln der zur zweiten Kommunikationseinheit zu übertragenden Nutzdaten mit den (mit einer bzw. der oben genannten virtuellen Kommunikationseinheit) ausgehandelten kryptographischen Parametern und Übertragen der verschlüsselten Nutzdaten zur zweiten Kommunikationseinheit (durch eine erste Kommunikationseinheit im ersten Netzwerk oder dieser virtuelle Kommunikationseinheit).

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 comprising 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 provision unit for providing or generating at least one transmission data structure containing at least partially negotiated cryptographic parameters for the 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 payload data to be transmitted to the second communication unit with the cryptographic parameters negotiated (with one or the above-mentioned virtual communication unit) and transmitting the encrypted payload data to the second communication unit (by a first communication unit in the first network or this virtual communication unit).

• zumindest eine Kommunikationssitzungseinheit zum Festlegen bzw. Aushandeln von mindestens einem kryptographischen Parameter, für die kryptographisch geschützte, Datenübertragung von Nutzdaten von der ersten Kommunikationseinheit zu einer weiteren Kommunikationseinheit.

According to a further aspect, the invention relates to an arrangement comprising the transmission device of the above-mentioned type and the decryption device of the above-mentioned type, additionally comprising:

• at least one communication session unit for specifying or negotiating at least one cryptographic parameter for the cryptographically protected data transmission of user data from the first communication unit to a further communication unit.

• zumindest eine Kommunikationssitzungseinheit zum Festlegen/Aushandeln von mindestens einem kryptographischen Parameter, für die kryptographisch geschützte, Datenübertragung von Nutzdaten von der ersten Kommunikationseinheit zu einer weiteren Kommunikationseinheit.

An arrangement comprising the aforementioned communication unit and the aforementioned virtual communication unit additionally comprises:

• at least one communication session unit for specifying/negotiating at least one cryptographic parameter for the cryptographically protected data transmission of payload data from the first communication unit to a further communication unit.

A one-way communication unit is suitable for cryptographically protected unidirectional data transmission via the payload data between a first network with a first security requirement and a second network with a second security requirement that is different from that of the first network, comprising a transmission device of the type mentioned above.

A unit or component, in particular a communication unit or network component, can in particular be designed as a hardware component. A component can in particular comprise a processor. A processor can be, in particular, 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 be, for example, an IC (integrated circuit) or a multi-chip module, in particular an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit), an SoC (system on chip), a graphics processor GPU (graphics processing unit), a processor for evaluating a neural network such as a TPU (tensor processing unit) or a DSP (digital signal processor). The processor can have one or more processing cores (multi-core). A processor can also be understood to be a virtualized processor or a soft CPU. For example, it can also be a programmable processor that is equipped with configuration steps for carrying out the above-mentioned method according to the invention or is configured with configuration steps such that the programmable processor implements the inventive features of the method or other aspects and sub-aspects of the invention. The processor can have tamper protection to protect against physical manipulation, eg tamper sensors to detect physical attacks.

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

A computer program product, such as a computer program tool, may, for example, be Storage medium or data carrier, such as a memory card, USB stick, CD-ROM, DVD or in the form of a downloadable file provided or delivered from a server in a network.

Fig. 1:

eine schematische Darstellung des Zusammenwirkens der erfindungsgemäßen Kommunikationseinheiten bzw. Einrichtungen und

Fig. 2:

ein Ablaufdiagramm eines erfindungsgemäßen Vorgehens.

Embodiments of the computer-implemented method and the transmission device according to the invention are shown as examples in the drawings and are explained in more detail using the following description. They show:

Fig. 1:

a schematic representation of the interaction of the communication units or devices according to the invention and

Fig. 2:

a flow chart of an inventive procedure.

Corresponding parts are provided with the same reference numerals in all figures.

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

In particular, a person skilled in the art, with knowledge of the method claim(s), will of course be aware of all the possibilities for implementing the invention that are customary in the state of the art, so that a separate disclosure in the description is not required. In particular, these customary implementation variants known to the person skilled in the art can be implemented exclusively using hardware (components) or exclusively using software (components). Alternatively and/or additionally, the person skilled in the art can, within the scope of his professional knowledge, You can choose almost any combination of hardware (components) and software (components) according to the invention in order to implement implementation variants according to the invention.

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

Two networks NW1 and NW2 are shown as examples. In this case, the network NW1 can have different security requirements compared to the second network NW2. Network NW1 can, for example, correspond to a factory network and network NW2 can be a remote network for diagnosis, e.g. for predictive maintenance, of the components/units of the network NW1. In network NW 1 there is a first communication unit FD, which can be designed as a field device or IOT device, wherein the field device comprises a client unit C or component, which can, for example, be designed as a type of communication session unit. This communication session unit can have at least one cryptographic parameter for a cryptographically protected data transmission of user data PL (payload) from the first communication unit to a further communication unit. The further or third communication unit is preferably a virtual communication unit vSrv. Furthermore, there is a second communication unit in the NW2 network, which can be designed as a remote server rSrv.

Therefore, in the marked step 1, a handshake HS (eg DTLS handshake, DTLS = Datagram Transport Layer Security), ie the communication context and/or one or more cryptographic parameters are negotiated or defined with a local, virtual communication unit vSrv. Bidirectional communication takes place. The sender, here the first communication unit C, performs a DTLS handshake with a virtual DTLS endpoint or server, in the 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 the authentication of the virtual server. It is not used here for the actual authentication of the DTLS endpoint, but is present virtually in order to be able to carry out a (bidirectional) DTLS handshake. In all embodiments, the virtual communication unit vSrc is arranged upstream of a one-way communication unit DCU, e.g. a one-way gateway, a data diode or also a DCU (non-reactive data capture unit http://www.siemens.com/dcu ), ie from a technical point of view the DTLS handshake takes place locally without being transmitted via the one-way communication unit.

However, a recorded handshake or generally information created as a function of it is transmitted as handshake information HSInfo via the one-way communication unit to the server rSrv, so that the server rSrv can decrypt the encrypted payload data PL (Record Layer) that is also transmitted to it. For this purpose, a generally known key pair (public key PubK and private key PK) is used for the virtual communication unit vSrv. Furthermore, a generally known cryptographic parameter can be used as a Diffie-Hellman random value for the virtual communication unit vSrv. The virtual communication unit vServ can combine both the functions of the client C and the functions of a DTLS server and thus set up a DTLS session "with itself". This means that existing DTLS implementations can be used without special adaptations.

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

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 the client C and transmitted to the actual target server, in the example the server rSrv. A public key rSrv PubK or a digital certificate of the client C is used for encryption. The signature can be made by the providing node (the sender, e.g. client C, or the virtual communication unit vSrv) or by both.

In one embodiment, the handshake information HSInfo variant is recorded and completely packed into a transmission data structure and transmitted unidirectionally to the second communication unit rSrv. In another embodiment, not the entire handshake information HSInfo is transmitted, but rather the resulting security session context (e.g. session key, cipher suite). 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 HS-Info is transmitted after a DTLS session key update. This has the advantage that the handshake information can be used to immediately decrypt the received, encrypted DTLS data (records). In another embodiment, HS-Info is transmitted to the second communication unit rSrv. This can be done after the DTLS session between the 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 afterwards, ie the data cannot be listened to or manipulated during the encrypted data transmission between the client C and the virtual communication unit vSrv.

The actual endpoint, in the example the second communication unit, receives the handshake information and sets up the security session context agreed between client C and the virtual communication unit vSrv. This means that it sets up a DTLS session context that corresponds to the received handshake information HSInfo. This enables it to decrypt the received payload data and check its integrity.

The virtual communication unit vSrv preferably sends the encrypted payload data 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 payload data (DTLS record layer) in addition to the handshake information HSInfo and forwards it to the actual recipient, in the example the second communication unit rSrv, without processing. Since the device FD implements both functions (client C and virtual communication unit vSrv), the encrypted transmission of a DTLS record from the sender (C) to the actual recipient (rSrv) is end-to-end protected.

In particular, IoT protocol messages such as MQTT publish messages or CoAP messages can be transmitted securely via the DTLS session.

In a further embodiment, the virtual communication unit vSrv is implemented on a separate computer as a central component in the system (factory network). This allows several field devices FD to send data to the second communication unit rSrv via the virtual communication unit vSrv as a proxy. The proxy can also implement another useful functionality such as NAT (for forwarding to the second communication unit rSrv). The main advantage of this embodiment is that the field device-side implementation does not have to be adapted and scaling effects can be achieved. Nevertheless, the transmission path between the first network (e.g. factory network) of the virtual communication unit vSrv and the actual receiver (second communication unit rSrv) is protected end-to-end.

Figure 2 shows a flow chart of a procedure according to the invention, wherein the individual steps are marked with the numbers 11 to 25.

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

A virtual communication unit vSrv can be implemented in the field device FD. This uses cryptographic parameters. The actual client C, as a DTLS client, establishes a DTLS session to its internal virtual communication unit vSrv (see step 11). From the DTLS HS protocol perspective, this can be authenticated on both sides (one-sided authentication or no authentication at all is also possible). The result is a common security session context (e.g. session key and cipher Suite according to the handshake information HSInfo) is set up 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, ie with its private key FD PK. Another virtual communication unit on the second communication unit rSrv decrypts the handshake information HSInfo (step 16) and sets up the security session context with the decrypted HSInfo (step 17) (step 18).

After this setup phase, the security session context (corresponding to the HSInfo) is available on the other virtual communication unit of the second communication unit rSrv. If the client of the field device FD now sends a data packet (step 19), this can be sent encrypted (step 20) to the second communication unit rSrv (steps 22, 23) and decrypted there (step 24) and processed (step 25). The special feature is that purely unidirectional communication takes place between the field device FD and the second communication unit rSrv. A one-way gateway (DCU, data capture unit) only forwards the data packet or packets from the field device FD (step 21) to the second communication unit rSrv, but not in the opposite direction.

In one embodiment, a secret pre-shared key (PSK cipher suite) is used to negotiate the DTLS session (DTLS handshake). In another embodiment, a non-authenticated DTLS handshake is performed.

Although the invention has been illustrated and described in detail by the preferred embodiment, the invention is not limited to the disclosed examples and other variations may be devised by those skilled in the art. derived from this without departing from the scope of the invention.

The processes or procedures described above can be implemented using instructions that are available on computer-readable storage media or in volatile computer memories (hereinafter collectively referred to as computer-readable memories). Computer-readable memories include, for example, volatile memories such as caches, buffers or RAM as well as non-volatile memories such as removable storage devices, hard drives, etc.

The functions or steps described above can be present in the form of at least one instruction set in/on a computer-readable memory. The functions or steps are not tied to a specific instruction set or to a specific form of instruction sets or to a specific storage medium or to a specific processor or to specific execution schemes and can be carried out by software, firmware, microcode, hardware, processors, integrated circuits, etc., either alone or in any combination. A wide variety of processing strategies can be used, for example serial processing by a single processor or multiprocessing or multitasking or parallel processing, etc.

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 the network.

The transmission device can have one or more processors. The term "processor", "central signal processing", "control unit" or "data evaluation means" includes processing means in the broadest sense, for example 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 the person skilled in the art or developed in the future. Processors can consist of one or more devices or units. If a processor consists of several devices, these can be designed or configured for parallel or sequential processing or execution of instructions.

Claims (8)

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.

Images