LAP-IoHT: A Lightweight Authentication Protocol for the Internet of Health Things.

The Internet of Health Things (IoHT), which is an extension of the Internet of Things (IoT) in healthcare, has provided a new type of telemedicine approach. In IoHT, wearable sensors are used to collect patient health data, and information is transmitted remotely to doctors who can develop accurate treatment plans and provide timely telemedicine services to patients. However, patient health data are transmitted over a public channel, which means that the privacy and medical data of patients are at significant risk of leakage and can be confronted by serious security problems. We proposed a lightweight authentication protocol known as LAP-IoHT for IoHT environments to overcome the various threats that are currently faced by IoHT. We verified the security of LAP-IoHT using a Real-or-Random model and demonstrated its significant performance advantage by conducting a comparative analysis with other similar protocols for a better adaptation to the IoHT environment.

1. Introduction

The rapid development of communication technologies has resulted in the extensive application of the Internet of Things (IoT) [1,2,3,4]. By using wireless networks to connect devices and various servers, IoT [5] provides a new means of communication that further enables interaction between virtual environments and the real world. Sensors [6,7] are the most common and versatile IoT devices. Wireless sensor networks (WSNs) [8,9,10] consist of numerous sensors to monitor specific areas and collect data. Hence, sensors and WSNs play an essential role in IoT development. At present, IoT is widely deployed in various applications and environments, such as manufacturing [11], environmental protection [12], smart cities [13,14], and intelligent transportation [15,16]. The rapid increase in the number of IoT devices demonstrates the importance and development potential of IoT, which is gradually improving the quality of life and making intelligent living and digital life possible.

Furthermore, the Internet of Health Things (IoHT) [17,18], which is a subset of IoT, is used extensively in healthcare scenarios [19,20,21]. In IoHT, wearable sensors [22,23] are implanted into the human body or set on body surfaces depending on the disease condition, thereby continuously monitoring the physiological indicators of the patient. These wearable sensors collect real-time data from the human body and transmit them to servers. Doctors can remotely analyze these data in order to provide timely medical services to patients. As the development of the healthcare sector is closely linked to people’s lives, IoHT can prevent several chronic diseases, save patient transportation costs, protect the health of healthcare professionals, reduce the possibility of conflicts between doctors and patients, and help family members to remain abreast of patients’ current conditions. IoHT provides higher-quality healthcare services, improves the level and efficiency of services, and optimizes the use of healthcare resources.

Security and privacy [24,25,26,27] have become the primary challenges of IoHT. In an IoHT system, the medical information of patients collected by sensors is transmitted over open networks. Since this information is highly sensitive, it must be protected from unauthorized users or malicious attackers, who may steal, modify, and delete health data, corrupt medical records, and even threaten the lives of patients. Moreover, attackers may target medical devices by hijacking and forging such devices, resulting in the denial of service and, in severe cases, possible damage to medical devices. Therefore, exploring a security mechanism to address the current environment and eliminate threats in IoHT is necessary.

This study proposed a lightweight authentication protocol (LAP) known as LAP-IoHT for IoHT environments. In LAP-IoHT, all participants, including the users and wearable sensors, are authenticated by the gateway. Subsequently, a shared session key is established for each communication session. LAP-IoHT encrypts the biometric features of the users to ensure anonymity. To demonstrate the security and reliability of this approach, we applied the Real-or-Random (ROR) model to analyze LAP-IoHT. The experimental results indicated that LAP-IoHT exhibits improved communication and computationally efficient performance.

The main contributions of this study are as follows:

To address the current security issues frequently encountered in healthcare IoT systems, we designed a three-factor IoHT-based protocol that incorporates authentication and key negotiation, thereby guaranteeing privacy and access control.

The introduction of biometrics, which protects the anonymity of users with unique information, can provide better user experience and privacy protection. In addition to using common one-way hash functions and simple XOR operations, we adopted asymmetric encryption and decryption in the protocol to provide higher security.

Based on a shared ROR model, we performed a formal security analysis to evaluate the security, soundness, and integrity of the session key and protocol. Moreover, the informal security analysis provided strong evidence that the protocol is resistant to currently known security attacks.

