A method and apparatus for verifying a relay attack, an electronic device, and a storage medium

Abstract

Embodiments of the application disclose a relay attack verification method and device, electronic equipment and a storage medium. The method is applied to a client. In the method, first, a first process of the client obtains a target parameter set from a setting component through a first setting tool. The target parameter set includes a public key set, and the public key set includes at least one public key. The setting component points to a memory associated with a user state. Second, the first process of the client sends a first request to a server based on a first public key. The first public key is any one of the public keys in the public key set. Finally, the first process of the client receives a first remote attestation report sent by the server according to the first request, and verifies the server by judging whether the public key parsed from the first remote attestation report is the same as the first public key. By obtaining the public key from the memory, the method can adapt to the verification process in different situations and improve the efficiency of the overall business.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a method, apparatus, electronic device and storage medium for relay attack verification. 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 relay verification scenarios within related technologies, practical applications primarily rely on listening to kernel functions. This involves obtaining port number information from the kernel space, minimizing proxy traffic, and extracting the key from the proxy traffic in user space. While this method offers sufficient performance in most cases, it may still have the following drawbacks: For example, in extreme cases (such as when the network is excellent and the user-space proxy takes effect very slowly, which usually does not occur in actual machines, but is theoretically possible), it may happen that when traffic is provided to user space, the Client Hello / Server Hello information has already been sent and cannot be intercepted, so the key cannot be extracted; or, even if the key is extracted from the proxy traffic in user space, it will affect the efficiency of the overall business. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and storage medium for relay attack verification, which can adapt to the verification process under different circumstances and improve the overall efficiency of the business.

[0005] In a first aspect, one embodiment of this application provides a method for verifying relay attacks. This method is applied to a client and includes: The client's first process obtains the target parameter set from the setting component through the first setting tool; wherein, the target parameter set includes a public key set, and the public key set includes at least one public key; the setting component points to the memory associated with user space; The client's first process sends a first request to the server based on the first public key; where the first public key is any public key in the public key set. 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 determining whether the public key parsed from the first remote authentication report is the same as the first public key.

[0006] The relay method provided in this application is applied to a client and is executed by a first process of the client. The first process of the client first obtains a target parameter set from a setting component through a first setting tool. This target parameter set includes a public key set, which includes at least one public key. The setting component points to memory associated with user space. Secondly, based on the first public key, a first request is sent to the server. The first public key is any public key in the public key set. Finally, the first remote authentication report sent by the server according to the first request is received, and the server is verified by determining whether the public key parsed from the first remote authentication report is the same as the first public key. This design allows the public key to be directly obtained from memory for server verification. Compared with related technologies that extract keys from proxy traffic, this design can adapt to verification processes under different circumstances, improving overall business efficiency.

[0007] Secondly, one embodiment of this application provides a method for verifying relay attacks, which is applied to a server and includes: The second process on the server side obtains the second public key of the first handshake traffic from the configuration component through the first configuration tool; wherein, the configuration component points to the memory associated with user space; The second process on the server side generates the first remote proof report based on the second public key; The second process on the server receives the first request from the client, parses the first request, and obtains the first public key. If the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, the first remote proof report is sent 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 the second public key.

[0008] The relay method provided in this application is applied to the server side, and is executed by a second process on the server side. The second process first obtains the second public key of the first handshake traffic from a configuration component (which points to user-space associated memory) using a first configuration tool. This first handshake traffic can be TLS Server Hello handshake traffic. Next, based on the second public key, a first remote authentication report is generated. During this process, the second process uses the second public key as a random value and generates the first remote authentication report based on this random value. Finally, it receives a first request from the client, parses the request to obtain the first public key, and if the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, the first remote authentication report is sent to the client. This allows the client to verify the server based on whether the public key parsed from the first remote authentication report matches the second public key. This design allows direct retrieval of the public key from memory for server verification. Compared to extracting keys from proxy traffic in related technologies, this approach adapts to different verification scenarios and improves overall business efficiency.

