Blockchain-Based, Dynamic Attribute-Based Access Control for Smart Home Energy Systems

Abstract

The adoption of the Internet of Things (IoT) in smart household energy systems offers new opportunities for efficiency and automation, while also posing substantial security challenges. These systems utilize diverse standards and protocols to autonomously access, collect, and share energy-related data over distributed networks. However, this interconnectivity increases their vulnerability to cyber threats, making the system vulnerable to cyber threats. The literature reveals numerous cases of cyberattacks on IoT-based energy infrastructures, primarily involving unauthorized access, data breaches, and device exploitation. Therefore, designing a robust ecosystem with secure and efficient access control (AC), while safeguarding user functionality and privacy, is essential. This paper proposes a dynamic attribute-based access control (ABAC) model that leverages a hybrid blockchain architecture to enhance security and trust in smart household energy systems. The proposed architecture integrates Hyperledger Fabric for managing user, resource, and device attributes using smart contracts, while Hyperledger Besu enforces decentralized access policies. Additionally, a trust recalibration mechanism dynamically adjusts access permissions based on behavioral analysis, mitigating unauthorized access risks and improving energy system adaptability. Experimental results demonstrate the model’s effectiveness in securing IoT smart home energy, while ensuring seamless device onboarding and efficient access control.

1. Introduction

The Internet of Things (IoT) is revolutionizing daily life, offering enhanced convenience, efficiency, and automation. The convergence of emerging technologies such as artificial intelligence (AI), 5G networks, and IoT has accelerated its adoption across industries, particularly in smart home energy systems. By 2030, the IoT market is expected to reach 500 billion USD, with smart home energy devices being a key contributor to this growth [1]. Smart homes allow users to remotely control and monitor energy devices such as smart meters, solar inverters, energy storage systems, and intelligent appliances. This enables automation and an optimized energy consumption, enhancing the quality of life, improving convenience, efficiency, and security for users. However, integrating both homogeneous and heterogeneous devices into a smart home ecosystem presents technical challenges, such as achieving interoperability, scalability, and robust security [2]. Research highlights numerous cases of cyberattacks on IoT-based energy infrastructures, including unauthorized access, data breaches, and device exploitation [3]. Therefore, it is essential to design a robust ecosystem with secure and efficient access control (AC), while safeguarding both user functionality and privacy. IoT device manufacturers have both an ethical and legal responsibility to implement strong security measures against data misuse or unauthorized access [4]. As a result, modernizing conventional access control mechanisms is imperative [5]. In a smart home energy network, access control is important for data security, as it ensures protection against the unauthorized use of accessible resources, and it also serves as the initial point of interaction between devices [6].

Table 1. Access control models with security, flexibility, and energy efficiency level.

Model	Description	Security	Flexibility	Energy Efficiency
MAC	A centralized security model enforcing access permissions based on security classifications.	High	Low	Limited
DAC	A flexible model, where resource owners control access permissions.	Moderate	High	Low
RBAC	Access is role-based, simplifying management and enhancing security.	High	Moderate	Moderate
ABAC	A dynamic model granting access based on user, device, location, and time for fine-grained control.	High	High	High

presents the existing access control models such as discretionary access control (DAC), mandatory access control (MAC), role-based access control (RBAC), and attribute-based access control (ABAC) and highlights these models’ security levels, flexibility, and energy efficiency.

RBAC and ABAC have been adapted to manage permissions based on roles and attributes associated with users, devices, and environmental conditions, respectively [7]. Recently, ABAC is considered a more suitable model due to its flexibility and fine-grained control. It evaluates attributes and is better suited for dynamic, complex scenarios where context-aware access is required. The goal of ABAC is to protect objects such as data, network devices, and IT resources from unauthorized users and actions, specifically those lacking the approved characteristics defined by an organization’s security policies [8]. For example, the attribute-based encryption (ABE) scheme is used to limit access to data generated by smart home energy devices. In this approach, each user’s attributes are used to encrypt the data, producing ciphertext that can only be decrypted by users with sufficient attributes to meet the access policy set by the data owner. However, the computational overhead of this approach is too high for many IoT devices [9]. Moreover, it primarily focuses on encryption and storage, rather than on real-time access authorization. In the same way, existing access control systems are based on a single-server architecture, which can result in a single point of failure. A compromised server may quickly alter access policies, allowing unauthorized access. In some situations, malicious devices may attempt to work together to gain more access rights. As a result, any access control system that uses ABAC architecture must ensure secure and reliable collaboration. It is important to develop a dynamic, decentralized, flexible, and computationally efficient, real-time access control system for smart environments [10].

Blockchain technology is increasingly being adopted to address these concerns. Its decentralized architecture mitigates issues related to computational limitations, resource management, and attribute verification, while eliminating the risk of a single point of failure, Blockchain enhances system resilience and secure cooperation, reducing the likelihood of unauthorized access and data breaches. By utilizing blockchain, the probability of illegal access and data breaches is significantly reduced, protecting users’ sensitive information. The inclusion of smart contracts in blockchain expands the potential for addressing access control concerns with blockchain technology [11].

This paper presents a dynamic ABAC model in a hybrid blockchain framework to enhance security and trust in smart home energy systems. The model ensures secure access to smart meters, renewable energy controllers, and HVAC systems. It integrates Hyperledger Fabric for storing user attributes and device details and Hyperledger Besu for enforcing access control policies via smart contracts. This approach enhances security, scalability, and efficiency in decentralized environments, while mitigating threats such as unauthorized access, rogue device takeovers, and flooding attacks. This framework extends the work proposed by [12,13,14,15] in order to overcome the authentication and access control issues present in existing IoT systems. Furthermore, this paper makes the following key contributions: (1) a novel hybrid blockchain-based dynamic ABAC model for secure smart home IoT environments, (2) an adaptive access control mechanism incorporating real-time trust recalibration aligned with zero-trust principles, (3) a modular smart contract architecture leveraging Hyperledger Fabric and Besu, and (4) a detailed security and performance evaluation demonstrating the system’s robustness and efficiency.

This paper is structured as follows: Section 2 provides the background and motivation behind the research, while Section 3 discusses the preliminaries. Section 4 summarizes related work. The proposed system architecture is detailed in Section 5, followed by the implementation of the proposed model in Section 6. Section 7 outlines the policy framework used for access control in the system, and Section 8 presents a workflow and scenario-based analysis involving devices of varying criticality. Section 9 provides the performance evaluation of the proposed implementation. Section 10 offers a discussion on the findings, and finally, Section 11 concludes the paper.

2. Background and Motivation

The integration of sensors and smart devices into daily life has gained significant traction, driving the development of intelligent systems for human interaction modeling and behavior analysis. While these advancements have helped increase the adoption of various IoT architectures, they have also posed significant security and privacy risks [16]. Access control is a critical component of IoT security, preventing unauthorized access, data breaches, and resource exploitation. Effective access control mechanisms ensure the secure and efficient utilization of system resources [17]. Access control mechanisms facilitating CRUD operations on data govern the physical actions performed by connected devices [18]. The access control process includes a variety of tasks such as identity verification, authorization, policy enforcement, device and user management, and audit processes to ensure security protocol compliance. A well-implemented access control system protects sensitive information from cyberattacks, while also preventing authorized users from exploiting or misusing system resources [19]. Zero-trust architecture (ZTA) has emerged as a robust security framework, operating under the assumption that implicit trust is a vulnerability and must be eliminated. This architecture segments the network to limit access, ensuring that even if an attacker breaches one segment, they cannot freely move across the entire system [20]. By enforcing networks segmentation and adhering to the “never trust, always verify” principle, ZTA mitigates cyber security risks, making it an essential strategy for securing modern, interconnected IoT ecosystems. This concept enhances security within the IoT ecosystem by treating every interaction as untrustworthy unless legitimacy is confirmed through authentication and verification procedures. For the effective implementation of ZTA, ABAC plays an essential role by providing fine-grained and context-aware access control [21]. Traditional RBAC relies on static role assignments, whereas ABAC dynamically evaluates user identity, device type, location, time, and security posture based on real-time contextual factors, aligning perfectly with ZTA’s principles [22]. The research proposes dynamic ABAC, which further reinforces access management by integrating real-time environmental and behavioral attributes into decision-making. While ABAC imposes policies based on predefined attributes, dynamic ABAC introduces continuous monitoring and adaptive AC by evaluating risk levels dynamically. This solution not only reinforces the zero-trust security model but also reflects the intrinsically dynamic and heterogeneous character of IoT systems, where traditional static security frameworks fall short.

3. Preliminary

3.1. Attribute-Based Access Control (ABAC)

The ABAC model is a fine-grained and adaptive framework for access control, assessing subject qualities, resource attributes, and environmental factors against specified policies associated with these attributes and conditions [23]. The ABAC model is structured as a four-tuple set, which includes subject attributes, resource attributes, authority attributes, and environmental attributes [24], as shown in

Table 2. ABAC model fundamental structure.

