Real-Time Lightweight Cloud-Based Access Control for Wearable IoT Devices: A Zero Trust Protocol

In IoT, smart sensors enable data collection, real-time monitoring, decision-making, and automation, but their proliferation exposes them to cybersecurity threats. Zero Trust Architecture enhances IoT security by challenging conventional trust models and emphasizing continuous trust verification in the overall $875.0 billion IoT market projected by 2025. This paper presents a new Zero-Trust Real-Time Lightweight Access Control Protocol for Cloud-centric Dynamic IoT Sensor Networks. This protocol empowers data owners, referred to as sensor coordinators, to define intricate access policies, blending recipient identifiers and data-related attributes for data encryption. Additionally, the protocol incorporates efficient cryptographic primitives, eliminating the need for reliance on a trusted party. Furthermore, it ensures real-time data access while preserving data confidentiality and user privacy through seamless data upload to the cloud and the offloading of computationally intensive tasks from resource-constrained data owners and sensors. The protocol utilizes Merkle Trees for lightweight, ongoing trust measurement of sensors, ensuring efficient trust assessment by sensor coordinators. Simultaneously, the cloud conducts thorough trust evaluations for network entities including users. Comprehensive security analysis and performance evaluation highlight the protocol's effectiveness in tackling the multi-faceted security challenges of IoT ecosystems while ensuring scalability and high availability.


INTRODUCTION
Smart sensors, ranging from accessories to implants, play a crucial role in the IoT ecosystem, connecting to the Internet, collecting data, and aiding in intelligent decision-making.They seamlessly interface with smartphones and other devices, facilitating data collection and communication on the go.Leveraging advancements in low-power networks, electronics miniaturization, and sensor technology, these devices enhance efficiency, quality of life, and productivity.However, their increasing prevalence brings security challenges, as they become enticing targets for cybercriminals in both personal and industrial contexts [5], [24].
The National Institute of Standards and Technology (NIST) has introduced a Zero Trust Architecture (ZTA), which serves as an enterprise's comprehensive cybersecurity strategy, incorporating essential elements such as workflow planning, component relationships, and access policies [18].The intrinsic characteristics of IoT, including its heterogeneity, distributed nature, large-scale deployment, autonomy, dynamic behaviors, and safety considerations, position it as a highly favorable candidate for the application of these ZT principles [3].
In this context, the zero trust principle in IoT security takes center stage, emphasizing that trust should not be assumed based solely on physical or network location.IoT ecosystems, comprising billions of devices scattered across diverse locations and seamlessly integrated with cloud services, are inherently vulnerable to security threats due to their enlarged attack surface.Consequently, it becomes imperative to establish robust security protocols that transcend conventional trust paradigms, thereby fortifying the protection of these intricate networks.
In fact, three of the top 10 OWASP IoT vulnerabilities, including insecure data transfer and storage, lack of device management, and lack of physical hardening, could be effectively mitigated through the implementation of a robust and secure access control mechanism [8].However, despite the pressing need for such measures, there remains a noticeable absence of secure lightweight protocols designed specifically for IoT applications [13].This underscores the critical importance of advancing research and development in this domain to address these vulnerabilities and fortify the security of IoT ecosystems through the implementation of a ZT lightweight access control protocol tailored for IoT sensors.

Motivation
The dynamic and security demands of IoT sensor networks necessitate an agile, robust data access control protocol.In these ever-changing, often challenging environments, realtime decision-making and data protection are paramount.To meet these requirements, a lightweight and flexible access control protocol is essential, ensuring efficient resource utilization and adaptability to evolving network conditions.Implementing a Zero-Trust model adds further complexity, demanding continuous monitoring, dynamic policy enforcement, and trust verification without prior assumptions.Our paper introduces a novel Zero-Trust Real-Time Lightweight Data Access Control Protocol for Cloud-centric IoT Sensor Networks, addressing these critical challenges.

