ID-Based Deniable Authentication Protocol with Key Agreement and Time-Bound Properties for 6G-Based WBAN Healthcare Environments

: The advent of 6G technology is expected to bring a paradigm shift in the ﬁeld of wireless communication. With its faster data transfer rates and lower latency, 6G could be an ideal solution for the challenges faced by Wireless Body Area Networks (WBANs) in terms of efﬁcient data bandwidth and edge computing. Smart healthcare systems with 6G-based WBANs might provide more efﬁcient and higher-quality healthcare services. However, 6G-based WBAN healthcare systems might face potential security and safety challenges from cybersecurity threats. This paper will propose an ID-based deniable authentication protocol with key agreement and time-bound properties for 6G-based WBAN healthcare environments by considering user privacy, secure communications, authentication, authorization, and scalability of 6G-based WBANs. As compared with previously proposed protocols, the proposed protocol will achieve the following security requirements: mutual authentication, key agreement for secure communication, deniability, time-bound access privilege control, and identity-based public key management for scalable wearable devices and 6G-based WBAN Service Providers. We proved the claimed security requirements of the proposed protocol by using AVISPA simulation and discussed its computational complexities. As compared with previous works, the proposed protocol can gain better contributions in terms of security requirements and performance evaluations for 6G-based WBAN healthcare environments.


Introduction
Wireless Body Area Networks (WBANs) comprise minisensors placed on or within the body to monitor physiological parameters such as heart rate, temperature, and blood pressure.They wirelessly relay data to nearby hubs and devices, facilitating real-time remote health monitoring and significantly improving healthcare delivery efficiency and quality while reducing treatment costs [1,2].WBANs can utilize a range of devices, including mobile phones, as gateways to gather sensor data and transmit them to a remote server for analysis [3].The emergence of 6G technology, with its superior data transfer rates and lower latency, could significantly enhance WBANs' data transmission and processing capacities.Additionally, the ability of 6G networks to support more connected devices and provide extensive coverage may enable broader remote healthcare services, reaching rural and underserved populations.

•
ID-Based public key systems: This simplifies key and certificate management and reduces the complexity to decrease the risks of bandwidth and vulnerabilities but still increases the security level.

•
Scalablility for 6G WBAN: It manages this expansion without sacrificing the quality of service, maintaining high security and performance levels even under heavy network loads.

•
Key Agreement for securing WBAN communication: It protects all entities from the risk of a third-party intercepting or compromising the key.

•
Deniability of authentication for protecting user privacy: It lets the users communicate securely without leaving any trace of their conversation, even if their messages are intercepted and decrypted by an attacker.The verifier cannot convince the third party of the authentication by releasing the communication messages.

•
Time-bound authentication service for secure access control: It allows authorized users to access specific resources within a limited time frame, ensuring that only authorized users can access the resources and reducing the risk of unauthorized access.

Paper Structures
The structure of this paper is organized as follows.We present the related works in Section 2. Section 3 will mention the technical preliminaries of our works.The system model of our work, including all entities with communicating roles as well as all the procedures and algorithms of our proposed protocol, will be presented in Section 4. Section 5 presents a security analysis of the proposed protocol including the AVISPA toolset.Finally, some concluding remarks and future works are given in Section 6, the conclusion of this paper.

Related Works
Based on Weil pairing and an elliptic curve cryptosystem, Yi [22] proposed a protocol with a group key agreement scheme to handle faults in the communication network and guarantee that all authorized participants can still communicate with each other; this protocol provides better privacy protection than traditional group key agreement protocols.However, in traditional key agreement protocols, information about the identity or affiliation of the participants might be leaked out to third parties when multiple malicious participants work together to compromise the security of the system.Xu et al. [23] proposed an authenticated asymmetric group key agreement protocol to provide secure and more efficient communication among group members while keeping their affiliations private.By combining symmetric and asymmetric encryption, the protocol achieves authentication and confidentiality and provides better performance and efficiency than traditional group key agreement protocols.Li et al. [24] introduced authenticated dynamic protocols for asymmetric group key agreement.The protocol is designed to be flexible and efficient in handling dynamic group membership, where members can join or leave the group at any time.
Wu et al. [25] and Choi et al. [26] presented a revocable ID-based authenticated group key exchange protocol to address some security concerns related to group key exchange by using the bilinear pairing technique to achieve a secure group key agreement with resistance to malicious participants by providing better security than traditional group key agreement protocols that do not consider revocation or resistance to malicious participants.The protocol is built on a modified version of the Boneh-Franklin identity-based encryption system, providing better efficiency and scalability than traditional group key agreement protocols that use traditional public key cryptography.
Zhang et el.[27] proposed a round-efficient and sender-unrestricted dynamic group key agreement protocol for secure group communications.This protocol provides better efficiency and security than traditional group key agreement protocols, especially in largescale dynamic group scenarios.Overall, these articles show improvements in various aspects of group key agreement protocols, such as privacy protection, dynamic group handling, security against malicious participants, efficiency, and scalability.However, none of these articles specifically address the challenges and requirements of using a robust network to store and transfer a great amount of data without corruption.Moreover, these protocols also could perform well in controlling the authentication and authorization of the users by time slots, as well as keeping the privacy of their identities.
Given the drawbacks of all the above works, I am motivated to propose a new protocol to address the security and privacy concerns in 6G-based WBAN healthcare environments.

Technical Preliminaries
We discuss some important technical preliminaries including Elliptic Curve Cryptography (ECC), Bilinear pairing, one-way hash function, and computational Diffie-Hellman problem (CDHP), time-bound, and security assumptions which are used in our proposed protocol.

Elliptic Curve Cryptography (ECC)
Elliptic Curve Cryptography (ECC) is a method for implementing public key cryptography that utilizes the algebraic structure of the elliptic curve over finite fields.It was first introduced by Neal Koblitz [28] and Victor Miller [29].Compared to other public key cryptosystems, ECC has a smaller key size, as reported in [30].For instance, ECC can provide the same level of security strength with a 256-bit key size, while the Rivest-Shamir-Adleman cryptosystem (RSA) requires a 2048-bit key size.This makes ECC more advantageous in terms of performance, transmitted bandwidth, and storage space than RSA.Furthermore, ECC is included in modern cryptosystem applications according to international standards such as IEEE 1363-2000 [31] and ISO/IEC 11770-3 [32].
The equation of ECC can be defined as E: y 2 = x 3 + ax + b(modp) over a finite field F p , where a, b ∈ Z q .Therefore, a non-super-singular curve can be represented as 4a 3 + 27b 2 = 0.As a result, there are some properties of ECC from the definition above.

