Method and device for preventing malicious network traffic

Abstract

Methods for preventing malicious network traffic, wherein the method comprises: Providing (110) a client key to a client device through a key generation device; Receiving (120) by a control device, several data packets destined for an application server from the client device, the multiple data packets comprising a first and a subsequent second data packet; Determine (130) by the control device whether the first and second data packets contain the client key; Forwarding (140) the first and / or the second data packet by the control device to the application server in response to a determination that the respective data packet contains the client key; and / or Blocking (150) the first and / or second data packet by the control device in response to a determination that the respective data packet does not contain the client key.

Description

BACKGROUND OF THE INVENTION

[0001] Malicious network traffic can occur in various types of network structures. It can be used, among other things, to launch attacks on application servers, such as game servers, in networks that include the application server and multiple client devices, such as game clients or game client devices.

[0002] Malicious network traffic, especially game traffic, can consist of a particularly large volume of data packets transmitted from a malicious user on a client device to the game server. In a successful attack, the application server or network connection may become so overloaded by the received malicious traffic that it cannot keep up with the workload for legitimate users, or the application server's network port may become congested. This results in the service provided by the application server becoming unavailable to legitimate users, a phenomenon commonly known as a Denial of Service (DoS) attack. A DoS attack carried out by a particularly large number of client devices is commonly referred to as a Distributed Denial of Service (DDoS) attack.In various network structures, an attack is considered successful if the attacker(s) is / are able to impair the quality of service, for example by causing delays.

[0003] Conventional methods and mechanisms aim to prevent successful DoS or DDoS attacks by mitigating the load of malicious network traffic reaching an application server and / or maintaining a reasonable quality of service for legitimate users while an attack is underway. This is generally achieved by recognizing patterns in the received network traffic. Since each application, especially each game application, typically requires different game protocols and thus different or differently structured data packet payloads, known pattern recognition methods are generally based on the header content of the data packets included in the network traffic, rather than the payload of the data packets themselves.

[0004] Patterns within network traffic can be detected based on predefined or known patterns that are considered attacks. Alternatively, patterns can be detected by identifying a (significant) anomaly within the payload or network traffic that was previously received or that occurs during normal operation when no attacks are taking place.

[0005] However, these safeguards can be circumvented relatively easily, as the information contained in the header, especially the source information such as the IP address of the client device, can be altered or falsified. Furthermore, there are certain network structures, such as a gaming network comprising a game server and multiple client devices, where little or no malicious network (gaming) traffic reaching the application server can be tolerated without significantly impacting network traffic factors that affect the user experience, such as increased response time or application server latency.

[0006] Pattern recognition takes time. For example, a single new connection from a specific range of IP addresses might be from a legitimate user. Thousands of connection attempts from that same IP address range could form a pattern and thus be classified as an attack. Due to the detection delay, too few malicious data packets might be blocked. Furthermore, such systems or processes can be exploited by malicious users creating patterns to block one or more legitimate users. For instance, if an attacker knows the IP address or IP address range of at least one legitimate user, they can spoof traffic to appear as if it originates from that user's IP address or range, causing the system or process to block legitimate network traffic exhibiting the same characteristics as the maliciously created pattern.In other words: Too many data packets can be blocked.

[0007] US 10 841 088 B2 describes techniques for generating and validating credentials. A server generates credentials using a current key until a certain number is reached. The server accepts connection requests from clients if the credentials were generated using one of the n most recently used keys, including the current key and one or more older keys. Requests using credentials generated with other keys are rejected. Once the maximum number of credentials generated with the current key is reached, the server switches to a new key.

[0008] DE 602 06 856 T2 describes techniques for protecting a server on the internet from attacks such as denial-of-service through so-called server profile enforcement (SPE). A website creates a profile of legitimate traffic and transmits it to its internet service provider (ISP). The ISP filters incoming traffic according to this profile, blocks or marks unauthorized packets, and thus prevents malicious attacks. SPE units in the ISP's network perform this filtering. The service can be deployed in different classes to protect against various types of attacks.

