Authentication in the Internet of Medical Things

Authentication in the Internet of Medical Things: Comparison

Please note this is a comparison between Version 1 by Norah Alsaeed and Version 2 by Lindsay Dong.

The Internet of Medical Things (IoMT) has revolutionized the world of healthcare by remotely connecting patients to healthcare providers through medical devices connected over the Internet. IoMT devices collect patients’ medical data and share them with healthcare providers, who analyze it for early control of diseases. The security of patients’ data is of prime importance in IoMT. Authentication of users and devices is the first layer of security in IoMT.

Internet of Medical Things
security requirements
IoMT authentication scheme

1. Introduction

The current COVID-19 epidemic has again highlighted the importance of smart healthcare services that offer prevention, diagnosis, and treatment at a distance. Smart healthcare is not simply a technology improvement rather it provides multi-level and global changes in the healthcare arena. The smart healthcare is built around emerging technologies, such as cloud computing, Internet of Things (IoT), machine learning, and big data [1]. IoT has become an essential component to fulfill the connectivity requirements of the current smart healthcare systems. IoT, in the healthcare context, is called the Internet of Medical Things (IoMT). IoMT comprises medical devices connected to patients to sense their medical parameters and share that information with healthcare staff so that they may provide remote healthcare services. The IoMT security is an imperative need worthy of more research due to the need to safeguard the patient’s sensitive information from exploitation [2]. To avoid such exploitation, and to ensure a high level of security, IoMT applications must maintain strict authentication schemes that prevent unauthorized access to patients’ data, as well as the IoMT resources, and protect the entire system from various types of attacks ^[3][4][3,4]. Developing a strict authentication scheme within the IoMT context is challenging for three main reasons. First, IoMT devices are resource-constrained and cannot handle intensive computational and complex authentication procedures. Second, various IoMT products and vendors work through different platforms and protocols. Consequently, developing strict authentication requires deep knowledge of how different products, platforms, and protocols collectively work. Third, highly distributed IoMT devices that share medical data through the Internet make IoMT systems intrinsically prone to security violations.

1.1. Smart Healthcare

The evolution of technologies contributes to the high quality of services in the healthcare sector as patients receive faster and more personalized services ^[5][17]. Smart healthcare, or healthcare 4.0, is an intelligent healthcare asset that uses sensing devices to gather medical data, network devices to transmit data, and an advanced infrastructure to process, store, and display that data for enhancing healthcare services. In summary, smart healthcare involves the use of cutting-edge technologies to increase the effectiveness of medical assistance and, where possible, to decrease healthcare costs. Smart healthcare provides significant capabilities, such as continuous interaction between all the relevant parties in healthcare, helping the healthcare providers make knowledgeable decisions, and supporting the dynamic allocation of healthcare resources. In short, today’s healthcare services need to be personalized and available anytime, anywhere, and for everyone. This goal is met through smart healthcare [1].

1.2. IoT in Smart Healthcare

In its basic form, IoT connects physical objects to the Internet to perform related activities remotely. This connection provided features such as context-awareness capabilities, autonomous data capture, and on-line communication facilities for a specific purpose. In particular, IoMT refers to smart medical devices connected via the Internet to a central entity, usually a cloud, to automatically gather, process, and share medical data for healthcare services ^[6][18]. Smart healthcare requires the IoT paradigm to provide solutions that can capture patients’ health parameters, recognize symptoms, and thus recommend preventive actions. On the other hand, IoMT applications help the healthcare industry to design and develop new medical solutions based on big data analytics that use the data generated from IoMT devices, and to take other knowledge-based measures as needed. Patients, healthcare providers, such as doctors, nurses, pharmacists, physicians, and hospitals, as well as insurance companies, can benefit directly or indirectly from IoMT applications. IoMT applications are helpful for many healthcare areas, such as remote healthcare services, medical asset management, optimization of medical inventory, patient-doctor rapport, real-time medical data analytics, augmented surgeries, and treatment [4].

1.3. IoMT Context

This section presents the overall context of IoMT systems. It includes the IoMT system architecture and the way its layers are integrated to perform tasks remotely. Moreover, the IoMT context discusses some applications related to IoMT systems. At the end, it briefly classifies the IoMT devices and describes their functions.

12.3.1. IoMT Architecture

Figure 1 illustrates the IoMT layers. The IoMT architecture operates mainly through four layers ^[7][19], as described below.

Figure 1.

