A data cipher distribution system for heterogeneous network cross-domain communication

Abstract

This invention relates to the field of network communication and information security technology, specifically to a data ciphertext distribution system for cross-domain communication in heterogeneous networks. The system includes: a state awareness module for acquiring real-time trust state data of cross-domain nodes, underlying communication protocol information, ciphertext to be distributed, initial access control policy, and target cross-domain nodes; a context mapping module for detecting protocol differences and calculating the inter-domain context mapping fidelity; a policy evolution module for dynamically evolving and proxy re-encryption based on real-time trust state data and protocol differences, generating updated access control policies and reconstructing ciphertext; a topology routing module for establishing ciphertext distribution paths; an adaptive feedback module for adjusting the policy evolution frequency based on the overhead ratio and adjusting the path based on the evolution delay; and a data distribution execution module for sending the reconstructed ciphertext. This invention can maintain the continuity and end-to-end confidentiality of ciphertext relay distribution across domains.

Description

Technical Field

[0001] This invention relates to the field of network communication and information security technology, specifically to a data encrypted distribution system for cross-domain communication in heterogeneous networks. Background Technology

[0002] With the rapid growth in demand for medical collaboration, emergency response, and industry private network interconnection, there are more and more cross-domain data communication scenarios between heterogeneous networks. Since different communication domains often use different identity authentication standards, underlying communication protocols, and node trust assessment mechanisms, how to achieve continuous distribution and security control of encrypted data during cross-domain transmission has become an urgent problem to be solved in the field of network security and data circulation.

[0003] Traditional cross-domain data transmission schemes currently rely primarily on the following methods: using fixed access control policies for encrypted forwarding, relying on static trust assessment to select relay nodes, and completing protocol conversion through preset gateways. However, fixed access control policies, static trust assessment, and preset gateway protocol conversion all have certain drawbacks. For example, fixed access control policies are difficult to adapt to real-time changes in the trusted state of cross-domain nodes and task context, which can easily lead to blocked legitimate access or distorted permission boundaries. Static trust assessment has insufficient response to short-term node fluctuations, local attacks, and link switching, making it difficult to guarantee the continuity of the cross-domain distribution process. Although preset gateway protocol conversion can achieve basic interoperability, it is not adaptable to differences in attribute semantics, access policy mapping deviations, and dynamic reconstruction of cross-domain routes, which can easily cause interruptions in encrypted distribution, lag in policy evolution, and a decrease in overall transmission efficiency. Summary of the Invention

[0004] The purpose of this invention is to provide a data ciphertext distribution system for cross-domain communication in heterogeneous networks, to solve the problems in existing technologies where fixed access control policies, static trust assessments, and preset gateways are difficult to adapt to real-time changes in the trusted state and semantic differences of cross-domain nodes, thus easily causing ciphertext distribution interruptions, policy evolution delays, and overall transmission efficiency degradation. To achieve the above objective, this invention proposes the following technical solution:

[0005] A data ciphertext distribution system for cross-domain communication in heterogeneous networks is applied to a network containing at least two heterogeneous communication domains, the network including multiple cross-domain nodes, including:

[0006] The state awareness module is used to obtain the state information of cross-domain nodes, as well as the ciphertext to be distributed, the initial access control policy of the ciphertext to be distributed, and the target cross-domain node; the state information includes real-time trust state data and underlying communication protocol information.

[0007] The context mapping module is used to detect protocol differences between cross-domain nodes based on the underlying communication protocol information and to calculate the inter-domain context mapping fidelity.

[0008] The policy evolution module is used to dynamically evolve and re-encrypt the initial access control policy based on real-time trust state data and protocol differences, generating updated access control policies and reconstructing ciphertext; the dynamic evolution and re-encryption conversion include re-encryption key generation and attribute tree reconstruction.

[0009] The topology routing module is used to calculate the trust topology distribution cost index based on the reconstructed ciphertext and the fidelity of the inter-domain context mapping, and to establish a ciphertext distribution path to the target cross-domain node based on the trust topology distribution cost index.

[0010] An adaptive feedback module is used to calculate the cross-domain policy evolution delay and dynamic evolution computation overhead ratio, and adjust the policy evolution frequency of the policy evolution module and the ciphertext distribution path accordingly.

[0011] The data distribution execution module is used to send the reconstructed ciphertext to the target cross-domain node along the ciphertext distribution path established by the topology routing module or adjusted by the adaptive feedback module.

[0012] Optionally, the adaptive feedback module obtains the total packet forwarding lifecycle time, the central processing unit processing time, and the time required to generate updated access control policies, and calculates the cross-domain policy evolution delay and dynamic evolution computation overhead ratio accordingly; configured as follows:

[0013] If the dynamic evolution calculation overhead ratio is greater than or equal to the preset overhead ratio threshold, the strategy evolution frequency of the strategy evolution module is reduced. The reduction in frequency is matched with the corresponding frequency adjustment step size based on the difference between the dynamic evolution calculation overhead ratio and the preset overhead ratio threshold, and the current strategy evolution frequency is reduced in a step-by-step manner according to the frequency adjustment step size.

[0014] If the cross-domain policy evolution delay caused by a cross-domain node in the encrypted distribution path exceeds a preset delay threshold, the cross-domain node will be removed from the encrypted distribution path and the topology routing module will be triggered to adjust the path.

[0015] Optionally, the initial access control policy includes an initial attribute access tree; the context mapping module is also used to: obtain the authentication criteria and attribute definitions of cross-domain nodes; extract the corresponding original attribute set from the initial attribute access tree; and perform attribute mapping on the initial attribute access tree based on the authentication criteria and attribute definitions to generate a mapped attribute set.

[0016] Optionally, the context mapping module calculates the inter-domain context mapping fidelity, including: calculating the semantic similarity between the mapped attribute set and the original attribute set; and using the semantic similarity as the inter-domain context mapping fidelity.

[0017] Optionally, the policy evolution module generates updated access control policies and reconstructed ciphertext, including: calculating the rate of change of real-time trust state data within a preset time window as a dynamic fluctuation value; constructing a corresponding protocol feature vector based on the inconsistency of fields in the underlying communication protocol in the protocol differences, and generating a re-encryption key based on the dynamic fluctuation value and the protocol feature vector; and using the re-encryption key to perform proxy re-encryption transformation on the ciphertext to be distributed to generate reconstructed ciphertext.

[0018] Optionally, the initial attribute access tree contains multiple attribute nodes; the policy evolution module generates updated access control policies and reconstructed ciphertext, and is further configured to: if the dynamic fluctuation value is greater than a preset fluctuation threshold, delete the attribute node in the initial attribute access tree corresponding to the cross-domain node that generates the dynamic fluctuation value; if the dynamic fluctuation value is less than or equal to the preset fluctuation threshold, extract preset restrictive conditions as supplementary attribute nodes, and add supplementary attribute nodes to the initial attribute access tree; complete the attribute tree reconstruction through the addition and deletion operations of attribute nodes, and generate updated access control policies.

[0019] Optionally, the topology routing module calculates the trust topology distribution cost index and establishes the ciphertext distribution path, including: using the product of the inter-domain context mapping fidelity and the data length of the reconstructed ciphertext as the trust topology distribution cost index; identifying nodes among cross-domain nodes whose real-time trust status data is greater than or equal to a preset trust threshold as remaining trusted nodes; calculating an adaptive routing path based on the remaining trusted nodes and the trust topology distribution cost index; and outputting the adaptive routing path as the ciphertext distribution path.

