MAPE-ZT: A Multi-Layer Access Policy Encryption System for Zero Trust Architectures

Abstract

Organizations usually rely on stringent access control mechanisms where access policies are an important asset. Their storage or transmission in plaintext can compromise sensitive access rules. It is important in dynamic environments where access decisions are made in real time such as Zero Trust (ZT). Existing ZT approaches were found to oversee the aspect of securing these policies. This investigation presents a Multi-layer Access Policy Encryption System for ZT systems (MAPE-ZT). The first stage uses the trapdoor index to generate a secure index to find the applicable access policies. Advanced Encryption Standard-256 is used in counter mode for the encryption of the policies. They are re-encrypted using the Ciphertext-Policy Attribute-Based Encryption (CP-ABE) to allow decryption based on a matching set of attributes. Various experiments using quantitative metrics, including comparison with baseline access control systems simulation, scalability evaluation, storage overhead, etc., highlight the efficacy of the MAPE-ZT and establish new benchmarks. The result count entropy for the policies ranged 3.84–4.21 for different scales of policies. The evaluation in different scales of systems shows that the MAPE-ZT reduces various observable patterns even if the deployment size grows. Its unique design of securing policies makes this approach scalable for multi-domain integration.

1. Introduction

With the rise of the Internet and technologies in this digital era, digital security has been stretched to a very thin line. Adversaries are finding new ways to breach into the organizations and cause harm. It could be in terms of financial loss, goodwill, information, etc. On average, businesses that were cyberattacked lost $4.88 million each [1]. Surveys indicate that ransomware attacks will cost $275 billion annually, with a new attack frequency every 2 s [2]. The digital lifestyle has also made Gen Z a lucrative target for attackers, be it personal devices or office premises [3].

Traditional security measures such as firewalls, intrusion detection systems/prevention systems (IDS/IPS), etc., are not enough to secure the assets of the organization. Such security measures trust the entities implicitly, which could lead to a compromised situation. These security principles work on the principle of the castle-and-moat approach (no restrictions on an attacker once it gets past the moat around the castle). With the presence of cloud technologies and remote collaborative industry work, simultaneous maintenance of stringent access control and privacy has also increased the difficulties of conventional security measures [4]. To address it, Zero Trust (ZT) came into play.

ZT is a set of ideologies and principles that drives the security posture of an organization [5]. It is a collective set of measures that lays over the existing conventional security measures of the organization. Although the term “ZT” was coined less than two decades ago, the history of it dates back decades [6,7]. Its wide adoption in various domains lies due to its core principles: ‘never trust, always verify.’ It uses stringent access control using dynamic access policies and continuously applying the rules evaluated using these policies [8]. The policies are maintained by the Policy Administration Point (PAP), a logical core component of the ZT Architecture (ZTA) [9]. It is dynamic in nature by default. It re-evaluates trust continuously based on frequent and fine updates in policies. A slight unintended change in these policies could collapse the entire ZTA. As a result, its protection is necessary.

Through different ZTAs, only a handful of researchers have addressed the importance of securing these policies. However, the number grows even smaller when the securing techniques are discussed. The principles of ZTA enable us to not trust any component, including the systems that store and manage access policies [10]. Compromise in the system can lead to the manipulation of policies. The leakage of policies residing in plaintext could lead to the manipulation of access requests to access resources. It is also prone to insider attacks [11]. Various compliance agencies enforce the security of sensitive documents that could lead to data leakage [12,13]. Encryption is one of the most useful ways to secure it.

Usual text-based encryption techniques are not feasible for these policies. Traditional encryption schemes are one-to-one in nature, which is not suitable for a large organization accessing multiple resources simultaneously. When a user’s access must be revoked, usual encryption techniques require re-encryption of data and redistribution of keys to all remaining authorized users. If a single shared decryption key is compromised, all protected data becomes accessible. In addition, sharing a subset of encrypted data requires multiple copies and encrypted keys. It increases storage and memory overhead, since traditional text encryption focuses solely on protecting data confidentiality. On the other hand, access policy encryption must preserve the ability to search, evaluate, etc. Encrypting structured logic while preserving non-malleability is a complex task. A single flip of bits in policy can lead to a change in values or thresholds. If policy encryption is malleable, the system is also prone to privilege escalation attacks. Resilience against leakage of content is the primary objective in text encryption. On the other hand, leakage of metadata of policies is also a major issue. Leakage of policy structure, size, thresholds, etc., can cause side-channel attacks. Policy systems are stateful in nature as compared to the usual stateless nature of text encryption. Changes in policies may require updating distributed metadata, re-keying, etc. Knowledge about the structure of policies and patterns of their possible contents can lead to logical manipulation of requests. It is one of the serious issues in usual encryption techniques in client–server models. In addition, relying solely on a single encryption technique or secret could lead to exploitation of its limitations by adversaries [14,15]. Traditional access control systems rely on single-layer encryption or role-based permissions that are not suitable for the dynamics of ZTA [16,17]. It makes the environment unsuitable for enforcing the principles of ZT.

Current encryption methods lack attribute-based access control at the cryptographic level over who can access information based on user attributes and context. They cannot verify the runtime conditions for adaptive access management. It makes it difficult for organizations to fully enforce the ZT principles. Decrypting the hundreds of encrypted policies, checking each one ($\mathcal{O}\left(n\right)$ complexity), extracting the meaningful rules, followed by their re-encryption for a large number of requests/seconds, is a huge computational load. Even though we design a list of policies applicable to a certain role or users, its frequent update or maintenance is not feasible or secure. The researchers in [18,19] observed computational complexities as the depth of policies increases. A similar issue is also faced in [20], where all the policies are evaluated to make decisions. The approach also results in high storage overhead along with the absence of re-keying approaches, as it has been observed. In addition, the use of a single RSA-based approach is prone to data leakage if broken. Traditional encryption algorithms are computationally infeasible in nature. Although homomorphic encryption could be helpful, it tends to be resource-intensive and infeasible for large volumes of requests per second [21,22]. Existing ZT approaches using policies for decisions focus on integrity verification or secure storage. However, verification alone is not suggested [23]. In order to have a proactive approach suitable for ZT, an efficient approach is needed that focuses on all the triads of information security while maintaining the performance [24].

To address this issue, a Multi-layer Access Policy Encryption System for ZT (MAPE-ZT) has been developed to secure access policies in ZTAs. In the first stage, a trapdoor indexing system that uses five-tier keyword extraction with Hash-based Message Authentication Code (HMAC)–Secure Hash Algorithm 256-bit (SHA256) is used to create searchable fingerprints that do not reveal content. This enables a diverse set of keywords to defend against frequency analysis and search pattern analysis. The choice of HMAC-SHA256 over alternatives such as HMAC-MD5, HMAC-SHA1 (deprecated due to collision attacks and vulnerabilities), or newer candidates such as BLAKE2 or SHA-3, originates from its optimal balance of security, performance, and widespread implementation support [25,26]. In the second stage, the symmetric Advanced Encryption Standard (AES)-256 in counter (CTR) mode with random nonce is used for encryption of policies. It was selected over competing algorithms such as Serpent, Twofish, RC6, etc., due to the rigorous evaluation by the National Institute of Science and Technology (NIST) and its hardware acceleration availability [27]. Unlike CBC mode, which requires sequential processing and is vulnerable to padding oracle attacks, or ECB mode, which reveals patterns in encrypted data, CTR mode with unique nonces ensures that identical plaintexts produce different ciphertexts [28]. A 96-bit nonce is generated using a 32-bit timestamp and a 64-bit random value. Using a time window as per organizations for validation of tokens can also alleviate replay attacks. This small value is also efficient for storage and caching. With 64 bits of randomness, the probability of collision after $2^{32}$ nonces (by the birthday paradox) is approximately $P_{\mathrm{collision}}\approx 2^{-32}$. For realistic query volumes (<${10}^7$ per day), the collision probability is negligible, i.e., $P_{\mathrm{collision}}<{10}^{-6}$. In the third stage, Ciphertext-Policy Attribute-Based Encryption (CP-ABE) provides fine-grained control over who can decrypt specific encrypted information (based on the attributes provided during the request) [29,30]. The combination of all three stages presents the keyword-based searchable index and the policy encryption technique. All of these processes are handled by the PAP.

Whenever an access request is received, instead of going through all policies, only the selected policies are parsed. The selection is based on the keywords within the access request matched with those in the trapdoor index. Afterwards, the CP-ABE matches the attribute requirement, and only the selected policies are decrypted using AES-CTR to provide the policy data. A hierarchical key derivation scheme has been used to generate all keys throughout the process. These keys are derived from a root master key ($K_{\mathrm{master}}$) using an HMAC-based Key Derivation Function (HKDF). $K_{\mathrm{master}}$ is generated randomly and is not used directly for encryption. It is used to derive other keys. This process enables us to have easy key rotation and efficient storage. Even if one key from a user is compromised, it does not affect the entire cryptosystem. Only PAP and other components receive the specific derived keys they need (principle of least privilege). The keys for the trapdoor are distributed to authorized query processors. The distribution uses Transport Layer Security (TLS) 1.3. The keys can be stored in secure enclaves in local storage or a specialized Hardware Security Module (HSM), depending upon the needs of the organization. The policies are passed to the Policy Decision Point (PDP) for evaluation and further access control. This optimized integration and innovative approach to secure access policies within a ZT environment is underexplored in the existing literature. The optimizations used in the study are mentioned in

Table 1. Algorithmic optimizations and novelties.

SL	Techniques	Usual Way	Optimized Way Used
1	Trapdoor Index Generation	Single keyword extraction with basic hashing	Five-category keyword extraction (structural, value, paired, resource, action) with HMAC-SHA256 and deduplication.
2	Symmetric Encryption	AES-CBC with fixed IV causing pattern leakage	AES-256-CTR with random 96-bit nonces provides parallelization.
3	CP-ABE Key Generation	Complex bilinear pairings requiring expensive group operations	HMAC-based key derivation replaces bilinear pairings with a single HMAC call.
4	CP-ABE Key Encapsulation	Modular exponentiation in multiplicative groups	XOR-based encapsulation: $EK\left[attr\right]=K_2\oplus K_{attr}$ for constant-time operation.
5	Policy Evaluation	Perfect attribute matching only (binary decision)	Recursive Boolean evaluation supporting leaf nodes, AND-nodes, and OR-nodes via evaluate_policy(), with short-circuit evaluation and backward compatibility with flat string policies.
6	Search Intersection	Linear search through policy lists	Hash-based O(1) lookup with set intersection optimization.
7	User Key Generation	Regenerate keys for each query	Per-attribute HMAC derivation is computed on demand to avoid long-term key storage in memory.
8	Policy Parsing	Real-time string parsing for each evaluation	Unified evaluate_policy() handles both flat string and structured tree formats to remove redundant parsing branches through a single recursive traversal.
9	Batch Processing	Individual policy encryption sequentially	Sequential per-policy encryption with one-time trapdoor index construction at setup, amortizing index build cost for all policies rather than rebuilding at query time.

