Zero-trust driven cross-domain dynamic access control method for internet of things

Abstract

The application relates to the technical field of Internet of Things, and discloses a zero-trust-driven cross-domain dynamic access control method for Internet of Things, which comprises the following steps: initiating an access request by an IoT device; after receiving the request, an edge node calculates a request trust score of a fusion device history trust, a request context and a request behavior based on a zero-trust principle, and dynamically calculates a risk level in combination with resource sensitivity; the request is routed in layers: low-risk requests are locally decided by an edge layer, medium-risk requests are asynchronously chained after edge decision, and high-risk and cross-domain requests are submitted to a blockchain layer for processing; for cross-domain requests, a cross-chain smart contract executes a trust decay function to realize trust mapping from a source domain to a target domain; finally, an ABAC smart contract dynamically authorizes based on a five-tuple policy containing a trust attribute, and maps the request trust score to a multi-dimensional permission vector. The scheme solves three major problems of a blind area of camouflage attack detection, a performance bottleneck and a lack of cross-domain interoperability.

Description

Technical Field

[0001] This invention relates to the fields of Internet of Things (IoT) and blockchain-related technologies, particularly to IoT access control schemes based on blockchain, and especially to a zero-trust driven cross-domain dynamic access control method for IoT. Background Technology

[0002] The rapid development of Internet of Things (IoT) technology is profoundly driving transformation in smart cities, Industry 4.0, and smart healthcare. The dynamic, heterogeneous, and open nature of IoT systems exposes them to increasingly serious security threats, including unauthorized resource access, sensitive data breaches, and device hijacking. Access control, as a fundamental security mechanism for managing resource access behavior, plays a crucial role in preventing unauthorized operations and protecting sensitive data in IoT environments.

[0003] Traditional centralized access control schemes suffer from single points of failure, poor scalability, and lack of transparency. To address these limitations, blockchain technology has been introduced into the IoT access control field, leveraging its decentralized, immutable, and auditable characteristics. Among existing models, attribute-based access control (ABAC) has become the mainstream paradigm due to its fine-grained and flexible policy management capabilities. Subsequent research has further introduced trust assessment mechanisms and edge computing to reduce network latency and enhance security, and introduced sidechain architectures to improve blockchain scalability. Nevertheless, existing solutions still have three key limitations that restrict their applicability in large-scale, multi-domain IoT deployments.

[0004] First, existing solutions inherently presuppose device trustworthiness, creating a fundamental security blind spot. Most current blockchain-based IoT access control solutions grant access based on static trust thresholds. If a device's trust score exceeds a fixed value, full access is granted; otherwise, access is denied. This binary authorization strategy ignores the continuous dynamics of trust. More importantly, it assumes that registered devices with high historical trust scores are trustworthy for every subsequent request. However, a compromised device may maintain a high historical trust score while exhibiting anomalous behavior in a single request. Under static solutions, such spoofing attacks are difficult to detect in a timely manner in solutions relying solely on historical trust, leading to long-term security blind spots.

[0005] Second, the unified on-chain processing architecture creates an irreconcilable performance bottleneck. Existing solutions submit all access requests—regardless of their sensitivity or domain—to the blockchain network for processing. As the number of IoT devices grows, on-chain transaction volume increases dramatically, consensus latency rises significantly, and system throughput is severely limited. Research shows that blockchain transaction processing capacity becomes a major performance bottleneck in large-scale IoT deployments, failing to meet the low latency and high concurrency requirements of time-sensitive IoT applications.

[0006] Third, the lack of cross-domain access control support severely restricts the interoperability of multi-domain IoT. In practical deployments such as smart cities and industrial IoT, devices often belong to different management domains (such as medical, industrial, and smart home domains), and cross-domain resource access needs are frequent. However, existing solutions only support access control decisions within a single domain, failing to provide trust conversion mechanisms for cross-domain requests or policy coordination protocols, which severely restricts the interconnection and interoperability of multi-domain IoT systems. Summary of the Invention

[0007] Based on the potential shortcomings of the existing technology, the technical problem to be solved by the present invention includes at least one of the following aspects:

[0008] (1) The existing solution assumes the trustworthiness of the equipment, resulting in a blind spot for detecting spoofing attacks;

[0009] (2) The existing unified on-chain processing architecture causes a performance bottleneck;

[0010] (3) Existing solutions lack cross-domain access control support, which restricts the interoperability of multi-domain IoT.

[0011] Based on the first main aspect of the present invention, a zero-trust driven cross-domain dynamic access control method for the Internet of Things (IoT) is provided. This method is based on a system model consisting of three entity layers: an IoT device layer, an edge computing layer, and a blockchain layer. Furthermore, the method includes the following steps:

[0012] IoT devices at the IoT device layer send access requests to the edge computing layer of their respective management domains;

[0013] The edge nodes of the edge computing layer receive the access request and, based on the zero trust principle, independently calculate the Request Trust Score (RTS) for each access request. The RTS integrates three dimensions: the device's historical trust value, the normality of the request context, and the normality of the request behavior.

[0014] The edge node dynamically calculates the risk level RRL for each access request based on the request trust score (RTS) and the resource sensitivity of the accessed resource.

[0015] The edge node routes access requests to the corresponding processing layer according to the risk level RRL, including routing low-risk requests to the edge computing layer for local access decision-making, routing medium-risk requests to the edge computing layer for decision-making and asynchronous on-chain recording, and routing high-risk requests and cross-domain requests to the blockchain layer for real-time verification and execution.

[0016] For cross-domain access requests, the cross-chain smart contract deployed at the blockchain layer executes a cross-domain progressive trust establishment protocol, which maps the device trust value of the source domain to the effective trust value of the target domain through a trust decay function, and gradually adjusts the effective trust value based on the cross-domain interaction history.

[0017] The ABAC smart contract deployed at the blockchain layer makes authorization decisions on access requests based on the five-tuple ABAC access control policy. The five-tuple includes subject attribute, resource identifier attribute, environment attribute, trust attribute, and permission attribute. The trust attribute includes the request trust score RTS and the preset minimum trust threshold, and is dynamically mapped to the corresponding multi-dimensional permission vector according to the request trust score RTS.

[0018] In the above solutions, this invention eliminates the reliance of existing solutions on static device historical trust by using the Request Trust Score (RTS) mechanism, thus solving the security blind spot problem of spoofing attacks. Specifically, existing solutions only compare the device's historical trust score with a fixed threshold. When an compromised device maintains a high historical trust score, its abnormal single request will still be granted full permissions. In contrast, the above solution of this invention requires edge nodes to independently calculate the RTS for each access request, integrating device historical trust, request context normality, and request behavior normality, and to dynamically authorize based on the trust attributes in the five-tuple ABAC strategy. This process of independent verification for each request ensures that even if the device's historical trust score is high, as long as the frequency, time, resource type, or data volume of the current request is abnormal, the RTS will drop significantly, and the request will be mapped to a low-privilege or even denied state. This timely blocking of spoofing attacks at the request level fills the structural blind spot of static trust authorization.

[0019] Furthermore, the above solutions match requests with processing resources using a risk-level RRL dynamic routing approach, resolving the performance bottleneck caused by unified on-chain processing. Existing solutions submit all access requests to the blockchain for processing regardless of risk level, resulting in a linear increase in on-chain transaction volume with the number of devices, high consensus latency, and low throughput. The solution in this invention limits edge nodes to dynamically calculate the risk level of each request based on RTS and the sensitivity of the accessed resource. Low-risk requests are then routed to the edge computing layer for local access decisions (without blockchain involvement), medium-risk requests are asynchronously recorded on the blockchain after edge decision-making, and only high-risk and cross-domain requests are routed to the blockchain layer for real-time verification and execution. This hierarchical routing process enables approximately 65% ​​of low-risk intra-domain requests to receive millisecond-level responses at the edge layer, reducing the transaction load and consensus pressure on the blockchain layer. This significantly improves system throughput and reduces average access latency without sacrificing security.