We conducted a comparative study and analyzed the performance of several protocols of the same type, taking into account the computational cost, time efficiency, and security properties. The results demonstrated that our protocol exhibits a significant performance advantage.

The remainder of this paper is organized as follows: Section 2 describes related work. In Section 3, we outlined the proposed LAP-IoHT protocol. Section 4 and Section 5 provide the security analysis and performance evaluation, respectively. Finally, Section 6 concludes the paper.

2. Related Work

IoT is widely adopted in healthcare monitoring systems. Onasanya et al. [28] proposed an IoT healthcare system for cancer care. Sun et al. [29] developed a medical record search protocol for IoT healthcare to ensure privacy preservation. Zhang et al. [30] proposed an isolation computing technology for cloud-based IoT healthcare. In 2020, Selvaraj et al. [31] reviewed the challenges and opportunities in IoT healthcare systems. Furthermore, several researchers have emphasized security and privacy issues. In 2019, Alassaf et al. [32] simulated the implementation of cryptographic functions for data in IoT healthcare. Kumari et al. [33] described a secure framework for medical systems in 2020. In 2021, Hossien et al. [34] introduced a privacy-preserving architecture for IoT healthcare based on blockchain. Wang et al. [35] proposed privacy preservation in IoT-enabled healthcare systems.

Moreover, several authentication protocols are available for IoHT. A summary of the applications of IoT in the medical industry is presented in Table 1. In 2015, Amin et al. [36] argued that elliptic curve cryptography could provide improved security for IoHT, but the protocol was not resistant against offline password-guessing attacks and privileged insider attacks. Challa et al. [37] proposed a three-factor authentication protocol for IoHT in 2018. However, once the sensor node was obtained by a malicious attacker, it broke the security of the protocol [37]. In 2019, Preeti et al. [38] designed a protocol that applied a WSN to IoHT and used a smart card. However, their protocol did not provide perfect forward security or resistance against sensor node capture attacks. Aghili et al. [39] proposed an access control and ownership transfer protocol for IoHT systems. Unfortunately, Amintoosi et al. [40] pointed out that the protocol of Aghili et al. [39] could not provide perfect forward security and was vulnerable to malicious sensor and server spoofing attacks. They also proposed a low-cost protocol for IoHT. In 2019, Gupta et al. [41] proposed a protocol that used wearable medical devices for IoHT to prevent attackers from modifying patient health information. However, Hajian et al. [42] pointed out that this protocol [41] did not protect information against privileged insider attacks, offline password-guessing attacks, and de-synchronization attacks. The proposed protocol of Hajian et al. [42] also could not provide perfect forward security and was vulnerable to session-key disclosure and impersonation attacks. To improve the security of the protocol, Kumar et al. [43] used digital signatures to encrypt the IoHT protocol communication process. Recently, Yu et al. [44] proposed a more realistic application-compliant authentication protocol designed around blockchain and physically unclonable functions while also enhancing mutual authentication between entities.

Table 1

A summary of the application of the Internet of Things in the medical industry.

Protocols	Advantages	Limitations
Amin et al. [36]	(1) Resist impersonation attack (2) Resist smart card stolen attack (3) Resist replay attack	(1) Cannot resist privileged insider attack (2) Cannot resist offline password guessing attack
Challa et al. [37]	(1) Provide user anonymity (2) Resist offline password guessing attack (3) Resist man-in-the middle attack	(1) Cannot resist sensor node capture attack
Preeti et al. [38]	(1) Provide mutual authentication (2) Resist DoS attack (3) Resist known-session-specific temporary information attack	(1) Cannot provide perfect forward security (2) Cannot resist sensor node capture attack
Aghili et al. [39]	(1) Provide user untraceability (2) Resist de-synchronization attack (3) Resist DoS attack	(1) Cannot provide perfect forward security (2) Cannot resist malicious sensor attack (3) Cannot resist server impersonation attack
Amintoosi et al. [40]	(1) Resist known-session-specific temporary information attack (2) Provide perfect forward security (3) Resist privileged insider attack	–
Gupta et al. [41]	(1) Provide perfect forward security (2) Resist impersonation attack (3) Provide anonymity and untraceability	(1) Cannot resist privileged insider attack (2) Cannot resist offline password guessing attack (3) Cannot resist de-synchronization attack
Hajian et al. [42]	(1) Resist replay attack (2) Resist privileged insider attack (3) Resist de-synchronization attack	(1) Cannot provide perfect forward security (2) Cannot resist session key disclosure attack (3) Cannot resist impersonation attack
Kumar et al. [43]	(1) Resist privileged insider attack (2) Resist man-in-the-middle attack (3) Resist replay attack	–
Yu et al. [44]	(1) Provide user untraceability and anonymity (2) Resist session key disclosure attack (3) Provide mutual authentication	–