Our Contributions
Our protocol introduces the following novelties: • Zero-Trust Access Control: Our protocol establishes a zero-trust environment, where trustworthiness of entities is verified on a per-request and per-resource basis.This entails continuous monitoring and secure storage of entities trust level.• Fine-Grained Access Control: We empower data owners with the capability to define detailed access policies via fine-grained attribute-based encryption.• Lightweight Design: Our protocol utilizes computationally efficient cryptographic primitives and eliminates the need for reliance on a trusted third party.• High Availability: Our system ensures real-time data access by efficiently uploading data to the cloud and outsourcing computationally intensive tasks from resource-limited data owners to the cloud without compromising data confidentiality or users' privacy.

Overview of Proposed Scheme
In this section, we outline how our protocol achieves realtime, zero-trust access control for mobile IoT sensors.
1.3.1 Zero-Trust Access.We introduce a lightweight mechanism for sensor coordinators to manage sensors' trust scores.During initialization, sensors receive a full score based on authentication, protocol engagement, and user reports.A unique Merkle Tree is constructed, with the root hash shared as a seed trust token with the sensor.Trust scores are continuously updated during data transfer; sensors falling below a threshold lose access.We also employ dynamic trust for sensor coordinators, and users through a Trust-Level Evaluation Engine [6] deployed in cloud, ensuring alignment with NIST Zero-Trust principles [18].
1.3.2Fine Grained Access.Our protocol combines Identity-Based Broadcast Encryption with Key-Policy Attribute-Based Encryption to provide data owners, known as sensor coordinators, with enhanced control and reduced operational burden through collaboration with cloud service providers.In our approach, sensor coordinators define the access policy during data encryption.This policy combines the recipient's identifiers (e.g., roles, geo) with specific data-related attributes (e.g., vital, urgent) using the "AND" operation.This design serves a dual purpose: it safeguards user identities from the cloud while preventing the cloud from decrypting the data.The cloud's role is limited to key generation for attributes and does not involve identity-related decryption keys.

DESIGN OVERVIEW
In this section, we introduce the system model and outline the security prerequisites for public safety services, serving as a case study.

Architecture
The principal system roles integral to the proposed protocol encompass the following entities as depicted in Figure 1.
• Wearable Devices (  ): These sensors are affixed to first responders' bodies, tasked with gathering vital information.• Wearable Network Coordinator: WNC assumes the role of managing the (  s) and collecting their data.• Cloud Service Provider (CSP): Operating as an access control authority mediating between users and WNCs, the CSP is responsible for authenticating users seeking access to Wis data and trust level evaluations.• Users (  ): These individuals, often Command and Control officers geographically distributed, oversee and collaborate with first responders in real-time.

Trust model and threats
In our approach, we adhere to the "never trust, always verify" principle, which requires rigorous verification of the identity, device integrity, and security posture of all network entities, including users and devices, before granting access to resources.Following the Dolev-Yao threat model [7], an adversary possesses the capability to alter or delete the message contents transmitted over the insecure public channel.
The Cloud Service Provider operates on the "honest-butcurious" premise, authorizing users and generating private keys based on attributes while preserving the potential for data inspection.Users pose insider threats, potentially attempting unauthorized data access either independently or collaboratively.Security concerns also extend to WNC and   s due to potential compromise by adversaries, risking the introduction of falsified or malicious data into the cloud platform, endangering data integrity and authenticity.

Design Goals
Our objective is to design a scalable, real-time access control mechanism within the framework of zero trust.This protocol should effectively utilize device resources and accommodate dynamic network characteristics without compromising security.Here, we outline the main security requirements.

Zero Trust Access Control.
Our aim is to incorporate a secure access control mechanism enabling data owners (WNCs) to share information securely with users via a cloud platform.This mechanism must empower data owners to enforce fine-grained access structures, ensuring data decryption aligns with specific attribute requirements.In a zero trust environment, trust is absent between entities, requiring WNCs to monitor   s behaviors, while CSP continuously assesses the trustworthiness of both WNCs and Users.

Mutual Authentication.
A mutual authentication mechanism must be incorporated between  s and   s and also between WNCs and the CSP to fortify the system against impersonation attacks.

Data Confidentiality and Integrity.
To safeguard against data leakage and message fabrication, the protocol must employ appropriate encryption and hash algorithms to ensure data confidentiality and integrity during data transmission and at rest among the involved entities.

