Physical Unclonable Function and Machine Learning Based Group Authentication and Data Masking for In-Hospital Segments

Abstract

The involvement of the Internet of things (IoT) in the development of technology makes systems automated and peoples’ lives easier. The IoT is taking part in many applications, from smart homes to smart industries, in order to make a city smart. One of the major applications of the IoT is the Internet of medical things (IoMT) which deals with patients’ sensitive information. This confidential information needs to be properly transferred and securely authenticated. For successful data protection and preserving privacy, this paper proposes multidevice authentication for the in-hospital segment using a physical unclonable function (PUF) and machine learning (ML). The proposed method authenticates multiple devices using a single message. Most of the protocols require PUF keys to be stored at the server, which is not required in the proposed framework. Moreover, authentication, as well as data, is sent to the server in the same message, which results in faster processing. Furthermore, a single ML model authenticates a group of devices at the same time. The proposed method shows 99.54% accuracy in identifying the group of devices. Moreover, the proposed method takes 2.6 ms and 104 bytes to complete the authentication of a device and takes less time with the increment of devices in the group. The proposed algorithm is analyzed using a formal analysis to show its resistance against various vulnerabilities.

1. Introduction

Industry 4.0, or the fourth industrial revolution, was coined in 2011 by the German Federal Government to emphasize its high-tech approach [1]. Industry 4.0 aimed to integrate the physical components or devices for manufacturing (i.e., various machines, sensors, complex tools) and communication parts (i.e., advanced software) through wired/wireless networks to predict, control, maintain, and integrate the manufacturing process [2]. IoT, cyberphysical systems, cloud computing, edge computing, Big Data analytics, robotics, virtual reality, etc., are the categories of industry 4.0 [3]. The smart city is a major application to make industry 4.0 successful. Many countries are adopting smart cities to provide a better quality of life [4]. Since the smart city generates a network where all connected devices can communicate with one another, enabling the creation of a device-to-device or machine-to-machine network, it is imperative to develop an omnipresent computing system [5]. To provide seamless support and better health service, the IoMT system is developing in the smart city. The IoMT is a system where people with both wearable or implantable medical devices (MD) suffering from diseases, for example, blood pressure, cardiac, and diabetes, are connected to a network to transfer health data to health experts. Experts check the data and prescribe the patients accordingly [6]. The environment of the IoMT can be classified into five categories.

• On-body segment: consumer health wearables (used for fitness or health data monitoring such as fitness bands, smartwatches, smart shoes, smart clothes, etc.) and clinical-grade wearables (for example, elders can wear smart belts for identifying any risks and providing safety support, Halo Sport headset to activate specific brain regions, etc.) [7].
• In-home segment: For making a healthy home, wearable devices for monitoring patients at home use health data collection using sensors [8]. For example, a personal emergency response system can be used by older people to get live service; telemedicine and digital tests are part of the in-home IoMT segment.
• Community segment: The MDs and health stations of a particular area develop this segment [9]. This segment considers mobility, emergency response intelligence, kiosks, point-of-care devices, and logistics as components.
• In-clinic segment: the MDs that help to gather necessary data and device suggestions regarding administrative and clinical operations build this segment [10].
• In-hospital segment: This segment manages the system of a hospital using MDs’ data. This can provide solutions in the area of patient management, personnel management, environment, etc., in the hospital [11].

Figure 1 shows the IoMT ecosystem in a hospital environment in a smart city [12]. In the IoMT system, all the MDs are connected to the cloud server through the internet (wired or wireless). MDs collect data from the human body, and the data are passed to the cloud server. Doctors or experts access the data to take further action. Doctors do not need to visit in person to check the condition of patients. The advantages of the IoMT are attracting the healthcare sector to adopt it.

According to Deloitte’s report, the market value of the IoMT will reach around USD 158 billion by 2022 [13]. The IoMT is bringing advantages not only to the doctors and patients’ management but is also becoming a blessing economically. It is expected that the healthcare industry will be able to save approximately USD 300 billion per year. Nevertheless, the IoMT is also bringing severe challenges in the area of security and privacy.

1.1. Security and Privacy Concerns in the IoMT

Security and privacy concerns are rising in the IoMT system. Different adversarial impacts, such as data breach, identity theft, data modification, denial of service, etc., could pose threats to the IoMT network [14]. A report from Cynerio in August 2022 stated that in 88% of cases of cyberattacks, an MD was involved. Moreover, healthcare had to pay around USD 1 million for average data breach cases, and it increased the mortality rate by 24% [15]. A total of 2.9 million subscribers were affected in the cyberattack on Health South-East RHF in Norway. Approximately 19,000 appointments were canceled in the WannaCry ransomware attack on England’s National Health Service. Moreover, they had to spend 92 million to recover from the threat. Since the IoMT deals with sensitive information, it is required to preserve the security of the system and preserve user privacy to avoid data loss, unauthorized access, or malicious attackers.

IoMT systems need to implement a robust and secure authentication and data communication mechanism [16]. Authentication systems can be developed using a decentralized system, such as the blockchain, and also using a centralized server system. In the blockchain, a number of transactions make a block and connect with the previous blocks to build a chain. In the centralized server system, the server is responsible for making decisions. Different encryption methods, such as advanced encryption standard (AES), message authentication code (MAC), attribute-based encryption (ABE), elliptic curve cryptography (ECC), etc., are used to develop authentication mechanisms. A PUF is another method to develop an authentication method that does not need to store a cryptographic key in the system. To build a robust and secure authentication framework as well as data masking, this paper used a PUF and ML.

A PUF is a one-way function that provides a unique Boolean mapping between the input of the PUF and the output of the PUF. The manufacturing process differences of the chips create statistical process variations that define the PUF working principle [17]. PUF can also be called a chip fingerprint. It is a useful tool for applications such as authentication, validation, identification, etc. Unlike conventional methods to store secret keys, such as encryption and password, a PUF generates secret keys instantly using a semiconductor chip’s complex characteristics [18]. Due to imperfections in the manufacturing process, a PUF generates different secret keys when a different input is provided. The combination of input (challenge) and output (response) of the PUF is the signature of the PUF, which is referred to as a challenge–response pair (CRP) [19]. Figure 2 shows the CRP relations among different PUFs. It can be seen that n sets of challenges are sent to n PUFs where each PUF generates different responses due to different process variations of the chips. Recently, mathematical models was used against PUFs to exploit it. The attack was called a modeling attack. A successful tool for performing modeling attacks is ML [20]. By protecting CRP interfaces, it is possible to resist modeling attacks.