Component	Description
Subject	The initiator of the access request, such as a user or process.
Resource	The target of the access request, which could be a file, process, IoT device, etc.
Authority	The actions that the subject is permitted to perform on the resources, like opening, reading, or deleting.
Environment	Contextual information provided by the subject during the access request, such as the time of the request or the geographical location of the subject and resource.

.

ABAC enhances access management by associating identities or roles with a defined set of attributes, eliminating the need for separate access control lists (ACLs) for each entity. Since the number of attributes is significantly smaller than the total number of users, ABAC offers greater scalability and efficiency. ABAC allows access control decisions to incorporate dynamically changing attributes, such as time of day and location, without the need to engineer roles, unless role names are used as attributes. Essentially, ABAC can implement DAC, MAC, and RBAC models. For example, DAC can be viewed as ABAC using the “identity” attribute, while RBAC uses the “role” attribute [25]. However, ABAC introduces administrative complexity as it requires managing a potentially large number of attributes. This necessitates careful attribute selection and policy administration by trained security personnel [26]. Due to its granularity and adaptability. ABAC has been widely adopted for access control enforcement in IoT environments [27].

The ABAC framework consists of four essential components: the Policy Enforcement Point (PEP), Policy Decision Point (PDP), Policy Administration Point (PAP), and Policy Information Point (PIP) [28], as shown in Figure 1. The PEP processes the initial access request from the subject and executes the corresponding operation based on the decision returned by the PDP [29]. The PDP evaluates the access request according to established access control policies and sends the decision back to the PEP. The PAP manages the access control policies and offers authoritative guidance to the PDP for decision-making. Lastly, the PIP is responsible for managing the attribute information of subjects, resources, and environments, which is critical for making informed access control decisions [30].

In IoT contexts, relying solely on identities for authenticating users and devices can be challenging because it is difficult to manage and verify device identities [31]. Given the vast number of devices, which vary in processing power, connectivity, and security, managing and authenticating each device based on a static identity is not practical. Instead, incorporating other attributes, such as a user’s location, the time, the device being used, or the current task, alongside other contextual information, tends to be more effective in distributed environments like IoT. This approach enhances context-aware policy enforcement, strengthening security by dynamically adapting to the heterogeneous and evolving nature of IoT ecosystems [32].

3.2. Blockchain Technology

Advancements in storage have led to a significant reduction in storage costs, fueling interest in decentralized storage solutions. In decentralized storage, data are distributed across multiple nodes, instead of being stored on centralized servers. This approach reduces the risk of data breaches, enhances security, and provides users with greater control over their data without relying on third-party providers [33]. Blockchain technology, first introduced with Bitcoin, has emerged as a trustless and temper-resistant ledger that provides transparency, immutability, and decentralization. Blockchain networks can be categorized into public, private, and consortium blockchains based on their access control policies. Public blockchains, such as Ethereum, offer open access to all participants. Private blockchains restrict participation to authorized users only, while consortium blockchains operate under collective governance by multiple organizations [34]. The Ethereum blockchain pioneered smart contracts, self-executing programs that automate secure and transparent transactions without intermediaries. These smart contracts enable various blockchain-based applications, including decentralized applications (DApps), identity management, and access control systems [35,36,37]. Smart contracts are self-executing programs on a blockchain that automatically enforce agreement terms when predefined conditions are met. Their code is transparent, enabling verification, and transactions are trackable and irreversible. Once deployed, they cannot be modified or deleted [38,39].

Enterprise blockchain platforms such as Hyperledger Fabric and Hyperledger Besu provide scalable, secure, and customizable solutions for business applications. Hyperledger Fabric is designed for private and consortium blockchains, allowing organizations to create customized governance models with a high security and scalability [40]. Hyperledger Besu, an Ethereum-based client, supports public, private, and consortium deployments, offering modular security enhancements for enterprise adoption [41].

The Internet of Things (IoT) consists of heterogeneous, interconnected devices that require secure, scalable, and efficient access control mechanisms. Traditional access control models rely on centralized policy storage and decision-making, leading to single points of failure, security breaches, and data-tampering risks [42,43]. Blockchain enables a decentralized access control model in which access policies, permissions, and user roles are immutably recorded on a distributed ledger. This framework enhances security, reliability, and transparency in IoT environments [44].

Blockchain-based access control enhances traditional role-based access control (RBAC) and attribute-based access control (ABAC) models by providing the secure, automated enforcement of policies through immutable ledgers and smart contracts. In RBAC, blockchain securely stores user roles and permissions, while smart contracts automatically enforce access policies. Unauthorized actions can be logged, and violations can trigger penalties enforced by the smart contract [45]. Similarly, in ABAC, smart contracts dynamically enforce access control policies based on user attributes, environmental conditions, and device status, ensuring adaptive and fine-grained access control [46]. Blockchain’s cryptographic security mechanisms further strengthen access control by preventing unauthorized access, minimizing insider threats and mitigating risks of data manipulation [47].

Moreover, blockchain can integrate with challenge response authentication protocols, further strengthening access security across multiple IoT layers. This ensures real-time verification, while the minimizing risks associated with centralized key management and policy enforcement [48,49].

4. Related Work

Access control in IoT systems is crucial for ensuring data security, privacy, and resource management. Attribute-based access control (ABAC) models have gained popularity due to their flexibility, considering attributes such as identities, roles, and contextual parameters. Traditional access control solutions for IoT are either centralized or decentralized. With the advent of blockchain technology, decentralized access control models have been widely explored due to their immutability, transparency, and ability to remove single points of failure. Several studies have introduced blockchain-based access control mechanisms, each addressing different aspects such as smart contract enforcement, cryptographic security, edge computing, and interoperability challenges.

One prominent approach is the use of smart contracts to enforce access control policies in a decentralized manner. Zhang et al. [12] introduced a smart contract-based access control model that integrates ABAC principles within a blockchain framework. While their system enables distributed policy enforcement, it lacks scalability for large-scale IoT environments and does not support real-time policy updates. Similarly, Hasan et al. [15] developed a blockchain-based access control framework with smart contract-driven policy enforcement, ensuring tamper-proof mechanisms. However, their approach does not dynamically adjust permissions based on contextual changes. Zaidi et al. [14] proposed a transaction-based access control system that incorporates ABAC into blockchain networks, yet their solution is not adaptive to real-time environmental changes. Tomaz et al. [50] explored a smart contract-driven ABAC model for auditing access attempts but failed to provide a framework for dynamic policy generation.

To enhance security, many researchers have incorporated cryptographic mechanisms into blockchain-based access control. Wang et al. [13] proposed a decentralized storage framework with fine-grained access control by leveraging cryptographic techniques. However, the approach introduced a high computational overhead, making it impractical for resource-constrained IoT devices. Shi et al. [51] utilized lightweight encryption to protect privacy in distributed IoT systems but noted that traditional access control methods are more efficient for small-scale IoT networks. Sookhak et al. [52] conducted a comparative study of 28 blockchain-based access control methods for healthcare records, identifying key security challenges such as user and attribute revocation, privacy concerns, and blockchain network scalability issues. Dhar et al. [53] proposed a mutual authentication and key management scheme for IoT, but their model lacks a dynamic method for generating new access control policies in evolving environments.

To address latency and scalability concerns, some studies have explored the integration of blockchain with edge computing. Soo et al. [54] deployed a blockchain-based access control model on edge devices using Hyperledger Sawtooth 1.0 to execute smart contracts. Although the system reduces storage requirements by using compact JSON transactions, it exhibits inconsistencies in access time. Zhu et al. [55] proposed an edge computing-based blockchain model for smart grids, combining Ciphertext Policy Attribute-Based Encryption (CP-ABE) with edge nodes. While their design enhances security and reduces the computational overhead, it still lacks efficient mechanisms for real-time policy updates. Butun et al. [56] explored hybrid models incorporating threshold signatures and trusted computing but acknowledged processing delays and inefficiencies in IoT settings. Putra et al. [57] introduced a Trust and Reputation System using an attribute-based access control mechanism in a hybrid blockchain model. However, new devices face difficulties in joining the network due to their initial zero-reputation scores.

Interoperability remains a challenge in blockchain-based access control, as most existing models lack cross-platform compatibility. Qi et al. [58] developed a blockchain-enabled access control system for Green Smart Devices (GSDs) based on decentralized identifiers (DIDs). Their system effectively manages authentication through a vendor-based consensus platform but does not support cross-platform access control or dynamic environmental adaptation. Iftekhar et al. [59] integrated IoT devices with Hyperledger Fabric to establish a trusted route for access control, yet their model lacks runtime policy generation and requires a further assessment of memory constraints, power consumption, and scalability. Lyu et al. [60] proposed a blockchain-based access control token mechanism that allows continuous access within a token’s validity period. However, this exposes the system to security vulnerabilities and scalability challenges due to the overhead of managing tokens for millions of devices in large IoT networks.

