A relay attack verification method and device, electronic equipment and storage medium

Abstract

This application discloses a relay attack verification method, apparatus, electronic device, and storage medium. The method utilizes a client. First, a first process of the client monitors target traffic indicated by pre-defined filtering rules and parses the target traffic to obtain a first public key. The filtering rules are used to filter traffic indicated by set filtering parameters, including destination IP, destination port, source IP, and source port. Second, the first process of the client sends a first request to a server based on the first public key. Finally, the first process of the client receives a first remote authentication report sent by the server according to the first request and verifies the server based on whether the public key parsed from the first remote authentication report matches the first public key. Applying the method of this application can reduce resource consumption during relay attack verification.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a relay attack verification method, apparatus, electronic device and storage medium. Background Technology

[0002] A relay attack is a type of man-in-the-middle attack. The core of this attack is that the attacker doesn't crack the password or key, but instead uses a device to forward the wireless or network signals between the two parties as is, causing the system to mistakenly believe that a "legitimate device is nearby," thus bypassing distance verification to complete authentication. For example, an attacker impersonates the server, completes a Transport Layer Security (TLS) handshake with the client and obtains a random number, then forwards it to the real server to obtain a Remote Attestation (RA) report, which is then sent back to the client to gain trust and ultimately steal uploaded confidential data.

[0003] In practical applications, the local port used by the client when establishing a Transmission Control Protocol (TCP) session is temporarily assigned by the operating system and cannot be predicted in advance. Therefore, NFQueue / WinDivert can only configure traffic forwarding rules based on the server's IP address and port, copying all traffic destined for that server's IP address and port to user space, without the ability to configure more precise kernel-space forwarding rules. This means that the forwarding rule must always be enabled; otherwise, it cannot intercept new client IP / port requests in real time. However, in confidential network scenarios, as long as RA verification is completed before the TLS handshake phase ends, subsequent traffic in the current TCP session can be allowed to pass. Furthermore, the overall resource consumption of copying traffic packets from kernel space to user space is high, regardless of whether it's Windows or Linux. Summary of the Invention

[0004] This application provides a relay attack verification method, apparatus, electronic device, and storage medium to reduce resource consumption during the relay attack verification process.

[0005] In a first aspect, one embodiment of this application provides a relay attack verification method, which is applied to a client and includes: The client's first process monitors the target traffic indicated by the pre-defined filtering rules, parses the target traffic, and obtains the first public key; the filtering rules are used to filter the traffic indicated by the set filtering parameters, which include the destination IP, destination port, source IP, and source port; The client's first process sends the first request to the server based on the first public key; The client's first process receives the first remote authentication report sent by the server based on the first request, and verifies the server by checking whether the public key parsed from the first remote authentication report is the same as the first public key.

[0006] In this embodiment, the client's first process only monitors target traffic that meets the pre-defined filtering rules, without needing to monitor all traffic, thus saving resource overhead. Then, the specific target traffic is parsed to obtain a first public key, and a first request is sent to the server based on this first public key. After receiving a first remote authentication report sent by the server according to the first request, the first remote authentication report is parsed, and the server is verified based on whether the parsed public key matches the first public key. Because resource overhead is saved during traffic monitoring, the entire verification process also adaptively saves resource overhead.

[0007] Secondly, one embodiment of this application provides a relay attack verification implementation method, applied to a server, the method comprising: The server's second process monitors the target traffic indicated by the pre-defined filtering rules, parses the target traffic, and obtains the second public key; the filtering rules are used to filter the traffic indicated by the set filtering parameters, which include the destination IP, destination port, source IP, and source port. The second process on the server side generates the first remote proof report based on the second public key; If the second process on the server receives the first request from the client within a set time interval, it sends the first remote report to the client so that the client can verify the server by checking whether the public key parsed from the first remote verification report is the same as its own first public key.

[0008] In this embodiment, the second process on the server only monitors target traffic that meets the pre-set filtering rules, without needing to monitor all traffic, thus saving resource overhead. Then, the specific target traffic is parsed to obtain a second public key, and a first remote proof report is generated based on this second public key. After receiving a first request from the client within a set time interval, the first remote proof report is sent to the client. The client can then parse the first remote proof report and verify the server by checking if the parsed public key matches the first public key. Because resource overhead is saved during traffic monitoring, the entire verification process also adaptively saves resource overhead.