[0009] Thirdly, one embodiment of this application provides a relay attack verification apparatus applied to a client, the apparatus comprising a first processing unit and a first transmission unit: The first processing unit is configured to obtain a target parameter set from a setting component using a first setting tool; wherein the target parameter set includes a public key set, and the public key set includes at least one public key; the setting component points to memory associated with user mode; The first transmission unit is used to send a first request to the server based on a first public key; wherein the first public key is any public key in the public key set; The first transmission unit is used to receive the first remote certification report sent by the server in accordance with the first request; The first processing unit is used to verify the server by determining 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 apparatus, which is applied to a server and includes a second processing unit and a second transmission unit: The second processing unit is configured to: obtain the second public key of the first handshake traffic from the configuration component through the first configuration tool; wherein the configuration component points to the memory associated with user space; The second processing unit is used to: generate a first remote proof report based on the second public key; The second transmission unit is used to: receive a first request from the client; The second processing unit is used to: parse the first request and obtain the first public key; The second transmission unit is used to send a first remote proof report to the client when the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, 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 the second 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 flowchart illustrating a relay attack verification method provided in one embodiment of this application; Figure 2 A flowchart illustrating another relay attack verification method provided in an embodiment of this application; Figure 3 The flowchart of another relay attack verification method provided in an embodiment of this application; Figure 4 A schematic diagram of a confidential network framework based on kernel probes for verifying a server in an audit mode, provided as an embodiment of this application; Figure 5 A schematic diagram of a confidential network framework based on kernel probes for verifying a server in blocking mode, provided as an embodiment of this application; Figure 6 A schematic diagram of a confidential network framework based on kernel probes for verifying a client in blocking mode, provided as an embodiment of this application; Figure 7 A schematic diagram of a kernel probe-based confidential network framework for bidirectional verification in blocking mode provided in an embodiment of this application; Figure 8 This is a schematic diagram of the overall flow from a session perspective in a blocking mode, provided as an embodiment of this application. Figure 9 A schematic diagram of a relay attack verification device provided in an embodiment of this application; Figure 10 A schematic diagram of a relay attack verification device provided in an embodiment of this application; Figure 11 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) User-space probe (uprobe) is a kernel mechanism that allows probes to be set for specific functions or code locations in the user control (i.e., the memory area where ordinary applications run) to monitor and analyze the execution process of these codes. In practice, in the binary formed by software written in compiled languages ​​(such as C, C++, Go, Rust, etc.), there are usually several functions that are in an interceptable state by default (unless the function is manually specified as an inline function or a static function when writing the code). These functions can be intercepted by the uprobe mechanism and jump to a customizable logic with context information such as function parameters. When using uprobe, two pieces of information are usually required: one is the file location of the binary (e.g., / usr / lib / libssl.so), and the other is the name of the specific symbolic function to be intercepted. Generally, uprobe can only be used well in conjunction with the eBPF mechanism after the Linux kernel version 4.17 to observe several hook points in this application.

[0018] 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.

[0019] In the verification process of relay attacks using related technologies, this is mainly accomplished by listening to kernel functions. For example, port number information is obtained from the kernel space, proxy traffic is minimized, and the key is extracted from the proxy traffic in user space. This method is sufficient in most cases, but it may still have the following drawbacks: Defect 1: In extreme cases (excellent network, extremely slow user-space proxy activation, usually not seen in actual machines, but theoretically possible), it may happen that when traffic is provided to user space, the Client Hello / Server Hello information has already been sent and cannot be intercepted, thus making it impossible to extract. In this case, the relevant technical solutions cannot solve the problem.

[0020] Defect 2: When only verifying that the server / client is in a confidential environment, the purpose of user-space proxying of traffic by the server / client is to extract the corresponding ECDHE key. Although only a small amount of traffic is proxied using kernel-space probes, it still incurs some performance overhead and first-packet latency. Furthermore, in this scenario, the server / client must first generate the ECDHE key in memory before sending it to the client / server in the traffic. Therefore, capturing it from memory allows for earlier acquisition of the ECDHE key and local generation of the RA report, which can reduce client verification latency to some extent (e.g., the client's verification request arrives before the server's RA report is generated), thus allowing the client to grant access earlier and ultimately improving overall business efficiency. Defect 3: In audit-only mode, the server / client also needs to proxy a small amount of traffic in order to extract and parse the TLS key (i.e., the ECDHE key), which will also bring some performance overhead and first packet latency. Due to availability considerations, audit-only mode is usually the main mode used in practice, so performance optimization in this case is relatively important.