.

This research addresses various important objectives in policy encryption for ZT:

• Development and performance evaluation of multi-layer security architecture: A three-layer encryption framework, i.e., MAPE-ZT, has been developed that combines trapdoor indexing, Symmetric Encryption (SE), and CP-ABE.
• Reduce the risk of unauthorized modification in access policies: Having knowledge of access control policies and the ability to change them could allow adversaries to gain unauthorized access. It may appear legitimate by manipulating a query accordingly.
• Realistic modeling of policy complexity for a real-life simulation: To address the issue of perfect attribute matching, three access levels (simple, medium, and complex) were used with an increasing level of complexity.
• Tradeoff between security and performance: To achieve enterprise-grade performance while maintaining security, parallelizable encryption and various other techniques have been used to take full advantage of processing units.
• Establish reproducible benchmarking methodology for ZT policy encryption: Various tests, including security assessments, performance analysis, scalability, accuracy measurement, etc., were tested under different circumstances to get a complete overview of the research.
• Achieve various security principles: Various security principles, including confidentiality, integrity, etc., are fulfilled to call MAPE-ZT secure.

In addition, the contributions of the research are as follows:

• Novel Three-Layer Policy Protection Framework: An integrated framework combining the following:

  –

  Layer 1: HMAC-SHA256 trapdoor generation.

  –

  Layer 2: AES-256-CTR SE.

  –

  Layer 3: Simplified CP-ABE with XOR-based key encapsulation.

• Multi-dimensional Security Protection: The approach provides comprehensive security through:

  –

  Confidentiality through dual-layer encryption;

  –

  Integrity through AES-GCM authentication tags and cryptographic binding of policies to their encrypted content (CP-ABE);

  –

  Robust defense against various cyberattacks.

• Design for PAP: A design for PAP has been put forward through this study. It was a relatively overlooked component in many studies.
• Realistic Enterprise Policy Modeling: Various eXtensible Access Control Markup Language (XACML)-based control policies were generated using various contexts, including 10 role types and six geographic locations. In addition, an intentional failure rate of ∼30% has been used to simulate real-life scenarios.
• Optimized CP-ABE for ZT: HMAC-based derivation has been used instead of complex bilinear pairings to improve the speed of the approach.
• Comprehensive Performance Analysis: A comprehensive benchmarking framework has been designed using various metrics to evaluate the efficacy of the approach.

Further sections of the paper are classified as follows: Section 2 briefly discusses related studies and highlights current technological advancements in the domain. Section 3 provides a detailed explanation of the methodologies used. Section 4 analyzes the findings and presents key results. Section 5 puts the paper to an end and discusses key future research directions.

2. Related Works

With the inception of ZT, its security principles have made it a widely adopted security architecture. According to a survey, almost 63% of the participating organizations use ZTA fully or partially [31]. It has been widely used in various domains, including cloud security, next-generation communications, finance, etc. In addition, various emerging technologies are also being used to further strengthen the ZTA, including AI and blockchain [32]. In summary, this section provides technological improvements over recent ZTAs in various domains.

The researchers in [33] proposed a dual-layered ZTA to secure industrial Internet of Things (IIOT) and Operation Technologies (OT) devices with the use of various open-source technologies. Similarly, Huber and Kandah proposed a trust-based ZTA focusing on the Internet of Things (IoT) devices [34]. To further secure IoT devices, the researchers in [35] proposed a dynamic trust scoring scheme based on differential equations that evaluates assets based on vulnerability scores from standard Common Vulnerabilities and Exposures (CVE) data. Al Sharfi et al. proposed a federated learning-based model to protect consumer IoT from various intrusion-based attacks in the ZT environment [36]. The model was increased with the use of a temporal convolution network with a gated recurrent unit and an improved artificial gorilla troop optimizer.

Chen et al. proposed a ZTA to secure healthcare systems utilizing 5G technologies [37]. Various principles, including continuous monitoring, trust assessment, and access control mechanisms, were applied to four core aspects of the organization: subject, object, environment, and behavior. Similarly, the researchers in [38] used the Software-Defined Perimeter (SDP) and various ZTA techniques to secure mobile networks. In [39], researchers proposed a ZTA to secure 6G technologies with the integration of Artificial Intelligence (AI). Nie et al. proposed a blockchain-based ZT methodology to secure IoT devices in a 6G environment [40]. Smart contracts to automate access control, a consensus-based trust model for node reputation, and an asymmetric inner-product encryption approach further improve the cyber resilience of the framework.

The distributed and decentralized approach of blockchain makes it highly suitable for security architectures [41]. The researchers in [42] proposed a ZTA to secure IoT devices using blockchain. Trust is computed for each access request, and stringent access control is applied accordingly. Similarly, the researchers used Zero-Knowledge Proofs (ZKPs) to design a Distributed Authentication Mechanism (DAM) in ZTA to eliminate centralized authentication [43]. In addition, a distributed method of OTP generation and on-chain verification using smart contracts secures the architecture.

AI plays a significant role in ZT by enabling real-time threat detection, adaptive access control, etc. [44,45]. The researchers in [46] discussed the potential of AI-based models in threat detection. The UNSW-NB15 and CICIDS2017 datasets were used for evaluation using various supervised learning models. Similarly, the researchers in [47] proposed an Android malware classification model using Differential Privacy (DP) within a Feedforward Neural Network (FNN), tested with static features (CCCS-CIC-AndMal-2020) and dynamic features (CICMalDroid 2020). The researchers in [48] proposed a certificate-less digital signature authentication method with ZT to secure the IoT technologies of marine technologies. They used the genetic algorithm and the particle swarm optimization algorithm to generate the keys of Elliptic Curve Cryptography (ECC), which reduced the key generation time by 40% and 20%, respectively.

A practical demonstration of the deployment of ZTA in financial institutions is illustrated by [49]. The researchers used various technologies of ZTA including Identity and Access Management (IAM), continuous monitoring, and various others. Similarly, Purantha and Ivan proposed adopting the PDIOO network life cycle to secure the inter- and intra-communication of different Kubernetes containers [50]. All traffic prior to authentication is treated as untrustworthy.

A brief comparison among various ZTAs is presented in

Table 2. Comparison among various ZTAs.

Evaluation Technique	Criterion	[33]	[34]	[35]	[36]	[37]	[38]	[39]	[40]	[42]	[43]	[46]	[47]	[48]	[49]	[50]	Proposed
Proposal Type	Architecture/ Implementation	A + I	A	A + I	I	A + I	A + I	A	A + I	A	A + I	I	A + I	A + I	A + I	A + I	A + I
Policy Evaluation	Static (S)/ Dynamic(D)	D	–	D	D	–	S	–	D	D	S	–	–	–	D	S	NA
	Contextual Awareness	✓	✓	✓	–	✓	✓	✓	✓	✓	✓	✓	✓	–	✓	–	✓
Authentication	MFA/ Continuous Authentication	✓	✓	✓	–	✓	–	–	✓	✓	✓	✓	✓	✓	✓	–	✓
Asset Security	Posture Calculation	✓	✓	✓	–	✓	✓	–	✓	✓	✓	✓	–	–	✓	–	–
Automated Threat Detection & Traffic Control	Anomaly Detection and Traffic Monitoring	✓	✓	✓	✓	✓	✓	✓	✓	✓	–	✓	✓	–	✓	✓	NA
Policy Management	Securing Access Policies	–	–	–	–	–	–	–	–	Hashed storage of data in IPFS	–	–	–	–	–	–	Policy Encryption

✓ indicates that the corresponding feature is supported. – indicates that the feature is not supported or not discussed. NA indicates that the feature is not applicable in the proposed framework.

. The comparison criterion is based on the subcomponents of various tenets of ZTA, proposed by [10]. In addition, studies are classified into two categories: architecture (A) and implementation (I). The ones that propose a framework, approach, or similar outcomes with the aim of implementation in further studies are classified into the category ‘Architecture.’ On the other hand, those who present a tangible outcome, including testbed, prototypes, or similar outcomes, are classified into the category ‘Implementation.’ It can be observed that various studies focus on other tenets; however, securing access policies is less explored. Researchers in [42] stored logs, smart contracts (used for access decision-making), and many other critical components in the InterPlanetary File System (IPFS). Although this method is well-suited for integrity verification, placing greater emphasis on securing it could further strengthen overall system security. In order to bridge this gap, the proposed MAPE-ZT would be highly suitable to secure access policies in the ZT environment.

Problem Motivation

The innovative idea of the researchers in [42] to store smart contracts and other necessary components for authentication in IPFS motivated this research. It enables integrity matching through content-based addressing. It ensures transparency and trust, as integrity checks can be performed openly by any party without relying on a central authority. In addition, IPFS provides decentralized storage, improved data availability, and resistance to censorship. Inspired by their approach, their ideology towards securing access policies has been extended to provide confidentiality and integrity verification. A cryptosystem has been used to secure access policies, focusing on the ZT environment that lacked focus on securing access policies. Its adaptable nature also makes it suitable for different domains.

3. Methodology

The decision-making process of MAPE-ZT can be completed in multiple stages, as depicted in Figure 1. The architecture is inspired by NIST [10]. It is considered a foundational model for ZT. When a user requests a certain resource (Step 1), the request goes through the Policy Enforcement Point (PEP). The keywords mentioned in the request are used to determine the applicable policies (Step 2). The actual content of the request may vary from one architecture to another. Usually, it contains the name of the resource, user details, access tokens, etc. The Policy Administrator (PA) verifies the access token. It proceeds only if the token is valid. In order to evaluate the decision, the Policy Engine (PE) requests the applicable policies from the PAP, based on the request (Step 3). Based on those policies, it evaluates the decision. It enables PA to inform PEP about the decisions (Step 4). The PEP acts accordingly and allows access to the particular resource, if granted (Step 5).

