Embedding Security Awareness into a Blockchain-Based Dynamic Access Control Framework for the Zero Trust Model in Distributed Systems

Abstract

The Zero Trust (ZT) model is pivotal in enhancing the security of distributed systems by emphasizing rigorous identity verification, granular access control (AC), and continuous monitoring. To address the complexity and scalability challenges of modern distributed systems, we propose a blockchain-based dynamic access control scheme (DACS) as a practical solution for implementing ZT principles. This framework dynamically manages access control lists (ACLs) and enforces policies through smart contracts. In the DACS framework, each blockchain node maintains an object list specifying access permissions within its ACL and incorporates a minimum trust metric (TM) threshold to evaluate access requests. The TM assigned to each node reflects its trustworthiness. To further enhance security, the framework includes security awareness, enabling the dynamic assessment of the risk factor (RF), which reflects the operational risk level. The TM of access-requesting nodes is updated at runtime based on their behavior, with penalties imposed for malicious actions according to the prevailing RF. Access control policies are dynamically adjusted, mitigating risks posed by potentially untrustworthy users with valid credentials. Implemented and tested on the Ethereum blockchain, the proposed DACS framework demonstrates its efficiency and effectiveness in securing distributed systems.

1. Introduction

The proliferation of distributed systems has transformed modern computing, introducing scalable and decentralized architectures that enhance performance, resilience, and availability [1]. However, as the number of interconnected nodes and services grows, security challenges have become increasingly complex. Traditional perimeter-based security models are no longer sufficient to safeguard these intricate environments [2,3]. This shift has driven the adoption of the Zero Trust (ZT) security model, which operates on the principle of “never trust, always verify” [2,4]. In the ZT model, every user, device, and service must continuously authenticate its identity and access rights, irrespective of its location or position within the network.

Implementing ZT in distributed environments requires a context-aware approach to security, making dynamic access control schemes (DACSs) essential [5]. A DACS includes functionality to adjust access policies according to the operational context, reducing the risks of insider threats or suspicious behaviors. Unlike static policies, the DACS adaptively evaluates various factors, such as an actor’s (e.g., user, device, or service) identity, service request patterns, and real-time threat intelligence, to make informed, real-time access decisions [6,7]. This ongoing evaluation allows access rights to be granted or revoked as conditions change [7,8], offering a flexible and strong solution for securing distributed systems under the ZT model [6].

DACS represents a paradigm shift from rigid, predefined policies to flexible, adaptive access management strategies. Effective DACS implementation depends on robust policy management [6,9,10] to smoothly coordinate access control lists (ACLs) with real-time security events [6,7], boosting the system’s ability to adapt and respond to new threats. With increased interaction among components in distributed systems, DACS policy management must be autonomous and integrate security awareness, allowing access policies to adjust dynamically based on the operational risk level [6,7]. Security awareness is like a system’s self-awareness [11,12]. It means having the knowledge to monitor behaviors, assess the system’s security status, detect changes, and make informed decisions about how to stay secure [13,14].

Continuous monitoring and risk management are essential for embedding security awareness in DACSs to implement the ZT model [4]. Continuous monitoring facilitates the early detection of emerging risks, such as compromised devices or insider threats, by providing real-time insights. Risk management complements this by proactively assessing potential threats and offering actionable mitigation strategies, thereby strengthening the overall security posture. Security awareness within DACSs enables real-time evaluation of access control decisions, dynamically adjusting permissions based on the latest risk indicators [6,7,8,15]. This adaptive approach reduces the attack surface by ensuring access rights stay appropriate, preventing unauthorized access or privilege escalation. However, traditional centralized policy management systems struggle to meet the dynamic and scalable demands of the ZT model [16]. Decentralized policy management, using blockchain technology, overcomes these challenges by storing policies and access logs on an immutable ledger [7,17]. This ensures transparency and auditability by maintaining unalterable records of access decisions. By combining blockchain with access control systems, organizations can create a ZT framework where smart contracts govern access, validated through consensus mechanisms [17]. This approach offers a secure, resilient, and scalable solution for managing access in distributed ZT environments.

This paper introduces a DACS framework to implement the ZT model with embedded security awareness and leveraging blockchain technology. The framework enhances smart contract functionality to support continuous risk assessment and real-time policy adjustments. Unlike traditional approaches that rely on specific trusted nodes for policy management and risk evaluation, the DACS decentralizes these capabilities. Each blockchain node independently manages policies for its own resources—referred to as objects—through smart contracts linked to an ACL. The ACL specifies which nodes have access permissions and defines the allowable operations for each object. Additionally, it incorporates impact levels associated with these operations, where higher impact levels signify a greater risk of harm to the system in the event of unauthorized access. Organizations determine these impact levels based on the potential damage unauthorized actions could inflict, aligned with their business security requirements [18]. While researchers in [7,19] explored trust values to quantify the reliability of actors in access decisions, they overlooked the significance of impact levels tied to unauthorized access attempts.

Our framework extends smart contract capabilities to conduct continuous risk assessments for every access request, dynamically adjusting access policies based on behavioral analysis and contextual risk. The contextual risk of a node is evaluated by examining incoming access requests within an organization-defined time window. The risk level increases as the frequency of unauthorized access requests rises, indicating potential broken access control attacks [20], where adversaries exploit legitimate nodes or infiltrate the network as insiders to probe for vulnerabilities. To capture this dynamic threat landscape, we introduce a metric called the risk factor (RF) along with its probability estimation. The RF quantifies the likelihood of security risks within the current operational context at runtime by analyzing access request patterns and assessing the impact levels of unauthorized access attempts.

Our framework assigns each blockchain node a trust metric (TM), which defines the node’s trustworthiness based on its behavioral history. A low TM value indicates a potential malicious actor. A penalty enforcement mechanism is triggered for anomalous behaviors, such as initiating unauthorized access requests. The penalty is dynamic and estimated by considering both the RF and the impact levels of unauthorized access attempts. Prior research [6,7,17] has explored penalty enforcement mechanisms, but these typically rely on predefined penalties that do not account for the dynamism of contextual risk. Such approaches are insufficient to address the uncertainty posed by evolving attack surfaces and dynamic interactions in distributed systems.