[0020] Optionally, the cross-domain policy evolution delay is the time elapsed from the moment a protocol difference or real-time trust state data change is detected until the moment the updated access control policy is generated; the dynamic evolution computational overhead ratio is the percentage of CPU processing time consumed by the cross-domain node in performing dynamic evolution and proxy re-encryption transformation and establishing ciphertext distribution paths relative to the total lifecycle time of packet forwarding.

[0021] Compared with the prior art, the present invention has the following beneficial effects:

[0022] 1. This system extracts the original attribute set corresponding to the ciphertext to be distributed, as well as the identity authentication standards and attribute definitions of cross-domain nodes, through the context mapping module. It performs attribute mapping on the initial attribute access tree and calculates the semantic similarity between the mapped attribute set and the original attribute set as the inter-domain context mapping fidelity. This mechanism effectively overcomes the problem of insufficient adaptability of traditional preset gateways to attribute semantic differences. By quantifying the degree of matching between the access control permissions after proxy re-encryption and the original security intent, it avoids the situation of permission expansion or semantic deviation after cross-domain translation, and ensures the accuracy of security policy migration between heterogeneous domains.

[0023] 2. This system uses a policy evolution module to calculate the rate of change of real-time trust state data within a preset time window as a dynamic fluctuation value, and combines this with the protocol feature vector corresponding to the protocol differences to generate a re-encryption key. Simultaneously, based on the comparison between the dynamic fluctuation value and the preset fluctuation threshold, the system performs attribute node addition and deletion operations on the initial attribute access tree to complete the attribute tree reconstruction. This mechanism solves the problems of insufficient response of static trust assessment to short-term node fluctuations and the difficulty of fixed policies adapting to changes in trusted state, enabling the ciphertext protection strength and authorization logic to adjust the permission level in real time with the network environment, thereby maintaining the end-to-end confidentiality of ciphertext distribution across domains.

[0024] 3. This system creatively derives a trust topology distribution cost index by multiplying the inter-domain context mapping fidelity with the data length of the reconstructed ciphertext through the topology routing module. Based on the remaining trusted nodes and this trust topology distribution cost index, it calculates an adaptive routing path. This overcomes the shortcomings of relying solely on real-time trust state data of nodes to select relay nodes. It incorporates the degree of security intent preservation and the actual ciphertext carrying system overhead into the routing evaluation, effectively preventing the risk of node processing overload or congestion caused by ciphertexts with data lengths exceeding the preset fragmentation threshold under high fidelity requirements. This achieves path optimization that is more in line with the actual transmission characteristics of cross-domain ciphertexts.

[0025] 4. This system introduces an adaptive feedback module, which calculates the proportion of CPU processing time consumed by cross-domain nodes to obtain the dynamic evolution computational overhead ratio, and dynamically reduces the policy evolution frequency when the limit is exceeded. At the same time, it calculates the cross-domain policy evolution delay, actively removes cross-domain nodes that cause delays exceeding the preset threshold from the ciphertext distribution path and re-triggers the topology routing module. This mechanism directly addresses the shortcomings of traditional schemes that are prone to distribution interruption and policy evolution lag. It avoids the exhaustion of computing resources due to frequent node evolution and achieves path avoidance for high-latency nodes, ensuring the continuous availability of ciphertext cross-domain distribution in case of emergencies. Attached Figure Description

[0026] The present invention will be further explained below with reference to the accompanying drawings and embodiments:

[0027] Figure 1 This is a structural diagram of the system of the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments.

[0029] like Figure 1 As shown, a data encrypted distribution system for cross-domain communication in heterogeneous networks is applied in a network containing at least two heterogeneous communication domains. The network includes multiple cross-domain nodes, including:

[0030] The state awareness module is used to obtain the state information of cross-domain nodes, as well as the ciphertext to be distributed, the initial access control policy of the ciphertext to be distributed, and the target cross-domain node; the state information includes real-time trust state data and underlying communication protocol information.

[0031] The context mapping module is used to detect protocol differences between cross-domain nodes based on the underlying communication protocol information and to calculate the inter-domain context mapping fidelity.

[0032] The policy evolution module is used to dynamically evolve and re-encrypt the initial access control policy based on real-time trust state data and protocol differences, generating updated access control policies and reconstructing ciphertext; the dynamic evolution and re-encryption conversion include re-encryption key generation and attribute tree reconstruction.

[0033] The topology routing module is used to calculate the trust topology distribution cost index based on the reconstructed ciphertext and the fidelity of the inter-domain context mapping, and to establish a ciphertext distribution path to the target cross-domain node based on the trust topology distribution cost index.

[0034] The adaptive feedback module is used to obtain the total lifecycle time of packet forwarding, the central processing unit processing time, and the time required to generate updated access control policies, and calculate the cross-domain policy evolution delay and dynamic evolution computation overhead ratio accordingly. It is configured as follows: if the dynamic evolution computation overhead ratio is greater than or equal to a preset overhead ratio threshold, the policy evolution frequency of the policy evolution module is reduced. The reduction in frequency is matched with the corresponding frequency adjustment step size based on the difference between the dynamic evolution computation overhead ratio and the preset overhead ratio threshold, and the current policy evolution frequency is adjusted in a step-wise manner according to the frequency adjustment step size. If the cross-domain policy evolution delay caused by a cross-domain node in the ciphertext distribution path is greater than a preset delay threshold, the cross-domain node is removed from the ciphertext distribution path and the topology routing module is triggered to adjust the path.

[0035] The data distribution execution module is used to send the reconstructed ciphertext to the target cross-domain node along the ciphertext distribution path established by the topology routing module or adjusted by the adaptive feedback module.

[0036] This embodiment provides a data encryption distribution mechanism for cross-domain communication in heterogeneous networks. Specifically, the following description uses a regional chest pain emergency collaborative network as the main scenario: the ambulance monitoring terminal belongs to the pre-hospital emergency domain, the county hospital gateway belongs to the regional private network domain, and the municipal chest pain center server belongs to the medical cloud domain. The three use different identity standards, different transmission protocols, and different node trust assessment rules. The system needs to continuously distribute the electrocardiogram, troponin results, and transport records of a suspected acute myocardial infarction patient from the ambulance terminal to the municipal chest pain center in encryption mode, while ensuring that the distribution is not interrupted due to protocol inconsistencies or sudden changes in trust level at intermediate cross-domain nodes.

[0037] The state awareness module first acquires the ciphertext to be distributed, the initial access control policy, the target cross-domain node, and the state information of each cross-domain node. This state information includes at least two types: one is real-time trust state data, such as 0.82 for the vehicle gateway, 0.76 for the county hospital boundary proxy, and 0.93 for the city-level center entry node; the other is underlying communication protocol information, such as the use of a lightweight messaging protocol in ambulances, a business encapsulation protocol based on the hospital information system within county hospitals, and a medical data exchange protocol in the city-level center. The ciphertext to be distributed can be recorded as a ciphertext packet. The initial access control policy can be understood as an access tree, such as an emergency room doctor with a chest pain center on-call status or an interventional surgery authorized doctor with a matching current task identifier; the target cross-domain node is the municipal chest pain center receiving server;

[0038] The context mapping module detects protocol differences between adjacent domains. Specifically, the system has a built-in protocol feature mapping table. By extracting the field structure from the underlying communication protocol information during the handshake phase of adjacent cross-domain nodes, the system compares it with the protocol feature mapping table. If the data format or validation rules of the corresponding field are found to be inconsistent, the difference feature of that item is set to 1; otherwise, it is set to 0.

[0039] For ease of explanation, assume there are two types of differences between the ambulance domain and the county hospital domain: different authentication token field lengths and different attribute name semantics; and one type of difference between the county hospital domain and the municipal center domain: different patient task identifier encoding rules. The system can first represent the protocol differences as a simplified feature set, for example, the first hop difference is {authentication format difference = 1, attribute naming difference = 1, timestamp rule difference = 0}, and the second hop difference is {authentication format difference = 0, attribute naming difference = 0, timestamp rule difference = 1}.