[0020] Finally, the above solution also addresses the lack of cross-domain access control support in existing solutions through a cross-domain progressive trust establishment protocol. Existing solutions only support access decisions within a single domain and cannot handle trust conversion and policy coordination for cross-domain resource access by devices in multi-domain IoT scenarios. In contrast, the cross-chain smart contract deployed at the blockchain layer of the above solution executes a trust decay function on cross-domain access requests, mapping the device trust value of the source domain to the effective trust value of the target domain. This effective trust value is gradually adjusted based on the number of historical cross-domain interactions (a non-zero initial trust is obtained upon the first cross-domain interaction, gradually approaching the source domain trust value as interactions accumulate). This process provides a verifiable and calibrable cross-domain trust credential conversion mechanism for the target domain, enabling devices to securely request resources between different management domains. Simultaneously, trust decay suppresses cross-domain spoofing attacks, thereby achieving interconnectivity and interoperability of multi-domain IoT systems.

[0021] Optionally, the formula for calculating the Request Trust Score (RTS) is as follows:

[0022] ;

[0023] in, This is the device's historical trust value. To request the context score, To request a score for the behavior, The weighting coefficients and .

[0024] The above scheme defines the specific calculation formula for the Request Trust Score (RTS), which integrates the device's historical trust value, request context score, and request behavior score, and controls the contribution of each dimension through weighting coefficients. Its essential function is to provide a quantifiable mathematical implementation of the zero-trust principle of never trusting and always verifying, enabling the trust assessment of each access request to simultaneously reflect long-term historical behavior, short-term context anomalies, and single-event behavior deviations. This effectively detects spoofing attacks where the device has a high historical trust score but the current request is abnormal.

[0025] Optionally, the request context score The calculation formula is:

[0026] ;

[0027] in, This is the ratio of the current request frequency to the historical average frequency; a value greater than 1 indicates that the frequency is too high. To request timestamp normality measurement, This reflects the normality of the requested timestamp; This indicates taking the maximum value between the expression within the parentheses and 0;

[0028] The request behavior score The calculation formula is:

[0029] ;

[0030] in, For resource type matching, For the normality of data volume, and The weighting coefficients and + =1;

[0031] The current request frequency, historical average frequency, request timestamp, resource type matching degree, and data volume normality are all extracted by the edge node from the access requests received from the IoT device layer.

[0032] The above scheme defines the specific calculation methods for request context score and request behavior score. The context score measures the anomalies in access frequency and time patterns through frequency ratio and timestamp normality, while the behavior score measures the anomalies in resource access behavior through resource type matching and data volume normality. Its substantial contribution lies in refining the quantitative indicators for spoofing attack detection, enabling the system to accurately capture abnormal behavior from two dimensions: the external manifestation of the request (frequency, time) and the internal content of the request (resource type, data volume), avoiding misjudgments caused by fluctuations in a single dimension.

[0033] Furthermore, the risk level RRL is calculated as follows:

[0034] Edge nodes calculate a Request Trust Score (RTS) based on historical device trust values ​​obtained from sidechains and the context and behavioral characteristics of requests. The RTS is then combined with resource sensitivity to calculate a Request Risk Score.

[0035] ;

[0036] in, The sensitivity level of the accessed resource, This is the risk trade-off coefficient;

[0037] The risk level is determined by the edge node according to the following rules: when A value less than 0.3 is considered low risk; a value less than or equal to 0.3 is considered low risk. A value less than 0.6 is considered medium risk. A value ≥ 0.6 is considered high risk;

[0038] Furthermore, all cross-domain access requests are unconditionally classified as high-risk.

[0039] The above solution matches security risks with processing overhead, enabling low-risk requests to be processed quickly at the edge layer and high-risk requests to be strongly secured by the blockchain layer. This significantly reduces on-chain load and access latency without sacrificing security, thus solving the performance bottleneck problem in large-scale IoT deployments.

[0040] Optionally, the trust decay function is:

[0041] ;

[0042] ;

[0043] in, This represents the trust value of the device in the source domain. The valid trust value of the device in the target domain. Based on the attenuation coefficient and 0 < ≤1, This represents the number of historical cross-domain interactions between the source and target domains. For familiarity function, It is a natural constant.

[0044] The specific form of the trust decay function includes the basic decay coefficient. It uses a familiarity function based on the number of cross-domain interactions to provide a secure trust conversion mechanism for multi-domain IoT scenarios. The first cross-domain device obtains non-zero initial trust, thus avoiding direct rejection. At the same time, it suppresses cross-domain spoofing attacks through trust decay and gradually restores the trust level of the source domain as the number of interactions increases, achieving a balance between security and availability and solving the technical problem of lacking a cross-domain trust conversion mechanism.

[0045] Optionally, the multidimensional permission vector includes read permission, write permission, execute permission, session validity period, maximum access frequency, and verification frequency, and the numerical range of the request trust score (RTS) is divided into four trust levels: high trust range RTS≥0.8, medium trust range 0.6≤RTS<0.8, low trust range 0.4≤RTS<0.6, and untrusted range RTS<0.4, with each trust level mapped to a different combination of multidimensional permission vectors;

[0046] The permission mapping is executed by a smart contract deployed in the blockchain layer, and the mapping result is returned to the edge node as an authorization decision.

[0047] The above scheme maps continuous RTS values ​​to discrete but fine-grained authorization policies, avoiding the coarse-grained problems caused by existing schemes that use a single static threshold, such as "trust 0.61 and 0.99 obtain the same permissions". It realizes dynamic binding of permissions and real-time trust levels, effectively defending against privilege escalation attacks.

[0048] Optionally, the corresponding processing layer includes:

[0049] The IoT device layer, composed of IoT devices, is used to initiate access requests and does not participate in the maintenance of the blockchain ledger.

[0050] The edge computing layer, consisting of edge nodes deployed within each IoT management domain, performs trust assessments and localized processing of domain access requests, and periodically synchronizes the latest access control policies from the main chain.

[0051] The blockchain layer, implemented based on the distributed ledger technology platform Hyperledger Fabric, is used to store and enforce ABAC access control policies, handle high-risk and cross-domain access requests, and record trust state update events.

[0052] Routing decisions are made by edge nodes based on the risk level RRL.

[0053] The above scheme defines the specific responsibilities of the three processing layers (IoT device layer, edge computing layer, and blockchain layer): the IoT device layer only initiates requests and does not participate in ledger maintenance; the edge computing layer is responsible for trust assessment and local processing within the domain and periodically synchronizes policies; and the blockchain layer, based on Hyperledger Fabric storage policies, handles high-risk and cross-domain requests and records trust events. This scheme clarifies the functional boundaries and collaborative relationships of each layer in the layered architecture, providing feasible physical architectural support for risk-adaptive routing and ensuring the coexistence of low-latency processing and high security guarantees.

[0054] Optionally, the method further includes a cross-chain trust state synchronization step, including:

[0055] Differential triggering and batch aggregation synchronization are performed by the cross-chain smart contract BA-CCSC, which is deployed simultaneously on the blockchain main chain and the trusted side chain;

[0056] Only when the device trust value changes Synchronization may be triggered when a trust level transition occurs, and within a preset time window. The trust updates of multiple devices are packaged into a single cross-chain transmission, in which The trigger threshold for changes in trust value;

[0057] The initiator of the cross-chain smart contract BA-CCSC is the trust smart contract TSC deployed on the edge node trust sidechain, and the synchronization target is the blockchain main chain.

[0058] The specific mechanisms for cross-chain trust state synchronization include differentiated triggering and batch aggregation, which solve the efficiency problem of real-time synchronization of trust state between the main chain and side chains. By avoiding frequent cross-chain transactions triggered by small trust fluctuations and batch transmission in concurrent scenarios, the overhead of cross-chain communication is reduced, providing low-cost inter-chain synchronization support for cross-domain progressive trust establishment protocols.

