Data security verification method, system, device, equipment, medium and product

Abstract

Embodiments of the present application provide a data security verification method, system, device, equipment, medium and product. The method comprises: determining, by an entry node, a security verification line identifier according to a service message corresponding to a service flow, constructing a first verification tag according to the security verification line identifier, the service message, a first key corresponding to the entry node and an initial hop sequence number, and sending the service flow carrying the first verification tag; determining, by a target intermediate node, a detection mode of the target intermediate node; detecting, by the target intermediate node, the service flow according to a detection process corresponding to the detection mode to obtain a service flow detection result; constructing a second verification tag; sending the service flow carrying the second verification tag to an exit node; and in response to detection of the second verification tag by the exit node, obtaining a security detection result of the service flow. According to the embodiments of the present application, the reliability of the security verification process of the network system is improved.

Description

Technical Field

[0001] This invention belongs to the field of data security technology, and in particular relates to a data security verification method, system, device, equipment, medium and product. Background Technology

[0002] In network systems, data traffic from external or cross-domain networks typically requires multiple security checks before entering the target business system to mitigate potential attack risks, meet compliance requirements, or ensure business stability. To achieve these objectives, the network side usually employs a multi-level security processing chain deployment approach, implementing layered and progressive security processing on the same data flow.

[0003] In a multi-level security processing chain, each node performs checks independently, and the results are only recorded locally as logs or statuses, without being transmitted with the data stream. Alternatively, the system may attempt to write tags representing the checks to the data packets to optimize performance, but it lacks a unified generation and verification mechanism. As a result, downstream nodes cannot verify whether upstream checks were actually performed based on data plane information, nor can they confirm whether the data stream strictly follows the predetermined order to complete all checks.

[0004] Therefore, improving the reliability of the security verification process in network systems is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] This invention provides a data security verification method, system, device, equipment, medium, and product that can improve the reliability of the security verification process in a network system.

[0006] In a first aspect, embodiments of the present invention provide a data security verification method applied to a security verification link, the security verification link including an entry node, at least one intermediate node, and an exit node, the data security verification method including: In response to the ingress node receiving a service flow, a security verification line identifier is determined based on the service message corresponding to the service flow. A first verification tag is constructed based on the security verification line identifier, the service message, the first key corresponding to the ingress node, and the initial hop sequence number. Through the ingress node, the service flow carrying the first verification tag is sent sequentially to the target intermediate nodes in the security verification line identifier, where the security verification line identifier includes multiple intermediate nodes arranged in sequence. In response to the target intermediate node receiving the service flow carrying the first verification tag, the first verification tag is pre-detected, and the detection mode of the target intermediate node is determined based on the pre-detection result. Through the target intermediate node, the service flow is detected according to the detection process corresponding to the detection mode to obtain the service flow detection result. Through the target intermediate node, a second verification tag is constructed based on the first verification tag, the pre-detection result, the service flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node. Through the target intermediate node, the service flow carrying the second verification tag is sent to the egress node. In response to the egress node receiving the service flow carrying the second verification tag, the second verification tag is detected to obtain the security detection result of the service flow.

[0007] In one implementation, a first verification tag is constructed based on the security verification line identifier, the service message, the first key corresponding to the entry node, and the initial hop sequence number, including: determining a first verification value based on the security verification line identifier, the service message, the first key, and the initial hop sequence number; and determining the first verification tag based on the security verification line identifier, the service message, the first verification value, and the initial hop sequence number.

[0008] In one embodiment, determining a first verification value based on a security verification line identifier, a service message, a first key, and a preset verification value generation function includes: determining a security verification policy corresponding to the target intermediate node in the security verification line identifier; extracting key features from the security verification policy to obtain a policy summary corresponding to the security verification policy; determining a service flow identifier based on the service message and a preset identifier constructor; determining a first verification value based on the security verification line identifier, policy summary, service flow identifier, first key, and the preset verification value generation function; and determining a first verification label based on the security verification line identifier, service message, first verification value, and initial hop sequence number includes: determining a first verification label based on the security verification line identifier, policy summary, service flow identifier, first verification value, and initial hop sequence number.

[0009] In one implementation, a first verification tag is constructed based on the security verification line identifier, the service message, the first key corresponding to the ingress node, and the initial hop sequence number, including: generating a random number; and constructing the first verification tag based on the security verification line identifier, the service message, the first key corresponding to the ingress node, the initial hop sequence number, and the random number.

[0010] In one implementation, a pre-detection of the first verification tag is performed, and the detection mode of the target intermediate node is determined based on the pre-detection result. This includes: parsing the first verification tag to obtain a security verification line identifier, a service message, an initial hop sequence number, and a first verification value; determining a second verification value based on the verification handle corresponding to the target intermediate node, the security verification line identifier, the service message, and a preset verification value generation function; determining a value verification result based on the first verification value and the second verification value; and determining the detection mode of the target intermediate node based on the pre-detection result and the value verification result.

[0011] In one embodiment, before determining the detection mode of the target intermediate node based on the pre-detection result and the value verification result, the method further includes: determining the preset intermediate hop sequence number corresponding to the target intermediate node based on the security verification line identifier; determining the detection service message based on the service flow carrying the first verification tag; detecting the initial hop sequence number and the service message respectively based on the preset intermediate hop sequence number and the detection service message, and determining whether the previous node of the target intermediate node belongs to the link topology set corresponding to the target intermediate node to obtain the pre-detection result; determining the detection mode of the target intermediate node based on the pre-detection result and the value verification result includes: determining the detection mode of the target intermediate node as a downgrade detection mode when the pre-detection result indicates that the detection has passed and the value verification result indicates that the verification has passed; or determining the detection mode of the target intermediate node as a strength detection mode when the pre-detection result indicates that the detection has not passed or the value verification result indicates that the verification has not passed.

[0012] In one implementation, a second verification tag is constructed using a target intermediate node based on a first verification tag, a pre-detection result, a service flow detection result, a second key corresponding to the target intermediate node, and an intermediate hop sequence number corresponding to the target intermediate node. This includes: if the pre-detection result indicates that the detection has not passed or the value verification result indicates that the detection has not passed, constructing an anomaly code based on the pre-detection result and / or the value verification result; and constructing the second verification tag based on the anomaly code, the first verification tag, the pre-detection result, the service flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node.

[0013] In one embodiment, the method further includes: if it is determined that the second verification tag contains an abnormal code, determining that the detection mode of the target intermediate node is an intensity detection mode.

[0014] Secondly, embodiments of the present invention provide a data security verification system, which includes an entry node, at least one intermediate node, and an exit node. The data security verification system includes: The ingress node is used to receive the service flow, determine the security verification line identifier according to the service message corresponding to the service flow, and construct the first verification tag according to the security verification line identifier, the service message, the first key corresponding to the ingress node and the initial hop sequence number; The ingress node is used to send the service flow carrying the first verification tag to the target intermediate node in the security verification line identifier in sequence, wherein the security verification line identifier includes multiple intermediate nodes arranged in sequence. The target intermediate node is used to receive the service flow carrying the first verification tag, perform pre-detection on the first verification tag according to the service flow carrying the first verification tag, and determine the detection mode of the target intermediate node according to the pre-detection result. The target intermediate node is used to detect the business flow according to the detection process corresponding to the detection mode, and obtain the business flow detection result; The target intermediate node is used to construct the second verification tag based on the first verification tag, the pre-detection result, the business flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node; The target intermediate node is used to send a service flow carrying a second verification tag to the exit node; The egress node receives the service flow carrying the second verification tag, and performs security detection on the second verification tag based on the service flow carrying the second verification tag to obtain the security detection result of the service flow.

[0015] Thirdly, embodiments of the present invention provide a data security verification device applied to a security verification link, the security verification link including an entry node, at least one intermediate node, and an exit node, the data security verification device including: The first construction module is used to respond to the ingress node receiving a service flow, determine the security verification line identifier according to the service message corresponding to the service flow, and construct the first verification tag according to the security verification line identifier, the service message, the first key corresponding to the ingress node and the initial hop sequence number; The first sending module is used to send a service flow carrying a first verification tag to the target intermediate node in the security verification line identifier in sequence through the entry node, wherein the security verification line identifier includes multiple intermediate nodes arranged in sequence. The determination module is used to respond to the target intermediate node receiving a service flow carrying a first verification tag, perform pre-detection on the first verification tag, and determine the detection mode of the target intermediate node based on the pre-detection result; The first detection module is used to detect the business flow through the target intermediate node according to the detection process corresponding to the detection mode, and obtain the business flow detection result. The second construction module is used to construct the second verification tag through the target intermediate node based on the first verification tag, the pre-detection result, the business flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node; The second sending module is used to send a service flow carrying a second verification tag to the exit node through the target intermediate node; The second detection module is used to detect the second verification tag in response to the egress node receiving a service flow carrying the second verification tag, and obtain the security detection result of the service flow.