[0040] Based on this, the inter-domain context mapping fidelity is calculated. The higher the fidelity, the closer the access control semantics are to the original security intent after crossing domains. The context mapping module outputs the protocol differences and the inter-domain context mapping fidelity to the policy evolution module. The policy evolution module then transmits the reconstructed ciphertext and the inter-domain context mapping fidelity to the topology routing module. Based on real-time trust state data and protocol differences, the policy evolution module dynamically evolves the initial access control policy and completes the proxy re-encryption conversion.

[0041] The specific calculation method is as follows: If the trust value of the county hospital's boundary agent node drops from 0.84 to 0.76 within the last 10-second window, the rate of change is -0.08 / 10 seconds; combined with the protocol difference characteristics of this hop, the corresponding re-encryption key is generated. This key does not directly expose the plaintext, nor does it require intermediate nodes to have the final decryption capability; rather, it only allows them to... Convert to ciphertext adapted to the next-domain policy If the next hop detects a second type of protocol difference, then generate... ,Will Convert to ;

[0042] At the same time, the initial access tree will be reconstructed based on the current trust fluctuations. For example, if the original policy requires the identity of a county hospital consultation relay, when the trust of that node decreases, the relay identity can be removed from the necessary conditions, and instead, the identity of a city-level chest pain center duty officer and the validity of the current emergency mission token can be required. This generates the updated access control policy P1 and the reconstructed ciphertext. Then, the topology routing module calculates the trusted topology distribution cost index based on the reconstructed ciphertext and fidelity, and establishes the ciphertext distribution path.

[0043] For ease of understanding, let's assume With a length of 100 units and a mapping fidelity of 0.88, a trust topology distribution cost index of 88 can be obtained for route evaluation. The system filters nodes with trust values ​​greater than or equal to a preset threshold of 0.75 from all cross-domain nodes, retaining the ambulance gateway (0.82), county hospital agent (0.76), and city-level entry point (0.93), while removing a backup edge node (0.61). Based on the remaining trusted nodes and the trust topology distribution cost index, the system calculates a preferred path: ambulance gateway → county hospital boundary agent → city-level center entry point. If the second alternative path has a high fidelity but requires passing through multiple low-trust nodes, it is not prioritized. The adaptive feedback module continuously calculates the cross-domain policy evolution delay and the dynamic evolution computation overhead ratio.

[0044] In the example, a policy evolution takes 120 milliseconds from detecting a decrease in trust at the county hospital node to generating a new policy and ciphertext. This value can be used as the delay for this round of cross-domain policy evolution. In the same round, the CPU processing time for trust assessment, policy reconstruction, re-encryption, and routing calculation is 40 milliseconds, while the total lifecycle of the data packet from entry to forwarding completion is 200 milliseconds. Therefore, the dynamic evolution computation overhead ratio is 20%. If the preset overhead ratio threshold is 25%, the current policy evolution frequency is maintained.

[0045] If the overhead ratio rises to 31% in the next round due to network congestion, the policy evolution frequency will be reduced, for example, from once every 5 seconds to once every 15 seconds. The specific step-down rule is as follows: multiple consecutive overhead difference intervals and corresponding frequency adjustment step sizes are pre-configured. The actual difference value that exceeds the preset overhead ratio threshold is compared with each difference interval. Based on the difference interval that the actual difference value falls into, the corresponding frequency adjustment step size is called to reduce the current policy evolution frequency. At the same time, if the cross-domain policy evolution delay increases significantly, the system can trigger path adjustment to avoid passing through intermediate nodes that cause policy processing delays.

[0046] The data distribution execution module sends the reconstructed ciphertext to the target node according to the current valid path. Specifically, each hop proxy node can only perform forwarding and proxy conversion actions. Finally, the target node of the municipal chest pain center completes the legal decryption according to the updated access control policy to obtain the electrocardiogram and test results, which are used to prepare catheterization lab resources in advance. As an anomaly handling mechanism, if the state awareness module fails to obtain the latest trust value of a node, it will temporarily mark the node as an uncertain node and treat it as below the trust threshold, and it will not enter the main path. If the protocol difference detection fails, a conservative mapping strategy will be adopted first, that is, the security constraint level of the original access control will not be reduced, only the security constraint level will be increased, and the permissions will not be expanded. If a proxy re-encryption fails, the previous valid ciphertext version will be retained and the system will switch to the backup path. If all optional paths do not meet the trust threshold, the system will only cache the ciphertext and wait for the next sampling cycle, and will not perform high-risk cross-domain transmission.

[0047] During the transport of a chest pain patient to the county hospital in an ambulance, the onboard monitor continuously generated electrocardiogram data. Due to the switch of the onboard link from the public network to the regional private network, the protocol context changed, and the trust value of the county hospital's boundary node fluctuated during a short-term attack detection. Instead of stopping data distribution, the system reconstructed the access tree in real time, updated the proxy re-encryption key, and switched the ciphertext from the original path to a more trusted backup county gateway before forwarding it to the municipal chest pain center. This allowed the center's doctors to view the core indicators within the legally authorized scope before the patient arrived at the hospital.

[0048] The purpose of this step is to integrate the evolution of heterogeneous access control protocol for node trust change and the reconstruction of distribution routes into the same closed loop, so as to maintain the continuity and end-to-end confidentiality of encrypted cross-domain relay distribution without relying on a unified global trust center.

[0049] In this embodiment, the initial access control policy includes an initial attribute access tree; the context mapping module is further used to: obtain the authentication standards and attribute definitions of cross-domain nodes; extract the corresponding original attribute set from the initial attribute access tree; and perform attribute mapping on the initial attribute access tree based on the authentication standards and attribute definitions to generate a mapped attribute set.

[0050] This embodiment provides a cross-domain attribute mapping mechanism oriented towards attribute access trees. Specifically, in the aforementioned chest pain emergency collaborative network, simply detecting different protocols is not enough. This is because different medical domains have significant differences in the naming methods for the same role. For example, the ambulance domain uses the pre-hospital doctor task force transfer shift as the identity attribute, while the municipal chest pain center uses the receiving physician consultation group green channel task number. Without the introduction of attribute mapping, even if the ciphertext can complete cross-domain forwarding, the problem will eventually arise that the policy rules exist but lack an effective semantic execution basis.

[0051] The system first extracts the original attribute set from the initial access control policy corresponding to the ciphertext to be distributed; assuming the initial attribute access tree contains three attribute nodes: Indicates pre-hospital doctors, The task number for chest pain is calculated as task number - 38. This indicates that the shift period equals the night shift; simultaneously, it extracts identifiable attribute definitions from the authentication standards of the target cross-domain nodes and relay nodes; for example, the municipal-level center authentication system uses... Indicates the attending physician. This indicates that the emergency medical assistance task code = medical assistance number - 38. This indicates that the emergency room duty window is for nighttime use.

[0052] At this point, the context mapping module does not directly reuse attribute names, but instead establishes attribute mapping relationships; for clarity, a simplified mapping table can be used for analysis; the original attribute set is { , , }, the candidate target domain attribute set is { , , , },in This indicates the person in charge of the interventional room; the system performs a step-by-step comparison based on identity authentication standards and attribute definitions: and Their roles and responsibilities are similar and can be mapped; and Although the task identifier fields have different encoding formats, they can be mapped using task number conversion rules. and The duty shifts have the same semantics and can be mapped; and Although both are medical roles, they have higher authority and different responsibilities, so they are not directly mapped.