3. Proposed LAP-IoHT

3.1. Network Model

Figure 1 depicts the overall network model of the proposed protocol. This model describes a typical IoHT environment. The architecture includes three entities: users, a gateway, and wearable sensors:

Figure 1

System model.

Wearable sensors are set on the bodies of patients. They can observe various body indicators, such as the electrocardiogram (ECG), electromyography (EMG), electroencephalogram (EEG), respiratory rate, pulse, blood pressure, blood glucose, and oxygen saturation. These wearable sensors should be registered with a gateway before being deployed to human bodies for precise management.

Users are organizations or groups of people who can view the health data of patients. For example, users may be hospital administrators, doctors, pharmacists, nurses, families of patients, data analysts, and drug trialists. If a person needs to enter the network and view patient medical data, the person must register with the gateway in advance and become a legitimate user with the appropriate authorities.

The gateway in our IoHT architecture acts as a trusted server. Prior to entering this network, all wearable sensors and users should register with the gateway. Subsequently, the gateway manages the list of all sensors and legitimate users.

Assume that a user desires to obtain data from a specific wearable sensor. This user transmits a request to the gateway and the gateway forwards this request to the sensor. After receiving the request, the wearable sensor sends the data to the user with the help of the gateway. Since medical data are personal and private, all communications among the users, gateway, and sensors should be confidential. The most straightforward method for achieving this is to encrypt the transmitted data.

The gateway can authenticate users and sensors using the proposed protocol. Moreover, a shared session key is established for each session.

3.2. LAP-IoHT

This section presents the proposed LAP-IoHT protocol for IoHT, which consists of three phases: user registration, sensor registration, and login and authentication. The notations and symbols are defined in Table 2.

Table 2

Notation definitions.

Notations	Descriptions
U_i	ith user
ID_i	Identity of U_i
PW_i	Password of U_i
Bio	Biometrics of U_i
SN_j	jth sensor node
SID_j	Identity of SN_j
GWN	Gateway node
G_j	Private key of GWN
pbs	Public key of SN_j
pvs	Private key of SN_j
SK	Session key
T_s	Time stamp, where s = 1, 2, 3, 4
r_1,r_u,r_g,r_s	Temporary random number
⊕	XOR operation
‖	Concatenate operation
h(·)	Hash function
Gen(·)/Rep(·)	Fuzzy extractor/reproduction function
ENC/DEC	Asymmetric encryption/decryption
→	The public channel
⇒	The secure channel
A	Adversary

3.3. User Registration Phase

Assume that user desires to become a legitimate user. This user must register with . Figure 2 shows the steps that are involved in this phase. The messages are transmitted through a secure channel.

Figure 2

User registration phase.

prepares his or her own and and unique biometric and selects a random number . Subsequently, computes , , , and . Thereafter, transmits , , to .

first verifies whether has already been registered. Thereafter, calculates , , , and . Subsequently, stores in its database and transmits , , to .

computes and , and then stores , , , , in his or her smart card.

3.4. Sensor Registration Phase

A wearable sensor must also be registered before joining the network. Assume that sensor desires registration with . Figure 3 depicts the detailed steps involved in this phase. The messages are submitted via a secure channel:

Figure 3

Sensor registration phase.

sends its identity to .

generates a random number b and calculates the pseudo-identity of , where . Subsequently, calculates and with its own private key . also uses an asymmetric encryption system to encrypt with the public key of . At this point, calculates , sends , to , and stores , in the database.

stores , in its own memory.

3.5. Login and Authentication Phase

If requires connection to a specific wearable sensor , needs to verify the legitimacy of the user. Subsequently, , , and build a session key to encrypt the messages among them. In this phase, several parameters (e.g., , , , , and ) are calculated. Figure 4 illustrates this phase, the details of which are as follows:

Figure 4

Login and authentication phase.

inserts his or her smart card into a smart card reader/computer and provides his or her identity , password , and biometrics . This computer calculates , , and , where and . Subsequently, it determines whether is equal to M stored in the smart card. If , the computer generates and timestamp and calculates , , and . calculates and then sends to .

first verifies the freshness of and retrieves the corresponding from its own database according to . Thereafter, calculates , , and . If and the received are equal, generates a random number and current timestamp . Subsequently, calculates , , , , , and . Thereafter, transmits , , , , to .

verifies the freshness of and then obtains by decrypting L with his or her private key . Thereafter, calculates , , , , and . determines whether is the same as the received . If so, generates , , and computes , , , and . Finally, calculates the session key as . At this point, transmits , , , to .

first verifies the freshness of , and calculates , , and . Subsequently, verifies the legitimacy of by determining whether is equal to . If they are equal, generates a timestamp , computes , , and , and produces a session key . provides for mutual authentications with the user and sends , , , , to .

The computer of inspects the timestamp from , and computes and . Thereafter, it calculates and verifies whether . Subsequently, it calculates , where . At this time, can successfully calculate the session key . Obviously, , , and have the same session key at this point.

4. Security Analysis

This section first describes the capabilities that the attacker may possess. Subsequently, we demonstrate that our method is secure against different types of attacks. Finally, we use the Real-or-Random (ROR) model to show that our LAP-IoHT protocol is provably secure.

4.1. Adversary Model

We consider the well-known Dolev–Yao (DY) adversary model [45] and assume that an attacker has the following capabilities:

can eavesdrop, block, replay, alter, and delete messages that are sent over a public channel.

can steal the smart card or smart device of a user and obtain the information stored therein.

can capture a sensor node to extract the information stored therein.

can obtain the long-term key of the gateway and acquire the contents stored therein as an internal privileged person.

4.2. Protection against Well-Known Attacks

4.2.1. Replay Attack

In LAP-IoHT, messages that are transmitted via a public channel have timestamps, such as , , , and . These timestamps ensure the freshness of the messages and resist replay attacks. Moreover, , , , , and include random numbers. Timestamps and random numbers are two effective means of preventing replay attacks. Thus, LAP-IoHT is resistant against replay attacks.

4.2.2. User Impersonation Attack

Assume that can obtain the private key of . Even if intercepts the parameters , , and via a public channel, still cannot obtain because cannot obtain and . Therefore, fails to calculate , cannot pass the authentication of , and cannot imitate for communication. Thus, LAP-IoHT can effectively resist user impersonation attacks.

4.2.3. Server Impersonation Attack

Suppose that can obtain a smart card for . However, does not know the value of and the private key of the gateway; therefore, cannot pass the authentication of by computing and cannot successfully imitate the gateway. Hence, our protocol can defend against server impersonation attacks.

4.2.4. Privileged Insider Attack

If is an insider of , can obtain , , , and , which are stored in the database of . However, cannot successfully obtain the session key because he or she does not know , , and . Thus, the proposed protocol can defend against privileged insider attacks. Therefore, we can state that the proposed protocol is secure against insider attacks.

4.2.5. Known Session Specific Temporary Information Attack

We assume that the temporary random number is obtained using . If wishes to calculate the session key , three parameters and are required. However, cannot know because he or she cannot obtain . Furthermore, cannot obtain . Thus, our protocol is not affected by temporary information leakage.

4.2.6. Stolen Smart Card Attack

obtains stored in the smart card that he or she has stolen. Even if knows and , cannot obtain because he or she cannot obtain . This implies that cannot pass the server verification let alone establish a communication session key with . Thus, LAP-IoHT is resistant against smart card theft attacks.

4.2.7. Perfect Forward Security

If knows the of the gateway when calculating the random number , can intercept the transmitted information and the other parameter . is already known by , but as , cannot obtain N and and, hence, cannot know . Since cannot calculate , he or she cannot obtain session key . Therefore, our protocol provides perfect forward security.

4.3. ROR Security Analysis