•
A specific point O is on an elliptic curve, E; nonetheless, the point O is not on the elliptic curve, E. The point O is an additive identity that is regarded as the point of infinity or a zero point.

•
There is a point P with coordinates (x, y) on the elliptic curve, E. The point P is reflected across the x-axis and mapped onto a point, −P (negative P).Hence, the coordinates of the point, −P, are (x, −y).

•
While q is the prime order of the point, P, the qP = O, and q is an integer.

•
In the finite field F q , all of the points on the elliptic curve E are called E(F q ).

Bilinear Pairing [33]
Suppose that a cyclic additive group G 1 is generated by P, where ∀P ∈ E F q .Besides, another cyclic multiplicative group G 2 has the same order q.We assume that c and d are the elements of Z q .Furthermore, Weil pairing is a category of bilinear mapping which is a map of ê: with the following characteristics [22,34].
3.3.Brief Review of Time-Bound Method of Chien's Group-Oriented Range-Bound Key Agreement Protocol [18] In 2018, Chien [18] proposed a group-oriented range-bound key agreement for an Internet of Things scenarios scheme.Chien considered time-bound security requirements for Internet of Things (IoT).The concept of time-bound is that a client can only access the resources from a server in a valid period, which is determined by the server.To explicitly form the concept above into practice, we illustrated it with a mathematical example.A parameter z determines the maximum number of time slots in a specified time zone.The specified time zone could be a day, a month, or even a year.The users send a service request to the server within the authorized time slot, which is determined by two authorized time slots: T1-the beginning, and T2-the ending.The server grants access to the client only if the client accesses the service within the authorized period.If the client accesses the service outside of the authorized time slot, the authentication token will include a negative hash time, which will cause the server to abort the service request.This authentication mechanism is based on one-way hash function properties, and it provides a secure and efficient way to authenticate clients while protecting against unauthorized access.

Security Assumptions
Security assumptions in our protocol are defined as follows.
3.4.1.Computational Diffie-Hellman Problem (CDHP) [34] Suppose that G 1 and G 2 are from the cyclic group G of order q with a large prime p.Therefore, a bilinear map ê: G 1 ×G 1 →G 2 , where G 1 is considered to be hard computationally.The CDHP is extremely difficult to solve abP in G 1 , which is proven by Joux and Nguyen [25,26], even though a random set < P, aP, bP > is provided.
3.4.2.Decisional Diffie-Hellman Problem (DDHP) [34,35] The DDHP involves distinguishing between two values, g xy and, g z , where z is a randomly chosen integer.The DDHP is also believed to be a hard problem, but it is generally considered to be somewhat easier than the CDHP.
3.4.3.One-Way Hash Function (OWHF) [36] Considering a function, h: x → y, where x and y are not mapped, as a hash function, for instance, y = h(x).Whenever the length of the input, x, is the output, y, it can be a fixed-length arbitrary string.However, it is hardly feasible to retrieve from y to x, which is known as h: x → y is nearly nonviable.

Time-Bound Method of Chien's Protocol [19]
Chien's protocol [19] uses two secure hash functions to acheive a time-bound security requirement.The system can randomly select two integers as x s and x e in GF(p), where p is a large prime.For a time-bound service between time periods t 1 and t 2 , the system should determine and issue two secret keys, K 1 and K 2 , for the user with the time-bound service access priviledge, where is the starting time slot, t 2 is the ending time slot, z is the total time slot, H is a secure one-way hash function, and the symbol H t (x s ) is denoted as t times hashing for the seed x s .For securely broad- casting a message M in t time slot, the system can first derive an encryption secret key as K = H H t−1 (x s ) H 24−t (x e ) and broadcast the ciphertext C = E K (M), where E K (M) denotes encryption of M over a secret key K. Upon receiving the broadcasting ciphertext C, the user with valid access privilege in t time slot can obtain the message M by performing the following tasks: Step 1: The user computes Step 2: The user computes Step 3: The user computes K as Step 4: The user uses K to decrypt the ciphertext C to obtain the message M.
If a user cannot derive the valid secret key K for the t time slot with their two secret keys, K 1 and K 2 , they cannot obtain the message M. Hence, the time-bound security requirement can be achieved.

Problem Statement
While various protocols have significantly improved group key agreement aspects such as privacy, dynamic group handling, resistance to malicious participants, and scalability, there are still gaps in the system that need to be addressed.For instance, Yi's protocol [22] offers better privacy protection, Xu et al.'s [23] enhances communication efficiency, and Li et al.'s [24] provides flexibility in dynamic group membership changes.Furthermore, Wu et al.'s [25] and Choi et al.'s [26] protocols present effective methods for addressing security concerns related to group key exchange, offering enhanced resistance to malicious activities.Zhang et al.'s [27] protocol optimizes efficiency in large-scale dynamic groups.

System Model
Figure 1 depicts our proposed system model.In our system model, there are three main roles: the Cloud Service Provider (CSP), the devices, and the Service Provider (SP).The Cloud Service Provider (CSP) serves as a trusted third party, responsible for managing both public and private parameters.The private parameters, held exclusively by the CSP, are central to its secure functioning.Devices, on the other hand, represent the users in a Wireless Body Area Network (WBAN) and are registered to the CSP.They, along with the Service Provider (SP), act as participants that authenticate each other to initiate communication sessions.The SP can represent various entities such as hospitals, emergency institutions, families, tele-medicare companies, etc.Like devices, the SP also needs to register with the CSP and authenticate its identity with registered devices.For an SP to provide healthcare services to users via registered devices, both parties need to authenticate each other and establish a shared secret key for secure communication.To ensure user privacy and restricted authorization, our proposed protocol meets the deniability and timebound security requirements.Hence, an ID-based deniable authentication protocol with key agreement and time-bound properties for 6G-based WBAN healthcare environments should be achieved by fulfilling the following security features:

•
Simplified key and certificate management, reducing complexity and increasing security.

•
Scalability for 6G WBAN without compromising quality of service.

•
Key agreement for secure WBAN communication, protecting against interception.

•
Deniability of authentication, ensuring user privacy and non-repudiation.

•
Time-bound authentication service for secure access control.

•
Improved efficiency with lower computational overheads compared to existing protocols.
deniability and time-bound security requirements.Hence, an ID-based deniable authentication protocol with key agreement and time-bound properties for 6G-based WBAN healthcare environments should be achieved by fulfilling the following security features: Improved efficiency with lower computational overheads compared to existing protocols.

Proposed Protocol
The purpose of the proposed scheme is to establish a robust and secure framework for communications, particularly within healthcare settings.The proposed protocol's security features will focus on secure key management, mutual authentication, deniable security, and time-bound access control; this scheme seeks to address the prevalent security concerns.In any secure communication protocol, the security of the private key is crucial; it must be safeguarded from unauthorized access and remain solely in the hands of the rightful owner.Mutual authentication bolsters this security further by ensuring that both parties involved in a conversation verify each other's identities, thereby avoiding interactions with imposters.Key confirmation then plays its role by validating that the shared secret key, crucial for secure communication, is correctly established by all involved parties.The addition of undeniable security into the mix ensures a robust proof of authenticity, preventing a signer from falsely denying their participation in the message exchange.Lastly, the principle of forward security secures past session keys, ensuring that even in the event of a key compromise, the confidentiality of past communications remains intact.
The proposed protocol consists of three phases: system setup, key generation, and identity authentication phases.In the system phase, we will use the Setup algorithm to generate the public and secret parameters used in the whole proposed protocol; the Cloud Service Provider, or CSP, is also responsible for carrying out this task.In the key generation phase, we will use the Keygen algorithm to generate public and private keys

Proposed Protocol
The purpose of the proposed scheme is to establish a robust and secure framework for communications, particularly within healthcare settings.The proposed protocol's security features will focus on secure key management, mutual authentication, deniable security, and time-bound access control; this scheme seeks to address the prevalent security concerns.In any secure communication protocol, the security of the private key is crucial; it must be safeguarded from unauthorized access and remain solely in the hands of the rightful owner.Mutual authentication bolsters this security further by ensuring that both parties involved in a conversation verify each other's identities, thereby avoiding interactions with imposters.Key confirmation then plays its role by validating that the shared secret key, crucial for secure communication, is correctly established by all involved parties.The addition of undeniable security into the mix ensures a robust proof of authenticity, preventing a signer from falsely denying their participation in the message exchange.Lastly, the principle of forward security secures past session keys, ensuring that even in the event of a key compromise, the confidentiality of past communications remains intact.
The proposed protocol consists of three phases: system setup, key generation, and identity authentication phases.In the system phase, we will use the Setup algorithm to generate the public and secret parameters used in the whole proposed protocol; the Cloud Service Provider, or CSP, is also responsible for carrying out this task.In the key generation phase, we will use the Keygen algorithm to generate public and private keys for Service Providers and devices.Lastly, in the authentication phase, the devices and the SP will use the AuthID algorithm to authenticate each other and compose a shared key for further communication.Table 1 describes notations and cryptographic functions used in the protocol.The detailed scheme is presented in the three phases as follows.
In the setup phase, the CSP will use the Setup algorithm to select a large prime q and choose an elliptic curve function It then generates two cyclic groups G 1 and G 2 from the prime order q and the bilinear pairings ê: Then, the CSP chooses a point P from the G 1 with order q.It will take a random number s ∈ Z q as the system private key and calculate as the system public key and choose three one-way hash functions, namely, H 2 , H 3 , and h, in which H 2 : {0, 1} → Z q and H 3 : {0, 1} → G 1 .It is noted that H t 2 (x) denotes x times hashing for the seed x.It is also noted that date denotes access date.
The public key of the entity x, where x = {i, j}.

S x DS, SPS
The private key of the entity x, where x = {i, j}.

MAC x MACI, MACJ
The authentication code for entity x, where x = {i, j}.

Pub_parameter
The public parameter of the system.

Priv_parameter
The private parameter of the system.
The generators are based on the cyclic additive group, which is generated by P. P P A point from the generator with a prime.
The system secret value.
The one-way hash algorithm.AT a,i , AT b,i ATA, ATB Two secret tokens which are generated by CSP and published to the Service Provider.
Note: HLPSL is the abbreviation of High-Level Protocol Specification Language for security proof.
CSP can apply a symmetric cryptosystem, for example, RSA to encrypt the message m with key k; on the contrary, D k (m) is used for decrypting the message with key k.Finally, the CSP publishes Pub_params = G 1 , G 2 , P, q, H 2 (), H 3 (), P pub , E k (m) and pre- serves Priv_params = s as a system secret.The specific steps of this phase are described in Algorithm 1.
In the key generation phase, the device, D i , and the Service Provider, SP j , are involved in obtaining their public and private key as registration.The private keys of the device and the Service Provider are generated by the CSP while they provide their identity to the CSP via a secure channel.Due to the input in this phase being the device's identifier D i and the Service Provider's identifier SP j the output will be the public and private keys of the device, D i , and the Service Provider, SP j .Algorithm 2 will depict the specific steps of this phase.
During the authentication phase, the device D i and the Service Provider SP j will authenticate each other through the AuthID algorithm and compose a shared key for further communication.The authentication procedure is provided in Algorithm 3, as follows (Figure 3).Output: The public parameters Pub_params = G 1 , G 2 , P, q, H 2 (), H 3 (), P pub , E k (m) and the private parameters Priv_params = s.Algorithm: (1) Select a large prime q, and choose an elliptic curve function y 2 = x 3 + ax + bmodq = 0, which must meet 4a 2 + 27b 3 modq = 0, where x, y ∈ Z q and a, b ∈ Z q .
(2) Generate two cyclic groups G 1 and G 2 and the bilinear pairings ê : (3) Choose a point P from the G 1 .
(4) Take a random number s ∈ Z * q as the system private key and calculate P pub = sP as the system public key.
(6) Determine a symmetric algorithm E, such as encryption standards DES and AES, where E k (m) and D k (m) are denoted as the encryption and decryption of the message m over the secret key k, respectively. (7)Publish Pub_params = G 1 , G 2 , P, q, H 2 (), H 3 (), P pub , E k (m) , and preserve Priv_params = s.

