A message propagation method, device, medium and system

Abstract

The application relates to the technical field of network security, in particular to a message propagation method, device, medium and system. The method comprises the following steps: signing all contents of a first message package, generating an accumulated signature corresponding to an intermediate forwarding node; appending the accumulated signature and a digital certificate corresponding to the intermediate forwarding node to the first message package to generate a second message package; forwarding the second message package based on a Gossip protocol; and performing no signature verification operation in the forwarding process by the intermediate forwarding node, and performing the signature verification operation by a target consumer node. By postponing all verification work to the final consumer node for execution, the forwarding operation of the intermediate node is simplified, so that the additional cost of each hop is extremely small. Meanwhile, since the complete certificate chain and signature chain are carried in the first message package, the intermediate node does not need to backtrack the historical data in subsequent forwarding, so that the efficient propagation of the message in the large-scale distributed network is realized without sacrificing the security.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a message propagation method, device, medium and system. Background Technology

[0002] In distributed networks such as the Internet of Things (IoT), edge computing clusters, and distributed data centers, nodes frequently need to disseminate critical security-sensitive data, such as access control policies, key distribution materials, security alerts, and configuration baselines. Because these networks are often large-scale, with nodes dynamically joining or leaving, frequent topology changes, and a lack of natural trust between nodes, enabling the rapid and reliable dissemination of secure data among numerous unfamiliar nodes without relying on a central node has long been a fundamental requirement in this field. The Gossip protocol, due to its advantages such as simple implementation, strong fault tolerance, ability to achieve near-network-wide synchronization with O(logN) hops, and fast convergence speed, has been widely chosen as a data dissemination framework for such scenarios.

[0003] To meet the aforementioned requirements for secure data propagation, related technologies have proposed methods to overlay trusted propagation capabilities onto the Gossip framework. Specifically, after a message is sent by the source node, each node receiving the message in the network uses asymmetric cryptography to verify the signature carried in the received message, made by the previous hop node, before forwarding it to other neighboring nodes. Only after verifying and confirming the authenticity of the signature and that the message has not been tampered with in the previous hop, does the node continue to propagate to its neighbors. By performing signature verification and re-signing at each hop in the forwarding path, the final receiver can confirm the complete forwarding path the message has traversed from the source node and is certain that no node on the path has tampered with the message content. However, this practice of verifying and re-signing at each hop, given the high single-trip cost of asymmetric signature verification, and the fact that this cost is multiplied by the number of hops and concurrent messages, results in considerable signature verification latency at each hop. Under high concurrency, signature verification tasks accumulate in the CPU queue, leading to limited forwarding throughput, increased end-to-end latency, and even congestion and packet loss, weakening the fast convergence characteristics of Gossip. However, the number of network nodes can now reach thousands or even tens of thousands, the update frequency of security data (such as policies and alarms) has increased significantly, the amount of messages that need to be disseminated per unit time has increased dramatically, and messages are required to converge across the entire network within seconds or even sub-seconds.

[0004] Therefore, how to improve the efficiency of secure message transmission is a technical problem that urgently needs to be solved in this field. Summary of the Invention

[0005] The purpose of this application is to provide a message propagation method, device, medium, and system that enables messages to be propagated efficiently in large-scale distributed networks without sacrificing security.

[0006] Firstly, a message propagation method is provided, wherein the message propagation method is executed by an intermediate forwarding node, including:

[0007] The system receives a first message packet, which includes business data, a timestamp token, a digital certificate chain, and a signature chain. The business data is generated by the source node. The timestamp token is obtained by the source node from a timestamp server and includes a digital hash of the business data, a trusted time value, and a digital signature from the timestamp server. The digital certificate chain includes the digital certificates of all nodes preceding the intermediate forwarding node, and these digital certificates are issued by the root certificate authority. The signature chain includes the signatures of all nodes preceding the intermediate forwarding node.

[0008] Sign all contents of the first message packet to generate an accumulated signature corresponding to the intermediate forwarding node;

[0009] The accumulated signature and the digital certificate corresponding to the intermediate forwarding node are appended to the first message packet to generate the second message packet;

[0010] The second message packet is forwarded based on the Gossip protocol. The intermediate forwarding node does not perform signature verification during the forwarding process; the signature verification operation is performed by the target consumer node.

[0011] In a preferred embodiment, this application can be further configured such that the extended field of the digital certificate contains a transmission policy.

[0012] After receiving the first message packet, it also includes:

[0013] Check the validity of the digital certificate of the previous node in the first message packet;

[0014] If the digital certificate of the previous node is valid, then read the transmission policy from the extended field of the digital certificate of the previous node;

[0015] According to the transmission policy of the previous node, perform a policy check on the first message packet;

[0016] If the policy check passes, then the step of signing all the contents of the first message packet and generating the cumulative signature corresponding to the intermediate forwarding node is executed.

[0017] If the policy check fails, the first message packet is discarded and a security event is generated.

[0018] In a preferred embodiment, this application can be further configured to: perform a policy check on the first message packet according to the transmission policy of the previous node, including:

[0019] Check whether the data type of the service data is within the range of data types allowed to be forwarded by the transmission policy of the previous node;

[0020] Check whether the current propagation hop count exceeds the maximum propagation hop count allowed by the transmission strategy of the previous node;

[0021] Check whether the intermediate forwarding node and the previous hop node belong to the same security domain allowed by the transmission policy of the previous node.

[0022] Secondly, a message propagation method is provided, which is executed by a target consumer node, including:

[0023] Receive a second message packet forwarded by an intermediate forwarding node. The second message packet includes business data, a timestamp token, a digital certificate chain, and a signature chain. The second message packet is generated based on any one of the message propagation methods of claims 1 to 3.

[0024] Verify the legality of the digital certificates of each node in the digital certificate chain in the second message packet, and verify the compliance of the transmission policy in each digital certificate;

[0025] After verifying the legitimacy of the digital certificates and the compliance of the transmission policies in each digital certificate, verify the validity of the timestamp tokens and the correctness of each signature in the signature chain.

[0026] If the timestamp token is valid and all signatures in the signature chain are correct, the business data of the second message packet is obtained.

[0027] In a preferred embodiment, the method may be further configured as follows: the method further includes: discarding the message packet after verifying that the digital certificate is invalid, or that the transmission policy in each digital certificate is non-compliant; and discarding the message packet if the timestamp token is invalid, or if any signature in the signature chain is incorrect.

[0028] And / or, verify the legality of the digital certificates of each node in the second message packet, including: using the root certificate of the locally pre-configured root certificate authority, verifying whether the digital certificate of each node was issued by a trusted certificate authority and has not been revoked;

[0029] And / or, verify the compliance of the transmission policy in each digital certificate, including: starting from the source node, sequentially extracting the transmission policy of each digital certificate in the signature chain; for each digital certificate, verifying whether the node corresponding to the digital certificate meets the corresponding transmission policy when propagating the business data, wherein the transmission policy includes at least one of the following: allowed data types for forwarding, maximum propagation hops, and allowed security domain range for communication.

[0030] In a preferred example, this application can be further configured to: verify the validity of the timestamp token, including:

[0031] The validity of the digital signature of the timestamp server in the timestamp token is verified using a locally pre-installed timestamp authority certificate.

[0032] Extract the trusted time value from the timestamp token and verify whether the trusted time value is within the allowed time window;