PROPOSED ZERO-TRUST REAL-TIME ACCESS CONTROL FOR IOT SENSORS
The proposed protocol comprises three phases as follows:

Initialization
This phase encompasses key agreement between   and   s, as well as between   and CSP.It enables   to evaluate the trustworthiness of messages from   and establish cryptographic schemes utilized in the data transfer phase.These cryptographic schemes facilitate   in managing users' static attributes through Identity-Based Broadcast Encryption and handling users' dynamic attributes via Key-Policy Attribute-Based Encryption (KP-ABE).

Key Agreement.
To establish key agreements between entities   and   s, as well as between   and , we adopt an ECDH scheme to generate pairwise MAC keys, denoted as  , and  , , following a similar approach as presented in [4].
At the conclusion of the key agreement handshake between each   s and  , a symmetric encryption key () is sent to each   s for generating a key hash chain [15] based on , which will be used to encrypt data collected by   s.Upon receiving , each   produces a key hash chain H = ℎ −1 , ℎ −2 , ..., ℎ 1 , where ℎ 0 =  and ℎ  =  (ℎ  −1 ), 1 <=  <= .Each ℎ  is utilized to encrypt vital data recorded by   .Each ℎ  has a validity period determined by  , matching the number of hash chain values for each epoch.

3.1.2
Seed Trust Token Distribution.The Wearable Network Coordinator employs an efficient real-time trust score management algorithm for   sensors.During initialization, a seed token is assigned, computed using Eq. 1.This equation combines authentication ( 1 ), activity ( 2 ), and userreported event ( 3 ) factors, with respective weights assigned by scoring factors (  ): 40% for  1 and  2 , and 20% for  3 , prioritizing objective metrics.
The WNC initializes with a score of 100 and constructs a Merkle Tree using the seed score and device ID as leaves, sharing the root (  ,0 ) with   .Subsequently, for any violated factors (  ) by   , WNC reduces the   's score until it falls below a threshold, with the maximum score set at 100.

Running KP-ABE Setup by WNC.
Step 1: WNC selects a security parameter  and an attribute set  =  1 ∪ 2 to initiate a KP-ABE setup.Here,  1 corresponds to a receiver set  of the IBBE scheme, while  2 is a set of chosen attributes by WNC for the KP-ABE scheme.The KP-ABE setup yields the public key set (PK) and master key set (MK).
WNC should then share the  and  =  1 ∪  2 sets with CSP to enable the generation of users' private keys during the registration phase.It's important to note that CSP, being a semi-honest entity, must not have the ability to Step 2: Upon receiving a message from WNC, CSP first verifies the integrity of ℎ( * ) and then proceeds to decrypt the  (, ) ( 2 ) values.CSP maintains a mapping between user IDs ( 1 ) and their respective encrypted secret keys ().

User Registration
In this phase, users register by sending their IDs to the cloud, which associates private keys with their attributes.
Step 1:    initiates the registration process by sending its ID to CSP, which is transmitted via   − ( ).ID serves as an identifier for a group of users (e.g., Command and Control officers) to maintain privacy.
Step 2: CSP initiates the validation of the request, ensuring its authenticity.If the request is verified, CSP proceeds to execute a key generation algorithm using the user's predefined access structure P (maintained by CSP), the master key (MK), and the public key set (PK).Subsequently, CSP returns   − (  ) to the user, where  encompasses the user's private key policies along with the encrypted IDbased key    .Additionally, CSP adds the user's ID to the User List, which maintains the roster of authorized users.
Step 3:    receives the message, first verifying its authenticity, and then decrypts its private key policy.To access resources, the user combines their attribute-based subtree with the user ID subtree using a logical 'AND' operation.This integration results in a combined private key set that encompasses both the user's attributes and their user ID.Please refer to delegation of private keys section in [10] for more details on access tree reconstructoin in KP-ABE protocol.