The detailed flow of the MAPE-ZT that lies inside the PAP is discussed subsequently.

3.1. Encryption Process Flow

MAPE-ZT uses a three-layer cryptographic architecture that combines trapdoor-based searchable indexing, SE, and optimized CP-ABE. This multi-layer approach ensures comprehensive security while maintaining practical performance for enterprise-scale policy management. Each stage is explained below:

3.1.1. Phase 1: Policy Preprocessing and Keyword Extraction

The encryption process starts with preprocessing of XACML-based policies. The keywords of the policies are extracted using Algorithm 1. The keywords used are of five different categories to provide flexible search capabilities. They are as follows:

1.

Structural Keywords: Attribute names such as role, department, clearance_level.

2.

Value Keywords: Attribute values such as admin, IT, confidential.

3.

Paired Keywords: Attribute-value combinations such as role:admin, department:IT.

4.

Resource Keywords: API endpoints such as /api/users, /api/billing.

5.

Action Keywords: Permission types such as read, write, delete.

This strategy generates 5–15 searchable keywords per policy. This provides flexibility to search and maintain security using various keywords. The extraction process recursively traverses the policy structure to identify all searchable elements.

Algorithm 1 Keyword extraction

Require:  Policy p in XACML format Ensure:  Keyword set $\mathcal{KW}$   1: Initialize $\mathcal{KW}\leftarrow \varnothing$   2: Extract attribute names:   3: for each attribute $attr$ in p do   4:     $\mathcal{KW}\leftarrow \mathcal{KW}\cup \left\{attr\right\}$   5: end for   6: Extract attribute values:   7: for each value $val$ in p do   8:     if $\left|val\right|\ge 2$ then   9:         $\mathcal{KW}\leftarrow \mathcal{KW}\cup \left\{val\right\}$ 10:     end if 11: end for 12: Extract attribute-value pairs: 13: for each pair $(attr,val)$ in p do 14:     $pair\leftarrow attr+\mathtt{“}\mathtt{:}\mathtt{”}+val$ 15:     $\mathcal{KW}\leftarrow \mathcal{KW}\cup \left\{pair\right\}$ 16: end for     return  $\mathcal{KW}$

3.1.2. Phase 2: Trapdoor Index Construction

After keyword extraction, the system constructs a secure searchable index called a trapdoor. The trapdoor index is generally an index that is easy to compute output when given an input (in one direction), but practically impossible to determine the original input from output [51]. For each extracted keyword $kw$, the system generates a cryptographic trapdoor using HMAC-SHA256 (as illustrated in Equation (1)).

$$T\left(kw\right)=\text{HMAC-SHA}256(K_{\mathrm{trap}},kw)$$

(1)

where $K_{\mathrm{trap}}$ and $kw$ represent the 256-bit trapdoor generation key and the set of keywords, respectively. The resulting trapdoors form an inverted index structure, as illustrated in Equation (2).

$$\mathrm{Index}[T(kw)]=\{\text{policy\_ids} \mathrm{containing} kw\}$$

(2)

Let us consider a simple access policy, as mentioned in Figure 2.

The extracted keywords, such as “role,” “department,” etc., follow the above indexing and create a trapdoor index, as follows:

• ‘a7f5c9d2e8b1a4c6…’→[policy_00001, policy_00045]// original keyword: “role”
• ‘b8e6d3f1a9c2b5e8…’→[policy_00002]// original keyword: “role:admin”
• ‘c9f7e4a2b0d3c6f9…’→[policy_00001, policy_00012]// original keyword: “department”
• ‘d4a8b5c2f6e9a3d7…’→[policy_00001, policy_00034]// original keyword: “IT”

Note: The hash values are truncated with … for conciseness.

This construction ensures trapdoor unlinkability. Only cryptographic hashes are visible to the server that appear random without knowledge of $K_{\mathrm{trap}}$. It prevents correlation analysis with probability $1/2^{256}$. The index construction creates a hash table that enables $O\left(1\right)$ keyword lookup during search operations.

This unlinkability also provides more protection than the suggested search-pattern leakage. The trapdoor $T\left(kw\right)=\text{HMAC-SHA}256(K_{\mathrm{trap}},kw)$ is keyed by a 256-bit secret $K_{\mathrm{trap}}$. It is held exclusively by the authorized query issuer. An external adversary who observes these trapdoor values in transit sees computationally unclear pseudorandom strings. Frequency analysis on trapdoor values leaks nothing about the underlying keywords without $K_{\mathrm{trap}}$. It correctly associates any trapdoor with its keyword without $K_{\mathrm{trap}}$ succeeds with probability at most $1/2^{256}$. Frequency analysis is therefore only feasible for an insider adversary already holding $K_{\mathrm{trap}}$, not an external observer.

In addition, the search channel and content channel are cryptographically separated using independent key values. Even if an adversary finds out which trapdoor was queried, the matched policy content is protected using two independent encryption layers with entirely separate keys. As a result, access pattern leakage does not represent content leakage. The practical impact of search pattern observation is bound to structural metadata rather than policy content.

3.1.3. Phase 3: Multi-Layer Policy Encryption

The policy encryption uses a nested two-layer approach:

Layer 1: AES-CTR Encryption

The policy content after trapdoor creation undergoes AES-256-CTR encryption as depicted in Algorithm 2, using Equation (3). Policies are converted to JSON format and encrypted using AES-CTR with the SE key $K_{\mathrm{se}}$. $K_{\mathrm{se}}$ is also randomly generated and stored in the SE component. A random nonce ${\mathrm{nonce}}_1$ of 96 bits is used to make each encryption unique.

$$\begin{array}{cc}\hfill C_1& ={\text{AES-CTR}}_{256}(K_{\mathrm{se}},\mathrm{JSON}(\mathrm{policy}),{\mathrm{nonce}}_1)\hfill \end{array}$$

(3)

where $K_{\mathrm{se}}$ represents a 256-bit SE key. The selection of CTR mode provides parallel encryption/decryption capabilities that enable the elimination of padding oracle vulnerabilities and deterministic random access to encrypted policy sections.

Algorithm 2 Policy encryption

Require:  Policy set $\mathcal{P}=\{p_1,p_2,\dots ,p_n\}$, Keys $K_{\mathrm{trap}}$, $K_{\mathrm{se}}$ Ensure:  Encrypted database $\mathcal{EPD}$ and index $\mathcal{I}$   1: Phase 1: Build Trapdoor Index and Encrypt Policies   2: Initialize $\mathcal{I}\leftarrow \varnothing$, $\mathcal{EPD}\leftarrow \varnothing$   3: for each policy $p_i\in \mathcal{P}$ do   4:     Extract keywords ${\mathcal{KW}}_i$ from $p_i$   5:     for each keyword $kw\in {\mathcal{KW}}_i$ do   6:         Compute $t\leftarrow \text{HMAC-SHA}256(K_{\mathrm{trap}},kw)$   7:         Update $\mathcal{I}\left[t\right]\leftarrow \mathcal{I}\left[t\right]\cup \left\{p_i\right\}$   8:     end for   9:     AES-CTR Encryption: 10:     Convert $text\leftarrow \mathrm{JSON}\left(p_i\right)$ 11:     Generate $n_1\leftarrow \mathrm{Random}\left(96\mathrm{bits}\right)$ 12:     Create $counter\leftarrow n_1\parallel 0^{32}$ 13:     Compute $stream\leftarrow {\mathrm{AES}}_{K_{\mathrm{se}}}\left(counter\right)$ 14:     Encrypt $C_1\leftarrow text\oplus stream$ 15:     $(C_2,meta)\leftarrow \text{CPABE-Encrypt}(C_1,p_i.\mathrm{policy})$ 16:     Store $\mathcal{EPD}\left[p_i\right]\leftarrow (C_2,meta,n_1)$ 17: end forreturn  $(\mathcal{EPD},\mathcal{I})$

Layer 2: CP-ABE Encryption

Although AES-256 provides strong cryptographic protection, it will fail if the keys are compromised [15]. To address it, CP-ABE has been used, which enables stringent access control upon policy decryption itself. Since the decryption process requires proof of user attributes that match the embedded access policy, unauthorized users cannot decrypt policies even if they compromise the storage system or obtain the encrypted data. The AES-encrypted policy undergoes attribute-based encryption using Equation (4). A new random key $\left(K_2\right)$ of 256 bits and a random nonce ${\mathrm{nonce}}_2$ of 96 bits are generated for the policy, and again the already encrypted policy with this new key. AES-GCM also creates a “tag” to verify the integrity of the data. Algorithm 3 highlights the whole process in detail. $\mathcal{EK}$ stores the attribute-protected encryptions of the symmetric data key $K_2$. It ensures that only users whose attributes satisfy the access policy can recover $K_2$ and decrypt the ciphertext. It acts as a bridge between CP-ABE policy enforcement and Symmetric Encryption.

$$\begin{array}{cc}\hfill (C_2,\mathrm{tag})& =\text{AES-GCM}(K_2,C_1,{\mathrm{nonce}}_2)\hfill \end{array}$$

(4)

Algorithm 3 CP-ABE encryption

Require:  Data D, Access policy $\mathcal{AP}$, Master key $K_m$ Ensure:  Ciphertext $C_2$, Metadata $meta$   1: Parse $\mathcal{A}\leftarrow \mathrm{ExtractAttributes}\left(\mathcal{AP}\right)$   2: Generate $K_2\leftarrow \mathrm{Random}\left(256\mathrm{bits}\right)$   3: Generate $n_2\leftarrow \mathrm{Random}\left(96\mathrm{bits}\right)$   4: Encrypt with AES-GCM:   5: Compute $(C_2,tag)\leftarrow {\text{AES-GCM}}_{K_2}(D,n_2)$   6: Encrypt symmetric key:   7: Initialize $\mathcal{EK}\leftarrow \varnothing$   8: for each attribute $attr\in \mathcal{A}$ do   9:     Derive $K_{attr}\leftarrow \text{HMAC-SHA}256(K_m,\mathtt{“}\mathtt{attr}\text{\_}\mathtt{”}+attr)$ 10:     Encrypt $\mathcal{EK}\left[attr\right]\leftarrow K_2\oplus K_{attr}$ 11: end for 12: Create $meta\leftarrow \{\mathcal{AP},\mathcal{EK},n_2,tag\}$     return  $(C_2,meta)$