[0009] Thirdly, one embodiment of this application provides a relay attack verification device applied to a client. The first process of the client includes a first processing unit and a first transmission unit. In this device: The first processing unit is used to: monitor the target traffic indicated by the pre-set filtering rules, and parse the target traffic to obtain the first public key; wherein, the filtering rules are used to filter the traffic indicated by the set filtering parameters, and the set filtering parameters include the destination IP, destination port, source IP and source port; The first transmission unit is used to: send a first request to the server based on the first public key; The first transmission unit is also configured to: receive a first remote certification report sent by the server in accordance with the first request; The first processing unit is also used to: verify the server based on whether the public key parsed from the first remote proof report is the same as the first public key.

[0010] Fourthly, one embodiment of this application provides a relay attack verification implementation apparatus. This apparatus is applied to a server and includes a second processing unit and a second transmission unit. In this apparatus: The second processing unit is used to: monitor the target traffic indicated by the pre-set filtering rules, and parse the target traffic to obtain the second public key; wherein, the filtering rules are used to filter the traffic indicated by the set filtering parameters, and the set filtering parameters include the destination IP, destination port, source IP and source port; The second processing unit is also used to: generate a first remote proof report based on the second public key; The second transmission unit is used to send a first remote report to the client when a first request is received from the client within a set time interval, so that the client can verify the server based on whether the public key parsed from the first remote verification report is the same as its own first public key.

[0011] Fifthly, one embodiment of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the above methods.

[0012] Sixthly, one embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the steps of any of the above methods.

[0013] In a seventh aspect, one embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above methods. Attached Figure Description

[0014] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 A schematic diagram of a TCP session provided in an embodiment of this application; Figure 2 A schematic diagram of a confidential network framework based on kernel probes provided in an embodiment of this application; Figure 3 A schematic diagram of a proxy based on a Linux kernel probe provided in an embodiment of this application; Figure 4 A schematic diagram of a Windows kernel probe-based proxy provided in an embodiment of this application; Figure 5 A flowchart illustrating a relay attack verification method provided in one embodiment of this application; Figure 6 A flowchart illustrating another relay attack verification method provided in an embodiment of this application; Figure 7 A schematic diagram of a confidential network framework based on kernel probes provided in an embodiment of this application; Figure 8 A schematic diagram of a Linux-based kernel probe proxy provided in an embodiment of this application; Figure 9 A schematic diagram of a Windows kernel probe-based proxy provided in an embodiment of this application; Figure 10 A schematic diagram of a confidential network framework based on kernel probes provided in an embodiment of this application; Figure 11 A schematic diagram of a kernel probe-based proxy provided in one embodiment of this application; Figure 12 This is a schematic diagram of the structure of a relay attack verification device provided in an embodiment of this application; Figure 13 This is a schematic diagram of the structure of a relay attack verification device provided in an embodiment of this application; Figure 14 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings.

[0017] For ease of understanding, the terms used in the embodiments of this application are explained below: (1) Extended Berkeley Packet Filter (eBPF): A kernel-level programmable mechanism initially used for filtering network packets, it has now been extended into a general-purpose "kernel applet" execution platform. Users can write small, restricted C-like code snippets, which are then loaded into specific mount points (such as a kernel function or an exported function of a user-space binary program) after the kernel verifies their security. This allows for network filtering, performance monitoring, and security auditing without modifying or restarting the kernel, making it one of the most important innovations in the Linux kernel field. With each upgrade of the Linux kernel version, the number of mount points that eBPF can load onto increases.

[0018] (2) Kprobe (Kernel-space probe): A dynamic instrumentation (dynamic probe insertion) mechanism provided by the Linux kernel. Through kprobe, developers can dynamically insert custom processing logic (i.e., probe functions) at the entry, exit, or intermediate instruction points of any kernel function. This allows for real-time monitoring, analysis, debugging, or tracing of the execution flow of kernel-mode code without modifying the kernel source code or restarting the system. In Linux version 4.1 and later, kprobe supports integration with eBPF, meaning that eBPF programs can be mounted onto specific kprobe probes to achieve efficient and low-overhead kernel-level event capture and processing. This mechanism is widely used in performance analysis, security detection, and fault location. For example, kprobe can be used to trace system calls and network protocol stack function execution, enhancing observability and security.