In our framework, the ACL incorporates a minimum TM threshold for each operation, aligning the required trust level with the operation’s associated impact level. Organizations define the minimum TM for each operation and object based on their business and security needs. The policy management mechanism then evaluates each access request by referencing both the ACL and the requester’s TM. Access permission is granted or denied based on a comparison with the threshold value assigned to the requested operation, enabling real-time dynamic policy adjustments. To ensure transparency and resilience, we adopt the Proof of Stake (PoS) consensus mechanism [21] to validate each transaction, including policy adjustments and TM updates. The PoS mechanism is ideal for our use case, which requires fast computation and the ability to process numerous access requests with minimal computational power, and aligns with the ZT model. Additionally, we treat validator nodes’ TM values as tokens, where a higher TM indicates greater trustworthiness, reinforcing confidence in their validation decisions.

This penalty enforcement and risk-aware policy adjustment approach aligns with the ZT principle, offering an adaptive access control solution tailored to the organization’s security and business needs. The key contributions of this paper are threefold:

• Enhanced smart contract functionality and node architecture—embedding security awareness by extending ACLs to include impact levels and minimum TM thresholds.
• Continuous risk assessment—developing a mechanism to dynamically evaluate the RF of access requests by analyzing request patterns and the impact levels of operations.
• Dynamic penalty enforcement and TM adjustment—implementing real-time penalty enforcement based on the RF within the operational context, allowing runtime adjustments to a node’s TM.

To evaluate the framework, we implement a testbed on the Ethereum blockchain platform. Smart contracts are developed using the Remix IDE, demonstrating the framework’s effectiveness in providing resilient and adaptable access control.

2. Related Work

Distributed systems, composed of diverse components, applications, and services operating across varied environments, present unique and pressing security challenges [1]. Traditional security models, rooted in the outdated concept of a trusted perimeter, were once effective but now fail to meet the demands of increasingly decentralized infra-structures [2]. Their reliance on implicit trust and static access controls creates critical vulnerabilities, leaving systems exposed to insider threats, unauthorized access, and operational inefficiencies [3]. Addressing these challenges requires a paradigm shift toward innovative, adaptable, and scalable security frameworks [4]. The Zero Trust (ZT) security model has emerged as a transformative approach to securing distributed systems [4,17]. Emphasizing the principles of “never trust, always verify”, ZT validates user identities, continuously monitors behavior, and enforces fine-grained access controls across all network resources. ZT principles have been successfully implemented across various domains, including healthcare [22], supply chains [23], and communication networks [24,25].

An essential enhancement to ZT is the integration of a dynamic access control scheme (DACS), which adjusts access permissions in real-time by analyzing actors’ behavior, attack patterns, and changes in network or system architecture [6,7,8,26]. A DACS extends traditional access control policies by incorporating contextual attributes, enabling more flexible and adaptive security measures. Effective implementation of a DACS relies on robust policy management, consisting of key components such as the Policy Enforcement Point (PEP), responsible for intercepting and evaluating access requests; the Policy Administration Point (PAP), which defines and updates access rules in response to evolving security contexts and compliance standards; and the Policy Decision Point (PDP), which dynamically assesses access requests and modifies policies based on real-time contextual data [6,9,10].

A DACS effectively addresses the challenges of dynamism in borderless network environments, ensuring robust access governance and accountability [27]. According to [27], a DACS requires a comprehensive set of functional requirements to define, update, and enforce access policies. It also emphasizes the importance of event logging to monitor anomalies, reinforcing security oversight. Continuous monitoring emerges as a key component, enabling the tracking of user–resource interactions for risk assessment and dynamic policy management [26]. In the ZT model, the DACS must intercept every access request, granting access only to trusted actors [26]. This necessitates the integration of a trust algorithm to assess actors’ trust levels based on their behavioral history [4]. Within the DACS for ZT, an actor’s trust level influences both access request decisions and the reasoning behind policy updates [4]. When behavioral changes are detected, the trust level must be re-evaluated, and access policies adjusted accordingly to align with the system’s security requirements [28].

Researchers have proposed trust-based dynamic access control models and developed trust management schemes to compute actors’ trust levels [7,21,26]. In [7], the authors define four rating constants representing distinct behavioral patterns: normal, denied, DDoS, and invasive. Trust values are dynamically updated based on these rating constants. Meanwhile, ref. [19] introduces a trust evidence set and corresponding trust degrees, using a fuzzy evaluation matrix to calculate entropy weights for each piece of evidence. The trust evaluation vector is derived by combining a predefined weight vector with the evaluation matrix, ultimately determining the user’s trust value. However, these approaches often rely on predefined conditions and static parameter values to compute trust levels, limiting their adaptability to the dynamic nature of distributed systems. To address this limitation, ref. [26] proposes a trust calculation method that evaluates deviations in user behavior from expected patterns. This approach incorporates rules for setting trust evaluation factors by comparing the degree of deviation against predefined ranges. The user’s trust degree is then calculated by aggregating trust evaluation factors across multiple dimensions of the user profile, weighted proportionally. Despite its recognition of behavioral dynamism, this method introduces a potential vulnerability: attackers may exploit predefined deviation thresholds by generating small, incremental deviations to remain undetected. This highlights the need for more sophisticated, adaptive trust evaluation mechanisms capable of detecting subtle yet persistent malicious behavior.

In [4], the National Institute of Standards and Technology (NIST) outlines the broad categories of inputs required for trust algorithms, including access requests, subject databases, asset databases, and threat intelligence. These inputs help evaluate the trust levels of actors initiating access requests. Trust algorithms can be implemented in various ways: criteria-based approaches assess a set of qualified attributes before granting access, while score-based approaches assign organization-defined values to objects and apply enterprise-configured weights [4]. The resulting score is compared against a predefined threshold value—if the score exceeds the threshold, access is granted. However, deploying trust algorithms requires a dedicated ‘tuning’ phase, involving careful planning and testing to establish criteria, weights, and threshold values for each resource. The duration of this phase and the selection of criteria or scoring weights depend on the organization’s business policies and its tolerance for incorrect access denials or approvals within operational workflows [4].

Trust algorithms can evaluate access requests using two primary approaches. The singular approach focuses solely on the individual access request and its parameters, but this method is inherently vulnerable to insider threats as it lacks broader context. In contrast, the contextual approach considers the requester’s access history, identifying anomalies and dynamically adjusting trust levels. Drawing on their expertise, the NIST recommends adopting a contextual, score-based trust algorithm [4]. This method enables more dynamic and granular access control by integrating confidence scores for current access requests with contextual insights, allowing for adaptive access policy decisions. Enhancing the contextual approach, security awareness plays a crucial role by extracting insights into the system’s security state through analyzing variations in the operational environment and behavioral patterns. Simultaneously, it assesses the impact of these changes on the system’s overall security posture [13,14]. To implement ZT, the DACS must embed security awareness, empowering systems to continuously evaluate their security state, detect emerging threats, and adapt access policies in real time [11,12,14].