The ROR (Real-or-Random) model is a widely used security-proof method. The ROR model can obtain the probability of successfully breaking session key through several different game rounds. Therefore, we use the ROR model to perform a formal security analysis to demonstrate the security and accuracy of the protocol.

4.3.1. ROR Model

Our protocol comprises three entities: , , and . We use , , and to denote the x-th user, y-th gateway, and z-th sensor nodes, respectively, such that , , and . Suppose that attacker can execute the following queries:

: When this query is executed, can intercept the messages that are transmitted among entities , , and over the public channel.

: By executing this query, can send message M to R and receive the response message from R.

: Through this operation, can obtain the hash value of a fixed-length string after inputting it.

: By executing this query, obtains the private value of an entity, such as long-term key, generated temporary information, or parameters that are stored in a smart card.

: Assume that executes this query and can determine the security of the session key by tossing coin C. If C = 1, obtains the correct session key. Otherwise, receives a random string.

Theorem 1: In the ROR model, we use as a function of the attacker’s ability to compromise the protocol through query operations; that is, the probability that can obtain the session key , where and represent the number of times to perform the and queries, respectively, and represent the space range and dictionary size corresponding to the hash operation, respectively, and t represents the number of bits of biological information in the protocol.

4.3.2. Security Proof

To prove the accuracy of Theorem 1, we performed four rounds of game , where denotes the probability of the attacker winning in each round of the game. The details of the game are as follows.

: At the beginning of the game, only needs to determine bit b and does not perform any query operation. Therefore, we can obtain

: performs a wiretap operation on top of . In this round, can only steal messages that are transmitted on the common channels , , , and . cannot execute the queries to obtain the session key during communication because the values of the random numbers , , and cannot be obtained based only on the information in the common channels. Therefore, the probability of winning the game after performing an query is equal to .

: is the third round of the game, in which the query and operation have already occurred in . During the game, forgery is not possible because , , , , , , , , and are encrypted using hash functions. Moreover, the important parameters , , and , which constitute the session key, are random in all sessions and do not cause hash conflicts. Thus, according to the birthday paradox, we obtain

: In this round, the query is executed and the attacker can obtain the private value of an entity, such as , , or . Moreover, attempts to guess and ; however, even if can successfully guess and simultaneously, he or she still cannot obtain the random number . Since , , , , and the probability of the biometric being estimated is , cannot obtain the biological eigenvalue . If can only enter the code a finite number of times, we know that

Since can only win the game if the correct bit b is guessed, we obtain

Using Equations (1)–(5) above, we obtain

Ultimately, we can obtain .

4.4. Security Comparisons

We compare LAP-IoHT with other related protocols with similar architectures, such as those of Kumar et al. [43], Yu et al. [44], Amin et al. [36], Challa et al. [37], Aghili et al. [39], and Preeti et al. [38]. We set the following representations: A1: resist replay attack; A2: resist impersonation attack; A3: resist privileged insider attack; A4: perfect forward security; A5: resist known session specific temporary information attack; A6: resist stolen smart card attack; A7: resist offline password guessing attack; A8: resist sensor node capture attack; A9: resist de-synchronization attack; A10: resist session key disclosure attack. “Y” indicates that the protocol is invulnerable to this attack, and “N” indicates that the protocol is vulnerable to this attack. The results in Table 3 demonstrate that, with the continual development of technology and various attack methods, the other related protocols will be affected by the above attacks. Compared to these protocols, our method exhibits better security and sufficient advantages in resisting the above attacks to guarantee the security of communication sessions.

Table 3

Comparisons of security.

Protocols	A1	A2	A3	A4	A5	A6	A7	A8	A9	A10
Ours	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
Kumar et al. [43]	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
Yu et al. [44]	Y	Y	Y	Y	Y	Y	Y	Y	Y	Y
Amin et al. [36]	Y	Y	N	Y	Y	Y	N	Y	Y	Y
Challa et al. [37]	Y	Y	Y	Y	Y	Y	Y	N	Y	Y
Preeti et al. [38]	Y	Y	Y	N	Y	Y	Y	N	Y	Y
Aghili et al. [39]	Y	N	N	Y	Y	Y	Y	Y	Y	Y

5. Performance Comparison