[0019] (3) Windows-eBPF: This is an engineering and framework that introduces the kernel programmable mechanism eBPF into the Windows operating system. By providing hook points in the Windows network stack and system events, verified eBPF programs can run in the Windows kernel environment, thereby implementing functions similar to programmable network filtering, system monitoring, and security control under Linux on the Windows platform, facilitating a unified cross-platform development model. Its implementation principle differs significantly from Linux, and it is more based on simulating the effect of Linux eBPF using classic Windows drivers. Currently, the main capabilities of Windows-eBPF are concentrated on the kernel network stack, which can meet the technical requirements of this application.

[0020] (4) User mode is the space where applications run. It has low privileges, memory isolation, and cannot directly operate hardware.

[0021] (5) Kernel mode, the space where the operating system kernel runs, has the highest privileges and can operate hardware and manage all processes.

[0022] (6) Audit mode, which triggers alarms but does not block them.

[0023] (7) Blocking mode, a scenario in which traffic destined for non-confidential environments is intercepted.

[0024] The number of any elements in the accompanying drawings is for illustrative purposes only and not as a limitation, and any naming is for distinction only and has no limiting meaning.

[0025] In practical application, both auditing and blocking modes suffer from the same problem: the traffic for the corresponding port needs to be completely forwarded from kernel space to user space. For example, when using Wireshark to capture packets and obtain key information from the TLS Server / Client Hello, filtering is only possible in user space, but Wireshark's mechanism requires copying the entire TCP session traffic to user space for evaluation. This application is typically applicable to Linux kernel versions 4.1 and above, and Windows 10 version 1809 / Windows Server 2019 and above.

[0026] Similarly, because the local port used when establishing a TCP session by the client is temporarily assigned by the operating system and cannot be predetermined, NFQueue / WinDivert can only set traffic forwarding rules based on the server's IP and port, copying all traffic destined for that server's IP and port to user space. It cannot perform more precise kernel-space forwarding rule settings (client IP, client port, server IP, server port). This means the forwarding rule must always be enabled; otherwise, it cannot intercept new client IP / port requests in real time. However, in confidential network scenarios, as long as RA verification is completed before the TLS handshake phase ends, subsequent traffic in the current TCP session can be allowed. Due to the randomness of the client port, related technologies cannot quickly remove unnecessary traffic forwarding rules.

[0027] Whether on Windows or Linux, copying traffic packets from kernel space to user space incurs significant resource overhead. It's important to note that although all packets in the entire TCP session matching the port requirements are copied, only a small amount of handshake packet information is actually needed. Figure 1 This is a schematic diagram of a TCP session provided in an embodiment of this application, wherein the TCP session process consists of several traffic packets, through... Figure 1 It can be seen that this TCP session process incurs unnecessary performance overhead.

[0028] Therefore, it can be assumed that if only a small amount of traffic is copied to user space for processing, and subsequent TCP sessions do not require copying, the overhead in this area can be significantly reduced. This assumption is reasonable because network communication is not entirely the responsibility of the network stack. The operating system kernel needs to trigger several functions to prepare for communication establishment, some of which explicitly allocate temporary port information. If the port information can be determined, then it is unnecessary to intercept the entire traffic to the server IP and server PORT; instead, it can be further limited to a specific four-tuple (source IP, source PORT, peer IP, peer PORT). In this case, only more specific traffic is proxied. Since TLS handshakes always occur at the beginning of a TCP session, this traffic copying and proxying can be closed after obtaining the information (if identified as illegal, an RST packet is sent to terminate the session). Subsequent session packets can then only go through kernel space without further interception and copying. Furthermore, it is necessary to know the TCP session termination information to clear port records and avoid incorrectly closing or allowing traffic during subsequent port reuse.

[0029] As mentioned above, with the help of technologies such as eBPF, when the relevant kernel function is called or returns, it can automatically switch to a custom logic with parameter information, and then observe the parameters in this custom logic, extract the necessary information, and then set appropriate rules.

[0030] More specifically, in this section's solution, the following hook points are required in the Linux system: tracepoint / sock / inet_sock_set_state: This point is triggered every time the TCP socket state changes. Specifically, the network four-tuple information in the TCP, as well as the original and new states of the TCP session, can be obtained here. In other words, all TCP session information can be obtained in kernel space, and then filtered in kernel space based on the known server IP and PORT. The corresponding complete four-tuple is then sent back to user space to further obtain information on the start and end of the TCP session, as well as the corresponding client PORT.

[0031] The following three types of hook points are required in Windows systems: cgroup / connect4 or cgroup / connect6: If the current machine is in an IPv4 network environment, use connect 4; if it is in an IPv6 network environment, use connect 6.

