Receiver-initiated path verification method for data acquisition

Abstract

The invention discloses a receiver-initiated path verification method for data acquisition, which comprises the following steps that: a data user is used as a receiver, and firstly initiates a session to acquire a key and a token; and then generating and sending a request message containing a cryptographic verification field based on the secret key, the token and a specified path. And when the message is forwarded along the path, each intermediate node verifies and updates the field in sequence. After arriving at the data provider, performing end-to-end verification; and after the verification is passed, multiplexing the head of the request message and recalculating the verification field to construct a response message. And the response message is returned in a reverse order along the original path, and is forwarded after being subjected to reverse verification and field updating by the intermediate node. And finally, the data user performs end-to-end verification on the returned response message to complete a path verification closed loop. According to the invention, end-to-end active control and closed-loop verification of the data acquisition path are realized through the session initiated by the receiver and the bidirectional path proof, and the controllability and security of data transmission are improved.

Description

Technical Field

[0001] This invention belongs to the field of network communication technology, and in particular relates to a receiver-initiated path verification method for data acquisition. Background Technology

[0002] The current internet has achieved tremendous success over the past few decades based on the TCP / IP architecture. This architecture employs a simplified data delivery model that combines stateless forwarding with push-based transmission, allowing terminal hosts to initiate network layer packet transmissions to any node in the network simply by specifying the target IP address. The actual forwarding path is dynamically determined by the underlying network routing mechanism. However, due to the lack of systematic security design, the existing internet architecture is vulnerable to various network attacks in open environments, such as distributed denial-of-service (DDoS) attacks, path hijacking, unauthorized data eavesdropping and tampering, seriously affecting the reliability and controllability of data transmission.

[0003] Against this backdrop, path verification technology has emerged, enhancing the security of internet data transmission by granting terminal hosts the ability to enforce the specification and verification of packet forwarding paths. This technology has gained widespread research attention in recent years, driven by the Path Aware Networking Research Group (PANRG), jointly supported by the IETF and ITF. To implement path verification, an additional verification field is typically introduced into the network layer packet header, and routers along the path maintain corresponding cryptographic states (i.e., path proofs), enabling nodes in the path to verify whether received packets have indeed been transmitted along the specified path.

[0004] Currently, research on path verification mainly focuses on how to maintain the path verification capabilities of both destination and intermediate nodes while reducing protocol overhead and state maintenance costs. Although existing solutions differ in their design and optimization priorities, they all share the commonality of being sender-initiated path verification mechanisms. In these mechanisms, the path specification and verification process is primarily led and controlled by the data sender (i.e., the data provider). This design paradigm, to some extent, follows the TCP / IP architecture's host-centric communication model, which naturally favors the sender.

[0005] However, sender-initiated path verification mechanisms have the following obvious drawbacks: First, the data receiver (i.e., the data user) is in a passive position in path selection and control, and cannot actively define and enforce the data acquisition path according to its own needs, network status, or security policies; second, this type of mechanism is difficult to effectively deal with unexpected data pushes, path deviations, or denial-of-service attacks initiated by the sender or malicious nodes in the path; finally, in a dynamic network environment, the receiver cannot optimize and switch paths based on real-time data transmission quality feedback, which limits the further improvement of overall communication efficiency and reliability.

[0006] Therefore, there is an urgent need to propose a path verification method led by the receiver to make up for the shortcomings of existing technologies in terms of path controllability and security adaptability. Summary of the Invention

[0007] To address the aforementioned technical problems, this invention provides a receiver-initiated path verification method for data acquisition. It aims to overcome the limitations of existing technologies, enabling data receivers (i.e., data users) to actively define, enforce, and verify their desired data acquisition paths, thereby enhancing the autonomy and security of end users in network communication. This invention introduces a receiver-led design concept, constructing a receiver-oriented session management structure and a bidirectional path verification system. This transforms data users, who are passive recipients in the traditional model, into active participants in the path verification process, thereby achieving proactive control and dynamic optimization of the data acquisition path.

[0008] This invention provides a receiver-initiated path verification method for data acquisition, comprising the following steps: The data user, as the data recipient, obtains the key and token information used for path verification by initiating a session establishment process; Based on the key, token, and determined forwarding path, the data user generates and sends a request message containing a path verification header, which integrates cryptographic fields for verification by each node on the path. Using the path verification header, the request message is verified sequentially by intermediate nodes along the forwarding path as it is transmitted, and the path verification field is updated after successful verification before forwarding. When the request message arrives at the data provider, which is the data sender, the data provider performs end-to-end verification on it. After the verification is successful, the data provider constructs a response message by reusing the path verification header field of the request message and recalculating the destination verification field. The response message is returned in reverse order along the forwarding path, and the intermediate nodes on the path perform reverse path verification in sequence. After the verification is successful, the path verification field is updated and the message is forwarded. When the response message is returned to the data user, the data user performs end-to-end verification to complete the path verification closed loop.

[0009] Optionally, the step of the data user, as the data recipient, initiating a session establishment process to obtain key and token information for path verification includes: Data users generate and send session packets containing session public keys, path information, and timestamps; After receiving the session establishment packet, the intermediate node on the path generates its own session symmetric key, determines the forwarding interface based on the path information in the packet, maintains the binding relationship between the session identifier and the forwarding interface, and then forwards the session establishment packet. After receiving the session establishment packet, the data provider verifies its authenticity and generates its own session key. At the same time, it obtains the session symmetric keys of all intermediate nodes on the path, encrypts them, and sends them back. During the backhaul process, the intermediate node encrypts and signs its own token and adds it to the backhaul message; The data user parses the returned message to obtain the session symmetric key of the data provider and all intermediate nodes, as well as the tokens of all intermediate nodes.