[0033] Calculate the hash value of the business data, and verify the consistency between the calculated hash value and the digital hash of the business data in the timestamp token;

[0034] If all verifications pass, the timestamp token is deemed valid.

[0035] In a preferred embodiment, this application can be further configured such that verifying the correctness of each signature in the signature chain includes:

[0036] Extract the public key from the digital certificate of the source node in the second message packet, and verify whether the signature of the source node is a complete signature of the business data and timestamp token by the public key;

[0037] The public key in the digital certificate of each intermediate forwarding node is extracted sequentially, and each accumulated signature is verified to be signed by the corresponding public key on the preceding accumulated message packet. The preceding accumulated message packet includes the business data, the timestamp token, the signature of the source node, and the digital certificates and accumulated signatures of each preceding intermediate forwarding node.

[0038] Thirdly, an electronic device is provided, the electronic device including a memory and a processor, the memory storing a computer program, the processor executing the method of any one of the first aspects, or the method of any one of the second aspects, when running the computer program.

[0039] Fourthly, a computer-readable storage medium is provided, wherein at least one piece of program code is stored therein, the program code being loaded and executed by a processor to implement the method as described in any of the first aspects, or the method as described in any of the second aspects.

[0040] Fifthly, a computer program product is provided, comprising a computer program or instructions that, when executed by a processor, implement the method as described in any of the first aspects, or the method as described in any of the second aspects.

[0041] Sixthly, a message propagation system is provided, including: a source node, at least one intermediate forwarding node, and a target consumer node;

[0042] The source node generates business data and sends a request to the timestamp server based on the business data to obtain a timestamp token that includes the digital hash of the business data, a trusted time value, and the digital signature of the timestamp server. It then signs the business data and the timestamp token to obtain the signature corresponding to the source node. An initial message packet is generated, which includes the business data, the timestamp token, the source node's digital certificate, and the source node's signature. Finally, the message packet is forwarded to intermediate forwarding nodes based on the Gossip protocol.

[0043] The intermediate forwarding node is used to implement the method as described in any of the first aspects; the target consumer node is used to implement the method as described in any of the second aspects.

[0044] In summary, the method provided in this application offers the following beneficial technical effects: The first message packet is constructed as a composite structure containing business data, a timestamp token, a digital certificate chain, and a signature chain. The business data is generated by the source node, and the timestamp token is obtained by the source node from a trusted timestamp server. The token contains a digital hash of the business data, a trusted time value, and a digital signature from the TSA. The digital certificate chain and signature chain record the certificates and signatures of each node preceding the intermediate forwarding node, respectively. The business data and timestamp token are bound at the source, ensuring that the hash value of the message content is endorsed by an authoritative third party. Any subsequent modification to the business data will result in hash comparison failure. The existence of the digital certificate chain allows the identity of each hop node to be traced. The existence of the signature chain allows the forwarding behavior of each hop node to be verified. Based on this, after receiving the first message packet, the intermediate forwarding node signs the entire content of the first message packet to generate an accumulated signature. This accumulated signature, along with its own certificate, is appended to the end of the message packet before forwarding it based on the Gossip protocol. No signature verification operation is performed during this process. By deferring all verification work to the final consumer node, the forwarding operations of intermediate nodes are simplified, resulting in minimal overhead for each hop. Furthermore, since the first message packet already carries the complete certificate and signature chains, intermediate nodes do not need to backtrack and request historical data during subsequent forwarding, further ensuring efficient message propagation in large-scale distributed networks without sacrificing security.

[0045] In addition, this application also provides an apparatus, a medium, and a system, all of which have the aforementioned beneficial technical effects. Attached Figure Description

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

[0047] Figure 1 This is a schematic diagram of a message propagation system provided in an embodiment of this application;

[0048] Figure 2 This is a schematic diagram of a message propagation method provided in an embodiment of this application;

[0049] Figure 3 This is a schematic diagram of another message propagation method provided in an embodiment of this application;

[0050] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0051] This specific embodiment is merely an explanation of this application and is not intended to limit it. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of this application.

[0052] It should be noted that, in the optional embodiments of this application, the data related to object information, when applied to specific products or technologies, requires the permission or consent of the object. Furthermore, the collection, use, and processing of this data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. In other words, if the embodiments of this application involve data related to an object, it must be obtained with the permission and consent of the object, the permission and consent of relevant departments, and in accordance with the relevant laws, regulations, and standards of the country and region. If the embodiments involve personal information, the acquisition of all personal information requires the consent of the individual. If sensitive information is involved, the separate consent of the information subject is required. The embodiments also need to be implemented with the permission and consent of the object.

[0053] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0054] Furthermore, the terms "and / or" in this document are merely descriptions of the relationships between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0055] Conventional end-to-end signatures cannot prove that intermediate nodes have not been tampered with or hijacked, and end-to-end signature verification introduces a large amount of asymmetric computation, severely damaging Gossip's propagation efficiency. Furthermore, existing solutions lack time freshness guarantees based on trusted third parties, failing to effectively defend against replay attacks and lacking fine-grained policy control over forwarding node behavior. Any legitimate node can unconditionally forward all types of data, violating the principle of least privilege. Therefore, a method is needed that can simultaneously provide proof of the complete propagation path, certificate validity verification, trusted time window anti-replay, and policy-driven forwarding control, while minimizing the additional overhead on the propagation path and maintaining Gossip's fast convergence characteristics.

[0056] To facilitate understanding, the key terms involved in the embodiments of this application will be explained in a unified manner first.

[0057] The Gossip protocol is a distributed communication protocol in which each node in the network randomly selects one or more neighboring nodes to forward a message after receiving it. The message spreads through the network in a manner similar to the spread of rumors until all nodes in the network have received the message. It typically achieves network convergence in O(logN) hop counts, with specific implementations such as Push-Pull Gossip and Anti-Entropy Gossip.

[0058] Zero-trust architecture refers to a network security architecture that "never trusts and always verifies". No node is trusted by default in data interaction because of its position in the network or its existing identity. All data must pass verifiable security verification before it is finally used.

[0059] A digital certificate is an electronic document issued by a Certificate Authority (CA) to prove the identity of a node and the ownership of its public key. For example, a certificate conforming to the X.509 standard may contain extended fields in addition to the usual fields such as node identity information and node public key.

[0060] The root certificate authority (hereinafter referred to as rootca) is the top-level certificate issuing authority in a zero-trust system that is trusted by all legitimate nodes. The root certificate Root_CA issued by rootca is pre-installed on the local machine of each legitimate node.

[0061] The transmission policy refers to the policy attributes written into the X.509 extended fields of a digital certificate, which are used to declare the forwarding behavior allowed for the certificate-holding node. For example, the data types allowed to be forwarded (such as only device health reports, threat intelligence, etc.), the maximum number of propagation hops allowed, and the security domain / network segment range allowed for communication. This policy is bound when the certificate is issued and cannot be tampered with.

[0062] A timestamp server, also known as a Time Stamping Authority (TSA), is a server that acts as a trusted third party and provides trusted time endorsement for data in accordance with the RFC3161 standard. The timestamp tokens it issues are cryptographically non-repudiable.

[0063] A timestamp token is a token returned by a timestamp server in accordance with the RFC3161 standard. Its core data structure includes: the signed data hash (i.e., the hash value H submitted by the requester), the trusted time value (GenTime), and the digital signature of the timestamp server.