[0009] The problem addressed by the present invention is therefore the improvement of protection against network attacks, in particular the provision of an improved protection method, device or system to prevent malicious network traffic from reaching an application server. SUMMARY

[0010] According to one of many embodiments, a method for preventing or blocking malicious network traffic is provided, the method comprising: providing, by a key generation device, a client key to a client device; receiving, by a control device, a data packet destined for an application server from the client device; determining, by the control device, whether the data packet contains the client key; forwarding the data packet by the control device to the application server in response to a determination that the data packet contains the client key; and / or blocking the data packet by the control device in response to a determination that the data packet does not contain the client key.

[0011] In other words, the control device forwards the data packet only in response to a determination that the data packet contains the client key. This means that, as a default measure, the control device can block all data packets—that is, all traffic—that do not contain the client key provided to the client device by the key generation device. In this way, malicious network traffic can be reliably detected on a single-packet basis, thereby identifying and blocking individual, and especially initial, malicious network packets of an attack. This provides a deterministic approach that can prevent a significantly larger number, and in particular all, malicious data packets from reaching the application server.

[0012] In the method described above, the client key can be a client token. The key generation device can include a token application programming interface (API) for providing the client token.

[0013] The key generation device and the control device can be coupled via communication. The key generation device and the control device can exchange their respective client key(s). Alternatively or additionally, the key generation device and the control device can possess key generation data, i.e., have stored it, and / or they can have previously communicated with each other and / or transmit key generation data based on which the respective client key(s) can be generated and / or validated. In other words, the control device can be designed to verify whether the client key was generated by the key generation device, for example, based on a shared secret, a shared key generation process, and / or shared key generation data.

[0014] Additionally or alternatively, the key generation device and the control device can be contained within a (higher-level) device, e.g., a network traffic control device. Additionally or alternatively, the key generation device can be contained within the control device, or vice versa.

[0015] Additionally or alternatively, the key generation device, the control device and / or the network traffic control device can be included in the application server and prevent malicious data packets from reaching a specific server application, such as a game application, within the server, as described above.

[0016] According to one embodiment, determining whether the data packet contains the client key involves: Determining whether the client key contained in the data packet is valid.

[0017] For example, the key generation device can provide the client with multiple client keys, and in particular, periodically provide the client device with a new client key. Only the most recently received client key can be a valid client key. In this way, the client key can be replaced regularly or periodically, thereby invalidating previous client keys.

[0018] Additionally or alternatively, the client key can be valid (only) for a specific period of time. In other words, the client key can be (automatically) invalidated after a predetermined period. For example, the key generation device can provide the client with multiple client keys, and in particular, periodically provide a new client key to the client device upon request. In other words, the client device requests a new client key when the client key has expired or before it expires. This method better prevents data packets containing forged or intercepted client keys from reaching the application server.

[0019] According to one embodiment, determining whether the data packet contains the client key involves: determining, in particular based on a timestamp of the client key, whether the client key contained in the data packet has not yet expired.

[0020] The timestamp can indicate the time at which the client key was generated and / or provided to the client device. In other words, the procedure can include the step of determining, based on the client key's timestamp, whether a predetermined time interval has elapsed since the client key was generated and / or provided.

[0021] Additionally or alternatively, the timestamp can indicate the time at which the client key contained in the data packet expires. In other words, the method can include the step of determining, by the key generation device, particularly during the generation of the client key, the time at which the client key expires and / or a time interval after which the client key expires; and of determining, by the control device, based on the client key's timestamp, whether the time has passed and / or whether the time interval has elapsed.

[0022] A client key can be provided to the client device, which is only valid for a limited, and in particular predefined, period of time, for example, less than 1 minute, approximately 1 minute, approximately 1-5 minutes, or approximately 1-30 minutes. This prevents malicious users from carrying out attacks based on extracted or intercepted client keys, for example, by examining third parties or their own network traffic.

[0023] According to one embodiment, the client key provided to the client device is a first client key, and determining whether the data packet contains the client key includes, in particular: determining whether the data packet contains the first or a second client key, wherein the second client key is derivable from the first client key.