Input:
The identity ID i of D i and the identity ID j of Service Provider SP j Output : The private key S i of the device D i and the private key S i of the Service Provider SP j Algorithm: (1) The Cloud Service Provider CSP sends a request for ID x s for device D i and service provider SP j , where x = i and j.That implies that ID i stands for device i (i.e., x = i) and ID j stands for Service Provider j (i.e., x = j).As in Figure 2, it is noted that ID x stands for the ID of both Device/Service Provider, where x = {i, j}.
(2) The device D i provides the ID i to the CSP.
(3) The Service Provider SP j submits the identity ID j to the CSP.
(4) Conduct (5) Calculate the device's and Service Provider's private keys as (6) Transmit S i to the device, and send S j back to the Service Provider, SP j , via the secure channel.

Algorithm 3: AuthID
(1) forward the parameter, (t 1 , t 2 ), Seed a,i and Seed b,i and the identity ID j of the Service Provider SP j to the device D i .
(2) The device D i generates a random number θ and keeps the value in private with the following steps: (3) The device encrypts its identity with a symmetric key v i and calculates the authentication token, Seed a,i and Seed b,i , which have been registered to the CSP.The element of the authentication token is composed of the public key (Q i ), the identity (ID i ), the access date (date), the subscription starting time (t 1 ), and the subscription ending time (t 2 ) of the device, D i .Besides, the public key Q j of the Service Provider, SP j , performs the following equations: (4) Forward the parameter, (t 1 , t 2 ), Seed a,i and Seed b,i , and the identity ID j of the Service Provider SP j to the device D i .
(5) The device D i generates a random number θ and keeps the value in private with the following steps: The device encrypts its identity with a symmetric key v i and calculates the authentication token, Seed a,i and Seed b,i , which have been registered to the CSP.The element of the authentication token is composed of the public key (Q i ), the identity (ID i ), the access date (date), the subscription starting time (t 1 ), and the subscription ending time (t 2 ) of the device, D i .Besides, the public key Q j of the Service Provider, SP j , performs the following equations: ) (7) The device D i applies the hash function H 2 () to calculate a message authentication code MAC i .Therefore, the message authentication code MAC i includes a parameter a, the symmetric key v i , the encrypted message C, the identity of the device ID i , and two authentication tokens Seed a,i and Seed b,i , where (8) The device D i sends the message (B, MAC i , C) to the Service Provider SP j .
(9) Due to the Service Provider SP j obtaining a message (B, MAC i , C), it forms the device D i .Hence, the Service Provider SP j will compute the following equations: (10) The Service Provider SP j applies the hash function, H 2 () to exam the integrity of the message authentication code MAC i .The Service Provider SP j computes MAC i as: If MAC i equals to MAC i , it implies that the integrity of the message authentication code MAC i is valid.Otherwise, the request from the device D i will be dropped, and the Algorithm will be terminated.(11) The Service Provider SP j chooses a random number λ and computes the symmetric key v j , a shared key K i,j , and MAC j , where (12) The Service Provider SP j transmits another set of parameters (v j , MAC j ) to the device D i , which launches the service request.
(13) The device D i contributes the shared key with its θ through the following equation: (14) As soon as the shared key K i,j has been built by the device D i , the device D i will combine K i,j , v j , v i , MAC i , and ID j with the hash function H 2 () as the message authentication code MAC j .The device D i checks the message authentication code MAC j by computing MAC j as If MAC j equals to MAC j , it implies that the integrity of the message authentication code MAC j is valid.Otherwise, the request from the service provider SP j will be dropped and the algorithm will be terminated.

Algorithm:
(1) The Cloud Service Provider CSP sends a request for   's for device   and ser provider   , where x = i and j.That implies that   stands for device i (i.e., x and   stands for Service Provider j (i.e., x = j).As in Figure 2, it is noted that stands for the ID of both Device/Service Provider, where  = ,  .(2) The device   provides the   to the CSP.
(3) The Service Provider   submits the identity   to the CSP.During the authentication phase, the device  and the Service Provider  w authenticate each other through the AuthID algorithm and compose a shared key further communication.The authentication procedure is provided in Algorithm 3, follows (Figure 3).

Security Analysis
To evaluate the security of the proposed scheme, various security properties are examined in this section, including security proof of the private key security, mutual authentication, key confirmation, undeniable security, forward security, and an analysis of security using AVISPA.

Security Analysis
To evaluate the security of the proposed scheme, various security properties are examined in this section, including security proof of the private key security, mutual authentication, key confirmation, undeniable security, forward security, and an analysis of security using AVISPA.

Security of Private Keys
The private key of a device D i cannot be self-generated, as it is provided by the CSP.However, a malicious device D Ω generates its private key using the public parameter H 3 () and its identity ID Ω .Even though the malicious device uses its secret s to create the private key S Ω , the system's private key s remains secret.However, the illegal private key S Ω cannot be used for mutual authentication, and the Service Provider will reject requests from the malicious device due to the computational difficulty of the ECDLP that protects the security of the private key as the following equations:

Mutual Authentication
To gain access to the Service Provider as a regular device, a malicious device must satisfy the condition ID σ = D v σ (C) and falsify the message (B, MAC i , C) by computing v σ = ê P pub + S j , B .However, since the message authentication code generated by the malicious device does not contain the system secret s from the KeyGen phase, it will fail to obtain the shared key K σ,j .Similarly, if a malicious Service Provider tries to communicate with legal devices by impersonating as a legitimate Service Provider, it can falsify the message (v σ , MAC σ , ID σ ).However, it cannot pass the validation check for the message authentication code MAC j , because it does not have the correct value of parameter "a" containing the secret s from the key generation phase.The legal device will therefore reject the session with the malicious Service Provider.

