A Zero-Trust Access Control Model Based on Attribute and Dynamic Trust Evaluation for Cloud Environments

Abstract

Attribute-Based Access Control (ABAC) has become the most suitable access control method for cloud environments due to its flexibility and fine-grained advantages. However, it suffers from issues such as insufficient dynamic adaptability and a lack of risk perception capabilities. The Zero Trust Architecture (ZTA) provides a new approach to addressing these problems through continuous trust evaluation, but its high dependence on the Policy Decision Point (PDP) component in the control plane introduces new security risks. To this end, this paper proposes a Zero-Trust Access Control Model based on Attributes and dynamic user Trust scores (AT-ZTAC). The model incorporates a trust evaluation module, which quantifies the user’s trustworthiness in real time through positive trust values and negative risk values, and dynamically integrates this quantification into access decisions to achieve fine-grained, dynamic, and secure authorization. In addition, to address the single-point trust risk of the PDP component, the model adopts a BLS-based threshold signature scheme to ensure the normal operation of the control plane even under limited intrusions, while supporting decision traceability. Theoretical analysis shows that this model significantly improves the overall security of the control plane. Experiments demonstrate that AT-ZTAC outperforms comparative models in terms of trust evaluation effectiveness, access decision throughput (reaching 1850 req/s, a 54% increase compared to traditional ABAC), and access control accuracy (reaching 96.8%). Compared with traditional solutions, it has advantages in flexibility, accuracy, and efficiency, demonstrating its potential for applications in cloud environments.

1. Introduction

Cloud computing has become a mainstream IT infrastructure due to its low cost, high performance, and high scalability, and is widely used in government services, finance, and enterprise digital businesses. However, inherent characteristics of cloud environments, such as resource virtualization and ambiguous service boundaries, pose severe challenges to traditional access control models in addressing dynamic access requirements and complex attacks [1]. According to IBM’s 2025 Cost of a Data Breach Report [2], cloud environments have become a major target for data breaches, with security incidents involving cloud data accounting for 85% of the total. Among these, misconfiguration and cloud credential leakage are the primary causes, accounting for 18% and 16% of all attack vectors, respectively. This highlights the urgent need for identity governance and dynamic access control mechanisms in cloud environments.

ABAC [3] is inherently suitable for the complexity and dynamism of cloud environments due to its fine-grained nature and flexibility. ABAC makes authorization decisions based on subject attributes (e.g., user role, department), object attributes (e.g., data sensitivity, resource type), environment attributes (e.g., time, location), and operation attributes. Compared to the Discretionary Access Control (DAC) model [4], Mandatory Access Control (MAC) model [5], or Role-Based Access Control (RBAC) model [6], ABAC better meets the dynamically changing access requirements of cloud environments.

Nevertheless, existing ABAC models applied in cloud environments still face the following key challenges [7,8,9]:

• Insufficient dynamic adaptability: Traditional ABAC models mainly rely on static or preconfigured attributes for one-time authorization decisions. Permissions are usually not adjusted dynamically after authorization, making it difficult to implement the principle of least privilege throughout the session and potentially leading to excessive permission retention.
• Lack of risk perception capabilities: Traditional models lack deep integration of real-time threat intelligence and user abnormal behaviors during deployment, limiting their ability to effectively identify and respond to malicious behaviors (e.g., malicious actions after user credential theft) or internal threats.

The Zero Trust Security Architecture [10], guided by the principle of “never trust, always verify”, emphasizes continuous authentication, trust evaluation, and dynamic authorization for all access requests, providing a new approach to cloud security. Theoretically, ZTA is highly compatible with ABAC, and the integration of ZTA can effectively address the aforementioned challenges. However, ZTA implicitly assumes absolute trust in the control plane; if the control plane is compromised, incorrect authorization decisions may occur, and the entire ZTA will no longer be secure [11,12].

To address these challenges, this study proposes a zero-trust access control model based on attributes and dynamic trust evaluation. The core innovations of this model are as follows:

• Deep integration of dynamic trust evaluation, ZTA, and the ABAC model: Contextual data (including real-time risk information) is collected through the Policy Information Point (PIP) and integrated into trust evaluation. Minimum authorization is implemented based on the trust level and attribute policies, enabling more fine-grained, flexible, and secure dynamic access control.
• Provision of traceable trusted proof for PDP cluster decision-making in ZTA: An m-of-n threshold signature scheme based on BLS signatures [12,13,14] is introduced into the PDP cluster decision-making process. This ensures that each critical authorization decision takes effect only after being jointly signed by multiple PDP nodes, effectively dispersing trust risks and improving the fault tolerance and accountability of decisions. Thus, the control plane is constructed as a verifiable plane that does not require absolute trust, significantly enhancing the security of the ZTA control plane itself.

2. Related Studies

As a core mechanism for ensuring the security of information systems, access control models have evolved from DAC and MAC to RBAC. However, in highly dynamic cloud environments with ambiguous boundaries, these models all exhibit significant limitations. The DAC model [4] delegates permission management to resource owners. Although it offers flexibility, it is difficult to implement unified security policies, leading to issues such as “permission creep” and inconsistent security policies. For example, the scheme proposed by Kumar et al. [15] retains the rigid security requirements of MAC to a certain extent but adopts DAC in the second stage, which still carries the risk of permission chain diffusion. This may lead to unauthorized access, and the diffusion path is difficult to trace, posing a direct threat to sensitive data. The MAC model [5] enforces access based on system-mandated security labels. While it provides high security guarantees, its policy configuration is extremely rigid, making it difficult to adapt to the frequently changing access requirements of cloud environments and complex multi-tenant scenarios. The model proposed by Nakamura et al. [16] suffers from insufficient dynamism and cannot be effectively adapted to cloud environments. The RBAC model [6] associates permissions with roles, simplifying permission management and finding applications in many scenarios [17]. However, in cloud environments, it faces problems such as “role explosion” and slow response to dynamic permission adjustments, making it difficult to meet the requirements of fine-grained, context-aware access control. Specifically, as the number of cloud platform projects, engineer-project combinations, and resources (e.g., buckets, database instances) increases, the number of roles that need to be created and maintained expands sharply. Meanwhile, permission changes usually require manual operations by administrators. In cloud environments with frequent project terminations and high personnel turnover, delays in manual permission revocation may lead to serious security risks.

In contrast, ABAC [3] makes dynamic decisions based on multi-dimensional attributes (subject, object, environment, and operation) and is theoretically well-suited for cloud environments. In recent years, many scholars have conducted extensive research on the optimization and application of ABAC models. For example, Yang [18] made important contributions to the management of Static Separation of Duty (SoD) in ABAC, providing the first general constraint verification and minimal intervention repair scheme. However, this model relies on static policy snapshots to verify SoD, does not consider dynamic changes in attributes, and the repair scheme only involves one-time policy adjustments, lacking an automatic permission revocation mechanism. Tall et al. [19] proposed a big data security framework based on ABAC by combining Apache Ranger (a distributed policy engine) and Atlas (metadata management). However, this framework requires manual triggering of Atlas label updates, and its policies are based on one-time authorization decisions, making it impossible to automatically shrink permissions and difficult to implement the principle of continuous least privilege. De Oliveira et al. [20] designed an Acute Care Attribute-Based Access Control (AC-ABAC) model for cross-institutional emergency scenarios to achieve fine-grained access control of Electronic Medical Records (EMRs). By introducing timestamp attributes to dynamically adjust permissions, the model improves dynamic adaptability. However, it lacks in-depth context awareness and integration of real-time risk analysis, making it unable to effectively respond to internal threats. Zhonghua et al. [21] optimized the application of traditional ABAC in the Internet of Things (IoT) environment by leveraging the immutability of blockchain and the automation of smart contracts, proposing the SC-ABAC model. However, permission adjustments in this model rely on post-event penalties rather than real-time risk perception and only assume static threats without addressing internal threats or abnormal behavior detection. Alohaly et al. [22] proposed an enhanced ABAC framework that detects internal threats by integrating network deception technology. However, the generation of honeypot attributes relies on offline genetic algorithms, making it impossible to adjust deception strategies in real time. Additionally, permissions cannot be dynamically downgraded after being granted, leading to the risk of permission retention. Chiquito et al. [23] proposed an integrated architecture of ABAC and Attribute-Based Encryption (ABE), which uses the graph policy model of Next-Generation Access Control (NGAC) to implement complex constraints. However, environment attributes (e.g., time/location) are only used for initial authorization, and the model lacks integration of real-time risks such as abnormal login detection. Shahraki et al. [24] proposed the D-ABAC model, which realizes cross-domain attribute verification through Attribute-Based Group Signatures (ABGS) and Zero-Knowledge Proofs (ZKPs), avoiding centralization risks. However, permissions are bound to attribute keys, and there is no continuous verification mechanism during sessions, making it difficult to implement the principle of continuous least privilege. The above analysis indicates that ABAC models still have shortcomings in addressing dynamic changes in user behavior and potential internal threats; relying solely on preconfigured attributes is insufficient to fully reflect the user’s real-time trust level and access intentions.

The dynamic trust-based access control model proposed by Wang et al. [25] can promptly reflect the user’s trust level and adjust permissions dynamically. Kesarwani et al. [26] proposed a machine learning trust model based on fuzzy logic, which dynamically calculates user trust values through machine learning methods to achieve more accurate access control. In the study by Chen et al. [27], direct trust values are obtained from the historical behaviors of cloud users, and recommended trust values are calculated based on interactions between users. Access permissions are adjusted based on the comprehensive trust value derived from these two values, realizing trust-based access control. However, in cloud environments, relying solely on a single trust model may make it difficult to clearly define permission boundaries, leading to users with high trust levels accessing unauthorized resources (e.g., a doctor with the same trust score accessing judicially sensitive data). Trust models embody the concepts of trust evaluation and dynamic authorization in ZTA. By combining ZTA with the ABAC model, the problems identified in related studies can be addressed. However, ZTA is highly dependent on the reliability and security of the PDP (a core component of the control plane). If the PDP is compromised, attackers can arbitrarily authorize unauthorized access, resulting in severe consequences [11]. Traditional schemes [12,28] usually assume that the PDP itself is absolutely trustworthy or only rely on single-point hardening, which poses high risks in actual complex cloud environments.