For each attribute (attr) in the access policy, a unique key is created using the master key ($K_{\mathrm{master}}$) using Equations (5) and (6). The use of multiple independent master key generation authorities can also help to design a multi-authority key management for ZTA. It can alleviate the inherent limitations of centralized key management systems. When the access policy is represented as a structured tree, all leaf attribute values can be extracted recursively from all the branches (both AND and OR) to form the complete attribute set $\mathcal{A}$. Using it, $\mathcal{EK}$ is created. This superset ensures that $\mathcal{EK}$ contains entries for every possible satisfying attribute irrespective of which branch of the policy the authorized user satisfies.

$$\begin{array}{cc}\hfill K_{\mathrm{attr}}& =\text{HMAC-SHA}256(K_{\mathrm{master}},“\mathrm{attr}\text{\_}”+\mathrm{attr})\hfill \end{array}$$

(5)

$$\begin{array}{cc}\hfill \mathrm{EK}\left[\mathrm{attr}\right]& =K_2\oplus K_{\mathrm{attr}}\hfill \end{array}$$

(6)

This simplified CP-ABE design replaces bilinear pairings that are computationally expensive with efficient XOR-based key encapsulation. It reduces complexity from $O\left(n^2\right)$ to $O\left(n\right)$ and maintains cryptographic access control properties. This construction also provides resistance against collusion attacks. Consider two users holding distinct attributes A and B, with corresponding encrypted key entries $\mathcal{EK}\left[A\right]=K_2\oplus \mathrm{HMAC}(K_{\mathrm{master}},A)$ and $\mathcal{EK}\left[B\right]=K_2\oplus \mathrm{HMAC}(K_{\mathrm{master}},B)$. XOR-ing these two entries yields the value, as mentioned in Equation (7).

$$\mathcal{EK}\left[A\right]\oplus \mathcal{EK}\left[B\right]=\mathrm{HMAC}(K_{\mathrm{master}},A)\oplus \mathrm{HMAC}(K_{\mathrm{master}},B)\ne K_2$$

(7)

Therefore, neither user can isolate $K_2$ by combining their respective entries, since recovery of $K_2$ requires the correct per-attribute key $K_{\mathrm{attr}}$ derived from $K_{\mathrm{master}}$. It is held exclusively by the key authority. The encapsulation and decapsulation process is presented in Algorithms 4 and 5. Algorithm 4 wraps a CP-ABE ciphertext using a keystream derived from HKDF. On the other hand, Algorithm 5 reverses it. A domain separation string “MAPE-ZT-v1” is used that serves multiple purposes. It ensures that the keys derived in this context cannot be maliciously reused in other contexts. The version suffix (v1) provides cryptographic agility that allows future protocol updates. This technique is also used in various types of protocols and mentioned in different standards as well [52]. In order to make the approach resilient against replay attacks, timestamps are extracted for verification. The entire process uses UTF-8 encoding. The keystreams are expanded using HKDF to match the length of $C{T}_{abe}$.

In order to evaluate the security of the proposed XOR-based CP-ABE model, an adaptive chosen-attribute attack scenario has been considered. It is similar to the IND-CPA definition used in traditional CP-ABE approaches. An adversary may obtain secret keys corresponding to random attribute sets that do not satisfy a chosen challenge access policy. The adversary then submits two plaintext policies of equal length and receives the encrypted text for one of them. The scheme is considered secure if the adversary’s ability to distinguish the two of which text was encrypted is negligible in the security parameter.

Assuming HMAC-SHA256 acts as a secure PseudoRandom Function (PRF), each $K_{\mathrm{attr}}$ is computationally indistinguishable from a uniformly random value to any party that does not know the master key $K_m$. As a result, $\mathcal{EK}\left[attr\right]$ reveals no information regarding $K_2$ without the information of the corresponding attribute-derived key.

Collusion resistance follows from the independence of PRF outputs. For any alliance of users that have attributes $\{A_1,A_2,\dots ,A_k\}$, XOR combinations of their respective $\mathcal{EK}\left[A_i\right]$ entries remove $K_2$. It provides only XOR combinations of independent outputs of PRF. These values are computationally indistinguishable without knowledge of $K_m$. As a result, the combination of attribute entries does not cause recovery of $K_2$.

Algorithm 4 XOR-based CP-ABE encapsulation

Require:  $\mathcal{P}$ (policy data), $\mathcal{A}$ (access structure), $P{K}_{master}$ (CP-ABE public key), $K_{se}$ (256-bit symmetric key), $policy\text{\_}id$ (policy identifier string) Ensure:  $C{T}_{wrapped}$ (encapsulated ciphertext), $\eta$ (nonce)                                                                                                            ▹Step 1: Generate nonce   1: $timestamp\leftarrow$ Unix_Time_Seconds()                                           ▹32-bit unsigned integer   2: $random\leftarrow$ CSPRNG(64)                                                           ▹64 bits from OS CSPRNG   3: $\eta \leftarrow timestamp \Vert random$                                                                                   ▹ 96-bit nonce                                                                                                  ▹Step 2: CP-ABE encryption   4: $C{T}_{abe}\leftarrow$ CP-ABE.Encrypt $(P{K}_{master},\mathcal{P},\mathcal{A})$   5: $L_{ct}\leftarrow \left|C{T}_{abe}\right|$                                                                             ▹Ciphertext length in bytes                                                                                                    ▹Step 3: Prepare PRF input   6: $policy\text{\_}i{d}_{bytes}\leftarrow$ UTF-8.Encode(policy_id)   7: $prf\text{\_}input\leftarrow policy\text{\_}i{d}_{bytes} \Vert \eta$                                                                              ▹Step 4: Derive keystream using HKDF   8: $PRK\leftarrow$ HMAC-SHA-256$(“\text{MAPE-ZT-v}1”,K_{se})$                                          ▹Extract phase   9: $keystream\leftarrow$ HKDF-Expand(PRK, pr f_input, Lct)                  ▹Expand to needed length                                                                                                  ▹Step 5: XOR encapsulation 10: $C{T}_{wrapped}\leftarrow C{T}_{abe}\oplus keystream$ 11: return  $(C{T}_{wrapped},\eta )$

Algorithm 5 XOR-based CP-ABE decapsulation

Require:  $C{T}_{wrapped}$ (wrapped ciphertext), $\eta$ (nonce), $S{K}_{user}$ (user’s CP-ABE secret key), $K_{se}$ (symmetric key), $policy\text{\_}id$ (policy identifier) Ensure:  $\mathcal{P}$ (decrypted policy data) or ⊥ (failure)                                                                                               ▹Step 1: Verify nonce freshness   1: $timestamp\leftarrow \eta [0:32]$    return ⊥                                                        ▹Extract timestamp   2: if |Current_Time( ) − timestamp| > 300 then   3:     return ⊥                                                                                               ▹Nonce expired   4: end if                                                                                                          ▹Step 2: Check for replay   5: if $\eta \in$ Nonce_Cache then   6:     return ⊥                                                                                             ▹Replay detected   7: end if   8: Nonce_Cache.Add(η)                                                                                                ▹Step 3: Reconstruct keystream   9: $policy\text{\_}i{d}_{bytes}\leftarrow$ UTF-8.Encode(policy_id) 10: $prf\text{\_}input\leftarrow policy\text{\_}i{d}_{bytes} \Vert \eta$ 11: $PRK\leftarrow$ HMAC-SHA-256$(“\text{MAPE-ZT-v1}”,K_{se})$ 12: $L_{ct}\leftarrow \left|C{T}_{wrapped}\right|$ 13: $keystream\leftarrow$ HKDF-Expand(PRK, pr f_input, Lct)                                                                                                  ▹Step 4: XOR decapsulation 14: $C{T}_{abe}\leftarrow C{T}_{wrapped}\oplus keystream$                                                                                                      ▹Step 5: CP-ABE decryption 15: $\mathcal{P}\leftarrow$ CP-ABE.Decrypt(SKuser, CTabe) 16: return  $\mathcal{P}$

The encapsulation layer also protects the ciphertext using a keystream from the HKDF and XOR wrapping. Even if an adversary was able to recover the content of the policy or identify ciphertexts without the knowledge of the access structure, it could indicate at least one of the following:

1.

PRF security of HMAC-SHA256 is broken;

2.

Security guarantees of HKDF are violated;

3.

IND-CPA security of AES-256-GCM is compromised.

Therefore, under the given assumptions and the secrecy of the master key, the adversary’s advantage is not sufficient. As a result, the proposed pairing-free approach provides semantic security as well as cryptographic access control properties. It shifts the traditional foundation of dependency on bilinear pairings towards symmetric-key approaches.

3.1.4. Final Storage Structure

The final storage structure in Equation (8) represents the complete encrypted policy package. The ciphertext ($C_2$) contains doubly encrypted policy content. On the other hand, the metadata includes all necessary components for authorized decryption: encrypted attribute keys (EK) for CP-ABE access control, two nonces for the respective encryption layers, an authentication tag for integrity verification, and the plaintext access policy that defines authorization requirements. This structure provides efficient access control evaluation without requiring decryption of the policy content itself. In practice, policies could be stored in a database, preferably a schema-less NoSQL database, until further requested [53,54].