[0053] This generates a mapping attribute set { , , }, and the initial attribute access tree from and and Convert to and and The corresponding target domain representation; in actual processing, one-to-many or many-to-one mappings are also allowed; for example, if the original domain has only one attribute. =Emergency authorization, and the target domain requires both the attending physician's identity and the chest pain center's on-duty status, then Combined properties that can be mapped to the target side and Conversely, if the original domain distinguishes between pre-hospital doctors and on-call nurses, while the target domain only recognizes members of the resuscitation team, then and Can be merged and mapped as The above mapping combination mechanism does not relax access control, but rather maintains the continuity of security semantics before and after cross-domain operations.

[0054] As an exception handling mechanism, if no acceptable mapping can be found for a certain original attribute, the system will not delete the attribute and continue to allow it to pass. Instead, it will mark it as an untranslatable attribute and add a manual approval attribute or a high-level task token attribute to the update strategy to avoid the expansion of permissions due to missing attributes. If multiple candidate mappings exist at the same time and have the same priority, the mapping result with stronger restrictions can be selected. For example, when both the attending physician and the consulting expert can be matched, the one with narrower permissions and a smaller decryption scope will be given priority. If the identity authentication standard is not fully extracted, the system will keep the original attribute tree unchanged and only allow forwarding within the same security domain, without cross-domain diffusion.

[0055] During the process of transferring a patient from a county hospital to a municipal chest pain center, the county hospital's policy specifies that the pre-hospital doctor is qualified, the task number matches, and the night shift staff can view the ECG summary. The municipal center does not recognize the literal attribute of "pre-hospital doctor," but it does recognize the attending physician. After the system completes the mapping of pre-hospital doctor → attending physician, task number-38 → medical collaboration number-38, and night shift → night shift window, the target node can correctly determine the authorization conditions within the local authentication system, rather than the legitimate doctor being unable to receive the encrypted message due to the difference in attribute names.

[0056] The purpose of this step is to elevate the access control policy from literal consistency to semantically translatable, thereby enabling the migration of attribute access trees between heterogeneous domains and providing a computable input basis for subsequent fidelity calculations and proxy re-encryption.

[0057] In this embodiment, the context mapping module calculates the inter-domain context mapping fidelity, including:

[0058] Calculate the semantic similarity between the mapped attribute set and the original attribute set;

[0059] Semantic similarity is used as the fidelity of inter-domain context mapping.

[0060] This embodiment provides a mechanism for calculating the fidelity of inter-domain context mapping. Specifically, simply completing attribute mapping still has a drawback: although some mappings have a corresponding relationship, there is a matching deviation. For example, mapping pre-hospital doctors to medical personnel is semantically logically valid, but the latter's coverage is larger than the original authorization constraint range, which may relax the authorization boundary. Therefore, it is necessary to further quantify the degree of matching of security intent before and after mapping.

[0061] The system first obtains the original attribute set and the mapped attribute set generated in the previous implementation method, and calculates the semantic similarity item by item. Specifically, the semantic similarity can be calculated through a preset dimension scoring mechanism. Assume that the original attribute set is {pre-hospital doctor, Task No. Task-38, night shift}, and the mapped attribute set is {attending physician, emergency collaborative task code MC-38, night shift window}. For each pair of attributes, the system can score them based on three dimensions: role responsibility, task uniqueness, and time window consistency. Specifically, this scoring process is achieved by the system calling a preset attribute semantic mapping scoring dictionary or using a natural language processing model to calculate the cosine similarity between attribute word feature vectors to achieve objective quantitative processing.

[0062] For example, pre-hospital physicians and attending physicians share clinical continuity in their roles and responsibilities, but their responsibilities are not entirely the same, so a value of 0.82 can be assigned; Task-38 and MC-38 correspond to the same task after encoding conversion, so a value of 0.95 can be assigned; the time range of night shift and night duty window is highly consistent, so a value of 0.90 can be assigned; the system averages the three values ​​to obtain 0.89, or uses a weighted summation method, and takes 0.89 as the inter-domain context mapping fidelity of the current hop;

[0063] Specifically, semantic similarity calculation follows a defined weighting rule: attributes are divided into core attributes, such as task identifiers, and auxiliary attributes, such as duty hours, with the core attributes assigned a first preset weight. For example, 0.6 assigns a second preset weight to the auxiliary attribute. For example, 0.4; assuming the average of the individual similarity scores for all core attributes is... The average of the individual similarity scores for all auxiliary attributes is Then the inter-domain context mapping fidelity The calculation formula is:

[0064]

[0065] in, The plus sign indicates multiplication, and the plus sign indicates addition. (The text also mentions core attribute weights.) With auxiliary attribute weights The constraints are satisfied: + =1;

[0066] The individual similarity scores for each dimension are multiplied by their corresponding weights and then summed to replace a simple averaging calculation, yielding the final inter-domain context mapping fidelity. Through structured decomposition and weight allocation of attributes, the similarity calculation process is structured and transparent, ensuring that the fidelity score objectively reflects the degree of matching of the original security intent. If a mapping attribute is a composite attribute, for example... =If the emergency authorization is converted to the attending physician and on-duty status, the matching degree with the two sub-attributes can be calculated separately first, and then the lower value or weighted value can be taken to ensure that the result is conservative.

[0067] To illustrate this more specifically, the system can also set level ranges; for example, a fidelity of not less than 0.90 indicates a high-fidelity mapping, which can directly participate in subsequent path optimization; a fidelity between 0.75 and 0.90 indicates an acceptable mapping, which needs to be judged in conjunction with the node trust value; a fidelity below 0.75 indicates that the mapping risk is higher than the preset security threshold, and even if the network quality of the path meets the preset transmission standard, it will not be given priority to carry ciphertext involving sensitive verification results.

[0068] As an exception handling mechanism, if the number of original attributes and mapped attributes is inconsistent, the system will not force an average, but will calculate the value according to the priority of required attributes and the secondary priority of optional attributes. For example, the task number attribute usually has a higher access control priority than the duty window attribute, so it can be assigned a higher weight value. If a certain attribute cannot be semantically mapped at all, the similarity of that item will be recorded as 0 and a low-fidelity alarm will be triggered. If the average fidelity of all mapped items is lower than the preset lower limit, such as 0.60, the current round of cross-domain proxy conversion will be terminated, and it will only be allowed to fall back to the same domain cache or wait for a higher trusted node to take over.

[0069] When distributing troponin results from a county hospital to a municipal chest pain center, the system discovered that if the on-duty doctor in the county hospital's authentication system was directly mapped to a medical staff member at the municipal center, although basic authentication could be passed, the permissions corresponding to this mapping exceeded the scope of the original strategy. After semantic scoring, the attribute similarity of this pair was only 0.54, causing the overall fidelity to drop to 0.71. Therefore, the system did not select this mapping that exceeded the permission scope, but instead used the mapping of on-duty doctor → attending physician that satisfied the principle of least privilege, which raised the fidelity back to 0.88, thereby maintaining the original security intent from being diluted.

[0070] The purpose of this step is to use quantifiable fidelity metrics to characterize whether the permission boundaries after cross-domain translation are still close to the original settings, thereby avoiding problems such as permission expansion, permission distortion or semantic deviation after proxy re-encryption.

[0071] In this embodiment, the policy evolution module generates and updates the access control policy and reconstructs the ciphertext.

[0072] include:

[0073] Calculate the rate of change of real-time trust status data within a preset time window as a dynamic fluctuation value;

[0074] Based on the inconsistencies in the fields of the underlying communication protocol in the protocol differences, a corresponding protocol feature vector is constructed, and a re-encryption key is generated based on the dynamic fluctuation value and the protocol feature vector;