Several studies have explored blockchain-based access control models specifically for industrial IoT (IIoT) and smart grid environments. Banerjee et al. [61] proposed a fine-grained access control scheme for IIoT using a constant-size key and ciphertext. However, their approach lacks automation and keyword search capabilities over encrypted data. Bera et al. [62] developed a blockchain-based access control protocol for smart grids using attribute-based encryption (ABE) to secure data transmission between smart meters and service providers. While their system enhances traceability and secrecy, it does not support keyword-based searching, limiting its usability in large-scale deployments. Ma et al. [63] proposed DBACP-IoTSG, a decentralized access control protocol for smart grids, utilizing a voting-based consensus mechanism for validating smart meter data. Despite its security enhancements, the system still faces challenges in balancing transparency with scalability.

Blockchain-based access control has also been investigated in healthcare applications, where strict access control is required to protect sensitive medical data. Egala et al. [64] designed a blockchain-based distributed storage system for the Internet of Medical Things (IoMT), introducing a Selective Ring-based access control mechanism. While their approach enhances data privacy and reduces single points of failure, it is not well suited for machine-to-machine (M2M) communications in IIoT environments. Sun et al. [65] presented a transaction-based access control system integrated into the Bitcoin blockchain with cryptographic enhancements. However, its reliance on the proof-of-work (PoW) mechanism makes it unsuitable for real-time applications due to inherent latency.

Table 3. Summary of blockchain-based access control approaches.

Reference	Approach Used	Blockchain Type	Key Features	Limitations
Smart Contract-Based Access Control
Zhang et al. [12]	Smart contract-based AC model using blockchain	Public Blockchain (Ethereum)	Ensures transparency by using a public blockchain (Ethereum) with smart contract-based ABAC for decentralized IoT access control	Scalability and cost challenges due to Ethereum’s PoW consensus
Zaidi et al. [14]	ABAC model with smart contracts for IoT using multichain blockchain	Private Blockchain (Multichain)	Smart contract-based ABAC, PoA consensus, IPFS for data storage, attribute recording, tamper-resistance, improved scalability	Lacks trust dynamics, no real-time attribute updates, scalability limited by static policies
Hasan et al. [15]	Smart contract-based decentralized access control framework	Public Blockchain (Ethereum, Ropsten Testnet)	Three-stage architecture (initialization, ACP, inspection); policy enforcement via smart contracts, misuse detection, two-factor authentication, gas-cost analysis, Slither-based vulnerability testing	No support for dynamic attribute management, limited scalability testing, lacks integration with real-time IoT applications
Tomaz et al. [50]	Privacy-preserving healthcare using NIZKP and blockchain	Permissioned Blockchain	Non-interactive zero-knowledge proofs (NIZKPs), patient-controlled ABAC, ABE for secure data sharing, full patient data ownership	High complexity in authentication for constrained devices, less suitable for non-health IoT domains, lacks dynamic trust logic
Cryptographic-Based Access Control
Wang et al. [13]	Hyperledger Fabric-based access for IoT	Permissioned Blockchain (Hyperledger Fabric)	Supports fine-grained access control for decentralized storage using CP-ABE and smart contracts	Lacks efficient key management for large-scale systems, affecting scalability
Shi et al. [51]	BacS: Blockchain-based access control for distributed IoT	Private Blockchain (Ethereum Private Chain)	Uses blockchain wallet address as identity, stores access control policies on-chain, implements symmetric encryption for privacy	High computational and storage overhead for small-scale IoT; lacks efficient retrieval methods
Sookhak et al. [52]	Blockchain-based access control for healthcare	Various Blockchain Types	Reviews 28 access control solutions, analyzes blockchain types, consensus mechanisms, and strategies	Scalability concerns, security risks in attribute revocation, privacy issues with outsourced data
Dhar et al. [53]	Zero-trust-based IoT security framework with blockchain	Private Blockchain	Risk-based segmentation, zero-trust architecture, device-level authentication, blockchain for access logs and trust extension, security guidelines	Lacks formal policy enforcement mechanism, no real-time trust recalibration, no fine-grained access control model
Latency and Scalability of Access Control
Soo et al. [54]	Edge-based access control with Hyperledger Sawtooth	Permissioned Blockchain	Uses smart contracts, JSON-based policy storage, distributed trust model	High inconsistency in access time due to edge computing limitations
Zhu et al. [55]	TBAC: Transaction-based ABAC integrated with CryptoTBAC	Public Blockchain	Flexible permission management via transaction types, decentralized authorization, script-based policy logic, secure attribute exchange	Script-based logic adds complexity, lacks dynamic policy updates, no trust-based adaptation
Butun et al. [56]	Various distributed access control approaches	Permissioned	Threshold signature, reputation, trusted computing, identity, ACL, hybrid access control models	High energy use, processing delays, unsuitable for IoT
Putra et al. [57]	Decentralized ABAC with Trust and Reputation System (TRS)	Hybrid (Public + Private Sidechains)	Trust-based dynamic access control, recursive trust and reputation evaluation, TRS-based decision-making, privacy via sidechains	Complex trust evaluation logic, performance limitations on large-scale deployments, reliance on consistent trust feedback
Interoperability
Qi et al. [58]	Fine-grained access control for cloud-assisted IIoT	Hybrid (Public and Private Cloud)	Uses CP-ABE encryption, hybrid cloud infrastructure, item-level data protection	High computational cost for CP-ABE, privacy risks from key authority compromise
Iftekhar et al. [59]	Hyperledger Fabric-based access control for IoT	Permissioned Blockchain (Hyperledger Fabric)	Implements attribute-based access control (ABAC), secure chaincode execution, integrates IoT devices	No runtime policy generation, high latency in policy updates, scalability issues
Lyu et al. [60]	SBAC: Blockchain-based access control for ICN	Private Blockchain	Hierarchical access via matching-based model, blockchain-based access tokens, Cuckoo filter for fast query, support for audit and revocation	Focused on ICN use-case, limited generalizability for broader IoT scenarios, complex token verification scheme
Smart GRID
Banerjee et al. [61]	Multi-authority CP-ABE-based fine-grained access control for IIoT	Private Blockchain	Supports multiple attribute authorities, constant-size key and ciphertext, policy-hidden encryption, and outsourced computation	Lacks automation and keyword search over encrypted data
Bera et al. [62]	DBACP-IoTSG: Blockchain-based AC protocol for IoT-enabled smart grid	Private Blockchain	Uses voting-based PBFT consensus, secure smart meter data collection, leader-based block validation	High computation cost for cryptographic operations, scalability concerns
Ma et al. [63]	BDKMA: Blockchain-based distributed key management for hierarchical access control	Multi-Blockchain (Fog + Cloud)	Hierarchical key management, fog-assisted latency reduction, decentralized trust model, cross-domain access control, dynamic group authorization	High system complexity, trust challenges in inter-chain operations, limited real-time policy reactivity
Hybrid Blockchain Access Control
Egala et al. [64]	Fortified Chain: Blockchain-based decentralized EHR with SRAC	Hybrid (Blockchain + IPFS)	Selective Ring-based access control (SRAC), hybrid edge–cloud model, smart contracts, IPFS-based distributed storage, privacy-preserving patient data management	Scalability challenges with large medical datasets, higher latency in hybrid operations, lacks dynamic policy tuning
Sun et al. [65]	Cross-domain ABAC system using permissioned blockchain (HLF)	Permissioned Blockchain (Hyperledger Fabric)	Identity-based signatures (IBSs), PDP selection algorithm, local ledgers per IoT domain, cross-domain access via channels, off-chain PDP decisions	Requires multiple domain configurations, higher setup complexity, potential performance bottlenecks in cross-domain coordination

summarizes the existing literature on blockchain-based access control. It highlights the approaches, blockchain types, key features, and associated limitations. Public and consortium blockchains offer decentralization and security but suffer from high transaction costs and latency. Private blockchains, on the other hand, provide better scalability but may lack interoperability and trust.

The existing literature on blockchain-based access control highlights several common challenges, including a limited scalability, high computational overhead, lack of real-time policy adaptation, interoperability issues, and inefficiencies in resource-constrained environments. While smart contract-based approaches improve decentralization, they often suffer from policy rigidity. Cryptographic-based models enhance security but introduce computational burdens. Edge and fog computing integrations attempt to address latency but still lack consistent performance in real-time scenarios. Additionally, cross-platform interoperability remains a significant challenge for large-scale IoT networks.

To address these gaps, this paper proposes a scalable, adaptive, and context-aware blockchain-based access control framework. Our approach introduces dynamic policy updates, lightweight cryptographic mechanisms to reduce the computational overhead, and an optimized blockchain structure for enhanced scalability and interoperability. By integrating context-aware decision-making and automated access control policies, our model significantly improves upon existing solutions, making it well suited for large-scale IoT and industrial environments.

5. Proposed System Architecture for Dynamic ABAC