Key Confirmation
Assuming that the malicious device D Ω is trying to convert the message (B, MAC i , C, v i , MAC j , t 1 , t 2 ) to extract the shared key K i,j among the device D i and the Service Provider SP j , the malicious device D Ω may compose the secret key as below.
If a malicious device D Ω wants to obtain the shared key K i,j between device D i and Service Provider SP j by modifying the message (B, MAC i , C, v i , MAC j , t 1 , t 2 ), it can create a secret key using the following equation: It is important to note that the malicious device D Ω cannot obtain θ or λ, as they are generated by the legitimate device and Service Provider, respectively.Therefore, D Ω cannot generate a falsified shared key K Ω,j ∨ K i,Ω to participate in a legitimate session and deceive the legitimate device or Service Provider.

Deniability
Once the device D i and the Service Provider SP j have each generated their own shared key, they can decrypt messages that have been encrypted using that key.This ensures that both parties can verify the authenticity of the message.However, SP j cannot determine the identity of the device D i , as it is not included in the encrypted message.

Forward Security
The shared key K i,j is computed by the Service Provider SP j and the device D i , because they select different random numbers from time to time.The possibility of computing the same shared key in two separate conferences is low.The shared key K i,j is generated by both the Service Provider SP j and the device D i by selecting different random numbers each time.The likelihood of computing the same shared key in two separate sessions is minimal.

