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.
5.2. 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()” is instantiating a new value to the primed (‘) variable. The symbol “ /\ “ denotes the conjunction action.
Following the description of CSP, we will describe the role of device D and provide the HLPSL script for it in
Figure 5. The device’s knowledge includes agents (D, SP, CSP), symmetric keys (SKcspd, SKcspsp, SKspd), hash functions (H, H2, H3, MUL), a public key (PUBLICP), and communication channels (SND and RCV). The device’s structure is similar to CSP, with the same local variables and keywords. However, the “init State” keyword starts from 0 to indicate the script’s starting point. This expression also appears in the Service Provider’s role and is permitted to execute on AVISPA.
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, 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 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 secure and satisfies the security goals. To provide a reference, we include execution snapshots in
Figure 11 and
Figure 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.
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.