[0016] Fourthly, embodiments of this application provide a data security verification device, the device comprising: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the data security verification method of the first aspect or any embodiment of the first aspect.

[0017] Fifthly, a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the data security verification method of the first aspect or any embodiment of the first aspect.

[0018] In a sixth aspect, embodiments of this application provide a computer program product in which instructions, when executed by a processor of an electronic device, cause the electronic device to perform a data security verification method as described in the first aspect or any embodiment of the first aspect.

[0019] The data security verification method, system, apparatus, device, medium, and product of this invention can construct verifiable verification tags that are transmitted along with the flow of data between nodes in the security verification link. This allows the execution status of security checks to be propagated along with the business flow in the form of explicit status information, solving the problem that downstream nodes cannot verify whether upstream checks have actually been executed, and improving the overall reliability of the security verification link. Specifically, each intermediate node performs pre-detection after receiving the verification tag, which can reliably confirm the execution of upstream checks and avoid the omission of security checks by upstream nodes. This forms a real-time verifiable constraint mechanism in terms of execution order and completeness, further improving the reliability of the link execution status. At the same time, since the pre-detection results can be used as a basis for adjusting subsequent detection modes, downstream nodes can dynamically adjust their detection strategies with the premise of obtaining reliable execution status information. This reduces the security risks caused by simplified processing based on untrusted tags and reduces unnecessary duplicate check overhead, thereby achieving a synergistic improvement in system performance while ensuring security. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating a data security verification method provided in an embodiment of the present invention is shown; Figure 2 A schematic diagram of the process for constructing a first verification tag according to an embodiment of the present invention is shown; Figure 3 A flowchart illustrating a detection mode for determining a target intermediate node is shown in one embodiment of the present invention. Figure 4 This diagram illustrates the architecture of a data security verification system according to an embodiment of the present invention. Figure 5 This diagram illustrates the architecture of a data security verification system according to an embodiment of the present invention. Figure 6 A flowchart illustrating a data security verification method provided in an embodiment of the present invention is shown; Figure 7 This is a schematic diagram of the structure of a data security verification device provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a data security verification device provided in an embodiment of the present invention. Detailed Implementation

[0022] The features and exemplary embodiments of various aspects of the present invention will now be described in detail. To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are merely intended to explain the present invention and not to limit the present invention. For those skilled in the art, the present invention can be practiced without some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present invention by illustrating examples of the invention.

[0023] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0024] It should be noted that the acquisition, storage, use, and processing of data in this application embodiment all comply with the relevant provisions of national laws and regulations.

[0025] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0026] In network systems, data traffic from external or cross-domain networks typically undergoes multiple security checks before entering the target business system to mitigate potential attack risks, meet compliance requirements, or ensure business stability. Therefore, the network side usually employs a multi-level security processing chain deployment approach, implementing layered and progressive security processing on the same data flow. In this deployment, different security functions are divided into several security processing nodes according to their responsibilities. Examples include boundary protection functions for access control, intrusion detection functions for identifying abnormal behavior, data leakage prevention functions for content compliance and sensitive information identification, and application protection functions for application-layer attack protection. Furthermore, these security functions are logically arranged in a predetermined order to form a security processing chain, used to perform multi-stage security checks on the same data flow.

[0027] Specifically, data flows are typically directed to the aforementioned security processing chain through one or a combination of mechanisms, including service function chain-based traffic redirection, service identification and forwarding control based on network service headers, logical traffic redirection based on tunnel encapsulation or policy routing, or security function instance orchestration based on virtualization and containerization platforms. This logically ensures that the data flow is sequentially sent to each security processing node for processing, without requiring these security functions to be chained together in the physical topology. After completing its own security checks, each security processing node can forward the data flow to the next node until the entire security processing chain is completed.

[0028] In a multi-level security processing chain, each security processing node generates corresponding check results when performing security checks, such as allowing, blocking, alarming, or risk level assessment. However, these results are mainly used for the node's local decision-making to determine whether to allow the data flow to continue downstream. For the entire system, the check results of each node exist primarily in the form of local status. That is, after completing the check, each node typically only records the results or log information locally for post-event auditing, alarm analysis, or operation and maintenance management. This type of information does not propagate with the data flow and does not directly participate in the real-time processing decisions of subsequent nodes. Furthermore, the check execution status of each node is decoupled from the data plane. The execution of security checks is not encoded into state information that can be recognized by the data plane. When a downstream node receives a data flow, it cannot determine whether the upstream node has performed the corresponding security check based solely on the content of the data packet. Furthermore, the inspection order is implicitly guaranteed by the control or orchestration mechanism. Typically, it only depends on the order of the security processing chain configured by the control plane or orchestration system. However, this order constraint is mainly reflected in the traffic guidance phase, rather than in the state information carried by the data flow itself. Once the data flow is detoured, abnormally forwarded, or the policy is changed during actual operation, downstream nodes cannot determine whether the execution order still meets expectations through data plane information.

[0029] Based on this, in related technologies, to reduce the performance overhead caused by multi-level security processing chains, tags indicating "checked," "low-risk," or "trusted traffic" can be written into data packets to prompt subsequent nodes to reduce redundant checks or perform simplified processing. Specifically, after completing the check, the security processing node writes a flag bit in the packet header or extended fields, or the network side pre-configures security level labels for specific service traffic during the traffic guidance phase, or the control plane system injects security attribute identifiers into specific traffic according to policy configuration. Downstream nodes can use the tags or metadata generated in the above manner to verify and judge the upstream nodes. Furthermore, downstream nodes can also adjust their processing strategies to a certain extent based on tags or metadata to reduce computational overhead or overall latency.

[0030] However, the aforementioned tags or metadata are usually used only as supplementary reference information. Their generation, modification, and dissemination lack a unified constraint mechanism and do not have cross-node verifiable capabilities. Therefore, they are strictly limited in practice and cannot be used as the sole basis for security decisions.

[0031] Therefore, it is understandable that in the multi-level security processing chain of related technologies, although the network side can logically send data streams to multiple security processing nodes through service function chains or traffic redirection mechanisms, downstream nodes cannot determine whether upstream nodes have actually performed the corresponding security checks based on data plane information when processing the data stream. That is, when receiving a data stream, downstream nodes cannot effectively distinguish whether the data stream has completed the upstream checks as expected, whether it bypassed some nodes during operation, or whether it was directly redirected downstream under abnormal circumstances. These uncertainties make it difficult for downstream nodes to use the upstream check execution status as a reliable input condition when making security decisions.

[0032] Meanwhile, the execution order and integrity of the security processing chain cannot be confirmed. Related technologies typically rely on control plane configuration or traffic routing policies to constrain the execution order, but these constraints do not form an explicit, verifiable state representation in the data plane. When network policies are adjusted, topology changes occur, or abnormal forwarding occurs, data flows may deviate from the predetermined order without being noticed. Since the data flow itself does not carry information reflecting the execution state, downstream nodes cannot confirm whether it has strictly followed the predetermined order to complete all necessary checks. This makes it difficult for existing technologies to achieve real-time verification of execution integrity and sequence at the data plane level.

[0033] Furthermore, to improve the overall performance of multi-level security processing chains, some systems may optimize security checks based on tags or metadata, such as reducing duplicate checks or performing simplified processing. However, such tags or metadata lack unified generation rules and cross-node verifiable mechanisms, making their reliability difficult to guarantee. In the absence of verifiable execution information, even if downstream nodes receive tags indicating "checked" or "low risk," they cannot confirm whether these tags truly reflect the check execution status of upstream nodes. Therefore, such optimization mechanisms are typically only used as weak reference conditions in engineering practice and are unlikely to achieve system-level performance optimization without compromising security.

[0034] Therefore, improving the reliability of the security verification process in network systems is a technical problem that urgently needs to be solved in this field. To address the problems of existing technologies, embodiments of the present invention provide a data security verification method, system, apparatus, device, medium, and product.

[0035] The data security verification method provided in the embodiments of the present invention will be introduced below.

[0036] Figure 1 A flowchart illustrating a data security verification method according to an embodiment of the present invention is shown. Figure 1 As shown, the data security verification method is applied to a security verification link, which includes an entry node, at least one intermediate node, and an exit node. The data security verification method may include the following steps: S110. In response to the ingress node receiving a service flow, determine the security verification line identifier based on the service message corresponding to the service flow, and construct the first verification tag based on the security verification line identifier, the service message, the first key corresponding to the ingress node, and the initial hop sequence number.

[0037] S120. Through the entry node, send the service flow carrying the first verification tag to the target intermediate node in the security verification line identifier in sequence, wherein the security verification line identifier includes multiple intermediate nodes arranged in sequence.

[0038] S130. In response to the target intermediate node receiving a service flow carrying a first verification tag, the target intermediate node performs pre-detection on the first verification tag and determines the detection mode of the target intermediate node based on the pre-detection result.