[0021] Therefore, this application provides a solution based on a combination of user-space probes and kernel-space probes. Since eBPF in Windows systems does not yet support user-space probes, this application is currently only applicable to Linux systems (with a kernel version of at least 4.17); however, if Windows systems subsequently support equivalent capabilities through other methods, the approach to Linux in this application can also be largely applied to Windows systems.

[0022] The core idea of ​​this application is that the ECDHE key, or a subsequent key negotiated based on ECDHE, actually appears in memory. Specifically, it appears in the memory controlled by the process corresponding to the binary executable file of the library component that performs TLS encryption (such as openssl / boringssl / gnutls / gotls, etc.). Using an uprobe user-space probe, the exported functions of these binary executable files can be hooked, and their parameter information can be obtained. This allows the desired key information to be obtained directly from memory, without needing to extract it from the network traffic, thus eliminating the need for traffic forwarding and overcoming the aforementioned shortcomings.

[0023] It should be noted that this method only avoids extracting the ECDHE key from the traffic. If traffic interception is required, tools such as NFQueue / WinDivert are still needed.

[0024] Referring to the foregoing embodiments, the process of "properly hooking the exported functions of the user-mode binary executable" requires verification of eBPF and uprobe support, thus placing higher demands on the Linux kernel version. Distinguishing itself from the NIRAK (Non-Intrusive RA based on Kprobe) + TLS scheme in related technologies, the scheme in this application embodiment can be called the NIRAK (Non-Intrusive RA based on uprobe and Kprobe) + TLS scheme.

[0025] Furthermore, compared to obtaining ECDHE information from traffic in related technologies, this application needs to specify the specific SSL implementation component (e.g., OpenSSL or BoringSSL), as the exported functions of the hook differ depending on the SSL component. Therefore, for the sake of generality, this application describes the uprobe hook function points of mainstream SSL components: OpenSSL server (version 1.0): SSL_do_handshake OpenSSL client (version 1.0): SSL_get_wbio, SSL_state OpenSSL server (versions 1.1 and 3.0+): SSL_do_handshake OpenSSL client (versions 1.1, 3.0+): SSL_get_wbio, SSL_in_before BoringSSL server-side: SSL_do_handshake BoringSSL client: SSL_get_wbio, SSL_in_init gnutls server and client: gnutls_handshake NSS server and client: SSL_ForceHandshake gotls server and client: crypto / tls. Config).writeKeyLog The hook points mentioned above may be the optimal ones, capable of capturing the desired ECDHE key or session key with minimal performance overhead (these functions are triggered infrequently). However, other derived functions may also be able to capture it. Therefore, this is merely an example and does not constitute a specific limitation.

[0026] The following section explains how monitoring sockets to minimize the impact of NFQueue proxying requires the use of kprobe points in related technologies: 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 mode, and then filtered in kernel mode based on the known server IP and PORT, and the corresponding complete four-tuple is sent back to user mode to further obtain information on the start and end of the TCP session, as well as the corresponding client PORT. Here, in order to associate the key and four-tuple session obtained from the TLS side, it is also necessary to obtain process information from the above hook point and TLS-related hook points; consistency between the two sides is sufficient for association. In addition, if the server is a high Linux version, the scheme in this application can be used; if the client is another version or system, the scheme in related technologies can be used. It is not necessary for both the client and server to be based on a specific scheme.

[0027] Before introducing the specific scheme of this application, it is necessary to explain some information used in this application.

[0028] ① 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).

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

[0030] ③ 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).

[0031] 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.

[0032] The technical solutions provided in the embodiments of this application will be described below.

[0033] 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.

[0034] refer to Figure 1 This application provides a method for verifying relay attacks, applied to a client, the method comprising the following steps: S101: The first process of the client obtains the target parameter set from the setting component through the first setting tool.

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

[0036] The first public key is any public key in the public key set.

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