[0075] The ciphertext to be distributed is re-encrypted using the re-encryption key to generate the reconstructed ciphertext.

[0076] This embodiment provides a mechanism for generating a re-encryption key based on trust fluctuations and protocol differences. Specifically, in the aforementioned scenario, updating the policy solely based on the current trust value has a security lag: although the real-time trust status data of a specific node is currently higher than a preset threshold, its credibility may show a rapid decline trend. If the system relies solely on static trust status data for decision-making, it is easy for the reconstructed ciphertext to be assigned to a relay node with a continuously declining trust value. Therefore, this embodiment introduces dynamic fluctuation values, which, together with protocol difference features, participate in the generation of the re-encryption key.

[0077] The system first calculates the rate of change of real-time trust status data within a preset time window. Assuming a window length of 10 seconds, if the trust value of the county hospital's boundary agent node is 0.88 at time t1 and 0.80 at time t2, the dynamic fluctuation value can be simplified to (0.80-0.88) / 10 = -0.008 per second. Another backup node rises from 0.79 to 0.83 within the same window, resulting in a dynamic fluctuation value of +0.004 per second. Negative values ​​indicate decreasing node trust, while positive values ​​indicate recovering trust. Simultaneously, the system extracts the protocol feature vector corresponding to the protocol differences. For ease of explanation, the protocol difference vector can be three-dimensional, where the first dimension represents authentication format differences, the second dimension represents attribute encoding differences, and the third dimension represents time synchronization differences. If the current cross-domain jump point difference is {1, 1, 0}, then the corresponding protocol feature vector... The other jump point is {0, 1, 1}, then the corresponding The strategy evolution module inputs the dynamic fluctuation value and the protocol feature vector into the re-encryption key generation process.

[0078] The specific generation rule is as follows: the basic re-encryption key parameters are determined based on the protocol feature vector, wherein the basic re-encryption key parameters include the basic validity period. Based on dynamic fluctuation values The sign and size of the adjustment factor are calculated. The calculation formula is:

[0079]

[0080] in, For preset sensitivity coefficient and Preset sensitivity coefficient The dimension of is time; and in the calculation formula, + represents addition. Indicates multiplication operation;

[0081] If dynamic fluctuation value If it is negative, then the adjustment factor <1, and ensured by setting a preset minimum lower limit. If the value is greater than zero, convert it into a penalty factor, and use this penalty factor to calculate the actual effective duration for generating the re-encryption key. And simultaneously according to the penalty factors The ratio is rounded down to reduce the maximum number of transformation hops allowed in the basic re-encryption key parameters, which is then used as a reduction value for the transformation permission bits. This reduces the validity period of the basic re-encryption key parameters and the transformation permission bits, thereby generating a more restrictive and shorter-lasting downgraded re-encryption key. If the dynamic fluctuation value If it is positive or zero, then the adjustment factor is... Convert it into a reward factor, and use that reward factor in the same way... The algorithm calculates, assigns or extends the validity period, and generates an upgrade re-encryption key with a normal or relaxed validity period. Through this deterministic parameter adjustment mechanism, the flow of algorithm data is clearly defined, the uncertainty of complex algorithms is avoided, and the re-encryption key is dynamically adjusted according to fluctuation values.

[0082] The generated re-encryption key is used to perform a proxy re-encryption transformation on the ciphertext to be distributed; in the example, the ambulance side generates the original ciphertext. When the data is sent to the county hospital's boundary agent, the system uses the agent node's dynamic fluctuation value of -0.008 and the protocol difference vector. generate ,Will Transform into If the protocol difference vector from the county hospital to the city-level center then becomes... If the reliability of the hop relay node is stable, then the generation... ,Will Transform into ; thus obtained It is not a simple copy, but a reconstruction of the ciphertext adapted to the new access control context; this process can continue to be executed in conjunction with access policy updates; for example, when the system detects a drastic fluctuation in the trust of a node, it can not only change the key parameters, but also shorten the cache time that the ciphertext can stay on that node, or prohibit it from participating in subsequent batch forwarding; this dynamic adjustment mechanism makes the ciphertext protection strength change synchronously with the network environment status;

[0083] As an anomaly handling mechanism, if there are insufficient data points within the time window, such as when a node has just come online and the rate of change cannot be reliably calculated, the system can use the most recent stable trust value as a temporary fluctuation value of 0 and set the key validity period to be shorter. If the protocol difference feature extraction result is empty, a loose general re-encryption key is not allowed to be generated. Instead, a conservative key template is switched to support only the most basic cross-domain conversion. If the node is interrupted during the re-encryption process, the input ciphertext is retained to prevent the generation of an unrecoverable half-conversion state.

[0084] When the ambulance enters the county hospital's coverage area, the encrypted ECG data, which was previously forwarded over the public network, needs to be switched to the hospital's private network path. At this time, although the trust value of the county hospital's boundary proxy node is still above the lower limit, it has been continuously decreasing within 10 seconds. The system does not simply reuse the re-encryption parameters from the previous round, but regenerates a short-term re-encryption key based on the decreasing trend and the current protocol differences. This ensures that the node can only complete the necessary proxy conversion and cannot hold reusable conversion capabilities for a long time. The converted encrypted data is then sent to the municipal chest pain center to ensure that security and continuity are maintained during the link switching phase.

[0085] The purpose of this step is to make the re-encryption behavior no longer dependent on a fixed template, but to shrink or adjust in real time according to the trusted state of the node and the heterogeneous characteristics of the protocol, so as to achieve ciphertext reconstruction protection that is more in line with the actual state of the network.

[0086] In this embodiment, the initial attribute access tree contains multiple attribute nodes; the policy evolution module generates an updated access control policy and reconstructed ciphertext, and is further configured to: if the dynamic fluctuation value is greater than a preset fluctuation threshold, delete the attribute node in the initial attribute access tree corresponding to the cross-domain node that generates the dynamic fluctuation value; if the dynamic fluctuation value is less than or equal to the preset fluctuation threshold, extract preset restrictive conditions as supplementary attribute nodes and add supplementary attribute nodes to the initial attribute access tree; the attribute tree reconstruction is completed through the addition and deletion operations of attribute nodes, and an updated access control policy is generated.

[0087] This embodiment provides a mechanism for performing addition, deletion and reconstruction of the attribute access tree based on dynamic fluctuation values. Specifically, adjusting the re-encryption key alone has a limitation: even if the constraints of the re-encryption key are extremely strict, if the attribute access tree itself still retains its dependence on high-risk relays or low-reliability roles, the authorization logic will lag behind changes in the network environment. Therefore, this embodiment performs structural reconstruction of the attribute tree in addition to key reconstruction.

[0088] The system first reads the initial attribute access tree; for ease of explanation, a simple tree structure can be set up: the root node is a logical AND, which contains three attribute nodes, namely N1=county hospital consultation relay identity, N2=chest pain task number matching, and N3=attending doctor's on-duty status valid; here N1 is used to constrain the relay identity in the cross-domain process, and N2 and N3 are used to constrain the decryption qualification of the final receiving side.

[0089] The system compares the dynamic fluctuation value calculated in the previous implementation method with the preset fluctuation threshold. Assuming the threshold is set to +0.01, it means that when the trust status changes by more than the preset positive threshold within the window, the environment tends to be stable and some temporary reinforcement conditions can be appropriately simplified. Conversely, if the dynamic fluctuation value is less than or equal to the threshold, it means that the node has not reached the preset improvement threshold or may even deteriorate, and it is necessary to add supplementary attribute nodes to tighten authorization.