To address these issues, this study proposes a Zero-Trust Access Control Model based on Attributes and Dynamic Trust Evaluation (AT-ZTAC). The model deeply integrates the zero-trust framework with the ABAC model: after the PIP collects the user’s relevant attributes and contextual data, the trust evaluation module calculates the user’s trust level, which is then incorporated as a key attribute into the ABAC decision-making policy to achieve fine-grained, dynamic, and secure access control. Meanwhile, a BLS-based multi-signature scheme is applied to ensure that access decisions take effect only after being jointly endorsed by multiple PDP nodes, improving the system’s fault tolerance and traceability.

Table 1. Comparison of AT-ZTAC with Existing Access Control Models.

Model Category	Specific Schemes	Core Features of Category	Common Deficiencies of the Category	AT-ZTAC
DAC	[4,15]	Permissions are managed autonomously by resource owners; high flexibility.	High risk of permission chain diffusion; lack of centralized control; unsuitable for cloud environments.	Adopts centralized policy management (PAP + Policy Repository) to unify permission control and avoid permission diffusion.
MAC	[5,16]	Enforces access control based on mandatory security labels; high security.	Rigid policy configuration; difficult to adapt to dynamic environments.	Uses ABAC-based flexible attribute policies + dynamic trust evaluation to adapt to the dynamic needs of cloud environments.
RBAC	[6,17]	Associates users and permissions through roles; simple and convenient permission management.	“Role explosion” may occur in cloud environments; manual and delayed permission adjustments; insufficient fine-grained control; poor dynamic adaptability.	Fine-grained control via multi-dimensional attributes + dynamic trust level adjustment; no pre-defined roles required.
ABAC Model and Its Improved Models	[3,18,19,20,21,22,23,24]	Makes decisions based on multi-dimensional attributes; supports fine-grained control; some integrate optimization technologies (timestamps, blockchain, encryption, deception technologies) and are relatively suitable for dynamic scenarios.	Heavily relies on static attributes/policies, with insufficient session-level continuous verification; weak risk perception, difficult to respond to internal threats.	Real-time trust evaluation + session-level continuous verification; permissions dynamically adjusted with trust level; real-time quantification of threats via reverse risk values to quickly respond to internal threats.
Trust Evaluation Related Models	[25,26,27],	Dynamically calculates trust values to reflect the user’s real-time trustworthiness.	Lack of deep integration with ABAC; ambiguous permission boundaries; risk of unauthorized access.	Treats trust level as a key ABAC attribute; strong association between trust and permissions to clearly define authorization boundaries.
Zero-Trust Architecture Related Models	[12,28]	Assumes both internal and external networks are untrustworthy; relies on the control plane (e.g., PDP) for fine-grained access decisions; emphasizes trust evaluation and continuous verification.	High risk of single-point failure in the control plane (e.g., PDP compromise may lead to illegal authorization).	Uses BLS threshold signature (m-of-n) to disperse trust risks, supports decision traceability, and improves fault tolerance.
AT-ZTAC (Proposed in This Study)	-	Deeply integrates zero trust + ABAC + dynamic trust evaluation; BLS threshold signature ensures control plane security.	-	Simultaneously addresses three core issues: insufficient dynamic adaptability, weak risk perception, and single-point trust risk in the control plane.

compares AT-ZTAC with existing access control models.

3. Design of the AT-ZTAC Model

3.1. Access Control Model

The trust-based access control model (AT-ZTAC) proposed in this paper is shown in Figure 1. This model follows the NIST ZTA standard reference architecture and incorporates key enhancements. Its core idea is to treat the dynamically calculated real-time trust level as a key attribute for ABAC decision-making, thereby transforming static authorization into dynamic authorization linked to trust and permissions.

• The definitions of each element are described as follows:

  (1)

  Access Subject: A user who intends to access cloud services and initiates access control requests. The subject must carry multi-source identity identifiers (e.g., user account, device certificate), environment attributes (e.g., access IP ownership, network environment), and operation attributes (e.g., access time, operation type). This information serves as the basic input for trust evaluation.

  (2)

  Access Object: A collection of cloud resources to be accessed, including system data and executable instructions, and is the target of access requests. The object must be pre-labeled with object attributes such as data sensitivity level (public/internal/confidential), resource type (computing/storage/network), and access permission granularity (read/write/modify/delete). These attributes are linked to the subject’s trust level to determine the final authorization scope.

  (3)

  Trust Evaluation Module: A core component of ZTA that provides continuous trust evaluation for access subjects, object resources, and the system environment through a trust level evaluation algorithm. The resulting trust calculation serves as a key input for access control decisions.

  (4)

  Authentication Server (AS): A service responsible for verifying the authenticity of the access subject’s identity, which serves as the identity benchmark for subsequent trust calculations. It verifies user identity using technologies such as single sign-on (SSO), multi-factor authentication (MFA), biometric identification, and passwords, and verifies user device identity using technologies such as device certificates.

  (5)

  Policy Enforcement Point (PEP): Forwards access requests and enforces access control decisions (e.g., allow, deny, restricted access), while feeding back execution results to the PIP in real time.

  (6)

  Policy Decision Point (PDP): Makes access decisions based on contextual data, trust level, and current access policies. The identity of each PDP node is bound to a hardware root of trust (Trusted Platform Module, TPM).

  (7)

  Policy Administration Point (PAP): A center for creating, storing, distributing, and managing access control policies, which accepts inputs from policy administrators.

  (8)

  Policy Information Point (PIP): Continuously collects and aggregates all attribute information and contextual data related to access decisions from various parts of the system, including user attributes, resource attributes, environment attributes, and real-time behavior data (e.g., traffic, logs). It provides data services for the PDP and the trust evaluation module.

  (9)

  Policy Repository: A database that stores access control policy definitions. The access control policies herein are based not only on attribute information but also integrate trust level indicators. Policies are defined in accordance with the XACML [29] standard, and their core logic can be formally described as a four-tuple model that maps subject attributes, object attributes, environment attributes, and trust level thresholds to access permissions.

  (10)

  Policy Administrator (PA): A personnel with the authority to configure, modify, and manage access control policies in real time.

• The entire access control process is described as follows:

  (1)

  The access subject initiates a cloud resource access request to the AS.

  (2)

  The AS verifies the access subject’s identity using technologies such as SSO. Upon successful authentication, the AS generates a time-stamped identity credential, synchronizes the credential to the PEP and the trust evaluation module, and forwards the access request to the PEP.

  (3)

  The PEP receives the identity credential from the AS, verifies the timeliness and format validity of the credential, and filters out illegal requests with expired or malformed credentials. After initial verification, the PEP encapsulates the access request into a standardized JSON data packet and forwards it to the PDP via the gRPC protocol.

  (4)

  The PDP requests the PIP for attribute information (of the access subject, object, and system environment) and related contextual data, and simultaneously queries the trust evaluation module to obtain the subject’s current trust level.

  (5)

  The PIP collects and returns the contextual data required for access control decisions to the PDP, and continuously transmits the latest contextual data (e.g., access logs, traffic data) to the trust evaluation module.

  (6)

  Based on the data provided by the PIP, the trust evaluation module obtains the user’s trust level through access hot-spot caching or real-time calculation and returns the result to the PDP.

  (7)

  The PDP requests the PAP for a list of access control policies corresponding to the current trust level.

  (8)

  Based on the PDP’s request, the PAP retrieves and invokes relevant access control policies from the policy repository.

  (9)

  The PAP returns the retrieved set of access control policies to the PDP.

  (10)

  The PDP performs policy matching and policy determination based on the contextual data, access policy list, and trust level, returns the access decision result (signed jointly by the PDP cluster) to the PEP, and synchronizes the decision process log to the PIP for storage (for subsequent auditing).

  (11)

  The PEP enforces access control on the access object (e.g., allowing connections, blocking requests, restricting operation permissions) based on the decision result of the PDP cluster, and feeds back the execution result to the PIP.

Traditional trust models typically treat trust evaluation as a mandatory step before access decision-making, creating serial dependency. To address this issue, the trust evaluation module in this model adopts asynchronous computing and hot-spot caching mechanisms. Specifically, trust evaluation is no longer a mandatory pre-step of access decision-making but operates as a parallel background task continuously. This module asynchronously obtains the latest contextual data from the PIP and utilizes hot-spot caching to store recent evaluation results and intermediate calculation factors. In subsequent short-cycle calculations, only rapidly changing factors need updating, thereby providing accurate and efficient trust data support for the next access decision and significantly reducing access request response latency.

3.2. Trust Level Evaluation Algorithm

In the access control model proposed in this paper, the access subject’s trust level score is an important basis for access decisions. Contextual data is continuously collected and transmitted by the PIP, and the user’s real-time dynamic trust level is calculated using a trust level evaluation algorithm. As shown in Figure 2, the trust level is determined by both positive trust value and reverse risk value. Positive trust values include recommended trust value, device trust value, time-based trust value, and history-based trust value, which are used to evaluate the trustworthiness of entities. Negative risk values consist of abnormal traffic detection results and abnormal log detection results, which are used to evaluate negative indicators of the system and quantify potential risk factors of the system. Only by comprehensively considering trust and risk factors can trust evaluation be effectively conducted to further guide access control.

3.2.1. Calculation of Positive Trust Value

The positive trust value $T_{\mathrm{fwd}}$ is the weighted sum of the recommended trust value $T_{\mathrm{rec}}$, the device trust value $T_{\mathrm{eqp}}$, the time-based trust value $T_{\mathrm{time}}$, and the history-based trust value $T_{\mathrm{hist}}$, calculated using Formula (1).

$$T_{\mathrm{fwd}}={\lambda }_1\cdot T_{\mathrm{rec}}+{\lambda }_2\cdot T_{\mathrm{epq}}+{\lambda }_3\cdot T_{\mathrm{time}}+{\lambda }_4\cdot T_{\mathrm{hist}}$$

(1)

where ${\lambda }_1,{\lambda }_2,{\lambda }_3,{\lambda }_4$ are the corresponding weights, and ${\lambda }_1+{\lambda }_2+{\lambda }_3+{\lambda }_4=1$. $T_{\mathrm{rec}}$ represents identity trust values and social relationship data, $T_{\mathrm{eqp}}$ represents the security of the access terminal, $T_{\mathrm{time}}$ represents compliance with behavioral habits, and $T_{\mathrm{hist}}$ represents trust continuity (i.e., evaluation from four different dimensions: identity source, terminal status, behavioral habits, and historical performance), forming a multi-dimensional method for calculating positive trust values.