The advancement of machine learning (ML) technology enhances the detection of anomalous user–resource interaction patterns [29,30] and dynamically adjusts access policies to ensure security and compliance [31]. Ali et al. [32] developed the d-CAP framework, an ML-based dynamic ACL system for Software-Defined Networks (SDNs), which optimizes access control rules in real time, reducing both latency and processing overhead. Similarly, Jung et al. [33] proposed PortCatcher, a scalable architecture that streamlines ACL rule management using a TCAM-SRAM hybrid design, maximizing space efficiency while minimizing latency. Despite these innovations, implementing ZT in distributed systems presents significant challenges, particularly regarding scalability and the dependence on centralized security administration. Blockchain technology offers a promising solution by providing a decentralized, tamper-resistant foundation for managing security policies [24,25]. Blockchain-based ZT solutions enable secure resource access while dynamically adjusting access controls to reflect evolving operational contexts.

Researchers [7,17,34,35] have explored blockchain-based approaches to enforce dynamic access control schemes (DACSs); however, these solutions often depend on a set of distinguished trusted nodes within the network to monitor access requests and manage policies. This reliance creates a critical vulnerability, as these trusted nodes become prime targets for attackers. Furthermore, these approaches lack mechanisms to verify the actions of trusted nodes, undermining the core principles of the ZT model, which assumes no entity should be inherently trusted. To align with ZT principles, future blockchain-based DACSs must incorporate mechanisms for continuous verification and consensus-driven policy enforcement, ensuring trust is never assumed but consistently validated.

Blockchain-based dynamic access control systems (DACSs) effectively address the key limitations of centralized systems, such as single points of failure and lack of auditability. Sun et al. [36] introduced a Blockchain-enabled Provenance-based Dynamic Access Control (BPDAC) scheme, leveraging smart contracts to automate access-related decision-making while maintaining decentralized governance. Nakamura et al. [37] demonstrated an Ethereum-based Capability-Based Access Control (CapBAC) system, which manages permissions with granular control, offering flexibility and security in hierarchical organizations. Similarly, Gong et al. [5] proposed SDACS, a blockchain-powered architecture for IoT systems based on Hyperledger Fabric and IPFS, utilizing Attribute-Based Access Control (ABAC) to ensure fine-grained and decentralized access management. The integration of blockchain and DACS presents a promising future for access control in distributed systems. By eliminating reliance on trusted third parties and central authorities, these technologies empower organizations to implement decentralized, scalable, and context-aware security policies. Research has shown that blockchain can revolutionize access control by enabling secure policy enforcement under complex and dynamic conditions [38,39]. Furthermore, combining ZT principles with DACS and blockchain technologies marks a significant evolution in distributed systems security.

When implementing a blockchain-based DACS, it is crucial to evaluate the consensus mechanisms used in blockchain solutions, considering their security, effectiveness, and decentralization characteristics [40]. Traditional consensus mechanisms include Proof of Stake (PoS) [41], Proof of Work (PoW) [42], and Byzantine Fault Tolerance (BFT) [43]. In PoS, validators are selected based on the number of tokens they hold and are willing to “stake” [41]. A transaction is validated when a majority of stakeholders approve it. PoS is energy-efficient and offers faster performance but poses a centralization risk, as nodes with a high number of staked tokens may dominate the validation process. On the other hand, in PoW, validators solve complex but easily verifiable mathematical problems [42]. Although secure, PoW requires significant computational power and introduces high latency, making it less suitable for distributed systems with frequent access requests. BFT mechanism relies on real-time voting and can tolerate a certain level of faulty or malicious nodes [43]. While BFT enhances fault tolerance, it incurs high communication costs and is vulnerable to denial of service (DoS) attacks [40]. Over time, various consensus mechanism adaptations have emerged, with the choice depending on specific use cases and organizational resources [40].

To build blockchain networks, several platforms offer an infrastructure for developing decentralized applications (dApps), each with distinct capabilities and limitations [44]. Platform selection typically involves evaluating criteria such as network type (permissioned vs. permissionless), consensus mechanism, programming language support, APIs, cost, reputation, performance, and security. According to multiple surveys [44,45], Ethereum, Hyperledger, Chain, and Corda are widely accepted platforms with domain-specific features. Ethereum and Hyperledger, in particular, are prominent public blockchain platforms. Ethereum operates on a permissionless network, promoting decentralization, immutability, and transparency, while Hyperledger supports permissioned networks managed by administrators, making it more suitable for use cases requiring privacy and controlled access [45].

3. Approach

This paper introduces a DACS framework with embedded security awareness to implement a ZT model in distributed systems, leveraging blockchain technology to enhance security and reliability. The DACS framework is designed to dynamically decide on access requests by considering contextual attributes and adjusting access control policies in real time based on changes in the security state, guided by the analysis of access request patterns. These updated access control policies aim to mitigate emerging security risks while ensuring alignment with the system’s security compliance requirements. The embedded security awareness empowers the framework to reason over access policy changes, ensuring decisions are context-aware and risk-informed. Continuous monitoring plays a key role by tracking access requests and spotting potential threats as they happen. Risk assessment evaluates the possible impact of new threats, while policy management uses this information, along with the trustworthiness of those requesting access, to make informed decisions. Recognizing how important trust is in granting permissions, the DACS framework includes a trust evaluation mechanism to support secure and well-informed access decisions.

This section explains the framework in detail, including blockchain nodes and smart contract functionalities, which are integral to our DACS framework. The framework leverages blockchain nodes to enable decentralized and tamper-resistant logging, ensuring that all access attempts are continuously monitored and recorded. Smart contracts facilitate real-time detection of unauthorized access attempts and perform runtime risk assessments. Policy management includes mechanisms to process and enforce access requests based on an ACL and the TM associated with the participating nodes. This functionality ensures that access decisions are dynamically determined and modified using the most current contextual and trust-related data, ensuring a robust and responsive access control mechanism that aligns with ZT principles. By combining continuous monitoring, runtime risk assessment, and adaptive policy management, the proposed DACS framework provides a comprehensive solution for securing distributed systems while maintaining operational flexibility and resilience against emerging threats.