In this section, we evaluate the performance of the proposed LAP-IoHT protocol by performing comparisons with other protocols, such as those proposed by Kumar et al. [43], Yu et al. [44], Amin et al. [36], Challa et al. [37], Aghili et al. [39], and Preeti et al. [38], in terms of the computation time and communication cost.

We used different devices to obtain the computation time and communication cost required for the certification stage in the performance comparison. We used a mobile phone, laptop computer, and desktop computer to simulate the user, gateway, and sensor nodes, respectively. The relevant parameters for the three devices are listed in Table 4. Table 5 presents the times required by different devices to perform certain operations. denotes the time required to perform a single hash function operation, denotes the time required to perform a single symmetric encryption or decryption operation, denotes the time required to perform a single fuzzy extraction operation, denotes the time required to perform a single asymmetric encryption or decryption operation, denotes the time required to execute the digital signature operation, and denotes the time required to perform an elliptic curve point multiplication operation. As the communication times required by the connection and XOR operations are insignificant compared to the other operations, these can be ignored. Table 6 presents a comparison of the communication times of our proposed protocol and other similar protocols. Several communication costs arise in the communication process, and asymmetric encryption or decryption has an enormous overhead of 1024 bits. The length required for the elliptic curve point multiplication operation is 320 bits; the length of each block for symmetric encryption or decryption is 256 bits; the hash values and random numbers all have similar lengths of 160 bits; the identity, password, and biometrics are all 128 bits in length; the timestamps require a length of 32 bits. In Table 7, we compare the communication overheads of multiple protocols to determine the specific communication cost.

Table 4

Parameters of the devices.

Devices	Model	Operating System	Memory	Processor
mobile phone	MI 8	Android	6 GB	Qualcomm Snapdragon 845
laptop computer	DELL G15 5510	Windows 10	16 GB	Intel(R) Core(TM)i7-10870H
desktop computer	LENOVO 90M2A0A6CD	Windows 10	8 GB	Intel(R) Core(TM)i5-9500

Table 5

Execution time of operations.

Operations	MI 8	DELL G15 5510	LENOVO 90M2A0A6CD
T_FE	20.7028 ms	2.2823 ms	1.6197 ms
T_ASED	47.6405 ms	5.2520 ms	3.7272 ms
T_PM	0.00044 ms	16 ms	13 ms
T_SED	0.2009 ms	0.1551 ms	0.0879 ms
T_H	0.02812 ms	0.0031 ms	0.0022 ms
T_S	69 ms	270 ms	139 ms

Table 6

Comparison of time.

Protocols	User	Gateway	SensorNode	Total Computation
				(ms)
Ours	T_FE+10T_H	14T_H	T_ASED+7T_H	24.77
Kumar et al. [43]	2T_PM+8T_H+2T_S+3T_SED	T_SED+3T_H	T_PM+10T_H+2T_S+2T_SED	370.19074
Yu et al. [44]	T_FE+9T_H	9T_H	7T_H	20.99918
Amin et al. [36]	T_SED+4T_PM+7T_H	T_SED+2T_PM+6T_H	2T_SED+3T_PM+4T_H	71.7578
Challa et al. [37]	T_FE+2T_PM+9T_H	T_PM+4T_H	6T_H	36.9824
Preeti et al. [38]	T_FE+3T_PM+15T_H	3T_PM+11T_H	5T_H	69.171
Aghili et al. [39]	T_FE+12T_H	16T_H	4T_H	21.09864

Table 7

Comparison of cost.

Protocols	User	Gateway	SensorNode	Total Communication Cost (bits)	Number of Messages
Ours	480	1504	512	2496	4
Kumar et al. [43]	1824	3424	1472	6720	4
Yu et al. [44]	672	1216	672	2560	5
Amin et al. [36]	960	1280	800	3040	4
Challa et al. [37]	832	224	352	1408	3
Preeti et al. [38]	832	1088	352	2272	4
Aghili et al. [39]	800	864	4352	2016	4

5.1. Computation Time

We use three devices to determine the computation time and communication cost. The times required to perform elliptic curve point multiplication, symmetric encryption/decryption, asymmetric encryption/decryption, single fuzzy extraction, and hash functions vary on different devices. Furthermore, the computation times required for the connection and XOR operations are insignificant compared to the other operations; thus, we ignore these in our evaluation.