A Formal Security Verification Using AVISPA
We will utilize AVISPA to analyze our protocol and present the simulation results and HLPSL script details in this section.The protocol involves three roles: the device, the Service Provider, and the cloud Service Provider.However, AVISPA does not support the Weil pairing method, so we substituted it with a hash function, which is a common approach in related research.Additionally, the current AVISPA version does not include the elliptic curve key initialization phase, so we defined the public key, private key, and session key beforehand as PUBLICP, inv(PUBLICP), and SK, respectively.
The environment role defines the protocol's design goals, including secrecy of DS, SPS, and KIJ, and authentication of the Service Provider and device using MACI and MACJ.The protocol involves five roles: CSP as the Cloud Service Provider, SP as the Service Provider, D as the device, the session overseeing all communication channels, and the environment testing for attacks within an insecure channel, covering variables, procedures, roles, session, and multiple security goals.Encrypted messages using symmetric keys, such as SKcspd, between CSP and D are considered secure, and symmetric keys, such as SKcspd, are inaccessible to attackers.Finally, a brief profile of the HLSPL script for all roles will be provided.
Figure 4 presents the HLPSL specification of a Cloud Service Provider, which is played by the CSP.Initially, the CSP has knowledge of all the agents (D, SP, CSP), symmetric keys for secure communication (SKcspd, SKcspsp, SKspd), a predefined hash function (H, H2, H3, MUL), a public key generated by a predefined elliptic curve algorithm (PUBLICP), and a send/receive channel under the Dolev-Yao model (noted with dy) (SND, RCV).The keyword "played_by CSP" indicates that this is the role of the Cloud Service Provider.After the keyword "def=", the scripting of the CSP's steps and procedures starts in detail.The keyword "local" indicates that all local variables should be declared in this section, including a variable "State" declared as a natural number of data types.
The following sets of variables are separated by commas (,) with specified data types, including a set of variables with a message data type declared as "text".The keyword "init State:= 1" initializes the local variables, and the "State" starts at step 1.The "transition" keyword marks the beginning of how the protocol executes and behaves.In State 1, the key generation phase between the CSP and D is initiated within a secure channel using the symmetric key SKcspd.After the CSP receives the identity of D with a symmetric key, the state switches to 3, and the CSP calculates the public key of D, UPPERQ.Then, the CSP applies its secret to register the device and sends the public key UPPERQ and private key DS back to D with a symmetric key.
The same procedure is conducted between the Service Provider and the CSP, with variables for the identity of the Service Provider, IDSP, the symmetric key, SKcspsp, the public key, UPPERSP, and private key, SPS.After the key generation phase, the CSP will receive a service request from the device for a time-bound delegation in State 5 and will perform the time-bound delegation for the device when the state approaches 7.In step 7, the CSP will assign T1, T2, and DATE within the authorized period, generate two authentication seeds, SEEDA and SEEDB, from the public key of the device, the identity of the device, and the public key of the Service Provider, and produce two authentication tokens, ATA and ATB, respectively.Finally, the CSP sends T1, T2, ATA, ATB, SEEDA, and SEEDB to the device.The notation "end role" indicates the completion of the CSP's role.Some variables are marked with a prime (') when the CSP assigns a new value to the variables.The ": =" stands for being defined as, and the following string "new()" After declaring the local variables and essential keywords, we present the script's workflow.The device sends the "RCV(start)" keyword to initialize the script, and then sends its identity (IDD) to CSP via the secure channel using SKcspsp.The device receives a private key (DS) from CSP through the secure channel protected by SKcspsp.The device then sends a service request (SERVICEREQUEST) to CSP and receives authorized seeds, subscription starting and ending times, and the Service Provider's identity (IDSP) in State 4.
In State 6, the device performs authentication using the received parameters within a valid time slot.The device and Service Provider generate their public keys from their identities.After authentication, the device issues a number (B) multiplied with ALPHA from bilinear pairing, a message authentication code (MACI), and a cipher containing the device's identity (CIPHER) to the Service Provider.
The first authentication process is successfully completed at the Service Provider, resulting in the message containing a parameter (VJ) and another message authentication (MACJ), which is transmitted to the device.In State 7, the shared key (KIJ) and another round of authentication are constructed on the device.Two authentication procedures to validate for AVISPA are specified in State 8.The first is a request to determine whether the message authentication code (MACI) is valid, and the second is an event when the device calculates the message authentication code (MACJ) and wants to check it with the Service Provider.
The "exp" keyword denotes a mathematical exponent computation, and the "PREP" keyword is defined as a hash function for addition computation, since AVISPA's built-in function does not support it.The "BILINEARPAIR" keyword refers to the Weil pairing, which is also a hash function.Finally, the "end role" keyword is necessary to complete the device's role actions.
To summarize the role of the Service Provider, we present a brief description and provide the HLPSL script for it in Figure 6.The initial part of the script remains the same as that for the device, with symmetric keys, hash functions, public key, and communication channels unchanged.The Service Provider is denoted as SP in the script, and local variables and keywords are similar to those used in the device script.However, the Service Provider script differs in the identity of the Service Provider, IDSP, the symmetric key for secure communication between the Service Provider and the CSP, SKcspsp, the public key, UPPERQSP, and the private key, SPS.
The key generation phase is similar to that in the device script, but with these new values.After generating the keys, the Service Provider receives a message which is from state 0 to 4, (T1'.T2'.ATA'.ATB'.SEEDA'.SEEDB') from the CSP and keeps ATA and ATB, forwarding T1, T2, and IDSP to the device.Next, the Service Provider receives a message from the device and performs an authentication phase to authenticate and grant the device the subscribed services.Keywords such as "PREP," "BILINEARPAIR," and "exp" are used in the script, as in the device script.However, a new shared key, KIJ, is generated by the Service Provider and kept secret between the Service Provider and the device.The script ensures the secrecy of KIJ using the keyword "secret" and identifier "sp_d_key" for AVISPA auditing.The Service Provider also verifies the validity of the shared key using the message authentication code, MACJ.Finally, the script includes the string "request (SP, D, device_serviceprovider_macj, MACJ)" and the keyword "end role" to conclude the activities.
Figure 7 illustrates the role of the session, which involves the device, Service Provider, and CSP.The starting parts of the script are the same as in the device role, including the symmetric keys (SKcspd, SKcspsp, SKspd), (H, H2, H3, MUL), the public key (PUBLICP), and communication channels (SND, RCV).However, after the "def=" keyword, the communication channels for each agent are declared as local variables, and each agent is assigned to send and receive channels.To compose the session and communicate across different channels, the keyword "composition" is used to instruct AVISPA on how the session is constructed.The session is built up with the CSP, device, and Service Provider, with the same header information as in the agent roles, including symmetric keys, hash functions, each agent is assigned to send and receive channels.To compose the session and communicate across different channels, the keyword "composition" is used to instruct AVISPA on how the session is constructed.The session is built up with the CSP, device, and Service Provider, with the same header information as in the agent roles, including symmetric keys, hash functions, public key, and communication channels.Once the communication channels (SD, RD, SSP, RSP, SCSP, RCSP) are assigned to their respective agents, the session is complete.Finally, the script concludes with the "end role" keyword to ensure proper operation.In Figure 8, different from the previous script of the roles in the parentheses, in other words (), the header of the environment is empty parentheses.All variables are declared and instantiated using the "const" keyword.The agents, D, SP, and CSP, are instantiated as d, sp, and csp, respectively.Symmetric keys, skcspd, skcspsp, and skspd, are also instantiated, representing SKcspd, SKcspsp, and SKspd.However, a new symmetric key, ski, is introduced as an instance that an intruder can use.The hash function is instantiated as h, h2, h3, and mul, representing H, H2, H3, and MUL, respectively.Two public keys based on the elliptic curve cryptosystem are instantiated as publicp, representing PUBLICKP, and publicpi, which is built for the intruder.The "protocol_id" keyword declares the identifiers mentioned earlier for the goal section.The "intruder_knowledge" keyword is used to define the knowledge that the intruder possesses, including all agents, public keys (including the intruder's public key), and hash functions.The "inv()" keyword is used to invert a key, allowing AVISPA to convert a given public key to a private key.Each session is composed of a "session" keyword and all the instances.These sessions simulate possible attacks on the protocol under the symmetric key, ski.The goal section is critical for AVISPA to validate the safety of the protocol SAFE or UNSAFE.The "secrecy_of" keyword is used to indicate that the identifiers and related instances are intended to keep secrets, such as ds, sps, and sp_d_key.The "authentication_on" keyword is used when agents request In Figure 8, different from the previous script of the roles in the parentheses, in other words (), the header of the environment is empty parentheses.All variables are declared and instantiated using the "const" keyword.The agents, D, SP, and CSP, are instantiated as d, sp, and csp, respectively.Symmetric keys, skcspd, skcspsp, and skspd, are also instantiated, representing SKcspd, SKcspsp, and SKspd.However, a new symmetric key, ski, is introduced as an instance that an intruder can use.The hash function is instantiated as h, h2, h3, and mul, representing H, H2, H3, and MUL, respectively.Two public keys based on the elliptic curve cryptosystem are instantiated as publicp, representing PUBLICKP, and publicpi, which is built for the intruder.The "protocol_id" keyword declares the identifiers mentioned earlier for the goal section.The "intruder_knowledge" keyword is used to define the knowledge that the intruder possesses, including all agents, public keys (including the intruder's public key), and hash functions.The "inv()" keyword is used to invert a key, allowing AVISPA to convert a given public key to a private key.Each session is composed of a "session" keyword and all the instances.These sessions simulate possible attacks on the protocol under the symmetric key, ski.The goal section is critical for AVISPA to validate the safety of the protocol SAFE or UNSAFE.The "secrecy_of " keyword is used to indicate that the identifiers and related instances are intended to keep secrets, such as ds, sps, and sp_d_key.The "authentication_on" keyword is used when agents request authentication, such as device_serviceprovider_maci, device_serviceprovider_macj, csp_d_ds, csp_sp_sps.We examine and test our suggested protocol using the OFMC and CL-AtSe back-end checkers.The OFMC report, presented in Figure 9, confirms that our protocol is secure and meets all the security goals we designed.We also use the CL-AtSe back-end checker to validate our protocol, and Figure 10 shows the results, indicating that our protocol is % environment role environment() def= const d, sp, csp: agent, skcspd, skcspsp, skspd, ski: symmetric_key, h, h2, h3, mul: hash_func, publicp, publicpi: public_key, ds, sps, cipher, sp_d_key, csp_d_ds, csp_sp_sps, newkey_d, newkey_sp, device_serviceprovider_maci, device_serviceprovider_macj: protocol_id intruder_knowledge = {d, sp, csp, publicp, publicpi, inv(publicpi), h, h2, h3,mul} composition session(d, sp, csp, skcspd, skcspsp, skcspd, publicp, h, h2, h3, mul) /\ session(d, i, csp, ski, ski, ski, publicp, h, h2, h3, mul) /\ session(i, sp, csp, ski, ski, ski, publicp, h, h2, h3, mul) /\ session(d, sp, i, ski, ski, ski, publicp, h, h2, h3, mul) end role % set goal goal secrecy_of ds, sps, sp_d_key, newkey_d, newkey_sp authentication_on device_serviceprovider_maci, device_serviceprovider_macj, csp_d_ds, csp_sp_sps end goal environment() Figure 8.The HLPSL script for the role of environment.
We examine and test our suggested protocol using the OFMC and CL-AtSe back-end checkers.The OFMC report, presented in Figure 9, confirms that our protocol is secure and meets all the security goals we designed.We also use the CL-AtSe back-end checker to validate our protocol, and Figure 10 shows the results, indicating that our protocol is secure and satisfies the security goals.To provide a reference, we include execution snapshots in Figures 11 and 12.We examine and test our suggested protocol using the OFMC and CL-AtSe back-end checkers.The OFMC report, presented in Figure 9, confirms that our protocol is secure and meets all the security goals we designed.We also use the CL-AtSe back-end checker to validate our protocol, and Figure 10 shows the results, indicating that our protocol is secure and satisfies the security goals.To provide a reference, we include execution snapshots in Figures 11 and 12   Several recent studies have highlighted the potential benefits of 6G in healthcare, including improved communication speed and capacity [37] and enhanced quality of life for patients through telecare services [38].In 2023, Suraci et al. [39] pointed out several security risks of deploying 6G in a healthcare environment such as impersonate risk or data breached risk.To eliminate these risks, we can use mutual authentication.Hence, providing an ID-based mutual authentication feature is considered crucial in 6G healthcare environments, because it will ensure that both users and devices are verified and authenticated each other to protect patients' safety, sensitive information, and prevent unauthorized access.Hence, only legitimate and authorized entities can interact with the healthcare system.After performing authentication protocol, only the system can accomplish other cryptography to achieve the confidentiality, integrity, and availability for healthcare service and information.Several recent studies have highlighted the potential benefits of 6G in healthcare, including improved communication speed and capacity [37] and enhanced quality of life for patients through telecare services [38].In 2023, Suraci et al. [39] pointed out several security risks of deploying 6G in a healthcare environment such as impersonate risk or data breached risk.To eliminate these risks, we can use mutual authentication.Hence, providing an ID-based mutual authentication feature is considered crucial in 6G healthcare environments, because it will ensure that both users and devices are verified and authenticated each other to protect patients' safety, sensitive information, and prevent unauthorized access.Hence, only legitimate and authorized entities can interact with the healthcare system.After performing authentication protocol, only the system can accomplish other cryptography to achieve the confidentiality, integrity, and availability Suraci et al. [40] proposed a more secured and lightweight 6G eHealth system.The study used a device-to-device mutual authentication protocol to mitigates security issues.It can ensure that both communicating entities verify each other's identity before sending important data.However, their study cannot achieve better performance in mutual authentication and time-bound 6G-based healthcare environments.Later, Le et al. [3] also proposed a three-factor authentication protocol for multiple service providers in 6G-aided intelligent healthcare systems.In their study, they can provide fast authentication and time-bound security features to overcome the above drawbacks to strengthen the security requirements and accelerate the communication processes.
In a 6G-based mutual authentication healthcare system, there might be a risk of authenticated communication messages disclosure to the third party and violation of the privacy and confidentiality of patients.Hence, the deniability feature is important in 6G healthcare environments to provide user privacy.However, both schemes [3,40] do not provide deniability protocols to provide entities/users with privacy.Considering scalability of the system, we must use the ID-based Deniable Authentication Protocol with Key Agreement and Time-Bound Properties for 6G-based WBAN healthcare environments to gain better performance.
While some studies have identified potential risks and proposed partial solutions, there is still a need to develop comprehensive and robust security measures for 6G deployment in healthcare environments.Considering the importance of security and privacy concerns in our research, we tabulate the comparison results of various functions achieved by different protocols in Table 2.The symbol denotes that the protocol achieves a specific function.We also use the symbol to denote that the function is not achieved by the protocol.It is observed that the proposed protocol provides more security properties and functionalities as compared with the previous protocols in terms of ID-based, deniability mutual authentication, key agreement, and time-bound properties for 6G-based WBAN healthcare environments.In particular, only our work introduces deniability ID-based key agreement authentication and time-bound authentication solutions in the proposed 6G-IoT WBAN healthcare environment.