3.1. Define Node in Proposed Blockchain-Based DACS Framework

In our blockchain infrastructure, any active actor that collaborates to maintain operations in a distributed system, such as devices, components, services, or user accounts, is represented as a node. Each node plays a vital role in maintaining, validating, and broadcasting transactions and blocks within the network. The blockchain network comprises a set of such nodes, collectively referred to as $AllNodes$. We define a node, $N$ as

$$N=({basicInfo}_N,{hierarchyInfo}_N,O_N,{ACL}_N,{TM}_N)$$

Here, ${basicInfo}_N$ includes the fundamental information required to uniquely identify and instantiate the node, $N$, within the blockchain network. As shown in Figure 1, nodeName is a unique identifier of a node.

${hierarchyInfo}_N$ represents the hierarchical relationships within the blockchain network, if applicable. It includes the information of the node’s parent, which is another active node in the network. Such hierarchical relationships model interdependencies among system components, reflecting organizational or functional structures.

$O_N$ denotes the set of objects owned by the node.

For each object $o_i\in O_N$, the node maintains an ACL:

$${ACL}_N(o_i)={\bigcup }_{n\in AllNodes}\left\{\right({basicInfo}_n,\left(Opp,I,minTH\right)\left)\right\}$$

Each entry in ${ACL}_N$ defines the permitted operation ($Opp\in OP)$ that a node $n$ can perform on the object, $o_i$. Each operation has an organization defined impact level, $I$, and $minTH$ specifies the minimum required trustworthiness of node $n$ to perform the operation.

$OP$ is the set of all possible operations. In this paper, we are dealing with create (C), read (R), update (U), and delete (D) operations. So, $OP=\{C,R,U,D\}$.

${TM}_N$ represents the TM assigned to the node $N$. The trust metric reflects the reliability and security posture of the node, dynamically adjusted based on its actions and behavior within the network.

A node encompasses a range of critical functionalities that enable its role within the blockchain infrastructure as shown in Figure 1. It can set up and manage ACLs for its own objects by creating new policies or updating existing ones, ensuring that access rules follow organizational requirements. The node also updates its TM based on feedback from other nodes about its actions and behavior, reflecting changes in its trustworthiness. Additionally, the node handles operations on its objects, such as create, read, update, and delete (CRUD), according to decisions made by the access control mechanism. This ensures that policies are consistently applied across the network. Beyond access control and policy enforcement, the node supports key blockchain operations, including creating blocks, processing transactions, and maintaining the ledger. These functions work together to keep the blockchain network decentralized, secure, and tamper-resistant.

3.2. Enhanced Smart Contract for DACS with Embedded Security Awareness

The Zero Trust (ZT) model relies on three core functionalities: continuous monitoring, risk assessment, and trust evaluation [4]. These components form the backbone of the DACS, supporting policy management mechanisms to ensure secure resource access [6,7]. Continuous monitoring provides real-time oversight of access requests by analyzing patterns, identifying requesters, and evaluating their behaviors. This proactive approach helps detect deviations from normal patterns or signs of anomalous activity. Additionally, it builds detailed behavioral profiles for each requester, offering a comprehensive view of access dynamics over time.

Risk assessment leverages data from continuous monitoring to evaluate the risk associated with each access request. This process considers factors such as the sensitivity of the requested resource, the requester’s historical behavior, and the current access context, assigning an RF to each request. The RF plays a key role in decision-making, enabling proactive responses to potential threats. Trust evaluation, on the other hand, assesses the trustworthiness of the requester by analyzing behavioral consistency, adherence to security policies, and alignment with expected access patterns—insights drawn from continuous monitoring. This evaluation produces a trust metric (TM), reflecting the requester’s reliability within the given access context.

To implement DACS, we enhanced the smart contract functionality to embed security awareness that dynamically evaluates and adjusts access permissions based on predefined ACLs along with the calculated RF and TM. The enhanced the smart contract serve as a decentralized policy management mechanism for the DACS, as illustrated in Figure 2. This enhancement enables secure, automated, and distributed management of access requests. When a blockchain node receives a new access request, the getAccessRequest function within the smart contract associated with that node is triggered. This function initiates the monitoring process by passing the access request to the monitorAccessRequest function. The monitoring process evaluates the access request against the predefined ACLs and generates actionable insights based on the request’s characteristics and context. Let ${Req}_N$ represent the set of access requests directed to node $N$. Each individual access request $req$ is defined as follows:

$$req=({basicInfo}_{\overline{N}},o_N,Opp,{TM}_{\overline{N}})$$

It specifies which node $\overline{N}\in AllNodes\backslash \left\{N\right\}$ requests access to the object $o_N$ to perform the operation $Opp$, as well as the TM of the node $\overline{N}$. This ${TM}_{\overline{N}}$ is a critical decision factor for policy enforcement.

The policy enforcement mechanism includes decideAccessRequest, which evaluates and decides on access requests based on insights from monitorAccessRequest in real time. Based on this evaluation, there are three possible outcomes:

• Access granted: if the requesting node, $\overline{N}$, has the necessary access permissions as per the ACL and maintains a TM above the minimum threshold, the operation is allowed, and the node retains its current permissions.
• Access denied—insufficient permissions: if the requesting node, $\overline{N}$, does not have the required access permissions in the ACL, the operation is denied outright.
• Access denied—low trust metric: if the requesting node, $\overline{N}$, has the required access permissions but its TM falls below the minimum threshold, the operation is denied due to insufficient trustworthiness.

In the third scenario, access is denied because the node $\overline{N}$ maintains a TM below the acceptable threshold despite having access permissions. In this case, decideAccessRequest triggers a critical follow-up process that invokes the policy administration mechanism. The generateAccessPolicy function, part of the policy administrator, is activated. This function generates a revised access policy to revoke the access permissions of node $\overline{N}$ due to its low TM. The adjustAccessPolicy function then updates the ACL to reflect the revoked permissions. This adjustment ensures that the node’s access rights are aligned with the current trust evaluation. Finally, an updated ACL is instantiated for node N that includes the adjusted policy for node $\overline{N}$, ensuring that the latest trust and access policies are enforced across the system.