On the other hand, ML is mainly driven by data [21]. ML is a powerful tool that is making life easier and providing faster solutions to complex systems. In healthcare, ML is a blessing by identifying diseases using images and data, scheduling appointments, and creating a better relationship between patients and doctors [22]. ML is a method that tries to learn outputs using input data through mathematical models. There could be a number of input features and a number of output features. Supervised, unsupervised, and reinforcement learning are the three types of ML [23]. In supervised learning, a training dataset is required. During training, a decision rule is trained, and a classifier is constructed. The learning process runs till the desired goal is achieved with a proper optimization of weights and other parameters [24]. Supervised ML is divided into segments such as binary classification, multiclass classification, regression, etc. In binary classification, there are two kinds of output classes, and a sigmoid is used in the last layer of the modeling. In multiclass classification, there are a number of classes in the output feature. There are three types of layers which are the input layer, the hidden layer, and the output layer. The input features map with the output class to learn properly. Figure 3 shows an example of multiclass classification. The first layer is the input layer, where the size of the layer depends on the features of the dataset. The next layer is the hidden layer, which is a layer of mathematical functions, each designed to produce an output specific to an intended result. There could be more than one hidden layer. The last layer is the output layer, where the size is the classes/labels of the dataset. In this kind of supervised learning, a softmax function with the number of classes as unit size is in the last layer of the model. An explanation of the relationships among input features and one or more responses or target output features is provided by a regression model.

1.2. Contributions

Researchers in both academia and the industry are working continuously to develop authentication methods to secure IoMT applications. The developed methods need to be robust enough to provide security against known security threats. Moreover, it is required to avoid complex calculations and make the framework lightweight as the IoMT devices are resource-constrained and cannot allocate a lot of resources for authentication purposes. Furthermore, the authentication process should not raise a burden on the communication network. Most of the existing methods use single device authentication and need to perform several steps of communication to validate the devices. This type of method consumes the transmission resources and device resources to perform operations at different times. Moreover, the device needs to send data separately after completing the authentication. To resist known security attacks, validate multiple devices, and send data in the authentication request, simple and lightweight operations along with a low communication cost are required; this paper proposes an authentication framework using a PUF and ML to validate a group of medical devices and send data at the same time. The contributions of the proposed framework are as follows.

• It is the general norm for PUF-based methods to transmit challenges to the device and/or the cloud. The proposed framework incorporates machine learning to control the PUF. It eliminates the requirement of transmitting challenges from the cloud server.
• Usually, CRPs are stored on the cloud server to verify the devices. The proposed method removes the requirement of CRP storage in the cloud server, which reduces the storage cost in the secure database.
• A group of devices are authenticated at a time instead of a single device.
• A single message transfer is adequate to complete the authentication of the group of medical devices.
• A single machine learning model identifies a group of medical devices. The proposed method eliminates the requirement of storing multiple models for multiple devices.
• No need to transfer data separately after authentication. Health data are sent at the same time with the authentication request.
• The secret encryption key in the edge router is updated periodically, which removes prevents key guessing attacks.
• The method involves each device’s authentication separately, it follows a linear relation for communication overhead. Communication overhead is decreased with the increment of devices in the proposed method.
• Less computation cost is involved. The cost is also decreased with the number of devices.

The rest of the paper consists of related work in Section 2, the proposed framework in Section 3, results in Section 4, a security proof in Section 5, and the conclusion and future work in Section 6.

2. Related Work

Li et al. [25] proposed a lightweight authentication mechanism using a secret key. The method required a trusted gateway to register the node using the secret key. The secret key helped to establish the session key. The method was lightweight; however, the storage cost was high in the developed scheme. Amintoosi et al. [26] developed another lightweight scheme using identity (ID), a password, and a smart card. This scheme used operations such as hash, XOR, concatenation, etc., to make it lightweight. A MAC-based authentication scheme was developed by Siddiqi et al. [27]. In the method, the server used the key where K-bit was missing, and the sensor device needed to identify the hash of the missing bits. The method saved energy but did not preserve user anonymity. Hwang et al. [28] developed a CP-ABE-based framework for the IoMT environment. The ciphertext length was the same and it was independent of other parameters. The method identified the root cause by finding the first receiver of the key. The proposed method needed significant computations to identify devices. If an attacker received the delegated key, there could be a chance of health data leakage. Liu et al. [29] proposed a multikeyword searchable method using the ABE mechanism. The proposed method used ABE to encrypt the symmetric key. The method performed most of the decryption calculations on the server, which reduced the calculations on the user side. A combination of boolean attributes and a weighted comparison of attributes was used to develop a new method called ciphertext policy weighted-attribute-based encryption (CP-WABE) by Li et al. [30]. The storage cost was comparatively high due to the storage of a set of weights. An ECG- based IoMT device authentication scheme was developed by Huang et al. [31]. The method removed the noise from the ECG signal to operate. Depending on the saved attributes and patients’ movement, noise interference was changed. Angular distances dues to different movements, such as running and walking, could impact the proposed method. The method needed to improve to preserve user anonymity and reduce computation cost. Another method developed by Ying et al. used ECG templates as user biometrics [32]. The framework used ECC and a smart card. Different nonces and hash functions were written in the smart card for verification purposes. The method needed to cater to ECG-related problems and server impersonation attacks. Moreover, the method needed to optimize communication overhead. Ryu et al. also proposed an ECC based authentication framework [33]. The proposed method also used the user’s biometrics, but it kept the features separate to avoid attacks due to theft parameters. The proposed method could optimize storage costs due to unused parameters in the authentication process. Moreover, the cost of the framework was high comparatively. Al-Zubaidie et al. [34] developed an authentication method using ECC and the PHOTON hash function. The method used information from the user and device for the successful completion of the authentication. Moreover, information related to physical address, a one-time password, etc., was part of the authentication framework. Gopalan et al. [35] proposed an ECC based mechanism for secure data transfer when the initial authentication is completed. The method used log-of-round-value-based elliptic curve cryptography (LR-ECC) for securing the data transfer. De-Marcos et al. [36] developed a continuous authentication method to avoid the security issue of one-time authentication. They used seven different classifiers where the ensemble algorithm showed better performance for classification. Wazid et al. developed an authentication mechanism for secure communication between a device and a personal server using a secret key [37]. They also used artificial intelligence for data analysis. The method used a decision tree, a support vector machine, and logistic regression, and the accuracy was below 88%. The above methods used different cryptographic keys, which are required to be stored in the device.