[0039] S140. Through the target intermediate node, the business flow is detected according to the detection process corresponding to the detection mode to obtain the business flow detection result.

[0040] S150. Construct a second verification tag through the target intermediate node based on the first verification tag, the pre-detection result, the business flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node.

[0041] S160. Send a service flow carrying a second verification tag to the exit node through the target intermediate node.

[0042] S170. In response to the egress node receiving a service flow carrying a second verification tag, the second verification tag is checked to obtain the security check result of the service flow.

[0043] For example, a security verification link may include nodes for performing multi-stage security checks on the business flow.

[0044] In one example, a business flow can be data traffic transmitted in the network, which can be input into the corresponding business system after being securely checked by a security verification link.

[0045] A security verification link can include an ingress node, at least one intermediate node, and an egress node. The ingress node is the first node in the security verification link, responsible for receiving the original service flow, constructing an initial verification tag, and introducing the service flow to the intermediate nodes. Further, the intermediate nodes are the security processing nodes in the security verification link, excluding the ingress and egress nodes, used to perform specific security checks on the service flow. The egress node is the last node in the security verification link, responsible for the final verification of the service flow carrying the complete verification tag and outputting the security detection result.

[0046] In one example, intermediate nodes may include one or more, and the type and number of intermediate nodes can be determined according to the verification requirements of different business flows.

[0047] In another example, intermediate nodes can be Security Function Nodes (SFNs). The nodes in the security verification link can be independent hardware security devices (FW / IDS / DLP / WAF Appliances), Virtualized Network Functions (VNFs) / Containerized Network Functions (CNFs), forwarding nodes with security capabilities (such as a border gateway supporting SRv6 / SFC with a security function plugin), or several nodes connected in series via tunneling / orchestration within the same "service chain domain." It's important to understand that nodes in the security verification link are not equivalent to ordinary routers; they typically have forwarding capabilities, but they need to perform security checks, detection, filtering, or protection functions.

[0048] In some embodiments, in S110, after the ingress node receives the service flow, the ingress node can determine the security verification line identifier based on the service message corresponding to the service flow, and construct the first verification tag based on the security verification line identifier, the service message, the first key corresponding to the ingress node, and the initial hop sequence number.

[0049] For example, security verification line identifier It can be used to uniquely identify a security verification link. Understandably, the security verification link identifier contains the sequential arrangement information of the intermediate nodes in the link, used to guide the forwarding path of the service flow.

[0050] In one example, the ingress node parses the business message corresponding to the business flow to determine the security processing chain instance that the business flow needs to enter, and determines the security verification line identifier corresponding to the security processing chain instance.

[0051] For example, the ingress node can construct a first verification tag based on the security verification line identifier, the service message, the first key corresponding to the ingress node, and the initial jump sequence number.

[0052] The first verification tag can be generated by the entry node, enabling subsequent nodes to perform verification based on the first verification tag.

[0053] In some alternative embodiments, Figure 2 This diagram illustrates a flowchart of constructing a first verification tag according to an embodiment of the present invention, as shown below. Figure 2 As shown, the method includes the following steps: S111. Determine the first verification value based on the security verification line identifier, service message, first key, and preset verification value generation function.

[0054] For example, a service message can be a data packet carried in a service flow, containing service content and corresponding network header information, such as a 5-tuple or an equivalent stable field.

[0055] The first key can be the local encryption key corresponding to the entry node. The verification tag can be encrypted based on the first key.

[0056] The preset checksum generation function can be a pre-defined algorithm or function used to calculate and generate a checksum based on input parameters (such as security verification line identifier, service message, key, etc.). For example, the preset checksum generation function can be a hash algorithm, message authentication code algorithm, or digital signature algorithm.

[0057] For example, the security verification line identifier, service message, and first key are calculated by a preset verification value generation function to obtain the verification result, i.e., the first verification value.

[0058] In some optional embodiments, the security verification policy corresponding to the target intermediate node in the security verification line identifier is determined based on the security verification line identifier. Key features are extracted from the security verification policy to obtain a policy digest corresponding to the security verification policy. The service flow identifier is determined based on the service message and a preset identifier constructor. A first verification value is determined based on the security verification line identifier, policy digest, service flow identifier, first key, and a preset verification value generation function.

[0059] For example, a security verification policy can be a set of inspection rules associated with the target intermediate node in the security verification line, used to guide the intermediate node to perform what kind of security inspection operation on the business flow, such as the access control policy of a firewall, the signature database rules of an intrusion detection system, etc.

[0060] Furthermore, after determining the security verification strategy, key features can be extracted from the security verification strategy to obtain a strategy summary corresponding to the security verification strategy.

[0061] In one example, after receiving a service flow, the ingress node can determine the secure processing chain instance that the service flow should enter and generate or parse the secure chain identifier chainId. Further, the ingress node determines the current policy version effective for chainId from the policy repository or orchestration plane output and calculates the policy digest p. For example, the policy digest can be a hash value of the policy content, a version hash value, or a digest fingerprint, etc.

[0062] Understandably, policy summaries can be used to bind tags to policy versions. This way, even if an attacker obtains tags under the old policy, they will be unable to continue evolving and pass verification under the new policy version.

[0063] For example, the service flow identifier can be the result obtained by the ingress node calculating the service message using a preset identifier constructor, used to uniquely identify the service flow. The preset identifier constructor can be a pre-defined function or algorithm. For instance, the preset identifier constructor can be implemented using a hash function, a hash message authentication code, a mapping function, etc.

[0064] In one example, the ingress node constructs a flow identifier (flowId) based on stable fields of the flow. For instance, the flowId can be constructed based on the five-tuple hash of the flow or, in tunnel / slice scenarios, by taking an equivalent combination of stable fields.

[0065] In another example, the flowId can be constructed using the preset identifier constructor shown in the following formula: Among them, flowId is used to identify the business flow and is used for commitment chain binding and cross-hop consistency verification. srcIp represents the source IP address; dstIp represents the destination IP address; srcPort represents the source port number; dstPort represents the destination port number; proto represents the protocol type. These parameters all come from the message; fid() is the default identifier constructor, which can be a hash function or a mapping function.

[0066] For example, after obtaining the policy summary and the service flow identifier, the first verification value can be determined based on the security verification line identifier, the policy summary, the service flow identifier, the first key, and the preset verification value generation function.

[0067] In one example, the first verification value can be obtained by calculating the security verification line identifier, policy digest, service flow identifier, and first key using a preset verification value generation function as shown in the following formula: ;in, The local key material corresponding to the entry node; : Preset check value generation function, which can be implemented using HMAC or hash commitment, and the algorithm form is not restricted.

[0068] Furthermore, in some alternative embodiments, to prevent replay, the ingress node can generate a random number and construct a first verification tag based on the security verification line identifier, the service message, the first key corresponding to the ingress node, the initial hop sequence number, and the random number.

[0069] Taking replay into account, the first checksum above can be expressed as the following formula: ;in, A random number generated for the entry node. This is understandable. Its function is to put Bind to the current business flow to block the replay path of copying historically valid tags to the new flow.

[0070] S112. Determine the first verification tag based on the security verification line identifier, service message, first verification value, and initial jump sequence number.

[0071] For example, the initial hop sequence number can be the sequential position information corresponding to the ingress node, used to identify the sequential position of the ingress node in the verification link. In one example, the ingress node can determine the sequence of nodes for which security checks are required in the service flow based on the security verification line identifier, where each node has a corresponding hop sequence number.

[0072] For example, the ingress node can calculate the first verification tag based on the security verification line identifier, service message, first verification value and initial jump sequence number, so as to transmit the execution fact of the security check to the downstream node.

[0073] In some optional embodiments, the first verification tag can be determined based on the security verification line identifier, policy summary, service flow identifier, first verification value, and initial hop sequence number.

[0074] In one example, the first verification label can be determined based on the security verification line identifier, policy summary, service flow identifier, first verification value, initial hop sequence number, and random number. As shown in the formula below: ;in, This is the initial hop sequence number. Understandably, this is to avoid having to fill in a hop sequence number when the entry node doesn't have a previous hop. The ambiguity can lead to And the label only writes .

[0075] In this embodiment, the introduction of policy digests allows the security verification policy itself to be included within the verifiable scope of the tag. When a downstream intermediate node receives a service flow, it can not only confirm the execution of the upstream check, but also verify whether the security policy to be executed by the node is consistent with the control plane's expectations. This solves the problem that policy configuration deviations or tampering are difficult to detect in a timely manner, further improving the reliability of the verification link from a policy perspective. Simultaneously, the construction of the service flow identifier establishes a unique binding relationship between the verification tag and the service flow. Each node can confirm that the processed service packet is consistent with the one received by the ingress node by comparing the service flow identifier, avoiding the damage to the overall reliability of the verification link caused by attacks such as cross-flow mixing or packet replay.