The proposed system integrates dynamic ABAC with blockchain technology to enhance the security of smart home energy devices. The ABAC dynamically controls access to specific devices and services based on attributes such as identity, role, device type, and energy context. This approach optimizes network performance and mitigates real-time attacks through continuous monitoring, adaptable policy creation, and the supervision of network security and communication elements. The proposed model includes a hybrid blockchain, smart contracts, KYC-based identity verification, real-time attribute repository, and dynamic trust recalibration as core components, as shown in Figure 2 and also described in Algorithm 1.

Algorithm 1. Dynamic ABAC with Hybrid Blockchain
START
Step 1:	INPUT Collection
	Collect user/device ID, requested action, trust score (TS), energy sensitivity weight (Te), and System defined attributes.
Step 2:	Device/User Registration
	Generate RSA key pair (Kpub, Kpriv), sign metadata. Attach a timestamp (Tstamp) to prevent replay attacks. For energy-sensitive devices: ○ Require multi-step authentication (KYC + Biometric). ○ Validate manufacturer-issued certificate to confirm authenticity. ○ Perform an energy compliance check before approving the device,
Step 3:	Identity Verification and Validation
	Verify user identity via KYC authentication. For energy-sensitive devices: ○ Confirm owner identity and operator authorization. ○ Fetch attributes from User Attribute Contract (UAC). ○ If verification fails → Reject request.
Step 4:	Metadata and Certificate Validation
	Validate metadata in Hyperledger Fabric. For energy devices: ○ Ensure certificates are from trusted manufacturers. ○ Cross-check regulatory compliance. ○ If validation fails → Reject registration.
Step 5:	Certificate Issuance and Storage
	Generate and store digital certificates securely in Hyperledger Fabric.
Step 6:	Access Request Submission
	User/device submits request to Policy Decision Point (PDP). For high-energy devices (e.g., HVAC, battery storage): ○ Require Multi-Factor Authentication (MFA). ○ Cross-check role and trust score (TS). ○ Implement real-time anomaly detection.
Step 7:	Attribute and Policy Retrieval
	Fetch attributes from UAC and DAC. Retrieve policies from Access Policy Contract (APC). For energy devices: ○ Check energy consumption policies and thresholds. ○ If policy violation occurs → Deny access and flag request.
Step 8:	Trust Score Evaluation
	If TS < TSmin (80% for energy-critical devices) → Deny access.
Step 9:	Policy-Based Access Evaluation
	Match attributes with energy-aware policies. If conditions fail → Deny and log event.
Step 10:	Multi-Factor Authentication (MFA) Check
	If MFA required → Trigger authentication (Biometric + OTP).
Step 11:	Policy Enforcement and Smart Contract Execution
	Fabric stores attributes, Besu enforces access policies.
Step 12:	Grant or Deny Access
	If approved: Grant access, log event, monitor energy usage. If denied: Decrease TS, issue failure response, allow recovery if policy is met.
Step 13:	Trust Score Recalibration
	Monitor failed attempts, anomalies, compliance. For energy devices: Unauthorized access → Reduce TS rapidly. If TS < threshold, trigger alerts and restrict access.
Step 14:	Security Monitoring and Anomaly Detection
	Detect policy violations and unauthorized attempts. For energy devices: ○ Analyze real-time power consumption for anomalies. ○ Flag irregular energy usage spikes. ○ If a grid configuration is altered without authorization, revoke access.
Step 15:	Quarantine and Revocation Mechanism
	If TS drops below critical threshold, revoke certificate & quarantine device. For energy devices: ○ Block unauthorized grid/hardware access. ○ If multiple attempts persist → Escalate to security team, blacklist device if necessary.
Step 16:	Blockchain Logging and Record Update
	Log access events, trust recalibrations, and policy changes in Hyperledger Fabric. Ensure tamper-proof auditing for compliance and security.
END

5.1. Hybrid Blockchain Integration for Secure and Controlled Access

The system is deployed across two blockchain platforms, Hyperledger Fabric and Hyperledger Besu, both hosted on AWS. This hybrid blockchain model ensures security and flexibility in the smart home ecosystem. Fabric handles internal, permissioned operations, while Besu enables external interactions via Ethereum’s public network.

Fabric acts as a private blockchain for IoT device authentication and communication. Its Membership Service Provider (MSP) and Certificate Authority (CA) verify devices before granting access. PEPs apply access control at both device and data levels, while PDPs evaluate requests in real time using PIPs. Fabric’s ABAC ensures fine-grained access control, logging all decisions for auditing. Operating in a trusted environment, Fabric eliminates transaction fees, allowing an efficient data exchange.

Besu facilitates public blockchain interactions, supporting token-based incentives for energy efficiency and connectivity with decentralized applications (DApps) and public services like weather APIs. It acts as a PDP via smart contracts, dynamically evaluating access policies. While Besu incurs transaction fees, its Ethereum compatibility makes it ideal for asset trading and external integrations.

5.2. Smart Contracts for Dynamic ABAC

To implement a dynamic ABAC in smart home energy systems, a modular contract architecture is required to efficiently handle, evaluate, and enforce access requests. These contracts consider multiple attributes, such as the following:

• User Role: Differentiates between homeowners, tenants, energy managers, and utility providers;
• Device Sensitivity: Classifies devices as critical (e.g., smart meters, battery storage, HVAC systems) or non-critical (e.g., smart lights, smart plugs);
• Energy Consumption Context: Real-time power usage, peak demand periods, and available renewable energy sources;
• Environmental Context: Evaluates real-time conditions such as time of day, user location, and household energy demand to adapt policies dynamically.

The proposed architecture comprises six smart contracts deployed on a hybrid blockchain system, as shown in Figure 3. Hyperledger Fabric hosts the User Attribute Contract (UAC), Resource Attribute Contract (RAC), Device Attribute Contract (DAC) and Certificate Management Contract (CMC), whereas Hyperledger Besu hosts the Access Policy Contract (APC) and Access Decision Contract (ADC).

5.2.1. User Attribute Contract

The UAC securely stores and manages user-related attributes like energy usage, access privileges, location, and time-based conditions. It supports dynamic, context-aware access control by working with the PDP, which evaluates access requests based on predefined PAP rules and additional attributes from the PIP when needed. The PEP enforces these decisions at the device or resource level, ensuring a secure and adaptive smart home ecosystem.

5.2.2. Resource Attribute Contract

The RAC manages metadata on devices, including their classification (critical/non-critical) and operational status. The PEP references PDP rules incorporating RAC attributes to verify compliance before executing an action, enabling secure cross-domain interactions in smart home environments.

5.2.3. Device Attribute Contract

The DAC stores device-specific details like identifiers, manufacturers, firmware version, and energy metrics. During the runtime, the PDP retrieves these attributes to enforce policy-compliant access in the hybrid smart home energy ecosystem.

5.2.4. Certificate Management Contract

The CMC supervises the certificate lifecycle management. The CMC is key in maintaining PKI systems on blockchains. It issues, stores, validates, renews, revokes, and maintains the credibility of digital certificates automatically.

5.2.5. Access Policy Contract

The APC enforces access control policies, integrating with tools and DApps. Policies adapt to user roles, devices, time, and location. The PDP queries the APC to evaluate re-quests, ensuring flexible and secure user–device interactions.

5.2.6. Access Decision Contract

The ADC, acting as the PDP, evaluates access requests in real time by retrieving attributes from Fabric (UAC and DAC) and policies from Besu (APC). It ensures secure, adaptive, and context-aware access control by leveraging Fabric’s privacy and Besu’s execution efficiency.

These smart contracts work together to ensure granular, real-time access control, enhancing both security and flexibility in smart home energy ecosystems.

5.3. KYC-Based Identity Verification

Before any smart energy device can connect to the network, it must go through the KYC (Know Your Customer) verification process to ensure allowed access. This requires the creation of an account, as well as the submission of evidence of identification. In a private blockchain situation, Fabric’s CA issues a digital certificate, which allows devices and users to communicate securely. The KYC results are maintained on Hyperledger Fabric, which ensures transparency and accountability. ABAC rules, paired with KYC verification, improve access control by granting rights based on attributes such as role, identity, or device type. In public interactions, KYC is used to control activities such as token-based reward mechanisms. For example, a smart home device that earns tokens by optimizing energy usage would need to go through KYC to verify that the device and its owner are legitimate. This check prevents attackers from tricking the system or abusing token rewards.

5.4. Real-Time Attribute Repository

The real-time attribute store dynamically manages critical information using the Hyperledger Fabric state database. This store provides secure and efficient data management and supports real-time updates, ensuring that the most up-to-date context is always available. CouchDB is used as the state database for Hyperledger Fabric because it allows rich JSON-based queries for complex attribute evaluations. Hyperledger Fabric provides a secure and tamper-proof store for sensitive user and device attributes. Attributes stored in Fabric are used by the UAC and RAC, allowing for granular and dynamic policy adjustments based on real-time situations. Fabric eliminates transaction fees by simplifying frequent attribute updates without additional costs. The CouchDB interaction with the blockchain platform is represented in Figure 4.

5.5. Dynamic Trust Recalibration