• Recommended trust value

When a user registers, the system requires the user to provide at least three referees who have registered in the system and have a certain trust level. The recommender gives the initial credit value of the recommended user, and the corresponding weight is related to the recommender’s trust level. The higher the trust level, the greater the corresponding weight. The recommended trust value $T_{\mathrm{rec}}$ is calculated using Formula (2).

$$T_{\mathrm{rec}}={\displaystyle \frac{{\displaystyle \sum _{i=1}^n{T}_i\cdot T_{{\mathrm{rec}}_i}}}{{\displaystyle \sum _{i=1}^n{T}_i}}}$$

(2)

Here, $n$ is the number of recommenders, $T_i$ is the trust level of each recommender, $T_{{\mathrm{rec}}_i}$ is the initial credit value of the recommended user given by the recommender.

2.

Device trust value

This factor focuses on the credibility of the login device itself and is calculated based on a weighted summation of multiple sub-factors. The calculation method for device trust value $T_{\mathrm{eqp}}$ is given by Formula (3).

$$T_{\mathrm{eqp}}=w_a\cdot I_a+w_b\cdot I_b+w_c\cdot I_c$$

(3)

Here, $I_a$ represents the device certificate identifier. It is 1 when the device has an effective and non-expired company certificate; otherwise, it is 0. $I_b$ represents the IP address reputation. If the login IP belongs to a reputable Internet Service Provider (ISP), it is 1; if it belongs to a known malicious or high-risk pool IP, it is 0; and the intermediate state is 0.5. $I_c$ represents the trust history. When the device has no risk history, it is 1; when it has a suspicious history, it is 0; and for a newly used device for the first time, it is 0.5. $w_a,w_b$ and $w_c$ are the weights of the corresponding three sub-factors, and they satisfy $w_a+w_b+w_c=1$.

3.

Time-based trust value

This factor assesses whether the access time conforms to the user’s normal behavior pattern. It is modeled using the Gaussian function, and the access-time-based trust value $T_{\mathrm{time}}$ is calculated by Formula (4).

$$T_{\mathrm{time}}=e^{-{\displaystyle \frac{{(t-\mu )}^2}{2{\sigma }^2}}}$$

(4)

Here, $t$ represents the current access time, $\mu$ represents the average time of the user’s most frequent access, $\sigma$ represents the standard deviation of the time distribution, which determines the tolerance for time deviations. All the units mentioned above are in hours. To prevent this value from being too low in special scenarios, such as emergency duty, it can be manually set in such cases.

4.

History-based trust value

To achieve a continuous assessment of user trust while avoiding undue influence from overly distant historical data on the current state, we introduce a sliding window mechanism. This mechanism only considers user behavior data from the most recent period (i.e., within the window). As time progresses, old data slides out of the window and new data slides in, ensuring the timeliness of the assessment. Furthermore, we add a time decay factor to give higher weight to newer data within the window, further optimizing assessment accuracy. The sliding window model is shown in Figure 3.

The history-based trust value $T_{\mathrm{hist}}$ is calculated by Formula (5).