[0024] The second client key can be a part of the first client key; in particular, it can be shorter than the first client key and / or comprise fewer bytes than the first client key. In other words, the second client key can represent a fraction of the first client key, such as 1 / 2, 1 / 4, 1 / 16, or 1 / 32 of the first client key, specifically the first 1 / 2, the first 1 / 4, the first 1 / 16, or the first 1 / 32 of the first client key. For example, the first client key comprises or consists of 64 bytes, and the second client key comprises or consists of the first 4 bytes of the first client key's 64 bytes.

[0025] The second client key can be derived from the first client key based on a shared secret, such as a secret shared between the key generation device and the control device. For example, the second client key can be derived from the first client key by XORing one or more parts of the first client key with the shared secret. The shared secret can be a static secret. Alternatively or additionally, the second client key can be derived from the first client key by extracting a fixed set of non-consecutive bits from the first client key, hashing the first client key and extracting specific bits from the result, and / or by any other deterministic computation that can be performed on the first client key to derive the second client key.

[0026] This reduces the size of the data packets to be transmitted and / or the time required for packet transmission. In particular, it shortens the time the control device needs to determine whether a data packet contains malicious network traffic, i.e., whether the data packet includes the client key or not. Furthermore, the control device only needs to store the second client key, thus making efficient use of the available storage capacity.

[0027] Furthermore, the use of a second client key, especially one containing a specific bit sequence not present in the first client key, makes it more difficult to forge the second client key, for example, by a malicious user inspecting their own traffic. This further enhances the security of the process.

[0028] According to one embodiment, determining whether the data packet contains the client key includes, in particular: determining whether a previous data packet previously received by the client device contains the first client key; and determining whether the data packet contains the second client key; and / or wherein determining whether the data packet contains the client key includes, in particular: determining whether a previous data packet previously received by the client device contains the second client key; and determining whether the data packet contains a third client key different from the second client key, wherein the third client key is derivable from the first client key.

[0029] The third client key can be the same length as the second client key. Another short client key, such as another second or third client key, can be sent with each packet. The data packet can, for example, initially contain the first two bytes of the first client key, then the second two bytes, and so on, or any permutation of this sequence, or a sequence of different values ​​derived from the first client key as described above. The control device can then expect to receive a specific pattern of different short client keys (second and / or third client keys) and will, for example, block traffic that always contains the same short client keys (second and / or third client keys).

[0030] The procedure may also include the step of determining whether the previously received data packet and the (subsequently received) data packet were received by the same client device. This determination may be based on parameters or source information contained or specified in the data packets, particularly in the respective headers of the data packets.

[0031] In this way, a portion of the client key, or a shorter client key derived from the full client key, is only accepted as the full client key if the full client key was contained in a previous or initial data packet received by the client device. This reduces the size of subsequent data packets and / or packet transmission time, while simultaneously protecting the application server from attacks.

[0032] Furthermore, by changing the part of the client key or the shorter client key that can be derived from the full client key, the security of the procedure is increased even further.

[0033] According to one embodiment, determining whether the data packet contains the client key includes: determining whether the client key contained in the data packet is associated with the client device and / or a user of the client device.

[0034] The client key can be associated with the client device or with a user, specifically a user account of a user of the client device; that is, it can be different for each client device or user of the client device. In this way, the sending client device (or a user thereof) of a received data packet can be reliably identified.

[0035] The determination can be based, for example, on source information such as the IP address, which is specified in the data packet, particularly in the packet header, while the client key may be contained in the packet payload. Therefore, both the packet header and the packet payload are used to identify legitimate or malicious traffic. This further enhances protection against network attacks, and in particular the security of the described method.

[0036] According to one embodiment, determining whether the data packet contains the client key includes: determining whether the data packet contains the client key at a predetermined position within the data packet, in particular within a payload and / or header of the data packet.