[0032] This function is triggered when the Windows operating system allocates a local port for the session when the client initiates a connection; that is, this hook point can obtain the local port of the session (i.e., the client PORT).

[0033] cgroup / recv_accept4 or cgroup / recv_accept6: This hook is triggered when the server receives a new client connection; similarly, it allows the server to obtain the client port corresponding to this TCP session. Specifically, if the current machine's network environment is IPv4, then `recv_accept4` is used; if it's IPv6, then `recv_accept6` is used.

[0034] sockops: This point can be triggered in three situations, and the specific situation can be determined in kernel mode. One is the active establishment of a TCP session (i.e., client-side establishment), another is the passive establishment of a TCP session (i.e., server-side establishment), and the third is the termination of a TCP session. In this embodiment, the termination of a TCP session is mainly used for illustration.

[0035] The hook point mentioned above may be the most suitable hook point, but there are other hook points (especially in Linux systems) that can obtain the same information; in the embodiments of this application, it is only an example and does not constitute a specific limitation.

[0036] Therefore, in this embodiment, by reasonably hooking some kernel functions, the port prepared by the client for this TCP session can be obtained as early as possible, and then more accurate traffic interception and forwarding can be performed. Because the TCP traffic is intercepted early, the TCP handshake traffic may have already been sent, but the TLS handshake traffic is likely not yet sent. Therefore, the TLS handshake traffic can be obtained in user space, and the desired public key information can be extracted from it. After extraction, the TLS handshake traffic is immediately allowed. After the RA report is received and verified, the remaining traffic is allowed and the proxy rule is deleted. Subsequent TCP sessions can then be allowed. As mentioned above, the process of "reasonably hooking some kernel functions" requires support from eBPF, etc., and therefore has certain requirements for the Linux or Windows version. Distinguishing itself from the NIRA (Non-Intrusive RA) + TLS scheme in related technologies, the scheme in this application can be called the NIRAK (Non-Intrusive RA based on Kprobe) + TLS scheme.

[0037] Before discussing specific solutions, it is necessary to explain some information used in this application.

[0038] ① The IP and PORT of the server providing TLS service are known in advance by both the client and the server (the IP and PORT known by both sides may be different due to factors such as NAT or gateway; however, they are fixed for each side).

[0039] ②The server can open an additional port for the client to initiate a request to obtain a remote proof report.

[0040] ③ The client knows its own IP address when making the request (if it cannot know, the network four-tuple restriction in the subsequent embodiments needs to be replaced with a three-tuple restriction of client PORT, server IP, and server PORT, which has the same effect).

[0041] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, the method may include more or fewer operation steps based on conventional or non-inventive methods. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application.

[0042] The following is combined Figure 1 The application scenarios shown illustrate the technical solutions provided in the embodiments of this application.

[0043] This application embodiment mainly includes scenarios involving server-side authentication (in which reasonable traffic hijacking is performed on the client side), client-side authentication (in which reasonable traffic hijacking is performed on the server side), and two-way authentication (in which reasonable traffic hijacking is performed on both the client and server sides). In practical applications, server-side authentication is the more common scenario; therefore, the following section will mainly describe the server-side authentication process in detail, while the client-side authentication and two-way authentication processes will also be briefly described. Furthermore, this application embodiment uses a single TLS service as an example; in practical applications, this can be extended to multiple TLS services, which will not be elaborated here.

[0044] Taking the verification server as an example, Figure 2 This is a schematic diagram of a confidential network framework based on kernel probes provided in an embodiment of this application. Figure 3 This is a schematic diagram of a proxy based on a Linux kernel probe, provided as an embodiment of this application. Figure 4 This is a schematic diagram of a Windows kernel probe-based proxy provided in an embodiment of this application.

[0045] Root-of-trust refers to the root of trust; RA+ refers to Remote Verification (RA) which is a decoupled enhancement of the traditional TLS certificate-based security mechanism. Specifically, attackers must break both the TLS security mechanism and the RA security mechanism to compromise the trustworthiness of the trusted / confidential environment and ensure that a genuine secure environment is providing network services.

[0046] In this embodiment, the specific client port is obtained by observing session information through a kernel probe, thus enabling more precise filtering of traffic in kernel mode. Furthermore, the proxy can be revoked immediately upon obtaining the information, overcoming the problem in related technologies that require proxying all traffic based solely on the server IP and port. For details, please refer to [link to related documentation]. Figures 2-4 .