[0064] Accumulated signatures refer to the signature value obtained by an intermediate forwarding node using its own private key to sign all the preceding content in the message packet (i.e., all the fields that existed before the intermediate forwarding node received the message packet). The accumulated signatures of multiple nodes are arranged in the order of propagation to form a signature chain.

[0065] Payload refers to the actual data content generated by the source node and expected to be propagated in the network, such as device health reports, threat intelligence, and configuration synchronization data.

[0066] Please refer to Figure 1 , Figure 1 This is a schematic diagram of a message propagation system provided in an embodiment of this application. The application scenario is a distributed data synchronization scenario in a zero-trust network environment, involving a source node Node_0, several intermediate forwarding nodes Node_1 to Node_{n-1}, and a target consumer node Node_n.

[0067] Furthermore, it can also include: root certificate authority (rootca) and timestamp server (TSA).

[0068] The process involves several nodes: the source node generates business data and sends a request to the timestamp server to obtain a timestamp token containing the digital hash of the business data, a trusted time value, and the timestamp server's digital signature; it then signs the data and the timestamp token to obtain its own signature; an initial message packet is generated, containing the business data, the timestamp token, the source node's digital certificate, and its signature; and finally, the message is forwarded to intermediate forwarding nodes using the Gossip protocol. The intermediate forwarding nodes implement the message propagation methods they execute. The target consumer node also implements the message propagation methods it executes.

[0069] Specifically, during the system initialization phase, all legitimate nodes within the zero-trust system possess a digital certificate, Cert_Node, issued by the root certificate authority, rootca. Each node pre-installs the same root certificate, Root_CA, and a timestamp server certificate, Cert_TSA, used to verify the legitimacy of other nodes' certificates and the signature in the timestamp token, respectively. Before joining the zero-trust system, each node submits a signature request carrying its own transmission policy to rootca. When issuing the digital certificate, rootca writes the node's transmission policy into the extended field of the X.509 certificate; the node then installs the digital certificate. Thus, each node corresponds to a unique digital certificate containing identity information and its transmission policy.

[0070] During system operation, the source node performs the following processing: generates the business data payload to be propagated; calculates H = Hash(Payload); initiates a timestamp request to the timestamp server TSA and sends H to the TSA; receives the timestamp token (TimestampToken) compliant with RFC3161 returned by the TSA; signs the entire (Payload||TimestampToken) using its own private key to generate Sign_0; constructs an initial message packet (business data payload, timestamp token, source node's digital certificate Cert_0, source node's signature Sign_0); and sends the initial message packet based on the Gossip protocol. The message packet propagates hop-by-hop along intermediate forwarding nodes. Each intermediate forwarding node only performs a lightweight policy check and accumulates a signature, without performing signature verification. Intermediate forwarding nodes perform certificate checks, policy checks, signature accumulation, and random forwarding hop-by-hop. The target consumer node performs two levels of verification: the target consumer node centrally completes certificate chain verification, transmission policy compliance verification, timestamp token verification, and signature chain verification, and consumes the business data only after all verifications are passed. The entire system constitutes a complete zero-trust propagation system consisting of source node timestamp anchoring and overall signature, intermediate forwarding nodes lightweight checks and signature accumulation, and target consumer nodes two-level deep verification.

[0071] This application provides a message propagation method, such as... Figure 2As shown, the method provided in this application embodiment can be executed by an electronic device, which is a server. This server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. The electronic device can be a smartphone, tablet, laptop, desktop computer, etc., but is not limited to these. This application embodiment does not impose any limitations on these. The method is applied to any intermediate forwarding node Node_i (i is an integer greater than or equal to 1) in a zero-trust network environment. The method includes the following steps 110 to 140, wherein:

[0072] Step S110: Receive the first message packet.

[0073] The first message packet includes business data, a timestamp token, a digital certificate chain, and a signature chain. The business data is generated by the source node. The timestamp token is obtained by the source node from the timestamp server. The timestamp token includes the digital hash of the business data, a trusted time value, and the digital signature of the timestamp server. The digital certificate chain includes the digital certificates of each node before the intermediate forwarding node. The digital certificates are issued by the root certificate authority. The signature chain includes the signatures of each node before the intermediate forwarding node.

[0074] The first message packet represents a message data packet transmitted via the Gossip protocol, sent by the previous node and received by an intermediate forwarding node; the previous node can be the source node or any other intermediate forwarding node. If the previous node is the source node, the digital certificate chain only includes the source node's digital certificate, and the signature chain only includes the source node's signature; the source node's signature is obtained by signing the business data and the timestamp token. The source node is the first node that generates business data and initiates message propagation (denoted as Node_0). The source node is the propagation initiator and does not need to perform verification on any other nodes.

[0075] The payload represents the actual data content generated by the source node and intended to be propagated in the network, such as device health reports, threat intelligence, and configuration synchronization data. The timestamp token represents a token conforming to the RFC3161 standard, obtained by the source node from a timestamp server. The digital hash represents the digest value obtained by calculating a hash function on the payload data, such as a hash calculated using the SHA-256 algorithm. The trusted time value refers to the trusted time for this timestamp request by the timestamp server; the digital signature of the timestamp server refers to the timestamp server signing the token content (including the digital hash and trusted time value) using its own private key. The digital certificate chain represents an ordered set of digital certificates from all nodes preceding intermediate forwarding nodes (including the source node and all intermediate forwarding nodes preceding it) arranged in the propagation order within the message packet. A digital certificate is an X.509 certificate issued by a root certificate authority, containing node identity information, the node's public key, and a transmission policy written into an extended field. A signature chain represents an ordered set of signatures from all nodes preceding intermediate forwarding nodes in a message packet, arranged in the order of propagation. This includes the source node's source signature of the business data and timestamp token as a whole, as well as the cumulative signatures of each intermediate forwarding node for the preceding content.

[0076] When the previous node sends a message packet to this intermediate forwarding node Node_i based on the Gossip protocol, this node receives the first message packet. The internal structure of the first message packet, in field order, is as follows: business data Payload, timestamp token, source node digital certificate Cert_0, source node signature Sign_0, and the digital certificates and accumulated signatures of the preceding intermediate forwarding nodes arranged in the propagation order: Cert_1, Sign_1, Cert_2, Sign_2, ..., Cert_{i-1}, Sign_{i-1}; where Cert_0 to Cert_{i-1} constitute the digital certificate chain, and Sign_0 to Sign_{i-1} constitute the signature chain. It should be noted that in this step, the intermediate forwarding node only receives and caches the message packet, does not check the timestamp token in the message packet, and does not perform signature verification operations on any signature in the signature chain.

[0077] Step S120: Sign all contents of the first message packet to generate the cumulative signature corresponding to the intermediate forwarding node.

[0078] All content refers to all fields in the first message packet that existed before the intermediate forwarding node signed it, i.e., the preceding accumulated content. Specifically, this includes the business data Payload, TimestampToken, source node digital certificate Cert_0, source node signature Sign_0, and the digital certificates Cert_1 to Cert_{i-1} and accumulated signatures Sign_1 to Sign_{i-1} of each preceding intermediate forwarding node, i.e.: Payload||TimestampToken||Cert_0||Sign_0||Cert_1||Sign_1||……||Cert_{i-1}||Sign_{i-1}. The private key is the asymmetric key corresponding to the public key in the intermediate forwarding node's digital certificate, held only by that node.