This dynamic trust evaluation and policy adjustment ensure that access permissions are not only granted based on predefined rules but also adjusted in response to behavioral and contextual changes, thereby maintaining a robust security posture. Moreover, the continuous monitoring functionality, denoted as $CMFunc$, encompasses a crucial component called logAccessRequestForCM. This component is responsible for systematically logging each access request alongside the corresponding access decision. This functionality is integral to ensuring traceability and enabling comprehensive analysis of access control activities within the system. For every access request $req\in {Req}_N$ the $CMFunc$ generates a detailed outcome encapsulating essential information. The outcome can be expressed as follows:

$$\forall req\in {Req}_N,{CMFunc}_N:req\to ({basicInfo}_{\overline{N}},o_N,\left(Opp,I,minTH\right),decision,{TM}_{\overline{N}})$$

The outcome includes ${basicInfo}_{\overline{N}},o_N,Opp,{TM}_{\overline{N}}$ derived from the request and $req$ entry, while $I$ and $minTH$ are obtained from the ACL for the associated $Opp$ on the corresponding $o_N$. $decision$ represents the final access control outcome, specifying whether the request is approved or denied.

The risk assessment functionality in a smart contract enables dynamic risk assessment according to an organization-defined observation window. The observation window determines the number of recent access requests that must be analyzed to accurately assess and contextualize the current security posture. To support this, the collectObservationRecords method retrieves a batch of the most recent access requests from the outcomes of ${CMFunc}_N$ as specified by the observation window. This approach ensures that the system continuously monitors and evaluates access patterns in real time. A significant number of unauthorized access requests within the observation window serves as an indicator that the node is being targeted, potentially signaling an elevated security risk. In this context, risk in dynamic access control is defined as the combination of two factors: the likelihood of unauthorized access occurring and the impact such access could have on the system’s operations or sensitive data. We formulate the probability of a single request to a specific node$,N$ being unauthorized as follows:

$$p_N(unauthorizedaccessrequest)={\displaystyle \frac{\left|{(O}_N\times OP\times Allnodes)\right|-\left|{ACL}_N\right|}{\left|{(O}_N\times OP\times Allnodes)\right|}}$$

The RF increases as the number of unauthorized access requests rises, indicating that the node is being targeted by malicious actors. The evaluateRisk estimates the likelihood $L_N$ of an unauthorized access request based on the records within the observation window, as derived from the outcomes of ${CMFunc}_N$. The likelihood is computed using the following formula:

$$L_N(unauthorizedaccessrequest)=\left({\displaystyle \genfrac{}{}{0pt}{}{m}{k}}\right){{\times p}_N}^k\times (1-{p_N)}^{(m-k)}$$

Here, $m$ is total number of access requests within the observation window from ${CMFunc}_N$ outcomes.

$k$ is the number of access requests identified as unauthorized within the observation window from ${CMFunc}_N$ outcomes. The RF for a specific request $req$ to access the node $N$ is defined as follows:

$${{RF}_N\left(req\right)=L}_N\left(unauthorizedaccessrequest\right)\times I\times \left\{\begin{array}{c}0,ifdecision=granted\\ 1,otherwise\end{array}\right.$$

The trust evaluation functionality within the smart contract is designed to evaluate the TM for a node, $\overline{N}$, that initiates an access request. To enhance security, a penalty enforcement mechanism is incorporated, which is triggered when an unauthorized access request is detected. The TM of the node $\overline{N}$ is dynamically adjusted based on the RF at the specific moment of evaluation. The penalty enforcement and trust metric adjustment are formulated as follows:

$${TM}_{\overline{N_{adjusted}}}={TM}_{\overline{N}}-{TM}_{\overline{N}}\times {RF}_N$$

With a high ${RF}_N$, the penalty will be high and dynamically estimated. The adjusted TM will be the new TM for the node $\overline{N}$. PublishchangeInTrustMetric allows node N to instantiate a transaction to publish the changes so that the affected node, $\overline{N}$, can validate the actions and update its current TM. The smart contract executes a synchronization process in which a new transaction is created by node $\overline{N}$ to notify the network of the updated TM. Following the Proof of Stake (PoS) consensus mechanism, validator nodes validate the TM update transaction. We consider a node’s TM value as a token for participation in the consensus process. Once validated, a block is added to the network to synchronize the updated TM across all nodes.

The smart contract associated with each node continuously repeats this process for every access request, integrating the DACS to implement the ZT model. Our trust evaluation mechanism does not reward a node for behaving as expected; in other words, the TM cannot increase dynamically. This design prevents persistent attackers from gradually building trust over time while waiting to attempt unauthorized access and evade detection. If a node’s TM falls below the threshold, the system administrator can investigate the actor represented by the node and manually reassign the TM based on their findings.

4. Experiment

To evaluate our approach, we designed a blockchain network within the Ethereum testing environment using Remix IDE. Remix IDE is a powerful, web-based development tool specifically tailored for Ethereum blockchain development. It is widely recognized for its capabilities in writing, deploying, testing, and debugging smart contracts. Supporting Solidity, Remix IDE provides an extensive suite of tools that allow seamless interaction with the Ethereum network. One key feature of Remix IDE is its interactive interface, enabling developers to directly test both public and internal functions of smart contracts. This is crucial in validating the logic and functionality of our enhanced smart contracts prior to deployment. We chose the Ethereum platform for our experiments because of its permissionless network, which aligns with our distributed system use case, where participant interactions are unpredictable. Additionally, Ethereum’s open-source nature promotes the creation and deployment of smart contracts and decentralized applications (DApps). Its robust infrastructure and support for programmable contracts make it the ideal platform for implementing our solution. While we acknowledge Ethereum’s limitations, such as scalability challenges and high gas fees compared to platforms like Hyperledger, it remains a feasible option for our moderate-sized network. Furthermore, our approach is designed to be platform-agnostic, with the primary goal of this experiment being to evaluate the effectiveness of our approach and mitigate potential broken access control attacks by implementing the ZT model.

4.1. Blockchain Network Design and ACL Define

After successfully implementing and deploying the defined node functionalities and enhanced smart contracts, we designed a blockchain network comprising 10 interconnected nodes ($S_A$ to $S_J$), as outlined in

Table 1. Access control list (ACL) matrix: node-wise permissions (rows) vs. object-wise operations (columns) for create (C), read (R), update (U), and delete (D).

	${\mathit{O}}_{\mathit{A}}$ (C = H, R = H, U = H, D = H)	${\mathit{O}}_{\mathit{B}}$ (C = H, R = M, U = H, D = H)	${\mathit{O}}_{\mathit{C}}$ (C = H, R = M, U = H, D = H)	${\mathit{O}}_{\mathit{D}}$ (C = M, R = L, U = L, D = M)	${\mathit{O}}_{\mathit{E}}$ (C = M, R = L, U = L, D = M)	${\mathit{O}}_{\mathit{F}}$ (C = M, R = L, U = L, D = M)	${\mathit{O}}_{\mathit{G}}$ (C = M, R = L, U = L, D = M)	${\mathit{O}}_{\mathit{H}}$ (C = L, R = L, U = M, D = L)	${\mathit{O}}_{\mathit{I}}$ (C = L, R = L, U = L, D = L)	${\mathit{O}}_{\mathit{J}}$ (C = L, R = L, U = M, D = L)
$S_A$	C, R, U, D	C, R, U, D	C, R, U, D	C, R, U, D	C, R, U, D	C, R, U, D	C, R, U, D	C, R, U, D	C, R, U, D	C, R, U, D
$S_B$	C	C, R, U, D	C, R	C, R, U, D	C, R, U, D	R	R	R, U	R, U	R, U
$S_C$	C	C, R	C, R, U, D	R	R	C, R, U, D	C, R, U, D	R	R	R
$S_D$		C		C, R, U, D	C, R	C, R	C, R	C, R, U, D	C, R, U, D	R
$S_E$		C		C, R	C, R, U, D	C, R	C, R	R	R	C, R, U, D
$S_F$			C	C, R	C, R	C, R, U, D	C, R	R	R	R
$S_G$			C	C, R	C, R	C, R	C, R, U, D	R	R	R
$S_H$				C				C, R, U, D	C, R	C, R
$S_I$				C				C, R	C, R, U, D	C, R
$S_J$					C			C, R	C, R	C, R, U, D

. This network simulates a decentralized environment, enabling us to rigorously test and analyze the performance and security of our proposed system in a realistic and scalable setup. For simplicity, we assume that each node is associated with a single object, resulting in a total of 10 objects in the entire application, as outlined in Table 1. CRUD (create, read, update, and delete) operations can be performed on these objects, and each operation is assigned an impact level based on its potential severity to the application if performed without proper authorization. The impact levels are categorized as follows: (i) high (H)—impact score of 0.9, (ii) moderate (M)—impact score of 0.5, and (iii) low (L)—impact score of 0.2.

Each object and its associated operations are assigned a minimum threshold value for TM, as detailed in

Table 2. Minimum required trust metric for perform CRUD operations on objects.

	${\mathit{O}}_{\mathit{A}}$	${\mathit{O}}_{\mathit{B}}$	${\mathit{O}}_{\mathit{C}}$	${\mathit{O}}_{\mathit{D}}$	${\mathit{O}}_{\mathit{E}}$	${\mathit{O}}_{\mathit{F}}$	${\mathit{O}}_{\mathit{G}}$	${\mathit{O}}_{\mathit{H}}$	${\mathit{O}}_{\mathit{I}}$	${\mathit{O}}_{\mathit{J}}$
Create (C)	0.95	0.8	0.8	0.65	0.65	0.65	0.65	0.55	0.55	0.55
Read (R)	0.95	0.75	0.75	0.6	0.6	0.6	0.6	0.55	0.55	0.55
Update (U)	0.95	0.8	0.8	0.6	0.6	0.6	0.6	0.6	0.6	0.6
Delete (D)	0.95	0.8	0.8	0.65	0.65	0.65	0.65	0.55	0.55	0.55

. The methodology for determining impact levels and establishing these threshold values is beyond the scope of this paper. For our experiment, we assume these values are provided by domain experts, informed by organizational policies and risk assessments. Organizations incorporate a “tuning” phase during deployment to gather empirical data from the system and refine the threshold values according to their specific business needs.

Each node’s ACL contains entries only for its own objects. For instance, node $S_F$ owns the object $O_F$. So, the ACL for node $S_F$ for object $O_F$ would be the following:

$$\begin{gathered} {ACL}_F\left(o_F\right)=\left\{\right({basicInfo}_{S_A},\left(C,M,0.65\right)),({basicInfo}_{S_A},\left(R,L,0.6\right)), \\ ({basicInfo}_{S_A},\left(U,L,0.6\right)),({basicInfo}_{S_A},\left(D,M,0.65\right)),({basicInfo}_{S_B},\left(R,L,0.6\right)),({basicInfo}_{S_C},\left(C,M,0.65\right)), \\ ({basicInfo}_{S_C},\left(R,L,0.6\right)),({basicInfo}_{S_C},\left(U,L,0.6\right)),({basicInfo}_{S_C},\left(D,M,0.65\right)),({basicInfo}_{S_D},\left(C,M,0.65\right)), \\ ({basicInfo}_{S_D},\left(R,L,0.6\right)),({basicInfo}_{S_E},\left(C,M,0.65\right)),({basicInfo}_{S_E},\left(R,L,0.6\right)),({basicInfo}_{S_F},\left(C,M,0.65\right)), \\ ({basicInfo}_{S_F},\left(R,L,0.6\right)),({basicInfo}_{S_F},\left(U,L,0.6\right)),({basicInfo}_{S_F},\left(D,M,0.65\right)),({basicInfo}_{S_G},\left(C,M,0.65\right)), \\ ({basicInfo}_{S_G},\left(R,L,0.6\right))\} \end{gathered}$$

4.2. Attack Simulation and Experiment

After designing the blockchain network and successfully instantiating the nodes, assigning their ACLs, and specifying the corresponding TM and minimum TM thresholds for each operation, we conducted experiments across various scenarios to simulate broken access control (BAC) attacks. BAC is recognized as one of the top 10 vulnerabilities in distributed systems according to the Open Web Application Security Project (OWASP) [20]. In a BAC attack, adversaries exploit vulnerabilities such as insufficient input validation, misconfiguration, incomplete authorization techniques, flawed APIs, and other weaknesses to compromise less secure components within the distributed system by manipulating access request parameters. During the probing phase, attackers repeatedly send crafted access requests, varying the target objects and operations in an attempt to bypass allocated permissions.

To simulate this, we ran a script designed to probe for misconfigurations and gain unauthorized access to node $S_F$. The script generated a series of crafted access requests targeting node $S_F$, aiming to access object $O_F$. These requests originated from different nodes and involved a mix of legitimate and malicious operations on $O_F$. The probing activity resulted in a noticeable spike in unauthorized access attempts. The DACS framework responded by dynamically determining the RF, evaluating each access request based on the ACL policy, the calculated RF, and the current TM of the requesting node. Access decisions—whether to grant or deny—were made in real time, ensuring adaptive responses to emerging threats. This experiment highlights the framework’s ability to detect and mitigate BAC attacks through continuous monitoring, risk-aware decision-making, and dynamic policy enforcement.

We noticed three scenarios depending upon the access request and the requesting node’s current TM values. We describe some instances of our scenarios in detail:

Scenario 1: Access Request Granted

Our first scenario is that node $S_F$ receives an access request from node $S_B$ to perform a read (R) operation on object $O_F$ as shown below:

$${req}_{sc1}=({basicInfo}_{S_B},o_F,R,1)$$

The request includes the current TM of node $S_B$, denoted as ${TM}_B$, as 100%. Upon receiving the access request, the smart contract associated with node $S_F$ triggers the evaluation of the request. The smart contract checks the access policy-defined ACL of node $S_F$ for object $O_F$, denoted as ${ACL}_F\left(O_F\right).$

According to ${ACL}_F\left(O_F\right),$the read operation is permitted (as shown in Table 1), and the minimum required TM threshold is 60% (as shown in Table 2). Since the current ${TM}_B$ is 100%, which exceeds the required threshold, the access request is “granted”. The decision is logged for continuous monitoring and appended to the outcome of the continuous monitoring function (${CMFunc}_F$) as follows:

$${CMFunc}_F:{req}_{sc1}\to ({basicInfo}_{S_B},o_F,\left(R,0.2,0.6\right),“granted”,1)$$

Since the request is “granted”, no risk assessment and trust evaluation have been performed.

Scenario 2: Access Request Denied Due to No Permission

In the second scenario, node $S_F$ receives an access request from node $S_G$ to perform an update (U) operation on object $O_F$, with ${TM}_G$ currently at 100%. The access request is defined as follows:

$${req}_{sc2}=({basicInfo}_{S_G},o_F,U,1)$$

The smart contract evaluates the access request based on ${ACL}_F\left(O_F\right)$ and ${TM}_G$. The decision is to deny the request, as node $S_G$ lacks update operation permission for object $O_F$ (as referenced in Table 1). The outcome generated by ${CMFunc}_B$ includes the decision and relevant information as follows:

$${CMFunc}_B:{req}_{sc2}\to ({basicInfo}_{S_G},o_F,\left(U,0.2,0.6\right),“denied”,1)$$

Risk Assessment and Trust Metric Adjustment

The risk assessment mechanism is triggered to evaluate ${RF}_{S_F}$ (the risk factor for node $S_F$) and adjust ${TM}_G$ to penalize node $S_G$. Any unauthorized access request is considered a potential security compromise attempt.

The risk assessment uses an observation window containing a specified number of recent records to determine the frequency of denied access requests. For demonstration, we consider variations in the observation window size and the resulting ${RF}_{S_F}$ and adjusted ${TM}_G$. The RF and adjusted TM vary depending on the observation window size and the number of unauthorized access requests within the window. These variations, along with their calculated RF and TM adjustment, are summarized in

Table 3. Dynamic RF and adjusted TM estimation with variation in records across different observation windows (considering that we perform the calculation when node $S_F$ receives an access request from node $S_G$ to perform an update (U) operation on object $O_F$, and the request has been “denied”).

Observation Window Size	Number of Unauthorized Access Requests	RF	Current TM	Adjusted TM
25	3	0.00000514	1	0.99999486
50	7	0.00000236	1	0.99999764
25	3	0.00000514	0.7	0.699996402
50	7	0.00000236	0.7	0.699998348

.

The probability of a single request to node $S_F$ being unauthorized is calculated as shown below:

$$p_{S_F}\left(unauthorizedaccessrequest\right)={\displaystyle \frac{(1\times 4\times 10)-19}{(1\times 4\times 10)}}=0.525$$

In our experimenting observation window from ${CMFunc}_B$ outcomes, 25 recent records are considered, with 3 recorded as unauthorized access requests. The likelihood of an unauthorized access request ($L_{S_F}$) is computed as follows:

$$L_{S_F}\left(unauthorizedaccessrequest\right)=\left({\displaystyle \genfrac{}{}{0pt}{}{25}{3}}\right)\times {0.525}^3\times (1-{0.525)}^{22}=2.57\times {10}^{-5}$$

Risk Factor and Adjusted Trust Metric

The ${RF}_{S_F}$ calculated after the denied access request ${req}_{sc2}$ is

$${RF}_{S_F}\left({req}_{sc2}\right)=2.57\times {10}^{-5}\times 0.2\times 1=0.00000514$$

Additionally, the adjusted ${TM}_G$ would be

$${TM}_{\overline{G_{adjusted}}}=1-1\times 0.00000514=0.99999486$$

The PublishchangeInTrustMetric function allows node $S_F$ to initiate a transaction to notify node $S_G$ of its adjusted ${TM}_G$, which will be validated by node $S_G$ and established in the network.

Scenario 3: Access Request Denied Due to Insufficient Trust Metric

In the third scenario, node $S_F$ receives an access request from node $S_C$ to perform a read (R) operation on object $O_F$. However, ${TM}_C$ (current trust metric of node $S_C$) is only 50%, as specified below:

$${req}_{sc3}=({basicInfo}_{S_C},o_F,R,0.5)$$

The access request is denied, even though node $S_C$ has read operation permission in ${ACL}_F\left(O_F\right)$ (see Table 1). This denial occurs because the minimum required trust metric to perform a read operation on $O_F$ is 60% (as referenced in Table 2), which node $S_C$ fails to meet.

Triggering Policy Adjustment

This decision triggers the generateAccessPolicy mechanism to create a new access policy. The updated policy revokes previously granted permission to node $S_C$ to perform the read operation on object $O_F$, reflecting its reduced trustworthiness.

The adjustAccessPolicy function then updates ${ACL}_F\left(O_F\right)$ to reflect the changes, creating a new instance of the access control list.

5. Performance Analysis and Comparison with Existing Approach

To evaluate the scalability, robustness, and efficiency of the proposed DACS framework, we measured key performance metrics, such as average transaction validation time and gas consumption for processing access requests. All experiments were conducted on a personal computer running Linux (csx2 5.15.0-130-generic #140-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux). The experiment considered a mix of both authorized and unauthorized access requests. We compared the average transaction validation time of our approach with that of a basic blockchain-based access control management method. To conduct the comparison, we gradually increased the number of participating nodes and access requests. The comparison results are presented in

Table 4. Performance comparison of our approach with a basic blockchain-based access control management approach by varying the number of nodes in the network.

Number of Nodes	Average Transaction Validation Time (Our Approach) in Seconds	Average Transaction Validation Time (Basic Approach) in Seconds
15	0.08523	0.002839
50	0.261504	0.002834
100	0.468003	0.002819
500	2.31576	0.002814
1000	4.602902	0.002920

.

Although our approach takes more time than the basic blockchain-based approach, this is due to the fact that the basic method allows nodes to decide on access requests based on a predefined ACL for the node’s objects. In contrast, our approach introduces additional operational overhead due to the dynamic calculation of the risk factor (RF) and the real-time adjustment of the trust metric (TM). Furthermore, the results indicate that despite the extra processes of risk evaluation and TM adjustment at individual nodes, the operational overhead remains within a tolerable range. This ensures that our DACS framework maintains an effective balance between security enhancements and system efficiency.

We conducted an in-depth performance analysis of the various processes within the DACS framework to assess its scalability, robustness, and efficiency. Key metrics considered in the evaluation include average transaction validation time and gas consumption for completing access decisions, risk assessment, trust evaluation, and policy adjustments. The results, presented in

Table 5. Performance analysis on transaction validation time and gas consumption to evaluate the practical impact on latency and efficiency.

Processes	Number of Nodes	Average Transaction Validation Time in Seconds	Average Gas Consumption
Access Decision	15	0.4339	22,780
	100	0.7028	22,828
	500	0.4750	22,840
	1000	0.0439	22,852
Risk Assessment	15	0.6809	21,624
	100	0.4623	21,508
	500	0.5182	21,660
	1000	0.9271	21,660
Trust Evaluation	15	0.9530	21,624
	100	0.6792	21,648
	500	0.7764	21,660
	1000	0.9558	21,520
Policy Adjustment	15	0.9263	0.9846
	100	21,508	0.8913
	500	21,520	0.2011
	1000	22,828	0.5092

, demonstrate that as the number of nodes in the network increases, the DACS framework maintains consistent performance with only minimal degradation. This stability highlights the robustness of our approach.

In the future, we are committed to optimizing the performance of our framework further to improve the efficiency of access request processing, ensuring that our solution continues to scale effectively without compromising security or operational efficiency.

We conducted a comprehensive comparison of our approach with three existing methods for implementing DACS, as referenced in [7,19,26]. The comparison results are presented in

Table 6. Comparison of our approach’s features with existing methods for DACS following ZT model.

Approaches	Decentralization of Policy Management	Contextual Score-Based Trust Algorithm	Dynamic Risk Assessment	Reliance on Pre-Trusted Authority
Dynamic Access Control and Trust Management for Blockchain-Empowered IoT [7]	Yes	Yes	No	Yes
Trust and Attribute-based Dynamic Access Control Model For Internet of Things [21]	No	Yes	No	No
Dynamic Access Control and Authorization System based onZero-trust architecture [28]	No	Yes	Yes	No
Our Approach	Yes	Yes	Yes	No

. Our evaluation focuses on key features, including the decentralization of policy management, a contextual score-based trust algorithm, dynamic contextual risk assessment, and reliance on pre-trusted authority. These features were selected for their relevance to the ZT model. The decentralization of policy management helps mitigate single points of failure [36] and is recommended for addressing the dynamic, scalable, and context-aware requirements of the ZT model [16]. The NIST emphasizes the importance of incorporating a contextual score-based trust algorithm to effectively implement ZT principles [4]. Additionally, dynamic contextual risk assessment is crucial for embedding security awareness, ensuring policy adjustments are aligned with potential risk factors [6,14]. Lastly, we aim to implement the DACS by minimizing reliance on pre-trusted authorities, as this contradicts the core tenets of the ZT model [4]. The comparison results highlight that our approach incorporates these NIST-recommended features for implementing the ZT model while addressing limitations found in existing DACS methods. This demonstrates the effectiveness and alignment of our framework with modern security best practices.

6. Conclusions

The rapid growth of distributed systems has brought about complex security challenges, making it clear that strong frameworks are needed to address these threats. The Zero Trust (ZT) model has become an essential strategy for securing modern systems. However, its success depends on using dynamic access control schemes (DACSs), which provide flexible, context-aware security measures. By embedding security awareness in a DACS, access policies can be adjusted in real time based on the current situation, keeping the system responsive to changing threats.

This paper introduces a new DACS framework with embedded security awareness, using blockchain technology to remove the need for centralized trusted nodes. This approach improves both security and scalability. By improving smart contract functions, the framework allows for ongoing risk assessment, real-time policy changes, and penalty enforcement, making it more resistant to security threats. The framework also uses two key metrics, the risk factor (RF) and trust metric (TM), to provide detailed and flexible access control, ensuring alignment with both security goals and the ZT model. The framework uses a Proof of Stake (PoS) consensus mechanism, which securely validates access control transactions and TM adjustments in a decentralized way. However, two limitations of our approach must be noted: (1) the lack of a procedural approach to determine the minimum TM required for operations based on organizational impact and (2) the absence of a communication protocol to coordinate TM adjustments across multiple nodes. These limitations highlight areas for future research and development. While blockchain solutions offer many security benefits, they also bring new risks, such as Sybil and 51% attacks. Although these are not the focus of this study, we plan to explore these issues in future research to make the system more resilient to new threats.

Experiments in the Ethereum testing environment using Remix IDE show that the framework effectively reduces broken access control attacks. The analysis reveals that the framework not only strengthens security but also significantly improves scalability, adaptability, and decentralized access control. These results provide a strong foundation for future advancements in secure, scalable, and context-aware access management in dynamic environments.

In the future, we plan to deploy the framework on open-source platforms like Ethereum, Hyperledger Fabric, and Corda to test its performance in real-world situations. Our goal is to create a platform-independent DACS solution that can work across different blockchain environments. By comparing our framework with existing dynamic access control methods, we aim to refine it further, ensuring it remains a leading solution for access control in response to changing security challenges.