[0037] The client key can be included within the data packet at the end of the header or at the beginning of the payload, thus extending a standardized data packet header. Providing the client key at the predetermined position can further reduce the processing time of the control device—that is, the time it takes to transmit data packets from the client device to the application server via the control device—and / or enable the implementation of the method in various types of network structures.

[0038] According to one embodiment, the method further comprises: receiving, by the key generation device, an authentication key, wherein the authentication key indicates authentication of the client device and / or a user of the client device; providing, by the key generation device, the client key to the client device in response to the receipt and / or validation of the received authentication key.

[0039] In particular, the key generation device can provide the client key to the client device only in response to the receipt and / or validation of the received authentication key. Similarly, the key generation device can provide any subsequent client key to the client device only in response to an additional or repeated receipt and / or validation of the received authentication key. Alternatively, the key generation device can (periodically) provide a (new) client key to the client device in response to the initial receipt and / or validation of the received authentication key.

[0040] The authentication key can be received by the key generation device from an authentication device or directly from the client device. In other words, the authentication key is exchanged with the client key in the key generation device. The authentication key can be an authentication token that represents authentication of the client device or a user (user account) of the client device, such as a JSON Web Token. The authentication key can also contain a digital signature of the authentication device.

[0041] Replacing the authentication key with the client key—that is, including the client key in the data packet instead of directly using the authentication key—not only improves forgery resistance but also increases the efficiency of the process, particularly the determination / validation of the client key by the control device. For example, the client key can be smaller and specifically designed for the determination and validation mechanism within the control device.

[0042] Furthermore, separating the authentication key from the client key allows for less coordination between the systems controlled by an authentication device that provides the authentication key and the controlling device / key generation devices. For example, new key clients can be created periodically, and the entire structure of the key client can be changed without requiring any modification of the authentication key or the authentication device.

[0043] According to one embodiment, the method further comprises: receiving, by the key generation device, a platform key associated with the client device; providing, by the key generation device, the client key to the client device in response to the receipt and / or validation of the received platform key.

[0044] In particular, the key generation device can only provide the client key to the client device in response to receiving and / or validating the received platform key. The platform key can be received by the client device. Alternatively or additionally, the platform key can be received by or via the authentication device. For example, the key generation device can only provide the client key to the client device if both the authentication key and the platform key have been received and / or validated.

[0045] The platform key can be a static key or a secret that is linked to the client, meaning it is integrated into the client and can therefore only change with client updates. Requiring a platform key allows for the detection of reverse engineering attempts by malicious users, for example, if the authentication device receives requests for a client key with a valid authentication key but an invalid platform key, or vice versa.

[0046] According to one embodiment, the method further comprises: receiving, by an authentication device, user credentials of one or the user of the client device; transmitting, by the authentication device, the authentication key to the key generation device and / or to the user device in response to the receipt of the user credentials and / or validating the received user credentials.

[0047] For example, a user of a client device can send user credentials to the authentication device. In response, the authentication device can provide the user or client device with the authentication key, which can be used to indicate the user's or client device's authentication to other devices or services. These other devices or services only need to validate the authentication key and do not need to re-verify the credentials. Because the authentication device already performs the receipt and / or validation of the user credentials, and the control device operates with the client key exchanged with the authentication key, the efficiency and reliability of the process are further increased.Furthermore, by providing a client key only after authentication of a user, user account, or client device, every client key, and thus every received data packet containing a client key, can be associated with the authenticated user, user account, or client device. This improves the process of identifying and blocking malicious users or user devices.

[0048] According to another, possibly independent, embodiment, a device for preventing or blocking malicious network traffic is provided, the device comprising: a control device; and a key generation device; the device being designed to perform each of the methods described above.

[0049] According to another, possibly independent, embodiment, a system for preventing malicious network traffic is provided, the system comprising: the device described above; an authentication device, the authentication device being configured to: receive user credentials of one or the user of the client device; transmit the authentication key or an authentication key to the key generation device in response to receiving the user credentials; and / or validate the received user credentials.

[0050] According to one embodiment, the system further comprises: the application server; and / or the client device.

[0051] According to another, possibly independent, embodiment, a computer program is provided which includes instructions which, when the program is executed by a computer, cause the computer to perform one of the procedures described above.