Performance Analysis
We assessed the interpretation of our protocol with other study protocols [22][23][24][25][26][27] and adopted the estimation time, which is based on the result of the application with the PBC library on a common hardware platform with Intel Core i5-4460 CPU at 3.2 GHz.In order to unite the benchmark baseline, we assume that n is the number of group members.A cyclic additive group and a multiplicative group with the order q, G 1 , and G 2 , respectively, ê: G 1 × G 1 → G 2 implies the permitted bilinear map.Besides, the generally adopted 80-bit security (equal to RSA-1024 bit or ECC-160 bit) level is regarded.Therefore, we organized the operation time consumption in Table 3 for the comparison in Table 4 with an illustration in Figure 13.The y-axis of Figure 13 is the estimated time for calculation, which is applied with logarithm adjustments with the base of two and the x-axis is the number of groups.Scalar multiplication refers to multiplying a scalar value (typically an integer) with a point on an elliptic curve.The running time of scalar multiplication in elliptic curve cryptography depends on the chosen algorithm, such as the double-and-add algorithm or the Montgomery ladder algorithm.These algorithms provide efficient ways to perform scalar multiplication on elliptic curves.The running time of scalar multiplication is typically proportional to the number of bits in the scalar value, which determines the number of iterations required [41].Exponentiation, on the other hand, involves raising a base value to a large exponent (typically an integer) and computing the result.The running time of exponentiation depends on the algorithm used, such as the square-andmultiply algorithm or the binary exponentiation algorithm.These algorithms provide efficient ways to compute exponentiation, taking advantage of properties such as squaring and modular reductions.The running time of exponentiation is typically proportional to the number of bits in the exponent, which determines the number of multiplications required [42].In terms of running time, scalar multiplication on elliptic curves tends to be more computationally expensive than exponentiation in traditional modular arithmetic.This is because scalar multiplication involves multiple iterations of point additions on the elliptic curve, while exponentiation typically involves a series of multiplications.Additionally, the specific algorithms used for scalar multiplication and exponentiation can also impact their respective running times.
Le et al.'s scheme [3] is designed for E-healthcare services between patients and services, not for devices.Moreover, [40] is designed based on symmetric cryptography, not public key infrastructure.Hence, our computational comparison does not include the two 6G-based schemes.The results demonstrate that our protocol is the most efficient by Scalar multiplication refers to multiplying a scalar value (typically an integer) with a point on an elliptic curve.The running time of scalar multiplication in elliptic curve cryptography depends on the chosen algorithm, such as the double-and-add algorithm or the Montgomery ladder algorithm.These algorithms provide efficient ways to perform scalar multiplication on elliptic curves.The running time of scalar multiplication is typically proportional to the number of bits in the scalar value, which determines the number of iterations required [41].Exponentiation, on the other hand, involves raising a base value to a large exponent (typically an integer) and computing the result.The running time of exponentiation depends on the algorithm used, such as the square-and-multiply algorithm or the binary exponentiation algorithm.These algorithms provide efficient ways to compute exponentiation, taking advantage of properties such as squaring and modular reductions.The running time of exponentiation is typically proportional to the number of bits in the exponent, which determines the number of multiplications required [42].In terms of running time, scalar multiplication on elliptic curves tends to be more computationally expensive than exponentiation in traditional modular arithmetic.This is because scalar multiplication involves multiple iterations of point additions on the elliptic curve, while exponentiation typically involves a series of multiplications.Additionally, the specific algorithms used for scalar multiplication and exponentiation can also impact their respective running times.
Le et al.'s scheme [3] is designed for E-healthcare services between patients and services, not for devices.Moreover, [40] is designed based on symmetric cryptography, not public key infrastructure.Hence, our computational comparison does not include the two 6G-based schemes.The results demonstrate that our protocol is the most efficient by contracting to others; however, the efficiency of Choi et al. [26] is almost the same as our protocol.