Dynamic trust recalibration continuously evaluates user and device behavior against trust metrics and adjusts trust scores accordingly. User behavior, device stability, and environmental factors are securely stored in CouchDB. Smart home devices and external APIs can feed data to the system in real time to detect anomalous behavior. Whenever an anomaly is identified, the trust evaluation engine (TEE) recalibrates trust scores based on predefined rules. Access policies dynamically reference these updated trust scores to grant or restrict access. All trust score adjustments are immutably logged on the blockchain, ensuring transparency and accountability, as represented in Figure 5.

6. Proposed Model Implementation

6.1. Device Registration Process on Blockchain

In a smart home environment, only authenticated and authorized smart energy devices are allowed to access the network. The process starts with device initialization and identity verification. Whenever a new device tries to access the network, it sends a registration request on Hyperledger Fabric. The smart device uses an RSA algorithm to generate a unique public–private key pair (K_pub, K_priv). Then, a registration packet is created, which includes a device unique identifier, manufacturer details, firmware version, device categorization based on security level (high, moderate, and low), and owner credentials. This serves as metadata (M_device) for the device and is signed using K_priv as expressed in Equation (1). A timestamp (T_stamp) is also appended to prevent replay attacks and ensure authenticity and integrity.

S_device = Sign (K_priv, [M_device, T_stamp]),

(1)

Before the registration request is processed, the owner’s credentials must go through a KYC verification process to ensure legitimacy. The owner provides proof of identification and creates an account, after which their details are validated against the KYC repository. This step ensures that only verified owners can register devices, preventing malicious actors from gaining unauthorized access.

Once KYC verification is successful, a secure TLS session is established on a gateway node in order to ensure that the registration request cannot be interrupted or tampered with during transmission. The gateway node forwards the registration request to a dedicated peer node in the Hyperledger Fabric network. Upon receiving the request, the DAC verifies the digital signature using the public key as expressed in Equation (2).

V_device = Verify (K_pub, S_device),

(2)

The DAC validates the metadata from CouchDB, which is storing the records of approved device metadata. If the submitted metadata match the approved database record, the device is validated and registered. If not, the request is rejected. The UAC authenticates the associated owner credentials via the KYC repository. If all validations are successful, the Hyperledger Fabric Certificate Authority (CA) issues a digital certificate binding the public key, device identifier, and owner details in a tamper-proof format as shown in Equation (3).

C_device = Cert (K_pub, UD_ID, owner_info),

(3)

This immutable certificate is stored on the blockchain ledger by the CMC, ensuring a secure audit trail. A success response, along with the certificate, is sent back to the device. The issued certificate is subsequently used for secure interactions within the smart home energy system. The complete device and user registration process is represented in Figure 6 and Figure 7, respectively.

6.2. Data Storage/Collection

CouchDB securely stores the attributes of connected smart home energy devices, smart contracts, access policies, trust level history, and real-time IoT-generated data as shown in Figure 8. This data is stored in JSON format, permitting unified integration with the ABAC mechanism. Each record is indexed and queried by means of rich JSON queries, allowing efficient access policy evaluations. Access policies and the trust level history, which serve as critical data in our case, are hashed by means of the SHA-256 algorithm before being logged on the blockchain to guarantee immutability. SHA-256 provides a strong level of security, while ensuring a low computational overhead and efficient processing. This makes it ideal for the constrained computational capabilities of IoT devices in smart home environments. SHA-256’s balanced performance ensures secure data integrity and authentication, which is crucial for maintaining the reliability and efficiency of the system in real-time operations. For a data entry D, its hash H_d is computed as shown in Equation (4).

H_d = SHA-256(D),

(4)

This hash is stored in the Fabric ledger, whereas the original data resides in CouchDB. The authenticity of policies or trust levels can be verified by comparing H_d with the on-chain hash, guaranteeing no tampering. The real-time data generated by smart home devices is enriched before storage by appending the M_device, device id UD_ID, and Timestamp T_stamp value for data traceability and temporal accuracy, as expressed in Equation (5). The CouchDB change feed updates records nonstop, supporting dynamic policy evaluations in ABAC.

M_final = {M_device, UD_ID, T_stamp, RTD},

(5)

6.3. Trust Evaluation Framework (TEF)

The trust evaluation framework assigns a trust score to the device based on several trust metrics such as identity T_i, behavior T_b, reliability T_r, security T_s, history T_h and the energy sensitivity factor T_e. The details of these metrics are defined in

Table 4. Trust metrics.

Evaluation Criteria	Description	Effect on Trust Score	Smart Home Energy Context
Identity Authentication	Verifies device credentials, manufacturer details, firmware, and KYC compliance.	Trust rating improves upon successful authentication. Devices from verified manufacturers receive a higher initial trust score.	Smart meters, solar inverters, and HVAC systems must have manufacturer-issued energy certifications.
Behavior Monitoring	Tracks real-time actions and interactions of the device.	Trust score decreases if suspicious activity is detected (e.g., irregular data patterns, multiple failed access attempts).	Detects excessive energy usage anomalies, signaling potential misuse or unauthorized device access.
System Reliability	Measures device stability, including uptime, response speed, and error frequency.	Higher scores are assigned to devices with consistent performance. Trust rating drops if frequent failures or downtime occur.	Ensures HVAC, battery storage, and grid controllers maintain operational stability.
Security Adherence	Assesses firmware updates and compliance with security protocols.	Trust score decreases for outdated or unpatched firmware. Devices meeting security standards earn higher trust rating.	Smart home energy devices must comply with energy grid security protocols.
Energy Consumption Efficiency	Evaluates whether devices operate within expected energy limits.	Devices exceeding energy limits see a decrease in trust score.	Prevents overconsumption or inefficient energy device behavior.
Interaction History	Examines past access attempts, security breaches, and recalibrations.	Devices with frequent anomalies have lower trust; stable history increases trust.	A smart meter repeatedly accessed from multiple unauthorized locations gets flagged.
Grid Impact and External Factors	Analyzes manufacturer’s reputation and impact on the smart grid.	Poor reputation or past vulnerabilities reduce trust.	Devices interacting with the power grid require extra validation to prevent unauthorized power flow changes.

.

For the inclusion of a device on the network, weights are assigned to each metric. The trust score can be computed as shown in Equation (6).

TS = w₁T_i + w₂T_b + w₃T_r + w₄T_s + w₅T_h + w₆T_e,

(6)

Once a score is calculated, it is compared with the minimum-threshold TS_min value. TS_min is a critical parameter in the trust evaluation framework, as it determines which devices are allowed to participate in the network based on the specific requirements of the system, such as security sensitivity, performance expectations, and the operational environment. The mathematical model for a simple static threshold, which is ideal for systems where resources are constrained, is given in Equation (7),

TS_min = Predefined Value,

(7)

For devices that balance security with flexibility, a dynamic statistical threshold can be computed as shown in Equation (8),

$${\mathrm{T}}_{\mathrm{m}\mathrm{i}\mathrm{n}}=\mathsf{\mu }-\mathsf{\beta }·\mathsf{\sigma },$$

(8)

Beta: Sensitivity factor (e.g., =1 for strict inclusion, =0.5 for lenient inclusion).

Risk-aware dynamic adjustment offers the highest level of protection but needs sophisticated mechanisms to detect and respond to risks in real time. As shown if Equation (9),

$${\mathrm{T}}_{\mathrm{m}\mathrm{i}\mathrm{n}}={\mathrm{T}}_{\mathrm{b}\mathrm{a}\mathrm{s}\mathrm{e}}+\mathsf{\gamma }·\mathrm{R}\mathrm{i}\mathrm{s}\mathrm{k}\mathrm{L}\mathrm{e}\mathrm{v}\mathrm{e}\mathrm{l},$$

(9)

T_base: Base threshold;

T_min: Based on the network’s current risk level;

γ: Weight for adjusting.

Smart home energy devices can be categorized into three security classes, high, moderate, and low, based on these threshold levels.

Table 5. Evaluation criteria.

Evaluation Criteria	Description	Effect on Trust Score (TS)	Smart Home Energy Context
Identity Verification (Ti)	Ensures device and user credentials are validated through KYC and blockchain certificates.	Verified identity increases TS. Unverified identity or mismatched credentials lower TS.	Energy devices (e.g., smart meters, battery storage units) require a stricter identity verification.
Behavior Monitoring (Tb)	Tracks real-time activity, failed access attempts, and suspicious usage patterns.	Normal behavior maintains TS. Anomalies (e.g., unauthorized control attempts) reduce TS.	If a solar inverter is accessed from an unregistered IP, TS drops immediately.
Device Reliability (Tr)	Measures uptime, failure frequency, and response times.	Reliable devices retain high TS. Devices with frequent crashes see TS decrease.	An HVAC system that fails frequently may be compromised and should be flagged.
Security Compliance (Ts)	Checks firmware updates, encryption status, and adherence to security policies.	Regular updates improve TS. Outdated firmware lowers TS.	Smart meters must meet energy security compliance to maintain access.
Historical Trust Score (Th)	Evaluates previous interactions and recalibrations.	Good past behavior boosts TS. Multiple flagged events lower TS.	Grid controllers with frequent unauthorized access attempts face a stricter TS recalibration.
Energy Sensitivity Factor (Te)	Considers device energy consumption and grid impact.	Low-impact devices (smart lights) require lower TS. High-impact devices (smart grid controllers) require higher TS.	If an EV charger exceeds energy limits, the TS decreases dynamically.