[0052] According to another, possibly independent, embodiment, a computer-readable medium is provided which includes instructions which, when executed by a computer, cause the computer to perform one of the procedures described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] The present invention can be better understood if the following description of non-restrictive embodiments is read with reference to the accompanying drawings, wherein: Fig. Figure 1 shows a flowchart of an initial procedure for preventing malicious network traffic. Fig. 2. A flowchart of a second procedure that precedes the first procedure; and Fig. 3 shows a network system designed to perform the first and / or the second procedure. DETAILED DESCRIPTION OF PREFERRED EXECUTION FORMS

[0054] Fig. Figure 1 shows a flowchart of a procedure 100 for preventing or blocking malicious network traffic, in particular for preventing malicious network data packets from reaching an application server. The procedure 100 can be carried out by at least some of the network components that are described in Figure 1. Fig. The network system shown comprises 300.

[0055] Procedure 100 begins with step 110, in which a client key is provided from a key generation device 340 to a client device 330. The key generation device 340 may consist of a network traffic control device 360. In other words, the client key may be provided from the network traffic control device 360 ​​to the client device 330.

[0056] The client key can be a key generated by the key generation device 340. The client key can also be specifically designed for a control process performed by a control device 320, as described in more detail below.

[0057] The network system 300 and the procedure 100 can be a system and a procedure used for a game application, for example, an online game application. That is, the client device 330 can be a game client. The application server 310 can be a game server. The key generation device 340 can be a token API. The client key can also be referred to here as the initial client key or as a client token, especially as a long client token.

[0058] The client key can be generated for and / or associated with a specific client device 330. The client key can be provided to client device 330 upon request. For example, key generation device 340 can provide the client key to client device 330, i.e., transfer the client key to client device 330, in response to a request received from client device 330.

[0059] In step 120, a control device 320 receives a data packet from the client device 330. The data packet is destined for the application server 310. In other words, the client device 330 sends the data packet to the application server 310 via the control device 320.

[0060] The control device 320 can consist of the network traffic control device 360. In other words, the data packet destined for the application server 310 can be received by the network traffic control device 360.

[0061] In step 130, the control device 320 determines whether the data packet received by the client device 330 contains the client key that was previously provided to the client device 330 by the key generation device 340 in step 110.

[0062] If the data packet received by client device 330 contains the client key, as determined in step 130, control device 320 forwards the data packet to application server 310. If the data packet received by client device 330 does not contain the client key, as determined in procedure step 130, control device 320 blocks the data packet in step 150; that is, it does not forward the data packet to application server 310.

[0063] This prevents all data packets that do not include the client key and are transmitted from client device 330 to application server 310 from reaching application server 310, by having control device 320 control the network traffic between client 330 and application server 310.

[0064] In this way, network traffic between the client device 330 and the application server 310 is monitored packet by packet. In other words, the monitoring device 320 can determine, based on the content of the data packet itself, whether a data packet belongs to malicious network traffic or is part of a network attack, such as a DDoS attack.

[0065] This means that the control device 320 can even detect the first malicious data packet of an attack directed against the application server 310. Therefore, the control device 320, or any other network component of the network system 300, does not need to recognize patterns within network traffic to identify malicious network packets. While a pattern-based method inherently blocks too many or too few data packets, the method described here is capable of deterministically blocking (i) all malicious data packets and (ii) only malicious data packets.

[0066] Reference is now made in more detail to process step 130, in which the control device 320 determines whether the data packet received by the client device 330 contains the client key that was previously provided to the client device 330 by the key generation device 340.

[0067] The control device 320 can determine that the data packet contains the client key only if the client key (or part of the client key, or another client key derivable from the client key, as described below) is valid. A valid client key can be the last or most recent client key among several client keys previously provided to the client device 330 by the key generation device 340.