To avoid key storage, a PUF-based authentication mechanism was developed by Alladi et al. [38]. The method used two factors to complete the authentication. Moreover, instead of using a complete response, the method used a segmented response. However, the method required complex computations. Moreover, the method needed to store the challenge, and after completing authentication, the device needed to select the challenge in random order. If the PUF of the device could not produce a stable response for the challenge, there was authentication failure. Gope et al. [39] also developed a PUF-based authentication framework for the IoMT system. Both server and client devices verified one CRP to identify each other. Two CRPs were required to transfer over the communication channel. The process of updating reserve CRPs was not mentioned in the method. Lee et al. [40] also used a PUF to develop an authentication mechanism for a dynamic group key agreement. A key agreement between two devices was initiated by a register center. After that, CRPs from both devices, stored parameters, and different operations were used for mutual agreement. Both devices broadcast the keys to update the group key by other devices of the group. One of the devices for mutual agreement was required to be an existing device for a successful update. Moreover, the method needed to state the procedure for getting the existing group key for the new devices.

To avoid using a centralized server, blockchain-based authentication mechanisms have been used. Abdellatif et al. [41] developed a blockchain-based authentication mechanism which integrated edge computing to process health data. The method created three different channels for different kinds of data. The work focused on prioritizing different levels of data. Another blockchain-based authentication system was developed by Lin et al. [42]. They used reinforcement learning to allocate resources. In the method, a ${360}^{\circ }$ video was captured using virtual reality. The method could identify the common view of similar patients, but a comparatively high computing capacity was required. Egala et al. [43] developed a novel blockchain-based system. The method introduced selective ring-based access control and ECC to authenticate the device. The method also maintained a gray list to record unauthorized devices. Wang et al. [44] developed an authentication mechanism using a PUF. They applied fuzzy extraction to handle users’ biometric data.

Table 1. Comparative analysis of related works.

Author	Objective	Technique Used	Pros	Cons
Li et al. [25]	Reduce complexity and secure communication	PKI	Lightweight scheme	Much time and storage required
Siddiqi et al. [27]	Security protocol for IMD ecosystem	MAC	7% energy consumption	No user anonymity
Hwang et al. [28]	Improve CP-ABE-based scheme	CP-ABE	Resolves key abuse problem	PHI leakage
Liu et al. [29]	Achieve data SNP preservation	ABE	Major decryption on server side	Complex
Huang et al. [31]	Protection from unauthorized entity	ECG	Remove noise, light algorithm	No anonymous identity
Ying et al. [32]	Secure communication	ECC	Low computational time	High communication overhead
Ryu et al. [33]	Robust authentication	ECC	Used biometrics along with stored parameter	Unused parameters
Wazid et al. [37]	Secure communication among devices, personal server, and cloud server	AI	Low end-to-end delay	Low accuracy
Alladi et al. [38]	To achieve physical security	PUF	Low computation time	Unstable CRP can cause failure
Gope et al. [39]	Secure and efficient authentication	PUF	Less computation at server	Two CRPs per transaction
Lee et al. [40]	Establish group key agreement	PUF	Simple	Two new devices cannot take part at a time
Abdellatif et al. [41]	Process large quantities of medical data	Blockchain	Remote monitoring, different actions for different data	Security is not focused
Egala et al. [43]	Efficient secure exchange for decentralized network	Blockchain and ECC	Low energy, fast response	Ring tamper resistance instead of device
Wang et al. [44]	To build a reliable communication channel for healthcare	Blockchain (PoW) and PUF	Low cost	Storage cost

shows a comparison of existing authentication schemes.

3. Proposed Group Medical Devices Authentication and Data Masking Framework

In the proposed method, a group of MDs are authenticated, and their data are masked. The cloud server (CS) authenticates and retrieves the original data with the help of an edge router (ER). A group of MDs are connected to the ER through a wired/wireless medium. The below elements are used in the proposed framework. Figure 4 shows the overview of the proposed mechanism.

Table 2. Acronyms used in the proposed section.

Acronym	Full Form	Acronym	Full Form
MD	IoMT device	PUF	Physical unclonable function
ER	Edge router	CS	Cloud server
SDB	Secure database	$PID,PI{D}_1,PI{D}_2,PI{D}_n$	Pseudoidentity
$M{C}_{model}$	PUF controlling model	$M{L}_{model}$	Device prediction model
$C,C_1,C_2,C_3,C_n$	Challenge of MDs	$R,R_1,R_2,R_3,R_n$	Response of MDs
$C{1}_n,C{2}_n,C{3}_n,C{n}_n$	Stored challenge in MDs	$R{1}_n,R{2}_n,R{3}_n,R{n}_n$	Stored response in MDs
$C_{ER}$	Stored challenge in ER	$R_{ER}$	Stored response in ER
$C1\left(p\right),C2\left(p\right),Cn\left(p\right)$	Partial challenge	$Re{s}_1,Re{s}_2,Re{s}_n$	MD’s generated response
$T_{st}$	Timestamp	$D{T}_1,D{T}_2,D{T}_n$	Health data
${\left(Y\right)}_E$	Y encrypted using E	$E\left(Y\right)$	Y decrypted using E
→	CRP generation	⟶	Data transfer
↦	ML model prediction	⊧	Model training
H	Hash operation	⊕	XOR operation
∈	Store operation	?	Validation checking
$\left|\right|$	Concatenation operation	×	Delete operation

shows the acronyms used in the proposed section.

• Medical Devices: The MDs are wearable devices used by patients on hospital premises. These MDs collect data from patients’ bodies for further analysis by doctors or other experts. Each MD is equipped with a PUF and also stores a unique challenge. The MDs are connected to the hospital network.
• Edge Router: The ER is the gateway of the hospital, which has enough processing power to handle multiple requests and perform many tasks at the same time. It is not a limited-resources device like an MD. It is responsible for network handling, maintaining MDs’ authentication processes, data masking, etc. Like MDs, it is also equipped with a PUF. Moreover, an ML model is stored in the ER to control the PUF.
• Cloud Server: The CS is the central element for making the decision and storing any kind of data. The CS stores the authentication parameters of the MDs. It is the only trusted element in the network. It is the most powerful device in the IoMT network. It is responsible for authenticating MDs and retrieving data. After the extraction of data, it stores the data in a secure database (SDB) through a secure channel. Moreover, the SDB stores the pseudoidentity ($PID$) of each MD and ERs. Furthermore, two ML models are stored in the SDB for authentication purposes.
  • PUF controlling model: The PUF used in the method is a controlled PUF or MC-PUF [45]. $PID$ and timestamp ($T_{st}$) are used as the input features, and the partial challenge is the output feature of the model. This ML model is stored in both the EG and the SDB. The model is called $M{C}_{model}$.
  • Device prediction model: This model is responsible for identifying the MDs. The CRPs of the group of MDs are collected and trained. The CRPs are the input features of the model and the MDs identity are the output feature. This model is stored in the SDB for identifying the $PID$s of the MDs. The model is named $M{L}_{model}$.