[0038] The relay method provided in this application is applied to a client and is executed by a first process of the client. The first process of the client first obtains a target parameter set from a setting component through a first setting tool. This target parameter set includes a public key set, which includes at least one public key. The setting component points to memory associated with user space. Secondly, based on the first public key, a first request is sent to the server. The first public key is any public key in the public key set. Finally, the first remote authentication report sent by the server according to the first request is received, and the server is verified by determining whether the public key parsed from the first remote authentication report is the same as the first public key. This design allows the public key to be directly obtained from memory for server verification. Compared with related technologies that extract keys from proxy traffic, this design can adapt to verification processes under different circumstances, improving overall business efficiency.

[0039] Regarding S101, the target parameter set includes a public key set, which contains at least one public key; the configuration component points to the user-space associated memory. In a specific example, the first configuration tool could be an uprobe, and the configuration component could be a TLS component.

[0040] Regarding S102, since the public key set includes multiple public keys, we will use one of them as an example for explanation, referring to it as the first public key. The client's first process sends the first request to the server based on the first public key. It should be noted that the first public key here refers to the public key in the ECDHE temporary key; therefore, for ease of description, it can be called the first public key or the ECDHE key.

[0041] In the case of S103, after the first process of the client sends the first request to the server, the server sends the first remote proof report to the first process of the client according to the first request, parses the first remote proof report, compares the parsed public key with the first public key, and verifies the server based on whether the comparison results are the same.

[0042] During the verification process, 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, that is, the verification fails.

[0043] In practical applications, the following operations can be performed in case of verification failure: For example, the target parameter set also includes a first process information set. In this case, if the verification fails after verifying the server, an alarm message is triggered. The alarm message carries the first process information, which corresponds to the first public key.

[0044] The above embodiments are in audit mode. Compared with audit mode, blocking mode has some additional operations. The following describes the relay attack verification process in the blocking scenario. Figure 2 This is a schematic diagram illustrating another relay attack verification method provided in an embodiment of this application. Figure 2 It should include at least the following steps: S201: The client's first process obtains the port information set and the second process information set through the second configuration tool.

[0045] The second process information refers to any one of the process information sets. Optionally, the second setting tool can be inet_sock_set_state.

[0046] S202: The client's first process determines the target traffic packet based on the pre-established association, first process information, and second process information.

[0047] The pre-established association is an association of at least one port information, at least one public key, and at least one process information; the target traffic packet is the traffic packet of the first port corresponding to the first public key.

[0048] S203: If TLS-related information is detected, the client's first process allows the target traffic packets during the TLS session.

[0049] S204: For traffic containing real data, if the server's verification result is unsuccessful or no verification result is detected within a set time, the client's first process will discard the traffic containing real data and send an RST packet; if the verification passes, the target traffic packet will be allowed to pass.

[0050] In this embodiment of the application, in response to the problem that traffic packets cannot be directly obtained from memory, the target traffic packets are determined by using port information, public keys and the relationship between processes, thus realizing the verification process, and traffic is intercepted or allowed based on the actual verification results.

[0051] The above embodiments describe the operations performed by the client in a server-side verification scenario. The following section will explain the operations performed by the server in this scenario. Figure 3 A flowchart illustrating a relay attack verification method provided in this application embodiment, applied to the server side. Figure 3 It should include at least the following steps: S301: The second process on the server side obtains the second public key of the first handshake traffic from the configuration component through the first configuration tool.

[0052] This involves setting the component to point to the memory associated with user space. The first handshake traffic can be the TLS Server Hello handshake traffic.

[0053] S302: The second process on the server generates a first remote proof report based on the second public key; During this process, the second process on the server side uses the second public key as a random value and generates the first remote proof report based on the random value.

[0054] S303: The second process on the server receives the first request from the client, parses the first request, obtains the first public key, and if the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, the first remote proof report is sent 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 the second public key.