[0047] refer to Figure 5 This application provides a relay attack verification method, which is a verification process for the server and applied to the client. The method includes the following steps: S501: The client's first process monitors the target traffic indicated by the pre-set filtering rules, parses the target traffic, and obtains the first public key.

[0048] The filtering rules are used to filter traffic specified by the filtering parameters, which include the destination IP, destination port, source IP, and source port.

[0049] S502: The client's first process sends the first request to the server based on the first public key.

[0050] S503: The client's first process receives the first remote authentication report sent by the server according to the first request, and verifies the server based on whether the public key parsed from the first remote authentication report is the same as the first public key.

[0051] In this embodiment, the client's first process only monitors target traffic that meets the pre-defined filtering rules, without monitoring all traffic, thus saving resource overhead. The specific target traffic is then parsed to obtain a first public key, and a first request is sent to the server based on this first public key. After receiving a first remote authentication report sent by the server according to the first request, the first remote authentication report is parsed, and the server is verified based on whether the parsed public key matches the first public key. Because resource overhead is saved during traffic monitoring, the entire verification process also adaptively saves resource overhead.

[0052] In the S501 architecture, the client involves multiple processes. One process is selected to authenticate the server; this process is called the first process. This first process only monitors the target traffic indicated by pre-defined filtering rules, rather than monitoring all traffic. It then parses the target traffic to obtain the first public key. The filtering rules are used to filter traffic specified by set filtering parameters, which include the destination IP, destination port, source IP, and source port. For example, the filtering parameters can be filtering rules or tool-related; the filtering rules can be NFQueue rules. The first public key can be an ECDHE public key.

[0053] In a specific example, the IP address of the TLS service can be determined as the destination IP address, and the port of the TLS service can be determined as the destination port; the local IP address and local port can then be determined based on the destination IP address and destination port.

[0054] In the case of S502, after obtaining the first public key, the client's first process sends a first request to the server based on the first public key, and the request carries relevant information about the first public key.

[0055] In the case of S503, after receiving the first public key, the second process on the server generates a first remote proof report (RA report) and then sends the first remote proof report to the client. The first process on the client receives the first remote proof report, parses it, and determines whether the parsed public key is the same as the first public key generated by the first process on the client.

[0056] Optionally, if the public key parsed from the first remote proof report is the same as the first public key, the verification result for the server is determined to be successful; otherwise, the verification result for the server is determined to be unsuccessful.

[0057] Based on the above technical solution, if the verification fails, or if no verification result is detected after a preset time, the target traffic is discarded, an RST packet is sent to block the current session, and an alarm log is generated.

[0058] For example, the preset duration could be 3 seconds. This is just an example and does not constitute a specific limitation.

[0059] Based on the above technical solution, if a TCP connection is detected to be closed, the existence of a filtering rule is checked. If it is, the traffic packet corresponding to the target traffic is discarded, the filtering rule is deleted, and an alarm is generated.

[0060] Based on the above technical solution, traffic packets during the TLS session are allowed, while traffic packets containing real data are intercepted.

[0061] The following example illustrates the operations performed by the first process of the client, which is a client traffic RA-enhanced verification process based on Linux kernel probes.

[0062] Step 1: Start the kernel-mode and user-mode logic corresponding to the hook point ininet_sock_set_state. In the kernel mode, limit the reporting to information that is determined to be the destination IP of the TLS service and the destination PORT of the TLS service. In the user mode, parse the relevant state and extract the local IP and local PORT.

[0063] Step 2: Upon learning that a TCP connection has been established, and obtaining the local IP and PORT, immediately set up NFQueue rules to filter traffic proxies containing the four-tuple (local IP, local PORT, TLS service IP, TLS service PORT); extract the ECDHE public key from the TLS Server Hello in the proxies and immediately request a RA report from the server; then allow traffic packets during the TLS session phase, and intercept and wait for traffic packets containing real data; periodically poll until the RA report has been verified, then allow the relevant traffic; if the RA report verification fails, or is not received within a fixed time (e.g., 3 seconds), discard the relevant traffic, send an RST packet to block the session, and generate an alarm log.

[0064] Step 3: Upon learning that a TCP connection has been closed, check if there is an NFQueue rule corresponding to the local IP address, port, and other four-tuples. If so, discard all packets in the queue, delete the NFQueue proxy rule, and generate an alarm log.