[0059] Based on a second key aspect of the present invention, an electronic device is provided, comprising one or more processors;

[0060] Storage device for storing one or more programs;

[0061] When one or more programs are executed by one or more processors, the one or more processors implement the aforementioned zero-trust-driven cross-domain dynamic access control method for the Internet of Things.

[0062] Based on a third key aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed, implements the aforementioned zero-trust-driven cross-domain dynamic access control method for the Internet of Things.

[0063] Compared with existing technologies, this invention achieves an overall improvement in three aspects: security, system performance, and cross-domain interoperability.

[0064] In terms of security, existing solutions based on static device historical trust cannot detect spoofing attacks launched by high-trust devices. However, this invention uses the Request Trust Score (RTS) mechanism to independently evaluate the behavior of each access request in multiple dimensions, dynamically binding permissions with real-time request credibility. This eliminates the structural security blind spots of static trust thresholds and can effectively defend against spoofing attacks, privilege escalation attacks, replay attacks, and cross-domain deception attacks.

[0065] In terms of system performance, existing solutions submit all requests to the blockchain for processing, resulting in throughput bottlenecks. This invention adopts a risk-adaptive three-layer hierarchical architecture, which dynamically routes requests to the edge layer for local processing, asynchronous on-chain processing, or real-time verification on the main chain based on the risk level of the request. This offloads approximately 65% ​​of low-risk requests to the edge layer, reducing the transaction load and consensus latency of the blockchain layer, and achieving low latency and high throughput in high-concurrency scenarios.

[0066] Regarding cross-domain interoperability, existing solutions only support access control within a single domain. This invention designs a cross-domain progressive trust establishment protocol, which provides a secure and calibrable cross-domain trust conversion scheme for multi-domain IoT systems through a trust decay function and a familiarity accumulation mechanism based on interaction history. It achieves secure interconnection and resource access between multiple management domains for the first time. Attached Figure Description

[0067] To more clearly illustrate the technical solutions in the embodiments of the present invention 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 the present invention. For those skilled in the art, obtaining other drawings based on these drawings without creative effort still falls within the scope of the present invention.

[0068] Figure 1 The following is an execution flowchart of a zero-trust-driven cross-domain dynamic access control method for the Internet of Things, according to one embodiment of the present invention.

[0069] Figure 2 A system model diagram of a GTAC scheme for implementing the method of the present invention is shown in one embodiment;

[0070] Figure 3 An overall architecture diagram of a GTAC scheme for implementing the method of the present invention is shown in one embodiment;

[0071] Figure 4 Algorithm 1 of the present invention, ZT-ABACSC — ABAC smart contract pseudocode, is shown in one embodiment.

[0072] Figure 5 Algorithm 2 of the present invention, CCSC — cross-chain smart contract pseudocode, is shown in one embodiment. Detailed Implementation

[0073] The preferred embodiments of the present invention will be described in detail below to provide a clearer understanding of the purpose, features, and advantages of the present invention. It should be understood that the following embodiments are not intended to limit the scope of the present invention, but are merely illustrative of the essential spirit of the technical solution of the present invention.

[0074] In the following description, certain specific details are set forth for the purpose of illustrating various disclosed embodiments in order to provide a thorough understanding of the various disclosed embodiments. However, those skilled in the art will recognize that embodiments may be practiced without one or more of these specific details. In other instances, well-known techniques associated with the invention may not have been shown or described in detail to avoid unnecessarily obscuring the description of the embodiments.

[0075] Throughout this specification, references to "an embodiment" or "an embodiment" indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Therefore, the appearance of "in an embodiment" or "an embodiment" in various places throughout the specification does not necessarily refer to the same embodiment. Furthermore, a particular feature, structure, or characteristic may be combined in any manner in one or more embodiments.

[0076] The following are the main technical terms that may be involved in the embodiments of this invention and their meanings:

[0077] Trust Sidechain: A parallel blockchain network deployed on edge nodes, responsible for executing Trust Smart Contracts (TSCs) to periodically calculate device trust values ​​and maintain the sidechain ledger.

[0078] Admin Node: The system management entity responsible for initializing the blockchain network, registering the identities of all participants, installing and updating smart contracts, and dynamically managing ABAC strategies based on device trust status.

[0079] Distributed Data Storage (DDS): An off-chain distributed storage system for raw data generated by IoT devices, where storage entries are organized in the form of triples.

[0080] Cross-domain access request: A request initiated by a device from its own management domain (source domain) to another management domain (target domain) to access resources. In this invention, this is unconditionally classified as high-risk.

[0081] Cross-domain progressive trust establishment protocol: A protocol that maps the trust value of a source domain device to the effective trust value of the target domain through a trust decay function, and gradually adjusts the effective trust value based on the cross-domain interaction history.

[0082] Cross-chain smart contracts (BA-CCSC): Smart contracts deployed on both the main blockchain and the trust sidechain, responsible for executing differentiated triggering and batch aggregation of cross-chain trust state synchronization.

[0083] ZT-ABACSC: An ABAC smart contract deployed on the blockchain layer, which executes the access verification process (resource verification, policy query, environment verification, RTS verification, permission mapping) and is the on-chain execution core of the zero-trust mechanism of this invention.

[0084] Trust Smart Contract (TSC): A smart contract deployed on the trust sidechain, responsible for periodically calculating the device trust value. The calculation formula integrates PDR (packet delivery rate), Quality (service quality), and Freq_norm (normalized frequency) and introduces a time smoothing mechanism.

[0085] Replay attack: An attacker intercepts a legitimate, expired access request and resubmits it, attempting to impersonate a legitimate user using expired credentials.

[0086] Privilege escalation attack: Attackers control low-trust devices and attempt to gain unauthorized access to restricted resources by forging attributes or exploiting the boundary effects of static single-threshold binary authorization.

[0087] Disguise attack: An attacker takes control of a compromised device that has accumulated a high historical trust score through legitimate behavior, and manipulates single request parameters (such as frequency and resource type) to perform unauthorized operations while maintaining the high historical trust value.

[0088] Cross-domain spoofing attack: Attackers deliberately accumulate a high trust value within their home domain, and then use that credential to send access requests to other domains in an attempt to bypass the target domain's security policy.

[0089] Hyperledger Fabric: The distributed ledger technology platform used in the blockchain layer of this invention to build the ABAC main chain network.

[0090] UNSW-NB15 dataset: The real network dataset used in the experiments of this invention contains normal traffic and 9 types of attack traffic (Fuzzers, DoS, Exploits, etc.) to simulate IoT access request flow.

[0091] Raft consensus protocol: The consensus protocol adopted by the sorting nodes in the main chain network of this invention is used to uniformly maintain the transaction order and ledger consistency across organizations.

[0092] Batch aggregation mechanism: Within a preset time window, trust updates from multiple devices are packaged into a single cross-chain transmission, reducing on-chain overhead.

[0093] Please see Figure 1 The present invention provides an embodiment of a zero-trust driven cross-domain dynamic access control method for the Internet of Things, including steps S100 to S600 executed by a computer system.

[0094] Step S100: The IoT device in the IoT device layer sends an access request to the edge computing layer of its management domain.

[0095] In step S200, the edge node of the edge computing layer receives the access request and, based on the zero trust principle, independently calculates the request trust score RTS for each access request. The request trust score RTS integrates three dimensions: device historical trust value, request context normality, and request behavior normality.

[0096] Step S300: The edge node dynamically calculates the risk level RRL for each access request based on the request trust score RTS and the resource sensitivity of the accessed resource.

[0097] Step S400: The edge node routes access requests to the corresponding processing layer according to the risk level RRL, including routing low-risk requests to the edge computing layer for local access decision, routing medium-risk requests to the edge computing layer for decision and asynchronous on-chain recording, and routing high-risk requests and cross-domain requests to the blockchain layer for real-time verification and execution.