[0055] The relay method provided in this application is applied to the server side, and is executed by a second process on the server side. The second process first obtains the second public key of the first handshake traffic from a configuration component (which points to user-space associated memory) using a first configuration tool. This first handshake traffic can be TLS Server Hello handshake traffic. Next, based on the second public key, a first remote authentication report is generated. During this process, the second process uses the second public key as a random value and generates the first remote authentication report based on this random value. Finally, it receives a first request from the client, parses the request to obtain the first public key, and if the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, the first remote authentication report is sent to the client. This allows the client to verify the server based on whether the public key parsed from the first remote authentication report matches the second public key. This design allows direct retrieval of the public key from memory for server verification. Compared to extracting keys from proxy traffic in related technologies, this approach adapts to different verification scenarios and improves overall business efficiency.

[0056] To make the technical solution of this application easier to understand, the following specific example illustrates the process of verifying the server: Figure 4 This is a schematic diagram of a confidential network framework based on kernel probes for verifying the server in an audit mode, as provided in an embodiment of this application.

[0057] See Figure 4 The first process on the client performs the following operations: First, observe the TLS temporary key. Specifically, obtain the ECDHE key and process information from the Server Hello using the uprobe. Second, request RA report verification. Specifically, request remote verification using the aforementioned ECDHE key as a challenge value. After receiving the return result, return and verify it. If verification fails, trigger an alarm message. Although the alarm message cannot contain the local port, it can contain prompts such as the process name.

[0058] See also Figure 4 The second process on the server performs the following operations: First, observe the TLS temporary key. Specifically, obtain the ECDHE key from the Server Hello using the uprobe; record the current time as the generation time; second, generate the RA report, specifically by generating the RA report based on the aforementioned ECDHE key as the challenge value; finally, return the corresponding RA report: when a request carrying the ECDHE key requests an RA report, verify whether the ECDHE key was recently generated (e.g., 2 seconds). If so, return the RA report.

[0059] Figure 5 This is a schematic diagram of a confidential network framework based on kernel probes for verifying a server in blocking mode, as provided in an embodiment of this application.

[0060] See Figure 5 The first process on the client performs the following operations: First, observe the TCP connection information. Specifically, observe the TCP establishment information through the aforementioned `inet_sock_set_state` point to obtain port and process information. Second, observe the TLS ephemeral key. Specifically, obtain the ECDHE key and process information from the Server Hello using the uprobe. Third, request RA report verification. Specifically, associate a specific ECDHE key with a specific local port based on the process information (PID information) obtained from both TCP and TLS. Use the aforementioned ECDHE key as a challenge value to request remote verification. Verify the returned result using RA. Finally, proxy the traffic. Specifically, based on the port information, proxy the traffic (proxies refer to the behavior of copying from kernel space to user space, replacing the operating system). At this point, there is no need to parse the TLS key information from the traffic. If TLS-related information is encountered, allow it directly. If real data traffic is encountered, wait for a judgment based on the RA report. If the verification fails, or if no verification result is received within a timeout (e.g., 3 seconds), discard the traffic and terminate the TCP session by sending an RST packet. If the verification passes, allow the traffic on the corresponding port and close the NFQueue proxy.

[0061] See also Figure 5The operations performed by the second process on the server side are the same as those in audit mode, so they will not be elaborated here.

[0062] Compared with related technologies, in this application, the Nonce value used as the challenge value can be either the party's ECDHE key or other keys such as the session key negotiated further (but these keys cannot be transmitted directly, they must be hashed first before transmission).

[0063] The above embodiments are for verifying the server side. The following examples will illustrate the process of verifying the client side: Figure 6 This is a schematic diagram of a confidential network framework based on kernel probes for verifying a client in blocking mode, provided in an embodiment of this application.

[0064] See Figure 6 Verifying the client and server status is essentially a mirror image of each other. The blocking mode is illustrated here, and further details will not be elaborated upon. In audit mode, there is also no need to listen on the socket or set up an NFQueue proxy.

[0065] Figure 7 This is a schematic diagram of a kernel probe-based confidential network framework for bidirectional verification in blocking mode, provided as an embodiment of this application.

[0066] See Figure 7 The process of two-way verification is illustrated, which is essentially a combination of the first two, and will not be elaborated here.

[0067] It should be noted that if the ECDHE public keys on both the client and server sides are not used here, the negotiated session key (and its hash value calculated locally) can also be used. In this case, only one value needs to be observed, and both parties can use this value as a nonce to initiate remote authentication. In this embodiment, the key observed from the TLS library can use the session key, and its hash value can be used as a challenge, which has the same security effect as the ECDHE public key.