[0068] A valid client key can be, for example, a client key that has not yet expired. An expired client key can be a client key that has been replaced by a newer or subsequent client key. Additionally or alternatively, a client key (or part of the client key, or another client key derivable from the client key, as described below) can have a limited validity period. In other words, a client key can be determined to be expired when a predetermined time interval has elapsed since the client key was generated by the key generation device 340 and / or provided to the client device 330.In other words, the control device 320 can determine the age of the client key, for example, based on a timestamp of the client key, and can determine that the client key is an expired client key when its age exceeds a predefined age threshold. Additionally or alternatively, the control device 320 can determine that the client key is an expired client key when the time or time interval specified by a timestamp of the client key has elapsed. In other words, the key generation device 340 can define in step 110 when the client key expires.

[0069] Thus, a new client can be provided to the client device by the key generation device 340, especially at the request of the client device 330, when a previous client key has become invalid and / or expired, or before the client key expires or becomes invalid.

[0070] The control device 320 can further determine that the data packet contains the client key if the data packet contains at least a part of the client key, in particular (only) a part of the client key or another client key derivable from the client key. In other words, the data packet sent from the client device 330 to the application server 310 via the control device 320 can contain a second client key, a short (or tiny) client key, or a short client token. The second client key can be a part of the first (complete) client key. The second client key can be shorter and / or smaller than the first client key. Or, put yet another way, the method can determine that the client is included in the data packet even if the data packet contains (only) the second client key.

[0071] In this way, the data packets sent from client device 330 to application server 310 via control device 322 can be smaller while still containing the valid client key(s). Furthermore, the determination performed by control device 320 in process step 130 as to whether the data packet contains the client key can be carried out more efficiently, and in particular, more quickly. Moreover, control device 320 can store only the second, i.e., shorter, client key in a memory associated with or used by control device 320, further improving the efficiency of process 100, network traffic control device 360, and network system 300.

[0072] The control device 320 can further determine in step 130 that the data packet contains the client key by determining that the data packet contains at least the second client key, in particular only the second client key, in combination with the determination that a previous data packet previously received by the client device contains the (complete, i.e. first) client key.

[0073] In other words, a first data packet sent from client device 330 to application server 310 can only be forwarded by control device 320 (i.e., pass through control device 320) if the first data packet contains the first client key or the long client key. A subsequently received second data packet sent from client device 330 to application server 310 can only be forwarded by control device 320 if the second data packet contains the first client key or the second client key (i.e., the short client key).

[0074] This ensures that the client device is or was in possession of the first client key. Therefore, the efficiency of Network System 300 or Procedure 100 can be improved by using the short client key, while simultaneously ensuring the security and / or reliability of the system and the procedure.

[0075] The control device 320 can forward the data packet received from the client device 330 to the application server 310 only if the second client key contained in the second data packet is related to the first client key contained in a previously received first data packet—that is, if it belongs to it, is based on it, is derivable from it, or is a part of it. After the key generation device 340 provides a new or subsequent client key to the client device 330, the control device 320 can forward a data packet containing a corresponding new second client key, which may be a part of the new first client key, only if a data packet containing the new first client key has been received previously.In other words, for all data packets to be forwarded to the application server 310, the provision of a new client key by the key generation device 340 requires that the new client key be included in each subsequent data packet sent by the client device 330.

[0076] In step 130, the control device 330 can determine that the data packet contains the client key if the client key contained in the data packet is associated with the client device and / or a user of the client device. The control device 320 can store or otherwise possess data pairs indicating that a particular client key belongs to, and / or is associated with, a particular client device and / or a particular user of that particular client device. The control device 320 can perform this determination, for example, based on source information contained in the data packet, particularly in the header of the data packet.

[0077] In step 130, the control device 330 can determine that the data packet contains the client key if the data packet contains the client key at a predetermined position within the data packet. For example, the control device 330 can determine that the data packet contains the client key only if the client key is located at the end of the header of the data packet and / or at the beginning of the payload of the data packet, or at a predetermined position within the header and / or within the payload of the data packet.

[0078] Likewise, in the exemplary procedure steps mentioned above, which include procedure step 130, the control device 330 can determine that the data packet does not contain the client key if the requirements described above are not met, and can therefore block the corresponding data packets, as described with reference to step 150.