presents the classification of different appliances into these categories, along with the recommended TS_min value.

Devices with a TS greater than equal to TS_min are added to the network, whereas devices with a TS less than TS_min are excluded.

Figure 9 illustrates the proposed dynamic trust evaluation framework for smart home environments. It depicts the TS evaluation, adjustments, access control updates, and interactions between trust evaluation, policy enforcement, and real-time updates based on smart device behavior.

6.4. Dynamic Trust Recalibration (DTR)

Dynamic trust recalibration (DTR) is a powerful system that constantly examines smart home energy devices and user behavior, updating trust scores based on real-time information, as illustrated in Figure 10. It employs smart contracts to automate trust score updates and enforce security standards, ensuring accountability and safety. The trust evaluation framework gathers user attributes from the UAC, resource information from the RAC, and device metrics from the DAC. This information is examined for anomalies, such as unwanted access attempts, unusual traffic patterns, or extended idleness. TSs are dynamically modified:

• Positive Adjustments: Devices and users demonstrating secure and reliable behavior, such as successful authentications and reliable operations, see their scores increase when the TS is above the minimum threshold (TS_min);
• Negative Adjustments: Anomalies or behaviors below the TS_min trigger a recalibration, reducing trust scores.

Recalibration events are immutably logged by the CMC and referenced by the APC. The APC dynamically updates access rules based on the recalibrated scores, while the ADC enforces these policies during real-time interactions. Smart contracts automate the entire process, ensuring the trust recalibration and policy enforcement are transparent, adaptive, and secure. The immutability of blockchain ensures the system remains tamper-proof and trustworthy.

7. Policy Framework

A dynamic security framework that enforces policies based on the trustworthiness of devices, user behavior, and contextual attributes ensures increased smart device interconnectivity. The proposed framework dynamically recalibrates trust scores (TSs) and enforces context-aware policies to regulate device interactions. The policy framework ensures granular trust-based access and dynamic trust adjustments and is divided into two categories:

7.1. Device-Level Policies

7.1.1. Device Acceptance Policy

Any new device that wishes to join the network undergoes a trust establishment phase before full integration.

Policy A: Initial Restricted Access for New Devices
Rule	New device can only communicate with N devices for the first T hours.
Purpose	Stop a rogue device from instantly interacting with all devices.
Condition	If (TS < TSmin & Talive < T), communicate with N devices within zone.
Action	Restrict access; allow incremental communication as TS increases.

Policy B: Progressive Trust-Based Access
Rule	A new device cannot initiate communication with high-security devices until it achieves a TS ≥ 70%.
Purpose	Stop unauthorized devices from accessing critical infrastructure.
Condition	If the (TS < 70%), inter-zone communication is not allowed.
Action	Log attempts, adjust TS accordingly.

7.1.2. Device Access Policies

Policies ensure that only authorized devices with suitable trust levels can interact.

Policy C: Trust-Based Device Communication
Rule	A device can access another device only if its TS and priority is higher than the target device’s threshold.
Purpose	Only trusted devices are allowed to initiate communication.
Condition	If (TS + Priority) ≥ (TS target + Required Level), access is granted.
Action	Log access requests; if TS is insufficient, deny and reduce TS.

Policy D: Monitoring Devices Cannot Send Control Commands
Rule	A device with a monitoring role cannot send control signals.
Purpose	Only trusted devices are allowed to initiate communication.
Condition	If (Device_Role) = “Monitoring”, deny control requests.
Action	Generate a security alert on repeated attempts.

Policy E: Centralized Device Control Enforcement
Rule	A device can receive control data from only one controlling device at any given time.
Purpose	Prevent conflicting control signals.
Condition	If (Active (Control Request)), deny control requests.
Action	Place additional requests in a pending state.

7.1.3. Access Limitation Policy

The following policies prevent rogue devices from taking over the network and attempting flooding attacks.

Policy F: Trust-Based Limited Control Broadcasting
Rule	A monitoring device can send control signals to multiple devices only if its TS is above a defined threshold.
Purpose	Prevent large-scale attacks and unauthorized mass control attempts.
Condition	If the (TS < 50%), restrict control to a maximum of N devices at a time.
Action	Deny excessive control requests, recalculate TS; if the (TS < 40%), quarantine the device.

Policy G: Restricted Large-Scale Control Access
Rule	Only authorized supervisory devices with a TS ≥ 80% can initiate mass control operations.
Purpose	Ensure only trusted devices can send commands to multiple devices.
Condition	If (User_Role! = “Supervisor”) OR (TS < 80%), deny mass control requests.
Action	Revoke access and lower the TS if unauthorized attempts persist.

Policy H: Network-Wide Broadcast Prohibition
Rule	No device can broadcast messages to all network devices simultaneously.
Purpose	Prevent flooding attacks and network congestion.
Condition	If a device attempts a network-wide broadcast, reset its TS to zero.
Action	Immediately quarantine the device and flag it for security review.

7.2. User-Level Policies

To ensure dynamic and trust-based access control for users, policies are enforced based on user behavior, their trust score (TS), and contextual attributes such as role, device sensitivity, and historical compliance.

Policy I: Trust-Based Multi-Factor Authentication (MFA)
Rule	A user must provide additional authentication factors if their TS is below a defined threshold.
Purpose	Stop unauthorized access by requiring stricter authentication for low-trust users.
Condition	If the (TS < threshold), enforce MFA
Action	Reject access on authentication failure and lower the TS further on repeated failures

Policy J: Adaptive RBAC
Rule	A user can only access specific device categories and operations based on their role and TS.
Purpose	Restrict users to their assigned permissions while adapting access dynamically based on trust level.
Condition	If (User_Role = “Energy Auditor”) → Can access energy monitoring and optimization devices only. If (User_Role = “Homeowner”) → Can control home energy management devices. If the (TS < 50%), restrict access to critical energy functions.
Action	Deny unauthorized requests, log violations, and lower the TS for misuse attempts.

Policy K: Trust-Driven Time-Based Access
Rule	Users with a lower TS have restricted access windows for security-sensitive devices.
Purpose	Prevent unauthorized late-night access and enforce time-sensitive controls.
Condition	If the (TS ≥ 80%), full access 24/7. If the (TS < 80%), access is allowed only between 6 a.m.–10 p.m. If the (TS < 40%), restrict access to non-sensitive functions only.
Action	If an access request occurs outside the allowed timeframe, deny access and reduce the TS.

Policy L: Behavior-Based Access Restrictions
Rule	Users with a lower TS have restricted access windows for security-sensitive devices.
Purpose	Detects potential attackers or compromised accounts.
Condition	If (Failed Attempts ≥ 3), reduce the TS by 10%. If (Failed Attempts ≥ 5), enforce a mandatory cooldown period before retrying. If the (TS < threshold), flag the user for administrative review.
Action	Lock the account if continuous violations occur and alert security admins.

Policy M: Device Sensitivity-Based User Authentication
Rule	Users require a higher authentication to access high-security devices.
Purpose	Ensure sensitive devices are accessed only by trusted and authorized users.
Condition	If (Device_Security_Level = “High”) AND (TS < threshold), enforce biometric + OTP authentication. If (Device_Security_Level = “Moderate”), password + OTP required. If (Device_Security_Level = “Low”), password-only access is allowed.
Action	If authentication fails, lock access for T minutes and reduce the TS.

8. Workflow and Scenario

To explain the working of the proposed methodology, a complete system workflow is presented as a common use-case example to ensure secure, efficient, and context-aware access control in a smart home environment.

• A smart home device initiates a registration request by generating an RSA-based public–private key pair.
• The device sends a digitally signed registration packet containing its metadata and timestamp.
• The owner’s credentials undergo KYC verification, and upon successful verification, the DAC validates the device metadata.
• The CMC issues a digital certificate binding the public key, device identifier, and owner details.
• User, device, and environmental attributes are stored securely in Hyperledger Fabric’s CouchDB. Attributes are dynamically updated using the change feed mechanism for real-time evaluations.
• Access requests from users or devices are routed to the PEPs; the PEP queries attributes and policies.

  a.

  The PDP evaluates the request against predefined policies.

  b.

  Dynamic TSs are integrated into the decision-making process to determine access eligibility.

• The ADC dynamically evaluates the access request using attributes and policies. The decision is logged immutably on the blockchain and communicated back to the PEP for enforcement.
• Real-time behavioral data are analyzed by the trust evaluation framework. Any anomalies trigger a recalibration of the TS and adaptive policy adjustments.