[0068] in addition, Figure 8 This is a schematic diagram illustrating the overall flow from a session perspective in a blocking mode, as provided in an embodiment of this application. Only the blocking mode is used as an example here; the audit mode is similar and will not be elaborated upon.

[0069] See Figure 8 By using an independent process, it ensures that the forced insertion of TEE remote verification does not require modification of the original business code. This essentially leverages the high privilege capabilities of the operating system. Because it is an independent process (or even multiple different processes jointly deciding on it), its performance far surpasses that of solutions such as RA-TLS, which directly modify the TLS certificate level.

[0070] Therefore, it can be any custom verification logic, not just TEE remote verification logic. For example, in a trusted data space, it may be necessary to set custom identity authentication (user identity, device identity) rules. Theoretically, these rules can be completed on the business code side or extracted and completed on the network side.

[0071] In practical applications, the effect achieved on the network side is as follows: Adding coding to a complex system is prone to problems and is typically time-consuming. If the system is already running and cannot be restarted, it cannot be implemented by modifying the application layer; it needs to be implemented on the network side in this pluggable manner. Since HTTP (or other application layer protocols) may be short-lived, the verification logic and the actual processing logic may not be in the same HTTP request. If an attacker forges the server in real time after verification, the verification may not be valid (while in this embodiment, strongly binding the ECDHE key or derived session key to the custom verification process can circumvent this problem).

[0072] Thus, the technical solutions of this application are not only applicable to trusted computing or trusted execution environments, but can also be used in any scenario that requires enhanced identity verification beyond standard TLS verification.

[0073] In summary, the embodiments of this application have the following beneficial effects: First, the hash value of the TLS ECDHE public key generated internally by the trusted party or the negotiated session key is used as the remote proof nonce challenge value. This design can resist relay attacks in the event that the TLS key has been leaked. This is based on the aforementioned specific nonce value or hash value, and both values ​​can be extracted from mainstream SSL libraries through the uprobe mechanism.

[0074] Second, the design of the RA enhancement algorithm based on user-space probes and kernel-space probes, specifically, the method of obtaining TLS keys and processes based on user-space probes, and the linkage method with kernel-space probes, traffic proxies, RA proofs, etc.; similarly, it is necessary to consider three cases: server verification, client verification, and two-way verification.

[0075] Third, the design of user-space probe-based hook points is as follows: the specific hook points under different TLS libraries (and their different versions) all serve the same purpose: to obtain the ECDHE key or session key from a suitable memory offset value. Fourth, the design of a general-purpose, pluggable, custom authentication framework can be used not only for remote authentication scenarios but also for custom authentication logic scenarios, and it has advantages in security or implementation compared to implementing it directly at the application layer.

[0076] like Figure 9 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 a client and includes a first processing unit 91 and a first transmission unit 92.

[0077] The first processing unit 91 is configured to obtain a target parameter set from a setting component through a first setting tool; wherein the target parameter set includes a public key set, and the public key set includes at least one public key; the setting component points to memory associated with user mode; The first transmission unit 92 is used to send a first request to the server based on a first public key; wherein the first public key is any public key in the public key set; The first transmission unit 92 is used to receive the first remote certification report sent by the server according to the first request; The first processing unit 91 is used to verify the server by determining whether the public key parsed from the first remote proof report is the same as the first public key.

[0078] In one optional implementation, the first processing unit 91 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.

[0079] In one alternative implementation, the target parameter set further includes a first process information set; The first processing unit 91 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, trigger an alarm message if the verification fails; wherein the alarm message carries first process information, and the first process information corresponds to the first public key.

[0080] In an optional implementation, the first processing unit 91 is further configured to: The client's first process obtains a set of port information and a set of second process information through a second configuration tool; wherein, the second process information is any one of the process information in the second process information set; The first process of the client determines the target traffic packet based on the pre-established association, the first process information, and the second process information; wherein, the pre-established association is an association of at least one port information, at least one public key, and at least one process information; the target traffic packet is the traffic packet of the first port corresponding to the first public key; If TLS-related information is detected, the client's first process allows the target traffic packets during the TLS session phase. For traffic containing real data, if the server's verification result is "failed" or no verification result is detected within a set time, the client's first process discards the traffic containing real data and sends an RST packet; if the verification passes, the target traffic packet is allowed to pass.