[0010] Optionally, the path verification header includes: A session identifier field used to identify the session; A timestamp field used to record the time when a group is created; A request identifier field used to uniquely identify a request within a session; A hash field used to verify header integrity; A path validation field used by intermediate nodes to implicitly record the actual path and update it sequentially. An array of recipient and path verification fields used by each intermediate node to verify the user's identity and path in the data; The destination verification field is used for integrity and path verification by the destination node.

[0011] Optionally, based on the key, token, and determined forwarding path, the data user generates a request message containing a path verification header, including: The data user calculates the hash field based on the session identifier, request identifier, and timestamp; The data user generates the path verification field, the receiver and path verification field for each node, and the destination verification field by calculating the path verification field, the key and token assigned to each node on the path, and the key of the data provider through the cascading message authentication code, based on the hash field, the key and token assigned to each node on the path, and the key of the data provider. The generated fields are assembled into a path validation header and inserted between the network layer header and the transport layer header.

[0012] Optionally, the step of using the path verification header, whereby the request message is verified sequentially by intermediate nodes along the forwarding path, includes: The intermediate node parses the path verification header of the request message and generates the corresponding key and token based on the session identifier; The intermediate node uses the key, token, parsed hash field, and neighboring node identifier to calculate the local expected verification value; The local expected verification value is compared with the corresponding receiver and path verification fields in the message. If they match, the verification is successful. After successful verification, the intermediate node uses the key to encrypt and update the path verification field in the message, and forwards the updated request message from the preset forwarding interface.

[0013] Optionally, when the request message arrives at the data provider, which is the data sender, the data provider performs end-to-end verification, including: The data provider parses the path verification header of the request message; The data provider uses its own key, the parsed path verification field, and the message payload to calculate the local expected destination verification value; The local expected destination verification value is compared with the destination verification field carried in the message. If they match, the verification is successful.

[0014] Optionally, the data provider constructs a response message by reusing the path verification header field of the request message and recalculating the destination verification field, including: The data provider reuses the session identifier, timestamp, request identifier, hash, path verification field, and receiver and path verification field array in the path verification header of the request message; The data provider recalculates the destination verification field based on its own key, the path verification field, and the message payload; The recalculated destination verification field is assembled with other reused fields into the path verification header of the response message.

[0015] Optionally, the response message is returned in reverse order along the forwarding path, and the intermediate nodes along the path sequentially perform reverse path verification, including: The intermediate node identifies the response message and decrypts the path verification field in the message using the corresponding key of the session; The intermediate node uses the decryption result, the key, and the token to calculate the local expected verification value; The local expected verification value is compared with the corresponding receiver and path verification fields in the response message. If they match, the verification is successful. After successful verification, the intermediate node updates the path verification field in the message with the decrypted value and forwards the updated response message to the next hop node.

[0016] Optionally, when the response message is returned to the data user, the data user performs end-to-end verification, including: The data user uses the data provider's key to decrypt the path verification field in the response message to obtain the intermediate result; The local expected target verification value is calculated based on the intermediate results; The local expected destination verification value is compared with the destination verification field carried in the response message. If they match, the verification is successful.

[0017] Optionally, the method further includes: According to a preset strategy, data users execute the token update function in parallel with relevant nodes to generate new tokens for the calculation of path verification fields in subsequent messages.

[0018] Compared with the prior art, the present invention has the following advantages and technical effects: This invention enables the receiver to have proactive and exclusive control over the data transmission path: by granting the data user the right to initiate "session establishment" and the right to authorize "keys and tokens," the invention establishes the receiver's core control position from the very beginning of communication. This allows the data user to proactively specify and encrypt the expected path, fundamentally eliminating the possibility of the sender or network intermediate nodes arbitrarily changing the path or pushing unauthorized data.

[0019] It provides hop-by-hop real-time verification and tamper detection capabilities for data transmission paths: by integrating a sophisticated cryptographic verification field into the request message and forcing each intermediate node on the path to decrypt and verify sequentially during transmission, this invention can instantly detect and discard any data packets that deviate from the specified path, have been tampered with, or have been forged, thus distributing security defense capabilities across the entire transmission link.

[0020] This invention ensures strict consistency between request and response paths, establishing a two-way security constraint: through a unique field reuse and dual update mechanism, it strongly binds the legitimate forwarding qualification of the response message with the successful verification and forwarding history of the corresponding request message. This forces the response to return in reverse along the original request path, effectively defending against eavesdropping, hijacking, or denial-of-service attacks carried out through side-channels or malicious nodes.

[0021] This invention establishes a secure, end-to-end, verifiable data acquisition loop: through independent end-to-end verification by both the data provider and the data user, it provides dual adjudication for each data interaction. This not only ensures the authenticity and integrity of the response data but also allows the receiver to ultimately confirm that the entire process of "path specification - data transmission - result return" is completed under its control and verification, significantly improving the controllability, security, and reliability of network data transmission. Attached Figure Description

[0022] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a schematic diagram of the method flow according to an embodiment of the present invention; Figure 2 This is a schematic flowchart illustrating the receiver-oriented session establishment process according to an embodiment of the present invention. Figure 3 This is a schematic diagram of the path verification header (PVH) according to an embodiment of the present invention; Figure 4 This is a schematic diagram illustrating path adjustment when malicious behavior is detected, according to an embodiment of the present invention. Figure 5 The figure shows the experimental results of data transmission efficiency conducted by the container-based simulation platform according to an embodiment of the present invention. Figure 6 The figure shows the experimental results of the data transmission advantages of the container-based simulation platform in this embodiment of the invention. Detailed Implementation