[0098] In step S500, the cross-chain smart contract deployed in the blockchain layer executes a cross-domain progressive trust establishment protocol for cross-domain access requests. It maps the device trust value of the source domain to the effective trust value of the target domain through a trust decay function, and gradually adjusts the effective trust value based on the cross-domain interaction history.

[0099] In step S600, the ABAC smart contract deployed in the blockchain layer makes authorization decisions on access requests based on the five-tuple ABAC access control policy. The five-tuple includes subject attribute, resource identifier attribute, environment attribute, trust attribute, and permission attribute. The trust attribute includes the request trust score RTS and the preset minimum trust threshold, and is dynamically mapped to the corresponding multi-dimensional permission vector according to the request trust score RTS.

[0100] Inspired by the zero-trust security principle of "never trust, always verify," this invention abandons the implicit trust assumption inherent in existing solutions and instead evaluates each access request independently based on real-time behavioral evidence. This invention adopts a dual-chain architecture consisting of an ABAC main chain and a trust side chain, and introduces three novel mechanisms to systematically address the limitations of existing technologies: (1) a zero-trust-based request trust score (RTS) mechanism that uses multi-dimensional behavioral evidence to evaluate each access request independently; (2) a risk-adaptive three-layer hierarchical access decision architecture that routes requests to different processing layers based on dynamically calculated risk levels; and (3) a cross-domain progressive trust establishment protocol that provides a secure trust conversion mechanism for inter-domain device access.

[0101] 1) Zero-Trust Request-Level Trust Scoring Mechanism: To address the problem that existing solutions rely solely on historical device trust scores for authorization, failing to detect anomalies in individual requests and thus making spoofing attacks completely invisible, this invention proposes a Request Trust Score (RTS) mechanism based on the zero-trust principle of "never trust, always verify." This mechanism independently evaluates each access request by integrating three complementary behavioral dimensions—long-term device trust history, request context normality (including access frequency and time patterns), and request behavior normality (including resource type consistency and data volume anomalies)—and dynamically maps permissions to four trust levels. This allows the system to promptly identify and respond to abnormal request behaviors even when the device's historical trust score remains high.

[0102] 2) Risk-Adaptive Three-Layer Hierarchical Access Decision Architecture: To address the problem of existing solutions uniformly submitting all access requests to the blockchain for processing without regard to risk level, causing severe performance bottlenecks in large-scale IoT deployments, this invention designs a three-layer hierarchical architecture comprising an IoT device layer, an edge computing layer, and a main chain layer. This architecture dynamically calculates the risk level for each request by integrating RTS and resource sensitivity, and routes the request to the corresponding processing layer accordingly: low-risk requests are processed locally at the edge layer, medium-risk requests are decided at the edge layer and asynchronously recorded on the chain, and high-risk and cross-domain requests are verified and executed in real time by the main chain. This ensures that security guarantees are proportionally matched to request risk, significantly reducing on-chain load and improving system throughput without sacrificing security.

[0103] 3) Cross-Domain Progressive Trust Establishment Protocol: To address the issues of existing solutions not supporting cross-domain access control in multi-domain IoT scenarios and the inability of the target domain to effectively verify and calibrate trust credentials from other domains, this invention designs a cross-domain progressive trust establishment protocol based on trust decay and familiarity accumulation. This protocol maps the source domain trust value of a device to the effective trust of the target domain according to a basic decay coefficient, ensuring that the device obtains a non-zero initial trust on the first cross-domain interaction rather than being directly rejected. The effective trust gradually increases with the accumulation of cross-domain interaction history until it approaches the source domain value, thereby achieving interconnection and interoperability of multi-domain IoT systems while ensuring the security boundary of cross-domain access.

[0104] In the following embodiments, the above three mechanisms of the present invention are further described in detail using a system model named GTAC.

[0105] The GTAC provided by this invention is designed for multi-domain IoT deployment scenarios. For example... Figure 2 As shown, the overall system consists of three entity layers: the IoT device layer, the edge computing layer, and the blockchain layer.

[0106] The IoT device layer consists of a large number of heterogeneous, resource-constrained IoT terminals, including sensors, actuators, and smart gateways. These devices connect to the edge network via wireless gateways. Each device holds a unique device identifier and MAC address for identity management. The system is divided into multiple independent IoT management domains, such as a medical domain, an industrial IoT domain, and a smart home domain. Each domain independently maintains its own trust assessment infrastructure and ABAC policy repository.

[0107] The edge computing layer consists of edge nodes deployed within each IoT domain, responsible for trust assessment and localized access decision processing within the domain. Edge nodes continuously monitor IoT device behavior by running Trust Smart Contracts (TSCs) on the trust sidechain, periodically calculating and updating device trust values ​​based on historical interaction records. Crucially, edge nodes are the core decision-making points in the GTAC layered architecture: low-risk and medium-risk domain access requests are resolved locally at the edge, without on-chain involvement, significantly reducing latency and on-chain load.

[0108] The blockchain layer consists of an ABAC main chain implemented using Hyperledger Fabric, responsible for storing and enforcing ABAC access control policies, handling cross-domain access requests, and recording trust state update events. All participants authenticate their identities through CA nodes, ensuring the security and integrity of on-chain data. Distributed Data Storage (DDS) serves as an off-chain storage component for data generated by IoT devices. Data entries are accompanied by trust tags, ensuring that only trusted and verified data enters storage. In multi-domain scenarios, edge layers from different IoT domains synchronize trust states with the main chain through cross-chain smart contracts (BA-CCSC), with CCSC coordinating cross-domain access policy verification and authorization decisions.

[0109] In the following embodiments, this invention assumes that an attacker can eavesdrop on all IoT network communications and control some IoT devices or user nodes, performing injection, tampering, or replay operations on the controlled nodes. Based on the analysis of actual security threats to IoT access control systems, this invention defines the following four attack scenarios.

[0110] 1) Replay attack

[0111] Attackers intercept valid access requests from legitimate users—including subject attributes, resource identifiers, timestamps, and environment parameters—and resubmit them to the access control system after the policy expires, attempting to impersonate legitimate users using expired credentials. This replay attack exploits a vulnerability in the access control system's insufficient validity verification. In IoT deployments, this manifests as attackers capturing historical access credentials and resubmitting them after the policy expires, threatening the security of sensitive data resources. This attack primarily targets the environment attributes of ABAC policies. This involves using a strategy to create a window between expiration and detection. This indicates the start timestamp of the policy taking effect, representing the point in time when the access control policy begins to take effect. This indicates the end timestamp of the policy's expiration, representing the point in time when the access control policy expired. When the current time of the access request exceeds [time missing]... When this happens, the strategy automatically fails, the request is rejected, and thus replay attacks are defended against. Indicates allowed sources A set of addresses, indicating that only addresses from this set... Access requests to the specified address are allowed.

[0112] 2) Privilege escalation attack

[0113] Attackers control IoT devices or user accounts with low trust levels and attempt to access protected resources with actions exceeding their authorized permissions by forging attribute values ​​or exploiting the boundary effects of static single-threshold binary authorization mechanisms. Under a fixed-threshold authorization scheme, attackers only need to maintain the device's trust score above the threshold to gain full privileges, regardless of the actual quality of the behavior. This attack specifically exploits the coarse-grained nature of binary authorization: devices with trust scores of 0.61 and 0.99 receive the same permissions, making permission differentiation impossible. In industrial IoT scenarios, successful privilege escalation can grant attackers unauthorized access to critical control commands and configuration data.

[0114] 3) Disguise attack