The sequence of flow for the above workflow, including authentication, access requests, data logging and storage, and dynamic trust recalibration, is represented in Figure 11, Figure 12, Figure 13 and Figure 14, respectively. Each sequence diagram clearly defines the flow process for its respective transactions on the blockchain network.

8.1. High-Security Devices

For a high-security device such as a smart grid controller (SGC), the Device Attribute Controller (DAC) stores the device’s attributes, including its security level, location, and operational limits. The metadata associated with the SGC include operator IDs, operational status, and sensitivity flags. When an energy operator or authorized grid manager sends an access request via a mobile app to monitor grid settings, the PEP validates the request by retrieving the user’s attributes from the UAC, the device’s attributes from the DAC, and contextual information such as time, location, and TS. The ADC then performs a rigorous trust score check, requiring the TS to be greater than or equal to 90% for high-security devices. Simultaneously, the APC verifies an energy operator or authorized grid manager role to ensure proper authorization. To complete the process, these users must authenticate using multi-factor authentication (MFA), which involves entering a password followed by receiving a one-time passcode (OTP) on their smartphone. Once the authentication is successful, the operator is granted access to the SGC, and their TS value is increased as a reward for the successful interaction. All actions are logged immutably on the blockchain to ensure transparency and auditability. If the TS value falls below the threshold or the login attempt fails, access is denied, an alert is sent to the administrator, and the TS value is decreased accordingly. Figure 15 represents the high-security device workflow scenario in the smart home energy system.

8.2. Moderate-Security Devices

Considering noncritical devices such as smart thermostats as moderate-security devices, the DAC stores the device’s attributes, such as user role mappings, acceptable usage times, and device-specific settings (e.g., max temperature adjustments for thermostats). A house resident requests to adjust the thermostat. The PEP validates the user attributes, i.e., their role is checked against the APC—for instance, access allowed only between 7 a.m. and 10 p.m. If the request matches the policy, access is granted. Upon positive behavior, the TS is increased. If the request is outside of policy conditions, access is denied. On repeated denied attempts or attempts to exceed device thresholds, i.e., unsafe temperature limits, the TS is lowered. Figure 16 represents this scenario.

8.3. Low-Security Devices

Considering a low-security device, such as a smart light bulb, the DAC stores basic attributes like the device’s operational status, default settings (e.g., brightness and color), and access requirements. A house resident requests to turn on the light or adjust its brightness. The PEP validates the user’s attributes and ensures the request aligns with the APC, which might only require basic role verification. If the request satisfies the policy conditions, access is granted without requiring additional authentication steps, and the TS for the user is slightly increased. However, if repeated unusual activity is detected, such as attempting to access the device from an unknown location or excessive manipulation of settings, the system flags the behavior and slightly lowers the TS value. Despite the low-security categorization, all interactions are logged immutably on the blockchain to ensure traceability and accountability. The low-security device workflow scenario in the smart home environment is presented in Figure 17.

9. Performance Evaluation

The implementation and performance testing of the proposed dynamic ABAC system were conducted on an Ubuntu 20.04 LTS Operating System with 8 GB RAM, an Intel Core i7 processor, and 100 GB SSD storage to ensure efficient execution and scalability. The hybrid blockchain infrastructure utilized Hyperledger Fabric (v2.2) for managing user, device, and resource attributes and Hyperledger Besu (v22.1.3) for implementing access control decisions through smart contracts. The smart contracts for Fabric were implemented on chaincode and in Solidity for Besu. Remix IDE was used for writing, compiling, and testing Solidity smart contracts, and the Truffle suite was used for the deployment of smart contracts. The local blockchain environment for Ethereum-based components utilized Ganache, which simulated a real blockchain environment without needing to interact with an actual Ethereum network. MetaMask (Version 12.15.0), a browser extension, was used to connect the development environment (Remix) with the blockchain (Ganache). RSA was used for cryptographic operations and SHA-256 for hashing. Identity management and digital certificate issuance were handled using Hyperledger Fabric CA. The libbswabe library was employed for the implementation of Ciphertext Policy Attribute-Based Encryption (CP-ABE), while the cpabe toolkit provided command-line tools for CP-ABE encryption and decryption. Furthermore, the PBC library was used to perform bilinear pairings in cryptographic operations. Docker and Kubernetes were used for the containerized deployment of Fabric and Besu nodes. To benchmark blockchain performance in terms of latency and throughput, Hyperledger Caliper was employed. Fabric Explorer provided a GUI-based monitoring interface for Hyperledger Fabric networks. For real-time network and smart contract performance monitoring, Prometheus and Grafana were integrated. This comprehensive setup ensured that dynamic ABAC was thoroughly evaluated under real-world conditions, validating its performance, scalability, and security.

In Ethereum, gas is a small unit of cryptocurrency. The unit is deducted from the users’ accounts when performing a transaction in the Ethereum. The execution and transaction costs for dynamic ABAC operations are illustrated in Figure 18. The execution cost and transaction cost are in gas units. The execution cost represents the computational overhead for verifying user attributes, retrieving policies, and enforcing access decisions, while the transaction cost reflects the cost of storing and retrieving attributes and policies from the blockchain networks.

Figure 19 shows the gas consumption of a smart contract’s operation. There are three different functions in the smart contract that are used in the proposed work: (a) policy access, (b) the attribute storage operation, (c) dynamic trust. The gas consumption depends on the complexity of the smart contract.

For a cost evaluation and comparison, the gas price is set to 7.719 Gwei, where 1 ETH = 1 × 10⁹ (1,000,000,000) Gwei. For example, if a transaction requires 20,000 gas, then its cost will be 154,380 Gwei. Since 1 ETH is equal to 1,000,000,000 Gwei, the gas cost in ETH becomes 0.00015438 ETH. As of January 2025, the price of 1 ETH is approximately $3331.93 USD. Therefore, the total gas cost in USD is 0.514 USD. For evaluation, we compare our proposed model with existing access control models [Zhang 2018 [12], Wang 2018 [13], Zaidi 2021 [14], Hasan 2023 [15]]. The proposed model stores user attributes and details in Hyperledger Fabric and access control policies in Hyperledger Besu, ensuring efficient policy enforcement while reducing the computational overhead.

The cost efficiency of the proposed model is compared with existing access control models. This comparison is illustrated in Figure 20. The models considered for evaluation include access control systems using blockchain by Zhang 2018 [12] and Wang 2018 [13] and ABACs by Zaidi 2021 [14] and Hasan 2023 [15]. As shown in Figure 20, Zhang 2018 [12] incurs the lowest execution and transaction costs, as it does not involve complex cryptographic operations. Wang 2018 [13], Zaidi 2021 [14], and Hasan 2023 [15] exhibit moderate costs, as all attributes and policies are stored on the same blockchain, increasing storage expenses. The proposed model incurs higher transaction costs due to the hybrid blockchain approach, but this is justified by its improved security, scalability, and flexibility.

Figure 21 illustrates the comparison of Access Control Computation (ACC) time among the three models. This includes user authentication time, policy retrieval and evaluation time, and dynamic decision enforcement time. In Zhang 2018 [12], access control decisions are made rapidly since permissions are predefined. Wang 2018 [13], Zaidi 2021 [14], and Hasan 2023 [15] need more computation, as attributes and policies are not predefined and require computation. The proposed model shows a slightly higher computation time due to cross-chain communication between Fabric and Besu for dynamic policy evaluation. However, the overhead is minimal due to its optimized smart contract execution. The slight increase in computation time is an acceptable trade-off for achieving improved security, dynamic access control, and decentralized policy management for untrusted devices having a TS below the specified threshold.

Table 6. Computational complexity analysis for smart contract execution.

Operation	Blockchain Platform	Description	Complexity (Big-O Notation)
Policy Retrieval	Hyperledger Fabric	Indexed lookup for attribute verification.	O(1) (constant time)
Trust Score Recalibration	Hyperledger Fabric	Iterates through predefined metrics to update scores.	O(n) (linear time)
Access Policy Enforcement	Hyperledger Besu	Policy validation via Merkle Patricia Trie lookup.	O(log n) (logarithmic time)

and

Table 7. Computational complexity analysis for access control decisions.

Operation	Blockchain Platform	Description	Complexity (Big-O Notation)
RSA-Based Authentication	Hyperledger Fabric/Besu	Constant-time cryptographic key validation.	O (1)
Attribute-Based Policy Evaluation	Hyperledger Fabric/Besu	Single attribute check in policy.	O (1)
Multiple Attribute Conditions (ABAC)	Hyperledger Fabric/Besu	Evaluates m conditions in an ABAC policy.	O(m) (depends on attributes)
Blockchain Logging and Transaction Finalization	Hyperledger Fabric	Uses world state model for transaction recording.	O(log n) (logarithmic time)