[0076] Figure 2 In the illustrated embodiment, the security verification line identifier, service message, first key, and initial hop sequence number are integrated and a first verification tag is calculated using a preset verification value generation function. This establishes an immutable binding relationship between the service message content and the security verification line identifier. Any subsequent modification to the service message or line identifier will result in verification failure, thus resolving the reliability issues of downstream nodes being unable to confirm whether upstream checks have been truly executed and whether data flows according to the predetermined link, thereby improving the overall reliability of the security verification link. Furthermore, since the first verification value is generated based on the unique first key of the entry node, downstream nodes can verify this verification value to confirm that the source of the verification tag is indeed a legitimate entry node, avoiding the security risks caused by nodes forging or tampering with tags, further enhancing the credibility of the node security detection process. In addition, the introduction of the initial hop sequence number implies the link order in the verification tag, ensuring the irreversibility of the verification process.

[0077] In some embodiments, in S120, the ingress node may send a service flow carrying a first verification tag to the intermediate node in the destination sequence of the security verification line identifier.

[0078] The security verification line identifier includes multiple intermediate nodes arranged in sequence.

[0079] For example, the target intermediate node can be a node used to receive a service flow carrying a first verification tag. The target node can be determined based on the current node and the multiple sequentially arranged intermediate nodes included in the security verification line identifier. For instance, the node order represented by the security verification line identifier is: ingress node, intermediate node 1, intermediate node 2, egress node. If the current node is the ingress node, the target intermediate node is intermediate node 1; if the current node is intermediate node 1, the target intermediate node is intermediate node 2.

[0080] In some embodiments, in S130, after receiving a service flow carrying a first verification tag, the target intermediate node performs pre-detection on the first verification tag and determines the detection mode of the target intermediate node based on the pre-detection result.

[0081] For example, the detection mode can characterize the working mode of the intermediate node, and different pre-detection results correspond to different detection modes.

[0082] In some alternative embodiments, Figure 3 This diagram illustrates a flowchart of a detection mode for determining target intermediate nodes according to an embodiment of the present invention. Figure 3 As shown, the method includes the following steps: S131. Parse the first check tag to obtain the security check line identifier, service message, initial jump sequence number and first check value.

[0083] For example, the target intermediate node can parse the first check tag to obtain the security check line identifier, service message, initial hop sequence number, and first check value.

[0084] In one example, when the target intermediate node is not the next node after the ingress node in the link, the parameters parsed from the target intermediate node may include... (i.e., execution context), the previous hop sequence number ( ) and the checksum of the previous hop ( ).

[0085] S132. Determine the second verification value based on the verification materials corresponding to the target intermediate node, the security verification line identifier, the business message, and the preset verification value generation function.

[0086] For example, the verification materials may include credential information held by the target intermediate node for verifying the first verification value, corresponding to the first key used by the ingress node to generate the first verification value, and may be a shared key, public key, or verification handle, etc. For example, the orchestration plane may issue the current target intermediate node key, the expected hop order of the current target intermediate node in different chains, the configuration of the current target intermediate node for the "previous hop allowed set", the link topology summary or node set summary, shared key or public key, etc.

[0087] In one example, for each candidate upstream node corresponding to the target intermediate node (i.e., nodes in the allowed set of the previous hop), the target intermediate node can recalculate the checksum and compare consistency based on the locally held verification materials and parsed parameters, according to the checksum update rule to be used in the previous hop (i.e., the preset checksum generation function). The formula is as follows: ;in, () represents the function that generates the preset verification value recorded in the intermediate node of the target; This could be a shared key or public key, etc. A summary of the inspection results from the previous hop. This can be obtained by parsing the check tags output by the intermediate nodes of the previous hop, or by synchronization via the orchestration plane.

[0088] In one example, the target intermediate node determines the candidate set of the previous hop based on the link configuration. For example, for a Web Application Firewall (WAF), only Data Loss Prevention (DLP) systems are allowed upstream; for an Intrusion Detection System (IDS), only Firewalls (FW) are allowed upstream; in a parallel branching scenario, the set can contain multiple allowed nodes.

[0089] S133. Determine the value verification result based on the first verification value and the second verification value.

[0090] In one example, if the first check value and the second check value are the same, the value verification result is determined to be passed; if the first check value and the second check value are different, the value verification result is determined to be failed.

[0091] Continuing with the previous example, it is understandable that when in a This enables the verification material of the current target intermediate node according to u to be confirmed. Consistent with this rule, that is, when the calculated The result obtained from the analysis If they match, the value verification result is considered passed; otherwise, the value verification result is considered failed.

[0092] S134. Based on the pre-detection results and value verification results, determine the detection mode of the target intermediate node.

[0093] For example, pre-detection and value verification can be sequential. For instance, consistency verification can be performed first through pre-detection, and value verification can be performed after the consistency verification passes.

[0094] In some optional embodiments, a preset intermediate hop sequence number corresponding to the target intermediate node is determined based on the security verification line identifier; a detection service message is determined based on the service flow carrying the first verification tag; the initial hop sequence number and the service message are detected based on the preset intermediate hop sequence number and the detection service message, respectively; and it is determined whether the previous node of the target intermediate node belongs to the link topology set corresponding to the target intermediate node to obtain the pre-detection result.

[0095] In one example, the `chainId` is verified to ensure that the security chain the current target intermediate node is configured to participate in matches the local chain. Further, it is verified that `p` is the policy digest currently accepted by the current target intermediate node, or falls within the allowed policy version window, to confirm that the upstream policy version is compatible with local expectations. The `flowId` is verified to match the flow stability field observed by the current target intermediate node. In scenarios such as NAT or tunnels, this is compared with the "equivalent flow identifier mapping" to ensure that the verification label is correctly bound to the current business flow and to prevent cross-flow misuse. Does it satisfy the skip-order progression constraint, for example? Alternatively, it may fall within the allowed upstream set mapping range to confirm whether the business flow passes through each node in the predetermined order without skipping or detouring. If all four checks pass, the consistency pre-check result is considered passed; if any one fails, the verification is deemed to have failed.

[0096] For example, the detection mode of the target intermediate node can be determined based on the pre-detection results and the value verification results.

[0097] In some optional embodiments, if it is determined that the pre-detection result indicates that the detection has passed and the value verification result indicates that the verification has passed, the detection mode of the target intermediate node is determined to be the downgraded detection mode; or, if it is determined that the pre-detection result indicates that the detection has not passed or the value verification result indicates that the verification has not passed, the detection mode of the target intermediate node is determined to be the intensity detection mode.

[0098] For example, the judgment result of the verification label can be determined based on the pre-detection result and the value verification result. Based on the judgment results of the verification label, the detection mode of the target intermediate node is determined.

[0099] In one example, the result of verifying the label is shown. This can include both pass and fail. The determination of the verification label is only made when both the pre-detection result and the value verification result indicate a pass. Only then is it considered passed, that is, .

[0100] Furthermore, the judgment result of the verification label can be characterized by the following formula. With detection mode The relationship in between: That is, when the previous jump When the result is "fail," meaning the node cannot verify the authenticity or legality of the upstream check execution, the target intermediate node is forced into strict mode, i.e., strict processing mode, performing a complete, uncompromised security check on the business flow. When the value is "pass", it means that the upstream check execution has been verified and all context consistency checks have passed. At this time, the target intermediate node is authorized to choose between standard or light mode according to the local policy configuration. "Standard" is the standard detection mode and "light" is the lightweight detection mode. The two correspond to different check depths and computational overheads, respectively.

[0101] In this embodiment, by combining multi-dimensional pre-detection and value verification, intermediate nodes can only enter the degradation detection mode after the consistency of hop order, message integrity and link topology are confirmed. If any dimension fails, strength detection is forcibly executed. This solves the technical problem that the execution status of upstream checks cannot be verified, and significantly improves the overall decision reliability and protection tightness of the security verification link.

[0102] Figure 3 In the illustrated embodiment, by introducing a verification handle, intermediate nodes can independently recalculate the second verification value and compare it with the first verification value. This enables hop-by-hop verification of the authenticity and integrity of the verification tag, allowing for timely detection of tampering, forgery, or replay. This solves the problem of downstream nodes being unable to confirm the execution of upstream checks, enhancing the credibility of security decision-making. Simultaneously, the decision-making mechanism combining value verification results with pre-detection results improves the rigor of inter-node collaborative verification and the overall reliability of the link. Furthermore, intermediate nodes can dynamically select appropriate detection modes after confirming the credibility of upstream check execution, avoiding the security risks of blindly simplifying detection based on untrusted tags while reasonably reducing redundant check overhead in trusted scenarios.

[0103] In some embodiments, in S140, the target intermediate node can detect the service flow according to the detection process corresponding to the detection mode to obtain the service flow detection result.