[0115] An attacker gains control of a compromised device that has accumulated a high historical trust score through legitimate prior actions. While maintaining this high historical trust value, the attacker manipulates parameters for individual requests—such as unusually high request frequency, access to resource types inconsistent with historical patterns, or requests originating from anomalies. The request for an address—to perform an unauthorized operation. This attack is particularly stealthy because existing static trust schemes assess device trustworthiness solely based on historical trust scores. Since the historical trust score remains high, the scheme grants full permissions without detecting unusual request behavior. This spoofing attack directly exploits the gap between static historical trust and the actual behavior of each request, which is the primary motivation for introducing the zero-trust RTS mechanism in the GTAC of this invention.

[0116] 4) Cross-domain deception attack

[0117] In multi-domain IoT deployment scenarios, attackers deliberately accumulate high trust values ​​within their home domain and then use these high-trust credentials to initiate access requests to other domains, attempting to bypass the target domain's local security policies and gain unauthorized access to cross-domain resources. Because existing solutions lack cross-domain trust conversion mechanisms, the target domain cannot effectively verify or calibrate trust credentials from other domains, making this attack a real threat in multi-domain interconnected scenarios. This attack challenges resource isolation and data security in the collaborative environment of multi-subsystem smart cities.

[0118] Table 1 summarizes the key characteristics of the four attack types mentioned above and the corresponding defense mechanisms in GTAC.

[0119]

[0120] Based on the above system model and threat model, this invention formalizes the core problem that GTAC solves as follows.

[0121] Definition 1 (IoT Device Trust Value): Let IoT device... Trust value The trust value is 0 for completely untrusted and 1 for completely trusted. The trust value is determined by the edge node based on the device's behavior within a time window. The historical interaction records within the system are periodically calculated and updated to reflect communication reliability and behavioral compliance.

[0122] Definition 2 (Trust Request Score): Trust Request Score It is the core metric of the GTAC zero-trust mechanism. It independently evaluates each access request by integrating three dimensions: device historical trust, request context normality, and request behavior normality. This enables the system to detect spoofing attacks where the device has a high historical trust score but the current request is abnormal.

[0123] Definition 3 (Request Risk Level): Request Risk Level Depend on The calculation, combined with resource sensitivity, determines which of the three processing layers a request should be routed to: local processing at the edge layer, asynchronous on-chain processing at the edge layer, or real-time verification at the main chain.

[0124] Definition 4 (ABAC Five-Tuple Strategy): GTAC introduces trust as the fifth attribute element based on the traditional ABAC four-tuple, defining the access control strategy as a five-tuple:

[0125] ;

[0126] in, Indicates access control policy, Each of these represents one of the five elements in the quintuple.

[0127] The five elements are defined as follows:

[0128] : Subject attribute, describing the identity identifier and group membership of the access request initiator, uniquely identifying the access subject. Among them, This represents an identity identifier that uniquely identifies the accessing entity. Indicates group membership relationships and describes the group to which the subject belongs.

[0129] Resource identification attribute: Uses the MAC address of the IoT device as a unique identifier for the data resource to ensure accurate resource lookup. This indicates the MAC address of the IoT device.

[0130] Environment attributes, including policy validity period (start and end timestamps) and the set of allowed source IP addresses. Current time exceeds... The strategy automatically expires to defend against replay attacks.

[0131] Trust attributes (the fifth element introduced by GTAC), where The minimum trust threshold specified by the strategy. A trust score is calculated in real time for each request. Access decision verification. and will Dynamically map to fine-grained permission vectors.

[0132] P: Permission attribute, determined by... Dynamically determined and mapped to a multi-dimensional permission vector that includes read / write / execute permissions, session validity, and authentication frequency, rather than a simple binary allow / deny decision.

[0133] Based on the above definitions, the core problem that GTAC solves in this invention can be formally expressed as: designing an access control mechanism under the constraint of satisfying the system security objective (effectively defending against the above four attack types). , so that:

[0134] (1) Each requested permission is dynamically bound to the Real-Time Behavior Trust Score (RTS), rather than a static historical trust value;

[0135] (2) Minimize intra-domain request access decision latency and maximize system throughput through risk-adaptive hierarchical routing;

[0136] (3) Cross-domain access requests obtain secure and trustworthy authorization decisions after being attenuated by the trust conversion protocol.

[0137] Based on the above system model, threat model, and problem modeling, the design of GTAC in this invention must meet the following four core objectives:

[0138] Zero Trust Security: GTAC must implement the zero-trust principle of "never trust, always verify," independently evaluating each access request based on multi-dimensional behavioral evidence, rather than relying on static historical trust values. The solution must effectively defend against all four defined attack types: defending against replay attacks through ABAC strategy time window verification; defending against privilege escalation attacks through RTS-based fine-grained permission mapping; defending against spoofing attacks through per-request behavior anomaly detection; and defending against cross-domain spoofing attacks through trust decay protocols.

[0139] Fine-grained dynamic authorization: Access permissions must be continuously and precisely bound to each request's RTS, rather than a static device-level trust score. Permissions are progressively adjusted across four authorization levels as the trust level changes. This eliminates the security blind spots of existing binary authorization schemes and avoids service interruptions caused by sudden permission revocation.

[0140] Risk-adaptive scalability: As the scale of IoT devices grows, system performance should not degrade significantly. By routing low-risk intra-domain requests to local processing at the edge layer and submitting only high-risk and cross-domain requests to the main chain, the solution reduces on-chain transaction load and ensures acceptable access latency and throughput in large-scale IoT deployment scenarios.

[0141] Cross-domain interoperability: The solution must support secure and trusted access between multiple IoT management domains, provide a standardized cross-domain trust conversion protocol, and enable devices in different domains to securely access cross-domain resources under the guarantee of a progressive trust decay mechanism, so as to meet the interoperability requirements of actual multi-domain IoT deployments.

[0142] In one possible embodiment below, the design of the GTAC of the present invention will be fully presented. First, the overall system architecture and component responsibilities are described, then the three core innovative mechanisms are elaborated in detail, and finally the end-to-end workflow is introduced.

[0143] In one embodiment, the overall architecture of the GTAC scheme for implementing the method of the present invention is as follows: Figure 3 As shown, the system consists of six core components: an IoT network, a trust sidechain, a distributed data storage (DDS), an ABAC main chain, management nodes, and IoT users. The architecture's design philosophy stems from a fundamental rethinking of access control decision-making in large-scale, multi-domain IoT environments.

[0144] Existing solutions separate trust assessment from access control to improve scalability. However, they still route all access requests uniformly to the blockchain, and access decisions are based on static device-level trust values. GTAC builds on this by introducing two orthogonal innovations.

[0145] First, a Zero Trust Request Trust Score (RTS) mechanism is introduced, which no longer authorizes requests based on the device's historical trust score, but instead conducts a multi-dimensional behavioral assessment of each access request independently. Second, a risk-adaptive three-layer hierarchical routing mechanism is introduced, which no longer submits all requests to the blockchain, but routes requests to the corresponding processing layer based on a dynamically calculated Request Risk Level (RRL). These two mechanisms transform GTAC from a "device trust-driven" solution to a "request behavior-driven" solution, fundamentally solving the spoofing attack vulnerabilities and performance bottlenecks of existing solutions.

[0146] The six core components are defined as follows:

[0147] IoT Network: Composed of a large number of resource-constrained IoT devices connected to the edge network via gateways. Each device possesses a unique identifier and MAC address. All devices register on a trusted sidechain, and edge nodes continuously monitor their behavior and calculate trust values.

[0148] Trust Sidechain: A parallel blockchain network deployed on edge nodes, responsible for executing Trust Smart Contracts (TSCs) to periodically calculate device trust values ​​and maintain the sidechain ledger. The Trust Sidechain also serves as the core execution layer of the GTAC layered architecture, handling local authorization decisions for low-risk requests and providing asynchronous audit logs for medium-risk requests.