[0090] For example, if the dynamic fluctuation value of a backup city-level entry node rises from 0.78 to 0.91 within the most recent window, significantly exceeding the threshold, the system determines that the link has entered a stable recovery phase. The relay constraint node N1, previously added to protect unstable nodes, can be deleted, generating a more refined access tree N2 and N3. Conversely, if the dynamic fluctuation value of the county hospital boundary agent node is -0.008, which is less than or equal to the threshold, the system adds supplementary attribute nodes N4 = one-time transfer token valid or N5 = current session has not timed out, making the access tree N1 and N2 and N3 and N4.

[0091] By adding these short-term, task-bound attributes, the risk of unstable nodes being abused can be reduced. Furthermore, the added or deleted attribute nodes can correspond to specific nodes. If fluctuations occur at relay nodes, attributes related to relays are modified first. If fluctuations occur at target decryption nodes, the identity and timeliness attributes of the decryption side are modified first. If multiple nodes fluctuate simultaneously, nodes on the critical path are processed first, followed by edge backup nodes. This avoids making indiscriminate and large-scale changes to the entire access tree.

[0092] As an exception handling mechanism, if a certain add or delete operation results in an empty access tree, the system will not allow the generation of an empty policy, but will at least retain core constraints such as task number matching or data owner approval; if the tree depth exceeds the preset depth threshold after adding supplementary attributes for multiple consecutive rounds, making it difficult for the terminal to verify quickly, the system can merge multiple supplementary attributes into a composite attribute, such as merging the validity of the transfer token and the session not timed out into the validity of the temporary session authorization; if the fidelity decrease rate exceeds the preset decrease rate threshold after deleting a node, the system will roll back to the previous version of the access tree.

[0093] During the patient's transfer from the county hospital to the city-level chest pain center's catheterization lab preparation stage, the city-level center's entry node underwent multiple rounds of stable operation, with dynamic fluctuation values ​​consistently positive and exceeding the threshold. The system determined that the previously attached county hospital consultation relay identity was no longer a necessary constraint and therefore removed it from the access tree to avoid affecting rapid sharing within the city-level center. During the transfer, the county hospital's boundary agent experienced a decline in credibility due to abnormal scanning. The system then added a one-time transfer token valid node to the access tree, ensuring that even if the path continued to be used, the transfer could only be completed within a limited time and a limited task scope.

[0094] The purpose of this step is to allow access control policies to be structurally contracted or released as the node state changes, thereby enabling additional restrictions on unstable nodes and simplifying authorization for restoring stable links, thus balancing security and business continuity.

[0095] In this embodiment, the topology routing module calculates the trusted topology distribution cost index and establishes the ciphertext distribution path, including:

[0096] The product of the inter-domain context mapping fidelity and the data length of the reconstructed ciphertext is used as the trust topology distribution cost index.

[0097] Identify nodes in cross-domain nodes whose real-time trust status data is greater than or equal to a preset trust threshold, and designate them as remaining trusted nodes.

[0098] Calculate the adaptive routing path based on the remaining trusted nodes and the trust topology distribution cost index;

[0099] The adaptive routing path is output as the ciphertext distribution path.

[0100] This embodiment provides a mechanism for path reconstruction that combines mapping fidelity and reconstructed ciphertext length. Specifically, the aforementioned scheme can obtain updated ciphertext and update strategy, but if path selection relies solely on node trust values, a problem still arises: although the real-time trust status data of some path nodes is greater than the preset trust threshold, they need to carry ciphertext with a data volume greater than the preset length threshold or perform complex strategy mapping, resulting in the actual recovery time exceeding the preset time requirement; although some paths have fewer node hops than the preset number of hops, their fidelity is low, which can easily lead to permission distortion.

[0101] Therefore, this embodiment introduces the Trust Topology Distribution Cost Index as a comprehensive evaluation metric on the routing side; the system obtains the inter-domain context mapping fidelity on a candidate path. and the data length for reconstructing the ciphertext The product of the two is used as the trust topology distribution cost index. That is, using the calculation formula: ;in, Indicates multiplication operation;

[0102] For ease of explanation, assume that the mapping fidelity on path P1 is 0.90 and the reconstructed ciphertext length is 80 units, then the corresponding trust topology distribution cost index is 72; the fidelity on path P2 is 0.78 and the reconstructed ciphertext length is 100 units, then the corresponding trust topology distribution cost index is 78; the fidelity on path P3 is 0.95, but the ciphertext length is 40 units, then the corresponding trust topology distribution cost index is 38. These values ​​do not represent bandwidth or latency themselves, but are used to characterize the degree to which the path can stably converge after topology reconstruction under the current policy and ciphertext size. The system can select a more suitable path according to preset rules, such as prioritizing the path with better overall convergence performance among the remaining trusted nodes.

[0103] Specifically, the Trust Topology Distribution Cost Index actually represents the cost of the ciphertext data volume required to perform a strategy translation with a specific fidelity on that path. When the Trust Topology Distribution Cost Index is greater than the preset upper limit, it means that the path needs to transmit more ciphertext data than the preset carrying threshold and has high fidelity requirements, resulting in high node carrying pressure and potentially causing congestion or processing bottlenecks. When the Trust Topology Distribution Cost Index is less than the preset lower limit, the fidelity may be too low to meet security requirements. Therefore, in adaptive routing path calculation, the system presets an optimal Trust Topology Distribution Cost Index target range, such as 40 to 80. If the Trust Topology Distribution Cost Index of a candidate path falls within this range, it is considered to have better convergence performance. If it is greater than the upper limit or less than the lower limit, it indicates that the path has the risk of processing overload or translation distortion, and its routing priority is reduced accordingly. Through this structured rule, the actual routing application method of the product of fidelity and ciphertext length is clearly defined.

[0104] The system identifies the remaining trusted nodes among all cross-domain nodes. Assuming there are 6 candidate nodes in the entire network with real-time trust values ​​of 0.82, 0.76, 0.61, 0.88, 0.74, and 0.93, and a preset trust threshold of 0.75, the remaining trusted nodes are the 1st, 2nd, 4th, and 6th nodes. The 3rd and 5th nodes are not included in the main path calculation in this round because they are below the threshold. Based on the connection relationships of these remaining trusted nodes and the aforementioned trust topology distribution cost index, the system calculates an adaptive routing path.

[0105] For example, the candidate paths can be simplified as follows: First path: Ambulance Gateway → County Hospital Boundary Agent → City Center Entrance; Second path: Ambulance Gateway → Backup County Aggregation Node → City Center Entrance; Third path: Ambulance Gateway → Mobile Base Station Relay → Regional Cloud Agent → City Center Entrance; If the trust value of the backup county aggregation node in the second path is only 0.74, it will be directly eliminated; If the nodes in the third path are all trustworthy, but the mapping layers are too many and the reconstructed ciphertext is too long, resulting in a high trust topology distribution cost index, the system may still choose the first path; Finally, the selected adaptive routing path will be output as the ciphertext distribution path to the execution module.

[0106] Furthermore, when the ciphertext length is long, the system can also split it for processing; for example, the ECG waveform and the test report can be reconstructed into two ciphertexts with lengths of 30 and 70 respectively, with mapping fidelity of 0.92 and 0.85 respectively, corresponding to trust topology distribution cost indices of 27.6 and 59.5; for ECG waveforms with higher timeliness requirements, the low-hop-count path can be prioritized; for the larger test report, a more stable but slightly longer path can be selected; this refined arrangement is still an extended application of the same topology routing mechanism; as an anomaly handling mechanism, if all candidate paths fail... In the remaining trusted node links, the system does not forcibly establish low-trust paths, but instead switches to the mode of temporary storage of the nearest trusted node + periodic retry; if the trust topology distribution cost index of different paths is the same, the one with higher fidelity is selected first; if the fidelity is also the same, the one with fewer hops is selected first; if the ciphertext length exceeds the preset maximum carrying threshold, for example, with a large number of image slices, causing the trust topology distribution cost index to be greater than the preset upper limit of the trust topology distribution cost index or less than the preset lower limit of the trust topology distribution cost index, then fragmentation can be performed first, and then routing can be performed separately.