[0104] For example, different detection modes correspond to different detection processes. After determining the detection mode, the target intermediate node can perform detection on the business flow according to the detection process corresponding to the detection mode to obtain the business flow detection results.

[0105] For example, the business flow detection result is the judgment conclusion obtained by the target intermediate node after performing security checks on the business flow, such as pass or fail, and the business flow detection result may also include a failure reason code.

[0106] S150. Construct a second verification tag through the target intermediate node based on the first verification tag, the pre-detection result, the business flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node.

[0107] For example, the second verification tag may be generated by the target intermediate node so that subsequent nodes can perform security verification based on the second verification tag.

[0108] For example, the exception code can be determined based on the pre-detection results. Furthermore, feature extraction can be performed on the business flow detection results and the pre-detection results to obtain an inspection result summary. Furthermore, the second verification label is constructed from the first verification label, the anomaly code, the check result summary, the second key corresponding to the target intermediate node, and the intermediate jump sequence number corresponding to the target intermediate node.

[0109] In some optional embodiments, if the pre-detection result indicates that the detection has not passed or the value verification result indicates that the verification has not passed, an anomaly code is constructed based on the pre-detection result and / or the value verification result. A second verification tag is constructed based on the anomaly code, the first verification tag, the pre-detection result, the service flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node.

[0110] For example, the first verification value can be updated based on the first verification label, the pre-detection result, and the value verification result, that is, the second verification value corresponding to the second verification label can be obtained.

[0111] The system can determine whether an anomaly exists based on the pre-detection results and value verification results. Once an anomaly is identified, an anomaly identifier is constructed. The first verification value is then updated based on the anomaly identifier and the first verification label.