IoMT system architecture.

1.3.2. IoMT Applications

With rapid technological advancement, the various IoMT applications are exponentially increasing. Hundreds of applications are available for IoMT systems. These applications can be categorized as shown in

Figure 2

[4]:

Figure 2. IoMT applications.

1.3.3. IoMT Devices

D. Hemanth et al. ^[7] classified IoMT devices according to their position, such as in-community, in-hospital, in-clinic, in-home, and onbody devices. In this paper, IoMT devices are classified according to their distance from patients, as shown in

D. Hemanth et al. [19] classified IoMT devices according to their position, such as in-community, in-hospital, in-clinic, in-home, and onbody devices. In this paper, IoMT devices are classified according to their distance from patients, as shown in

Figure 3 ^[8][9][10]:

[21,22,23]:

Figure 3. IoMT devices.

1.4. IoMT Security Requirements

2.4. IoMT Security Requirements

The security requirements of the IoMT are divided into three levels: information security, function security, and access control, as illustrated in

Figure 4

. It is worth mentioning that the security requirements are interlinked and affected by each other [3]. The security requirements at these three levels are described as is detailed in the following section.

Figure 4. Levels of security requirements.

2. IoMT Authentication Taxonomy

4. IoMT Authentication Taxonomy

IoMT authentication can be viewed from different perspectives.

Figure 5 illustrates the IoMT authentication taxonomy’s perspectives: authentication levels, architectures, credentials, procedures, categories, schemes, and preventing attacks. The perspectives are described in the following sections.

7 illustrates the IoMT authentication taxonomy’s perspectives: authentication levels, architectures, credentials, procedures, categories, schemes, and preventing attacks. The perspectives are described in the following sections.

/media/item_content/202209/6334eca8df5dcapplsci-12-07487-g007.png

Figure 57. Taxonomy of authentication in IoMT.

2.1. Authentication Levels

4.1. Authentication Levels

Because IoMT systems are complex and distributed, it is challenging to propose generic authentication solutions for various IoMT systems nodes. Therefore, IoMT authentication is primarily considered at three levels: device-level, user-level, and network-level, as shown in

Figure 6.

Figure 68. Authentication levels.

2.2. Authentication Architectures

4.2. Authentication Architectures

Authentication in IoMT systems depends on either a centralized or decentralized architecture. Centralized authentication requires a centralized server to identify and authenticate the system entities. In contrast, the distributed architecture depends on multiple distributed nodes to accomplish the authentication process. Both the centralized and distributed architecture can be a flat or multi-level architecture. The flat architecture means the nodes are authenticated by authentication servers with the same roles. In a multi-level architecture, the authentication process is performed by authentication servers with different roles, according to their level of communication. That implies that the server at the lower level is used for authenticating nodes at the lower level.

Figure 7 shows the authentication architectures for IoMT systems.

9 shows the authentication architectures for IoMT systems.

Figure 79. Authentication architectures.

2.3. Authentication Credentials

4.3. Authentication Credentials

The authentication process asks for unique credentials from the entities to allow them to access the IoMT systems. This process can be performed through a third, trusted, party or directly between the communicating entities. Whatever the credentials used, it is necessary to consider their uniqueness, universality, and storability ^[11]. The credentials required for authentication are classified into four categories ^[12]. These types are depicted in

The authentication process asks for unique credentials from the entities to allow them to access the IoMT systems. This process can be performed through a third, trusted, party or directly between the communicating entities. Whatever the credentials used, it is necessary to consider their uniqueness, universality, and storability [60]. The credentials required for authentication are classified into four categories [61]. These types are depicted in

Figure 8.

10.

Figure 810. Authentication credentials.

2.4. Authentication Procedures

4.4. Authentication Procedures

The authentication in IoMT systems can be classified based on the direction of authenticating entities. The authentication procedure in the IoMT system can be one-way, two-way, and three-way ^[13].

The authentication in IoMT systems can be classified based on the direction of authenticating entities. The authentication procedure in the IoMT system can be one-way, two-way, and three-way [7].

Figure 9 shows the authentication procedure in the IoMT system.

11 shows the authentication procedure in the IoMT system.

Figure 911. Authentication procedures.

2.5. Authentication Categories

4.5. Authentication Categories

The IoMT systems need a continuous feed of data from IoMT to look after the patient’s situation. Accordingly, the IoMT systems need to authenticate those devices for a long period of time. IoMT authentication is classified into continuous and static from that perspective shown in