Conclusions
Healthcare systems that utilize the 6G network architecture offer quick and effortless communication channels between WBAN users and healthcare Service Providers, thereby ensuring speedy analysis of medical reports for multiple patients.Nevertheless, security and privacy remain significant issues in these systems.In this paper, we have proposed an ID-based deniable authentication protocol with key agreement and integrated timebound properties.It allows WBAN users, Service Providers, and cloud Service Providers to establish secured healthcare communications efficiently.The main contributions of our proposed protocol are given below:

•
Our proposed protocol is based on ID-based public key systems.It simplifies key and certificate management and reduces the complexity to decrease the risks of bandwidth and vulnerabilities, but still increases the security level.

•
Our proposed protocol can achieve scalablility for 6G WBAN.It manages this expansion without sacrificing the quality of service, maintaining high security and performance levels even under heavy network loads.

•
Our proposed protocol can achieve key agreement for securing WBAN communication.
It protects all entities from the risk of a third party intercepting or compromising the key.

•
Our proposed protocol can achieve deniability of authentication for protecting user privacy.It lets the users communicate securely without leaving any trace of their conversation, even if their messages are intercepted and decrypted by an attacker.The verifier cannot convince the third party of the authentication by releasing the communication messages.

•
Our proposed protocol can achieve time-bound authentication service for secure access control.It allows authorized users to access specific resources within a limited time frame, ensuring that only authorized users can access the resources and reducing the risk of unauthorized access.

•
Our proposed protocol can gain better efficiency than previously proposed protocols in terms of computational overheads.

•
Our proposed protocol can gain better security than previously proposed protocols by applying the AVISPA tool to give a formal security verification.
In future works, we will consider further improving the efficiency of the work with conference key distribution to reduce the cost of computing and storing.Other rigorous methods of authentication including three-factor authentication would also be an interesting research direction to consider.

Figure 1 .
Figure 1.The system model of the proposed scheme.•Simplifiedkey and certificate management, reducing complexity and increasing security.•Scalabilityfor 6G WBAN without compromising quality of service.•Keyagreement for secure WBAN communication, protecting against interception.• Deniability of authentication, ensuring user privacy and non-repudiation.• Time-bound authentication service for secure access control.•Improvedefficiency with lower computational overheads compared to existing protocols.

Figure 1 .
Figure 1.The system model of the proposed scheme.
encrypted by the symmetric encryption key k.D k (m) {m}_k The message is decrypted by the symmetric encryption key k.

Algorithm 1 :
SetupInput : The sec ret parameter 1 k (4) Conduct   =   (  )   =     (5) Calculate the device's and Service Provider's private keys as   =     =   (6) Transmit   to the device, and send   back to the Service Provider,   , via secure channel.

Figure 2 .
Figure 2. The key generation phase.

Figure 2 .
Figure 2. The key generation phase.

%Figure 7 .
Figure 7.The HLPSL script for the role of the session.

Figure 7 .
Figure 7.The HLPSL script for the role of the session.

Figure 8 .
Figure 8.The HLPSL script for the role of environment.

Figure 8 .
Figure 8.The HLPSL script for the role of environment.

Figure 10 .
Figure 10.The result of the CL-AtSe summary.Figure 10.The result of the CL-AtSe summary.

Figure 10 .
Figure 10.The result of the CL-AtSe summary.Figure 10.The result of the CL-AtSe summary.

Figure 10 .
Figure 10.The result of the CL-AtSe summary.

Figure 11 .
Figure 11.The snapshot of the formal security analysis of the proposed protocol using OFMC back-end.Figure 11.The snapshot of the formal security analysis of the proposed protocol using OFMC back-end.

Figure 11 .
Figure 11.The snapshot of the formal security analysis of the proposed protocol using OFMC back-end.Figure 11.The snapshot of the formal security analysis of the proposed protocol using OFMC back-end.Electronics 2023, 12, x FOR PEER REVIEW 24 of 29

Figure 12 .
Figure 12.The snapshot of the formal security analysis of the proposed protocol using CL-AtSe back-end.

Figure 12 .
Figure 12.The snapshot of the formal security analysis of the proposed protocol using CL-AtSe back-end.

Table 1 .
Notations used in the proposed protocol.
The identity   of   and the identity   of Service Provider   Output: The private key   of the device   and the private key   of the Service Prov . The results of the OFMC summary report.

Table 2 .
Comparison of functionality.

Table 3 .
The running time of the computing operations.
Note: ms means million seconds.