[0112] In one example, skip order advancement and local result summary normalization are performed first. The current target intermediate node determines the skip order. and ensure that link propulsion constraints are met. ,in This indicates the sequential position code of the current target intermediate node in the secure link. From the previous hop check tag Furthermore, the advancement rules are determined by the link definition. Simultaneously, the current target intermediate node outputs a fixed-format summary of the service flow detection results and pre-detection results. For example, the detection mode, risk level ( ), Hit rule number ( ) and handling actions ( The hash of the concatenated fields (e.g., ) is represented as: The detection mode comes from the process described above, while the remaining fields come from the intermediate nodes of the current target. (·) is a summary function, and its specific implementation is not limited.

[0113] Furthermore, the current target intermediate node calculates the verification label based on the previous hop's commitment state. The preset checksum generation function calculates the checksum label corresponding to the intermediate node of the current target. It can be represented as .in, The local key material for the current target intermediate node. All from the previous tag , The hop order for the intermediate nodes of the current target, determined by the link advancement rules. This is a summary of the results for checking intermediate nodes of the current target. This is an exception identifier (set to ok if no exception is triggered, and fill in the specific exception code such as verifyFail, skipDetected, highRisk, etc. if an exception is triggered).

[0114] For example, an anomaly code can be used as a normalized coded identifier to represent anomalies. It is constructed by intermediate nodes when the pre-detection result or value verification result fails and is written into a second verification tag that is passed downstream.

[0115] For example, the checksum can be updated using the exception code. For instance, an exception path marker can be determined based on the exception code, and the checksum can be updated using both the exception code and the exception path marker.

[0116] For example, when the pre-detection result indicates that the detection has passed (e.g., PreCheck=false) and / or the value verification result indicates that the verification has passed (e.g., ... When an error occurs (e.g., failure), the target intermediate node takes the failure reason code, risk level, skip order flag, and tampering flag as input and generates a fixed-length exception code using an exception coding function. This exception code, as explicit input, is irreversibly written into the checksum field of the checksum label. This ensures that downstream nodes, when parsing the second checksum label, can unambiguously ascertain that an exception has occurred upstream, and this exception cannot be overwritten or reset by subsequent nodes. This process upgrades the exception from a bypass log to a verifiable state in the data plane.

[0117] In one example, exception triggers can include the following categories: failure of prior commitment verification ( This includes situations such as mismatch of legitimate upstream sets, inconsistent context, suspected skipping or replaying; skipping or topological anomalies, i.e. Inconsistent with the expected upstream set of this node, or the following may occur. Signs of a pullback; check for high-risk hits, i.e. Indicators include high-risk rule violations, suspected intrusion, or sensitive data leakage; signs of tag tampering, i.e., context fields that can be parsed but contradict local observations, such as inconsistent flowId mappings and lack of legitimate NAT or tunnel interpretations; and situations where tags are missing or fields are omitted but required by the link policy. The key constraint is that upon detecting the above anomalies, An anomaly code must be carried to prevent downstream security monitoring and degradation. Furthermore, the evolution of the anomaly state must meet the requirement that anomalies can be superimposed but cannot be overwritten back to the normal state. For example, the anomaly code should be fixed by bit or set digest.

[0118] Subsequently, the anomaly trigger source code is set to the current target intermediate node. For example, the collection of exceptions can be digested into a fixed-length code. ,in This represents the normalized identifier of the abnormal facts for this node and can be used as a mandatory constraint. The verification failure reason code comes from the above process. Results from local inspection , From skip order check, From context consistency pre-check, (·) represents an exception encoding function. For example, it can be used as an exception encoding function. Take it as an enumeration code (e.g., 01 indicates an invalid upstream, 02 indicates a skipped order and backtracking, 03 indicates an inconsistent context). Take 0 or 1, Set to 0 or 1 Take 0 or 1, (·) is taken as HMAC or hash digest, and the output value size is fixed at 64 bits or 128 bits.

[0119] When an anomaly occurs (e.g.) ≠ 0 or When `fail` occurs, the target intermediate node must enter the abnormal commitment update path. (Introduction) With abnormal path markers (For example = 1), the updated formula is: ,in This is the key material for the current intermediate node. The chainId, p, r, and flowId are derived from the parsing of the jump tag. This is the link location of this node. For local inspection summary, This is an error code. Marking abnormal paths. Updated. This indicates a commitment state that contains facts of abnormal execution. Once generated, the downstream nodes will inevitably see the existence of the abnormality and cannot revert to a state that only carries a normal result.

[0120] For example, the second verification label is calculated using the updated label and corresponding parameters.

[0121] In one example, the current target intermediate node performs label update and forwarding constraints, updating the checksum in the old label to... And write the latest skip order. This forms a new label, namely, Among them, chainId, p, r, and flowId are inherited from the old tags. and Generated by this node. Furthermore, if the current target intermediate node is within the in-chain forwarding plane, then only carrying... The message proceeds to the next-hop security node; if a missing tag or a tag reset is detected (e.g., h rollback or context inconsistency), an exception is forcibly triggered. ≠ OK and enter strict or blocking strategy.

[0122] Understandably, in this embodiment, when either the pre-detection result or the value verification result fails, the intermediate node encodes the abnormal fact into an abnormal code and writes it into the second verification tag. This allows the abnormal information to be transmitted downstream in an unforgeable and unreversible manner. Once the downstream node identifies the abnormal code when parsing the verification tag, it can forcibly trigger a strict processing mode. This solves the problem of information gaps where node verification failures or execution anomalies can only be recorded locally and cannot be communicated to downstream nodes. It keeps the abnormal facts transparent and traceable throughout the entire security verification chain, while reducing the possibility of attackers "erasing" the abnormality by tampering with or resetting the tag. This improves the security verification chain's reliability in abnormal scenarios, the traceability of the execution loop, and the real-time performance of multi-node collaborative responses.

[0123] Furthermore, optionally, if it is determined that the second verification tag contains an anomaly code, the detection mode of the target intermediate node is determined to be the strength detection mode. It is understood that when the target intermediate node or exit node detects that the second verification tag carries an anomaly code, it directly determines its detection mode to the strength detection mode. This ensures that once the anomaly is written into the commitment chain, it can be recognized by downstream nodes and a full security check can be enforced, reducing the security risk that anomalies may be ignored or covered by downstream nodes due to tag tampering or resetting.

[0124] Following the previous example, when an anomaly is detected, intermediate nodes need to enforce a policy, such as: enforcing strict checks, that is, switching to strict checks regardless of whether they were originally lightweight. = strict; Alarm linkage, i.e., generation Reporting to the control plane or orchestration plane is used for isolating links, adjusting upstream topology, or triggering tracing; and controlled bypass (optional), which means that access to controlled bypass is only allowed when business continuity is required and the policy permits it, and the bypass fact must be written into the system. and This ensures that downstream visibility is maintained and that export nodes can restrict and release goods accordingly.

[0125] For example, the current target intermediate node can be based on (Obtained from the classification strategy) Determine its execution action.

[0126] For example, the set of final actions for a node. It can be represented as ,in This represents the set of final actions to be taken at this node, which may include strict checks, alarms, controlled bypass, and blocking. (•) is the strategy decision function.

[0127] It is understood that, in this embodiment of the application, the exception is upgraded from a bypass log to part of the label, and irreversible input is used. and The implementation of non-erasable anomalies ensures that even if attackers can tamper with Differentiated Services Code Points (DSCPs) or metadata, they cannot prevent downstream users from seeing the anomalies at the verifiable fact level.

[0128] In some embodiments, in S160, the target intermediate node may send a service flow carrying a second verification tag to the exit node.

[0129] In some embodiments, in S170, after receiving a service flow carrying a second verification tag, the egress node can detect the second verification tag to obtain the security detection result of the service flow.

[0130] For example, the second verification tag may be generated by the exit node, enabling subsequent nodes to perform security verification based on the second verification tag.

[0131] For example, the egress node may have a local link definition, including the expected link length H, the expected node set summary, etc.; the egress node may also have a pass-through policy configuration, including trusted pass-through, restricted pass-through, blocking threshold, etc.

[0132] Specifically, the exit node can first perform a consistency check to ensure that the received second verification tag... This belongs to this link instance, this policy version, and this flow instance. Specifically, the egress node can verify whether the chainId is a link instance maintained by this egress, whether p is within the policy version window allowed by this node, and whether the flowId matches the flow stability field observed by the egress (or matches the NAT / tunnel mapping table). It also verifies... Has the desired chain tail position been reached, for example? =H or at least satisfy the coverage constraint of the key node set. Through the above multiple verifications, the egress node can confirm the consistency of the label from three dimensions: link affiliation, policy version, and flow binding, before performing fact verification.

[0133] Furthermore, after completing the consistency check, the egress node generates a verifiable determination of whether the entire link has been fully executed. Specifically, the exit node can use a verification function to perform convergence verification of the entire chain's execution facts. The verification function for the exit node can be represented by the following formula: .

[0134] in, This represents the final verification result of the exit node on the execution facts of the entire chain, which is used to drive subsequent release decisions; and its context come from , This is the verification function corresponding to the exit node, and its specific implementation is not limited.

[0135] Understandable It can include two possible outcomes: pass or fail. The criteria for characterization can include outcome criteria and verifiability criteria. Among these, structural criteria, i.e. The desired value must be achieved or the critical node coverage constraint must be satisfied; verifiable conditions, i.e. It needs to be compatible with the legal evolution rules under the link configuration. For example, each hop within the chain must go through a verifiable fork and the result must be written to the chain for an update mode; otherwise, it is considered a failure. Depending on the link, the exit node can perform random checks and verifications on the proof fragments of key nodes, and can also... Verify the consistency of the derived structure.

[0136] Furthermore, the exit node will determine the result. Combining this with the solidified facts of in-chain anomalies, a release decision is generated. The decision-making mechanism can be expressed as the following formula: .

[0137] in, The exit node's output release decision includes at least three categories: trusted release, restricted release, and blocking. For the allowance policy configuration, svcclass represents the business category, and riskhint can be obtained from the on-chain anomaly solidification fact mapping, for example, through anomaly marking. The extractable summary is obtained by parsing; This is a decision function, and its specific implementation is not limited.

[0138] In one example, if Characterization is achieved through (i.e., And if no abnormal fixed markers appear within the chain (i.e., no abnormalities are detected when parsing the risk hint), then the exit node will... Set as trusted and allow (i.e., );like If an abnormal solidification occurs after passing the test, such as entering a controlled bypass after a high-risk hit or verification failure, then... Set to restricted access (i.e., ), and accordingly implement measures such as speed limiting, desensitization, or secondary challenges; if For failure (i.e., ),but Directly set to block (i.e., ).

[0139] Figure 1 In the illustrated embodiment, by constructing verifiable verification tags that are transmitted along with the flow between nodes in the security verification link, the execution status of security checks can be propagated along with the business flow in the form of explicit status information. This solves the problem that downstream nodes cannot verify whether upstream checks have actually been executed, thus improving the overall reliability of the security verification link. Specifically, each intermediate node performs pre-detection after receiving the verification tag, which can reliably confirm the execution of upstream checks and avoid the omission of security checks by upstream nodes. This forms a real-time verifiable constraint mechanism in terms of execution order and completeness, further improving the reliability of the link execution status. At the same time, since the pre-detection results can serve as the basis for adjusting subsequent detection modes, downstream nodes can dynamically adjust their detection strategies with the premise of obtaining reliable execution status information. This reduces the security risks caused by simplified processing based on untrusted tags and reduces unnecessary duplicate check overhead, thereby achieving a synergistic improvement in system performance while ensuring security.

[0140] Figure 4 This diagram illustrates the architecture of a data security verification system according to an embodiment of the present invention. Figure 4 As shown, the data security verification system 400 includes an entry node 401, at least one intermediate node 402, and an exit node 403.

[0141] The ingress node is used to receive the service flow, determine the security verification line identifier based on the service message corresponding to the service flow, and construct the first verification tag based on the security verification line identifier, the service message, the first key corresponding to the ingress node, and the initial hop sequence number; and send the service flow carrying the first verification tag to the target intermediate nodes in the security verification line identifier in sequence. The security verification line identifier includes multiple intermediate nodes arranged in sequence.

[0142] The target intermediate node is used to receive the service flow carrying the first verification tag, perform pre-detection on the first verification tag based on the service flow carrying the first verification tag, and determine the detection mode of the target intermediate node based on the pre-detection result; and is used to detect the service flow according to the detection process corresponding to the detection mode to obtain the service flow detection result; it can also be used to construct the second verification tag based on the first verification tag, the pre-detection result, the service flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node; and send the service flow carrying the second verification tag to the egress node.

[0143] The egress node receives the service flow carrying the second verification tag, and performs security detection on the second verification tag based on the service flow carrying the second verification tag to obtain the security detection result of the service flow.

[0144] In addition, the data security verification system may also include an orchestration surface for sending relevant data to ingress nodes, intermediate nodes, and egress nodes.

[0145] Below, in conjunction with Figure 5 , Figure 6 The following examples illustrate data security verification methods.

[0146] Figure 5 This diagram illustrates the architecture of a data security verification system according to an embodiment of the present invention. Figure 6 A flowchart illustrating a data security verification method provided in an embodiment of the present invention is shown.

[0147] like Figure 5As shown, the data security verification system may include a security chain entry node 502, a boundary firewall 503, an intrusion detection module 504, a data leakage prevention module 505, an application layer protection module 506, an auditing and evidence storage module 507, a display and alarm module 508, a verification module 509, and a policy control module 510. Specifically, the original user service flow generated by the external network 501 first enters the security chain entry node 502, where the entry node initializes the verification label and outputs a verification value containing a policy summary, a random factor, a flow identifier, and an initial label. The traffic carrying the label then enters the multi-level security processing chain area, sequentially passing through the boundary firewall 503 to complete access control checks and generate a first verification value C1, the intrusion detection module 504 to complete anomaly and feature detection and generate a second verification value C2, the data leakage prevention module 505 to complete content compliance checks and generate a third verification value C3, and the application layer protection module 506 to complete application semantic checks and generate a fourth verification value C4. Furthermore, data and event information from each node throughout the process are synchronously sent to the audit and evidence storage module 507 for audit evidence. Detected abnormal behaviors such as detours and forgery are alerted through the display and alarm module 508. Traffic that has completed multi-level processing enters the verification module 509 to verify the authenticity of the execution of upstream nodes and output a valid or invalid judgment result. The judgment result is input into the policy control module 510 to generate a trusted downgrade or mandatory re-examination execution action. Finally, the compliant business flow is sent to the business system or Internet server 511.

[0148] like Figure 6 As shown, in S601, the ingress node receives the service flow and completes the policy context freezing and random factor generation, flow identifier FID construction, initial checksum C0 calculation, and initial label T0 construction. This establishes a trusted starting point for the entire link.

[0149] In S602, the intermediate security node processes and parses the previous hop label and verifies the previous hop commitment. If verification fails, S603 is executed, triggering an exception and forcibly switching to strict inspection mode. If verification passes, S604 is executed to perform a policy fork judgment. If the conditions are not met, S605 is executed for standard inspection; if the conditions are met, S606 is executed for lightweight inspection. The policy fork judgment can be used to determine whether the current traffic can undergo lightweight security inspection. Based on the judgment result, the current security node chooses between the standard inspection path and the lightweight inspection path, adjusting the inspection strength and balancing security protection and system performance under the premise of security and trustworthiness.

[0150] In S607, a local security check is performed to determine if a risk has been detected. If a risk is detected, S608 is executed to generate an anomaly code E; if no risk is detected, S609 is executed to generate a normal digest R. Further, S610 can be executed to input the anomaly code and normal digest into the chained update step to generate a new checksum Ci and update the checksum label Ti.

[0151] In S611, it is determined whether the current node is an exit node. If it is not an exit node, S602 is returned. If it is, S612 is executed to perform consistency verification and full-chain execution fact verification. If the verification fails, S613 is executed to block traffic; otherwise, S614 is executed to check for anomalies within the chain. If there are no anomalies, S615 is executed to allow trusted passage; if there are anomalies, S616 is executed to allow restricted passage.

[0152] In addition, it can determine whether the traffic needs to cross domains. If no cross domain is required, the process ends; if cross domain is required, a cross domain summary is generated and sent to the target security domain.

[0153] In one example, before the business flow leaves the local domain, the source security domain egress node can compress the final execution fact according to the cross-domain policy to generate a cross-domain inheritance summary. ,in, The final commitment state generated for the source security domain exit. The validity period of cross-domain inheritance (given by the cross-domain policy). (·) is a summary function, the specific implementation of which is not limited. This summary is only used to determine whether there is a trustworthy upstream execution history in the target domain.

[0154] Furthermore, the target security domain entry point verifies XSum to obtain the cross-domain determination result. ,in, For cross-domain inheritance strategy, It serves as an inter-domain trust anchor (such as a certificate, public key, control plane verification handle, or equivalent verification material). Its function is limited to determining whether the cross-domain digest was generated by a trusted source security domain, and it is not used for the hop-by-hop evolution of the commitment chain, thereby avoiding the unconstrained diffusion of trust boundaries. (·) is a cross-domain verification function (which can be implemented based on signature verification, MAC verification or equivalent methods). For cross-domain inheritance, the decisional result must include at least "pass / fail" to determine whether to allow execution of facts in the target domain reference upstream. To pass through, the target security domain entry point can... As one of the inputs, it participates in the initialization of the new commitment chain in the target domain; when In the event of failure, the target security domain must not inherit any upstream execution facts and must fall back to the target domain for a complete and rigorous check or direct blocking. Understandably, this approach, through minimal inheritance, decision-based verification, and fallback upon failure, provides a non-propagating mechanism for referencing execution facts across security domains.

[0155] In this embodiment, the entry node establishes an unforgeable verification anchor point, ensuring the credibility of the security chain's starting point. Through pre-label verification and policy bifurcation constraints, the processing mode of each node strictly depends on the credible confirmation of upstream execution facts, fundamentally reducing structural vulnerabilities caused by forging low-risk labels. A chain-like label update mechanism solidifies the execution result of each node into an irreversible commitment state, enabling downstream nodes to verifiably trace upstream execution status. Simultaneously, the chain-like solidification of abnormal states ensures that facts such as detours, forgery, and skipping sequences are indelible. Combined with the full-chain verification of the exit node, a credible release decision based on complete execution facts is achieved. Therefore, this embodiment transforms the multi-level security chain from a collaborative mode of traffic diversion plus untrusted soft labels into a strongly constrained architecture of a verifiable execution fact chain. While ensuring robust security protection, it provides a reliable foundation for system performance optimization, significantly improving the overall reliability, traceability, and closed-loop constraint capability of the multi-level security processing chain in dynamic and complex network environments.

[0156] Based on the data security verification method provided in the above embodiments, this application also provides specific implementation methods of the data security verification device. Please refer to the following embodiments.

[0157] Figure 7 This is a schematic diagram of a device structure 700 provided in an embodiment of the present invention. Figure 7 As shown, the device may include: The first construction module 701 is used to respond to the ingress node receiving a service flow, determine the security verification line identifier according to the service message corresponding to the service flow, and construct the first verification tag according to the security verification line identifier, the service message, the first key corresponding to the ingress node and the initial hop sequence number; The first sending module 702 is used to send a service flow carrying a first verification tag to the target intermediate node in the security verification line identifier in sequence through the entry node, wherein the security verification line identifier includes multiple intermediate nodes arranged in sequence. The determination module 703 is used to respond to the target intermediate node receiving a service flow carrying a first verification tag, perform pre-detection on the first verification tag, and determine the detection mode of the target intermediate node based on the pre-detection result; The first detection module 704 is used to detect the business flow through the target intermediate node according to the detection process corresponding to the detection mode, and obtain the business flow detection result. The second construction module 705 is used to construct a second verification tag through the target intermediate node based on the first verification tag, the pre-detection result, the business flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node; The second sending module 706 is used to send a service flow carrying a second verification tag to the exit node through the target intermediate node; The second detection module 707 is used to detect the second verification tag in response to the egress node receiving a service flow carrying the second verification tag, and obtain the security detection result of the service flow.

[0158] In one implementation, a first verification tag is constructed based on the security verification line identifier, the service message, the first key corresponding to the entry node, and the initial hop sequence number, including: determining a first verification value based on the security verification line identifier, the service message, the first key, and the initial hop sequence number; and determining the first verification tag based on the security verification line identifier, the service message, the first verification value, and the initial hop sequence number.

[0159] In one embodiment, determining a first verification value based on a security verification line identifier, a service message, a first key, and a preset verification value generation function includes: determining a security verification policy corresponding to the target intermediate node in the security verification line identifier; extracting key features from the security verification policy to obtain a policy summary corresponding to the security verification policy; determining a service flow identifier based on the service message and a preset identifier constructor; determining a first verification value based on the security verification line identifier, policy summary, service flow identifier, first key, and the preset verification value generation function; and determining a first verification label based on the security verification line identifier, service message, first verification value, and initial hop sequence number includes: determining a first verification label based on the security verification line identifier, policy summary, service flow identifier, first verification value, and initial hop sequence number.

[0160] In one embodiment, the first construction module 701 constructs a first verification tag based on the security verification line identifier, service message, first key corresponding to the entry node, and initial hop sequence number as follows: generating a random number; constructing the first verification tag based on the security verification line identifier, service message, first key corresponding to the entry node, initial hop sequence number, and random number.

[0161] In one embodiment, the first construction module 701 performs pre-detection on the first verification tag in the following manner, and determines the detection mode of the target intermediate node based on the pre-detection result: parsing the first verification tag to obtain the security verification line identifier, service message, initial hop sequence number, and first verification value; determining the second verification value based on the verification handle, security verification line identifier, service message, and preset verification value generation function corresponding to the target intermediate node; determining the value verification result based on the first verification value and the second verification value; and determining the detection mode of the target intermediate node based on the pre-detection result and the value verification result.

[0162] In one embodiment, before determining the detection mode of the target intermediate node based on the pre-detection result and the value verification result, the device further includes: a generation module, configured to determine the preset intermediate hop sequence number corresponding to the target intermediate node based on the security verification line identifier; determine the detection service message based on the service flow carrying the first verification tag; detect the initial hop sequence number and the service message based on the preset intermediate hop sequence number and the detection service message respectively, and determine whether the previous node of the target intermediate node belongs to the link topology set corresponding to the target intermediate node, thereby obtaining the pre-detection result; the first construction module 701 determines the detection mode of the target intermediate node based on the pre-detection result and the value verification result in the following manner: if the pre-detection result indicates that the detection has passed and the value verification result indicates that the verification has passed, the detection mode of the target intermediate node is determined to be a downgraded detection mode; or, if the pre-detection result indicates that the detection has not passed or the value verification result indicates that the verification has not passed, the detection mode of the target intermediate node is determined to be a strength detection mode.

[0163] In one embodiment, the second construction module 705 constructs a second verification label through the target intermediate node in the following manner: Based on the first verification label, the pre-detection result, the service flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node: If the pre-detection result indicates that the detection has not passed or the value verification result indicates that the detection has not passed, an exception code is constructed based on the pre-detection result and / or the value verification result; the second verification label is then constructed based on the exception code, the first verification label, the pre-detection result, the service flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node.

[0164] In one embodiment, the second construction module 705 is further configured to: determine the detection mode of the target intermediate node as the strength detection mode when it is determined that the second verification tag contains an abnormal code.

[0165] Figure 8 A schematic diagram of the hardware structure of the data security verification device provided in an embodiment of the present invention is shown.

[0166] The data security verification device may include a processor 801 and a memory 802 storing computer program instructions.

[0167] Specifically, the processor 801 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of the present invention.

[0168] Memory 802 may include mass storage for data or instructions. For example, and not limitingly, memory 802 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. In one instance, memory 802 may include removable or non-removable (or fixed) media, or memory 802 may be non-volatile solid-state memory. Memory 802 may be internal or external to a data security verification device.

[0169] In one instance, memory 802 may be read-only memory (ROM). In one instance, the ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically rewritable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0170] Memory 802 may include read-only memory (ROM), random access memory (RAM), disk storage media device, optical storage media device, flash memory device, electrical, optical, or other physical / tangible memory storage device. Therefore, generally, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of this disclosure.

[0171] The processor 801 reads and executes computer program instructions stored in the memory 802 to achieve... Figure 1 The data security verification method in the illustrated embodiment.

[0172] In one example, the data security verification device may further include a communication interface 803 and a bus 804. For example, Figure 8As shown, the processor 801, memory 802, and communication interface 803 are connected through bus 804 and complete communication with each other.

[0173] The communication interface 803 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of the present invention.

[0174] Bus 804 includes hardware, software, or both, that couples components of a data security verification device together. For example, and not as a limitation, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 804 may include one or more buses. While specific buses are described and illustrated in embodiments of the invention, the invention contemplates any suitable bus or interconnect.

[0175] This data security verification device can execute the data security verification method of this invention based on the business flow, thereby achieving a combination of... Figure 1 The method described is for verifying data security.

[0176] Furthermore, in conjunction with the data security verification methods described in the above embodiments, this invention can be implemented using a computer storage medium. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the data security verification methods described in the above embodiments.

[0177] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the data security verification methods described in the above embodiments.

[0178] It should be clarified that the present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of the present invention.

[0179] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this invention are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried in a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memory (ROM), flash memory, erasable read-only memory (EROM), floppy disks, compact disc read-only memory (CD-ROM), optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0180] It should also be noted that the exemplary embodiments mentioned in this invention describe methods or systems based on a series of steps or apparatus. However, this invention is not limited to the order of the steps described above; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0181] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0182] The above description is merely a specific embodiment of the present invention. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the protection scope of the present invention.