[0107] When requesting the patient's ECG waveform and emergency laboratory test data from the chest pain center, the system found that although the path via mobile base station relay was physically shorter, it involved crossing more protocol layers, leading to an increase in the length of the reconstructed ciphertext. The trust topology distribution cost index was lower than the lower limit of the preset optimal trust topology distribution cost index target range. Although the county hospital boundary proxy path was only of medium complexity, the node trust values ​​all met the standards and the fidelity was higher. Therefore, it was selected as the main path to ensure that the patient's critical data was continuously delivered to the municipal center before the patient arrived at the hospital.

[0108] The purpose of this step is to incorporate the degree of security semantic preservation and the size of the ciphertext bearer into the route reconstruction process, so as to achieve adaptive path selection that is more in line with the actual transmission characteristics of cross-domain ciphertext.

[0109] In this embodiment, the cross-domain policy evolution delay is the time elapsed from the moment a protocol difference or a change in real-time trust state data is detected until the moment the updated access control policy is generated.

[0110] The dynamic evolution computational overhead ratio is the percentage of CPU processing time consumed by cross-domain nodes when performing dynamic evolution and proxy re-encryption transformation and establishing ciphertext distribution paths, relative to the total lifecycle of packet forwarding.

[0111] This embodiment provides a quantitative indicator definition mechanism for feedback control. Specifically, if the measurement benchmarks for cross-domain strategy evolution delay and dynamic evolution computation overhead ratio are not clearly defined, different nodes will have ambiguities in the judgment criteria for processing lag or high resource consumption, which will lead to inaccurate feedback regulation. Therefore, this embodiment uniformly defines the start and end boundaries of the two core indicators.

[0112] The starting point for the cross-domain policy evolution delay is set at the moment when the system first detects either of two types of events: one is the detection of protocol differences, such as an ambulance switching from the public network to a regional private network; the other is the change in real-time trust state data reaching a level that can trigger a policy update, such as the trust value of a county hospital boundary node dropping from 0.83 to 0.77. The endpoint is set at the moment when the updated access control policy is generated, rather than the moment when the ciphertext is sent. This distinguishes the policy generation time from the link transmission time, facilitating feedback control to accurately locate bottlenecks.

[0113] For example: Suppose the system detects a protocol difference at 10:00:00.100, completes attribute mapping at 10:00:00.160, completes fidelity calculation at 10:00:00.210, and completes access tree reconstruction at 10:00:00.260. Then the latency of this round of cross-domain policy evolution is 160 milliseconds, that is, from 00:100 to 00:260. If subsequent re-encryption and actual network transmission require another 100 milliseconds, these 100 milliseconds are not included in the above latency definition. The dynamic evolution calculation overhead ratio is the ratio of the central processing unit processing time to the total lifecycle time of packet forwarding.

[0114] Specifically, assuming a data packet takes 200 milliseconds from entering a cross-domain node to completing forwarding, this 200 milliseconds is the total lifecycle time. Of this, the central processing unit (CPU) uses 20 milliseconds for trust assessment, 10 milliseconds for attribute mapping, 18 milliseconds for proxy re-encryption, and 12 milliseconds for route reconstruction, totaling 60 milliseconds. Therefore, the dynamic evolution computation overhead is 60 / 200 = 30%. If another node, due to its stronger hardware acceleration capabilities, has a total CPU processing time of only 30 milliseconds while its lifecycle remains 200 milliseconds, then its overhead is 15%. Since these two metrics respectively reflect decision-making response speed and local resource burden, the system can use them separately in subsequent feedback control.

[0115] For example, if the cross-domain policy evolution delay is greater than the preset delay threshold, it indicates that the policy chain exceeds the preset number of levels or the number of queued tasks processed by the node exceeds the preset queue threshold; if the dynamic evolution computation overhead ratio is greater than the preset overhead ratio threshold, it indicates that the node has undertaken computational tasks exceeding its processing load within a unit forwarding cycle and is not suitable for continued high-frequency evolution; as an anomaly handling mechanism, if a data packet is cached multiple times in a node, its lifecycle may be abnormally long; at this time, the system can simultaneously record the pure processing lifecycle and the total lifecycle including waiting, for different scenarios; if the central processing unit processing time acquisition fails, the node will not participate in the overhead ratio threshold judgment for the time being, but its status will be recorded as incomplete monitoring and will not be used as a priority path; if protocol differences and trust changes occur simultaneously, the earliest trigger time will be taken as the starting point to avoid underestimating the policy evolution delay;

[0116] Within the first 30 seconds after the ambulance entered the county hospital's coverage area, protocol stack switching was very frequent. The system detected a switch from a public network protocol to a private network protocol at 13:15:20.050, and the new access tree was generated at 13:15:20.230. The latency of this cross-domain policy evolution was recorded as 180 milliseconds. At the same time, the average total lifetime of this batch of ECG data packets was 240 milliseconds, of which the central processing unit spent 72 milliseconds on policy evolution, proxy re-encryption, and routing calculations, resulting in an overhead ratio of 30%. This quantitative result was used by the feedback module to determine whether to reduce the frequency of policy evolution.

[0117] The purpose of this step is to provide a unified and reproducible measurement benchmark for feedback control, thereby avoiding frequency modulation inaccuracies and path judgment deviations caused by inconsistent statistical standards.

[0118] In this embodiment, the adaptive feedback module adjusts the ciphertext distribution path using cross-domain policy evolution delay. The configuration is as follows: if the cross-domain policy evolution delay caused by a cross-domain node in the ciphertext distribution path is greater than a preset delay threshold, the cross-domain node is removed from the ciphertext distribution path and the topology routing module is re-triggered; otherwise, the ciphertext distribution path is maintained.

[0119] This embodiment provides a feedback routing mechanism for eliminating high-latency nodes based on cross-domain policy evolution delay. Specifically, the aforementioned scheme can calculate the delay and overhead ratio, but if the system only records these indicators and does not use them for path correction, an extreme case may still occur: although the real-time trust status data of a specific relay node meets the preset requirements and can complete the re-encryption conversion, its policy evolution process continues to show significant lag characteristics, causing the ciphertext distribution delay to exceed the timeliness requirements of emergency rescue services.

[0120] Therefore, this embodiment directly links cross-domain policy evolution delay with path maintenance; the system continuously monitors the policy evolution delay caused by each cross-domain node on the current encrypted distribution path and compares it with a preset delay threshold; assuming the current path is ambulance gateway → county hospital boundary agent → city center entrance, the preset delay threshold is 150 milliseconds; in a certain round of processing, the policy evolution delay generated by the ambulance gateway is 60 milliseconds, the county hospital boundary agent is 210 milliseconds, and the city center entrance is 80 milliseconds; based on this, the system identifies the county hospital boundary agent as the node that caused the delay exceeding the threshold among the current processing nodes; once the node is detected to exceed the threshold, the system does not wait for the entire link to fail, but immediately removes the node from the current encrypted distribution path and re-triggers the topology routing module;