[0079] Step S130: Append the accumulated signature and the digital certificate corresponding to the intermediate forwarding node to the first message packet to generate the second message packet.

[0080] Here, "append" refers to the operation of concatenating new fields in a predetermined order to the end of the first message packet. The digital certificate (Cert_i) corresponding to the intermediate forwarding node refers to the digital certificate held by that node itself, issued by the root certificate authority, and containing the node's transmission policy in the X.509 extended fields. The second message packet represents the updated message packet obtained after completing the node's cumulative signature and certificate appending, used for forwarding to the next node.

[0081] Specifically, the intermediate forwarding node Node_i constructs a new data block Block_i, which contains two fields: one is its own digital certificate Cert_i (including the transmission policy extension field), and the other is the accumulated signature Sign_i generated in step S120. Subsequently, the node appends the data block Block_i to the end of the first message packet, that is, it concatenates it after the preceding content Payload||TimestampToken||Cert_0||Sign_0||……||Cert_{i-1}||Sign_{i-1}, forming the second message packet. At this point, the digital certificates in the second message packet, arranged sequentially from Cert_0 to Cert_i, form a longer digital certificate chain, and the signatures, arranged sequentially from Sign_0 to Sign_i, form a longer signature chain. The message packet completely records all propagation path evidence from the source node to this node.

[0082] The identity credentials (digital certificate) and propagation credentials (cumulative signature) of this node are written into the message packet together, so that the message packet continuously accumulates a complete certificate chain and signature chain as it propagates. By adopting the above technical solution, the message packet automatically carries the non-repudiable evidence of the hop node at each hop, and any subsequent node, especially the target consumer node, can completely reconstruct the propagation path based on this evidence chain.

[0083] Step S140: Forward the second message packet based on the Gossip protocol. The intermediate forwarding node does not perform signature verification during the forwarding process. The signature verification operation is performed by the target consumer node.

[0084] Among them, Gossip protocol forwarding refers to a random diffusion forwarding method in which a node randomly selects one or more nodes from its set of neighboring nodes and sends out message packets.

[0085] Specifically, the intermediate forwarding node Node_i entrusts the Gossip communication module to perform random forwarding of the second message packet: the node randomly selects one or more neighboring nodes from its locally maintained neighbor node table as forwarding targets, encapsulates the second message packet into a transmission message, and sends it to the selected neighboring node; if part of the transmission fails, it can select other neighboring nodes to resend according to the retry mechanism of the Gossip protocol, until the number of forwardings set by the protocol is reached or a sufficient number of acknowledgments are received. During the entire forwarding process, the node only performs a certificate field read once (in the implementation of policy checking) and a private key signature operation once, without performing any asymmetric signature verification operations. While sending the preceding byte data to the next node, it calculates the cumulative signature of the preceding content in parallel, appends the signature after signing, and forwards it. The timestamp token is completely transparent to the intermediate forwarding node, and the node does not check or process any content of the timestamp token.

[0086] As can be seen, in this embodiment, the first message packet is constructed as a composite structure including business data, a timestamp token, a digital certificate chain, and a signature chain. The business data is generated by the source node, and the timestamp token is obtained by the source node from a trusted timestamp server. The token contains a digital hash of the business data, a trusted time value, and a TSA digital signature. The digital certificate chain and signature chain record the certificates and signatures of each node before the intermediate forwarding node, respectively. The business data and timestamp token are bound at the source, ensuring the hash value of the message content is endorsed by an authoritative third party. Any subsequent modification to the business data will result in hash comparison failure. The existence of the digital certificate chain allows the identity of each hop node to be traced, and the existence of the signature chain allows the forwarding behavior of each hop node to be verified. Based on this, after receiving the first message packet, the intermediate forwarding node signs the entire content of the first message packet to generate an accumulated signature, appends the accumulated signature and its own certificate to the end of the message packet, and forwards it based on the Gossip protocol. No signature verification operation is performed during this process. By postponing all verification work to the final consumer node, the forwarding operation of the intermediate nodes is simplified, resulting in minimal overhead for each hop. Meanwhile, since the first message packet already carries the complete certificate chain and signature chain, intermediate nodes do not need to backtrack and request historical data when forwarding it in subsequent sessions, which further ensures that the message can be efficiently propagated in a large-scale distributed network without sacrificing security.

[0087] In one possible implementation of this application embodiment, the extended field of the digital certificate includes a transmission policy. After receiving the first message packet, the method further includes checking the validity of the digital certificate of the previous node in the first message packet; if the digital certificate of the previous node is valid, then the transmission policy in the extended field of the digital certificate of the previous node is read; according to the transmission policy of the previous node, a policy check is performed on the first message packet; if the policy check passes, then the step of signing all the contents of the first message packet and generating an accumulated signature corresponding to the intermediate forwarding node is performed; if the policy check fails, the first message packet is discarded and a security event is generated.

[0088] The transmission policy refers to the policy attributes written by the root certificate authority into the X.509 extended fields when the digital certificate is issued, declaring the forwarding behavior allowed for the certificate-holding node. Its content includes the allowed data types (e.g., device health reports only, threat intelligence, etc.), the maximum allowed propagation hops, and the allowed security domain / network segment range for communication. The previous node refers to the node that sent the first message packet to this intermediate forwarding node, and its digital certificate is Cert_{i-1}. Legitimacy indicates that the digital certificate is valid and the issuer is the root certificate authority. Security events refer to alarm records generated by the node when it detects an anomaly, used for logging and reporting, such as log records containing fields such as event time, message digest, and failure reason.

[0089] Specifically, the intermediate forwarding node Node_i extracts the digital certificate Cert_{i-1} attached to the previous hop node from the first message packet, checks whether the certificate is valid (e.g., compares the NotBefore and NotAfter fields in the certificate with the current local time), and whether the issuer of the certificate is the root certificate authority (e.g., reads the issuer field of the certificate and compares it with the locally preset root certificate subject information).

[0090] If the verification confirms the validity of the previous node's digital certificate, the process continues by reading the transmission policy written in the X.509 extended field of Cert_{i-1}. Based on this transmission policy, a policy check is performed on the first message packet to determine whether the forwarding of the message by this node complies with the policy constraints declared in the previous node's certificate. If the policy check passes, step S120 is executed to sign all content of the first message packet and generate an accumulated signature. If the policy check fails, the first message packet is immediately discarded and a security event is generated, achieving zero-trust least privilege control at the forwarding level. It should be noted that this certificate check and policy check process does not require any asymmetric signature verification computation; it only needs to read the certificate fields, therefore it does not affect forwarding efficiency.

[0091] As can be seen, in this embodiment of the application, after receiving the first message packet, the intermediate forwarding node first checks the validity of the digital certificate of the previous node. Only when the certificate is valid will it read the transmission policy in its extended field and perform the policy check. The transmission policy written in the extended field of the digital certificate is bound by the authoritative authority when the certificate is issued. The policy is immutable after being signed by the root certificate. Only after the policy check is passed can the signature accumulation and forwarding process be entered. Otherwise, the message is directly discarded and a security event is generated.

[0092] In one possible implementation of this application embodiment, in order to further refine the specific criteria for policy checking, in this application embodiment, policy checking is performed on the first message packet according to the transmission policy of the previous node, including: checking whether the data type of the service data is within the range of data types allowed to be forwarded by the transmission policy of the previous node; checking whether the current propagation hop count exceeds the maximum propagation hop count allowed by the transmission policy of the previous node; and checking whether the intermediate forwarding node and the previous hop node belong to the same security domain allowed by the transmission policy of the previous node.