Claims

1. A data security verification method, characterized in that, The data security verification method is applied to a security verification link, which includes an ingress node, at least one intermediate node, and an egress node. In response to the ingress node receiving a service flow, the security verification line identifier is determined according to the service message corresponding to the service flow, and a first verification tag is constructed according to the security verification line identifier, the service message, the first key corresponding to the ingress node, and the initial hop sequence number; Through the entry node, a service flow carrying the first verification tag is sent sequentially to the target intermediate node in the security verification line identifier, wherein the security verification line identifier includes multiple intermediate nodes arranged in sequence. In response to the target intermediate node receiving the service flow carrying the first verification tag, the first verification tag is pre-detected, and the detection mode of the target intermediate node is determined based on the pre-detection result; The business flow is detected through the target intermediate node according to the detection process corresponding to the detection mode, and the business flow detection result is obtained. A second verification tag is constructed using the target intermediate node based on the first verification tag, the pre-detection result, the service flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node. The service flow carrying the second verification tag is sent from the target intermediate node to the exit node; In response to the egress node receiving the service flow carrying the second verification tag, the second verification tag is detected to obtain the security detection result of the service flow.

2. The data security verification method according to claim 1, characterized in that, The step of constructing the first verification tag based on the security verification line identifier, the service message, the first key corresponding to the ingress node, and the initial hop sequence number includes: A first verification value is determined based on the security verification line identifier, the service message, the first key, and the following: The first verification tag is determined based on the security verification line identifier, the service message, the first verification value, and the initial hop sequence number.