[0065] refer to Figure 6 This application provides a relay attack verification method, which is a verification process for the server. The method is applied to the server and includes the following steps: S601: The second process on the server monitors the target traffic indicated by the pre-set filtering rules, parses the target traffic, and obtains the second public key.

[0066] The filtering rules are used to filter traffic specified by the filtering parameters, which include the destination IP, destination port, source IP, and source port.

[0067] S602: The second process on the server generates the first remote proof report based on the second public key.

[0068] S603: If the second process of the server receives the first request from the client within a set time interval, it sends the first remote proof report to the client so that the client can verify the server based on whether the public key parsed from the first remote proof report is the same as its own first public key.

[0069] In this embodiment, the second process on the server only monitors target traffic that meets the pre-set filtering rules, without needing to monitor all traffic, thus saving resource overhead. Then, the specific target traffic is parsed to obtain a second public key, and a first remote proof report is generated based on this second public key. After receiving a first request from the client within a set time interval, the first remote proof report is sent to the client. The client can then parse the first remote proof report and verify the server by checking if the parsed public key matches the first public key. Because resource overhead is saved during traffic monitoring, the entire verification process also adaptively saves resource overhead.

[0070] Regarding S601, the process of the second process on the server monitoring traffic and obtaining the second public key is the same as the process of the client monitoring traffic and obtaining the first public key, so it will not be described in detail here.

[0071] Involving S602, the second process on the server side extracts the ECDHE public key from the TLS Server Hello and generates the first remote proof report.

[0072] Regarding S603, if the second process on the server receives a first request from the client within a set time interval, it sends the first remote authentication report to the client. The first process on the client can then parse the first remote authentication report to obtain a public key and verify the server by checking if this public key matches its own first public key. The specific verification process can be found in the aforementioned embodiments and will not be repeated here.

[0073] Based on the above technical solution, if a TCP connection is detected to be closed, the existence of a filtering rule is checked. If it is, the traffic packet corresponding to the target traffic is discarded, the filtering rule is deleted, and an alarm is generated.

[0074] The following example illustrates the operations performed by the second process on the server side. In practical applications, if the server's kernel version is not high enough, the TLS key (i.e., the corresponding ECDHE public key) can be obtained using the pure observation method described in the previous embodiment. If the version is high enough, the following method can be used to avoid user-space forwarding that requires a large amount of traffic. This example demonstrates the server traffic RA-enhanced verification process based on Linux kernel probes.

[0075] Step 1: Start the kernel-mode and user-mode logic corresponding to the hook point ininet_sock_set_state. In the kernel mode, limit the reporting to information that is determined to be the destination IP of the TLS service and the destination PORT of the TLS service. In the user mode, parse the relevant state and extract the client IP and client PORT.

[0076] Step 2: Upon learning that a TCP connection has been established, immediately set up NFQueue rules to filter traffic proxies containing the four-tuple (client IP, client PORT, TLS service IP, TLS service PORT); extract the ECDHE public key from the TLSServer Hello in the proxies and generate a RA report locally; when a client makes a request with the corresponding ECDHE public key within a short period of time (e.g., 2 seconds), provide an RA report.

[0077] Step 3: Upon learning that a TCP connection is closed, check if there is an NFQueue rule corresponding to the local IP, PORT, and other four-tuples. If so, discard all packets in the queue, delete the NFQueue proxy rule, and generate an alarm log.

[0078] The above embodiments are illustrated using Linux as an example. In practical applications, there are also Windows scenarios, which are similar to Linux, except that the hook points for TCP establishment and closure are obtained differently, and instead of using NFQueue proxy, WinDivert proxy is used. These will not be elaborated upon further. The client and server do not need to be both Windows / Linux; different operating systems are acceptable because the interaction process between the two ends is unrelated to the hook points. The above process considers blocking mode. If auditing mode is considered, it is only necessary not to intercept packets, but to generate alarm logs only when the RA reports a verification failure.

[0079] The above embodiment describes the verification process on the server side. The verification process on the client side will be described next.

[0080] For client-side verification scenarios, there will be slight adjustments compared to the server-side verification process. Figure 7 A schematic diagram of a confidential network framework based on kernel probes provided in an embodiment of this application; Figure 8 A schematic diagram of a Linux-based kernel probe proxy provided for an embodiment of this application; Figure 9 This is a schematic diagram illustrating a Windows kernel probe-based proxy provided in an embodiment of this application. Figure 9 In the example, since IPv4 is still the mainstream, recv_accept4 is used, and no restrictions are imposed in actual application.