Data Transfer
This phase includes the periodic collection of encrypted data from   sensors by the Wearable Network Coordinator (WNC), with the frequency depending on the specific needs of the public safety operation (ranging from seconds to minutes).The collected data is then encrypted using a KP-ABE encryption algorithm, and the encrypted data is subsequently uploaded to the cloud platform.Users are granted access to the data based on their authorized attributes, identifiers (e.g., roles), and trust levels.The following steps outline this phase.
Step 2: WNC verifies the HMAC value of the received message and awaits data from other   sensors.This waiting period is typically about a few seconds or less, depending on the validity period of each key (ℎ  ) in the key hash chain.WNC validates and if true updates the trust score's Merkle Tree for   sensor and sends the root value to   as   ,+1 .
Step 3: WNC selects a subset of attributes  from the attribute set  and executes the KP-ABE Encryption function with  and ℎ  (used as a message).WNC then transmits the encrypted file, as illustrated in Fig 4, along with the HMAC value of the message, using the shared key , .
Step 4: The Cloud Service Provider (CSP) validates the data upload request from WNC, considering integrity and trust behavior aspects.
Step 5: When a    intends to access the data, they send their certificate   with desired attribute set  to the cloud.
Step 6: CSP verifies the received certificate and checks if the user's ID exists in the User List.If the user's ID is found and their trust level is acceptable, access to the encrypted data is granted for messages matching  ∈  ; otherwise, the user's request is disregarded.

EVALUATION
In this section, we thoroughly evaluate our proposed scheme, analyzing both computation costs and security aspects.

Computation Overhead -Initialization and User Registration Phases
Here, we provide an overview of the key computational overhead, highlighting that the overall computation cost is within acceptable limits.
ECDH Key Exchange: During this phase, wearable nodes and WNC, as well as WNC and CSP, perform an ECDH scheme to compute a shared key.
Trust Score Tree Construction: The WNC encrypts the seed of the key hash chain  using  , and simultaneously constructs a Merkle Tree for   trust scores, which includes the hash of the seed trust score and the sensor's ID as leaves.
Key Chain Generation: Each wearable node must decrypt the received message ℎ 0 =  using the key  , , and then generate a hash chain.The cost for this operation is  *   , where  represents the length of the key hash chain.The length of the key hash chain is determined by WNC based on the operational requirements.
KP-ABE Setup: WNC runs a KP-ABE setup with a chosen attribute set  and security parameter .This operation can be performed offline and does not introduce additional runtime overhead.
Share Public and Master Key Sets: WNC uploads the generated public and master key sets ( and ) to the cloud platform.WNC encrypts the master key set related to the chosen attribute set  1 with its shared key  , .Additionally, WNC generates decryption keys from the MK set related to  2 with the corresponding IBBE key.The total computational cost for this step is represented as   − +  *   − , where  refers to the cardinality of the receiver set of the IBBE scheme.
User registration request: The cloud generates user's private keys (  ) at a cost of  1 *   − , where  1 represents the cardinality of the attribute set  1 .Additionally, there is an associated cost for public key encryption by the cloud to securely transfer the user's keys.

Computation Overhead of Data Transmission Phase
The computation overhead during the data transmission phase primarily involves encryption operations carried out by wearable nodes (Wis) and WNC.Specifically: Wearable Nodes (Wis): Each wearable node computes a symmetric encryption over the sensed data, which incurs a computational cost denoted as   .
WNC: WNC performs KP-ABE encryption on received packets with a computational cost denoted as   − .Verifying the trust of a sensor requires a single hash operation on the sensor's Merkle Tree.
CSP: The cloud authorizes user data access requests by verifying whether the user's attributes satisfy the access policy on the decrypted data, alongside assessing the user's dynamic trustworthiness.This trust assessment is conducted by the Trust Level Evaluation engine [6].
The overall computation costs presented in Table 2.The detailed trust evaluation by CSP is not quantified, as it imposes negligible overhead given the available cloud resources.Definitions for terms used can be found in Table 1.The key agreement handshake between Wis and WNC, as performed in step 3.1.1,employs AES (Advanced Encryption Standard) techniques to share a base value for the key hash chain and other keys generated through a hash algorithm such as SHA-1.The secrecy of the key is contingent upon the difficulty of pre-image computation over a standard hash function.