[0093] Here, `data type` indicates the business category to which the business data belongs, such as device health reports, threat intelligence, configuration synchronization data, log data, etc. `data type range` indicates the set of data types declared and allowed for forwarding in the transmission policy. `current propagation hop count` indicates the number of times the message packet has been forwarded since it was sent from the source node. For example, it can be determined based on the length of the signature chain in the message packet (i.e., the cumulative number of signatures). If the signature chain contains i signatures from Sign_0 to Sign_{i-1}, the current propagation hop count is i. `maximum propagation hop count` indicates the upper limit of the number of hops allowed for message propagation declared in the transmission policy. `security domain` indicates the security domain identifier or set of IP network segments where the peer node is allowed to communicate, as declared in the transmission policy, such as security domain A or 10.0.1.0 / 24.

[0094] Specifically, the intermediate forwarding node performs three checks:

[0095] The first step is to check whether the data type of the business data is within the range of data types allowed to be forwarded by the transmission policy of the previous node. For example, extract the type identifier field from the business data header of the message packet and compare it with the set of allowed types declared by the transmission policy in the Cert_{i-1} extended field. If the type identifier matches any allowed type in the set, then this step passes.

[0096] The second step is to check whether the current propagation hop count exceeds the maximum propagation hop count allowed by the previous node's transmission strategy. For example, the current hop count is taken as the signature chain length and compared with the maximum hop count declared by the transmission strategy. If it does not exceed the limit, this step passes.

[0097] The third step is to check whether the intermediate forwarding node and the previous hop node belong to the same security domain allowed by the previous node's transmission policy. For example, compare whether the security domain identifier of this node is consistent with the security domain identifier of the previous hop node and belongs to the list of security domains allowed by the policy, or compare whether the address of this node and the address of the previous hop node fall into the same network segment allowed by the policy.

[0098] If any one of the three checks fails, the policy check is deemed to have failed, the message packet is discarded, and a security event is generated; if all three checks pass, the policy check is deemed to have passed.

[0099] In some embodiments, a sequential short-circuit checking approach can be adopted, first performing a data type check, then a hop count check, and finally a security domain check. Failure at any stage results in a short-circuit error and a failure result is returned, preventing further checks from being executed, thus reducing unnecessary computation. It is understood that other methods can also be used to implement policy checks, and this is not limited here.

[0100] As can be seen, in this embodiment, the criteria are based on three dimensions: data type, propagation hop count, and security domain, so that the zero-trust least privilege principle is implemented as a deterministic check that can be executed hop by hop, thereby avoiding the overhead of deep packet inspection while controlling the node forwarding behavior with fine granularity.

[0101] Furthermore, embodiments of this application provide a message propagation method executed by the target consumer node; please refer to [reference needed]. Figure 3 , Figure 3 This is a flowchart illustrating a message propagation method executed by a target consumer node, as provided in an embodiment of this application. The method is applied to a target consumer node Node_n in a zero-trust network environment.

[0102] In one possible implementation of this application embodiment, in order to complete zero-trust verification before the message is finally used, without increasing the verification burden on intermediate nodes, this application embodiment provides a message propagation method executed by the target consumer node, the method including the following steps S210 to S240, wherein:

[0103] Step S210: Receive the second message packet forwarded by the intermediate forwarding node.

[0104] The second message packet refers to a message packet generated and forwarded by an intermediate forwarding node according to the method executed by the intermediate forwarding node in the aforementioned embodiment. It includes business data, timestamp token, digital certificate chain, and signature chain. The target consumer node refers to a node Node_n that has not received a certain message content previously discovered according to the Gossip protocol and needs to consume the business data.

[0105] This step is executed when the message packet reaches the target consumer node after hop-by-hop propagation through intermediate forwarding nodes. Specifically, the target consumer node, according to the Gossip protocol's reception rules, determines whether it has previously received the message content after receiving the message notification. If it determines that it has not previously received the message and needs to consume it, it receives the second message packet forwarded by the intermediate forwarding node, caches it locally, and triggers the subsequent complete zero-trust verification process. The internal structure of the second message packet is: business data payload, timestamp token, and digital certificate chains Cert_0 to Cert_{n-1} and signature chains Sign_0 to Sign_{n-1} (taking the message packet passing through n preceding nodes as an example).

[0106] Then, a two-level verification is performed. The first level of verification is the certificate validity and policy chain check in step S220, and the second level of verification is the timestamp token verification and full-chain signature check in step S230.

[0107] Step S220: Verify the legality of the digital certificates of each node in the digital certificate chain in the second message packet, and verify the compliance of the transmission policy in each digital certificate.

[0108] The digital certificate chain includes source nodes and intermediate forwarding nodes along the propagation path; the legitimacy of the digital certificate indicates that the digital certificate is issued by a trusted certificate authority, has not been revoked, and is within its validity period; the compliance of the transmission policy indicates whether the actual behavior of the node corresponding to the digital certificate when propagating the business data meets the transmission policy declared in the extended field of its own digital certificate.

[0109] In one feasible approach, verifying the legitimacy of the digital certificates of each node in the second message packet includes: using the root certificate of a locally pre-configured root certificate authority (RCA), verifying whether the digital certificates of each node were issued by a trusted certificate authority and have not been revoked. Specifically, the target consumer node uses the root certificate Root_CA of the locally pre-configured root certificate authority to verify whether the digital certificates of each node were issued by a trusted certificate authority and have not been revoked, that is, using the root public key in Root_CA to verify the validity of the certificate signature one by one and query the revocation status.

[0110] In one feasible approach, verifying the compliance of the transmission policy in each digital certificate includes: starting from the source node, sequentially extracting the transmission policy of each digital certificate in the signature chain; for each digital certificate, verifying whether the node corresponding to the digital certificate meets the corresponding transmission policy when propagating business data, wherein the transmission policy includes at least one of the following: allowed data types for forwarding, maximum propagation hops, and allowed security domain range for communication.

[0111] Step S230: After verifying the legitimacy of the digital certificates and the compliance of the transmission policies in each digital certificate, verify the validity of the timestamp token and the correctness of each signature in the signature chain.

[0112] The validity of the timestamp token indicates that the token was indeed issued by a trusted timestamp server in accordance with the RFC3161 standard, its trusted time value is within the allowed time window, and the numerical hash in the token is consistent with the actual hash of the business data. The correctness of each signature in the signature chain indicates that the source signature in the signature chain is indeed the signature of the source node for the business data and the timestamp token as a whole, and each accumulated signature is indeed the signature of the corresponding node for the previously accumulated content.

[0113] In one feasible approach, verifying the validity of a timestamp token includes: using a locally pre-configured timestamp authority certificate to verify the legitimacy of the digital signature of the timestamp server in the timestamp token; extracting a trusted time value from the timestamp token and verifying whether the trusted time value is within an allowed time window; calculating the hash value of the business data and verifying the consistency between the calculated hash value and the digital hash of the business data in the timestamp token; if all verifications pass, the timestamp token is determined to be valid.