[0149] Distributed Data Storage (DDS): An off-chain distributed storage system for raw data generated by IoT devices. Storage entries are organized in the form of triples. ,in, Indicates the first The MAC address of each device; This refers to the raw data generated by IoT devices, i.e., the actual off-chain data content stored. For the first The current trust label of each device ensures that only trusted and verified data enters the storage. GTAC's DDS storage entries are dynamically associated with RTS permission vectors, and authorized users can only access the data fields corresponding to their permission level.

[0150] The ABAC main chain, built on Hyperledger Fabric, is responsible for storing and enforcing ABAC access control policies, handling high-risk and all cross-domain access requests. The main chain executes a five-step access decision process through ABAC smart contracts (ABACSC).

[0151] Management Node: The system management entity, responsible for initializing the blockchain network, registering the identities of all participants, installing and updating smart contracts, and dynamically managing ABAC policies (adding, updating, and invalidating) based on changes in device trust status.

[0152] IoT users: End users seeking access to IoT device data obtain authorization for resources in DDS by submitting an ABAC access request (ABACR) to the appropriate processing layer determined by the request RRL.

[0153] In one possible embodiment, the Zero Trust Request Trust Score (RTS) mechanism proposed in this invention is described.

[0154] The fundamental limitation of existing solutions stems from the fact that access decisions are based on static, device-level historical trust values, which fail to reflect abnormal behavior in each request. A device that has accumulated trust scores through legitimate historical behavior... The equipment, as long as Even with highly unusual requests, existing solutions fail to trigger any security response, rendering spoofing attacks completely invisible. The GTAC solution of this invention addresses this vulnerability by implementing the zero-trust principle. Regardless of the device's historical trust score, each access request is independently evaluated based on multi-dimensional behavioral evidence.

[0155] The RTS mechanism captures request credibility from three complementary dimensions. The first dimension is the request context score. It is used to detect the external manifestations of two types of spoofing attacks: abnormal access frequency and abnormal time.

[0156] ;

[0157] in, A value greater than 1 indicates a high frequency; This reflects the normality of the request timestamps. For example, if a device typically sends 10 requests per minute but suddenly sends 50, then... , It will decrease significantly.

[0158] The second dimension is the request behavior score (Behavior_score ∈ [0, 1]), which is used to capture resource type deviations and abnormal data access volumes. These two types of anomalies are often direct manifestations of unauthorized operations performed by compromised devices.

[0159] ;

[0160] in, For resource type matching degree; For the normality of data volume, Weight . The accuracy is higher because resource type deviation is the most direct behavioral characteristic of an compromised device performing unauthorized operations, making it more distinguishable. The values ​​are relatively low, as abnormal data access volumes can occur even during normal business fluctuations, and relying solely on this factor results in a high false positive rate. The values ​​of the two weights will be further verified through ablation experiments in Section 6.

[0161] The third dimension is device history trust. The baseline trust context is provided by TSC based on the periodic calculation of the device's historical interaction records within a time window W. While a positive value contributes to RTS, it alone is insufficient to grant high privileges; it must be supported by a normal request context and behavior. Integrating these three dimensions, RTS is calculated as follows:

[0162] ;

[0163] in, . The highest level of reliability is achieved because the long-term historical behavior of a device is the most stable basis for assessing the credibility of a request. Secondly, abnormal frequency and timing are the most common external manifestations of spoofing attacks; At its lowest, due to the significant variations in resource types and data volume characteristics across different scenarios, relying solely on one resource can easily lead to misjudgments.

[0164] The RTS-based permission mapping of the present invention will be described in one of the following possible embodiments.

[0165] After determining the RTS value, the GTAC of this invention divides the RTS range [0, 1] into four trust levels and maps them to the corresponding multi-dimensional permission vectors, as shown in Table 2. Unlike existing schemes that use a single threshold for binary authorization, this mapping achieves a continuous binding of permissions and trust.

[0166]

[0167] Under the existing scheme, and Devices that previously received the same full permissions cannot differentiate their permissions. Under the GTAC of this invention, if the same device issues a reduced... and For abnormal requests, even if the historical trust value is still high, the resulting RTS may drop to 0.55, mapping to a lower trust level with only read-only access. This gradual permission adjustment eliminates security blind spots while avoiding service interruptions caused by sudden permission revocation.

[0168] The risk-adaptive three-tier hierarchical access decision architecture of the present invention will be described in one of the following possible embodiments.

[0169] Existing solutions submit all access requests to the blockchain for processing. However, with the increasing scale of IoT devices, on-chain transaction volume rises sharply, severely limiting system throughput. Furthermore, access requests in actual IoT deployments vary significantly in terms of security sensitivity; low-risk intra-domain requests constitute the majority, with stable security policies that do not require the full consensus process of the blockchain; while high-risk and cross-domain requests require strong security guarantees from the main chain. To address this difference, the GTAC architecture of this invention designs a risk-adaptive three-layer hierarchical access decision architecture. By dynamically calculating the Request Risk Level (RRL) for each request, it routes requests to the processing layer commensurate with their risk, significantly reducing on-chain load while ensuring security.

[0170] 1) Three-tier architecture design

[0171] The design principle of the three-layer architecture is that security guarantees and processing overhead should be commensurate with the risk of the request: lower-risk requests are processed closer to the device to avoid unnecessary blockchain overhead; only higher-risk requests are sent to the main chain to obtain full consensus security guarantees. The responsibilities of the three layers are divided as follows.

[0172] IoT device layer: Responsible for initiating access and data storage requests. Devices do not participate in blockchain ledger maintenance; they only communicate with the edge layer through gateways, minimizing device-side computation and communication overhead.

[0173] Edge computing layer: Composed of edge nodes deployed in each IoT domain, performing two core tasks: (1) trust assessment, continuously calculating device trust values ​​by running a trust sidechain; (2) domain access decision, executing local authorization for requests classified as low-risk or medium-risk by the RRL mechanism. Low-risk requests are processed in millisecond response time without generating any on-chain transactions. Medium-risk requests are decided at the edge, and the results are asynchronously recorded to the sidechain for auditing. Edge nodes periodically synchronize the latest policies from the main chain to maintain the timeliness of local caches.

[0174] Main chain layer: Handles only two types of requests: high-risk access requests that require real-time verification by the main chain, and all cross-domain access requests (unconditionally classified as high-risk). Because the edge layer intercepts most intra-domain requests, the transaction pressure on the main chain is significantly reduced, maintaining high throughput in high-concurrency scenarios.

[0175] 2) Risk-adaptive request routing

[0176] RRL is the core link connecting RTS evaluation and the three-layer architecture: edge nodes are initially based on data obtained from the sidechain. The request risk score is calculated by combining the request context and behavioral characteristics with the request risk score.

[0177] ;

[0178] in Reflects the sensitivity level of the accessed resource, which is specified by the administrator during policy configuration; This is a risk trade-off coefficient, reflecting the relative contribution of RTS anomalies to risk assessment. The default value is [value missing]. This means that in general IoT scenarios, the impact of abnormal request behavior on risk is higher than resource sensitivity, and administrators can adjust this parameter according to the actual deployment scenario.

[0179] Risk level from Sure: hour The request is routed to the edge layer for local decision-making. hour The request is routed to the edge layer for decision-making and asynchronously recorded on the blockchain; hour The request is routed to the main chain for real-time execution. All cross-domain requests are unconditionally classified as high-risk and directly submitted to the main chain.

[0180] The cross-domain progressive trust establishment protocol of the present invention is illustrated in one of the following possible embodiments.

[0181] Current solutions limit trust assessment for all access requests to a single management domain, failing to handle cross-domain scenarios. When the source domain... The device carries its domain trust value To target domain There are two fundamental problems when initiating an access request.