[0023] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0024] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0025] Example 1 This embodiment provides a receiver-initiated path verification method for data acquisition, including the following steps: The data user, as the data recipient, obtains the key and token information used for path verification by initiating a session establishment process; Based on the key, token, and determined forwarding path, the data user generates and sends a request message containing a path verification header, which integrates cryptographic fields for verification by each node on the path. Using the path verification header, the request message is verified sequentially by intermediate nodes along the forwarding path as it is transmitted, and the path verification field is updated after successful verification before forwarding. When the request message arrives at the data provider, which is the data sender, the data provider performs end-to-end verification on it. After the verification is successful, the data provider constructs a response message by reusing the path verification header field of the request message and recalculating the destination verification field. The response message is returned in reverse order along the forwarding path, and the intermediate nodes on the path perform reverse path verification in sequence. After the verification is successful, the path verification field is updated and the message is forwarded. When the response message is returned to the data user, the data user performs end-to-end verification to complete the path verification closed loop.

[0026] As a specific implementation method, such as Figure 1 The diagram shows an overview of the entire request-response process. This process is initiated by the data user (User, ), intermediate network nodes ( ) and data provider (Provider, Collaborative execution. The data user is the receiver, i.e., the source node in the request process and the destination node in the response process, and also the initiator of the session and the specifyer of the path. The data provider is the sender, i.e., the destination node in the request process and the source node in the response process.

[0027] Implementable, the step of the data user, as the data recipient, initiating a session establishment process to obtain key and token information for path verification includes: The data user generates and sends a session establishment packet containing a session public key, path information, and a timestamp. Upon receiving the session establishment packet, intermediate nodes along the path generate their own session symmetric keys, determine the forwarding interface based on the path information in the packet, maintain the binding relationship between the session identifier and the forwarding interface, and then forward the session establishment packet. Upon receiving the session establishment packet, the data provider verifies its authenticity, generates its own session key, and obtains the session symmetric keys of all intermediate nodes along the path, encrypts them, and sends them back. During the backhaul process, intermediate nodes encrypt and sign their own tokens and add them to the backhaul message. The data user parses the backhaul message to obtain the session symmetric keys of the data provider and all intermediate nodes, as well as the tokens of all intermediate nodes.

[0028] As one specific implementation method, the process of establishing a session between a user and a provider includes: The core of path verification lies in establishing a shared-key session and generating a cryptographic pathproof. To ensure that an end-to-end path can be enforced and verified, most path verification schemes require the establishment of one or more shared-key sessions between the two endpoints. This embodiment uses a modified DRKey protocol for receiver-oriented session establishment. The DRKey protocol is currently the most advanced session establishment protocol, enabling routers along the path to establish a shared key with the two endpoints. This modified DRKey protocol mainly consists of five phases: S101, User node initializes "Session Establishment Group"; like Figure 2 As shown, to establish a receiver-oriented session, this embodiment designates the data user (i.e., the receiver) as the initiator of the session establishment. The standard DRKey protocol requires the initiator (i.e., the data user) to select a random pair of public and private keys before issuing a session establishment request, and then obtain an explicit path to the data provider from the routing system. During the initialization phase of the session establishment packet, the session public key, end-to-end path information, timestamp, and authenticated encrypted session identifier and session private key are written into the packet. The session identifier (SessionID, used to uniquely identify a session) is obtained by hashing the session public key, end-to-end path information, and timestamp.

[0029] S102, intermediate network nodes generate keys and forward them to downstream nodes; Upon receiving a session establishment packet carrying path information, the intermediate node calculates the session identifier and generates its own session symmetric key using its private secret value. Subsequently, the key is encrypted and signed to ensure its confidentiality and authenticity during transmission. The intermediate node then iterates through all its outgoing interfaces to determine if the next hop exists in the path specified by the session establishment packet. If it does, the session establishment packet is forwarded from that interface.

[0030] Meanwhile, intermediate nodes maintain a session state table. The core of this table is the binding relationship between session identifiers and a pair of forwarding interfaces. Specifically, it records the ingress interface of the session establishment packet as its logical receiver and the egress interface as its logical sender. For subsequent packets within the same session, the intermediate node matches the actual arrival interface with the above binding relationship to determine the forwarding behavior: if the packet arrives from the logical receiver and is identified as a request packet, it is determined that it needs to be sent to the sender along the session-specified path, and therefore forwarded through the logical sender; if the packet arrives from the logical sender and is identified as a response data packet, it is determined that it needs to be returned to the receiver along the session-specified path, and therefore forwarded through the logical receiver. With this mapping relationship, during the packet forwarding phase, packets only need to carry the correct session identifier, and intermediate nodes only need to query this mapping relationship to determine the correct forwarding direction, thus eliminating the need to carry complete end-to-end path information. Furthermore, binding the request path and response path ensures the consistency of bidirectional traffic paths within the same session, realizing stateful forwarding control in a stateless network.

[0031] S103, The provider verifies and returns the key sequence; After receiving the session establishment packet from the upstream node, the data provider (i.e., the sender) first verifies the packet's authenticity. Upon successful verification, the data provider, like the intermediate nodes, generates its own session key. Subsequently, it decrypts the packet's payload to obtain the session symmetric keys of all intermediate nodes along the specified path. Finally, the data provider encrypts these symmetric keys and its own key, then writes them into the session message and sends it back to the data user (i.e., the receiver).

[0032] S104, intermediate network nodes generate and forward tokens; Unlike the standard DRKey protocol, this embodiment requires intermediate nodes to add an operation during the session message return phase: attaching their tokens. When the session message is returned from the data provider to the data user, each intermediate node encrypts and signs its own token and adds it to the message payload.

[0033] At this point, for each network intermediate node in the current session It will record a series of relevant information: key Token The logical receiver and logical sender, as well as itself, are the i-th node in the path specified by the session (the next hop of the receiver is the first node).

[0034] S105, the user node obtains the key sequence and token sequence.

[0035] Similar to the standard DRKey protocol, the data user, as the initiator of the session establishment request, parses the key sequence returned by the data provider to obtain the keys of the data provider and all nodes along the route. Further, following the method in S103, after verification, the tokens of all intermediate nodes along the route are parsed to obtain the keys. At this point, the entire session establishment process is complete. As an extension, it allows the data user to not only obtain the session key { }, and you can also get tokens { (Known only to the receiver, this is called receiver-oriented). At this point, each intermediate network node on the path (denoted as a router) Each of these is associated with a session key. and a token The key By the router The token is shared by the data user and the data provider; By the router The data is shared with the data user and kept confidential from the data provider. While preserving the original protocol's security guarantees, the receiver-oriented session establishment process distributes information invisible to the provider and establishes a unified session for the entire request-response process, thus laying the foundation for a receiver-initiated path verification mechanism for data acquisition.

[0036] In this embodiment, all network nodes in the path will process two types of messages in the request phase and the response phase: request packets (RP) and data packets (DP).

[0037] Specifically, each network node performs a series of cryptographic operations to generate or verify path verification fields. Among these, " The operator "" indicates data concatenation. "Operators represent calculations, " The operators represent the same thing. "Indicates the field to be written, and the cryptographic primitives involved can be (but are not limited to) SHA3-256 as the hash function." AES as a symmetric encryption algorithm ), and HMAC based on SHA3-256 as the message authentication code ( "Payload" indicates the message payload.

[0038] As a specific implementation method, the process of a user initializing the path verification header of a request message and sending the message includes: In networks employing path verification, the classic IP header and the Path Verification Header (PVH) together determine the packet forwarding process. The PVH header is typically located between the network layer header and the transport layer header. This embodiment follows this design principle.

[0039] One of the core aspects of this embodiment is that, before the data packet leaves the sending port, all n intermediate nodes (denoted as n) on the predetermined forwarding path of the packet are cryptographically linked. The verification information is integrated into the header to ensure that any deviation from the predetermined path during packet transmission can be detected and discarded immediately.

[0040] See Figure 3 As shown, the path verification header in this embodiment includes the following parts: The Session ID field, 16 bytes, is used to identify a session. Its value is determined when the session is established. The timestamp field (TS), 8 bytes, is used to record the packet creation time and is used to prevent replay attacks. The Request Identifier (ReqID) field, 8 bytes, uniquely identifies each request within a session. It distinguishes different requests without relying on packet load. The hash field (Hash), 16 bytes, is used to verify the integrity of the header: it represents the hash value of the combination of the SessionID, TS, and ReqID fields in the path verification header, and is used for integrity verification.

[0041] The PathValidation Field, 16 bytes, is used by intermediate nodes to update sequentially to implicitly record the actual path. This field implicitly records the actual path traversed by the group, which is used by subsequent intermediate nodes for path validation. It is the only field that is updated sequentially by each intermediate node on the path. The Receiver and Path Verification Field (16 bytes) is used by intermediate nodes to verify the identity of data users and the path they take. This field is used to jointly verify the identity of data users and whether the data packet has traversed the specified path. Specifically, This represents the bidirectional path proof generated by the forwarding path between the data user and the i-th intermediate node of the path.

[0042] The DestinationValidation Field, 16 bytes, is used by the destination node for integrity and path verification. When a data provider or data user is acting as the destination for packet transmission, this field simultaneously performs integrity and path verification. This field binds the packet content to an authenticated forwarding path.

[0043] Overall, This allows each network node along the path to verify the forwarding path (from the source node to itself) and the identity of the data user. The field verifies whether the upstream node correctly forwarded the packet. If verification is successful, normal intermediate nodes will proceed... The field is updated to support subsequent path validation. To reduce the overhead of intermediate nodes, it can also be included only in the packet header. This allows the destination node to verify the entire forwarding path.

[0044] Implementably, based on the key, token, and determined forwarding path, the data user generates a request message containing a path verification header, including: The data user calculates a hash field based on the session identifier, request identifier, and timestamp. Based on the hash field, the key and token assigned to each node on the path, and the key of the data provider, the data user calculates the path verification field, the receiver and path verification field of each node, and the destination verification field through concatenated message authentication codes. The generated fields are assembled into a path verification header and inserted between the network layer header and the transport layer header.

[0045] Specifically, the process includes the following steps: S201, parameter initialization; After the session establishment phase is complete, the data user has determined a path containing n hops for the current request and obtained the following key parameters: The 32-bit request identifier (ReqID) corresponding to this request; Session identifier (SessionID); Each hop node Symmetric encryption information ; A security token visible only to data users and unique to each hop. ; Session key of the data provider ; S202, Generate cryptographic path verification fields; Data users obtain the current timestamp and set the TS field, then use the following formula to calculate the Hash field: .

[0046] The data user will use this hash, along with the key generated during the session setup process. } and tokens { }Keys of the collection and data provider As input, the cascaded calculation process is then defined by the following formula: ; ; : ; ; , ; Generate three core validation fields: (i) path validation field ( ): Used for overall path trustworthiness verification, updated hop-by-hop during packet transmission. (ii) Array of receiver and path verification fields ( ): Each element in the array Dedicated to the corresponding intermediate nodes Used to implement hop-by-hop independent verification. (iii) Destination verification field ( ): Dedicated to the final destination, used to perform end-to-end integrity checks and final path checks.

[0047] The above calculation process ensures that any tampering with any bits in the path verification header will be detected in subsequent verifications. This is due to the per-hop token. Visible only to the data user (i.e. the recipient), even if any third party intercepts the complete message header, they cannot reverse-engineer the valid token sequence, thus fundamentally eliminating the possibility of inserting forged intermediate nodes in the path.

[0048] S203, Assemble the path verification header and send it; The validation fields generated in S202 are assembled into a predefined fixed format as follows: Figure 3 The path verification header is shown. As a newly defined extended header, it is inserted between the network layer header (such as the IP header) and the transport layer header (such as the TCP or UDP header). After packet initialization is complete, the user forwards the packet through the session's pre-defined logical sender interface.

[0049] Through the above steps, this embodiment achieves a cryptographically secure closed loop of "lock-in from the start" from the very beginning of packet transmission. This mechanism effectively resists path deviation attacks at its technical root, ensuring the reliability and trustworthiness of the packet transmission path.

[0050] Implementable, the use of the path verification header, wherein the request message is verified sequentially by intermediate nodes along the forwarding path as it is transmitted, includes: The intermediate node parses the path verification header of the request message and generates a corresponding key and token based on the session identifier. The intermediate node uses the key, token, parsed hash field, and neighbor node identifier to calculate the local expected verification value. The local expected verification value is compared with the corresponding receiver and path verification fields in the message. If they match, the verification is successful. After successful verification, the intermediate node uses the key to encrypt and update the path verification field in the message and forwards the updated request message from the preset forwarding interface.

[0051] As one specific implementation, when the request message reaches the i-th intermediate node on the specified path... At this time, the node will execute a complete localized verification process. This process is characterized by including a series of operations such as parsing, retrieval, recalculation, comparison, updating, and forwarding. Any bit error in the verification result or deviation from the path order will immediately trigger the packet to be discarded directly on the data plane, and may optionally report an alarm to the control plane, thereby achieving hard security constraints.

[0052] S301, Header parsing and key generation; When a message carrying a path verification header arrives at the intermediate node hour, First, parse the fields in the path verification header. Then, Using the mapping relationship established during the session establishment phase (i.e., the mapping table based on "session" to "logical receiver" and "logical sender"), the message is confirmed to be a request message for a valid session, and the corresponding symmetric key is generated. and its corresponding verification token .

[0053] S302, Local verification value recalculation; node Using the session corresponding and Combining the Hash field parsed from the message with the predecessor and successor node identifiers of the current session as input, the same Message Authentication Code (MAC) algorithm as the sender is used to calculate and generate the local expected verification value. The calculation formula is as follows: .

[0054] S303 verification decision and message forwarding; node The locally calculated With the path verification header carried The fields are compared, and the following decision is made: Verification failed: If and If not matched, then The packet should be immediately discarded at the data plane. Optionally, an alarm message indicating path verification failure should be sent to the network control plane.

[0055] Verification successful: If and If they match, the verification is considered successful. Then use the key The path verification field in the message header ( ) performs encryption operations to generate a value for the next-hop node ( Update value used . Update this new value to the message path verification header. Fields: And forward the updated request message from the logical sender pre-defined when the session was established.

[0056] Through the above process, the intermediate node is the i-th hop specified by the path. The following two key pieces of information can be confirmed: (i) the device is indeed located at position i on the predefined path of the packet; and (ii) the forwarding of the upstream node strictly follows the predetermined order. These two verifications together constitute the core guarantee of path strictness.

[0057] Implementable, the step of having the data provider perform end-to-end verification on the request message when it arrives at the data provider (as the data sender) includes: The data provider parses the path verification header of the request message; the data provider uses its own key, the parsed path verification field and the message payload to calculate the local expected destination verification value; the local expected destination verification value is compared with the destination verification field carried in the message, and if they match, the verification is successful.

[0058] As a specific implementation method, once the request message arrives at its destination—the data provider—the data provider will perform end-to-end final verification, jointly determining the "path integrity," "content not tampered with," and "legality of the request source" of the request message. If verification fails, the data provider will silently discard the message; if verification succeeds, it will immediately trigger the subsequent response construction process.

[0059] S401 verification field decryption and local recalculation; When a message carrying a path verification header arrives at the data provider (sender), the data provider first parses out the fields in the path verification header of the request message, and then processes the parsed data... Using the message payload and the predecessor network node identifier as input, the system calculates the desired destination verification value using an authentication and encryption algorithm negotiated with the sender. The calculation formula is shown below: .

[0060] Optionally, the data provider uses its session private key. And the session key with the intermediate node { }, for the path validation field in the packet header ( The reverse decryption operation is performed in order to restore the initial hash value (RP.Hash) generated by the data user.

[0061] S402 Final Ruling and Resolution; The data provider will calculate locally. With the message carried in the request The fields are compared. Optionally, the decrypted data can also be verified simultaneously. Is it consistent with the request message? The fields match. A final decision is made based on the comparison results: Verification failed: If and Mismatch, or (optional validation in progress) and If there is an inconsistency, the data provider will silently discard the message.

[0062] Verification successful: If all verification items are consistent, the data provider confirms the following facts: the outbound path of the request is complete, the message content has not been tampered with during transmission, and the requesting source holds a valid session key. Once the ruling is passed, the data provider immediately initiates the subsequent response construction process.

[0063] As the endpoint of the path and the source of the response, the data provider confirms through the above process that: (i) the entire path chain is intact; (ii) the request content has not been tampered with; and (iii) the request source does indeed possess the session key. Exclusive usage rights. These three verifications together form the trusted foundation for end-to-end communication.

[0064] Implementably, the data provider constructs a response message by reusing the path verification header fields of the request message and recalculating the destination verification fields, including: The data provider reuses the session identifier, timestamp, request identifier, hash, path verification field, and receiver and path verification field array in the path verification header of the request message; the data provider recalculates the destination verification field based on its own key, the path verification field, and the message payload; and assembles the recalculated destination verification field with other reused fields into the path verification header of the response message.

[0065] As a specific implementation method, after the request message is verified by the terminal, the data provider needs to construct the data message in the response process under cryptographic constraints. The core of this method is that the data provider only holds its session private key. Without holding any tokens from intermediate nodes. The data provider is mandated to return responses only in strict reverse order of the request path. Simultaneously, the Path Validation Field (RPV) can be validated bidirectionally, thus enabling the reuse of Hash fields and Request Path Validation Fields (RPV). ), Array of recipient and path verification fields ( ), and recalculate the destination verification field ( The entire construction process can be completed in constant time, and the PVH of the data packets in the response process is finally generated by the operation of ").

[0066] S501 reuses the path verification field of the request message; When constructing data messages, the data provider, in addition to Apart from the fields specified in the request message path verification header, all other fields reuse their corresponding fields. This operation maintains the continuity of the cryptographic chain context during the request and response processes, enabling the verification of the return path to be dual to that of the outgoing path, thus logically forming a complete and consistent cryptographic loop.

[0067] S502 Recalculates the destination verification field; The data provider recalculates according to the following formula. Fields: ; These fields are assembled into a path verification header, and then the data packet is sent.

[0068] This algorithm will not be modified and is not allowed to be modified. This is because the data provider does not possess these tokens in the session facing the receiver. Through this mechanism, the datagram is faithfully transmitted back along the request path, ensuring that only intermediate nodes involved in the original request path can decrypt and process the datagram. On its way back to the data user, the datagram is bound to a designated data retrieval path, maintaining both verifiability and security.

[0069] In practice, the response message is returned in reverse order along the forwarding path, and the intermediate nodes along the path sequentially perform reverse path verification, including: The intermediate node identifies the response message and decrypts the path verification field in the message using the corresponding key of the session. The intermediate node uses the decryption result, the key, and the token to calculate the local expected verification value. The local expected verification value is compared with the corresponding receiver and path verification field in the response message. If they match, the verification is successful. After successful verification, the intermediate node updates the path verification field in the message with the decrypted value and forwards the updated response message to the next hop node.

[0070] As one specific implementation method, when data packets return from the data provider to the intermediate node in strict reverse order of the outgoing path. hour, Reverse path verification will be performed. This method is a dual design to the outbound path verification: Using credentials generated during session establishment, the system performs identification, decryption, recalculation, comparison, update, and forwarding operations. Throughout the process, no state maintenance is required for the return stream to determine whether a response is a legitimate reply to a previously forwarded request. If verification fails, the message is immediately discarded; if successful, the verification field is updated and the message is forwarded to the next hop, thus achieving the hard security constraint that "only the intermediate node that initially participated in forwarding the request can process its corresponding response."

[0071] S601 message identification and field decryption; Message arrived back, Based on the session ID and the ingress interface, identify whether the message type is a data packet (DP).

[0072] If it is a data message, use { The path verification field (DP) carried in the response message. Decryption To restore the functionality required in the S602 verification operation. .

[0073] S602 Local Validation and Field Update; After decryption is complete, The decrypted result The key corresponding to the session Token As input, the same Message Authentication Code Encryption Unit (MAC) as the outgoing route is used for calculation to obtain the local expected verification value. An example of the calculation formula is as follows: ; The calculated The corresponding return verification field DP in the response message extension header. Compare the two: if they do not match, The message is immediately dropped on the data plane; if both conditions are met, permission is granted to continue forwarding.

[0074] After successful verification, Update path validation field ( ), will the message Field updated to , ,for Use. Then, from the session's default outgoing interface to... Forward the updated message.

[0075] Through the above mechanism, intermediate nodes The fidelity of the return path is effectively verified without maintaining the return flow state. This method ensures that: (i) data packets are returned strictly in reverse order of the outgoing path; and (ii) the current node is indeed the i-th hop on the session path. Any unauthorized path injection or detour packets are automatically discarded because they cannot generate a valid RPV value, thus achieving a self-restraint at the cryptographic level that "only the node that originally forwarded the request can process its response."

[0076] Implementable, the step of having the data user perform end-to-end verification when the response message is returned to the data user includes: The data user uses the data provider's key to decrypt the path verification field in the response message to obtain an intermediate result; calculates the local expected destination verification value based on the intermediate result; compares the local expected destination verification value with the destination verification field carried in the response message, and if they match, the verification is successful.

[0077] As a specific implementation method, when the response message is returned to the data user, the data user performs end-to-end final verification. This process is the final closed loop of outbound and return verification, whereby the data user completes a three-dimensional joint judgment on the "content integrity," "return path fidelity," and "data source legitimacy" of the response message. Data can only be submitted if all verifications pass; if any step fails, the message is immediately discarded and an audit or security circuit breaker mechanism may be triggered. This fundamentally suppresses "server unsolicited push" through "user-initiated retrieval," achieving the ultimate security goal of "end-to-end path verifiable and complete end-user control." Specifically, it includes the following steps: S701 data message field decryption and content integrity verification; After receiving the response data packet, the data user uses the session key held by the data provider. Path validation field (DP) in the data message. The code is decrypted, and only when the result is the same as DP.Hash will subsequent verification be performed.

[0078] For DP. Encrypted layer by layer, restored And use the results to calculate the expected verification value. .

[0079] ; ; Data users will recalculate locally With the response message carried Field comparison: If With DP. If there is a mismatch, the path is deemed to be disloyal or the source is illegal, and the data user immediately discards the message; if all comparison items match, the response is confirmed as a legitimate, complete request response returned via the specified path.

[0080] Through the aforementioned ultimate verification mechanism of "decryption-recalculation-double comparison," the data user, as both the starting and ending point of communication, can make the final decision on the "content-path-source" of the response message. Combined with optional auditing, quality reporting, and circuit breaker mechanisms, not only is the verifiability of end-to-end communication ensured at the cryptographic level, but the end user is also given the final decision-making power at the control level, achieving the ultimate security loop of "only data that the user is willing to and requests can reach the application layer."

[0081] As an additional implementation method: to improve processing performance in high-concurrency scenarios, the parallel computing capabilities of modern processors (such as CPUs supporting the AES-NI instruction set) can be utilized to process data from multiple sessions. The fields are batch decrypted and MAC calculated. This optimization is completely consistent with the core solution in terms of cryptographic framework, and only improves throughput at the implementation level through parallel pipelined processing.

[0082] As an additional implementation, data users can maintain a failure statistics sliding window (e.g., recording the 1000 most recent authentication failures and their timestamps). The network controller can periodically retrieve the statistics from this window and dynamically adjust the security policy parameters of the session (such as the token refresh cycle), thereby achieving closed-loop management from "authentication discovery" to "policy control".

[0083] As an additional implementation: to enhance security and address potential replay attacks, this embodiment supports a dynamic token refresh mechanism. Specifically, a refresh strategy can be set (e.g., every 1024 successfully sent packets or every second), and the data user (receiver) executes the token update function in parallel with the relevant nodes: ; in This is a 16-bit packet counter. (Updated) Will be used immediately for subsequent grouping. This calculation effectively shortens the time window for replay attacks while maintaining the hash chain structure.

[0084] In summary, the data transmission process presented in this embodiment maintains strict path fidelity. This design ensures that every data packet returning to the user can be associated with its original requester through receiver-facing sessions and bidirectional path verification fields. Since data providers cannot forge path proofs or push unsolicited data, data users gain complete control over the enforcement, verification, and perception of their data acquisition path. With this control, receivers can combine experience quality feedback with path compliance verification capabilities to verify and evaluate the integrity and status of the data acquisition path in real time.

[0085] The feasible process of performing platform simulation using the method proposed in this embodiment includes: The method proposed in this embodiment, as well as the state-of-the-art methods ICING and OPT, are implemented in the Linux kernel and simulated on a container-based simulation platform.

[0086] Figure 5 This paper demonstrates the distribution of single-node processing latency and end-to-end request-response latency for this method, as well as state-of-the-art methods ICING and OPT, under different end-to-end hop counts.

[0087] The probability density curves show that: at the data provider end, this embodiment directly reuses the request packet header, eliminating the overhead of recalculating RPV, resulting in an average processing time reduction of approximately 30% compared to OPT and over 55% compared to ICING; at the intermediate router, this embodiment requires one decryption and one MAC calculation, with overhead roughly equivalent to OPT, differing by less than 0.1µs; at the data user end, this embodiment adds an additional... Complete verification is performed, but only a negligible delay of <0.4µs ​​is introduced. End-to-end latency distribution shows that the average request-response time for all three methods increases linearly with the number of hops, but this embodiment consistently performs worse than OPT and ICING. In the 8-hop scenario, this embodiment is approximately 10% faster than OPT. The results indicate that the receiver-initiated bidirectional path proof provides stronger path control without incurring additional burdens; on the contrary, it achieves higher data surface efficiency by eliminating the need for proof computation on the provider side.

[0088] Figure 6 This demonstrates the advantages of our method in data acquisition compared to the state-of-the-art OPT method.

[0089] Suppose that the data user initially selects session 1, and at the 5th second, router R2 becomes a malicious node, randomly tampering with the received packets with probability p, and p increases over time.

[0090] Figure 6 The real-time effective throughput (goodput) and file transfer time of OPT and this embodiment are given. The yellow and red curves correspond to this embodiment with α=0.2 and α=0.5, respectively, and the blue curve corresponds to OPT. As p increases with time, the effective throughput of OPT continuously decreases; while the effective throughput of this embodiment first decreases and then increases because data users can actively switch paths after detecting malicious behavior, such as... Figure 4 As shown, the file transfer time in this embodiment is reduced by approximately 57% compared to OPT. More specifically, the embodiment with α=0.2 recovers faster than the scenario with α=0.5.

[0091] This embodiment also extends the attack model to bandwidth fluctuations: router R2 oscillates between normal bandwidth (100MBps) and extremely low bandwidth (25MBps). This experiment ignores packet tampering (i.e., α=1 in this embodiment) and considers two QoS-driven strategies: multiple short periods of low bandwidth and long periods of continuous low bandwidth.

[0092] First, when a bandwidth drop is detected three times in a row, path reselection is triggered, and the blue curve (OPT) continues to decline; the red curve (in this embodiment) recovers after the third significant speed drop, and the effective throughput recovers from about 70MBps and stabilizes at about 67MBps.

[0093] Next, data users are allowed to reselect their paths under prolonged low bandwidth conditions (lasting 8 seconds). Figure 6 The results show that OPT maintained low throughput, but in this embodiment, after detecting continuous degradation, the effective throughput recovered from 15MBps to 66MBps. These results fully demonstrate the advantages of receiver-initiated design in multipath (multi-session) environments.

[0094] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A receiver-initiated path verification method for data acquisition, characterized in that, Includes the following steps: The data user, as the data recipient, obtains the key and token information used for path verification by initiating a session establishment process; Based on the key, token, and determined forwarding path, the data user generates and sends a request message containing a path verification header, which integrates cryptographic fields for verification by each node on the path. Using the path verification header, the request message is verified sequentially by intermediate nodes along the forwarding path as it is transmitted, and the path verification field is updated after successful verification before forwarding. When the request message arrives at the data provider, which is the data sender, the data provider performs end-to-end verification on it. After the verification is successful, the data provider constructs a response message by reusing the path verification header field of the request message and recalculating the destination verification field. The response message is returned in reverse order along the forwarding path, and the intermediate nodes on the path perform reverse path verification in sequence. After the verification is successful, the path verification field is updated and the message is forwarded. When the response message is returned to the data user, the data user performs end-to-end verification to complete the path verification closed loop.

2. The method according to claim 1, characterized in that, The data user, as the data recipient, initiates a session establishment process to obtain key and token information used for path verification, including: Data users generate and send session packets containing session public keys, path information, and timestamps; After receiving the session establishment packet, the intermediate node on the path generates its own session symmetric key, determines the forwarding interface based on the path information in the packet, maintains the binding relationship between the session identifier and the forwarding interface, and then forwards the session establishment packet. After receiving the session establishment packet, the data provider verifies its authenticity and generates its own session key. At the same time, it obtains the session symmetric keys of all intermediate nodes on the path, encrypts them, and sends them back. During the backhaul process, the intermediate node encrypts and signs its own token and adds it to the backhaul message; The data user parses the returned message to obtain the session symmetric key of the data provider and all intermediate nodes, as well as the tokens of all intermediate nodes.

3. The method according to claim 1, characterized in that, The path verification header includes: A session identifier field used to identify the session; A timestamp field used to record the time when a group is created; A request identifier field used to uniquely identify a request within a session; A hash field used to verify header integrity; A path validation field used by intermediate nodes to implicitly record the actual path and update it sequentially. An array of recipient and path verification fields used by each intermediate node to verify the user's identity and path in the data; The destination verification field is used for integrity and path verification by the destination node.

4. The method according to claim 1, characterized in that, Based on the key, token, and determined forwarding path, the data user generates a request message containing a path verification header, including: The data user calculates the hash field based on the session identifier, request identifier, and timestamp; The data user generates the path verification field, the receiver and path verification field of each node and the destination verification field by calculating the path verification field, the key and token generated by each node in the path according to the session, and the key of the data provider through the concatenated message authentication code, based on the hash field, the key and token generated by each node in the path and the key of the data provider. The generated fields are assembled into a path validation header and inserted between the network layer header and the transport layer header.

5. The method according to claim 1, characterized in that, Using the path verification header, the request message is verified sequentially by intermediate nodes along the forwarding path as it is transmitted, including: The intermediate node parses the path verification header of the request message and generates the corresponding key and token based on the session identifier; The intermediate node uses the key, token, parsed hash field, and neighboring node identifier to calculate the local expected verification value; The local expected verification value is compared with the corresponding receiver and path verification fields in the message. If they match, the verification is successful. After successful verification, the intermediate node uses the key to encrypt and update the path verification field in the message, and forwards the updated request message from the preset forwarding interface.

6. The method according to claim 1, characterized in that, When the request message arrives at the data provider, which is the data sender, the data provider performs end-to-end verification, including: The data provider parses the path verification header of the request message; The data provider uses its own key, the parsed path verification field, and the message payload to calculate the local expected destination verification value; The local expected destination verification value is compared with the destination verification field carried in the message. If they match, the verification is successful.

7. The method according to claim 1, characterized in that, The data provider constructs a response message by reusing the path verification header fields of the request message and recalculating the destination verification fields, including: The data provider reuses the session identifier, timestamp, request identifier, hash, path verification field, and receiver and path verification field array in the path verification header of the request message; The data provider recalculates the destination verification field based on its own key, the path verification field, and the message payload; The recalculated destination verification field is assembled with other reused fields into the path verification header of the response message.

8. The method according to claim 1, characterized in that, The response message is returned in reverse order along the forwarding path, and the intermediate nodes along the path sequentially perform reverse path verification, including: The intermediate node identifies the response message and decrypts the path verification field in the message using the corresponding key of the session; The intermediate node uses the decryption result, the key, and the token to calculate the local expected verification value; The local expected verification value is compared with the corresponding receiver and path verification fields in the response message. If they match, the verification is successful. After successful verification, the intermediate node updates the path verification field in the message with the decrypted value and forwards the updated response message to the next hop node.

9. The method according to claim 1, characterized in that, When the response message is returned to the data user, the data user performs end-to-end verification, including: The data user uses the data provider's key to decrypt the path verification field in the response message to obtain the intermediate result; The local expected target verification value is calculated based on the intermediate results; The local expected destination verification value is compared with the destination verification field carried in the response message. If they match, the verification is successful.

10. The method according to claim 1, characterized in that, The method further includes: According to a preset strategy, data users execute the token update function in parallel with relevant nodes to generate new tokens for the calculation of path verification fields in subsequent messages.

Images