Data Confidentiality and Integrity
. Data in our protocol is encrypted with AES, and the symmetric key is encrypted via KP-ABE, relying on the security of AES and KP-ABE for data confidentiality.Message integrity is guaranteed by HMAC values in all data exchanges.4.3.4Fine-Grained Access Control.Data encryption attributes are established using IBBE and KP-ABE.User roles, set via IBBE, are permanent, while data owners (WNC) can enforce dynamic attributes using KP-ABE.This setup enables precise access control, permitting only users with essential attributes to access specific data.

Zero Trust Access Control.
As per [3], our protocol integrates criterion-based access control with a multidimensional score-based approach for assessing entity trustworthiness.Sensor trust scores are securely stored by WNC using a Collision-Free hash function within a Merkle Tree, preventing sensors from altering their scores with received tokens.WNC reduces sensor scores in response to unauthorized messages, inactivity, or user-reported concerns.The trustworthiness of both the cloud and users is monitored through the application of the UCON+ scheme [6].

Privacy and Anonymity.
The IBBE scheme is employed to create confidential private keys for system users according to their roles, with user attributes requiring logical conjunction ('AND') for data access.This structure enhances privacy and security by effectively concealing user identities from the public cloud service provider.

RELATED WORK
In [16], best practices for addressing IoT security challenges are presented.In [3], a Zero Trust framework for IoT access control is introduced.We leverage these frameworks to review related work, with a specific focus on IoT AC and Zero Trust AC schemes, given the absence of lightweight real-time Zero Trust AC models, like our proposed scheme.
In [11], a zero-trust access control system combines ABE with zero-trust scoring for IoT in power-intensive settings.However, it relies on a static, resource-intensive AC module, making it unsuitable for sensor networks.In [2], a contextaware zero-trust access control framework is designed for healthcare IoT devices.It involves an initial and decision making stages, the former checks basic trust score and bond among resources while the latter powered by Cloud AI analysis.Yet, it's impractical for sensor networks due to non-realtime operation and high resource demands.
In [9], a lightweight mutual authentication protocol is proposed for wireless sensor networks but lacks zero trust and robust access control.In [21], an attribute-based access control method is presented for industrial IoT.While it safeguards real-time data integrity, it doesn't adhere to zero trust principles or address device mobility.Table 3 summarizes the related work in IoT AC.
Research has focused on secure access control for untrusted storage and the security challenges of integrating services with cloud computing [1,12,17,19,25].In [14], blockchain-based models have been proposed for IoT; however, their technical characteristics limit their suitability for real-time, resource-limited, dynamic networks.
In the context of fine-grained access control, [20] introduces a hybrid scheme that combines hierarchical identitybased encryption and CP-ABE for secure cloud data sharing.This approach offers efficient user revocation but raises concerns about potential access by the cloud storage to all data.

CONCLUSION
Our proposed Zero-Trust Real-Time Lightweight Access Control Protocol offers a pioneering solution to the dynamic and security challenges faced by IoT Sensor Networks.With finegrained access control, efficient cryptographic design, and a resilient Zero-Trust Access paradigm, it aligns with the stringent requirements of such networks while ensuring data availability and confidentiality.The protocol's performance and security evaluations provide concrete evidence of its practicality and significance, marking a step forward in fortifying the security landscape of IoT Sensor networks.Future work entails exploring sensor network-specific authentication models [22], investigating lightweight user attribute revocation mechanisms [23], and implementing the proposed scheme on comparable architectures such as vehicular networks.

Figure 1 :
Figure 1: Architecture of the proposed scheme

Table 2 :
Mutual Authentication.A standard Elliptic Curve Cryptography used for authentication and key agreement, with security relying on the hardness of the Elliptic Curve Discrete Logarithm Problem for mutual authentication.  +  *   2  + 2  +  − +      +   0 User registration 0 0  − +       +    +  − Overhead per protocol phase and entity 4.3.2Secrecy of Key Agreement.

Table 3 :
Comparative Analysis of Access Control (AC) Protocols: Zero Trust AC, Real-Time AC, Authentication, Fine-Grained AC, Sensor Mobility, and Lightweight Computation Support.