The computation times of the proposed protocol and other similar protocols are listed in Table 6. Table 6 shows the computation costs of all protocols. The most time-consuming protocol is the protocol proposed by Kumar et al. [43], which includes elliptic curve point multiplication and digital signature operations. The protocol proposed by Yu et al. [44] is the least time consuming. Although our proposed protocol includes fuzzy extraction and asymmetric operations in the login and authentication processes, its computation time is relatively short.

5.2. Communication Cost

We assume that the output of asymmetric encryption/decryption is 1024 bits; the length required for the elliptic curve point multiplication operation is 320 bits; each block for symmetric encryption/decryption is 256 bits; the hashed value and random number are 160 bits; the identity, password, and biometrics are all 128 bits in length; the timestamps require a length of 32 bits.

According to Table 7, we can determine the communication costs of all the protocols. The communication costs of the protocols proposed by Kumar et al. [43], Yu et al. [44], Amin et al. [36], Challa et al. [37], Aghili et al. [39], and Preeti et al. [38] are 6720 bits (256 ∗ 7 + 32 + 256 ∗ 6 + 32 + 256 ∗ 7 + 32 + 32 + 256 ∗ 5 + 160 + 32), 2560 bits (160 + 160 + 160 + 160 + 32 + 160 + 160 + 32 + 160 + 160 + 160 + 32 + 160 + 160 + 32 + 160 + 160 + 160 + 160 + 32, 3040 bits (128 + 320 + 160 + 160 + 32 + 160 + 256 ∗ 3 + 320 + 32 + 256hl∗3 + 32 + 160), 1408 bits (160 + 160 + 320 + 160 + 32 + 160 + 32 + 32 + 160 + 160 + 32), 2272 bits (160 + 160 + 160 + 320 + 32 + 160 + 160 + 32 + 32 + 160 + 160 + 320 + 32 + 32 + 160 + 160 + 32), and 2016 bits (160 + 160 + 160 + 160 + 128 + 32 + 160 + 160 + 160 + 32 + 160 + 160 + 32 + 160 + 160 + 32), respectively. The communication cost of our proposed protocol is 2496 bits (128 + 160 + 160 + 32 + 160 + 160 + 160 + 160 + 32 + 160 + 160 + 160 + 32 + 160 + 160 + 160 + 160 + 160 + 32).

Figure 5 and Figure 6 compare the LAP-IoHT protocol with the other related protocols in terms of the computation times and communication costs. Although the communication costs of the LAP-IoHT protocol are higher than those of the protocols proposed by Challa et al. [37], Aghili et al. [39], and Preeti et al. [38], the run time of LAP-IoHT is much lower [37,38]. Moreover, the security of LAP-IoHT is higher than those of all three [37,38,39]. Furthermore, although the protocols proposed by Kumar et al. [43] and Yu et al. [44] are more secure, they do not offer any advantages in terms of communication costs. Therefore, it is easy to conclude that LAP-IoHT performs better than the related protocols. More importantly, it can be observed from Table 3 that LAP-IoHT has excellent security advantages. It can effectively resist various attacks, thereby providing security for communication sessions.

Figure 5

Running times.

Figure 6

Communication costs.

6. Conclusions

Internet of Health Things (IoHT), which promotes intelligent healthcare, plays a pivotal role in the future e-healthcare environment. Due to its high sensitivity, the health data transmitted through a public channel should be protected from unauthorized access. This means that an authentication protocol is essential. This paper presented a more secure and reliable authentication protocol called LAP-IoHT for the Internet of Health Things. LAP-IoHT provides mutual authentication among users, sensors, and a gateway over a public channel. Moreover, a user and a sensor can establish a common session key after a protocol run. By using the ROR model and performing an informal analysis, it was proven that LAP-IoHT has adequate security and reliability as well as sufficient ability to resist various attacks. Furthermore, we compared LAP-IoHT with related protocols and found that our protocol is at the mid-to-upstream level in terms of time and communication costs, exhibiting a significant performance advantage. In summary, the proposed protocol offers specific practical value in the current environment and has more robust adaptability relative to the future development of IoHT.