[0121] At this point, alternative paths can be searched among the remaining trusted nodes, such as ambulance gateway → regional cloud agent → city-level center entry point, or ambulance gateway → backup county-level aggregation node → city-level center entry point. When triggered again, the reconstructed encrypted version available in the previous round can be used to avoid generating all policies from scratch, and only the affected hops are recalculated, thereby shortening the recovery time. If the latency caused by all nodes does not exceed the threshold, the current path is maintained. Maintaining this does not mean stopping monitoring, but continuing to calculate latency in subsequent cycles. If the latency is close to the threshold for several consecutive cycles, such as 145 milliseconds, 148 milliseconds, and 149 milliseconds, the system can also mark the node as a high-risk lag node in advance so that its priority can be reduced in the next round of route optimization.

[0122] In the example verification, the latency of the path nodes can be recorded as a node latency set D = [60, 210, 80] milliseconds, and the preset latency threshold T is set to 150 milliseconds. After comparing each item, the system finds that the second node exceeds the threshold, so it deletes the path edge corresponding to the second node and then runs route reconstruction on the remaining graph structure. If the node latency of the new path obtained after reconstruction is [70, 95] milliseconds, the new path remains effective. This clearly demonstrates the logical closed loop of detection-removal-rerouting.

[0123] As an anomaly handling mechanism, if the node exceeding the threshold is the only necessary node connecting to the target domain, the system cannot directly interrupt all services, but instead enters a degraded mode: only the most critical digest ciphertext, such as ECG abnormality markers and rescue levels, is sent, and the original waveform with a data length greater than the preset fragmentation threshold is not sent; at the same time, it continues to retry to find alternative links; if there is no reachable path after removing the node, the ciphertext is cached in the nearest trusted node with the current policy version number attached, and will continue to be sent after the next round of topology changes; if the node delay occasionally exceeds the threshold but returns to normal in the next cycle, frequent jitter switching can be avoided by setting a threshold for the number of consecutive times the threshold is exceeded.

[0124] Five minutes before the patient was to arrive at the municipal chest pain center, the system detected that the county hospital's boundary agent was experiencing a policy evolution delay of 230 milliseconds due to the backlog of local security audit tasks while processing the latest troponin results, exceeding the preset threshold of 150 milliseconds. The system immediately removed the node from the current path and had the regional cloud agent handle the cross-domain relay. Although the new path passed through one more logical node, the policy generation was faster, thus improving the overall distribution timeliness. The municipal center was still able to receive the critical test results before the patient arrived at the hospital.

[0125] The purpose of this step is to extend the trustworthiness of a node to whether the node can complete the policy evolution in a timely manner, so as to achieve proactive bypass of high-latency nodes and ensure that cross-domain encrypted distribution still has continuous availability in the event of sudden congestion or local processing degradation.

[0126] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.

Claims

1. A data ciphertext distribution system for heterogeneous network cross-domain communication, applied to a network comprising at least two heterogeneous communication domains, the network comprising a plurality of cross-domain nodes, characterized in that, include: The state awareness module is used to obtain the state information of cross-domain nodes, as well as the ciphertext to be distributed, the initial access control policy of the ciphertext to be distributed, and the target cross-domain node; the state information includes real-time trust state data and underlying communication protocol information. The context mapping module is used to detect protocol differences between cross-domain nodes based on the underlying communication protocol information and to calculate the inter-domain context mapping fidelity. The policy evolution module is used to dynamically evolve and re-encrypt the initial access control policy based on real-time trust state data and protocol differences, generating updated access control policies and reconstructing ciphertext; the dynamic evolution and re-encryption conversion include re-encryption key generation and attribute tree reconstruction. The topology routing module is used to calculate the trust topology distribution cost index based on the reconstructed ciphertext and the fidelity of the inter-domain context mapping, and to establish a ciphertext distribution path to the target cross-domain node based on the trust topology distribution cost index. An adaptive feedback module is used to calculate the cross-domain policy evolution delay and dynamic evolution computation overhead ratio, and adjust the policy evolution frequency of the policy evolution module and the ciphertext distribution path accordingly. The data distribution execution module is used to send the reconstructed ciphertext to the target cross-domain node along the ciphertext distribution path established by the topology routing module or adjusted by the adaptive feedback module. The topology routing module calculates the trust topology distribution cost index and establishes the ciphertext distribution path, including: using the product of the inter-domain context mapping fidelity and the data length of the reconstructed ciphertext as the trust topology distribution cost index; identifying nodes in the cross-domain nodes whose real-time trust status data is greater than or equal to a preset trust threshold as remaining trusted nodes; calculating the adaptive routing path based on the remaining trusted nodes and the trust topology distribution cost index; and outputting the adaptive routing path as the ciphertext distribution path. Cross-domain policy evolution latency is the time elapsed from the moment a protocol difference or real-time trust state data change is detected until the moment the updated access control policy is generated; dynamic evolution computational overhead ratio is the percentage of CPU processing time consumed by cross-domain nodes in performing dynamic evolution and proxy re-encryption transformation and establishing ciphertext distribution paths relative to the total packet forwarding lifecycle. The initial access control policy includes an initial attribute access tree; the context mapping module is also used to: obtain the authentication criteria and attribute definitions of cross-domain nodes; extract the corresponding original attribute set from the initial attribute access tree; and perform attribute mapping on the initial attribute access tree based on the authentication criteria and attribute definitions to generate a mapped attribute set. The context mapping module calculates the inter-domain context mapping fidelity, including: calculating the semantic similarity between the mapped attribute set and the original attribute set; and using the semantic similarity as the inter-domain context mapping fidelity.

2. The data ciphertext distribution system for heterogeneous network cross-domain communication according to claim 1, wherein, The adaptive feedback module obtains the total lifecycle time of packet forwarding, the CPU processing time, and the time required to generate updated access control policies, and calculates the cross-domain policy evolution latency and dynamic evolution computation overhead ratio accordingly; configured as follows: If the dynamic evolution calculation overhead ratio is greater than or equal to the preset overhead ratio threshold, the strategy evolution frequency of the strategy evolution module is reduced. The reduction in frequency is matched with the corresponding frequency adjustment step size based on the difference between the dynamic evolution calculation overhead ratio and the preset overhead ratio threshold, and the current strategy evolution frequency is reduced in a step-by-step manner according to the frequency adjustment step size. If the cross-domain policy evolution delay caused by a cross-domain node in the encrypted distribution path exceeds a preset delay threshold, the cross-domain node will be removed from the encrypted distribution path and the topology routing module will be triggered to adjust the path.

3. The data ciphertext distribution system for heterogeneous network cross-domain communication according to claim 1, wherein, The policy evolution module generates updated access control policies and reconstructs ciphertext, including: calculating the rate of change of real-time trust state data within a preset time window as a dynamic fluctuation value; constructing corresponding protocol feature vectors based on the inconsistencies in fields of the underlying communication protocol in protocol differences, and generating a re-encryption key based on the dynamic fluctuation value and the protocol feature vector; and using the re-encryption key to perform proxy re-encryption transformation on the ciphertext to be distributed to generate reconstructed ciphertext.

4. The data ciphertext distribution system for heterogeneous network cross-domain communication according to claim 3, wherein, The initial attribute access tree contains multiple attribute nodes; the policy evolution module generates and updates the access control policy and reconstructs the ciphertext, and is also configured to: if the dynamic fluctuation value is greater than the preset fluctuation threshold, delete the attribute node in the initial attribute access tree corresponding to the cross-domain node that generates the dynamic fluctuation value. If the dynamic fluctuation value is less than or equal to the preset fluctuation threshold, the preset restrictive conditions are extracted as supplementary attribute nodes, and supplementary attribute nodes are added to the initial attribute access tree; the attribute tree is reconstructed by adding and deleting attribute nodes, and an updated access control policy is generated.

Images