[0114] Specifically, the target consumer node performs three verifications: First, it uses the public key in the locally pre-installed timestamp authority certificate Cert_TSA to verify the legitimacy of the digital signature of the timestamp server in the timestamp token. This involves verifying the original signature of the token using the TSA public key to confirm that the token was indeed issued by a trusted TSA. Second, it extracts the trusted time value GenTime from the timestamp token and verifies whether it falls within the allowed time window. If the trusted time value is earlier than the lower limit of the time window, indicating the message is too old, it is considered a replay attack and the message packet is discarded. Third, it calculates the hash value of the business data payload in the second message packet and verifies the consistency between the calculated hash value and the digital hash of the business data in the timestamp token, confirming that the token is indeed anchored to the business data in the current message packet. If all three verifications pass, the timestamp token is deemed valid.

[0115] In one possible implementation, verifying the correctness of each signature in the signature chain includes: extracting the public key from the digital certificate of the source node in the second message packet, and verifying whether the signature of the source node is a complete signature of the business data and timestamp token by the public key; sequentially extracting the public key from the digital certificate of each intermediate forwarding node, and verifying whether each cumulative signature is a signature of the preceding cumulative message packet by the corresponding public key, wherein the preceding cumulative message packet includes business data, timestamp token, signature of the source node, and digital certificates and cumulative signatures of each preceding intermediate forwarding node.

[0116] Here, the public key represents the asymmetric verification key extracted from the digital certificate and corresponding to the private key of the signing node. The source node's signature (Sign_0) refers to the signature generated by the source node using its own private key to sign the entirety (Payload||TimestampToken) of the business data and the message packet. The preceding cumulative message packet represents all the preceding content already present in the message packet before each intermediate forwarding node's signature, including the business data, the timestamp token, the source node's signature, and the digital certificates and cumulative signatures of each preceding intermediate forwarding node.

[0117] Specifically, the target consumer node performs two-part verification: First, it extracts the public key PubKey_0 from the source node's digital certificate Cert_0 in the second message packet. Then, it verifies whether the source node's signature Sign_0 is signed by this public key for the entire business data and timestamp token (Payload||TimestampToken). This involves verifying Sign_0 with PubKey_0 and comparing the recovered original text with the concatenated content of the Payload||TimestampToken. Next, it sequentially extracts the public key P from the digital certificate Cert_i of each intermediate forwarding node. `ubKey_i` verifies whether each accumulated signature `Sign_i` is signed by the corresponding public key against the preceding accumulated message packet. The preceding accumulated message packet corresponding to the `i`th accumulated signature is `Payload||TimestampToken||Cert_0||Sign_0||……||Cert_{i-1}||Sign_{i-1}`, meaning it is verified hop-by-hop in the propagation order: after verifying `Sign_0`, it verifies sequentially from the first accumulated signature to the (n-1)th accumulated signature. Each accumulated signature is verified against all its preceding contents using the corresponding certificate public key. If any signature verification fails, the message is considered tampered with and is immediately discarded.

[0118] Step S240: After verifying that the timestamp token is valid and that all signatures in the signature chain are correct, obtain the business data of the second message packet.

[0119] Specifically, the fully verified business data payload is extracted from the message packet and delivered to the business processing module. The business processing module refers to the functional module running on the target consumer node that performs the actual consumption and processing of the business data.

[0120] Furthermore, the message packet is discarded after verifying that the digital certificate is invalid or that the transmission policy in each digital certificate is non-compliant; and the message packet is discarded if the timestamp token is invalid or if any signature in the signature chain is incorrect.

[0121] As can be seen, in this embodiment, after receiving the second message packet, the target consumer node performs two levels of verification: the first level verifies the legality of the certificates of each node in the digital certificate chain and the compliance of the transmission policies in each certificate; the second level verifies the validity of the timestamp token and the correctness of each signature in the signature chain; after both levels are passed, the business data obtained by the consumer node is not only complete in content and not tampered with, and fresh in time and not replayed, but also has been compliantly authorized at every hop in the propagation path, so that the data finally delivered has a complete and trustworthy chain and can be securely used for subsequent business processing.

[0122] Based on any of the above embodiments, this application provides a specific message transmission method. It introduces a progressive signature chain data structure with attached node certificates into the standard Gossip protocol communication framework, extends the node certificates to carry transmission policy attributes, and integrates an RFC3161 standard timestamp token at the source end to achieve trusted time anchoring. The entire verification system adopts an asymmetric design of extremely simple forwarding and deep verification at the consumer end. Forwarding nodes only perform lightweight policy checks and accumulate a single signature, thereby ensuring the original propagation efficiency of Gossip. Its basic technical flow is as follows:

[0123] 1. System initialization and policy enhancement: Certificate and timestamp service pre-configuration.

[0124] Within the zero-trust system, all legitimate nodes possess a digital certificate, Cert_Node, issued by an authoritative authority. Each node also has the same pre-installed root certificate, Root_CA, and a pre-installed timestamp server certificate, Cert_TSA, used to verify the signature validity of timestamp tokens and to verify the validity of other nodes' certificates.

[0125] Each node holds its own public and private key pair and uses this key pair to submit a signature request to the Root Certificate Authority (RootCA) to apply for a digital certificate.

[0126] In addition to regular identity information, each node's digital certificate also includes node transmission policies written through X.509 extended fields. These policies include: the types of data that can be forwarded (such as device health reports and threat intelligence only); the maximum number of propagation hops allowed; and the security domain / network segment range allowed for communication. This policy is bound when the certificate is issued and cannot be tampered with. Subsequent verification processes can forcibly restrict node behavior by reading the extended attributes.

[0127] 2. Message source processing: trusted timestamps and signatures.

[0128] The source node Node_0 generates the business data payload to be propagated. To provide standardized and verifiable time freshness guarantees, the source node performs the following steps:

[0129] Calculate H = Hash(Payload).

[0130] Send a timestamp request to the TSA, sending H to the TSA. The TSA returns a TimestampToken conforming to the RFC3161 standard. Its core data structure includes: the hash of the signed data (i.e., H); the trusted time value GenTime; and the TSA's digital signature.

[0131] The source node uses its own private key to sign the entire (Payload||TimestampToken) and generate Sign_0.

[0132] The initial message packet structure is: Payload, TimestampToken, Cert_0, Sign_0.

[0133] The timestamp of the source message is endorsed by a trusted third party, the TSA, rather than being generated by the source node itself. Its time value and signature conform to international standards and can be independently verified by any downstream node. In this embodiment, the system relies on a TimeStamping Authority (TSA) conforming to RFC 3161. As a trusted third party, the TSA provides a standard-format timestamp token (TimestampToken) for the source message. This token contains the hash of the requested data, a trusted time value, and a TSA signature, possessing legal validity and cryptographic non-repudiation.

[0134] 3. Intermediate node forwarding processing: policy check and signature accumulation.

[0135] When a message packet arrives at any intermediate forwarding node Node_i, only two lightweight operations are performed, without checking or processing the timestamp token, in order to maximize forwarding efficiency:

[0136] Step A: Quick check of certificate format and transmission policy:

[0137] Check whether the certificate Cert_{i-1} attached to the previous hop node is valid and whether the issuer is the root certificate.

[0138] Policy check: Read the transmission policy in the Cert_{i-1} extended attribute and determine: whether the data type of the current payload is within the allowed forwarding range; whether the current propagation hop count has exceeded the maximum value allowed by the certificate; whether the local machine and the previous hop node belong to the same security domain allowed by the policy, etc.