3.1. Assumptions

The following assumptions need to be considered for the successful deployment of the proposed group device authentication and data masking/retrieving operations.

• Each MD and the ER of the group need to be incorporated in the PUF module.
• The model which is stored in the ER for partially controlling the group of MDs is not modified.
• The ER is already authenticated prior to the MD group validation process.
• The stored challenge in the ER is updated periodically.
• The PUFs used are strong and reliable PUFs. The PUFs are not affected by noise and external parameters.
• The secure connection between the CS and the SDB is uninterrupted.
• No impact on CS and SDB is considered in the method.
• $ID$s, $PID$s, CRPs, and models are stored in the trusted SDB only.
• The group of MDs are enrolled at the same time. If any modification in the group is required, the model of the CS is updated. Moreover, the ER is updated with the required data of the new MD. After successful updating, the MD is included in the group.

The group of MDs’ authentication process is divided into two phases which are the enrollment phase and the authentication with data masking/retrieving phase. In the enrollment phase, both the group of MDs and the ER are enrolled in the network and necessary information is stored in the MDs, ER, and SDB. The successful training of ML models is done in the enrollment phase.

3.2. Edge Router Enrollment

Before placing the ER in the network of the hospital, it is registered to the IoMT network. The enrollment process of the ER is shown in Figure 5. The enrollment process is completed in a secure environment. The total enrollment phase is divided into two steps as shown in Algorithm 1.

• $M{C}_{model}$ training: The CS trains the $M{C}_{model}$ stored in the SDB. Moreover, it shares the model with the ER. After that, the ER receives the $PID$ and a secret response for each MD.
• Encryption of credentials: The ER first selects a secret challenge $C_{ER}$ and stores it. The incorporated PUF of the ER generates $R_{ER}$ using the challenge $C_{ER}$. The $R_{ER}$ is used as the encryption key to encrypt the $PID$s and the secret responses of the MDs. After encryption, the ER transfers the $R_{ER}$ to the CS for storing purposes in the SDB.

Algorithm 1 Edge router secure registration process.

Step 1: $M{C}_{model}$ training Server: $PID$, $T_{st}$, C⊧$M{C}_{model}$ Server ⟶ edge router {$(PI{D}_1,PI{D}_2,\cdots ,PI{D}_n)$, $(R{1}_n,R{2}_n,\cdots ,R{n}_n)$, $M{C}_{model}$} Step 2: Encryption of credentials Edge router:    ∈$M{C}_{model}$    PUF:       $C_{ER}$→$R_{ER}$    ${(PI{D}_1,R{1}_n,PI{D}_2,R{2}_n,\cdots ,PI{D}_n,R{n}_n)}_{R_{ER}}$=$SecK{y}_{ER}$    ∈$SecK{y}_{ER}$ Edge router ⟶ server {$R_{ER}$} Server ⟶ database {$R_{ER}$} Database:    ∈$R_{ER}$

3.3. Group of Medical Devices Enrollment

The group of MDs are enrolled at the same time and in a secure environment. Like the ER enrollment process, the group of MDs’ registration is also divided into two steps as shown in Algorithm 2. The whole enrollment process is presented in Figure 6.

• $M{C}_{model}$ Prediction and challenge collection: The stored $M{C}_{model}$ uses different timestamps and $PID$s to generate challenges for each MD. The different sets of challenges are sent to the different MDs.
• PUF response generation and $M{L}_{model}$ training: Each MD generates responses using the received set of challenges using the incorporated PUF in each MD. Each MD shares the set of CRPs with the CS. After receiving all the CRPs from each MD, the CS trains $M{L}_{model}$ and stores it in the SDB.

Algorithm 2 Secure registration process of a group of medical devices.

Step 1: $M{C}_{model}$ prediction and challenge collection Server:    $M{C}_{model}$:       $PID$, $T_{st}$↦C Server ⟶ device {C} Step 2: PUF response generation and $M{L}_{model}$ training IoMT device:    PUF:       C→R Device ⟶ server {C, R} Server:    C, R, $PID$⊧$M{L}_{model}$ Server ⟶ database {$M{L}_{model}$} Database:    ∈$M{L}_{model}$

3.4. Proposed Group Devices Authentication and Data Masking

Figure 7 shows the proposed method regarding group of MDs’ authentication and data masking/retrieving process. The total mechanism is divided into four steps as shown in Algorithm 3.

• Request for response generation: Authentication starts in the ER with the secret response generation by sending the stored challenge to the incorporated PUF in the ER. The ER uses the response to decrypt the stored secret message to find out the $PID$s of the group of MDs and the secret response of each MD. After this, the ER uses $M{C}_{model}$ to generate a partial challenge. $PID$ and $T_{st}$ act as input features of the model. A random nonce is concatenated with the partial challenge, then an XOR operation is performed with each secret response of each MD. The output of each XOR operation is shared with the corresponding MD.
• Response sharing by MDs: Each MD generates its secret response using the stored challenge. By performing an XOR operation, MDs get the partial challenge and random nonce. Each MD finds out the complete challenge by combining the received partial challenge from the ER and its own PID. The MDs generate the response using the PUF to validate the identity of the MD. The collected data and the random nonce are concatenated and an XOR operation is performed.
• Authentication request and data masking: The ER separates the responses and data using concatenation and an XOR operation using the nonce. The ER calculates $DT$ using $PID$s, completed challenges, and data. Here, XOR operations are performed to mask all the information. $HD$ is calculated by performing hash operations of partial challenges, the response of the ER, and data. Moreover, responses are concatenated to define $Res$ and the PIDs of all the MDs and the ER are calculated and a hash is made to find out $H_{PID}$. $DT$, $HD$, $Res$, and $H_{PID}$ are sent to the CS.
• Device authentication and retrieving data: After receiving a request from the ER, the CS runs the $M{C}_{model}$ to predict partial challenges like the ER and also calculates the complete challenges. Both challenges and responses act as input features of the $M{L}_{model}$ to predict the $PID$s to verify the identity. $H_{PID}$ is verified to complete the initial verification of the MDs and the ER. Using the challenges, $PID$s, and $DT$, the data of the MDs are extracted. The retrieved data are verified if the calculated $H{D}^{{}^{\prime }}$ matches the received $HD$. This completes the group of MDs’ authentication and data retrieving process.