[0081] See Figures 7 to 9The core issue is that the server needs to verify that the client is in a confidential environment as expected. Therefore, it's necessary to perform appropriate traffic interception on the server side, and for both parties to extract the ECDHE key information from the TLS client (i.e., the Client Hello). During this process, tracepoints / socks / inet_sock_set_state or relevant Windows hooks can be used to obtain TCP session establishment and termination information. Other processes are similar; the original client and server logic can be simply replaced, so they will not be elaborated here.

[0082] In addition, in practical applications, there are also scenarios requiring two-way verification, which means verifying both the server and the client simultaneously.

[0083] Figure 10 This is a schematic diagram of a confidential network framework based on kernel probes provided in an embodiment of this application. Figure 11 This is a schematic diagram of a kernel probe-based proxy provided in an embodiment of this application.

[0084] See Figure 10 and Figure 11 In kernel mode, the hook points remain unchanged; ultimately, they still retrieve the client's port and session state information. In the user-space traffic proxy component, the key information needs to be extracted from both the Client Hello and Server Hello. Then, each component is signed using its own RA (Real Estate Name), and the client sends its own RA and requests the server's RA. After each verifies the other's RA, the local proxy rule is deleted. Figure 11 In the example, since IPv4 is still the mainstream, the connect4 example is used. In actual application, no restrictions are imposed.

[0085] In summary, the embodiments of this application, based on the RA security enhancement framework and algorithm using traffic proxy and kernel-mode probe, combine information obtained from the kernel probe with traffic analysis and processing algorithms. Specifically, it includes various details such as how to extract client ports, enable the proxy, verify RA, disable the proxy, extract public keys, and allow or block traffic. It also needs to consider three scenarios: server verification, client verification, and two-way verification. It also includes kernel function hook points based on kernel-mode probes, hook points of kernel-mode probes specifically used in Windows / Linux, and their functions.

[0086] like Figure 12 As shown, based on the same inventive concept as the relay attack verification method described above, this application embodiment also provides a relay attack verification device. The device is applied to a client, and the first process of the client includes a first processing unit 121 and a first transmission unit 122.

[0087] The first processing unit 121 is used to: monitor the target traffic indicated by the pre-set filtering rules, and parse the target traffic to obtain the first public key; wherein the filtering rules are used to filter the traffic indicated by the set filtering parameters, and the set filtering parameters include the destination IP, destination port, source IP and source port. The first transmission unit 122 is used to: send a first request to the server based on the first public key; The first transmission unit 122 is further configured to: receive a first remote certification report sent by the server according to the first request; The first processing unit 121 is further configured to: verify the server based on whether the public key parsed from the first remote proof report is the same as the first public key.

[0088] In one optional implementation, the first processing unit 121 is specifically used for: If the public key parsed from the first remote proof report is the same as the first public key, then the verification result for the server is determined to be successful.

[0089] In an optional implementation, the first processing unit 121 is further configured to, after verifying the server based on whether the public key parsed from the first remote proof report is the same as the first public key, if the verification fails, or if no verification result is detected after a preset time, discard the target traffic, send an RST packet to block the current session, and generate an alarm log.

[0090] In an optional implementation, the first processing unit 121 is further configured to: Determine the IP address of the TLS service as the destination IP address, and determine the port of the TLS service as the destination port; Determine the local IP and local port based on the destination IP and destination port.

[0091] In an optional implementation, the first processing unit 121 is further configured to: If a TCP connection is detected to be closed, the system checks if the filtering rule exists. If it does, the system discards the traffic packets corresponding to the target traffic, deletes the filtering rule, and generates an alarm.

[0092] In an optional implementation, the first processing unit 121 is further configured to: Allow packets during the TLS session phase, and intercept packets containing real data.

[0093] like Figure 13 As shown, based on the same inventive concept as the relay attack verification method described above, this application embodiment also provides a relay attack verification device, which is applied to the server side and includes a second processing unit 131 and a second transmission unit 132.

[0094] The second processing unit 131 is used to: monitor the target traffic indicated by the pre-set filtering rules, and parse the target traffic to obtain the second public key; wherein the filtering rules are used to filter the traffic indicated by the set filtering parameters, and the set filtering parameters include the destination IP, destination port, source IP and source port. The second processing unit 131 is further configured to: generate a first remote proof report based on the second public key; The second transmission unit 132 is configured to send a first remote report to the client upon receiving a first request from the client within a set time interval, so that the client can verify the server based on whether the public key parsed from the first remote verification report is the same as its own first public key.