$$\mathrm{StoredPolicy}=\{\begin{array}{lll}\mathrm{ciphertext}:& C_2& \\ \mathrm{metadata}:& \{\begin{array}{ll}\text{encrypted\_keys}:& \mathrm{EK}\\ {\mathrm{nonce}}_1:& {\mathrm{nonce}}_1\\ {\mathrm{nonce}}_2:& {\mathrm{nonce}}_2\\ \mathrm{tag}:& \mathrm{tag}\\ \text{access\_policy}:& \mathrm{flat} \mathrm{string} \mathrm{or} \{\mathtt{op},\mathtt{children}\} \mathrm{tree}\end{array}\end{array}$$

(8)

3.2. Decryption Process Flow

The decryption steps reverse the overall decryption steps. Details are highlighted below:

3.2.1. Phase 1: Secure Search

The decryption process begins with a secure search using Algorithm 6. For a user query $\mathcal{Q}=\{k{w}_1,k{w}_2,\dots ,k{w}_k\}$, the system generates query trapdoors, similar to Equation (9).

$$T\left(k{w}_i\right)=\text{HMAC-SHA}256(K_{\mathrm{trap}},k{w}_i)\mathrm{for}\mathrm{each}k{w}_i\in \mathcal{Q}$$

(9)

Algorithm 6 Trapdoor search

Require:  Query keywords $\mathcal{Q}$, Index $\mathcal{I}$ Ensure:  Matching policy IDs $\mathcal{M}$   1: Initialize $\mathcal{M}\leftarrow \varnothing$, $first\leftarrow \mathrm{True}$   2: for each keyword $kw\in \mathcal{Q}$ do   3:     Compute $t\leftarrow \mathrm{HMAC}\text{-}\mathrm{SHA}256(K_{\mathrm{trap}},kw)$   4:     if $t\in \mathcal{I}$ then   5:         if $first=\mathrm{True}$ then   6:            $\mathcal{M}\leftarrow \mathcal{I}\left[t\right]$   7:            $first\leftarrow \mathrm{False}$   8:         else   9:            $\mathcal{M}\leftarrow \mathcal{M}\cap \mathcal{I}\left[t\right]$ 10:         end if 11:     else 12:         $\mathcal{M}\leftarrow \varnothing$ and break 13:     end if 14: end for     return  $\mathcal{M}$

The set intersection operation in Equation (10) finds policies that contain ALL query keywords by computing the intersection of policy sets associated with each keyword’s trapdoor. For example, if an access request contains [“role:admin”, “department:IT”], the system finds policies that appear in both the “role:admin” policy list AND the “department:IT” policy list. It only returns the policies that match the complete query criteria. This maintains privacy in search patterns using the trapdoor mechanism.

$$\mathrm{MatchingPolicies}=\bigcap _i\mathrm{Index}\left[T\left(k{w}_i\right)\right]$$

(10)

This operation identifies policies that contain all query keywords without revealing search patterns to the server. It also includes early termination optimization if any trapdoor returns an empty set. In such cases, the intersection is immediately empty.

The index $\mathcal{I}$ is created during the encryption phase. It is implemented as a Python’s defaultdict(list). It is used as a hash table that maps trapdoor hex strings to lists of policy IDs (defaultdict mapping trapdoor → posting list). Each policy $p_i$ is tokenized into keywords. Each keyword’s trapdoor is mapped to its corresponding policy identifier. The index stores $\mathcal{I}\left[T\left(kw\right)\right]+=\left\{p_i\right\}$ for each policy $p_i$ and its keyword $kw\in p_i$. This pre-computation ensures that at query time, each trapdoor lookup $\mathcal{I}\left[T\left(k{w}_i\right)\right]$ operates in $O\left(1\right)$. As a result, the overall search complexity becomes $O\left(\right|\mathcal{Q}|+|\mathcal{M}\left|\right)$, where $\left|\mathcal{Q}\right|$ and $\left|\mathcal{M}\right|$ represent the number of query keywords and the number of matching policies, respectively. The search converts posting lists to Python’s set objects. The posting lists are sorted by size before intersection, such that the smallest set is processed first. It reduces the number of comparisons in subsequent intersection steps and helps to increase the performance. This optimization is equivalent to the standard optimization in conjunctive query processing. Thus, the intersection over set objects sorted in descending order with early termination gives $O\left(\right|Q\left|\right|L_{m}in\left|\right)$ intersection cost, where $|L_{m}in|$ represents the smallest posting length of the list. This index is only computed once at the time of encryption. It remains fixed for all the subsequent queries. As a result, the per-query cost is independent of the number of policies n.

3.2.2. Phase 2: User Key Generation and Authorization

For each matching policy, the system performs attribute-based authorization using the user’s attributes $\mathcal{U}=\{{\mathrm{attr}}_1:{\mathrm{val}}_1,\dots ,{\mathrm{attr}}_{\mathcal{\ell }}:{\mathrm{val}}_{\mathcal{\ell }}\}$. The user attribute keys are generated using Equation (11). It creates attribute-specific keys for each user attribute. It is done by combining the master key with a standardized attribute string format. This process ensures that only users with the exact attribute-value combinations required by a policy can generate the correct keys needed for decryption. The “attr_” prefix and “:” separator create a consistent key derivation format that prevents collision attacks and ensures attribute specificity. In addition, this approach provides the flexibility to discard all the user’s keys with the change of master key. It is an important feature in ZT for key rotation, as it mitigates the inherent limitations of centralized key management systems. Logging keys and key-issuance events can also enable auditable key-issuance.

$$\mathrm{UserKey}\left[{\mathrm{attr}}_i:{\mathrm{val}}_i\right]=\text{HMAC-SHA256}(K_{\mathrm{master}},“\mathrm{attr}\text{\_}”+{\mathrm{attr}}_i+“:”+{\mathrm{val}}_i)$$

(11)

The system then evaluates the access policy using Algorithm 7 and supports three complexity levels:

• Simple Policies: Require exact attribute matching using AND logic; ≤5 attributes; no nested logic.
• Medium Policies: Support OR groups with AND operations within groups; 6–20 attributes; up to 3 levels of nesting.
• Complex Policies: Uses fuzzy matching with the 70% attribute satisfaction threshold; >20 attributes; >3 nesting levels; includes wildcards/negations/dynamic attributes.

Simple policies require complete attribute matching, medium policies evaluate OR groups for flexible alternatives, and complex policies use percentage-based matching for sophisticated multi-factor scenarios. Similar to the above policy types, each one of them is parsed through respective methods. Three different evaluation functions are used for the respective policy types. The adaptive decryption strategy changes the evaluation strategy based on the complexity of the policy. It reduces unnecessary computation for simple policies and properly handles the complex ones.

EvaluateSimple() handles simple policies by checking if the user has all required attributes. It immediately rejects if any attribute is missing and performs the minimal necessary operations. EvaluateMedium() handles the medium policies and uses cached results when the same attribute appears multiple times. On the other hand, the EvaluateComplex() handles the most complex type policies that contain attributes that are evaluated in runtime, such as context-based, time-based, etc. In addition, policies expressed as structured attribute trees (with explicit AND/OR nodes and leaf attribute conditions) are evaluated using a dedicated recursive function EvaluateRecursive(). Its working is presented in Algorithm 8. It traverses the tree bottom-up and applies short-circuit evaluation at each node. This is fully backward-compatible with the flat string policy format.

Algorithm 7 Policy evaluation

Require:  Access policy $\mathcal{AP}$, User key $\mathcal{UK}$ Ensure:  Authorization decision $auth$   1: Extract $\mathcal{PA}\leftarrow \mathrm{ExtractAttributes}\left(\mathcal{AP}\right)$   2: Get $\mathcal{UA}\leftarrow \mathrm{keys}\left(\mathcal{UK}\right)$   3: Determine policy format and complexity:   4: if $\mathcal{AP}$ is a structured tree (dict with op/children/attr keys) then   5:     $auth\leftarrow \mathrm{EvaluateRecursive}(\mathcal{AP},\mathcal{UA})$   6:     return $auth$   7: end if                    ▹ Flat string format: determine complexity by keyword presence   8: if  $“\mathrm{AND}”\in \mathcal{AP}$ and $“\mathrm{OR}”\in \mathcal{AP}$  then   9:     $complexity\leftarrow “\mathrm{complex}”$ 10: else if  $“\mathrm{OR}”\in \mathcal{AP}$  then 11:     $complexity\leftarrow “\mathrm{medium}”$ 12: else 13:     $complexity\leftarrow “\mathrm{simple}”$ 14: end if 15: Evaluate based on complexity: 16: if  $complexity=“\mathrm{simple}”$  then 17:     $auth\leftarrow \mathrm{EvaluateSimple}(\mathcal{PA},\mathcal{UA})$ 18: else if  $complexity=“\mathrm{medium}”$  then 19:     $auth\leftarrow \mathrm{EvaluateMedium}(\mathcal{AP},\mathcal{UA})$ 20: else 21:     $auth\leftarrow \mathrm{EvaluateComplex}(\mathcal{PA},\mathcal{UA})$ 22: end if     return  $auth$

Algorithm 8 Recursive policy tree evaluation

Require:  Policy tree node $\mathcal{N}$, User attribute dict $\mathcal{UA}$ Ensure:  Authorization decision $auth\in \{\mathrm{True},\mathrm{False}\}$   1: if $\mathcal{N}$ is a leaf node (contains key attr) then   2:     Parse $k,v\leftarrow \mathrm{Split}(\mathcal{N}.\mathtt{attr},\mathtt{“}\mathtt{:}\mathtt{”})$   3:     return $\mathcal{UA}\left[k\right]=v$   4: end if   5: $op\leftarrow \mathcal{N}.\mathtt{op}$   6: $children\leftarrow \mathcal{N}.\mathtt{children}$   7: if  $op=“\mathrm{AND}”$  then   8:     for each child $c\in children$ do   9:         if $\mathrm{EvaluateRecursive}(c,\mathcal{UA})=\mathrm{False}$ then 10:            return False                                                                            ▹ Early termination 11:         end if 12:     end for 13:     return True 14: else if  $op=“\mathrm{OR}”$  then 15:     for each child $c\in children$ do 16:         if $\mathrm{EvaluateRecursive}(c,\mathcal{UA})=\mathrm{True}$ then 17:            return True                                                                            ▹ Early termination 18:         end if 19:     end for 20:     return False 21: end if 22: return False

3.2.3. Phase 3: Multi-Layer Decryption

Upon successful authorization, the system performs reverse decryption using Algorithms 9 and 10. They are used to decrypt the policies by reversing the process of both encrypted layers.

Algorithm 9 CP-ABE decryption

Require:  Ciphertext $C_2$, Metadata $meta$, User key $\mathcal{UK}$ Ensure:  Decrypted data D or ⊥ (failure)   1: Extract $\mathcal{EK}\leftarrow meta.\mathrm{encrypted}\text{\_}\mathrm{keys}$   2: Extract $n_2\leftarrow meta.\mathrm{nonce}$, $tag\leftarrow meta.\mathrm{tag}$   3: Parse $\mathcal{PA}\leftarrow \mathrm{ExtractAttributes}(meta.\mathrm{policy})$   4: Find satisfying attribute:   5: $satisfying\leftarrow \perp$   6: for each attribute $attr\in \mathcal{PA}$ do   7:     if $attr\in \mathcal{UK}$ then   8:         $satisfying\leftarrow attr$ and break   9:     end if 10: end for 11: if  $satisfying$ = ⊥ then return ⊥ 12: end if 13: Decrypt symmetric key: 14: $encrypted\text{\_}key\leftarrow \mathcal{EK}\left[satisfying\right]$ 15: $attr\text{\_}key\leftarrow \mathcal{UK}\left[satisfying\right]$ 16: $K_2\leftarrow encrypted\text{\_}key\oplus attr\text{\_}key$ 17: Decrypt data: 18: try 19: $D\leftarrow {\text{AES-GCM-Decrypt}}_{K_2}(C_2,n_2,tag)$ 20: catch DecryptionError 21: return ⊥ 22: end try      return  D

Algorithm 10 Policy decryption

Require:  Query $\mathcal{Q}$, User attributes $\mathcal{U}$, Database $\mathcal{EPD}$, Index $\mathcal{I}$, Key $K_{\mathrm{se}}$ Ensure:  Authorized policies $\mathcal{AP}$   1: Phase 1: Search   2: Compute $\mathcal{M}\leftarrow \mathrm{TrapdoorSearch}(\mathcal{Q},\mathcal{I})$   3: Phase 2: Generate User Key   4: Compute $\mathcal{UK}\leftarrow \mathrm{GenerateUserKey}\left(\mathcal{U}\right)$   5: Phase 3: Decrypt Authorized Policies   6: Initialize $\mathcal{AP}\leftarrow \varnothing$   7: for each policy id $pid\in \mathcal{M}$ do   8:     Retrieve $(C_2,meta,n_1)\leftarrow \mathcal{EPD}\left[pid\right]$   9:     if $\mathrm{EvaluatePolicy}(meta.\mathrm{policy},\mathcal{UK})=\mathrm{True}$ then 10:         Decrypt $C_1\leftarrow \mathrm{CPABE}\text{-}\mathrm{Decrypt}(C_2,meta,\mathcal{UK})$ 11:         if $C_1\ne \perp$ then 12:            Symmetric Decryption: 13:            Reconstruct $counter\leftarrow n_1\parallel 0^{32}$ 14:            Generate $stream\leftarrow {\mathrm{AES}}_{K_{\mathrm{se}}}\left(counter\right)$ 15:            Decrypt $text\leftarrow C_1\oplus stream$ 16:            Parse $p\leftarrow \mathrm{JSON}\text{-}\mathrm{Parse}\left(text\right)$ 17:            Add $\mathcal{AP}\leftarrow \mathcal{AP} \cup \left\{p\right\}$ 18:         end if 19:     end if 20: end for       return  $\mathcal{AP}$

CP-ABE Decryption

The system identifies a satisfying attribute ${\mathrm{attr}}_s$ where ${\mathrm{attr}}_s\in \mathrm{UserKey}$ and recovers the symmetric key, as depicted in Equation (12).

$$K_2=\mathrm{EK}\left[{\mathrm{attr}}_s\right]\oplus \mathrm{UserKey}\left[{\mathrm{attr}}_s\right]$$

(12)

Using the recovered key, it decrypts the AES-GCM layer using Equation (13).

$$C_1=\text{AES-GCM-Decrypt}(K_2,C_2,{\mathrm{nonce}}_2,\mathrm{tag})$$

(13)

Symmetric Decryption

Finally, the system decrypts the inner AES-CTR layer using Equations (14) and (15).

$$\begin{array}{cc}\hfill \mathrm{PolicyJSON}& =\text{AES-CTR-Decrypt}(K_{\mathrm{se}},C_1,{\mathrm{nonce}}_1)\hfill \end{array}$$

(14)

$$\begin{array}{cc}\hfill \mathrm{OriginalPolicy}& =\text{JSON-Parse}\left(\mathrm{PolicyJSON}\right)\hfill \end{array}$$

(15)

4. Findings and Results

4.1. System Comparison

A brief comparison was simulated against traditional Role-Based Access Control (RBAC), basic encryption methodology, and IAM to test the performance of the approach. The traditional RBAC system was simulated using the TraditionalRBACSimulator class, which implements a simplified Role-Based Access Control model [55]. The test environment for all the simulations is similar for a fair test. In addition, processes are executed sequentially, such that the second process is executed only after the completion of the first one. This ensures correct execution and prevents unintended interference between the two processes. The simulation criteria included the following:

• Role-permission mapping: Five predefined roles (admin, manager, analyst, user, and guest) were used with hierarchical permissions.
• Access control logic: Simple Boolean checks in which users are granted access based solely on their role.
• Performance measurement: Access checks performed without any encryption overhead.

The basic encryption system simulation focused on AES encryption without access control. Its performance was assessed only through the encryption/decryption times, as the absence of access control gives a success rate of 100%. The IAM simulation represented typical IAM solutions in the enterprise that provide appropriate access to the right users at the right time [56,57]. During the analysis, access control and encryption were evaluated. The comparison among all is presented in

Table 3. Comparison among different security systems.

Approach	Encryption Time (s)	Avg. Access Time (s)	Access Success Rate (%)
Zero Trust	0.7967	0.0085	0.97
Traditional RBAC	0	0	0.8
Basic Encryption	0.1182	0	1
Enterprise IAM	1.195	0.0068	0.8

. The encryption time refers to the time required to encrypt the entire policy database (in seconds). The avg access time refers to the average time required to process a single access request (in seconds). The access success rate refers to the percentage of access requests that result in successful authorization.

It can be observed that the ZT delivers superior security as compared to others with reasonable performance trade-offs. It encrypts policies ∼33% faster than Enterprise IAM. Although IAM outperforms ZT by 25% at 0.0068 s, ZT demonstrates competitive performance despite cryptographic operations. With a success rate of 97%, ZT indicates an optimal balance between security and usability. It outperforms traditional RBAC and IAM by ∼17%. Basic encryption achieves 100% success by granting universal access after authentication. It violates the principles of least privilege. Although it reduces the access time, it is not preferable in practice. Such approaches usually provide binary access decisions (authorized vs unauthorized) and do not provide attribute-level, role-based restrictions, etc. Any change in policy may require re-keying or re-encrypting resources. Once a key is shared or misused, it is difficult to know which user accessed which data. The 3% denial rate in ZT reflects a conservative policy evaluation. A non-zero denial rate shows that access decisions are not liberal in nature. It also highlights that the policy evaluation approach is working as intended by filtering borderline or non-compliant requests. On the other hand, the 20% denial rate in traditional systems suggests rigid role hierarchies that inadequately support dynamic business needs. It highlights that ZT can maintain a limited tradeoff in terms of access time and success rate while maintaining security. In addition, it shows that the approach is more conservative in nature than optimized solely for maximum acceptance.

4.2. Policy Scalability

It is important to test the scalability of the approach to quantify optimal performance.

Table 4. Trends in policy scalability.

Metric	100	500	1000	2500	5000	7500	10,000
Encryption Time (s)	0.0477	0.0919	0.2071	0.7036	2.0733	4.2516	7.3284
Search Time (ms)	0.28	1.29	2.5	6.3	13.37	21.32	28.18
Trapdoor Lookup (ms)	0.0123	0.033	0.0553	0.1623	0.4769	0.6573	0.8749
Throughput	3594.4	775.87	399.27	158.85	74.79	46.9	35.48
Before Encryption (KB)	122.1	616	1227.7	3064.6	6130.4	9193.4	12,259.8
After Encryption (KB)	162.9	820.5	1636.9	4086.2	8175.6	12,261.4	16,349.1
Avg Policy Size (B)	1250.6	1261.5	1257.2	1255.3	1255.5	1255.2	1255.4
Storage Overhead (%)	33.4	33.2	33.3	33.3	33.4	33.4	33.4

depicts the scalability of MAPE-ZT when tested with a different number of policies. The policies were generated synthetically using Python for a given set of attributes. The encryption time refers to the total time required to encrypt all policies (in seconds). The search time refers to the average time (in milliseconds) to search and retrieve the matching policies. The throughput represents the number of search-decryption operations the system can handle per second.

The analysis presents predictable linear growth patterns. The encryption time scales linearly with the policy count. It maintains ∼1300–2100 policies per second regardless of the size of the database. This consistency indicates the efficiency of the encryption algorithm and the absence of quadratic complexity issues. The search performance shows degradation as the dataset grows. The search time increases from 0.28 to 28.18 ms. It shows a 100× increase for an increase in data of 100×. It suggests logarithmic complexity in the search algorithm. As a result, throughput also decreases linearly. Memory usage grows efficiently and requires only 16 MB for 10,000 policies. This indicates an effective data structure design. Storage overhead remains remarkably consistent at 33.2–33.4% for all scales. This overhead consists of two nonces (SSE, CP-ABE) of 12 bytes each, a GCM authentication tag of 16 bytes to detect tampering, and one encrypted key ($\mathcal{EK}$ entry) of 32 bytes per policy attribute. The variable metadata structure of the policy consists of another 66 bytes based on the policy string and dictionary structure overhead. It could be reduced further by efficient serializing. For conjunctive (AND-only) policies with two attributes, this amounts to 170 bytes of overhead, giving ∼33–34% for a 500-byte policy. Policies expressed as OR-trees carry one additional $\mathcal{EK}$ entry per extra attribute branch (32 bytes each), raising overhead to ∼40% for three-attribute policies. The average overhead can be amortized for larger policies. For example, a conjunctive policy of size 1000 and 2000 bytes will face additional storage overheads of 17% (170/1000) and 8.5% (170/2000), respectively. On the other hand, the overhead for OR-tree policies increases proportionally with the number of attributes.

The approach was evaluated under five multiple runs using the same metrics. It was done to test the consistency and reliable performance of the model. The results for the same are presented in

Table 5. Multiple-run scalability analysis.

Metric	100	500	1000	2500	5000	7500	10,000
Encryption Time (s)	0.024 ± 0.003	0.092 ± 0.003	0.206 ± 0.006	0.709 ± 0.025	2.093 ± 0.070	4.178 ± 0.188	6.784 ± 0.015
Search Time (ms)	0.286 ± 0.003	1.271 ± 0.022	2.492 ± 0.013	6.329 ± 0.082	13.832 ± 0.703	20.814 ± 0.183	28.436 ± 0.491
Trapdoor Lookup (ms)	0.013 ± 0.001	0.038 ± 0.003	0.058 ± 0.005	0.181 ± 0.017	0.523 ± 0.093	0.677 ± 0.071	0.944 ± 0.101
Throughput (ops/sec)	3494.956 ± 42.314	786.781 ± 13.703	401.303 ± 2.124	158.028 ± 2.051	72.437 ± 3.488	48.047 ± 0.421	35.175 ± 0.608
Before Encryption (KB)	123.170 ± 0.301	613.945 ± 1.766	1225.369 ± 1.742	3063.670 ± 1.681	6131.054 ± 2.205	9195.185 ± 5.000	12,258.526 ± 2.565
After Encryption (KB)	164.155 ± 0.553	818.319 ± 1.792	1634.214 ± 2.040	4085.182 ± 2.060	8175.038 ± 2.278	12,261.351 ± 5.159	16,346.533 ± 2.147
Avg Policy Size (B)	1261.264 ± 3.084	1257.360 ± 3.616	1254.778 ± 1.784	1254.879 ± 0.689	1255.640 ± 0.452	1255.449 ± 0.683	1255.273 ± 0.263
Storage Overhead (%)	33.275 ± 0.159	33.289 ± 0.096	33.365 ± 0.025	33.343 ± 0.016	33.338 ± 0.014	33.345 ± 0.020	33.348 ± 0.016

. The encryption time was observed to grow proportionally as observed earlier. The search time was also observed to increase gradually and remained within practical limits, even with 10,000 policies. It required 28.4 ± 0.5 ms search time. It highlights that the trapdoor-based retrieval and indexing mechanisms are efficient and do not cause excessive lookup overhead. The decrease in throughput (i.e., from ∼3495 to ∼35 ops/s) was smooth and controlled rather than being abrupt. This indicates the operational stability of the model under increased load. It shows the effectiveness of lightweight XOR-based encapsulation and the efficient key derivation process in reducing additional processing. In addition, the storage overhead and average size of the policy were observed to stay consistent around 1254–1261 bytes. It shows that the encryption and encapsulation process introduces a fixed and predictable expansion. The low standard deviation for all metrics highlights the reliability and reproducibility of the approach. The low variation indicates the approach is not influenced by random fluctuations and the results are not by luck.

4.3. Access Control Accuracy

The results for the access control accuracy patterns are presented in

Table 6. Variations in performance of access control.

Query Type	Simple Role	Department	Multi-Attribute	Complex
Accuracy (%)	96.6	96.7	96.4	96.3
Precision (%)	100	100	100	100
Avg Total Decision (ms)	5.4	5.46	5.61	5.76
Avg Search Trapdoor (ms)	0.0766	0.0771	0.1767	0.2923
Avg Decrypt (ms)	0	0	0	0
Decisions per s	185.1	183.2	178.3	173.8

. All query types achieve high accuracy rates of 96.3–96.7%. It indicates robust policy evaluation mechanisms. The consistent precision of 100% in all scenarios suggests that the system adopts a cautious approach by avoiding the risk of unauthorized access. The slight decrease in accuracy is due to intentional mismatched attributes of 30%. This behavior simulates real-world scenarios, such as expired roles, insufficient clearance levels, etc. Decision times remain consistent for query types around 5.4–5.7 ms. It shows minimal variation despite increasing complexity. This suggests that the system scales well algorithmically. The complex query scenario shows only a ∼6.6% increase in decision time compared to the simple role query. In addition, the other metrics with low variations indicate the efficient handling of multi-attribute evaluations.

4.4. Analysis Policy Size

The analysis of policy size shows that the complexity of the policy has a minimal impact on encryption overhead. All of the categories of policies achieve nearly similar storage overhead. This suggests the efficiency of the encryption scheme in different policy structures. In addition, the additional storage overhead of 33.2–33.4% is a modest cost for multi-layered encryption protection in large organizations. This consistency is valuable for deployment planning. Organizations can predict storage requirements regardless of the sophistication of the policy.

4.5. Scalability Impact on Observable Patterns

The proposed MAPE-ZT is analyzed with various statistical metrics to evaluate its efficacy and ensure privacy. Different quantitative measures are used to evaluate the approach in different deployment scenarios. Three experimental configurations are used to evaluate the leakage on different scales of system:

• Small: 500 policies, 50 users, 200 queries.
• Medium: 1000 policies, 100 users, 500 queries.
• Large: 2000 policies, 200 users, 1000 queries.

These configurations simulate different deployment scenarios. Users with different attributes query encrypted policies based on their roles and departments. In addition, it contains 30% repeated queries, since users usually submit similar requests. Different metrics are used to evaluate the different aspects of information leakage. They are as follows:

• User Query Diversity: It measures the diversity of queries issued by each user. It can be calculated as the average ratio of unique queries to total queries per user. It is presented in Equation (16).

  $$D_{user}={\displaystyle \frac{1}{\left|U\right|}}\sum _{u\in U}{\displaystyle \frac{|Q_u^{unique}|}{|Q_u^{total}|}}$$

  (16)

  where U is the user set, $Q_u^{unique}$ are distinct queries by user u, and $Q_u^{total}$ are all queries by u. This metric is important for assessing risk profile. A low diversity score indicates that the behavior of the user is predictable. This makes it easier for adversaries to identify the user’s access pattern and infer the roles or other details.
• Co-occurrence Strength: It measures how frequently pairs of policies together appear in the same result set. For each query returning policies $R=\{p_1,p_2,\dots ,p_k\}$, all policy pairs are counted and computed using Equation (17).

  $$S_{cooc}={\displaystyle \frac{1}{{\left|P\right|}^2}}\sum _{p_i\in P}\sum _{p_j\in P,j\ne i}count(p_i,p_j)$$

  (17)

  where $count(p_i,p_j)$ is the number of times that policies $p_i$ and $p_j$ appear in the same set of results. It ensures structural information on the relationships of policies. High occurrence indicates dependencies that could be exploited to gain knowledge about the semantics of policies.
• Result Count Entropy: It quantifies the unpredictability of the result set using Shannon entropy. It can be evaluated using Equation (18).

  $$H_{count}=-\sum _{c\in C}P\left(c\right){log}_{2}P\left(c\right)$$

  (18)

  where C is the set of observed result counts and $P\left(c\right)$ is the probability of the observed count c. It is measured in bits. This metric helps to identify how many different result size patterns exist. For example, an entropy of 4 bits suggests ∼$2^4=16$ unique result size patterns. Higher entropy indicates make inference of query type more difficult.

The combination of these metrics helps to quantify the abstract concepts of privacy to measurable and comparable values. In addition, the use of standardized metrics ensures a fair comparison with other future schemes.

Table 7. Results of the statistical analysis of the observable patterns.

Metric	Small Scale	Medium Scale	Large Scale
	(500 Policies)	(1000 Policies)	(2000 Policies)
User Query Diversity	0.821	0.827	0.835
Co-occurrence Strength	1.538	1.491	1.479
Result Count Entropy (bits)	3.84	4.02	4.21
Size Entropy (bits)	3.84	4.02	4.21

presents the comprehensive results on leakage analysis. Various metrics are used to evaluate the efficacy of the cryptosystem.

The user query diversity was observed to improve consistently. It increased from 0.821 to 0.835 in small–large scale scenarios. It represents an improvement of 1.7%. This trend suggests that larger systems naturally encourage more varied query behavior. This makes it difficult for adversaries to log into user-level behavioral patterns. Similarly, the co-occurrence strength was observed to decrease with the increase in load. A decrease of 3.8% was observed for the transition to large systems. As the number of policies grows, the number of possible combinations also increases, which reduces the chances of repeating any policy repeating. As the system grows, this scaling behavior reduces structural leakage because repeated policy pairings appear less often. As a result, it becomes difficult for an adversary to deduce semantic relationships between encrypted policies in larger deployments. In addition, the entropy was observed to achieve a positive trend. The entropy was found to increase from $3.84$ bits in small systems to $4.21$ bits in large systems. An improvement of $9.6\%$ was observed. It is calculated using Shannon’s entropy over the distribution of result set sizes for all queries. Larger deployments achieve more diverse result size distributions. The mutual information $I(Query;|Result\left|\right)$ is upper bounded by $H\left(\right|Result\left|\right)$, the entropy of the result-size distribution. In the evaluation vocabulary, $H\left(\right|Result\left|\right)\le lo{g}_2\left(\right|V\left|\right)\approx 4.6 bits$. As a result, it increases adversarial uncertainty about query selectivity. In terms of information theory, the increase from $2^{3.84}\approx 14$ to $2^{4.21}\approx 18$ effective outcome categories indicates a measurable increase in unpredictability as the size of system increases. It highlights that the proposed approach is resilient against various cyberattacks while maintaining suitable randomness for difficult cryptanalysis.

4.6. Statistical Analysis

In order to validate the reliability and significance of the observed performance differences, a comprehensive statistical analysis has been conducted. It includes descriptive analysis, paired t-tests, and one-way ANOVA. These results evaluate performance differences in the proposed approach and other baselines. It suggest that results are meaningful and are not due to random variation. All the models were executed again to validate the results and its repeatability under identical experimental conditions. However, there could be few numerical variations due to internal CPU factors, such as cache effects, interference of background processes, etc.

A descriptive statistical analysis has been conducted to verify the reliability of the results. The results are based on five independent runs. The Coefficient of Variation (CV) for MAPE-ZT was observed to be below 4% for all metrics other than success rate. It shows slightly higher variability. This shows very low variability and high reliability. On the other hand, traditional RBAC was observed to achieve higher variability in throughput. On the other hand, basic encryption showed low variability for all metrics. In addition, RBAC achieves zero encryption time due to the absence of cryptographic protection of policies. As a result, the negative results are due to those absent features in traditional approaches that were present in the ZT. The 95% confidence interval for the proposed approach was observed to be narrow for all timing and throughput metrics. It indicates that the performance of the approach is reproducible and behaves consistently.

Paired t-tests were also conducted between the proposed system and each baseline approach. It determines whether the observed performance differences are statistically significant. The results for the same are presented in

Table 8. Statistical test: paired t-test.

Comparison	Metric	t-Statistic	p-Value	Significant ($\mathit{\alpha }$ = 0.05)	Cohen’s d	Effect Size	Improvement (%)
ZT vs RBAC	Avg Access Time	146.3185	0	Yes	92.542	Large	−658,243.32
	Avg Search Time	66.8795	0	Yes	42.3219	Large	−9979.91
	Throughput	−41.9976	0	Yes	−26.5616	Large	99.98
	Success Rate	−21.5	0	Yes	−13.5978	Large	53.75
ZT vs Basic Encryption	Avg Access Time	146.0529	0	Yes	92.2067	Large	−26,406.02
	Avg Search Time	54.1071	0	Yes	32.144	Large	−305.83
	Throughput	−244.9993	0	Yes	−154.1823	Large	99.62
	Success Rate	−31.5	0	Yes	−19.9223	Large	63
ZT vs Enterprise IAM	Avg Access Time	134.6486	0	Yes	12.9417	Large	−25.11
	Avg Search Time	67.5973	0	Yes	41.8888	Large	−4900
	Throughput	−56.0227	0	Yes	−12.4388	Large	20.08
	Success Rate	−24	0	Yes	−15.1789	Large	56.47

. The p-values for the compared approaches are effectively zero ($p\approx 0$) and less than 0.05. It shows that the observed differences are statistically significant. Comparison of the success rate between the proposed ZT and RBAC shows significant improvement. The basic encryption approach achieves a higher success rate because it does not enforce strict access control policies. The proposed ZT intentionally enforces stringent access conditions with an intentional denial rate. In addition, the large Cohen’s d effect size values observed in the comparisons indicate that the differences are not only statistically significant but practically meaningful as well.

To further validate the differences for all systems, a one-way ANOVA test was conducted for the performance metrics. The results for the same are presented in

Table 9. ANOVA statistical significance results.

Metric	F-Statistic	p-Value	Significance
Avg Access Time	11,450.6699	0	Yes
Avg Search Time	3963.2976	0	Yes
Throughput	1719.4399	0	Yes
Success Rate	731	0	Yes

. It indicates statistically significant differences for all evaluated metrics with p-value < 0.05. The extremely high F-statistic values (F = 731–11,450) indicate that the differences in performances are substantial and not caused due to random variations.

4.7. Mitigation Against Various Cyberattacks

The proposed MAPE-ZT is secure against various cyberattacks, as illustrated in

Table 10. Mitigation against various cybersecurity attacks by MAPE-ZT.

SL	Attack Name	Protecting Component	How Protection Works
1	Search Pattern Analysis	Trapdoor Index	HMAC-SHA256 generates unlinkable trapdoors. The server sees random hashes, preventing correlation.
2	Frequency Analysis	Multi-tier Keywords	Each policy generates 5–15 diverse keywords, preventing frequency-based inference.
3	Chosen Plaintext Attack	AES-CTR + Random Nonces	96-bit random nonces ensure different ciphertexts for identical plaintexts.
4	Insider Privilege Escalation	CP-ABE Access Control	Cryptographic attribute proof required. Failed access reveals zero information.
5	Replay Attack	Nonce-Based Freshness	Unique 96-bit nonce per encryption. Deterministic trapdoor replay detection.
6	Man-in-the-Middle	AES-GCM Authentication	Authenticated encryption provides confidentiality and integrity verification.
7	Side-Channel Attack	Constant-Time Operations	XOR operations and HMAC resist timing attacks. No secret-dependent branches.
8	Brute Force Attack	Keyspace	Combined keyspace of $2^{1024}$ makes brute force computationally infeasible.
9	Differential Cryptanalysis	AES-256 + CTR Mode	Random nonces prevent differential analysis. AES-256 immune to known attacks.
10	Cache-Based Attack	Uniform Memory Access	All attributes are processed identically. XOR prevents cache timing leakage.
11	Key Escrow Demands	Distributed Key Architecture	Four independent 256-bit keys. No single master key compromises the system.
12	Advanced Persistent Threat	Key Rotation + Audit Logs	Regular key updates limit the compromise window. Complete operation tracking.
13	Dictionary Attack	Salted Attribute Keys	Each attribute key is derived as $\mathrm{HMAC}(K_{\mathrm{master}},\mathtt{attr}.\mathtt{lower}\left(\right))$, binding derivation to $K_{\mathrm{master}}$ and making offline dictionary attacks infeasible without it.
14	Collision Attack	SHA-256 Collision Resistance	HMAC-SHA256 provides $2^{128}$ collision resistance for trapdoors.
15	Timing Attack	Constant-Time XOR	XOR-based key encapsulation executes in constant time.
16	Memory Disclosure	On-Demand Key Derivation	Keys derived using HMAC when needed. No long-term key storage.

. The security analysis consists of both external threats and internal threats. Each identified attack vector is addressed through specific cryptographic countermeasures that ensure robust protection for the entire threat landscape. Thus, this approach is a trustworthy approach for modern enterprise access control systems.

4.8. Keyspace Analysis

The combined keyspace of $2^{1024}$ (trapdoor key $K_{\mathrm{trap}}$ (256 bits) + AES-256-CTR key $K_{\mathrm{se}}$ (256 bits) + CP-ABE master key $K_{\mathrm{master}}$ (256 bits) + per-policy AES-GCM key $K_2$ (256 bits)) makes it resilient to various cyberattacks. The probability of successful key-guessing approaches $1/2^{768}$ makes the discovery of random keys computationally infeasible on the current technological scale. Independent key generation for each encryption layer ensures that compromising one key does not weaken the security of the entire system. An attacker would need to simultaneously break all four cryptographic layers to gain complete system access. It creates multiple independent security barriers that exponentially compound the difficulty of the attack.

4.9. Complexity Analysis

The time and space complexities of the MAPE-ZT are given in

Table 11. Computational complexity of each operation in MAPE-ZT.

Operation	Time Complexity
Encryption	$O(n·(k+\left|P\right|\left)\right)$
Search	$O\left(\right|Q|+|M|·|A\left|\right)$
Decryption	$O\left(\right|M|·|A\left|\right)$

and

Table 12. Space complexity for MAPE-ZT.

Component	Space Complexity
Trapdoor Index	$O(n·k)$
Encrypted Database	$O(n·(\left|P\right|+\left|A\right|\left)\right)$
Total Space	$O(n·(k+\left|P\right|+\left|A\right|\left)\right)$

, respectively. The following notations are used for representations:

• n: Number of policies.
• k: Average keywords per policy.
• $\left|P\right|$: Average policy size in bytes.
• $\left|Q\right|$: Number of query keywords.
• $\left|I\right|$: Size of trapdoor index.
• $\left|M\right|$: Number of matching policies.
• $\left|A\right|$: Number of attributes per policy (also the size of the per-policy encrypted key table $\mathcal{EK}$).

4.10. Security Properties

In summary,

Table 13. Security properties and their cryptographic realizations in MAPE-ZT.

Security Property	Security Level	Cryptographic Basis
Trapdoor Unlinkability	$2^{256}$	HMAC-SHA256 one-way function; $K_{\mathrm{trap}}$ is a 256-bit secret key
Semantic Security	$2^{256}$	AES-256-CTR (Layer 1) and AES-256-GCM (Layer 2) pseudorandom permutation
Ciphertext Integrity	$2^{128}$	AES-GCM 128-bit authentication tag provides INT-CTXT
Enforcement of Access Control	Cryptographic	Attribute-based key derivation via $K_{\mathrm{master}}$; policy evaluation via evaluate_policy()
Collusion Resistance	$2^{256}$	$\mathcal{EK}\left[A\right]\oplus \mathcal{EK}\left[B\right]\ne K_2$; recovery requires $K_{\mathrm{master}}$
Search Pattern Privacy	External: $2^{256}$	Token unlinkability to external observers
Forward Secrecy	$2^{96}$ per nonce	Fresh 96-bit nonce per encryption (×2)
Collision Resistance	$2^{128}$	SHA-256 collision resistance
Key Separation	Independent	Four independent 256-bit keys

highlights the various security practices followed in the approach. These security properties collectively ensure that the system maintains confidentiality, integrity, and availability even under various attack scenarios.

This study focuses on securing access policies in ZTAs, which is an overlooked component in various literature. This approach enables cryptographic enforcement of authorization decisions at the encryption layer instead of relying on application-level controls. Unlike binary traditional encryption, where users either possess the decryption key or not, the proposed MAPE-ZT provides access where different users decrypt different policy subsets based on their authenticated attributes using CP-ABE. This makes it ideal for ZT environments that use cryptographically bound access decisions, which can lay an additional layer of security. With a total keyspace of $2^{768}$, MAPE-ZT required only ∼4 s to encrypt 10,000 policies, having an average size of 1258 bytes. The storage overhead of only 33% was increased, which is quite less than for various other algorithms. Although it adds a negligible overhead in access time, the approach enables encryption of the access policy for a comprehensive ZT approach.

5. Conclusions

In this study, MAPE-ZT has been proposed to secure access policies in ZTA. Its multi-layer design uses AES-CTR, HMAC-SHA256, and CP-ABE to secure access policies against unintended access. It aims to address a significant research gap that was found to be missing in various studies. MAPE-ZT was tested against different scenarios to test the efficacy and feasibility of working in a ZT environment. The approach can encrypt ∼1300–2100 policies, irrespective of the database size, with a storage overhead of ∼33.4%. A comparison was conducted among various standalone technologies (using simulations) and found similar or better performance with better security enhancements. MAPE-ZT achieves different security principles, such as confidentiality, integrity, etc., as well as manages to make limited trade-offs between security and performance. In addition, the increase in entropy per bit and various other statistical measures indicate a positive trend with an increase in deployment. In the future, the integration of various emerging technologies, including blockchain for a decentralized audit trail, AI for dynamic decision-making, etc., can strengthen the approach. The utilization and analysis of Oblivious RAM and query obfuscation for policy storage and retrieval can reduce access leakage patterns. A comparative analysis of various HSMs based on performance and overhead to manage keys in ZT-based traffic is a fruitful approach. Supporting threshold and non-monotonic policies via Shamir secret sharing of $K_2$ is a potential work. The skip pointers and Bloom filters can also be integrated to further reduce the cost of trapdoor. In addition, the design of lightweight quantum-safe keys is essential and can be integrated into the proposed design effectively.