[0182] Firstly, This only reflects the historical behavior of devices within the source domain. Significant differences may exist between the two domains in terms of management policies, device types, and security environments. Direct use... First, it introduces additional trust uncertainty; second, if the first cross-domain device is directly rejected, legitimate multi-domain IoT interconnection cannot be achieved. To address these two issues, the GTAC of this invention designs a cross-domain progressive trust establishment protocol: by using a trust decay function to map source domain trust to target domain valid trust, it ensures that the first cross-domain device obtains non-zero initial trust, and gradually restores it to the source domain trust level as cross-domain interaction history accumulates.

[0183] 1) Trust decay function

[0184] When the device Carry source domain trust value To target domain When initiating an access request, its valid trust value in the target domain. It is determined by the following attenuation function.

[0185] ;

[0186] ;

[0187] in, This represents the trust value of the device in the source domain. The valid trust value of the device in the target domain. Based on the attenuation coefficient and 0 < ≤1 reflects the inherent trust uncertainty introduced by cross-domain access; This represents the number of historical cross-domain interactions between the source and target domains. For familiarity function, It is a natural constant. The value of needs to balance security and availability: Too small a value will result in low trust levels for legitimate cross-domain devices, leading to their rejection. An excessively large value weakens the ability to suppress cross-domain spoofing attacks. The default value is... This means that the device gains 85% trust from the source domain for the first time across domains, which is sufficient to enter the medium trust level to complete basic access, while there is a clear permission downgrade relative to the source domain.

[0188] This decay function guarantees The trust level is consistently established, and the first cross-domain device gains non-zero initial trust, which gradually approaches the source domain trust level as interactions accumulate.

[0189] 2) Cross-chain trust state synchronization

[0190] The execution of the cross-domain trust decay protocol relies on real-time and reliable trust state synchronization between the trust sidechain and the ABAC main chain. This synchronization is handled by the cross-chain smart contract (CCSC). CCSC is installed on both the main chain and each trust sidechain. When a sidechain detects a change in a device's trust value... (Trigger threshold, default) When this occurs, cross-chain transmission is triggered, synchronizing the updated trust value, timestamp, device MAC address, and device status to the main chain. The main chain management node then decides whether to trigger the failure of the corresponding ABAC strategy.

[0191] Compared to traditional models, the cross-chain synchronization of GTAC in this invention introduces two optimizations. First, a differentiated triggering strategy: only when... Synchronization may be triggered when a trust level transition occurs, preventing a large number of cross-chain transactions from arising due to minor fluctuations. Secondly, a batch aggregation mechanism: within a time window... Internally, trust updates from multiple devices are packaged into a single cross-chain transmission, further reducing on-chain overhead while maintaining synchronization and timeliness.

[0192] The smart contract design of the present invention will be described in one of the following possible embodiments.

[0193] The GTAC of this invention extends the traditional model by deploying three core types of smart contracts: Zero-Trust ABAC Smart Contract (ZT-ABACSC), which introduces zero-trust RTS verification and fine-grained permission mapping on the basis of the original ABACSC, and is the core innovation of GTAC; Trusted Smart Contract (TSC), which adds linkage triggering logic with the RTS mechanism on the basis of the original framework; and Batch Aggregation Cross-Chain Smart Contract (BA-CCSC), which introduces differentiated triggering strategies and batch aggregation mechanisms on the basis of the original CCSC. All contracts push complex computational logic to off-chain (edge ​​layer) processing to minimize on-chain computational overhead.

[0194] 1) ABAC Smart Contracts

[0195] ZT-ABACSC is deployed on the main chain and is responsible for executing the five-step access verification process. It is the on-chain execution core of the GTAC zero-trust mechanism. The five-step verification uses short-circuit evaluation. If any step fails, a rejection response is immediately returned to avoid unnecessary calculations in subsequent steps. Figure 4 The algorithm 1 shown presents the complete ABACSC logic.

[0196] 2) Trusted Smart Contracts (TSC)

[0197] The Trust Controller (TSC) is deployed on the trust sidechain of the edge nodes, responsible for periodically calculating the trust value of IoT devices and providing the T_device input for step 4 of ABACSC. GTAC's TSC extends the SATI trust calculation framework, adding triggering logic linked to the RTS mechanism. The trust value update calculation is as follows:

[0198] ;

[0199] in, For the success rate of interaction; The normalized average service quality; Normalized interaction frequency; weighting coefficients satisfy Default value The success rate of communication has the highest contribution to device trustworthiness. To prevent frequent permission adjustments due to sudden changes in trust values, a time smoothing mechanism is introduced.

[0200]

[0201] in, To update the weights, the default is... When the calculation result satisfies When TSC calls CCSC, it triggers cross-chain synchronization; otherwise, it only updates the local ledger on the sidechain and does not generate cross-chain communication overhead.

[0202] 3) Cross-chain smart contracts

[0203] BA-CCSC is installed on both the main chain and each trusted side chain to achieve bidirectional trust state synchronization, which is the basis of the cross-domain trust decay protocol. Figure 5 The algorithm 2 presented demonstrates the core logic of CCSC, including two optimizations: differentiated triggering and batch aggregation.

[0204] The complete end-to-end workflow of GTAC in this invention includes three stages: system initialization, data storage and trust establishment, and access authorization and continuous monitoring. The system initialization stage completes network deployment and policy configuration; the storage stage ensures that only data from trusted devices enters the DDS through trust assessment using TSC; the authorization stage is completed collaboratively by RTS calculation, RRL routing, and ZT-ABACSC verification, with cross-domain requests additionally undergoing trust attenuation processing by BA-CCSC.

[0205] The present invention (GTAC) was compared with existing technologies (RBAC, Fabric-IoT, TABI, SATI) in multiple dimensions, which are described below.

[0206] 1) Comparison of access control latency and system throughput.

[0207] With the number of IoT devices increasing from 50 to 1000 and the transaction transmission rate fixed at 500 TPS, the GTAC of this invention exhibits the lowest average latency. When the number of devices reaches 1000, the GTAC latency is 168 ms, a reduction of 63.8% compared to Fabric-IoT (464 ms), 57.5% compared to TABI (334 ms), and 49.7% compared to SATI (334 ms). In terms of throughput, GTAC achieves a peak throughput of 690 TPS, exceeding Fabric-IoT (344 TPS), TABI (408 TPS), and SATI (503 TPS) by approximately 100.6%, 37.2%, and 37.2%, respectively. Experimental results show that GTAC's risk-adaptive three-layer hierarchical architecture offloads approximately 65% ​​of low-risk requests to the edge layer for local processing, significantly reducing the main chain load and thus achieving lower latency and higher throughput in large-scale IoT scenarios.

[0208] 2) Comparison of attack defense rate and false alarm rate.

[0209] GTAC outperformed all baseline solutions in defending against four threats: replay attacks, privilege escalation attacks, cross-domain spoofing attacks, and spoofing attacks. Specifically, GTAC achieved an 84% defense rate against spoofing attacks, compared to approximately 0% for RBAC, 36% for Fabric-IoT, 36% for TABI, and 40% for SATI, demonstrating a significant improvement. Regarding false positives, GTAC's false positive rate was only 2.1% in the spoofing attack scenario, far lower than SATI (17.3%) and TABI (20.6%). Experimental results confirm that GTAC's Zero Trust Request Trust Score (RTS) mechanism, through multi-dimensional behavioral evaluation of each request, effectively detects spoofing attacks initiated by devices with high historical trust, while avoiding false positives caused by single-dimensional anomalies.

[0210] 3) Dynamic permission response time and cross-domain access latency.

[0211] GTAC's dynamic permission response time remained stable at approximately 25 ms throughout, while SATI experienced a jump from nearly 0 ms to approximately 178 ms when the trust score crossed the threshold. GTAC's response time in the low trust range was reduced by approximately 85.9% compared to SATI. In cross-domain access scenarios with 1000 devices, GTAC's intra-domain latency was approximately 44 ms, and its cross-domain latency was approximately 216 ms, while SATI's unified processing latency was approximately 293 ms. GTAC's cross-domain latency was approximately 26.3% lower than SATI. Experimental results show that GTAC's RTS and permission continuity binding mechanism can adjust permissions in real time without on-chain transactions, while the cross-domain progressive trust decay protocol achieves multi-domain interoperability while ensuring security.