[0081] like Figure 10 As shown, based on the same inventive concept as the relay attack verification method described above, this application also provides a relay attack verification apparatus. This apparatus is applied to a server and includes a second processing unit 101 and a second transmission unit 102. The second processing unit 101 is configured to: obtain the second public key of the first handshake traffic from the setting component through the first setting tool; wherein the setting component points to the memory associated with user space; The second processing unit 101 is used to: generate a first remote proof report based on the second public key; The second transmission unit 102 is configured to: receive a first request from a client; The second processing unit 101 is used to: parse the first request and obtain the first public key; The second transmission unit 102 is used to: send a first remote proof report to the client when the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, 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 the second public key.

[0082] In one alternative implementation, the first handshake traffic is the TLS Server Hello handshake traffic.

[0083] In one optional implementation, the second processing unit 101 is specifically used for: The second process on the server side uses the second public key as a random value and generates a first remote proof report based on the random value.

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

[0085] 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 11 As shown, the electronic device may include a processor 111 and a memory 112.

[0086] Processor 111 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.

[0087] Memory 112, 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 112 in this embodiment may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0088] 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.

[0089] Alternatively, if the integrated units described above 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 related technologies, 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 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), etc.) and other media capable of storing program code.

[0090] 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.

[0091] 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 method of relay attack verification, the method comprising: Applied to a client, the method includes: The first process of the client obtains a target parameter set from a setting component through a first setting tool; wherein, the target parameter set includes a public key set, and the public key set includes at least one public key; the setting component points to memory associated with user space; The first process of the client sends a first request to the server based on the first public key; wherein the first public key is any one of the public keys in the public key set; 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 by determining 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, The target parameter set also includes a first process information set; 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 verification fails, an alarm message is triggered; wherein the alarm message carries first process information, and the first process information corresponds to the first public key.

4. The method according to claim 1, characterized in that, The method further includes: The first process of the client obtains a set of port information and a set of process information through a second setting tool; wherein, the second process information is any one of the process information in the second process information set; The first process of the client determines the target traffic packet based on a pre-established association, the first process information, and the second process information; wherein the pre-established association is an association of at least one port information, at least one public key, and at least one process information; and the target traffic packet is the traffic packet of the first port corresponding to the first public key. If TLS-related information is detected, the first process of the client allows the target traffic packet during the TLS session phase; For traffic containing real data, if the server's verification result is "failed" or no verification result is detected within a set time, the client's first process discards the traffic containing real data and sends an RST packet; if the verification passes, the target traffic packet is allowed to pass.

5. A method for verifying relay attacks, characterized in that, Applied to the server side, the method includes: The second process of the server obtains the second public key of the first handshake traffic from the setting component through the first setting tool; wherein, the setting component points to the memory associated with user space; The second process on the server side generates a first remote proof report based on the second public key; The second process of the server receives a first request from the client, parses the first request to obtain a first public key, and if the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, then the first remote proof report is sent 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 the second public key.

6. The method according to claim 5, characterized in that, The first handshake traffic is the TLS Server Hello handshake traffic.

7. The method according to claim 5, characterized in that, The second process on the server generates a first remote proof report based on the second public key, including: The second process on the server side uses the second public key as a random value and generates the first remote proof report based on the random value.

8. A device for verifying relay attacks, characterized in that, Applied to a client, the device includes a first processing unit and a first transmission unit: The first processing unit is configured to obtain a target parameter set from a setting component using a first setting tool; wherein the target parameter set includes a public key set, the public key set includes at least one public key; and the setting component points to user-mode associated memory. The first transmission unit is configured to send a first request to the server based on a first public key; wherein the first public key is any one of the public keys in the public key set; The first transmission unit is configured to receive a first remote authentication report sent by the server in accordance with the first request; The first processing unit is used to verify the server by determining whether the public key parsed from the first remote proof report is the same as the first public key.

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

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

Images