[0079] Before the key generation device 340 provides the client key to the client device 330, the procedure 100 may perform some or all of the procedure steps 210 to 240 of the procedure 200, a flowchart of which is shown in Fig. 2 is shown.

[0080] In a first process step 210, an authentication device 350 receives user credentials, i.e., user identification data, such as a username, and / or user security data, such as a user password, from a user of the client device 330. The user credentials can be transmitted from the client device 330 to the authentication device 350.

[0081] In response to receiving and / or validating the received user credentials, the authentication device 350 transmits an authentication key to the user device in step 220. In other words, the client device receives the authentication key after transmitting user credentials to the authentication device 350, i.e., after logging on to the authentication device 350 or an authentication service connected to the authentication device 350.

[0082] The user of the client device can have a personal account with the authentication device 350, which serves to authorize the user to use certain services, such as participating in a game located on a game server, e.g., the application server 310. The client device 330 can use the authentication key to prove to a server, e.g., the application server 310, that the client device 330 is being operated by a specific user, such as a player, who has been authenticated by the authentication device 350. However, the authentication key, which can be used as proof of authentication in different server systems and / or for different purposes, may not be suitable or may be less suitable for controlling network traffic to prevent malicious data packets from reaching the application server 310.For example, the authentication key may be too long or too large to be included in the data packets that are transmitted from the client device 330 via the control device 320 to the application server 310.

[0083] Client device 330 sends the authentication key to key generation device 340, which receives the authentication key in step 230. In exchange for the authentication key received from client device 330, key generation device 340 can provide the client key to client device 330, in particular the client key associated with client device 330, as discussed with reference to procedure step 110.

[0084] In this way, the client key can be used by the control application 320 to determine whether or not to forward the data packet to the application server 310. A client key can be generated specifically for use by the control device 320. Furthermore, the transmission of the client key between the control device 320 and the key generation device 340 can be facilitated by using a client key generated by the key generation device 340 instead of the authentication key. Specifically, the control device 320 and the key generation device 340 can be based on or comprised of the network traffic control device 360 ​​described above, as discussed above.Another advantage is that the client key can be generated and / or renewed independently of the authentication key, which can also be used for other purposes, thus avoiding additional network traffic and / or additional coordination between the control device 330, the key generation device 340, and / or the authentication device 350. On the other hand, each data packet containing the client key can be bound to an authentication key, i.e., to a user and / or user device that has been authenticated by an additional, independent authentication device.

[0085] Additionally or alternatively, the authentication device 350 can communicate directly with the key generation device 340. In particular, the authentication device 315 can directly transmit the authentication key associated with the client device 330 to the key generation device 340.

[0086] In addition to or instead of the authentication key, the client device 330 can transmit a platform key associated with the client device, received by the key generation device 340 in step 240, to the key generation device 340. The key generation device 340 can provide the client key to the client device 330 only after receiving the platform key and / or the authentication key. The platform key can be static, meaning it must not change when a user of the client device changes. In this way, both the client device user and the client device can be authenticated and / or validated by the key generation device 340 before the client key is provided to the client device 330, as discussed with reference to procedure step 110.

[0087] Alternatively or additionally, the client device 330 can transmit the platform key, or the platform token, to the authentication device 350, which then transmits the platform key and / or the authentication key to the key generation device 340.

[0088] Fig. Figure 3 shows the network system 300, which is designed to handle the in Fig. 1 and Fig. to carry out the procedures 100 and 200 shown in section 2, as described in reference to Fig. 1 and Fig. 2 described. In particular, shows Fig. 3 the network traffic control device 360, which is designed to carry out the procedure 100, as referred to in Fig. 1 described.