[0212] 4) Ablation experiments and parameter sensitivity analysis.

[0213] Ablation studies quantitatively analyzed the contributions of three core components: removing the three-layer hierarchical architecture (GTAC w / oLayered) increased latency to 560 ms (3.3 times that of full GTAC); removing the zero-trust RTS mechanism reduced the spoofing attack detection rate from 84% to 13%; and removing the cross-domain protocol resulted in direct rejection of cross-domain requests. Parameter sensitivity analysis showed that when the RTS weights were perturbed by ±0.1 around their default values ​​(w1=0.5, w2=0.3, w3=0.2), the detection rate decreased by no more than 7 percentage points, verifying the robustness of the parameter configuration. Based on all experimental results, the final conclusion is that compared to the state-of-the-art baseline SATI, GTAC reduces access control latency by 49.7%, increases peak throughput by 37.2%, improves spoofing attack defense rate by approximately 110%, and reduces false positive rate by approximately 87.9%, while maintaining comparable resource consumption to SATI. This simultaneously addresses the fundamental limitations of existing solutions in terms of security, scalability, and cross-domain interoperability.

[0214] It should be understood that the program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0215] The acquisition, storage, and application of user personal information involved in the technical solution of this invention all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0216] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this invention is not limited thereto.

[0217] The technical terms, principles, or means related to the technical solutions of the present invention mentioned in the above embodiments, which are not described in detail above, are all well-known technologies or common practices that are known to those skilled in the art.

[0218] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the present invention as claimed. The scope of protection of this invention is defined by the appended claims and their equivalents.

Claims

1. A zero-trust driven cross-domain dynamic access control method for the Internet of Things, characterized in that, This method is based on a system model consisting of three entity layers: an IoT device layer, an edge computing layer, and a blockchain layer; and the method includes the following steps: IoT devices at the IoT device layer send access requests to the edge computing layer of their respective management domains; The edge nodes of the edge computing layer receive the access request and, based on the zero trust principle, independently calculate the Request Trust Score (RTS) for each access request. The RTS integrates three dimensions: the device's historical trust value, the normality of the request context, and the normality of the request behavior. The edge node dynamically calculates the risk level RRL for each access request based on the request trust score (RTS) and the resource sensitivity of the accessed resource. The edge node routes access requests to the corresponding processing layer according to the risk level RRL, including routing low-risk requests to the edge computing layer for local access decision-making, routing medium-risk requests to the edge computing layer for decision-making and asynchronous on-chain recording, and routing high-risk requests and cross-domain requests to the blockchain layer for real-time verification and execution. For cross-domain access requests, the cross-chain smart contract deployed at the blockchain layer executes a cross-domain progressive trust establishment protocol, which maps the device trust value of the source domain to the effective trust value of the target domain through a trust decay function, and gradually adjusts the effective trust value based on the cross-domain interaction history. The ABAC smart contract deployed at the blockchain layer makes authorization decisions on access requests based on the five-tuple ABAC access control policy. The five-tuple includes subject attribute, resource identifier attribute, environment attribute, trust attribute, and permission attribute. The trust attribute includes the request trust score RTS and the preset minimum trust threshold, and is dynamically mapped to the corresponding multi-dimensional permission vector according to the request trust score RTS.

2. The zero-trust driven cross-domain dynamic access control method for the Internet of Things according to claim 1, characterized in that, The formula for calculating the Request Trust Score (RTS) is as follows: ； in, This is the device's historical trust value. To request the context score, To request a score for the behavior, The weighting coefficients and .

3. The zero-trust driven cross-domain dynamic access control method for the Internet of Things according to claim 2, characterized in that, The request context score The calculation formula is: ； in, This is the ratio of the current request frequency to the historical average frequency; a value greater than 1 indicates that the frequency is too high. To request timestamp normality measurement, This reflects the normality of the requested timestamp; This indicates taking the maximum value between the expression within the parentheses and 0; The request behavior score The calculation formula is: ； in, For resource type matching, For the normality of data volume, and The weighting coefficients and + =1; The current request frequency, historical average frequency, request timestamp, resource type matching degree, and data volume normality are all extracted by the edge node from the access requests received from the IoT device layer.

4. The zero-trust driven cross-domain dynamic access control method for the Internet of Things according to claim 2, characterized in that, The risk level RRL is calculated as follows: Edge nodes calculate a Request Trust Score (RTS) based on historical device trust values ​​obtained from sidechains and the context and behavioral characteristics of requests. The RTS is then combined with resource sensitivity to calculate a Request Risk Score. ； in, The sensitivity level of the accessed resource, This is the risk trade-off coefficient; The risk level is determined by the edge node according to the following rules: when A value less than 0.3 is considered low risk; a value less than or equal to 0.3 is considered low risk. A value less than 0.6 is considered medium risk. A value ≥ 0.6 is considered high risk; Furthermore, all cross-domain access requests are unconditionally classified as high-risk.

5. The zero-trust driven cross-domain dynamic access control method for the Internet of Things according to claim 1, characterized in that, The trust decay function is: ； ； in, This represents the trust value of the device in the source domain. The valid trust value of the device in the target domain. Based on the attenuation coefficient and 0 < ≤1, This represents the number of historical cross-domain interactions between the source and target domains. For familiarity function, It is a natural constant.

6. The zero-trust driven cross-domain dynamic access control method for the Internet of Things according to claim 1, characterized in that, The multidimensional permission vector includes read permission, write permission, execute permission, session validity period, maximum access frequency, and verification frequency. The request trust score (RTS) is divided into four trust levels: high trust (RTS ≥ 0.8), medium trust (0.6 ≤ RTS < 0.8), low trust (0.4 ≤ RTS < 0.6), and untrusted (RTS < 0.4). Each trust level is mapped to a different combination of multidimensional permission vectors. Permission mapping is executed by smart contracts deployed at the blockchain layer, and the mapping results are returned to the edge nodes as authorization decisions.

7. The zero-trust driven cross-domain dynamic access control method for the Internet of Things according to claim 1, characterized in that, The corresponding processing layer includes: The IoT device layer, composed of IoT devices, is used to initiate access requests and does not participate in the maintenance of the blockchain ledger. The edge computing layer, consisting of edge nodes deployed within each IoT management domain, performs trust assessments and localized processing of domain access requests, and periodically synchronizes the latest access control policies from the main chain. The blockchain layer, implemented based on the distributed ledger technology platform Hyperledger Fabric, is used to store and enforce ABAC access control policies, handle high-risk and cross-domain access requests, and record trust state update events. Routing decisions are made by edge nodes based on the risk level RRL.

8. The zero-trust driven cross-domain dynamic access control method for the Internet of Things according to claim 1, characterized in that, The method also includes a cross-chain trust state synchronization step, including: Differential triggering and batch aggregation synchronization are performed by the cross-chain smart contract BA-CCSC, which is deployed simultaneously on the blockchain main chain and the trusted side chain; Only when the device trust value changes Synchronization may be triggered when a trust level transition occurs, and within a preset time window. The trust updates of multiple devices are packaged into a single cross-chain transmission, in which The trigger threshold for changes in trust value; The initiator of the cross-chain smart contract BA-CCSC is the trust smart contract TSC deployed on the edge node trust sidechain, and the synchronization target is the blockchain main chain.

9. An electronic device, characterized in that, Includes one or more processors; Storage device for storing one or more programs; When one or more programs are executed by one or more processors, the one or more processors implement the zero-trust-driven cross-domain dynamic access control method for the Internet of Things as described in any one of claims 1-8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed, it implements the zero-trust-driven cross-domain dynamic access control method for the Internet of Things as described in any one of claims 1-8.

Images