Algorithm 3 Group of devices’ authentication and secure data transfer.

Step 1: Request for response generation Edge router:    PUF:       $C_{ER}$→$R_{ER}$    $(PI{D}_1,R{1}_n,PI{D}_2,R{2}_n,\cdots ,PI{D}_n,R{n}_n)$=$R_{ER}\left(SecK{y}_{ER}\right)$    $M{C}_{model}$:       $PID$, $T_{st}$↦$C1\left(p\right),C2\left(p\right),\cdots ,Cn\left(p\right)$    {$(R{1}_n\oplus \left(C1\left(p\right)\right||N_1\left)\right),(R{2}_n\oplus \left(C2\left(p\right)\right||N_1\left)\right),\cdots ,(R{n}_n\oplus \left(Cn\left(p\right)\right||N_1\left)\right)$} Edge router ⟶ IoMT device 1 {$(R{1}_n\oplus \left(C1\left(p\right)\right||N_1\left)\right)$} Edge router ⟶ IoMT device 2 {$(R{2}_n\oplus \left(C2\left(p\right)\right||N_1\left)\right)$} ........................................... Edge router ⟶ IoMT device n {$(R{n}_n\oplus \left(Cn\left(p\right)\right||N_1\left)\right)$} Step 2: Response sharing by MDs IoMT Device 1:    PUF:       $C{1}_n$→$R{1}_n$    $(R{1}_n\oplus \left(C1\left(p\right)\right||N_1\left)\right)\oplus R{1}_n=C1\left(p\right)\left|\right|N_1$    $C1\left(p\right)\left|\right|PI{D}_1=C_{n1}$    PUF:       $C_{n1}$→$Re{s}_1$ IoMT device 1 ⟶ edge router {$(Re{s}_1\left|\right|D{T}_1)\oplus N_1$} Step-3: Authentication request and data masking Edge router:    $\left(\right(PI{D}_1\left|\right|PI{D}_2\left|\right|\cdots \left|\right|PI{D}_n)\oplus (C_{n1}\left|\right|C_{n2}\left|\right|\cdots \left|\right|C_{nn})\oplus (D{T}_1\left|\right|D{T}_2\left|\right|\cdots \left|\right|D{T}_n\left)\right)=DT$    $H\left(C1\left(p\right)\right|\left|C2\left(p\right)\right||\cdots |\left|Cn\left(p\right)\right|\left|R_{ER}\right|\left|D{T}_1\right|\left|D{T}_2\right||\cdots |\left|D{T}_n\right)=HD$    $(Re{s}_1\left|\right|Re{s}_2\left|\right|\cdots \left|\right|Re{s}_n)\oplus R_{ER}=Res$    $H(PI{D}_{ER}\left|\right|PI{D}_1\left|\right|PI{D}_2\left|\right|\cdots \left|\right|PI{D}_n)=H_{PID}$ Edge router ⟶ Server {$DT,HD,Res,H_{PID}$} Step 4: Device authentication and retrieving data Server:    $M{C}_{model}$:       $PID$, $T_{st}$↦$C1\left(p\right),C2\left(p\right),\cdots ,Cn\left(p\right)$    $M{L}_{model}$:       C, $Res$↦$PID$ if  $H(PI{D}_{ER}\left|\right|PI{D}_1\left|\right|PI{D}_2\left|\right|\cdots \left|\right|PI{D}_n)==H_{PID}$  then    Initial verification of IoMT devices and edge router else    Invalid IoMT device and edge router end if    $\left(\right(PI{D}_1\left|\right|PI{D}_2\left|\right|\cdots \left|\right|PI{D}_n)\oplus (C_{n1}\left|\right|C_{n2}\left|\right|\cdots \left|\right|C_{nn})\oplus DT)=(D{T}_1\left|\right|D{T}_2\left|\right|\cdots \left|\right|D{T}_n)$    $H\left(C1\left(p\right)\right|\left|C2\left(p\right)\right||\cdots |\left|Cn\left(p\right)\right||R_{ER}\left|\right|D{T}_1\left|\right|D{T}_2\left|\right|\cdots \left|\right|D{T}_n)=H{D}^{{}^{\prime }}$ if  $HD==H{D}^{{}^{\prime }}$then    $\left(D{T}_1\right|\left|D{T}_2\right||\cdots |\left|D{T}_n\right)$ is actual IoMT data else    Invalid IoMT data end if

3.5. Encryption Key Update Process of the Edge Router

To avoid exposure to the secret response, the proposed framework uses periodic updates of the secret key. The encryption key update process is shown in Figure 8. The key-changing process is divided into two steps which are presented in Algorithm 4.

• New secret key generation: The ER selects a new challenge $C_{ER\left(new\right)}$ and generates response $R_{ER\left(new\right)}$ using the PUF. It decrypts the stored message using the previous secret response and encrypts it again using the new generated response.
• Updating secret key: The ER uses the XOR operation between $R_{ER\left(new\right)}$ and $R_{ER}$ and transfers the result to the CS using a public channel. After receiving the message, the CS uses the XOR operation to get the new secret key of the ER and stores it in the SDB.

Algorithm 4 Edge router encryption key update process.

Step 1: New secret key generation Edge router:    $C_{ER\left(new\right)}$→$R_{ER\left(new\right)}$    $(PI{D}_1,R{1}_n,PI{D}_2,R{2}_n,\cdots ,PI{D}_n,R{n}_n)$=$R_{ER}\left(SecK{y}_{ER}\right)$    ${(PI{D}_1,R{1}_n,PI{D}_2,R{2}_n,\cdots ,PI{D}_n,R{n}_n)}_{R_{ER\left(new\right)}}$=$SecK{y}_{ER\left(new\right)}$    ∈$SecK{y}_{ER\left(new\right)}$ Step 2: Updating secret key Edge router:    $R_{ER}$⊕$R_{ER\left(new\right)}$ = $R_{new}$ Edge router ⟶ server {$R_{new}$} Server:    $R_{new}$⊕$R_{ER}$ = $R_{ER\left(new\right)}$ Server ⟶ database {$R_{ER\left(new\right)}$} Database:    ×$R_{ER}$    ∈$R_{ER\left(new\right)}$

4. Results