Figure 10.

Figure 102. Authentication categories.

2.6. Authentication Schemes

4.6. Authentication Schemes

Authentication in IoMT systems can depend on a basic, key-based, certificate-based, or cryptography-based scheme. Researchers have recently adopted hybrid schemes to improve system performance and security.

Figure 11 shows a classification of authentication schemes.

3 shows a classification of authentication schemes.

Figure 113. Authentication schemes.

2.6.1. Basic Authentication

4.6.1. Basic Authentication

In basic authentication, the credentials used to authenticate an entity are the factors used to identify that entity. The accuracy and efficiency of the authentication schemes will rely on how many factors are required to perform the authentication process.

Figure 12 shows a classification of authentication schemes according to the number of factors involved in identifying entities for the IoMT systems. Usually, two factors are used for basic authentication; entities need to provide identification data and biometric information to access the IoMT system ^[14][15]. To enhance the security and make the problem of authentication harder for adversaries to compromise, many schemes depend on three factors by combining knowledge, inheritance, and possession credentials ^{[16][17][18][19][20][21]}.

4 shows a classification of authentication schemes according to the number of factors involved in identifying entities for the IoMT systems. Usually, two factors are used for basic authentication; entities need to provide identification data and biometric information to access the IoMT system [50,72]. To enhance the security and make the problem of authentication harder for adversaries to compromise, many schemes depend on three factors by combining knowledge, inheritance, and possession credentials [53,54,88,102,103,104].

Figure 124. Basic Authentication.

2.6.2. Authentication and Key Agreement

4.6.2. Authentication and Key Agreement

IoMT authentication can be achieved by creating a key shared between the communicating entities to ensure secure communication. Authentication protocols can adopt a simple key agreement where two entities negotiate upon a key to secure their communication ^[22][23]. G. Mwitende et al. ^[24] proposed a key agreement between two entities with a blind signing mechanism based on blockchain technology. On the other hand, authentication protocols can adopt a group key agreement ^[25][26]. Group-key agreement protocols require more than two entities to generate a group-key such that anyone of these entities can use it for communication ^[24].

IoMT authentication can be achieved by creating a key shared between the communicating entities to ensure secure communication. Authentication protocols can adopt a simple key agreement where two entities negotiate upon a key to secure their communication [98,99]. G. Mwitende et al. [105] proposed a key agreement between two entities with a blind signing mechanism based on blockchain technology. On the other hand, authentication protocols can adopt a group key agreement [106,107]. Group-key agreement protocols require more than two entities to generate a group-key such that anyone of these entities can use it for communication [105].

Figure 13a shows the key agreement classification.

5a shows the key agreement classification.

Figure 135. (a,b) Key agreement scheme.

2.6.3. Certificate-Based Authentication

4.6.3. Certificate-Based Authentication

The authentication schema in IoMT can depend on using a certificate to identify legitimate entities. Accordingly, authentication schemes may require a hard certificate, soft certificate, implicit certificate, or no certificate for identifying entities, see

Figure 14. Most of the authentication literature in the IoMT environment suggests a hard certificate to accomplish the authentication process. A smart card is a hard certificate used to authenticate users in the IoMT system ^[27][28]. Similarly, an RFID chip is used to authenticate IoMT devices uniquely by providing it as a device identifier ^{[29][30][31][32]}. A hard certificate also requires to be validated and signed by a reliable party. The second type of certificate is a soft certificate, or a digital certificate that refers to a token that requires to be validated by a reliable party ^[33][34]. The reliable party is called a certificate authority (CA) or a delegated entity.

6. Most of the authentication literature in the IoMT environment suggests a hard certificate to accomplish the authentication process. A smart card is a hard certificate used to authenticate users in the IoMT system [73,92]. Similarly, an RFID chip is used to authenticate IoMT devices uniquely by providing it as a device identifier [25,44,45,46]. A hard certificate also requires to be validated and signed by a reliable party. The second type of certificate is a soft certificate, or a digital certificate that refers to a token that requires to be validated by a reliable party [111,112]. The reliable party is called a certificate authority (CA) or a delegated entity.

Figure 146. Certificate-based authentication.

2.6.4. Cryptography-Based Authentication

4.6.4. Cryptography-Based Authentication

Currently, cryptography is an essential part of authentication, and various cryptography techniques offer a good opportunity to empower IoMT security.