present the Big-O complexity for key operations in the proposed hybrid model. The complexity analysis signifies the efficiency of Hyperledger Fabric for attribute retrieval (O(1)), the computational overhead of trust score recalibration (O(n)), and the logarithmic lookup time for policy enforcement in Besu (O(log n)). The access control decision-making process, including RSA authentication and ABAC policy evaluation, also follows well-defined complexity bounds, ensuring scalability and efficiency.

As the proposed model integrates cryptographic security mechanisms, blockchain immutability, and trust recalibration, it has been evaluated against various cyber threats commonly observed in IoT access control systems. The security measures help in mitigating attacks such as replay attacks, man, collusion, and Sybil attacks, Smart Contract Vulnerabilities, and data tampering.

Table 8. Security threats, their impact on access control, and proposed mitigation.

Attack Type	Impact on Access Control	Proposed Mitigation
Replay Attacks	Attackers resend intercepted access requests, bypassing authentication.	Timestamp and Nonce Mechanism: Ensures each request is unique. Immutable Logging: Fabric records prevent duplicate execution.
Man-in-the-Middle (MitM) Attacks	Unauthorized interception/modification of access requests or policies.	End-to-End Encryption: RSA for key exchange, SHA-256 for hashing. Hyperledger Fabric CA: Secure authentication of devices and users.
Collusion Attacks	Malicious users/devices share access to bypass policy enforcement.	Dynamic Trust-Based ABAC: Reduces trust scores of colluding users. Multi-Attribute Policy Enforcement: Fabric validates each access request.
Sybil Attacks	Attackers create multiple fake identities to manipulate access control decisions.	Blockchain Identity Verification: Hyperledger Fabric CA ensures unique, verifiable identities. Trust-Based Access Control: Prevents low-trust fake identities from gaining access.
Smart Contract Vulnerabilities	Exploiting bugs in smart contracts to bypass security checks.	Gas-Efficient Smart Contract Logic: Ensures strict input validation and execution constraints. Merkle Patricia Trie (MPT) in Besu: Prevents unauthorized state modifications.
Data Tampering and Unauthorized Access	Attackers modify stored attributes or policies to gain unauthorized access.	Immutable Blockchain Storage: Access policies and attributes stored in Fabric’s world state prevent tampering. Dynamic Trust Recalibration: Reduces access permissions for suspicious activity.

summarizes the key security threats and the corresponding mitigation techniques implemented in the proposed approach.

10. Discussion

The proposed model optimizes its latency and response time through a hybrid blockchain architecture. Latency is reduced as trust scores (TSs) for devices and users exceeding a predefined threshold are cached for a specified time window, preventing redundant recalculations. This approach maintains dynamic updates, while minimizing the computational overhead. Hyperledger Fabric efficiently handles attribute lookups, reducing authentication and policy enforcement delays. Meanwhile, Besu, leveraging Ethereum’s EVM, enforces policies with lower gas costs compared to public Ethereum networks.

To validate these performance improvements, the model is compared against Zhang 2018 [12], Wang 2018 [13], Zaidi 2021 [14], and Hasan 2023 [15], with results presented in Figure 22 and Figure 23. The proposed model demonstrates a superior response time and lower latency due to Fabric’s optimized data handling and Besu’s efficient policy execution.

The performance evaluation results validate that the proposed model addresses several limitations of existing access control models, as presented in Table 3. The prior approaches face limitations in computational overhead, scalability, real-time policy enforcement, and dynamic trust recalibration.

Table 9. Comparison of existing access control models with proposed approach.

Reference	Comparison with Proposed Approach
Zhang et al. [12]	Dynamic ABAC model reduces gas costs, enhances scalability, and improves access control efficiency by offloading attribute management to Hyperledger Fabric, avoiding Ethereum’s PoW overhead
Wang et al. [13]	Dynamic ABAC model employs efficient trust recalibration, automated key updates, and cross-chain policy execution, thereby enhancing scalability, flexibility, and computational efficiency
Zaidi et al. [14]	Dynamic ABAC model enhances real-time ABAC, introduces dynamic trust recalibration, and supports automated policy updates for better IoT scalability and adaptability
Hasan et al. [15]	Dynamic ABAC model ensures enhanced trust recalibration, real-time context-aware access enforcement, and hybrid blockchain scalability for smart home energy systems
Tomaz et al. [50]	Dynamic ABAC model offers lightweight authentication and cross-domain ABAC, with real-time policy updates for diverse IoT environments
Shi et al. [51]	Dynamic ABAC model optimizes computational efficiency and introduces real-time trust recalibration for adaptive policy enforcement
Sookhak et al. [52]	Dynamic ABAC model improves scalability using distributed trust recalibration and dynamic policy updates
Dhar et al. [53]	Dynamic ABAC model implements attribute-driven policies with real-time trust adjustment, enabling fine-grained ABAC and reducing reliance on fixed segmentation
Soo et al. [54]	Dynamic ABAC model ensures consistent access times using hybrid on-chain/off-chain architecture
Zhu et al. [55]	Dynamic ABAC model simplifies policy enforcement via smart contracts, supports real-time dynamic trust, and avoids overhead of cryptographic scripting by using efficient attribute-policy binding
Butun et al. [56]	Dynamic ABAC model improves efficiency with hybrid blockchain and dynamic trust recalibration
Putra et al. [57]	Dynamic ABAC model simplifies trust computation with lightweight dynamic scoring and integrates adaptive onboarding for improved performance at scale
Qi et al. [58]	Dynamic ABAC model reduces computational overhead with efficient hybrid blockchain-based policy enforcement
Iftekhar et al. [59]	Dynamic ABAC model enables real-time policy adaptation and dynamic trust recalibration to improve access control efficiency
Lyu et al. [60]	Dynamic ABAC model supports general-purpose IoT, enhances policy flexibility, and reduces verification overhead with streamlined access evaluation and trust update logic
Banerjee et al. [61]	Dynamic ABAC model introduces automated policy enforcement and real-time attribute updates
Bera et al. [62]	Dynamic ABAC model optimizes computation efficiency and enhances scalability with dynamic trust recalibration
Ma et al. [63]	Dynamic ABAC model streamlines hierarchical access via trust-based dynamic ABAC, supports faster policy updates, and minimizes multichain complexity with integrated hybrid blockchain design
Egala et al. [64]	Dynamic ABAC model enhances scalability using dynamic trust recalibration, supports real-time access policy adaptation, and reduces latency with efficient hybrid deployment
Sun et al. [65]	Dynamic ABAC model simplifies cross-domain integration with unified dynamic policy control and enhances scalability using a lightweight trust recalibration mechanism

presents the comparison of existing access control models with the proposed dynamic ABAC model.

11. Conclusions and Future Work

In this study, we propose a dynamic ABAC architecture integrating hybrid blockchain platforms to enhance the security, scalability, and efficiency of smart home energy systems. We address critical security challenges in existing access control schemes, such as centralized failure risks, rigid policy enforcement, and susceptibility to cyber threats in energy IoT devices. Our solution provides a decentralized, adaptive, and secure access control mechanism by leveraging a hybrid blockchain architecture (Hyperledger Fabric and Besu), smart contracts, and Know Your Customer (KYC) protocols.

The presented framework overcomes the shortcomings of conventional access control systems (DAC, MAC, RBAC) by allowing the advanced real-time enforcement of an energy policy, trust recalibration, and decision-making with regard to attributes of energy-sensitive appliances.

KYC-based authentication enhances user identity verification for critical energy infrastructure such as smart meters, HVAC systems, and battery storage units, preventing unauthorized access and energy misuse.

Smart contracts automate access control decisions, ensuring tamper-proof policy enforcement while reducing the administrative overhead.

In addition, the trust evaluation framework (TEF) continuously monitors user and device behavior, dynamically adjusting trust scores to detect anomalies such as unauthorized energy consumption, abnormal grid interactions, or attempted cyber intrusions.

The performance evaluation results demonstrate that the proposed hybrid blockchain-based ABAC model improves access decision accuracy, optimizes trust recalibration, and enhances system scalability for smart home energy applications.

While cross-chain communication introduces some computational overhead, the approach remains a secure and tamper-proof solution for real-world decentralized energy systems. Finally, this paper presents a novel blockchain-enhanced ABAC framework that strengthens the security and operational efficiency of smart home energy ecosystems, preventing unauthorized grid control, energy fraud, and cyber threats.

While the proposed model enhances security and privacy, it introduces some computational overhead, particularly in policy retrieval and enforcement. Our future work aims to optimize the smart contract execution and explore energy-efficient cryptographic techniques to mitigate these limitations. Additionally, since the system evaluation currently relies on simulated experiments to analyze gas costs and computation time and access control latency, future research will focus on deploying the model in a physical IoT-enabled smart home environment. This real-world implementation will provide deeper insights into practical deployment challenges, including real-time device interactions, network latency measurements, and security threat assessments under real-world conditions. Furthermore, future research will explore enhancing the system’s adaptability by integrating machine learning-based anomaly detection to dynamically adjust access control. This will improve the model’s ability to respond to evolving security threats and optimize decision-making processes in real time.