The proposed framework used a Raspberry Pi 4 model B, Xilinx PYNQ Z2 FPGA, Xilinx BASYS 3 FPGA, and a Jupyter notebook. The scheme used a 64-bit arbiter PUF which was deployed in both FPGAs. Figure 9 shows the experimental setup of the proposed framework. In the experimental setup, one FPGA was connected to a Raspberry Pi to make an MD or an ER. On the other hand, a standalone Raspberry Pi acted as a CS. At first, the model $M{C}_{model}$ was trained and predicted the challenges of PUFs of MDs [45]. The challenges were used in the PUFs of the FPGAs and the connected Raspberry Pis collected the responses. For example, if the predicted challenges were received for MD1, the challenges were placed in the Raspberry Pi. Tx/Rx ports were connected to the Rx/Tx ports of the FPGA, which were defined in the constraints file of the PUF. The baud rate in the Raspberry Pi should be selected as the baud rate used in the PUF to define clocks per bit. By sending challenges to the FPGA from the Raspberry Pi, the PUF generated responses and the Raspberry Pi collected the responses from the Rx port. Following these steps, the responses from the group of MDs and the ER were collected. Using the CRPs, the model $M{L}_{model}$ was generated.

4.1. Machine Learning Performance

In the proposed framework, five MDs were used in the group. From each MD’s PUF, 487,940 CRPs were collected. All the CRPs from five MDs were used to prepare the dataset. In the dataset, a total of 2,439,700 CRPs were present. To train the model, 80% of the dataset was used as training data, and 20% of the data were used for validation. No separate data were kept for testing as there were no novel data for testing. The whole dataset was used for testing when the training was done. In the training, 16 input features were considered and one output feature. Each byte of the CRP acted as an input feature, and the $PID$ was used as the output feature. It was a multiclass classification as there were five categories ($PID$) in the output feature; categorical cross-entropy was the loss function, and the regularizer L2 (0.1) was also applied. For the optimizers AdaDelta and AdaGrad, the model did not show good performance. Optimizer Nadam showed better results than AdaDelta, but the accuracy was not as good as the Adam optimizer.

Table 3. $M{L}_{model}$ performance of different models.

Units	Z-Score	Activation Function	Optimizer	Validation Accuracy
512-4096-4096-2048-1204	✗	ReLU	Adam	81.39
512-4096-4096-2048-1204	✓	ReLU	RMSProp	97.35
512-1024-1024-512-248	✗	ReLU	RMSProp	96.55
512-1024-1024-512-248	✓	ReLU	RMSProp	96.7
512-1024-1024-512-248	✓	ReLU	Adam	98.2
512-1024-1024-512-248	✓	ReLU	Nadam	96.65
512-4096-4096-2048-1204	✓	tanh	RMSProp	97.35
512-2048-1024-512	✓	ReLU	RMSProp	97.58
512-2048-1024-512	✓	ReLU	Adam	94.97
512-2048-1024-512	✓	tanh	Adam	97.9
512-2048-1024-512	✓	tanh	RMSProp	97.48

shows the performance of the $M{L}_{model}$ for different combinations. Each model was run for 50 epochs with batch size 5000. A few models also showed some fluctuations in their accuracy.

The best performance was found for 512-4096-4096-2048-1204 units, a ReLU activation function, and the Adam optimizer as shown in Figure 10. Moreover, a Z-score was applied to the model. The training accuracy was 99.46%, and the validation accuracy was 98.55%. While testing the whole dataset using the model, it showed 99.54% accuracy.

4.2. Computation Cost

The proposed framework is for medical devices which are resource-constrained devices. Complexity or much time consumed in operations will raise the burden on such devices. The operations performed during the authentication are lightweight and not resource hungry. The time required for completing XOR and concatenation operations is negligible and can be avoided [32]. The standard time for performing operations that are required in the proposed framework is presented in

Table 4. Computation cost of the proposed framework for single MD in a group.

Notation	Description	Computation Time	MD Times	ER Times	CS Times	Total	Total Time
$T_h$	Hash operation [46]	0.0234 ms	0	2	2	4	0.0936 ms
$T_R$	PUF response [46]	0.4 $\mathsf{\mu }$s	2	2	0	4	0.0016 ms
$T_D$	Decryption [47]	0.14 ms	0	1	0	1	0.14 ms
$T_M$	Model prediction [48]	0.75 ms	0	1	2	3	2.25 ms

. In the proposed scheme, four hash operations, four PUF responses, one message decryption, and three model predictions are required. Among these operations, the MD is required to perform the PUF response generation twice, which is negligible, as shown in Table 4. If there is a single MD in a group, the computation time to complete the process is 2.6 ms ($4\ast T_h+4\ast T_R+1\ast T_D+3\ast T_M$).

In Figure 11, it can be seen that the computational cost decreases comparatively if the number of devices is increased in the group. For the addition of an MD in a group, only the server needs to additionally predict $M{L}_{model}$ one more time. Each MD’s addition only adds 0.75 ms of computation time and the equation of the computation cost for n number of MDs is $T_{Computation}=(1.85+n\times 0.75)$ ms.

In the CRP update process in the ER, the computation cost is approximately 0.37 ms $(1\times T_E+1\times T_D)$ [47].

4.3. Communication Overhead

A single message to the CS is required to complete the authentication and data-sharing process. The CS needs not send any information in the proposed framework. Figure 12 shows the total communication cost of the proposed framework for an MD in a group. The communication overhead of an MD in a group is 104 bytes. For calculating the communication overhead, C, R, and $PID$ are considered as having 64 bits. The hash output has 256 bits. The communication overhead is changed based on the selection of the lengths of the parameters. It can be seen that step 3 is having more overhead compared to the other steps as the step is sending multiple data after performing hash operations.

Figure 13 shows the trend of communication overhead with the increment of MDs in the group. It can be seen that only 40 bytes are required to transmit for the addition of each MD, and the equation of the communication cost is $B_{Communication}=(64+40\times n)$.

The communication overhead in the CRP update process in the ER is eight bytes, as the ER only sends the response after performing an XOR operation.

4.4. Performance Comparison

Figure 14 shows the performance comparison of the proposed framework with respect to computation cost. The figure shows that the proposed method needs less computational resources than other methods. Moreover, other authentication frameworks follow a linear pattern to complete the authentication of more than one device. However, the proposed framework takes less time onward.

Communication overhead comparison is presented by Figure 15. The figure depicts that the proposed framework puts less burden to the transmission medium than other existing methods. Moreover, the proposed mechanism will not follow a linear pattern like others for multiple devices authentication.