$$T_{\mathrm{hist}}=\left\{\begin{array}{l}{T}_{\mathrm{rec}},\kappa =0\\ {\displaystyle \frac{{\displaystyle \sum _{i=1}^{\kappa }{T}_i\cdot {\alpha }_i}}{{\displaystyle \sum _{i=1}^{\kappa }{\alpha }_i}}},\kappa >\begin{array}{ccc}0& and& \kappa \end{array}<\mathrm{wid}\\ {\displaystyle \frac{{\displaystyle \sum _{i=\kappa -\mathrm{wid}+1}^{\kappa }{T}_i\cdot {\alpha }_i}}{{\displaystyle \sum _{i=\kappa -\mathrm{wid}+1}^{\kappa }{\alpha }_i}}},\kappa \ge \mathrm{wid}\end{array}\right.$$

(5)

Here, $\kappa$ represents the number of historical evaluation data $\mathrm{wid}$ represents the number of data in the window, and ${\alpha }_i$ is the attenuation window function.

Through the attenuation window function ${\alpha }_i$, we ensure the system can respond to both long-term trends and recent changes in user behavior, but with a higher weight given to recent behavior and a lower weight to older data. It is calculated using Formula (6).

$${\alpha }_i=e^{-{\displaystyle \frac{t_c-t_i}{{\mu }^{\prime }}}}$$

(6)

Here, $t_c$ represents the current time, $t_i$ represents the system time at the time of the $i-th$ request determination, and ${\mu }^{\prime }$ is a time adjustment factor.

3.2.2. Calculation of Reverse Risk Value

Network traffic and system logs record a large amount of network communication activities and system operation information, which contain rich behavioral patterns and anomaly signs. Analysis of network traffic can determine whether a network connection is malicious, while analysis of system logs can determine whether a behavior/operation is compliant. The combination of these two analyses can effectively address major risk scenarios in cloud environments, ensuring that threats—whether from outside the network or inside the system—can be effectively detected. This provides more comprehensive negative risk data for trust evaluation, thereby enabling dynamic adjustment and optimization of access control policies. That is, in this study, the reverse risk value $V_{\mathrm{REV}}$ is calculated by weighting the risk value based on anomaly traffic detection $V_{\mathrm{flow}}$ and the risk value based on anomaly log detection $V_{\log }$ using Formula (7).

$$V_{\mathrm{REV}}={\lambda }_{V_1}\cdot V_{\mathrm{flow}}+{\lambda }_{V_2}\cdot V_{\log }$$

(7)

Here, ${\lambda }_{V_1},{\lambda }_{V_2}$ represent the corresponding weights, and ${\lambda }_{V_1}+{\lambda }_{V_2}=1$.

• Risk value based on anomaly traffic detection

This metric measures the degree of anomaly in user access traffic, such as traffic spikes, malicious payloads, etc., calculated by sliding Windows and time decay using Formula (8).

$$V_{\mathrm{flow}}=\left\{\begin{array}{l}{\displaystyle \frac{{\displaystyle \sum _{i=1}^k{R}_{{\mathrm{flow}}_i}\cdot {\alpha }_{{\mathrm{flow}}_i}}}{{\displaystyle \sum _{i=1}^k{\alpha }_{{\mathrm{flow}}_i}}}},k>0\begin{array}{cc}\hspace{1em}and& k<{\mathrm{wid}}_{\mathrm{flow}}\end{array}\\ {\displaystyle \frac{{\displaystyle \sum _{i=k-{\mathrm{wid}}_{\mathrm{flow}}+1}^k{R}_{{\mathrm{flow}}_i}\cdot {\alpha }_{{\mathrm{flow}}_i}}}{{\displaystyle \sum _{i=k-{\mathrm{wid}}_{\mathrm{flow}}+1}^k{\alpha }_{{\mathrm{flow}}_i}}}},k\ge {\mathrm{wid}}_{\mathrm{flow}}\end{array}\right.$$

(8)

Here, $R_{{\mathrm{flow}}_i}$ represents the risk value of the $i-th$ flow detection, with a higher risk value corresponding to a closer proximity to 1, ${\alpha }_{{\mathrm{flow}}_i}$ represents the traffic risk time decay function, and ${\mathrm{wid}}_{\mathrm{flow}}$ indicates the sliding window size of the flow risk.

The traffic risk time decay function is calculated using Formula (9).

$${\alpha }_{{\mathrm{flow}}_i}=e^{-{\displaystyle \frac{t_c-t_i}{{\mu }_{\mathrm{flow}}}}}$$

(9)

Here, $t_c$ represents the current time, $t_i$ represents the system time at the time of the $i-th$ request determination, and ${\mu }_{\mathrm{flow}}$ is the traffic risk time adjustment factor.

2.

Risk value based on anomaly log detection

This metric measures risky behaviors in the user operation log, such as abnormal commands, attempts to get out of bounds, etc., calculated by sliding window and time decay using Formula (10).

$$V_{\log }=\left\{\begin{array}{l}{\displaystyle \frac{{\displaystyle \sum _{i=1}^k{R}_{{\log }_i}\cdot {\alpha }_{{\log }_i}}}{{\displaystyle \sum _{i=1}^k{\alpha }_{{\log }_i}}}},k>0\hspace{1em}\begin{array}{c}and\end{array}\hspace{1em}k<{\mathrm{wid}}_{\log }\\ {\displaystyle \frac{{\displaystyle \sum _{i=k-{\mathrm{wid}}_{\log }+1}^k{R}_{{\log }_i}\cdot {\alpha }_{{\log }_i}}}{{\displaystyle \sum _{i=k-{\mathrm{wid}}_{\log }+1}^k{\alpha }_{{\log }_i}}}},k\ge {\mathrm{wid}}_{\log }\end{array}\right.$$

(10)

Here, $R_{{\log }_i}$ represents the risk value of the $i-th$ log detection, with a higher risk value corresponding to a closer proximity to 1, ${\alpha }_{{\log }_i}$ represents the log risk time decay function, and ${\mathrm{wid}}_{\mathrm{flow}}$ indicates the sliding window size of the log risk.

The log risk time decay function is calculated using Formula (11).

$${\alpha }_{{\log }_i}=e^{-{\displaystyle \frac{t_c-t_i}{{\mu }_{\log }}}}$$

(11)

Here, $t_c$ represents the current time, $t_i$ represents the system time at the time of the $i-th$ request determination, and ${\mu }_{\log }$ is the log risk time adjustment factor.

This study focuses on constructing a dynamic trust evaluation framework that integrates these risk indicators, rather than designing new detection algorithms. The values of $R_{{\mathrm{flow}}_i}$ and $R_{{\log }_i}$ in the negative risk value can be obtained by integrating existing mature abnormal traffic and abnormal log detection schemes. In a specific implementation, it is only necessary to normalize the output of the selected detection scheme to a risk value in the [0, 1] interval.

3.2.3. Trust Level Calculation

Trust level is an important basis for PDP to make access decisions, derived from the combined positive trust value and reverse risk value mentioned above. To ensure that high-risk events significantly and reasonably reduce the trust level, a multiplicative model is used for calculation. The method is as shown in Formula (12).

$$T=T_{\mathrm{fwd}}\cdot (1-V_{\mathrm{REV}})$$

(12)

Here, $(1-V_{\mathrm{REV}})$ as the trust discount factor, when the reverse risk value is 0, the trust level is equal to the positive trust value, and when the reverse risk value is 1, the trust level is 0, regardless of the user’s positive trust value.

3.2.4. Weighting Determination Method-Combined Weighting Method

The above-mentioned scheme involves multiple weight distribution issues. To reasonably determine the weights of each factor, the combined weighting method was adopted in the study. The method first uses the AHP method [30] to determine the subjective weights based on the experience of security experts, then uses the entropy weight method [31] to determine the objective weights based on the actual data distribution, and finally combines the two, considering both domain knowledge and respecting the characteristics of the data itself, to achieve a more scientific and reasonable weight distribution.

• Subjective weights are determined by the AHP method

AHP combines quantitative analysis with qualitative analysis. The main idea is to build a judgment matrix by comparing the importance of each pair of factors, then calculate the maximum eigenvalue of the judgment matrix and the corresponding eigenvector and unite them to obtain the corresponding weight.

First, pairwise comparisons of the importance of the indicators are made, and qualitative language is converted into quantitative values through the 1–9 basic scale method, as shown in

Table 2. 1–9 Basic Scaling Method.

Scales	Definition
1	Both factors are equally important
3	One factor is slightly more important than the other
5	One factor is significantly more important than the other
7	One factor is strongly more important than the other
9	One factor is extremely more important than the other
2, 4, 6, 8	The median between the adjacent judgments mentioned above
Reciprocal	If the comparison value between factor i and factor j is $a_{ij}$, then the comparison value of factor j with factor i $\mathrm{is}{a}_{ji}=1/a_{ij}$

.

The decision factor judgment matrix A can be obtained with the help of Table 2.

$$A={(a_{ij})}_{n\times n}=\left(\begin{array}{cccc}{a}_{11}& a_{12}& \cdots & a_{1n}\\ a_{21}& a_{22}& \cdots & a_{2n}\\ ⋮& ⋮& \ddots & ⋮\\ a_{n1}& a_{n2}& \cdots & a_{nn}\end{array}\right)$$

(13)

Here, $a_{ij}$ represents the importance scale of factor $C_i$ relative to factor $C_j$.

Calculate the maximum eigenvalue ${\lambda }_{\max }$ of the above judgment matrix and obtain the characteristic Equation (14).

$$AW={\lambda }_{\max }W$$

(14)

The eigenvector $W={(w_1,w_2,\cdots ,w_n)}^T$ is obtained through the solution. The vector $W$ is normalized, which results in the weights of each element.

However, in practice, solving for $W$ is often very difficult. Therefore, an approximate calculation method is adopted, as shown in Formula (15).

$$w_i={\displaystyle \frac{1}{2}}\cdot ({\displaystyle \frac{{({\displaystyle \prod _{j=1}^n{a}_{ij}})}^{\frac{1}{n}}}{{\displaystyle \sum _{i=1}^n{({\displaystyle \prod _{j=1}^n{a}_{ij}})}^{\frac{1}{n}}}}}+{\displaystyle \frac{1}{n}}\cdot {\displaystyle \sum _{j=1}^n\frac{a_{ij}}{{\displaystyle \sum _{k=1}^n{a}_{kj}}}})$$

(15)

The values of $w_i$ obtained through the solution are the weights of each element.

Since the judgment matrix is given subjectively, there may be logical inconsistencies. Therefore, the degree of consistency must be tested, and the test steps are as follows.

(1)

Calculate the consistency index $\mathrm{CI}$, where $\mathrm{CI}={\displaystyle \frac{{\lambda }_{\max }-n}{n-1}}$.

(2)

Find the corresponding average random consistency index $\mathrm{RI}$.

Table 3. Average Random Consistency Indicator RI (Part).

n	1	2	3	4	5	6	7	8	9	10
RI	0	0	0.52	0.89	1.12	1.26	1.36	1.41	1.46	1.49

lists some of the $\mathrm{RI}$ values corresponding to n.

(3)

Calculate the consistency ratio $\mathrm{CR}$, $\mathrm{CR}={\displaystyle \frac{\mathrm{CI}}{\mathrm{RI}}}$. When $\mathrm{CR}<0.1$, it is considered that the consistency of the judgment matrix is acceptable; otherwise, the judgment matrix needs to be manually adjusted until $\mathrm{CR}<0.1$.

2.

Determine the objective weights using the entropy weight method

Entropy weighting is an objective weighting method that relies solely on the discreteness of the data itself. The stronger the discreteness, the greater the decision contribution of the indicator and the higher the weight.

For $n$ samples and $m$ evaluation elements, $x_{ij}^{\prime }$ represents the value of the $p-th$ element of the $q-th$ sample.

Normalize the data first, and for the positive element, calculate using Formula (16).

$$x_{qp}={\displaystyle \frac{x_{qp}^{\prime }-\min \{x_{1p}^{\prime },x_{2p}^{\prime },\cdots ,x_{np}^{\prime }\}}{\max \{x_{1p}^{\prime },x_{2p}^{\prime },\cdots ,x_{np}^{\prime }\}-\min \{x_{1p}^{\prime },x_{2p}^{\prime },\cdots ,x_{np}^{\prime }\}}}$$

(16)

The calculation method for negative elements is Formula (17).

$$x_{qp}={\displaystyle \frac{\max \{x_{1p}^{\prime },x_{2p}^{\prime },\cdots ,x_{np}^{\prime }\}-x_{qp}^{\prime }}{\max \{x_{1p}^{\prime },x_{2p}^{\prime },\cdots ,x_{np}^{\prime }\}-\min \{x_{1p}^{\prime },x_{2p}^{\prime },\cdots ,x_{np}^{\prime }\}}}$$

(17)

Calculate the entropy value of the $p-th$ element:

$$e_p=-k{\displaystyle \sum _{q=1}^n\frac{x_{qp}}{{\displaystyle \sum _{q=1}^n{x}_{qp}}}}\ln ({\displaystyle \frac{x_{qp}}{{\displaystyle \sum _{q=1}^n{x}_{qp}}}}),q=1,\cdots ,n,\hspace{1em}p=1,\cdots ,m$$

(18)

Here, $k={\displaystyle \frac{1}{\ln (n)}}>0,e_p\ge 0$.

Calculating information entropy redundancy:

$$d_p=1-e_p,p=1,\cdots ,m$$

(19)

Then the calculation methods for the weights of each element are shown in Formula (20).

$$w_p={\displaystyle \frac{d_p}{{\displaystyle \sum _{p=1}^m{d}_p}}},p=1,\cdots ,m$$

(20)

The final combined weight w is calculated as shown in Formula (21).

$$w=\theta \cdot w_i+(1-\theta )w_p$$

(21)

To achieve the highest degree of discrimination, the $\theta$ value that maximizes the variance of the final score is usually selected as the optimal ratio. However, $\theta$ can also be constrained as needed to ensure the subjective weights, such as $\theta >0.3$.

3.3. PDP Cluster Decision Co-Endorsement Scheme

In the zero-trust architecture, the PDP is the core component of access control, and its security directly determines the security of the entire system. The security enhancement of the PDP cluster in our scheme fundamentally relies on the algebraic property of symmetry, as realized through bilinear pairings in cryptography. Traditional single-PDP architectures suffer from an asymmetry in trust: the PDP is unconditionally trusted to make correct decisions, while other components are not. This creates a critical security vulnerability. Our model introduces symmetry by distributing the trust and decision-making power across multiple PDP nodes. The core enabler of this symmetrical design is the BLS signature scheme and its utilization of a bilinear map.

3.3.1. Foundation of BLS Signatures

Based on the discrete logarithm problem, BLS signatures define a bilinear mapping function e in three cyclic groups (G1, G2, G3) of order p:

$$e:\mathrm{G}1\times \mathrm{G}2\to \mathrm{G}3$$

(22)

The bilinear mapping function e must satisfy:

$$\left\{\begin{array}{l}e(P,Q+C_2)=e(P,Q)\times e(P,C_2)\\ e(P+C_1,Q)=e(P,Q)\times e(C_1,Q)\\ e(a\times P,b\times Q)=e{(P,Q)}^{a\times b}=e(a\times Q,b\times P)\end{array}\right.$$

(23)

Here, $P,C_1$ represents any element of group G1, $Q,C_2$ represents any element of group G2, and $a,b$ represents any integer.

The symmetry shown in Equation (23) is crucial. It allows any verifier to check the validity of a signature aggregated from m of n signers using a single, constant-time pairing operation, without needing to know the individual signers or their signatures. This computational symmetry is precisely what makes our threshold scheme both efficient and suitable for high-throughput cloud environments. Therefore, the concept of symmetry transitions from a cryptographic primitive to an architectural principle, ensuring a balance between security, decentralization, and performance.

3.3.2. Scheme Implementation

Standard BLS aggregate signatures do not distinguish between signers. To enable traceability of data signatures—i.e., to accurately identify the signatory proxy nodes for rapid localization and replacement in case of dishonest proxy nodes—the signer ID corresponding to the proxy node is introduced in this paper. The specific signature method is as follows:

In the PDP cluster, there are n policy signatories, denoted as set $A=\{1,2,\cdots ,n\}$. Each signatory $i(i\in (1,n))$ holds the private key $s{k}_i$ and the public key $p{k}_i=s{k}_i\times g$, and $g$ is the generator of the cyclic group. The scheme employs the digital hash function h(x) and the curve hash function H(x), and sets the threshold value m, meaning that at least m signatories are required to sign the decision result for it to be valid.

The aggregated public key PK is:

$$\mathrm{PK}=a_1\times {\mathrm{pk}}_1+a_2\times {\mathrm{pk}}_2+\cdots +a_n\times {\mathrm{pk}}_n$$

(24)

where $a_1,a_2,\cdots ,a_n$ is the corresponding coefficient, determined by the following formula:

$$a_i=h({\mathrm{pk}}_i,\left\{{\mathrm{pk}}_1,{\mathrm{pk}}_2,\cdots ,{\mathrm{pk}}_n\right\})$$

(25)

The unique $M{K}_i$ for each signer is generated using Formula (26):

$${\mathrm{MK}}_i=(a_1\times {\mathrm{sk}}_1)\times H(\mathrm{PK},i)+(a_2\times {\mathrm{sk}}_2)\times H(\mathrm{PK},i)+\cdots +(a_n\times {\mathrm{sk}}_n)\times H(\mathrm{PK},i)$$

(26)

The message $H(\mathrm{PK},i)$ contains the aggregate public key PK and ID information i, i.e., ${\mathrm{MK}}_i$ represents a valid signature of all signers on message $H(\mathrm{PK},i)$. In this case, Formula (27) holds:

$$e(g,{\mathrm{MK}}_i)=e(\mathrm{PK},H(\mathrm{PK},i))$$

(27)

Suppose that k signatories have successfully signed decision l. For ease of expression, let us denote this set as $B,B\in A$ where each individual signatory $j$ corresponds to the signature $S_j$ This is referred to as a member signature:

$$S_j=s{k}_j\times H(PK,l)+M{K}_j$$

(28)

By summing the above member signatures, the multi-signature (signature of the set of signers who signed decision l) $S^{\ast }$ and the corresponding set public key $P^{\ast }$ of the signers are obtained. The calculation is shown in Formula (29):

$$(S^{\ast },P^{\ast })=({\displaystyle \sum _{j\in B}{S}_j,{\displaystyle \sum _{j\in B}{P}_j}})$$

(29)

3.3.3. Scheme Verification

The verifier has knowledge of the message l, aggregate signature $S^{\ast }$, set public key of the signers $P^{\ast }$, aggregate public key PK, and the IDs of the signers in the signer set. The verification is performed as follows:

$$e(g,S^{\ast })=e(P^{\ast },H(PK,l)\times e(PK,{\displaystyle \sum _{j\in B}H(PK,j)}))$$

(30)

If the equation holds, the subscripts corresponding to set A can be used to prove which k signers signed the decision. This is because:

$$\begin{array}{l}e(g,S^{\ast })\\ =e(g,{\displaystyle \sum _{j\in B}{S}_j})\\ =e(g,{\displaystyle \sum _{j\in B}{\mathrm{sk}}_j\times H(\mathrm{PK},l)}+{\displaystyle \sum _{j\in B}{\mathrm{MK}}_j})\\ =e(g,{\displaystyle \sum _{j\in B}{\mathrm{sk}}_j\times H(\mathrm{PK},l)})\times e(g_2,{\displaystyle \sum _{j\in B}{\mathrm{MK}}_j})\\ =e({\displaystyle \sum _{j\in B}{\mathrm{sk}}_j\times g},H(\mathrm{PK},l))\times e(\mathrm{PK},{\displaystyle \sum _{j\in B}H(\mathrm{PK},j)})\\ =e(P^{\ast },H(\mathrm{PK},l))\times e(\mathrm{PK},{\displaystyle \sum _{j\in B}H(\mathrm{PK},j)})\end{array}$$

Therefore, through the above BLS signature scheme with signer IDs, it is possible to determine which proxy nodes signed each piece of data and whether the number of signers meets the $m-of-n$ signature requirement (k > m). This achieves the goal of ensuring the security of each piece of data by accumulating signatures from a majority of PDP policy signers.

4. Safety Analysis

AT-ZTAC, through multi-dimensional design, fully covers the core security requirements of zero-trust access control in cloud environments:

Control Plane Security: BLS threshold signature for fault tolerance against the risk of a single point of failure in PDP clusters.

Dynamic risk defense: Dynamic trust assessment responds in real-time to internal threats and identity theft.

Dynamic privilege control: The binding of permissions to the trust level, combined with session-level continuous verification, collectively achieves the principle of least privilege.

Resilience: ECDLP Difficulty and TPM binding against forgery and Sybil attacks;

Accountability: Node number binding supports anomaly tracing.

The following is a systematic analysis of its security in combination with model design details and cryptographic security assumptions.

4.1. Control Plane Security

The core security vulnerability of the zero-trust architecture lies in its assumption of absolute trust towards the control plane (especially the PDP). Once the authorization decision made by the PDP is forged, the entire access control system will fail. Therefore, AT-ZTAC adopts a $m-of-n$ threshold signature scheme based on BLS, converting the decision into a collective decision endorsed by the PDP cluster. Its security relies on the following design:

• Threshold fault-tolerance mechanism

Suppose the PDP cluster consists of n signing nodes and the threshold value is m, meaning that the decision can only take effect when at least m nodes sign it. If an attacker takes control of $k(k<m)$ nodes, since they cannot forge the private key signatures of the remaining $m-k$ honest nodes, the generated false decision will fail to pass the verification, and the system can still operate normally. Moreover, compared with the $n-of-n$ scheme that requires signatures from all nodes, this scheme can avoid the situation where the attacker controls a small number of nodes to refuse signatures and thereby hinder the normal decision-making process. This design is significantly superior to the traditional single PDP scheme and other $n-of-n$ schemes in terms of fault tolerance and availability.

2.

BLS Signature’s Cryptographic Security Foundation

The security of the BLS signature is based on the computational difficulty of the Elliptic Curve Discrete Logarithm Problem (ECDLP): in a cyclic group G1 of order $p$, given the base point $g$ and the point $y=x\cdot g$ (where x is the private key), it is impossible to solve for x within polynomial time. In the model, the private key $s{k}_i$ of each PDP node is randomly generated, and the public key $p{k}_i=s{k}_i\times g$ is used. The verification of the aggregated signature relies on the bilinear mapping $e(g,S^{\ast })=e(P^{\ast },H(PK,l)\times e(PK,{\displaystyle \sum _{j\in B}H(PK,j)}))$. If an attacker attempts to forge a signature, they need to crack the ECDLP to obtain the node’s private key or construct a false signature that satisfies the bilinear mapping. However, this is not feasible under the computational security assumption (i.e., the attacker’s computing power is limited).

4.2. Dynamic Risk Defense

Traditional ABAC models rely on static attribute authorization and are unable to deal with risks such as stolen credentials or unauthorized access by internal users to sensitive data. The dynamic trust assessment module of AT-ZTAC achieves real-time risk response through multi-dimensional trust and risk quantification, with specific security guarantees as follows:

• Anti-circumvention of multi-source trust factors

Positive trust value builds a user’s trusted profile from four dimensions: identity security, device security, behavioral habits, and historical records, and a single dimension cannot be easily tampered with.

2.

Real-time detection capabilities for reverse risks

Reverse risk value, through sliding Windows and time decay mechanisms, can capture sudden changes in user behavior in real-time through abnormal traffic detection and abnormal log detection, such as high-frequency scanning, oversized payload transmission, permission out-of-bounds attempts, deletion of audit logs, and other malicious behaviors. Setting a corresponding risk value for malicious behavior can dynamically adjust the final trust level and achieve real-time wind direction response.

4.3. Dynamic Permission Control

The zero-trust “continuous minimum privilege” principle is difficult to implement in traditional ABAC because static authorization cannot be dynamically adjusted according to the user’s trusted status. In addition, traditional ABAC can lead to policy conflicts and inconsistencies as systems grow in size and complexity. AT-ZTAC achieves real-time contraction and expansion of permissions by binding access rights to a dynamic trust level, and constraining possible policy conflicts to trust level intervals, and its security is reflected in:

• Strong association between permissions and trust level

The scheme divides trust level into multiple consecutive intervals, each of which maps to a different set of permissions, so the range of permissions granted automatically adjusts with the change in trust level, not only achieving dynamic management of permissions, but also effectively limiting the range of policy conflicts and improving the policy consistency of the system.

2.

Session-level continuous validation

Traditional ABacs typically perform one-time validation of attributes at the initial stage of access and do not re-evaluate them during the session. The AT-ZTAC’s PDP periodically reacquires user context data via PIP during session duration, invokes the trust evaluation module to update the trust level, and synchronously adjusts permissions. For example, when a batch of data downloads is suddenly initiated during a user session, the reverse risk value rises, the trust level drops, and the PDP adjusts permissions based on the latest policy without waiting for the session to end.

4.4. Resistance to Attacks

In response to common attack methods in the cloud environment such as “signature forgery” and “sycophant attack” (where attackers forge the identities of multiple PDP nodes), AT-ZTAC forms a defense through cryptographic mechanisms and architecture design:

• Resistant to signature forgery

To forge a valid aggregated signature $S^{\ast }={\displaystyle \sum _{j\in B}{S}_j}$, the attacker must at least be able to forge the member signature of a legitimate node; otherwise, it cannot pass the verification of $e(g,S^{\ast })=e(P^{\ast },H(PK,l)\times e(PK,{\displaystyle \sum _{j\in B}H(PK,j)}))$. If the attacker attempts to forge the member signature $S_j=s{k}_j\times H(PK,l)+M{K}_j$ of a certain legitimate node, then at least they need to solve $s{k}_j$ (given $p{k}_j$), which is the ECDLP difficult problem and is not feasible under the computational security assumption.

2.

Resistance to Sybil attacks

The core of a Sybil attack is to forge multiple node identities to meet the threshold m. In AT-ZTAC, the identity of each PDP node is bound through the TPM, and when a node joins the cluster, it has to submit the device certificate generated by the TPM, which is verified by the AS for legitimacy. Attackers cannot forge TPM certificates and thus cannot create fake PDP nodes, ensuring that all n nodes in the cluster are real and authenticated entities, effectively defending against Sybil attacks at the system architecture level.

4.5. Accountability

AT-ZTAC enables full traceability of decisions through the “node number binding” design of BLS signatures:

The node number is bound to the signature by Equations (25) and (26), so the aggregated signature is generated with the corresponding node number and the corresponding aggregated public key. When an abnormal decision is detected, the corresponding node number i can be obtained by combining the corresponding aggregated public key and the personal public keys held by all members (only the correct permutation and combination can generate a matching aggregated public key), thereby achieving the purpose of holding the signer accountable who signed the abnormal decision.

4.6. Formalize Security Verification

To further validate model security, formal security verification of the security of the BLS scheme used in the control plane of AT-ZTAC:

Definition 1. 

Multi-signature security: In a game, if an attacker with the maximum attack resources is still unable to complete the minimum attack target task, then the BLS multi-signature scheme is considered secure.

Definition 2. 

Breaking BLS multi-signature: In the random oracle model, for a security parameter$1^k$, there is a set of n signers  $\left\{ M_1,M_2,\cdots ,M_n\right\}$. The attacker A can control k of these signers. The internal attacker A can adaptively choose adaptive messages at will. Within polynomial time t, the challenger C can initiate at most$q_h$ Hash inquiries and$q_s$ signature queries. If the attacker A can win the above game with a probability of $\epsilon$, then it is said that the attacker A can break the BLS multi-signature scheme with $((n,k),q_h,q_s,\epsilon )$. Otherwise, it is said that the BLS multi-signature scheme has unforgeability under the adaptive message selection attack of the internal attacker A in $((n,k),q_h,q_s,\epsilon )$, and is considered to be EUF-CMA secure.

Theorem 1. 

The lightweight aggregated signature BLS scheme is secure under the adaptive message attack aaa by the internal attacker A.

Proof of Theorem 1. 

Assume that attacker A has the largest attack resources and can control $k=m-1$ internal signers. Then, based on the structure of the signature scheme (29), attacker A can create a collective signature of $m-1$ signers and verify it through Equation (30). To achieve the minimum attack goal, the attacker must be able to successfully forge the individual signature of any signer, that is, the member signature $S_i$, as indicated by Equation (28). It is assumed that the attacker wants to forge the member signatures $S_1,S_1={\mathrm{sk}}_1\times H(\mathrm{PK},l)+{\mathrm{MK}}_1$ of the honest signer $M_1$. Since the attacker has the largest attack resources, it is assumed that ${\mathrm{sk}}_i$ and ${\mathrm{MK}}_i$ can be obtained through signature queries. The signatures of all other signers can be obtained through signature queries. The generator of the cyclic group is $g$. The security of this BLS scheme can be reduced to the ECDLP. □

Let H be a random oracle, and if $\mathrm{G}1\times \mathrm{G}2$ is a gap group and $H:{\left\{0,1\right\}}^{\ast }\to \mathrm{G}1$ is a universal hash function, then the lightweight aggregate signature BLS scheme is EUF-CMA secure.

Specifically, suppose there exists an EUF-CMA adversary A that breaks the lightweight aggregate signature BLS scheme with a $\epsilon$ advantage. A can make at most $q_h$ queries to H and at most $q_s$ queries to the signature, then there must exist a challenger C that solves the ECDLP at least with a ${\mathrm{Adv}}_C^{\mathrm{ECDLP}}\ge {\displaystyle \frac{\epsilon }{e{q}_h}}$ advantage, where e is a natural constant.

①

Initialization

Challenger C runs the initialization algorithm, generating three p-factorial cyclic groups G1, G2, and G3, as well as a bilinear mapping function $e:\mathrm{G}1\times \mathrm{G}2\to \mathrm{G}3$. Then, the generated system parameters $\mathrm{parm}=\left\{\mathrm{G}1,\mathrm{G}2,\mathrm{G}3,e,g,p,H\right\}$ are sent to the attacker A.

②

Signature query-response

Extracting private key query: Challenger C records the private key values of each signer in the list $L_1$. The attacker A inputs the signer $M_i$. If $M_i\ne M_1$, then C randomly selects the private key ${\mathrm{sk}}_i\leftarrow Z_q^{\ast }$, calculates the public key ${\mathrm{pk}}_i={\mathrm{sk}}_i\times g$, and then records $(M_i,{\mathrm{sk}}_i,{\mathrm{pk}}_i)$ to the list $L_1$, and returns ${\mathrm{sk}}_i$ to A. If $M_i=M_1$, then C sets ${\mathrm{pk}}_1=b\times g$ and records $(M_i,\hspace{1em},{\mathrm{pk}}_i)$ to the list $L_1$, and returns an empty value to A.

H query: Challenger C uses the list $L_2$ to record the query values. The attacker A inputs the information $l_i$. Challenger C randomly selects $j{\to }_R\left\{1,2,\cdots ,q_h\right\}$. If $i=j$, return $H(\mathrm{PK},l_i)=a\times g$. If $i\ne j$, then C queries the list $L_2$, if there is a corresponding record $(l_i,g,H(\mathrm{PK},l_i))$, then return $H(\mathrm{PK},l_i)$ to the attacker A; otherwise, C randomly selects $c_i\leftarrow Z_q^{\ast }$, calculates $H(\mathrm{PK},l_i)=c\times g$, and then records $(l_i,g,H(\mathrm{PK},l_i))$ to the list $L_2$, and returns $H(\mathrm{PK},l_i)$ to the attacker A.

Querying the aggregated public key and numbered signature $({\mathrm{MK}}_i,\mathrm{PK},M_i)$: Challenger C uses the list $L_3$ to record the signature results of each signer for the aggregated public key and numbered signature. The attacker A inputs the signer $M_i$ and the aggregated public key PK, queries the signature of signer $M_i$ for the aggregated public key and the numbered. If there is a corresponding record $({\mathrm{MK}}_i,\mathrm{PK},M_i)$, then return ${\mathrm{MK}}_i$ to the attacker A; if there is no corresponding record, then C randomly selects ${\mathrm{MK}}_i$, which satisfies $e\left(g,{\mathrm{MK}}_i\right)=e\left(\mathrm{PK},H\left(\mathrm{PK},i\right)\right)$, and then records $({\mathrm{MK}}_i,\mathrm{PK},M_i)$ to the list $L_3$, and returns ${\mathrm{MK}}_i$ to the attacker A.

Member signature $(M_i,l_i,{\mathrm{MK}}_i,S_i)$ query: Challenger C uses the list $L_4$ to record the member signature results of user $M_i$. The attacker A inputs user $M_i$, information $l_i$, and the numbered signature ${\mathrm{MK}}_i$, queries $(M_i,{\mathrm{MK}}_i,S_i)$ for the signature of information $l_i$. When $M_i\ne M_1$, C queries the $(M_i,{\mathrm{sk}}_i,{\mathrm{pk}}_i)$ in the $L_1$ table, the $(l_i,g,H(\mathrm{PK},l_i))$ in the $L_2$ table, and the $({\mathrm{MK}}_i,\mathrm{PK},M_i)$ in the $L_3$ table to calculate the member $M_i$ for the message $l_i$ and the member signature $S_i={\mathrm{sk}}_i\times H(\mathrm{PK},l_i)+{\mathrm{MK}}_i$, and returns $S_i$ to the attacker A. When $M_i=M_1$, exit the member signature query and return failure.

③

Output signature (forged signature)

For the signature set $\left\{M_1,M_2,\cdots ,M_n\right\}$, the information $l^{\ast }$, attacker A outputs a forged multiple signature result $S^{\ast }$. If the above inquiry process does not terminate, user $M_1$’s private key has not been submitted to the private key query list, and $S^{\ast }$ has not undergone partial signature inquiry, and the multiple signature result $S^{\ast }$ is valid. Then attacker A wins in the game, that is, $l^{\ast }$ and $S^{\ast }$ satisfy Equation (31):

$$e\left(g,S^{\ast }\right)=e\left(P^{\ast },H\left(\mathrm{PK},l^{\ast }\right)\right)\times e\left(\mathrm{PK},H\left(\mathrm{PK},1\right)+H\left(\mathrm{PK},2\right)+\cdots +H\left(\mathrm{PK},j\right)\right)$$

(31)

Then, the challenger C can calculate the partial signature result $S_1$ of $M_1$ by querying the records in the list $L_4$ and the valid multiple signature result $S^{\ast }$ of the attacker A, as shown in Formula (32):

$$S_1=S^{\ast }-{\displaystyle {\sum }_{i\ne 1}{S}_i}$$

(32)

It is also known from the partial signature formula that:

$$S_1=b\times a\times g+{\mathrm{MK}}_1$$

(33)

By querying the list $L_2,L_3$ the challenger C can calculate $a\times g\times b$ as shown in Formula (34):

$$a\times g\times b=S_1-{\mathrm{MK}}_1$$

(34)

That is, C successfully resolves the given ECDLP instance.

For simplicity and without loss of generality, assume:

(a)

A will not make the same inquiry twice to $H(\mathrm{PK},l_i)$;

(b)

If A requests a signature for message l, then it has already inquired about $H(\mathrm{PK},l_i)$ before;

(c)

If A outputs $(l^{\ast },S^{\ast })$, then it has already been inquired about $H(\mathrm{PK},l_i)$ before.

The success of C is determined by the following three events.

E1: C does not interrupt during A’s signature inquiry;

E2: A generates a valid message signature for $(l^{\ast },S^{\ast })$;

E3: E2 occurs and $H(\mathrm{PK},l_i)$ has subscript $i=j$.

$\mathrm{Pr}[\mathrm{E}1]={(1-{\displaystyle \frac{1}{q_s}})}^{q_s},\mathrm{Pr}[\mathrm{E}2\left|\mathrm{E}1\right.]=\epsilon$, and $\mathrm{Pr}[\mathrm{E}3\left|\mathrm{E}2\mathrm{E}1\right.]=\mathrm{Pr}[i=j\left|\mathrm{E}2\right.\mathrm{E}1]={\displaystyle \frac{1}{q_h}}$. Therefore, the advantage of C is $\mathrm{Pr}[\mathrm{E}1\mathrm{E}2\mathrm{E}3]$$=\mathrm{Pr}[\mathrm{E}1]\mathrm{Pr}[\mathrm{E}2\left|\mathrm{E}1\right.]\mathrm{Pr}[\mathrm{E}3\left|\mathrm{E}2\mathrm{E}1\right.]={(1-{\displaystyle \frac{1}{q_s}})}^{q_s}\cdot {\displaystyle \frac{1}{q_h}}\epsilon \approx {\displaystyle \frac{1}{e{q}_h}}\epsilon$.

Therefore, if attacker A can break the BLS multi-signature scheme with a significant advantage $\epsilon$ within polynomial time, then challenger C can solve the ECDLP with a significant advantage ${\mathrm{Adv}}_C^{\mathrm{ECDLP}}$ within polynomial time by leveraging A’s capabilities. However, solving the ECDLP is difficult, so in the random oracle model, there cannot exist such an attacker A who can break the BLS multi-signature scheme within polynomial time. In this security model, an attacker can obtain ${\mathrm{MK}}_i$ through inquiries. In fact, the security of ${\mathrm{MK}}_i$ can also be reduced to the ECDLP, meaning that ${\mathrm{MK}}_i$ cannot be forged or broken by the attacker either. This further proves the security of this scheme.

5. Experiments and Performance Evaluation

5.1. Experimental Setup

To verify the effectiveness of the AT-ZTAC model in cloud environments, this study built a simulated cloud experimental platform. The relevant environment configurations are shown in

Table 4. Experimental Environment Configuration.

Configuration Item	Specific Configuration	Description
Hardware Environment
Number of Servers	5	Used for PDP cluster and resource pool
CPU Configuration	Intel Xeon E5-2680 v4 @ 2.4 GHz, 4 cores	Per server
Memory Capacity	8 GB DDR4	Per server
Storage	500 GB SSD	Per server
Software Environment
Operating System	Ubuntu Server 20.04 LTS	All servers
Python Version	Python 3.8.10	Trust evaluation module
Cloud Platform	OpenStack Wallaby version	Used to build a cloud resource pool
Database	PostgreSQL 13.3	Policy repository and log storage
Caching Service	Redis 6.2.5	Hot-spot caching
Message Queue	RabbitMQ 3.8.16	Asynchronous task processing
Dependency Libraries
Traffic Analysis	Scapy 2.4.5	Traffic feature extraction
Machine Learning	Scikit-learn 0.24.2	Anomaly detection model
Cryptography	PyCryptodome 3.10.1	BLS signature implementation
XACML Engine	PyXACML 1.0.0	Policy evaluation

.

Taking the traditional RBAC model [6], traditional ABAC model [3], dynamic trust evaluation model [25], machine learning trust model [26], history-based behavior trust model [27], and context-aware trust model [32] as controls, the core parameter configurations of this model are shown in

Table 5. AT-ZTAC Core Parameter Settings.

Core Parameter	Parameter Value Setting	Description
Positive Trust Value Weights	${\lambda }_1=0.2, {\lambda }_2=0.3$ ${\lambda }_3=0.25, {\lambda }_4=0.25$	Weights for recommended/device/time-based/history-based trust value
Reverse Risk Value Weights	${\lambda }_{V_1}$ = 0.6, ${\lambda }_{V_2}$ = 0.4	Weights for risk value based on anomaly traffic/log detection
Sliding Window Size	$\mathrm{wid}$ = 120, ${\mathrm{wid}}_{\mathrm{flow}}$ = 250, ${\mathrm{wid}}_{\log }$ = 180	History-based trust value window/Risk value based on anomaly traffic detection window/Risk value based on anomaly log detection window
Time Decay Factor	${\mu }^{\prime }$ = 0.01, ${\mu }_{\mathrm{flow}}$ = 0.025, ${\mu }_{\log }$ = 0.015	Controls the decay rate of historical data
Gaussian Function Parameters	$\mu =14.0$, $\sigma =4$	Modeling of normal access time
BLS Threshold Signature	m = 3, n = 5	Requires joint signature by 3 PDP nodes

.

Most of the above parameters are calculated by the system using the combined weighting method, and a small number are manually set hyperparameters. Among them, the sliding window size and time decay factor have the most significant impact on the experiment. In addition to the above parameter settings, the anomaly detection methods adopt those proposed in [33,34], both of which have real-time performance and certain robustness.

Experiments were conducted from three dimensions: trust evaluation effectiveness, access decision performance, and access control accuracy. All experimental data are the average values of three repeated tests. Additional ablation experiments and hyperparameter sensitivity experiments were conducted to ensure the reliability of the results.

5.2. Analysis of Trust Evaluation Effectiveness

Trust evaluation is the core of AT-ZTAC’s dynamic authorization. This section verifies the effectiveness of the model’s trust evaluation by simulating scenarios such as users’ first access, various typical attacks, continuous normal access, and sudden abnormal operations, combined with trust level distribution and response speed. The results all show advantages.

5.2.1. Trust Level Distribution for Users’ First Access

Experimental Scenario: Simulate a new user initiating a cloud resource access request for the first time, including 24,321 normal accesses and 9607 abnormal accesses. The system calculates the trust level based on Formula (12). To better align with the practical logic of “assigning higher initial trust to low-risk behaviors”, the recommended trust value for normal access is set to 0.8, and that for abnormal access is set to 0.3. The device attributes are uniformly set to have valid enterprise certificates, IP addresses belonging to reputable ISPs, and no historical records. The experimental results are shown in Figure 4.

As shown in Figure 4, the trust level of users’ first normal access ranges from 0.4 to 0.85, with an average of 0.607. Under the trust level evaluation algorithm, this distribution not only avoids permission overflow risks caused by excessively high initial trust (e.g., directly assigning a trust level above 0.8 may lead to privilege escalation risks) but also prevents insufficient authorization due to excessive conservatism (e.g., fixed trust levels cannot meet the diverse needs of different users), leaving reasonable room for subsequent dynamic adjustments. The trust level of users’ first abnormal access ranges from 0.0 to 0.55, with an average of 0.297. Through the multiplicative inhibition effect of the reverse risk value, the model can significantly reduce the trust level of high-risk access, ensuring security guarantees for the first access. The differentiation and concentration of the above distribution initially indicate that the trust evaluation module in the AT-ZTAC model can well distinguish users’ access intentions and assign relatively reasonable trust levels.

5.2.2. Trust Level and Access Control Results Under Attacks

Experimental Scenario: Eight types of typical attacks were simulated in the cloud environment, each lasting 10 min. The access decision results and corresponding average trust levels for each attack were recorded. To ensure the authenticity, reproducibility, and comparability of the experiment, this study used two widely recognized public datasets as the basis: the CIC-IDS-2017 dataset from the Canadian Institute for Cybersecurity and the CERT Insider Threat Dataset v4.2 from the Software Engineering Institute of Carnegie Mellon University. The former includes 14 modern network traffic attack scenarios and records more than 2.8 million traffic records, while the latter has rich log types, highly matching the audit logs in cloud environments, and provides typical cases for internal threats in cloud environments. On this basis, simulated experimental data conforming to cloud environment characteristics were constructed. For example, for DDoS attacks, the hping3 tool was used to simulate TCP SYN flood attacks to reproduce high-concurrency connection characteristics; privilege abuse was simulated by automatically executing sudo privilege commands and accessing restricted system files. All attacks were configured in accordance with the attack intensity, duration, and target selection patterns observed in the CIC-IDS-2017 and CERT Insider Threat Dataset v4.2, ensuring that the generated attacks are highly similar to the original datasets in terms of statistical characteristics. The final experimental results are shown in Figure 5.

As shown in Figure 5, the trust level of AT-ZTAC is negatively correlated with attack severity—the higher the attack severity, the lower the average trust level and the higher the rejection rate. For attacks with lower severity, the average trust level is relatively higher, and the proportion of conditional access rate and allowed access rate (1—rejection rate—conditional access rate) increases, achieving accurate matching of risk level—trust level—access control. This result indicates that AT-ZTAC can quantify attack threats in real time through reverse risk values, dynamically adjust trust levels and access policies, and avoid security redundancy or insufficient protection caused by “one-size-fits-all” defense.

5.2.3. Trust Level Changes During Users’ Continuous Normal Access

Experimental Scenario: Simulate 500 consecutive normal accesses by a user, set the initial trust level to 0.5, and compare the trust level change trends with those of typical trust models. The experimental results are shown in Figure 6.

As shown in Figure 6, with users’ continuous normal access, the trust levels of all models increase steadily, but there are also certain differences. Among them, the context-aware model and dynamic trust evaluation model can reach stability relatively quickly, but their trust levels are only around 0.7 after stabilization, which may lead to insufficient authorization. The trust level of the machine learning trust model increases indefinitely with the number of accesses and does not enter a stable stage for a long time, indicating poor responsiveness and insufficient timeliness of the model. The history-based behavior trust model grows slowly in the early stage and accelerates in the later stage, indicating that it fails to effectively filter the interference of distant data. Meanwhile, its trust level exceeds 0.95 after stabilization, posing a risk of over-authorization. The AT-ZTAC model studied in this paper can quickly reach stability within a reasonable range, avoiding the over-authorization risk caused by high trust levels and the insufficient authorization problem caused by low trust levels.

5.2.4. Trust Level Changes When Users Suddenly Perform Abnormal Operations

Experimental Scenario: On the basis of continuous normal access, simulate a user initiating a DDoS attack during the 200th access, and record the trust level changes in each model. The results are shown in Figure 7.

As shown in Figure 7, AT-ZTAC’s response speed to abnormal behaviors and risk suppression effect are significantly better than those of other models: when an attack occurs, the trust level of the AT-ZTAC model drops by approximately 0.7, which is more than 40% higher than that of the dynamic trust evaluation model (approximately 0.5) and the machine learning trust model (approximately 0.4), and also significantly higher than that of other models, enabling rapid response to malicious attacks. During subsequent normal access, the trust level of AT-ZTAC rebounds slowly and reasonably. Through the design of time windows for device trust value, history-based trust value, and reverse risk value, it avoids secondary risks that may be caused by the rapid trust level rebound of the context-aware trust model, and also prevents insufficient authorization caused by the long-term low trust level of the history-based behavior trust model.

5.3. Access Decision Performance Evaluation

Access decision performance directly affects the user experience and concurrent bearing capacity of cloud environments. This section evaluates the performance of AT-ZTAC after introducing the trust evaluation module and BLS threshold signature mechanism through throughput (the number of access decisions completed per unit time).

Experimental scenario: Simulate concurrent access requests increasing from 500 req/s to 2500 req/s, and measure the throughput of each model. The comparison results are shown in Figure 8.

As shown in Figure 8, the maximum access decision throughput of AT-ZTAC reaches 1850 req/s, which is a 54% increase compared to traditional ABAC (1200 req/s). The core reason is that the BLS aggregate signature simplifies the verification of multi-node signatures into a single verification. Moreover, since the trust score is incorporated into the ABAC decision policy as a key attribute, the policy retrieval range is limited to a specific trust threshold interval, reducing the decision space. Compared with the dynamic trust evaluation model (1400 req/s) and the context-aware trust model (1100 req/s), the throughput of AT-ZTAC has increased by 32% and 68%, respectively. The core reason is that the trust evaluation module in AT-ZTAC adopts asynchronous computing and hot-spot caching technologies, which effectively reduce performance loss and can meet the high-concurrency access requirements of cloud environments. However, the other two models still use a serial evaluation method: they only perform trust calculation after receiving a request and make access decisions only after the calculation is completed. When trust evaluation takes a long time, it will significantly increase the access response time. In addition, the AT-ZTAC model also has certain advantages over the history-based behavior trust model (1600 req/s), which may be due to the sliding window mechanism it adopts, which weakens the impact of distant data on the current evaluation and reduces computational overhead. The machine learning trust model has the lowest throughput (only 800 req/s), which is related to the large computational time consumption caused by its complex model. The traditional RBAC model has the highest throughput (2000 req/s) due to its simple policy structure, but RBAC has obvious deficiencies in dynamic access control and security, and cannot achieve accurate and adaptive decision-making capabilities.

To verify the statistical significance of the throughput advantage, a one-way Analysis of Variance (ANOVA) was used to test the overall differences among the models. The calculated result was F = 1246.38, p < 0.001, indicating that there were extremely significant overall differences in throughput among the seven models, excluding the possibility of inter-group differences caused by random fluctuations. To clarify the specific differences between AT-ZTAC and each comparative model, a Tukey HSD post hoc multiple comparison test was further used, with the results shown in

Table 6. Throughput Tukey HSD Test Results.

Comparison Group	AT-ZTAC Throughput (req/s)	Comparative Model Throughput (req/s)	Mean Difference (req/s)	Standard Error	95% Confidence Interval	p-Value	Significance
Traditional RBAC	1850 ± 15	2000 ± 12	−150	14.2	[−188, −112]	<0.001	***
Traditional ABAC	1850 ± 15	1200 ± 18	+650	16.8	[605, 695]	<0.001	***
Dynamic Trust	1850 ± 15	1400 ± 21	+450	18.3	[401, 499]	<0.001	***
Machine Learning Trust	1850 ± 15	800 ± 28	+1050	22.1	[992, 1108]	<0.001	***
History- Based behavior Trust	1850 ± 15	1600 ± 17	+250	16.1	[206, 294]	<0.001	***
Context- Aware Trust	1850 ± 15	1100 ± 23	+750	19.5	[698, 802]	<0.001	***

Note: *** indicates p < 0.001 (extremely significant); A positive mean difference indicates higher throughput for AT-ZTAC.

.

As shown in Table 6, the throughput of AT-ZTAC is significantly higher than all comparative models except traditional RBAC, and the differences in throughput compared to all comparative models reached an extremely significant level (p < 0.001). This proves that the performance gain of the asynchronous computing + hot-spot caching mechanism in high-load scenarios is effective and statistically significant, and not a random result.

5.4. Access Control Accuracy Evaluation

Access control accuracy is a core metric for ensuring the security and reliability of a cloud environment, directly related to whether the system can effectively block unauthorized access and ensure the normal use of legitimate users.

Experimental scenario: Inject mixed access request streams (a total of 10,000, including 80% normal access and 20% malicious access), calculate the accuracy of each model, and the results are shown in Figure 9.

As shown in Figure 9, the access control rate of the AT-ZTAC model is 96.8%, significantly higher than that of other models (the control rate of the traditional RBAC model is 87.5%, the control rate of the traditional ABAC model is 91.8%, the control rate of the dynamic trust evaluation model is 92.6%, the control rate of the machine learning trust model is 95.1%, the control rate of the historical behavior-based trust model is 89.3%, and the control rate of the context-aware trust model is 90.7%). The core advantage lies in the deep integration of dynamic trust scores and attribute policies: quantifying real-time user status through trust level, accurately distinguishing low-risk anomalies from high-risk malicious behaviors, avoiding false positives or missed judgments caused by rough static attribute judgments in traditional models, and further improving decision-making accuracy through the BLS multi-signature endorsement mechanism.

To verify the statistical significance of the accuracy rate differences, McNemar’s test (a paired binomial test) was used to compare the classification results of AT-ZTAC and each comparative model on the 10,000 samples. The results are shown in

Table 7. Significance Test for Access Control Accuracy Differences (McNemar’s Test).

Comparative Group	AT-ZTAC Accuracy (%)	Comparative Model Accuracy (%)	Accuracy Difference (%)	Discordant Pairs	χ2 Statistic	p-Value	Significance
Traditional RBAC	96.8	87.5	+9.3	1247	156.73	<0.001	***
Traditional ABAC	96.8	91.8	+5.0	678	89.32	<0.001	***
Dynamic Trust	96.8	92.6	+4.2	512	67.84	<0.001	***
Machine Learning Trust	96.8	95.1	+1.7	234	28.91	<0.001	***
History-Based behavior Trust	96.8	89.3	+7.5	891	112.45	<0.001	***
Context-Aware Trust	96.8	90.7	+6.1	745	95.67	<0.001	***

Note: Discordant Pairs = Number of samples where AT-ZTAC was correct but the comparative model was incorrect + Number of samples where AT-ZTAC was incorrect but the comparative model was correct; *** indicates p < 0.001 (extremely significant); χ² is the test statistic.

.

As shown in Table 7, the p-values for all comparison combinations are <0.001, reaching the “extremely significant” standard in statistics. This indicates that the access control accuracy of AT-ZTAC (96.8%) is significantly higher than that of traditional RBAC, ABAC, and various trust-based models. This advantage is not caused by random error but is a systematic result of its integrated design of “dynamic trust evaluation + ABAC attribute policies + BLS multi-signature endorsement”, with strong statistical reliability. Furthermore, the χ² values for all comparison combinations are far above the critical threshold for significant difference (χ²_0.001 = 10.83), further verifying that even small accuracy improvements possess rigorous statistical significance.

5.5. Ablation Experiment Analysis

To verify the effectiveness of each improved component in the AT-ZTAC model, this study designed a systematic ablation experiment. The improved parts of the model were decomposed into three key components for step-by-step verification:

• Component A: Zero Trust Architecture with the Trust Evaluation Module Removed
• Component B: Trust Evaluation Module
• Component C: BLS Threshold Signature

Figure 10 shows the performance changes when adding each component step by step, starting from the ABAC baseline model.

As shown in Figure 10, in terms of throughput, the throughput of the baseline ABAC is 1200 req/s; after adding Component A, the throughput drops to 1189 req/s. This is because Component A adds continuous identity verification compared to the baseline model. Although it only calculates changed attributes, there is still a small additional overhead, leading to a slight performance loss. After adding Component B, the throughput jumps to 1907 req/s (a 59% increase compared to the baseline). The core reason is that the addition of Component B reduces the policy search range to the trust value interval. At the same time, the adoption of asynchronous computing and hot-spot caching mechanisms decouples the serial dependence between trust evaluation and access decision-making, avoiding the performance bottleneck of real-time trust value calculation. After further adding Component C, the throughput drops to 1850 req/s (still a 54% increase compared to the baseline). The aggregation feature of the BLS signature simplifies multi-signature verification into a single operation, effectively controlling performance loss, but a multi-node signature still incurs slight computational overhead. In terms of accuracy, the accuracy of the baseline ABAC is 91.8%; after adding Component A, the accuracy increases to 92.5%, indicating that the continuous verification of zero trust can initially filter dynamic risks. After adding Component B, the accuracy significantly increases to 96.3% (a 4.5% increase compared to the baseline). The key lies in that Component B quantifies users’ real-time status through positive trust values and reverse risk values, accurately distinguishing legitimate access from malicious behaviors, and solving the misjudgment problem of static attributes in traditional ABAC. After adding Component C, the accuracy further increases to 96.8%, because the BLS threshold signature requires joint endorsement of decisions by multiple PDP nodes, reducing incorrect authorization caused by single-node failures or tampering. This proves that Component B is the core for improving accuracy, and Component C further enhances decision reliability. In terms of tolerable malicious PDP quantity, the baseline ABAC (single-PDP architecture) cannot tolerate malicious nodes (the system fails after being compromised); after adding Component A or B, the tolerable quantity does not change, as neither involves the fault-tolerance design of the control plane. After adding Component C, the number of tolerable malicious nodes increases to 2, indicating that the threshold signature scheme of Component C effectively disperses the trust risk of the control plane and significantly improves the system’s fault-tolerance capability.

5.6. Hyperparameter Sensitivity Experiment Analysis

The control variable method (with other variables set to optimal values) was used to analyze the impact of key hyperparameters (time adjustment factors ${\mu }^{\prime }$, ${\mu }_{\mathrm{flow}}$, ${\mu }_{\log }$; sliding window sizes $\mathrm{wid}$, ${\mathrm{wid}}_{\mathrm{flow}}$, ${\mathrm{wid}}_{\log }$) in the AT-ZTAC model on experimental accuracy, verifying the model’s robustness. The results are shown in Figure 11.

As shown in Figure 11, the optimal values and robustness characteristics of the key hyperparameters of the AT-ZTAC model are clear: the optimal baselines of the time adjustment factor for history-based trust value (${\mu }^{\prime }$), time adjustment factor for traffic risk (${\mu }_{\mathrm{flow}}$), and time adjustment factor for log risk (${\mu }_{\log }$) are 0.01, 0.025, and 0.015, respectively; the optimal baselines of the window size for history-based trust value ($\mathrm{wid}$), window size for traffic risk (${\mathrm{wid}}_{\mathrm{flow}}$), and window size for log risk (${\mathrm{wid}}_{\log }$) are 120, 250, and 180, respectively. At this time, the model’s accuracy reaches its highest. When each parameter is within the corresponding reasonable range (ranges from 0.005 to 0.02, ranges from 0.01 to 0.04, ranges from 0.008 to 0.03, ranges from 50 to 200, ranges from 100 to 400, ranges from 80 to 300), the accuracy can be maintained above 96%. Even if the parameters deviate from the optimal values, the maximum accuracy drop is no more than 0.8%, fully proving that the model has low sensitivity to hyperparameter changes and strong robustness.

6. Conclusions

To address the shortcomings of traditional access control models in cloud environments, such as insufficient dynamic adaptability, weak risk response capabilities, and poor control plane security, this paper proposes a zero-trust access control model (AT-ZTAC) that integrates dynamic trust evaluation and BLS threshold signature. The model calculates users’ trust levels in real time and incorporates them as key attributes into ABAC policies, realizing fine-grained and dynamic permission management. By introducing a BLS-based threshold signature mechanism, it effectively disperses the trust risk of the control plane and improves the system’s fault tolerance and accountability. Experimental results show that AT-ZTAC significantly outperforms traditional ABAC, dynamic trust evaluation models, and other comparison schemes in terms of trust evaluation effectiveness, access decision throughput, and control accuracy, verifying its application potential in cloud environments. The model can not only quickly respond to abnormal behaviors and dynamically adjust permissions but also maintain good system performance while ensuring high security. However, the current test has not been verified through large-scale deployment in complex real cloud environments. Even though the inherent aggregation feature of the BLS signature (constant communication overhead) provides a foundation for its scalability, there may still be potential challenges in practical implementation, such as latency and secure key distribution for PDP clusters.