3. The data security verification method according to claim 2, characterized in that, The step of determining the first verification value based on the security verification line identifier, the service message, the first key, and the preset verification value generation function includes: Based on the security verification line identifier, determine the security verification strategy corresponding to the target intermediate node in the security verification line identifier; Key features are extracted from the security verification strategy to obtain a strategy summary corresponding to the security verification strategy. The service flow identifier is determined based on the service message and the preset identifier constructor. The first verification value is determined based on the security verification line identifier, the policy summary, the service flow identifier, the first key, and the preset verification value generation function; The step of determining the first verification tag based on the security verification line identifier, the service message, the first verification value, and the initial hop sequence number includes: The first verification tag is determined based on the security verification line identifier, the policy summary, the service flow identifier, the first verification value, and the initial hop sequence number.

4. The data security verification method according to any one of claims 1-3, characterized in that, The step of constructing the first verification tag based on the security verification line identifier, the service message, the first key corresponding to the ingress node, and the initial hop sequence number includes: Generate random numbers; The first verification tag is constructed based on the security verification line identifier, the service message, the first key corresponding to the entry node, the initial jump sequence number, and the random number.

5. The data security verification method according to claim 2, characterized in that, The step of pre-detecting the first verification tag and determining the detection mode of the target intermediate node based on the pre-detection result includes: Parse the first verification tag to obtain the security verification line identifier, the service message, the initial hop sequence number, and the first verification value; The second verification value is determined based on the verification handle corresponding to the target intermediate node, the security verification line identifier, the service message, and the preset verification value generation function. The value verification result is determined based on the first verification value and the second verification value; Based on the pre-detection results and the value verification results, the detection mode of the target intermediate node is determined.

6. The data security verification method according to claim 5, characterized in that, Before determining the detection mode of the target intermediate node based on the pre-detection results and the value verification results, the method further includes: Based on the security verification line identifier, determine the preset intermediate hop sequence number corresponding to the target intermediate node; Based on the service flow carrying the first verification tag, a detection service packet is determined; based on the preset intermediate hop sequence number and the detection service packet, the initial hop sequence number and the service packet are detected respectively, and it is determined whether the previous node of the target intermediate node belongs to the link topology set corresponding to the target intermediate node, so as to obtain the pre-detection result. The step of determining the detection mode of the target intermediate node based on the pre-detection results and the value verification results includes: If the pre-detection result indicates that the detection has passed and the value verification result indicates that the verification has passed, then the detection mode of the target intermediate node is determined to be a degraded detection mode; or, If the pre-detection result indicates that the detection has not passed or the value verification result indicates that the verification has not passed, the detection mode of the target intermediate node is determined to be the intensity detection mode.

7. The data security verification method according to claim 5, characterized in that, The step of constructing a second verification tag through the target intermediate node, based on the first verification tag, the pre-detection result, the service flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node, includes: If the pre-detection result indicates that the detection has not passed or the value verification result indicates that the verification has not passed, an exception code is constructed based on the pre-detection result and / or the value verification result. A second verification tag is constructed based on the anomaly code, the first verification tag, the pre-detection result, the service flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node.

8. The data security verification method according to claim 7, characterized in that, The method further includes: If it is determined that the second verification tag contains an abnormal code, the detection mode of the target intermediate node is determined to be the strength detection mode.

9. A data security verification system, characterized in that, The data security verification system includes an entry node, at least one intermediate node, and an exit node. The data security verification system includes: The ingress node is used to receive service flows, determine the security verification line identifier according to the service message corresponding to the service flow, and construct a first verification tag according to the security verification line identifier, the service message, the first key corresponding to the ingress node and the initial hop sequence number. The entry node is used to send a service flow carrying the first verification tag to the target intermediate node in the security verification line identifier in sequence, wherein the security verification line identifier includes multiple intermediate nodes arranged in sequence. The target intermediate node is used to receive the service flow carrying the first verification tag, perform pre-detection on the first verification tag according to the service flow carrying the first verification tag, and determine the detection mode of the target intermediate node according to the pre-detection result. The target intermediate node is used to detect the business flow according to the detection process corresponding to the detection mode, and obtain the business flow detection result; The target intermediate node is used to construct a second verification tag based on the first verification tag, the pre-detection result, the service flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node; The target intermediate node is used to send a service flow carrying the second verification tag to the exit node; The egress node receives the service flow carrying the second verification tag, and performs detection on the second verification tag based on the service flow carrying the second verification tag to obtain the security detection result of the service flow.

10. A data security verification device, characterized in that, The data security verification device is applied to a security verification link, which includes an ingress node, at least one intermediate node, and an egress node. The first construction module is configured to, in response to the ingress node receiving a service flow, determine a security verification line identifier based on the service message corresponding to the service flow, and construct a first verification tag based on the security verification line identifier, the service message, the first key corresponding to the ingress node, and the initial hop sequence number; The first sending module is used to send a service flow carrying the first verification tag to the target intermediate node in the security verification line identifier in sequence through the entry node, wherein the security verification line identifier includes a plurality of intermediate nodes arranged in sequence. The determination module is configured to, in response to the target intermediate node receiving the service flow carrying the first verification tag, perform pre-detection on the first verification tag, and determine the detection mode of the target intermediate node based on the pre-detection result; The first detection module is used to detect the business flow through the target intermediate node according to the detection process corresponding to the detection mode, and obtain the business flow detection result. The second construction module is used to construct a second verification tag through the target intermediate node, based on the first verification tag, the pre-detection result, the service flow detection result, the second key corresponding to the target intermediate node, and the intermediate hop sequence number corresponding to the target intermediate node; The second sending module is used to send a service flow carrying the second verification tag to the exit node through the target intermediate node; The second detection module is used to detect the second verification tag in response to the egress node receiving the service flow carrying the second verification tag, and obtain the security detection result of the service flow.

11. A data security verification device, characterized in that, The device includes: a processor and a memory storing computer program instructions; the processor reads and executes the computer program instructions to implement the data security verification method as described in any one of claims 1-8.

12. A computer-readable storage medium, characterized in that, The computer storage medium stores computer program instructions, which, when executed by a processor, implement the data security verification method as described in any one of claims 1-8.

13. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the data security verification method as described in any one of claims 1-8.

Images