[0095] In an optional implementation, the second processing unit 131 is further configured to: If a TCP connection is detected to be closed, the system checks if the filtering rule exists. If it does, the system discards the traffic packets corresponding to the target traffic, deletes the filtering rule, and generates an alarm.

[0096] The relay attack verification device proposed in this application adopts the same inventive concept as the above-mentioned relay attack verification method and can achieve the same beneficial effects, so it will not be described again here.

[0097] Based on the same inventive concept as the relay attack verification method described above, this application also provides an electronic device, which can specifically be a desktop computer, portable computer, smartphone, tablet computer, personal digital assistant (PDA), etc., wherein a client can be integrated, and the electronic device can also be a server, etc. Figure 14 As shown, the electronic device may include a processor 141 and a memory 142.

[0098] Processor 141 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0099] Memory 142, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. Memory 142 in the embodiments of this application may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0100] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned computer storage medium can be any available medium or data storage device that a computer can access, including but not limited to: mobile storage devices, random access memory (RAM), magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)) and other media capable of storing program code.

[0101] Alternatively, if the integrated units described above in this application are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes: mobile storage devices, random access memory (RAM), magnetic memory (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical memory (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor memory (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs), etc.) and other media capable of storing program code.

[0102] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the relay attack verification methods discussed above. Since the principle by which the above computer program product solves the problem is similar to that of the relay attack verification method, the implementation of the above computer program product can refer to the implementation of the method, and repeated details will not be described again.

[0103] The above embodiments are only used to provide a detailed description of the technical solutions of this application. However, the description of the above embodiments is only for the purpose of helping to understand the methods of the embodiments of this application and should not be construed as a limitation on the embodiments of this application. Any changes or substitutions that can be easily conceived by those skilled in the art should be covered within the protection scope of the embodiments of this application.

Claims

1. A relay attack verification method, characterized in that, Applied to a client, the method includes: The client's first process monitors the target traffic indicated by the pre-set filtering rules and parses the target traffic to obtain the first public key; wherein, the filtering rules are used to filter the traffic indicated by the set filtering parameters, and the set filtering parameters include the destination IP, destination port, source IP, and source port; The first process of the client sends a first request to the server based on the first public key; The first process of the client receives the first remote proof report sent by the server according to the first request, and verifies the server based on whether the public key parsed from the first remote proof report is the same as the first public key.

2. The method according to claim 1, characterized in that, The step of verifying the server based on whether the public key parsed from the first remote proof report is the same as the first public key includes: If the public key parsed from the first remote proof report is the same as the first public key, then the verification result for the server is determined to be successful.

3. The method according to claim 2, characterized in that, After verifying the server by checking whether the public key parsed from the first remote proof report is the same as the first public key, the method further includes: If the verification fails, or if no verification result is detected after a preset time, the target traffic is discarded, an RST packet is sent to block the current session, and an alarm log is generated.

4. The method according to claim 1, characterized in that, The method further includes: The IP address of the TLS service is determined as the destination IP address, and the port of the TLS service is determined as the destination port. The local IP and local port are determined based on the destination IP and the destination port.

5. The method according to claim 1, characterized in that, The method further includes: If a TCP connection is detected to be closed, the existence of the filtering rule is checked. If it is, the traffic packet corresponding to the target traffic is discarded, the filtering rule is deleted, and an alarm is generated.

6. The method according to claim 1, characterized in that, The method further includes: Allow packets during the TLS session phase, and intercept packets containing real data.

7. A relay attack verification method, characterized in that, Applied to the server side, the method includes: The second process on the server monitors the target traffic indicated by the pre-set filtering rules and parses the target traffic to obtain the second public key; wherein, the filtering rules are used to filter the traffic indicated by the set filtering parameters, and the set filtering parameters include the destination IP, destination port, source IP and source port; The second process on the server side generates a first remote proof report based on the second public key; If the second process of the server receives a first request from the client within a set time interval, it sends the first remote report to the client so that the client can verify the server based on whether the public key parsed from the first remote proof report is the same as its own first public key.

8. The method according to claim 7, characterized in that, The method further includes: If a TCP connection is detected to be closed, the existence of the filtering rule is checked. If it is, the traffic packet corresponding to the target traffic is discarded, the filtering rule is deleted, and an alarm is generated.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 8.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When executed by a processor, the computer program instructions implement the steps of the method according to any one of claims 1 to 8.

Images