[0139] If the policy check fails, the message is immediately discarded and a security event is generated, achieving zero-trust least privilege control at the forwarding level. This process requires no asymmetric signature verification computation; it only needs to read the certificate field.

[0140] Step B, Signature Accumulation:

[0141] Node_i generates a new data block Block_i, which contains: Cert_i: Node_i's own digital certificate (including transport policy extensions); Sign_i: a global signature of all preceding content (i.e., Payload||TimestampToken||Cert_0||Sign_0||…||Cert_{i-1}||Sign_{i-1}) using Node_i's private key.

[0142] Step C, Message Forwarding: Append the newly generated Block_i to the end of the message packet and continue with Gossip random forwarding. The entire forwarding process adds only one signature operation, and this operation can be pipelined with message forwarding. The timestamp token is completely transparent to intermediate nodes, thus ensuring propagation performance that is almost indistinguishable from standard Gossip.

[0143] 4. Finally, a two-level verification mechanism is used for the nodes.

[0144] When the message finally arrives at the target node Node_n that needs to consume / process the data, the complete zero-trust verification process is triggered. This process centrally performs all heavyweight security operations, executing them in the order of certificate and policy first, then timestamp and signature: First-level verification (certificate validity and policy chain check): Starting from the source node i=0, Cert_i carried in the signature chain is extracted sequentially. Using the locally pre-configured Root_CA root certificate, each Cert_i is verified to be issued by a trusted CA and has not been revoked.

[0145] At the same time, the transmission policy extension attribute is extracted from each certificate, and the node is checked hop by hop to verify whether it meets the policy declared in its own certificate when propagating this message.

[0146] If any node's certificate verification fails or there is a policy conflict, it is determined that there is an unauthorized node or unauthorized forwarding in the propagation path, and the message is immediately discarded and an alarm is issued.

[0147] Second-level verification (RFC3161 timestamp token verification and end-to-end signature check):

[0148] Full verification of the timestamp token: Extract the TimestampToken, verify its legitimacy using the locally pre-set Cert_TSA, confirm that the GenTime is genuine and valid and within the allowed time window (to prevent replay), and verify that the hash value contained in the token is indeed a Hash (Payload). This step ensures that the message is stamped with a trusted timestamp at the source, possessing non-repudiation.

[0149] Signature chain verification: After all the above verifications pass, extract the public key PubKey_i corresponding to the certificate and decrypt and verify the signature Sign_i: verify whether Sign_0 is signed by PubKey_0 on (Payload||TimestampToken); verify whether Sign_i is signed by PubKey_i on the previous accumulated data block set.

[0150] If timestamp token verification fails or any signature mismatch occurs, the message is deemed to have been tampered with or forged during transmission and is immediately discarded. Only after all verifications are successful is the payload trusted and delivered to the business processing module.

[0151] This application's embodiments delay and concentrate computationally intensive verification (root certificate verification, full-chain signature verification) on the data consumer end, freeing the vast majority of forwarding nodes in the network from heavy-load encryption computations and preserving the Gossip protocol's O(logN) level rapid propagation characteristics. By introducing the RFC3161 standard timestamp service, the freshness of the source message is endorsed by a trusted third party (TSA), and the timestamp token is fully carried to the consumer end for verification, fundamentally eliminating the possibility of the source node forging time or replaying old messages. Certificate extended attributes are written into the node transmission policy, enabling forwarding nodes to enforce forwarding control based on certificates without deep packet inspection, and allowing for full-chain policy compliance to be traced back at the consumer end, strictly adhering to the zero-trust least privilege principle. The final message carries a complete and ordered certificate-signature-policy chain and an RFC3161 timestamp token, which not only reconstructs the propagation path and shows the policy role undertaken by each node, but the timestamp token itself can also serve as legal evidence conforming to international standards, providing solid evidence for security audits and incident tracing.

[0152] To more clearly illustrate the technical solutions of the embodiments of this application, the following uses a specific end-to-end scenario as an example to fully describe the processes of the above embodiments. In this embodiment, the example is taken as a zero-trust network where source node Node_0 generates threat intelligence data, propagates it through two intermediate forwarding nodes Node_1 and Node_2, and is finally consumed by the target consumer node Node_3.

[0153] During the system initialization phase, all legitimate nodes have a pre-configured root certificate Root_CA and a timestamp server certificate Cert_TSA, and each node holds a digital certificate issued by rootca with its own transmission policy written in the extended field.

[0154] Source phase: Source node Node_0 generates the threat intelligence payload to be propagated; calculates H = Hash(Payload); sends a timestamp request to the timestamp server TSA and sends H to TSA; TSA returns a timestamp token conforming to RFC3161, which contains the signed data hash H, the trusted time value GenTime, and TSA's digital signature; Node_0 signs the entire (Payload||TimestampToken) pair using its own private key to generate Sign_0; constructs an initial message packet with the structure Payload, TimestampToken, Cert_0, and Sign_0; and sends the initial message packet based on the Gossip protocol.

[0155] First-hop forwarding: Intermediate forwarding node Node_1 receives the initial message packet and checks whether the certificate Cert_0 attached to the previous hop node (i.e., the source node) is valid and whether the issuer is the root certificate authority. It reads the transmission policy from the extended attributes of Cert_0 to determine if the data type of the threat intelligence is within the allowed forwarding range, whether the current propagation hop count (currently 1) exceeds the maximum value, and whether the local machine and Node_0 belong to the same security domain allowed by the policy. After passing these three policy checks, Node_1 uses the preceding content Payload||TimestampToken||Cert_0||Sign_0 as the content to be signed, signs it with its own private key to obtain Sign_1, appends the data block (Cert_1, Sign_1) to the end of the message packet, and continues to execute Gossip random forwarding. During this process, Node_1 does not check or process the timestamp token at all; it only performs one certificate field read and one private key signing operation.

[0156] Second-hop forwarding: The intermediate forwarding node Node_2 receives the data according to the same process, checks the certificate Cert_1 and the transmission policy, signs the entire preceding content Payload||TimestampToken||Cert_0||Sign_0||Cert_1||Sign_1 to obtain Sign_2, appends the data block (Cert_2, Sign_2) and forwards it.

[0157] Consumer Verification: The target consumer node Node_3, based on the Gossip protocol, discovers that the message content has not been received before and needs to be consumed, thus triggering a complete verification process. First-level verification: Starting from the source node, Cert_0, Cert_1, and Cert_2 are extracted sequentially. The locally pre-configured Root_CA is used to verify whether each certificate was issued by a trusted certificate authority and has not been revoked. Simultaneously, each node is checked hop-by-hop to ensure that it meets the transmission policy declared in its own certificate statement when propagating this message. After all verifications are successful, the second-level verification begins: The locally pre-configured Cert_TSA is used to verify the TSA signature of the timestamp token, confirming that GenTime is within the allowed time window and verifying that the hash value in the token is indeed Hash(Payload). Then, the public key PubKey_0 is extracted to verify the signing of Sign_0 (Payload||TimestampToken), and then PubKey_1 and PubKey_2 are used to verify the signing of Sign_1 and Sign_2 for their respective preceding accumulated content. After all verifications are successful, the threat intelligence payload is trusted and delivered to the business processing module; at the same time, the complete certificate-signature-policy chain and timestamp token are archived as auditable evidence in compliance with international standards.