[0089] More precisely, network system 300 comprises the application server 310, which is communicatively coupled to the control device 320 via a first network connection 315. Network system 300 further comprises the client device 330, which is communicatively coupled to the control device 320 and the key generation device 340 via a second connection 325 and a third network connection 335, respectively. Network system 300 also comprises the key generation device 340, which is communicatively coupled to the control device via a fourth network connection 345. Network system 300 further comprises an authentication device 350, which is communicatively coupled to the key generation device 340 via a fifth network connection 355 and to the client device 330 via a sixth network connection 365. REFERENCE MARK LIST 100 First Procedure 110 - 150 procedural steps of the first procedure 200 Second procedure 210 - 240 procedural steps of the second procedure 300 network system 310 Application Server 315 First network connection 320 Control device 325 Second network connection 330 Client Device 335 Third network connection 340 Key generating device 345 Fourth network connection 350 authentication device 355 Fifth network connection 360 network traffic control device 365 Sixth network connection

Claims

[1] A method for preventing malicious network traffic, the method comprising: Providing (110), by a key generation device, a client key to a client device; Receiving (120), by a control device, a plurality of data packets intended for an application server from the client device, the plurality of data packets comprising a first and a subsequent second data packet; Determining (130), by the control device, whether the first and second data packets include the client key; Forwarding (140) the first and / or the second data packet by the control device to the application server in response to a determination that the respective data packet comprises the client key; and / or Blocking (150) the first and / or second data packet by the control device in response to a determination that the respective data packet does not include the client key. [2] The method of claim 1, wherein determining whether the first and second data packets include the client key comprises: Determine whether the client key contained in the first and second data packets is valid. [3] A method according to any preceding claim, wherein determining whether the first and second data packets comprise the client key comprises: Determining, in particular based on a timestamp of the client key, whether the client key contained in the first and second data packets has not yet expired. [4] The method of any preceding claim, wherein the client key provided to the client device is a first client key, and wherein determining whether the first and second data packets comprise the client key comprises: Determining whether the first and second data packets comprise the first or a second client key derivable from the first client key. [5] The method of claim 4, wherein determining whether the first and second data packets include the client key comprises: Determining whether the first data packet previously received by the client device includes the first client key; and Determining whether the second data packet includes the second client key; and / or wherein determining whether the data packet includes the client key comprises: Determining whether the first data packet previously received by the client device includes the second client key; and Determining whether the second data packet comprises a third client key different from the second client key, wherein the third client key is derivable from the first client key. [6] A method according to any preceding claim, wherein determining whether the first and second data packets comprise the client key comprises: Determining whether the client key included in the first and second data packets is associated with the client device and / or a user of the client device. [7] A method according to any preceding claim, wherein determining whether the first and second data packets comprise the client key comprises: Determining whether the first and second data packets include the client key at a predetermined position within the data packet, in particular within a payload and / or a header of the data packet. [8] A method according to any one of the preceding claims, further comprising: Receiving (230), by the key generating device, an authentication key, the authentication key indicating authentication of the client device and / or a user of the client device; Providing (110), by the key generation device, the client key to the client device in response to receiving and / or validating the received authentication key. [9] A method according to any one of the preceding claims, further comprising: Receiving (240), by the key generation device, a platform key associated with the client device; Providing (110), by the key generation device, the client key to the client device in response to receiving and / or validating the received platform key. [10] A method according to any one of the preceding claims, further comprising: Receiving (210), by an authentication device, user credentials of one or the user of the client device; Transmitting (220), by the authentication device, the or an authentication key to the key generation device and / or to the user device in response to receiving the user credentials and / or validating the received user credentials. [11] Device (360) for preventing malicious network traffic, the device comprising: a control device (320); and a key generating device (340); wherein the device is designed to carry out the method according to any one of claims 1-9. [12] A system (300) for preventing malicious network traffic, the system comprising: the device (360) according to claim 11; an authentication device (350), wherein the authentication device is configured to: Receiving user credentials of one or the user of the client device (330); Transmitting the or an authentication key to the key generating device (340) in response to receiving the user credentials and / or validating the received user credentials. [13] The system of claim 12, further comprising: the application server (310); and / or the client device (330). [14] A computer program comprising instructions which, when executed by a computer, cause the computer to carry out the method according to any one of claims 1-10. [15] A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 1-10.

Images