5. Security Proof

In this section, how the proposed authentication is comparatively more feasible than other existing methods for an IoMT application is presented. Security resistance against known attacks is discussed using both formal and informal ways.

5.1. Formal Security Proof

In this part, the Burrows–Abadi–Needham (BAN) logic is used to show the proposed group MDs’ authentication method’s formal security proof [49].

5.1.1. Notations

Each interference presented by the BAN logic is organized in accordance with its relevance using the basic notations and corresponding descriptions. The following expressions are used:

• P believes X (P |≡ X): P either believes or has the ability to think that the formula X is true.
• P sees X (P ◃ X): P either already believes or has a substantial basis for believing that the phrase X is true.
• P once sent X (P |∼ X): Although object P has already sent a message containing statement X, it is unclear if the information was sent there at the time of the process or in the past. However, in this instance, it is clear that P believes X.
• Fresh X (#(X)): communication X is regarded as new because it has not been addressed before the current transmission period.
• P has complete control over X (P ${}_{\Rightarrow }^{◃}$X): this happens when P has entire authority over function X and it is used in accordance with the authority’s instructions.
• Secret key between P and Q (P ${}_{\rightleftharpoons }^X$ Q): this implies that only P and Q are aware of the secret code or methods X.

5.1.2. Inference Rules

In the BAN logic, there are several sets of inference rules with the preceding remarks:

∘

${IR}_1$: <Nonce-Verification Rule>

$$\begin{array}{c}\hfill \frac{P|\equiv \#(X),P|\equiv Q|\equiv |\sim X}{P|\equiv Q|\equiv X}\end{array}$$

∘

${IR}_2$: <Jurisdiction Rule>

$$\begin{array}{c}\hfill \frac{P|\equiv P\Rightarrow X,P|\equiv Q|\equiv X}{P|\equiv X}\end{array}$$

∘

${IR}_3$: <Key Freshness Rule>

$$\begin{array}{c}\hfill \frac{P|\equiv \#(X)}{P|\equiv \#(X,Y)}\end{array}$$

∘

${IR}_4$: <Shared Key Rule>

$$\begin{array}{c}\hfill \frac{P|\equiv Q\stackrel{K}{\leftrightarrow }P,P◃{\left\{X\right\}}_K}{P|\equiv Q|\sim X}\end{array}$$

∘

${IR}_5$: <Secret Key Sharing Rule>

$$\begin{array}{c}\hfill \frac{P|\equiv Q|\equiv R\stackrel{K}{\rightleftharpoons }{R}^{{}^{\prime }}}{P|\equiv Q|\equiv R^{{}^{\prime }}\stackrel{K}{\rightleftharpoons }R}\end{array}$$

5.1.3. Initial Assumptions

The following propositions are taken into consideration when evaluating the security attribute of mutual authentication:

∘

$A_1$: CS |≡ CS ${}_{\rightleftharpoons }^{M{C}_{model}}$ ER

∘

$A_2$: MD1 |≡ CS ${}_{\rightleftharpoons }^{M{C}_{model}}$ ER

∘

$A_3$: CS |≡ CS ${}_{\rightleftharpoons }^{M{L}_{model}}$ MD1

∘

$A_4$: MD1 |≡ CS ${}_{\rightleftharpoons }^{M{L}_{model}}$ MD1

∘

$A_5$: ER |≡ ER ${}_{\rightleftharpoons }^{R{1}_n}$ MD1

∘

$A_6$: MD1 |≡ ER ${}_{\rightleftharpoons }^{R{1}_n}$ MD1

∘

$A_7$: CS |≡ CS ${}_{\rightleftharpoons }^{R_{ER}}$ ER

∘

$A_8$: ER |≡ CS ${}_{\rightleftharpoons }^{R_{ER}}$ ER

5.1.4. Idealized Form

The idealized structure of the presented framework’s messages is as follows:

∘

$I_1$: ER → MD1: {$R{1}_n$, $C1\left(p\right)$, $N_1$ #($N_1$, $C1\left(p\right)$)}

∘

$I_2$: MD1 → ER: {$Re{s}_1$, $D{T}_1$, $N_1$ #($Re{s}_1$, $D{T}_1$)}

∘

$I_1$: ER → CS: {$Re{s}_1$, $R_{ER}$, $PI{D}_1$, $PI{D}_{ER}$, $C1\left(p\right)$, $C_{n1}$, $D{T}_1$, #($R_{ER}$, $Re{s}_1$, $C_{n1}$, $C1\left(p\right)$)}

5.1.5. Goals of Proposed Framework

In order to have successful authentication, the following requirements must be met:

∘

$G_1$: ER |≡ MD1 |≡<ER ${}_{⟷}^{R{1}_n}$ MD1>

∘

$G_2$: CS |≡ MD1 |≡<CS ${}_{⟷}^{Re{s}_1}$ MD1>

5.1.6. Formal Verification Proof

We now use the preceding inference techniques, idealized form, and objectives to evaluate the framework’s MD authentication procedure.

∘

${FV}_1$: from $I_1$ and by practicing ${IR}_1$, ${IR}_2$ and ${IR}_3$, it is desired to obtain (1) and achieve goal $G_1$:

$$\begin{array}{c}\hfill \frac{MD1|\equiv \#<N_1,C1\left(p\right)>,MD1|\equiv ER|\equiv \#(N_1,C1\left(p\right)),MD1|\equiv ER\Rightarrow \left(R{1}_n\right),MD1|\equiv ER|\equiv \left(R{1}_n\right)}{MD1|\equiv \#(N_1,C1\left(p\right),R{1}_n),MD1|\equiv \left(R{1}_n\right)}\end{array}$$

(1)

∘

${FV}_2$: from $I_1$ and by practicing ${IR}_1$, ${IR}_3$ and ${IR}_5$, it is desired to obtain (2):

$$\begin{array}{c}\hfill \frac{ER|\equiv \#(Re{s}_1,D{T}_1),ER|\equiv MD{1}_{\rightleftharpoons }^{Re{s}_1}CS,ER|\equiv \sim \left(N_1\right)}{ER|\equiv \#(Re{s}_1,D{T}_1,N_1),ER|\equiv CS|\sim Re{s}_1}\end{array}$$

(2)

∘

${FV}_3$: from $I_3$ and by practicing ${IR}_1$, ${IR}_3$, and ${IR}_5$, it is desired to obtain (3) and achieve goal $G_2$:

$$\begin{array}{c}\hfill \frac{CS|\equiv \#(R_{ER},C_{n1},D{T}_1),CS|\equiv M{D}_{\rightleftharpoons }^{Re{s}_1}CS,CS|\equiv M{D}_{\rightleftharpoons }^{R_{ER}}CS,CS|\equiv ER|\equiv \sim (PI{D}_1,PI{D}_{ER})}{CS|\equiv \#(PI{D}_1,PI{D}_{ER},D{T}_1,R_{ER},Re{s}_1,C_{n1},C1\left(p\right)),CS|\equiv M{D}_{\rightleftharpoons }^{R_{ER}}CS,CS|\equiv M{D}_{\rightleftharpoons }^{Re{s}_1}CS}\end{array}$$

(3)

5.2. Informal Security Proof

This section demonstrates how the developed authentication system can implement security measures when taking into account the capacity of an adversary to alter and listen in on the sent data through public networks.

5.2.1. Impersonation Attacks

The proposed framework can resist MD, ER, and CS impersonation attacks. An adversary can try to act as an MD to alter or provide false data. To act as a valid MD, an attacker needs to generate the correct response of a challenge. However, the ER is responsible for providing a partial challenge. Therefore, it is not possible to impersonate an MD. To impersonate the ER, an attacker needs to get the secret responses of the MDs. An attacker can only get the secret response if they can get the decryption key. Moreover, the secret encryption key is updated periodically, which defends against the theft of the encryption key. Furthermore, the information of the MDs is not stored in plaintext but rather formed in a model. Moreover, the server is not requested to provide data in the framework. Therefore, it can be said that the proposed framework can resist impersonation attacks.

5.2.2. Side-Channel Attacks

Side-channel attacks are usually performed by measuring computation time, power analysis, etc., operations. Moreover, secret keys stored in the memory of the devices raise the chance to be affected by side-channel attacks [27]. To avoid this, a PUF was used to generate the responses. In the proposed method, an XOR operation was used to fabricate the response using random health data and a random nonce, which was not stored in the memory of the device nor used further by the MD.

5.2.3. Modeling Attacks

In modeling attacks, an adversary tries to grab the pattern of secret keys to build a model to predict the next keys/responses of the MD to disrupt the system. It is possible to resist modeling attacks to protect the CRP interface. By providing an additional block, hash function, etc., it is also possible to mask the interface [50]. The proposed method used $M{C}_{model}$ to generate a partial response which was completed by the MD itself and the challenge was not going out. Furthermore, the generated response was also masked before sending to the ER. Thus, the proposed scheme is able to resist modeling attacks. Figure 16 shows the process of hiding the challenge.

5.2.4. Physical Attacks

Physical attacks can be conducted by accessing the secret keys from the devices’ memory. If there is any attempt by an adversary to tamper with the PUF-based device, then the device will be damaged, and it will generate incorrect responses [39]. Moreover, neither challenges nor responses are stored in the devices. Thus, it can be said the framework is not affected by physical attacks.

5.2.5. Dos Attacks

An attacker can try to perform a DoS attack so that the regular service of the node is interrupted, and the device could go out of service. In this attack, the adversary tries to consume the limited resources of the device. To avoid this attack, the MD is able to understand whether the authentication request is from the legitimate ER by checking $R{1}_n$. If it does not match, it does not process the authentication request, and the PUF response generation is not a time- or resource-consuming operation. The proposed method manages a gray list for such kinds of requests to avoid DoS attacks.

5.2.6. Replay Attack

A replay attack is when an attacker sends repeated or falsely delayed lawful data transmission. Replay attacks can be resisted by using clock synchronization or a random nonce method. Li et al. [51] stated that clock synchronization is still an open research area for communication in a wireless sensor network. This paper adopted a random nonce $N_1$, a random challenge, a random response, etc., in each message to defend against replay attacks. When all of these factors are taken into account, it can be said that the proposed solution can block replay attacks by employing random numbers, and its effectiveness is unaffected by clock synchronization issues.

5.2.7. Eavesdropping Attack

Due to the distinctive characteristics of each PUF, the CRP ensures that only the legitimate device and server can interact with one another. Because the server stores only the model throughout the enrollment process, and the server has no information about the responses, eavesdroppers cannot replicate it without having access to the model and CRPs [52].

5.2.8. Man-in-the-Middle Attack

Each time, different responses are generated based on masked or partial challenges from the ER. The generated response is also masked using $DT$ and nonce. Moreover, the ER uses hash operations to mask all the collected responses and data from all the MDs of the group. Both the MDs and the ER generate random messages to prevent man-in-the-middle (MITM) attacks. Therefore, inside intruders do not have a chance to execute a MITM assault unless they are familiar with CRPs, XOR functions, and random nonces [52].

5.2.9. Anonymous Identity

To avoid exposing the real identity of a node, pseudoidentity is used instead of the original ID. The uses of $PID$ are resistant to attackers who try to identify the original owner of the device. Furthermore, it is not shared in plaintext. The proposed framework can preserve privacy by maintaining an anonymous identity.

5.2.10. Forward Secrecy

Forward secrecy’s primary goal is to guarantee that previously established transaction keys remain safe in the event that the keys are compromised. In the proposed framework, MDs do not use any prestored key to authenticate the device. The MDs generate responses where challenges are decided by the partial challenge and $PID$s by steps 1 and 2. Moreover, the response is masked using nonce and MD data, which are random as shown in step 2. Therefore, the secret key cannot be identified without the random numbers. Furthermore, for the next time authentication and data masking, different challenges, responses, nonce, data, etc., will be used, which keeps the forward secrecy.

The discussion has illustrated that the proposed group of medical devices’ authentication framework is resilient to known security threats.

6. Conclusions and Future Directions

Patients in a hospital pass a crucial time in their life. The diagnosis and treatment should be provided in an accurate manner as per the direction of doctors and experts. The IoMT is making the treatment process timelier, which helps patients, doctors, nurses, etc. However, the process could backfire and even could cause the death of patients if the IoMT data were fabricated. To ensure patients’ safety, secure communication is a must for the IoMT system. To protect the security of the IoMT system in a hospital environment in a smart city, the paper proposed an authentication framework where a group of devices were authenticated in a single message transmission. Moreover, the devices did not need to send health data separately; the data could be sent in the authentication request. The proposed framework showed a better resistance against security attacks compared to the state-of-the-art methods. The proposed framework is lightweight, and a low communication cost is required with respect to other works. In the future, federated learning along with blockchain will be incorporated to introduce more security features. Furthermore, group key agreement will be considered to make the proposed framework feasible for mobile applications.