[0158] This end-to-end implementation shows that: along the entire propagation path, intermediate nodes Node_1 and Node_2 each perform only one lightweight policy check and one signature operation, without any asymmetric signature verification overhead, and the propagation performance is almost no different from the standard Gossip protocol; while all heavyweight verification is concentrated in the single target consumer node Node_3, realizing an asymmetric design of extremely simple forwarding and deep verification at the consumer end.

[0159] Figure 4 A structural diagram of an electronic device provided in an embodiment of the present invention, such as... Figure 4 As shown, the electronic device includes: a memory 60 for storing a computer program; and a processor 61 for executing the computer program to implement the steps of the method as described in the above embodiments.

[0160] The processor 61 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 61 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor, also known as the Central Processing Unit (CPU), is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 61 may integrate a Graphics Processing Unit (GPU), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 61 may also include an Artificial Intelligence (AI) processor, which handles computational operations related to machine learning.

[0161] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory devices. In this embodiment, the memory 60 is used to store at least the following computer program 601, which, after being loaded and executed by the processor 61, is capable of implementing the relevant steps of the method disclosed in any of the foregoing embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. The operating system 602 may include Windows, Unix, Linux, etc.

[0162] In some embodiments, the electronic device may further include a display screen 62, an input / output interface 63, a communication interface 64, a power supply 65, and a communication bus 66.

[0163] Those skilled in the art will understand that Figure 4 The structures shown do not constitute a limitation on electronic devices and may include more or fewer components than those shown.

[0164] It is understood that if the methods in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods in the various embodiments of the present invention. The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, magnetic disks, or optical disks, and other media capable of storing program code.

[0165] Based on this, embodiments of the present invention also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method described above.

[0166] Based on this, embodiments of the present invention also provide a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the above-described method. It should be understood that although the steps in the flowcharts of the accompanying drawings are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying drawings may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least a portion of the sub-steps or stages of other steps.

[0167] The above are only some embodiments of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A message propagation method, characterized in that, The message propagation method is executed by intermediate forwarding nodes and includes: The system receives a first message packet, which includes business data, a timestamp token, a digital certificate chain, and a signature chain. The business data is generated by the source node. The timestamp token is obtained by the source node from a timestamp server and includes a digital hash of the business data, a trusted time value, and a digital signature from the timestamp server. The digital certificate chain includes the digital certificates of all nodes preceding the intermediate forwarding node, and these digital certificates are issued by the root certificate authority. The signature chain includes the signatures of all nodes preceding the intermediate forwarding node. Sign all contents of the first message packet to generate an accumulated signature corresponding to the intermediate forwarding node; The accumulated signature and the digital certificate corresponding to the intermediate forwarding node are appended to the first message packet to generate the second message packet; The second message packet is forwarded based on the Gossip protocol. The intermediate forwarding node does not perform signature verification during the forwarding process; the signature verification operation is performed by the target consumer node.

2. The method according to claim 1, characterized in that, The extended fields of the digital certificate contain the transmission policy. After receiving the first message packet, it also includes: Check the validity of the digital certificate of the previous node in the first message packet; If the digital certificate of the previous node is valid, then read the transmission policy from the extended field of the digital certificate of the previous node; According to the transmission policy of the previous node, perform a policy check on the first message packet; If the policy check passes, then the step of signing all the contents of the first message packet and generating the cumulative signature corresponding to the intermediate forwarding node is executed. If the policy check fails, the first message packet is discarded and a security event is generated.

3. The method according to claim 2, characterized in that, According to the transmission policy of the previous node, a policy check is performed on the first message packet, including: Check whether the data type of the service data is within the range of data types allowed to be forwarded by the transmission policy of the previous node; Check whether the current propagation hop count exceeds the maximum propagation hop count allowed by the transmission strategy of the previous node; Check whether the intermediate forwarding node and the previous hop node belong to the same security domain allowed by the transmission policy of the previous node.

4. A message propagation method, characterized in that, The message propagation method is executed by the target consumer node and includes: Receive a second message packet forwarded by an intermediate forwarding node. The second message packet includes business data, a timestamp token, a digital certificate chain, and a signature chain. The second message packet is generated based on any one of the message propagation methods of claims 1 to 3. Verify the legality of the digital certificates of each node in the digital certificate chain in the second message packet, and verify the compliance of the transmission policy in each digital certificate; After verifying the legitimacy of the digital certificates and the compliance of the transmission policies in each digital certificate, verify the validity of the timestamp tokens and the correctness of each signature in the signature chain. If the timestamp token is valid and all signatures in the signature chain are correct, the business data of the second message packet is obtained.

5. The method according to claim 4, characterized in that, The method further includes: discarding the message packet after verifying that the digital certificate is invalid, or that the transmission policy in each digital certificate is non-compliant; and discarding the message packet if the timestamp token is invalid, or if any signature in the signature chain is incorrect. And / or, verify the legality of the digital certificates of each node in the second message packet, including: using the root certificate of the locally pre-configured root certificate authority, verifying whether the digital certificate of each node was issued by a trusted certificate authority and has not been revoked; And / or, verify the compliance of the transmission policy in each digital certificate, including: starting from the source node, sequentially extracting the transmission policy of each digital certificate in the signature chain; for each digital certificate, verifying whether the node corresponding to the digital certificate meets the corresponding transmission policy when propagating the business data, wherein the transmission policy includes at least one of the following: allowed data types for forwarding, maximum propagation hops, and allowed security domain range for communication.

6. The method according to claim 4, characterized in that, Verify the validity of the timestamp token, including: The validity of the digital signature of the timestamp server in the timestamp token is verified using a locally pre-installed timestamp authority certificate. Extract the trusted time value from the timestamp token and verify whether the trusted time value is within the allowed time window; Calculate the hash value of the business data, and verify the consistency between the calculated hash value and the digital hash of the business data in the timestamp token; If all verifications pass, the timestamp token is deemed valid.

7. The method according to claim 4, characterized in that, Verifying the correctness of each signature in the signature chain includes: Extract the public key from the digital certificate of the source node in the second message packet, and verify whether the signature of the source node is a complete signature of the business data and timestamp token by the public key; The public key in the digital certificate of each intermediate forwarding node is extracted sequentially, and each accumulated signature is verified to be signed by the corresponding public key on the preceding accumulated message packet. The preceding accumulated message packet includes the business data, the timestamp token, the signature of the source node, and the digital certificates and accumulated signatures of each preceding intermediate forwarding node.

8. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the method according to any one of claims 1 to 3, or the method according to any one of claims 4 to 7, when running the computer program.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one piece of program code, which is loaded and executed by a processor to implement the method as described in any one of claims 1 to 3, or the method as described in any one of claims 4 to 7.

10. A message transmission system, characterized in that, include: Source node, at least one intermediate forwarding node, and target consumer node; The source node generates business data and sends a request to the timestamp server based on the business data to obtain a timestamp token that includes the digital hash of the business data, a trusted time value, and the digital signature of the timestamp server. It then signs the business data and the timestamp token to obtain the signature corresponding to the source node. An initial message packet is generated, which includes the business data, the timestamp token, the source node's digital certificate, and the source node's signature. Finally, the message packet is forwarded to intermediate forwarding nodes based on the Gossip protocol. The intermediate forwarding node is used to implement the method as described in any one of claims 1 to 3; the target consumer node is used to implement the method as described in any one of claims 4 to 7.

Images