RAMHU: A New Robust Lightweight Scheme for Mutual Users Authentication in Healthcare Applications

TL;DR

RAMHU is a novel lightweight authentication scheme designed for healthcare applications, ensuring mutual security between users and servers by leveraging device and user information, elliptic curve encryption, and formal security analysis.

Contribution

The paper introduces RAMHU, a new mutual authentication model combining elliptic curve encryption, pseudonyms, and one-time passwords for enhanced healthcare data security.

Findings

Provides strong security against various attacks.

Achieves good performance with ECIES and PHOTON.

Validated using AVISPA security analysis tool.

Abstract

Providing a mechanism to authenticate users in healthcare applications is an essential security requirement to prevent both external and internal attackers from penetrating patients' identities and revealing their health data. Many schemes have been developed to provide authentication mechanisms to ensure that only legitimate users are authorized to connect, but these schemes still suffer from vulnerable security. Various attacks expose patients' data for malicious tampering or destruction. Transferring health-related data and information between users and the health centre makes them exposed to penetration by adversaries as they may move through an insecure channel. In addition, previous mechanisms have suffered from the poor protection of users' authentication information. To ensure the protection of patients' information and data, we propose a scheme that authenticates users based on the information of both the device and the legitimate user. In this paper, we propose a Robust Authentication Model for Healthcare Users (RAMHU) that provides mutual authentication between server and clients. This model utilizes an Elliptic Curve Integrated Encryption Scheme (ECIES) and PHOTON to achieve strong security and a good overall performance. RAMHU relies on multi pseudonyms, physical address, and one-time password mechanisms to authenticate legitimate users. Moreover, extensive informal and formal security analysis with the automated validation of Internet security protocols and applications (AVISPA) tool demonstrates that our model offers a high level of security in repelling a wide variety of possible attacks.

Tables

Table 1. Table 1: keys sizes and some information for asymmetric algorithms

Algo.	Keys sizes					Ratio	Author(s)	Year	Mathmatical problem
RSA							Rivest, Shamirand, and Adleman	1978	Integer factorization
Elgamal	1024	2048	3072	7680	15360		Taher Elgamal	1985	Multiplicative group
ECIES	160-223	224-255	256-383	384-511	512-more	1:6-30	Neal Koblitz, and Victor Miller	1985	Elliptic curve discrete log. (ECDLP)

Table 2. Table 2: Comparison of lightweight hash function algorithms

	Performace			Security
Algorithm	Gate equivalent area	Throughput (kbps)	MD	PR	SPR	CR	Author (s)	Year
SQUASH	2646 GE	0.15	64	64	64	0	Shamir	2005
MAME	8100 GE	146.7	256	-	-	-	Yoshida et al.	2007
C-PRESENT-192	8048 GE	59.26	192	192	192	96	Bogdanov et al.	2008
ARMADILLO2	8653 GE	9.38	256	256	256	128	Bald et al.	2010
S-QUARK	2296 GE	3.13	256	224	112	112	Aumasson et al.	2010
KECCAK-f[400]	5090 GE	14.4	128	128	128	64	Kavun and Yalcin	2010
GLUON	4724 GE	32	224	224	112	112	Berger et al.	2011
SPONGENT-256	3281 GE	11.43	256	240	128	128	Bogdanov et al.	2011
PHOTON-256	2177 GE	0.88	256	224	128	128	Guo et al.	2011

Table 3. Table 3: Paper’s notations

Symbol	Description
$C_i$	Client entity or user
$CS$	Central server
$AS$	Attributes server
$DS$	Data server
$UI{D}_i,MI{D}_i$	$C_i$’s identity and medical centre identity
$P{W}_i,tmpP{W}_i$	$C_i$’s password, temporary password
$C_i{K}_{p{u}_i},C_i{K}_{p{r}_i}$	$C_i$ public and private key
$CS{K}_{p{u}_i},CS{K}_{p{r}_i}$	$CS$ public and private key
$AS{K}_{p{u}_i},AS{K}_{p{r}_i}$	$AS$ public and private key
$T{S}_{C_i},T{S}_{CS},T{S}_{AS}$	Timestamp generated by $C_i,CS,AS$
$N_{C_i},N_{CS},N_{AS}$	Nonce random generated by $C_i,CS,AS$
$I$	Internal, or external intruder
$II,EI$	Internal intruder and external intruder
$h(.)$	One-way hash function
$R_i$	Role of patient, patient relative or provider
$R{R}_i$	Revocation reason
$OT{P}_i$	One time password to authenticate first time
$C_{i}Si{g}_j$	Signature generated by $C_i$ and j is signature number
$CSSi{g}_j$	Signature generated by $CS$
$ASSi{g}_j$	Signature generated by $AS$
$U{P}_{C_i}^{CS},P{M}_{C_i}^{CS}$	User and medical centre pseudonyms sent by $C_i$ and verified by $CS$
$U{P}_{CS}^{AS},P{M}_{CS}^{AS}$	User and medical centre pseudonyms sent by $CS$ and verified by $AS$
$U{P}_{AS}^{CS},P{M}_{AS}^{CS}$	User and medical centre pseudonyms sent by $AS$ and verified by $CS$
$U{P}_{CS}^{C_i},P{M}_{CS}^{C_i}$	User and medical centre pseudonyms sent by $CS$ and verified by $C_i$
$\parallel ,\oplus$	Concatenation and exclusive or operations
$GM,CM$	Get MAC and check MAC address
$En{c}_i,De{c}_i$	Encryption and decryption operations

Table 4. Table 4: Comparison of resistance in repelling the threats between RAMHU and existing schemes

Attack	He et al. [1]	Giri et al. [17]	Li et al. [6]	Farash et al. [26]	Kumar et al. [27]	Jiang et al. [28]	Rajput et al. [7]	Das et al. [5]	Chandrakar et al. [19]	RAMHU scheme
Privileged-insider		✓	✓			✓		✓	✓	✓
Stolen device/application			✓			✓		✓	✓	✓
Replay	✓	✓	✓	✓	✓		✓	✓	✓	✓
MITM	✓			✓		✓		✓		✓
Guessing		✓	✓			✓		✓	✓	✓
Client impersonation	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
Server impersonation	✓	✓	✓	✓	✓	✓		✓	✓	✓
DoS		✓	✓				✓			✓
Change password		✓	✓			✓		✓	✓	✓
Eavesdropping	✓	✓	✓	✓	✓	✓	✓	✓	✓	✓
Traceability	✓		✓	✓	✓	✓	✓		✓	✓
Revocation						✓	✓			✓
Verifier	✓		✓			✓		✓		✓
Leakage	✓			✓		✓	✓	✓	✓	✓

Table 5. Table 5: Some HLSPL’s symbols and statements

Symbol	Description
.	Concatenation
$\left\{\right\}\_Kp$	Asymmetric encryption with public key
$played\_by$	Used to link the role with the intended entity
$=|>$	Reaction transitions to relate event with act
/\	Conjunction
$protocol\_id$	Goal identifier
$secrecy\_of$	The goal of protecting the secret between entities permanently
$authentication\_on$	The goal of strong authentication between entities
$intruder\_knowledge$	What intruder knows about network

Full text

\newbibfield

author

RAMHU: A New Robust Lightweight Scheme for Mutual Users Authentication in Healthcare Applications

Mishall Al-Zubaidie Corresponding author: e-mail: Mishall.Al-Zubaidie@usq.edu.au). Thi-Qar University, Nasiriya 64001, Iraq

Faculty of Health, Engineering and Sciences, University of Southern Queensland, Toowoomba, QLD 4350, Australia

Zhongwei Zhang

Faculty of Health, Engineering and Sciences, University of Southern Queensland, Toowoomba, QLD 4350, Australia

Ji Zhang

Faculty of Health, Engineering and Sciences, University of Southern Queensland, Toowoomba, QLD 4350, Australia

Abstract- Providing a mechanism to authenticate users in healthcare applications is an essential security requirement to prevent both external and internal attackers from penetrating patients’ identities and revealing their health data. Many schemes have been developed to provide authentication mechanisms to ensure that only legitimate users are authorized to connect, but these schemes still suffer from vulnerable security. Various attacks expose patients’ data for malicious tampering or destruction. Transferring health-related data and information between users and the health centre makes them exposed to penetration by adversaries as they may move through an insecure channel. In addition, previous mechanisms have suffered from the poor protection of users’ authentication information. To ensure the protection of patients’ information and data, we propose a scheme that authenticates users based on the information of both the device and the legitimate user. In this paper, we propose a Robust Authentication Model for Healthcare Users (RAMHU) that provides mutual authentication between server and clients. This model utilizes an Elliptic Curve Integrated Encryption Scheme (ECIES) and PHOTON to achieve strong security and a good overall performance. RAMHU relies on multi pseudonyms, physical address, and one-time password mechanisms to authenticate legitimate users. Moreover, extensive informal and formal security analysis with the automated validation of Internet security protocols and applications (AVISPA) tool demonstrates that our model offers a high level of security in repelling a wide variety of possible attacks.

Index terms— Anonymity, ECIES, MAC, mutual authentication, OTP, PHOTON, multi pseudonyms, healthcare applications

1 Introduction

A lack of security and confidentiality of information and data used by healthcare (HC) applications remains the main problem that limits widespread of these applications. These systems require a robust security mechanism to authenticate HC users for achieving the confidentiality, integrity, and availability (CIA) triangle [1, 2] and the compliance with the Health Insurance Portability and Accountability Act (HIPPA) and Health Level Seven (HL7) standards to protect data from being tampered and altered [3]. Security requirements (CIA) should be implemented when exchanging data between a client (patient or provider) application and a server application, as any modification to this data affects both medical decisions and the patient’s condition [4]. Authentication is the first as well as the most critical security requirement that plays a key role in building correct security before the exchange of patients’ data in HC applications [4, 5, 6, 7]. On one hand, authentication can reduce malicious or fatal errors caused by penetration attacks on the authentication information. On the other hand, it alleviates errors in specifying drug, dose, timing, or procedure [8]. As a result, authentication protocols are a critical requirement to repel various attacks. Typically, the server application should prevent all fake and illegal authentication requests [9, 10]. It should protect personal information, health records, and physiological parameters (such as sugar, and heart rate) [4, 11]. However, authentication information may be easier to compromise if data and information are stored on a single server. Furthermore, the transfer of authentication information in an insecure environment (wireless local area network (WLAN) or Internet), may expose patients’ data for detection or modification [6, 12]. Some of the recent cases of security threats on HC applications are presented as follows:

• •

Penetration attacks on HC data in the United States’ hospitals have occurred (2013). These attacks revealed 85.4% of the protected health information (PHI) of the 5 largest incidents for patients’ records [13];

• •

Apple Health (Medicaid) was exposed to data breach (2016). This attack revealed 370,000 records of users (Washington state) [14];

• •

An unauthenticated user penetrated the electronic health record (EHR) containing 14,633 records in the New Jersey Diamond Institute for Fertility and Menopause (2017) [15].

The traditional cryptography (such as Rivest Shamir Adleman (RSA)) and signature (such as secure hash algorithm 1 (SHA-1)) schemes require complex computations that consume server resources such as processing power and memory to deal with large amounts of health data in HC applications [16] and thus, which could render them unusable. The electronic signature is used to check the integrity of the users’ information in the authentication request [17]. Many lightweight algorithms such as PHOTON, QUARK, and SPONGENT, are desired to implement electronic signature that perform lightweight operations to reduce high overheads on the server. HC applications require cryptographic and signature high-speed, and secure algorithms [18]. To implement an authentication scheme, many algorithms, such as Elliptic Curve Cryptography (ECC), RSA, hash function, bilinear pairing, fuzzy extractor, and XOR operation [19], are used in HC application projects. Many recent HC applications are based on ECC and RSA, both of which provide the same security level, although ECC is more efficient than RSA.The design of an authentication protocols in HC applications should provide mutual authentication, resistance to known attacks such as man-in-the-middle (MITM), eavesdropping, tracing, replay, impersonation, guessing, denial of service (DoS) [20], protection of information and reduced cost and high-efficiency [21, 22].

1.1 Our Contributions

We propose a Robust Authentication Model for HC Users (RAMHU) for HC applications that perform massive and continuous authentication processes while simultaneously protecting against various attacks. Our contributions include providing robust authentication for legitimate users in the HC applications and access the server repository. They are summarized as follows:

• •

RAMHU uses lightweight algorithms for encryption (ECIES) and signature (PHOTON). These algorithms provide efficient and secure authentication for users in HC applications compared to other algorithms;

• •

RAMHU applies a one-time password (OTP) mechanism to authenticate users in their first registration in the HC network with timestamp verification and random nonce generation to repel different types of external attacks;

• •

RAMHU uses a multi pseudonyms mechanism to prevent any association between the real information, pseudonyms, and user’s data. This mechanism prevents attackers from identifying HC users (providers and patients);

• •

RAMHU integrates login request with media access control (MAC) address in addition to verifying that this address is original and not fake for authentication of legitimate devices. This prevents attackers from using different devices to compromise the network information;

• •

RAMHU improvements the mutual authentication between server and clients to prevent spoofing and impersonation attacks by either fake server or client. This prevents external attacks intended to deceive trusted parties;

• •

We simulate RAMHU with an automated validation of Internet security protocols and applications (AVISPA) tool that is generally acknowledged as an effective way to represent the threat model. We have used AVISPA to prove that our model is secure against both passive and active attacks.

1.2 Structure of the paper

The remainder of this paper proceeds as follows. Section 2 discusses previous studies related to our research. Threat model and basic concepts about the techniques used in RAMHU will be introduced in Section 3. Section 4 describes the proposed authentication model. Section 5 describes informal and formal security analysis for our proposed scheme. The conclusion and future research directions are presented in Section 6.

2 Related Work

There are many authentication schemes in literature related to our research area. This section discusses in brief the suggestions in previous studies to design authentication schemes in order to ensure the security of HC users in the network. We investigated these solutions and found that they had different drawbacks. We will discuss the solutions and their disadvantages while clarifying the superiority of our scheme on existing studies.

He and Zeadally [1] proposed an authentication scheme based on ECC and advanced encryption standards (AES) algorithms. Their scheme uses three entities: user, server, and controller. The authors claimed that their scheme provides many requirements such as mutual authentication, anonymity, and forward confidentiality. The problem with this scheme is that user and controller identities are statically sent to all three entities. If the attacker can penetrate the encryption, he/she can see the related user and controller identities. The attacker can then generate a random number, temporary key, timestamp, and message authentication code. Subsequently, he/she can encrypt the user and controller identities and obtain the message authentication code and send it to the network to become a legitimate and authenticated user. In addition, this scheme uses a 160-bit key with ECC, which is considered unreliable by trusted institutions such as the national institute of standards and technology (NIST). Our scheme uses a 256-bit key and does not exchange real information for legitimate users between clients and servers. An authentication protocol proposed to protect patients’ passwords by RSA against off-line password-guessing attacks [17]. The main problem in their scheme is that the authors used RSA with the 1024 key. This algorithm affects the performance of a huge HC network. Many schemes recommend using ECC [23, 24, 25], as the ECC-160 is equivalent to RSA-1024 with the same security level. In addition, their protocol suffers from sending an ID clearly from a client to the server at the registration phase, which causes authentication information to be detected for analysis attacks. Using shared-key to implement authentication mechanism is designed to prevent known attacks, especially DoS attacks [6]. The authors used the wrong password detection mechanism to reduce the risk of DoS attacks. However, the registration phase of their scheme is not reliable if the ID of patients is sent through an unsafe channel. Additionally, their research suffers from scalability because of the use of the single secret-key mechanism that needs protection from all parties.

Farash et al. [26] proposed an authentication scheme based on ECC for HC environments. They pointed out that their scheme provides forward secrecy. Their scheme provides authentication during the exchange of messages between the server and RFID (radio-frequency identification)’s tag. However, their scheme shows that the information (identities) and data are stored on a single server, and if the server is hacked, the users’ information and data are exposed to detection, tempering, and modification. The ECC and a Petri Nets model are proposed to achieve an authentication requirement to protect HC applications through the mobile cloud [27]. The authors pointed out that their scheme is resistant to attacks of eavesdropping, tracking, replay, and spoofing. Unfortunately, their scheme does not address the issue of steal/loss of tag or device and internal attacks that are more serious than external attacks in accessing patients’ data as well as no indication of what signature algorithm is used to integrity. In addition, tag’s ID is explicitly sent from server to tag, which makes it easier for the attacker to parse the authentication request. Jiang et al. [28] designed a three-factor (biometric, smart card and password) authentication protocol to protect e-health clouds. Their scheme protects authentication requests from impersonation attacks and off-line password guessing if a mobile device is lost or stolen. Their scheme relies on ECC to support the confidentiality and authentication of HC’s users. They used a fuzzy extractor to keep a biometric secret. However, this scheme relies on a single server to authenticate users, which is the target of the attackers. In addition, it performs 7 hash operations that can exhaust the single server capabilities if the network has a huge number of HC users, especially if it is not a lightweight hash. Our model has superior capacity, as it uses separation server (attribute server) for users’ information and also only 5 lightweight hash operations in the central server.

Cloud-assisted conditional privacy preserving authentication (CACPPA) [7] proposed to authenticate the network’s nodes. This scheme used ECIES and elliptic curve digital signature algorithm (ECDSA) algorithms with a timestamp and pseudonym integration to perform the authentication process. The problem with this scheme is that it does not provide mutual authentication to prevent an attack from a counterfeit party. Furthermore, authors did not explain the size of the keys in the algorithms to make sure that their scheme was able to repel the various attacks. Furthermore, a single pseudonym cannot separate the link to the real information to prevent analysing and tracking attacks for authentication requests. Das et al. [5] provided a user authentication scheme for HC applications based on AES and hash (SHA-1). They used biometrics users and the anonymity feature to repel attacks such as replay, MITM, and privileged insider. However, their scheme will suffer from key management problem if applied to a large health institution with hundreds of users including managing users’ accounts from adding and deleting, as symmetric encryption suffers from a scalability problem, as well as the difficulty of managing the single secret key. Furthermore, the attacker can submit a forgery attack on the login message if it detects the single secret key. Recently, Chandrakar and Om [19] provided an authentication scheme based on ECC and hash. Their scheme has supported several servers in user authentication with three factors. In this case, the user can connect to any server to perform the authentication process. In this scheme, the authors did not specify which hash algorithm was used and the size of the message digest (MD), which is necessary for repelling attacks such as collision and preimage. Using multiple servers means that the same users’ information is stored on more than one server; thus, the penetration of any server that causes users’ information to be detected or modified. Additionally, this scheme did not use a mechanism to prevent the association of real user information with authentication requests such as pseudonyms.

3 The Basic Techniques for our Authentication Scheme

Authentication mechanism specify connecting users to network services securely. The HC system needs a set of techniques to implement the authentication mechanism before accessing patients’ records. One authentication technique will not be sufficient to repel known attacks. To ensure that only legitimate users are associated with the HC application network, our project includes a set of techniques to validate the authentication request. In our scheme, we relied on algorithms that provide lightweight operations and a high-security level for encryption and signature operations. This section describes the threat model and the basic concepts of these techniques.

3.1 Threat Model

The threat model has used to detect security weakness in authentication schemes. The threat model is applied to RAMHU based on the Dolev-Yao (dy) [29] model in order to build a valid authentication process in insecure environments such as WLAN or Internet. The dy model is an efficient and practical way to illustrate security protocols in the real world. In addition, it is a formal examplar for modelling the risk of attackers against authentication protocols. This model is useful in detecting internal, external, single, and multiple attacks [30]. In our threat model, we assume that an intruder is capable of carrying out an internal, external, passive, or active attack such as MITM, replay, eavesdropping, and spoofing. Also, we assume that attributes server ($AS$) is trustworthy. It is safe against repository penetration attacks. We assume threats in our model as follows:

• •

The attacker can steal the client application and its files to analyse the data, retrieve the parameters, and reveal the secret key, and then use these applications on different devices.

• •

The attacker can listen for authentication requests in the insecure environment and execute interception, replay and MITM attacks in order to become a legitimate user in the network.

• •

The attacker can execute a forgery or masquerading attack in an attempt to penetrate the authentication process.

• •

A legitimate user can perform a privileged insider attack based on his/her legitimacy in the network.

• •

The attacker can successfully guess the real username, password, role and pseudonym associated with it during intensive analysis of many authentication requests.

3.2 Overview of Techniques

• •

Elliptic curve integrated encryption scheme (ECIES)

Elliptic Curve Cryptography (ECC) has been used to provide security requirements. It provides confidentiality, integrity, and authentication in the communications network with limited capacity in terms of power and processing. This algorithm was independently proposed by Neal Koblitz and Victor Miller in 1985 [31]. It depends on the discrete logarithm problem (DLP), which is impervious to known attacks when selecting parameters accurately [32], i.e., difficulty obtaining k from P and Q (where k is integer, and P and Q are two points on the curve). Small parameters used in ECC help to perform computations quickly. These computations are important in constrained-source and large environments that require processing power, memory, or power consumption [20, 33]. ECC provides encryption (Elliptic Curve Integrated Encryption Scheme(ECIES)), signature (Elliptic Curve Digital Signature Algorithm (ECDSA)), and exchange keys (Elliptic Cuvre Diffie-Hellman (ECDH)) approaches [31]. Many operations are performed in ECC algorithms (described in four layers) as shown in Figure 1 [34]. ECIES has provided confidentiality and proven to be extremely efficient in its performance, as it uses small keys; thus, the cost of computation is small compared with other public key cryptography algorithms, such as Rivest Shamir Adleman (RSA) [35]. Table 1 [33, 36, 37] shows a comparison of key sizes for public key encryption algorithms.

• •

Lightweight hash-function algorithm

Hash function has used to generate signatures for authentication requests. PHOTON is lightweight hash-function and extremely suitable for projects that require a robust and reliable signature. This algorithm is based on a sponge-like construction and AES-like primitive for domain extension and permutation efficiency [38, 39, 40]. PHOTON is available in several versions (80, 128, 160, 224, and 256). It is a balance between the efficiency in the execution of computations on the one hand and security in the implementation of the features of the signature principle that depend on preimage resistant (PR), second preimage resistant (SPR), collision resistant (CR) and mixing-transformation [17] on the other hand. It uses sponge construction and applies two phases of absorbing and squeezing to produce message digest (MD); more details are available in [41]. Table 2 provides a comparison among the lightweight hash algorithms (the latest version of these algorithms) in terms of security and efficiency [39, 41, 42, 43, 44, 45, 46]. Although standard hash algorithms are still used in applications such as SHA-1 (5527 GE, MD 160-bit) and SHA-2 (10868 GE, MD 256-bit), lightweight hash algorithms such as PHOTON (2177 GE, MD 256-bit) provides the most effective solution for handling complex signatures in large HC systems.

Table 2 shows that the PHOTON-256 (2177 GE) provides the best performance compared to all lightweight hash functions and offers a high level of security through the application of signature features PR (224), SPR (128), and CR (128). Linear and differential attacks are the most powerful attacks in the MD analysis of hash functions. Compared to PHOTON, ARMADILLO and SPONGENT-256 also offer signature features, but both are vulnerable to attacks, where ARMIDLLO2 has been attacked by local linearization (practical semi-free-start collision attack)[47] and SPONGENT has been attacked by linear distinguishers (23 rounds) [48] and (13 rounds) [49] for all SPONGENT versions; and additionally, they need the most computations (3281 GE and 8653 GE) compared PHOTON-256 (2177 GE). PHOTON is a reliable algorithm against linear and differential attacks [41]. It has a high level of security and efficiency; therefore, it is suitable for our project as a signature mechanism.

• •

One time password (OTP)

OTP is a way to authenticate legitimate users by generating passcode or nonce only once in a specified time. It will not be applicable the next times for authentication. OTP is an effective method for authenticating users in HC applications if used with robust encryption and signature technologies. Using a static password, or nonce without other authentication mechanisms is weak in respect to attacks. Therefore, OTP provides significant support to the authentication process. This mechanism prevents many attacks such as replay, MITM, and guessing [50]. The attacker cannot use this passcode or nonce to connect to the network later. The client sends OTP as part of an authentication request. If the authentication process is valid, the server will delete OTP from the dataset and will not accept it in the future. OTP is a powerful mechanism to mitigate the risk of hackers’ communication in the network. In this project, we apply OTP to generate a random password with the first link to users in HC applications to ensure that only legitimate users are connected to the network.

• •

Mutual authentication

Mutual authentication is a prerequisite for preventing fraudulent authentication requests. The traditional methods of authentication (such as password and name) are not suitable for HC applications [18]. In general, there are two kinds of authentication, simple and mutual. In simple authentication, one party performs the authentication process, for example, the server verifies the authentication request for the client. This type of authentication is vulnerable to attacks such as spoofing and impersonation. The attacker can use his device as a fake server to receive all clients’ requests. Mutual authentication provides a security solution to prevent known attacks [18]. In this type of authentication, each party authenticates the other party and thus, prevents counterfeit attacks by both client or server. In RAMHU, we adopt the mechanism of mutual authentication in the preservation of users’ information and data.

• •

Media access control (MAC) address

MAC address has used to distinguish legitimate users’ devices in a network during the completion of the authentication process. All network devices of different types should contain a hardware card (interface) to connect to the local or global network. Each wire or wireless interface has a media access control (MAC) or physical address that consists of a 48-bit. It is divided into six octets and written in hexadecimal such as ”8C: 70: 5A: 41: 49: BC”. This address is a unique identifier (no duplicate address twice) for a device defined as a global and persistent [51]. This address is used in WLAN networks because it offers advantages such as reducing costs and speed in access control procedures [52]. It can be changed programmatically in various operating systems such as Linux and Windows. In addition, anyone can use Address Resolution Protocol (ARP) to detect the MAC address of another user in the network [53]. The main problem with this address is that the attacker can execute an eavesdropping attack to access the MAC addresses of legitimate devices in the network and then select a legitimate MAC address to use it. For instance, an attacker could execute an ARP poisoning or spoofing attack by using a fake identifier of the MAC address (for a legitimate entity) to gain illegal privileges that would enable it to perform other attacks such as MITM and DOS [54]. In addition, randomization operations for the MAC address have become useless in the protection against tracking attacks [55, 56]. Therefore, if the server does not have a mechanism to detect MAC address change, the attacker becomes a legitimate user in the network and has access to network resources.

4 The Proposed Authentication Scheme

In this section, we will detail about RAMHU that provides security and efficiency features in HC applications. This section will be divided into the network model, security goals, and proposed authentication protocols. Notations listed in Table 3 are used to describe symbols used throughout this paper.

4.1 Network Model

The RAMHU model consists of four entities, as shown in Figure 2:

Client ($C_{i}$): This entity includes patients, relatives of patients, and HC providers such as doctors, researchers, emergency practitioners, advisors, and nurses. 2. 2.

Central server ($CS$): This entity is a gateway to authenticate users with the attributes server and to authorize the data server. 3. 3.

Attributes server ($AS$): This entity contains users’ real information as well as multi pseudonyms. The authentication process requires verifying the association of the actual information with the multi pseudonyms in this entity. 4. 4.

Data server ($DS$): This entity contains users’ data as well as multi pseudonyms. This entity is not implemented in our scheme and is left to future work. Our scheme focuses only on the process of users’ authentication in the HC network.

Generally, $C_{i}$ creates an authentication request mainly based on ECIES and PHOTON. $C_{i}$ sends a request to $CS$ to verify encryption, signature, and security parameters (such as MAC address, pseudonyms, and $OTP_{i}$). Then, the $CS$ sends a request to the $AS$ to verify the link between the pseudonyms, the real information, the signatures, and $PW_{i}$. After that, the $AS$ sends the response to the $CS$ that verifies the signature and the parameters and then the $CS$ sends the response (authenticated or not) to the $C_{i}$. If the user is authenticated, we assume that the user can then send an authorization request to access the data in the repository ($DS$) and obtain the authorization response from the $CS$, $AS$, and $DS$.

4.2 Security Goals

To build a robust authentication scheme, RAMHU adopts the following security requirements:

• •

Confidentiality: This requirement is performed to hide authentication information and to preserve user secrecy from detection by intruders. To implement this requirement, a high-security cryptographic algorithm [20] should be used. RAMHU executes ECIES to hide authentication information about intruders.

• •

Integrity: This is to protect the authentication request information from modification by intruders. The authentication request should reach the intended destination without modification to provide a reliable communication channel for legitimate users [57, 10]. RAMHU performs a PHOTON to prevent any process of modifying the user authentication information in HC applications.

• •

Non-repudiation: This requirement prevents both clients and server from denying their authentication requests. This is a way to prove that the message is sent by a particular sender in the HC applications network. If a legitimate user in the network performs internal attacks, he/she cannot deny his/her activities while exploiting the privileges granted to him/her. Our scheme uses PHOTON signatures and a MAC address to meet this requirement and detect malicious attacks.

• •

Anonymity: This requirement is extremely important in supporting the confidentiality of the authentication request. The purpose of this requirement is to disguise the source and destination of the authentication request. If the authentication scheme applies anonymity with encryption, the attacker finds it exceedingly difficult to analyze authentication requests for a particular user at different times because the authentication request is different each time the user is connected to the network [7]. RAMHU applies this requirement through the use of random nonces between entities.

• •

Pseudonym: This requirement denotes the provision of a mechanism to connect non-real attributes (such as terms and symbols) with the real attributes of the user (such as name, address, and phone number). The use of this mechanism in HC applications is an extremely important way to protect the personal information of users and prevent the detection of their identities. RAMHU uses a multi pseudonyms mechanism to prevent and separate the association with real information.

• •

Forward secrecy: This requirement is accomplished when network users use new keys and parameters temporarily without relying on old ones. This requirement prevents attackers from exploiting users’ keys and passwords in decrypting authentication requests. Using the temporary random password, private key, and MAC, RAMHU prevents users from accessing previous authentication information.

• •

Mutual authentication: This requirement is used in HC applications to mitigate the risks of external fraud. With this feature, each party ensures that it deals with a legitimate party. The server authenticates the client by checking encryptions and signatures and vice versa in order to establish a secure communication channel. In RAMHU, $CS$ and $C_{i}$ authenticate each other to prevent masquerading and impersonating attacks.

• •

Scalability: HC applications operate in a scalable environment in terms of data and users. Therefore, these applications require authentication schemes capable of handling and adapting to the ever-increasing number of users of HC applications. This requirement refers to the ability of the authentication scheme to appropriately handle large HC systems. Public key encryption schemes are efficient in supporting this requirement [27].

• •

Freshness: This requirement indicates that the authentication request is new and updated to ensure that the attacker cannot replay the authentication request at a later time. This requirement is achieved through the provision of time checking, a random nonce, and change of signatures in each authentication process to counteract counterfeit attacks such as MITM, replay, and impersonation [20], which ensures that the authentication request is unaltered or not tampered with.

4.3 Proposed Authentication Scheme

RAMHU scheme consists of 5 protocols: initial setup, registration/login, authentication, password update, and revocation. During these protocols, RAMHU provides reliable authentication processes to protect users’ information.

4.3.1 Initial Setup Protocol

In this protocol, all entities are ready to start communicating with each other while configuring all security parameters and ECIES’s keys as in the following steps:

• •

Each legitimate user receives a client application from the authorized system provider.

• •

Each legitimate user receives a $PW_{i}$ (that can be changed later) and a random $OTP_{i}$ to be used in the first registration.

• •

All entities ($C_{i}$, $CS$ and $AS$) should create public and private keys ($C_{i}$ ($CK_{pu_{i}}$, $CK_{pr_{i}}$), $CS$ ($CSK_{pu_{i}}$, $CSK_{pr_{i}}$), and $AS$ ($ASK_{pu_{i}}$, $ASK_{pr_{i}}$)) to be used to validate the authentication request. All entities choose an elliptic curve $Ep(a,b)$ over a prime field $F_{P}$ (where, $P$ = 256) and base point $G$ on curve. Each entity selects a private key $K_{pr_{i}}$ randomly and generates the public key $K_{pu_{i}}$ during the implementation of scalar multiplication ($K_{pu_{i}}=K_{pr_{i}}*G$).

• •

All entities broadcast the public key ($CK_{pu_{i}}$, $CSK_{pu_{i}}$, and $ASK_{pu_{i}}$) to use in ECIES’s encryption operations.

4.3.2 Registration and Login Protocol

Patients and HC providers ($C_{i}$) should complete the registration and login protocol with $CS$ to become legitimate users of HC applications. Without this protocol, the user cannot complete the authentication process in RAMHU. User registration is performed once, namely, the user does not need to complete the registration protocol the next times (only the login protocol), the registration information has been kept in the servers until the revocation protocol and deletion the user security parameters such as pseudonyms, MAC address and $PW_{i}$, this protocol accomplishes the following steps (Figure 3 shows registration, and login protocol and Figure 4 shows login protocol):

$C_{i}$ side:

• •

The user enters $UID_{i}$ (such as his/her name), $MID_{i}$ (such as medical centre name), $PW_{i}$ and $OTP_{i}$ for registration and login while only entering $UID_{i}$, $MID_{i}$, and $PW_{i}$ for the login protocol the next times to the client ($C_{i}$) application. $C_{i}$ replaces $UID_{i}$ with user’s pseudonym ($UP^{CS}_{C_{i}}$), and $MID_{i}$ with medical centre pseudonym ($MP^{CS}_{C_{i}}$) to protect the authentication information when moving from $C_{i}$ to $CS$. $C_{i}$ generates timestamp ($TS_{C_{i}}$) to be used to verify the sending time of the registration/login request in $CS$.

• •

$C_{i}$ gets a MAC address (GM) by entering its IP (Internet protocol) address. The process of checking MAC ($CM$) is performed by $C_{i}$ to test the credibility of the MAC address. In the Linux system, we used the command ”ethtool -P interface name” (such as ”ethtool -P wlo1”) in the $C_{i}$ application. If the result is identical to $GM$, it means that the MAC address is native ($CM$ = ”$Real\_MAC$”). In Windows system, $C_{i}$ searches for string value ”NetworkAddress” in the path of the system registry (”$HKEY\_LOCAL\_MACHINE\setminus SYSTEM\setminus CurrentControlSet\setminus Control\setminus Class\setminus\{4D36E972-E325-11CE-BFC1-$ $08002BE10318\}\setminus$”). If NetworkAddress = null, $CM$ = ”$Real\_MAC$”; otherwise $CM$ = ”$Fake\_MAC$”. The $GM$ send is encrypted with an registration/login request while $CM$ is implicitly sent with the signature value ($C_{i}Sig_{1}$). If only login protocol, $C_{i}$ needs to extract private key from temporary key, MAC address, password, and random nonce through $tmpC_{i}K_{pr_{i}}\oplus GM\oplus PW_{i}\oplus N_{C_{i}}$. $C_{i}$ generates a random nonce ($N_{C_{i}}$) to change signature and encryption data and add anonymity to the registration/login request.

• •

$C_{i}$ performs two signatures using the PHOTON-256 algorithm to protect information from modification. The first signature includes the parameters check MAC, nonce, and timestamp ($CiSig_{1}=h(CM\|N_{C_{i}}\|TS_{C_{i}}$). The second signature includes all the authentication parameters of the get MAC, nonce, timestamp, first signature, pseudonyms, one time password, and password ($CiSig_{2}=h(GM\|N_{C_{i}}\|TS_{C_{i}}\|$ $CiSig_{1}\|UP^{CS}_{C_{i}}\|MP^{CS}_{C_{i}}$ $\|OTP\|PW_{i}$). In the login protocol, $OTP$ is not added to the signature.

• •

$C_{i}$ computes a temporary value ($tmpPW_{i}=PW_{i}\oplus N_{C_{i}}\oplus GM\oplus C_{i}Sig_{1}$) of $PW_{i}$ when moving from $C_{i}$ to $CS$.

• •

$C_{i}$ uses ECIES to encrypt and hide all the data of this request ($Enc_{i}(TS_{C_{i}}\|N_{C_{i}}\|GM\|CiSig_{1}\|$ $UP^{CS}_{C_{i}}\|MP^{CS}_{C_{i}}\|OTP_{i}\|tmpPW_{i}\|CiSig_{2})$). In the login protocol, $OTP_{i}$ and $GM$ are not added to the encryption as in Figure 4. After that, $C_{i}$ sends the registration and login request or login to $CS$ to complete the authentication protocol. Then $C_{i}$ hides the private key by $tmpC_{i}K_{pr_{i}}=C_{i}K_{pr_{i}}\oplus PW_{i}\oplus C_{i}Sig_{2}$ .

$CS$ side:

• •

Upon receiving a registration and login request or login request, $CS$ decrypts this request using ECIES’s $C_{i}K_{pu_{i}}$ and $CSK_{pr_{i}}$. It checks timestamp ($TS_{CS}$-$TS_{C_{i}}$ $\leq$ $\triangle T$) to make sure that this request arrived at an appropriate time and without delay.

• •

In the registration and login protocol, $CS$ examines the random $OTP_{i}$ in the dataset. If $OTP_{i}$ exists, then the user is legitimate for the registration process. After that, $CS$ deletes $OTP_{i}$ from the dataset to prevent it from being used the next times. If $OTP_{i}$ is not found, It discards the connection. If the login protocol, $CS$ examines the $UP_{C_{i}}^{CS}$ and $MP_{C_{i}}^{CS}$ and then tests their association with the MAC address in the dataset. If $GM$ is found, $CS$ completes the steps of this protocol; otherwise, it cancels the connection.

• •

$CS$ needs to ensure that the user’s device is legitimate within the network. $CS$ computes the signature value to make sure that the MAC address is native and non-modified ($CSSig_{1}=h("Real\_MAC"\|N_{C_{i}}$ $\|TS_{C_{i}})$. It examines the result of the computed signature ($CSSig_{1}$) with the $C_{i}$’s signature ($C_{i}Sig_{1}$). If the signatures result are identical, then the device is legitimate and the MAC address did not change. In the registration and login protocol, $CS$ stores this address in dataset for use and check the next times in the login protocol.

• •

$CS$ performs the computation operation the $tmpPW_{i}\oplus N_{C_{i}}\oplus GM\oplus CSSig_{1}$ to extract the $PW_{i}$ value and then uses this value to produce a second signature ($CSSig_{2}$).

• •

$CS$ computes a second signature operation ($CSSig2$= $h(GM\|N_{C_{i}}\|TS_{C_{i}}\|CSSig_{1}$ $\|UP_{C_{i}}^{CS}$ $\|MP_{C_{i}}^{CS}\|OTP_{i}\|PW_{i}$) to guarantee that all the encrypted information is not changed. Then, it compares the computed signature ($CSSig_{2}$) with the received signature in the request ($CiSig_{2}$). If the signatures are identical, then the information for this request is unchanged or not tampered. In the login protocol, $OTP_{i}$ and $GM$ are not added to the signature. At this point, $CS$ prepares to send the user’s authentication request to $AS$.

4.3.3 Authentication Protocol

The authentication protocol verifies the reliability of the users’ security parameters with their personal information in the server. In this protocol, RAMHU needs to link pseudonyms and passwords with real information for users in $AS$’s datasets. Note that, the users’ information (such as name, age, address, mobile number, and passwords) are stored in a separate server (AS) and multi pseudonyms used to prevent detection and tracking of users’ information. This protocol is illustrated in the following steps (Figure 5 shows authentication protocol in RAMHU):

$CS$ side:

• •

$CS$ computes a new timestamp ($TS_{CS}$) to ensure the fresh authentication request.

• •

$CS$ replaces $C_{i}$’s pseudonyms ($UP_{C_{i}}^{CS}$ and $MP_{C_{i}}^{CS}$) with $CS$’s pseudonyms ($UP_{CS}^{AS}$ and $MP_{CS}^{AS}$) to prevent attackers from tracking the authentication request. It generates random nonce ($N_{CS}$) to ensure an anonymous authentication request.

• •

$CS$ signs security parameters by PHOTON-256 ($CSSig_{3}=h(TS_{CS}\|N_{CS}\|UP_{CS}^{AS}\|MP_{CS}^{AS}$) to prevent modification of authentication request information.

• •

$CS$ computes temporary $PW_{i}$ by the computation of $PW_{i}\oplus N_{CS}\oplus CSSig3$.

• •

$CS$ encrypts information of authentication request ($Enc_{i}(TS_{CS}\|N_{CS}\|UP_{CS}^{AS}\|MP_{CS}^{AS}\|CSSig_{3}$ $\|tmpPW_{i})$). It sends an authentication request to verify user’s information in $AS$.

$AS$ side:

• •

Upon receiving the authentication request, $AS$ decrypts that request using ECIES’s $ASK_{pr_{i}}$ and $CSK_{pu_{i}}$ to obtain the authentication information clearly.

• •

It checks timestamp by ($TS_{AS}-TS_{CS}\leq\triangle T$) to ensure that the authentication request is not delayed. $AS$ checks the pseudonyms ($UP_{CS}^{AS}$ and $MP_{CS}^{AS}$) sent from CS and correlates it with the user’s real identifier ($UID_{i}$ and $MID_{i}$) in the datasets. $AS$ extracts user’s password from the equation $PW_{i}=tmpPW_{i}\oplus N_{CS}\oplus CSSig_{3}$. After that, It checks matching $PW_{i}$ in the dataset. $AS$ computes the value of the signature based on authentication information ($ASSig_{1}=h(TS_{CS}\|N_{CS}\|UP_{CS}^{AS}\|MP_{CS}^{AS}$)) by PHOTON-256. $AS$ compares the computed value of the signature ($ASSig_{1}$) with the value of the received signature ($CSSig_{3}$). If the signature values are identical, the user’s information in the request for the signature is unmodified. At this point, $AS$ considers this user to be legitimate and reliable.

• •

$AS$ prepares a response to authenticate the request of that user. It computes new timestamp ($TS_{AS}$ = new $TS_{AS}$) to prevent delayed or replayed requests at later times. $AS$ replaces $CS$’s pseudonyms ($UP_{CS}^{AS}$ and $UP_{CS}^{AS}$) received with $AS$’s pseudonyms ($UP_{AS}^{CS}$ and $MP_{AS}^{CS}$) to hide users’ information. It generates a new random nonce ($N_{AS}$) to add anonymity and prevent attacks from encryption and signature analysis.

• •

$AS$ computes a signature ($ASSig_{2}=h(TS_{AS}\|N_{AS}\|UP_{AS}^{CS}\|MP_{AS}^{CS})$) to prevent modifications of authentication response information.

• •

$AS$ encrypts the authentication information ($Enc_{i}(TS_{AS}\|N_{AS}\|UP_{AS}^{CS}\|MP_{AS}^{CS}\|$ $ASSig_{2})$) and sends the authentication response to $CS$ to complete the authentication process.

$CS$ side:

• •

$CS$ decrypts the authentication response ($Enc_{i}$) received from $AS$. It checks the timestamp value ($TS_{CS}-TS_{AS}\leq\triangle T$) to prevent late authentication responses. It examines that $UP_{CS}^{AS}$ and $MP_{CS}^{AS}$ in datasets to complete the process of linking multi pseudonyms to the user.

• •

$CS$ computes the signature $CSSig4=h(TS_{AS}\|N_{AS}\|UP_{AS}^{CS}\|MP_{AS}^{CS})$ for authentication response information. It compares the computed result of the signature ($CSSig_{4}$) with the value of the received signature ($ASSig_{2}$). If the signature values match, then the authentication response information is unchanged.

• •

After this point, $CS$ initiates a login response request. It computes the value of new timestamp ($TS_{CS}=newTS_{CS}$). It replaces $AS$’s pseudonyms ($UP_{AS}^{CS}$ and $MP_{AS}^{CS}$) received with $UP_{CS}^{C_{i}}$ and $MP_{CS}^{C_{i}}$. It generates a new random nonce ($N_{CS}$) to hide encryption and signature information.

• •

$CS$ computes a new signature value ($CSSig_{5}=h(TS_{CS}\|N_{CS}\|UP_{CS}^{C_{i}}\|MP_{CS}^{C_{i}})$) to protect login response information from modification.

• •

$CS$ encrypts login response information ($Enc_{i}(TS_{CS}\|N_{CS}\|UP_{CS}^{C_{i}}\|MP_{CS}^{C_{i}}\|CSSig_{5})$) and sends this response to $C_{i}$.

$C_{i}$ side:

• •

$C_{i}$ extracts his private key ($C_{i}K_{pr_{i}}$) from the $tmpC_{i}K_{pr_{i}}\oplus PW_{i}\oplus C_{i}Sig_{2}$, and decrypts the login request ($Enc_{i}$) received from $CS$.

• •

$C_{i}$ checks timestamp ($TS_{C_{i}}-TS_{CS}\leq\triangle T$) to ensure that the login response is not late or replayed.

• •

$C_{i}$ checks that $CS$’s pseudonyms ($UP_{CS}^{C_{i}}$ and $MP_{CS}^{C_{i}}$) are received in the dataset and associated with $UP_{C_{i}}^{CS}$ and $MP_{C_{i}}^{CS}$. At this point, RAMHU applied multi pseudonyms among model entities ($Ci$, $CS$, and $AS$) to prevent traceability in linking the real information of the user with pseudonyms.

• •

$C_{i}$ calculates the value of the signature $CiSig_{3}=h(TS_{CS}\|N_{CS}\|UP_{CS}^{C_{i}}\|MP_{CS}^{C_{i}})$ for login response information. It compares the result of the computed signature ($CiSig_{3}$) and the value of the received signature ($CSSig_{5}$). If the signature values are identical, namely, the login response information is unmodified or not tampered, $C_{i}$ accepts the login response; otherwise $C_{i}$ discards the login response. Then, $C_{i}$ hides its private key by $C_{i}K_{pr_{i}}\oplus GM\oplus PW_{i}\oplus N_{C_{i}}$ after generating a random nonce to prevent the detection of the private key if the device is hacked. At this point, if all processes are achieved correctly, then all requests are considered legitimate and reliable through the implementation of mutual authentication.

4.3.4 Password Update Protocol

Updating the password is a security procedure to ensure authentication of legitimate users. The process of changing $PW_{i}$ is important in any HC system for two reasons. First, preventing the use of $PW_{i}$ fixed for a long time and which reduces the guessing attacks. Second, changing $PW_{i}$ gives users more flexibility in choosing the appropriate $PW_{i}$. This process requires strict security measures to protect new $PW_{i}$. RAMHU provides the legitimate user with a mechanism to change his/her password at any time. If the user wants to change his/her $PW_{i}$, the following illustration describes the new $PW_{i}$ protect procedures in a secure manner (Figure 6 shows password update protocol in RAMHU).

• •

$C_{i}$ side: $Ci$ enters $UID_{i}$, $MID_{i}$, old $PW_{i}$, and new $PW_{i}$. It replaces $UID_{i}$ and $MID_{i}$ with a pseudonyms to hide the user’s real information. $C_{i}$ calls MAC address, then extracts the private key from the $tmpC_{i}K_{pr_{i}}\oplus GM\oplus oldPW_{i}\oplus N_{C_{i}}$ to use in the encryption process of the password update request. $C_{i}$ generates three random nonces ($N_{C_{1}}$, $N_{C_{2}}$, and $N_{C_{3}}$) and computes a new timestamp ($TS_{C_{i}}$). $C_{i}$ computes the signature value ($C_{i}Sig_{1}=h(TS_{C_{i}}\|N_{C_{1}}\|UP_{C_{i}}^{CS}\|MP_{C_{i}}^{CS}\|oldPW_{i}$) by PHOTON-256 based on the parameters of the password change request. It applies an anonymity mechanism to old $PW_{i}$ and new $PW_{i}$ ($tmp\_oldPW_{i}$ = $oldPW_{i}\oplus N_{C_{2}}\oplus CiSig_{1}$ and $tmp\_newPW_{i}$ = $newPW_{i}\oplus N_{C_{3}}\oplus CiSig_{1}$) to hide passwords and not explicitly send it in the $PW_{i}$ change request. It encrypts the $PW_{i}$ change request ($Enc_{i}(TS_{C_{i}}\|N_{C_{1}}\|N_{C_{2}}\|N_{C_{3}}\|\ UP_{C_{i}}^{CS}\|$ $MP_{C_{i}}^{CS}\|$ $tmp\_oldPW_{i}\|$ $tmp\_newPW_{i}$ $\|C_{i}Sig_{1})$) and sends it to $CS$, $C_{i}$ then hides its private key by $C_{i}K_{pr_{i}}\oplus GM\oplus newPW_{i}\oplus N_{C_{i}}$.

• •

$CS$ side: $CS$ receives and decrypts a password update request ($Enc_{i}$). It examines timestamp to prevent delayed requests, and examines $UP_{C_{i}}^{CS}$ and $MP_{C_{i}}^{CS}$ in datasets. $CS$ extracts old $PW_{i}$ and new $PW_{i}$ from $tmp\_oldPW_{i}\oplus N_{C_{2}}\oplus CiSig_{1}$ and $tmp\_newPW_{i}$ $\oplus N_{C_{3}}\oplus CiSig_{1}$. Then, it computes signature value ($CSSig_{1}$) depending on $TS_{C_{i}},N_{C_{1}},$ $UP_{C_{i}}^{CS},$ $MP_{C_{i}}^{CS}$, and $oldPW_{i}$ to check the matching between $CSSig_{1}$ and $C_{i}Sig_{1}$. Similarly, in authentication protocol, $CS$ computes $TS_{CS}$ and replaces pseudonyms. $CS$ generates three nonces $N_{CS_{1}}$, $N_{CS_{2}}$, and $N_{CS_{3}}$ and then $CS$ computes signature value ($h(TS_{C_{i}}\|N_{C_{1}}\|UP_{C_{i}}^{CS}\|MP_{C_{i}}^{CS}\|oldPW_{i}$) and hides old $PW_{i}$ and new $PW_{i}$ by $oldPW_{i}\oplus N_{CS_{2}}\oplus CSSig_{2}$ and $newPW_{i}\oplus N_{CS_{3}}\oplus CSSig_{2}$. It encrypts password update request with security parameters ($TS_{CS}$, $N_{CS_{1}}$, $N_{CS_{2}}$, $N_{CS_{3}}$, $UP_{CS}^{AS}$, $MP_{CS}^{AS}$, $tmp\_oldPW_{i}$, $tmp\_newPW_{i}$, and $CSSig2$) and sends to $AS$.

• •

$AS$ side: $AS$ receives password update request, and decrypts ($Enc_{i}$) this request with $ASK_{pr_{i}}$, and $CSK_{pu_{i}}$. It checks time delay and then, it checks link pseudonyms with real information for users. It extracts old $PW_{i}$ from $tmp\_oldPW_{i}\oplus N_{CS_{2}}\oplus CSSig_{2}$ and then, it checks old $PW_{i}$ in dataset. It computes the signature value $ASSig_{1}=h(TS_{CS}\|N_{CS_{1}}\|UP_{CS}^{AS}\|MP_{CS}^{AS}\|$ $oldPW_{i})$, and then, it compares the calculated result ($ASSig_{1}$) with the result of the received signature ($CSSig_{2}$). If identical, the signature is true; otherwise, $AS$ rejects the $PW_{i}$ change request. $AS$ performs the calculation $tmp\_newPW_{i}\oplus NCS_{3}\oplus CSSig_{2}$ to obtain the new $PW_{i}$ value. If all previous checks are validated, $AS$ changes old $PW_{i}$ to new $PW_{i}$.

4.3.5 Revocation Protocol

Revocation in HC applications uses when a user finishes a task or to prevent attack. This protocol can be completed by $C_{i}$, or $AS$. If $C_{i}$ wants to cancel his account from the HC system after completing his/her duties such as a research doctor who uses the system for a limited period and then cancel his account after the completion of his duties. Additionally, $AS$ can revoke the account of any user who performs suspicious activities (internal attacks) that are not within his/her privileges such as a nurse who wants to access the personal information of a particular doctor, or patient. Furthermore, the user can request from authorities provider ($AS$) to revoke his/her account information that is associated with his/her data (note that the patients’ data history remains stored in $DS$ even after the completion of the revocation protocol). The protocol of revocation is extremely important in restricting the malicious activities of HC systems. RAMHU includes a revocation protocol to provide strict security procedures in protecting users’ authentication information (Figure 7 shows revocation protocol in $C_{i}$ side in RAMHU):

Revocation from $C_{i}$ side:

• •

$C_{i}$ enters $UID_{i}$, $MID_{i}$, and $PW_{i}$ and then replaces $UID_{i}$ with $UP_{C_{i}}^{CS}$ and $MID_{i}$ with $MP_{C_{i}}^{CS}$. It chooses the revocation reason ($RR_{i}$) from the drop-down list (such as ending the researcher’s study, ending a satisfactory condition, resigning a professional, changing a health institution, and the unwillingness of a patient to use the system). These reasons have converted to signatures using PHOTON to get MDs with a 256-bits in the dataset. $C_{i}$ computes new $TS_{C_{i}}$, $N_{C_{1}}$, $N_{C_{2}}$, and $N_{C_{3}}$. Then, $C_{i}$ performs the process of $RR_{i}\oplus N_{C_{1}}$ to add randomness for $RR_{i}$. Using this procedure is very useful in tightening security and distinguishing the roles of users (patients or professionals) in $CS$. It computes the signature $C_{i}Sig_{1}=h(TS_{C_{i}}\|N_{C_{1}}\|UP_{C_{i}}^{CS}\|MP_{C_{i}}^{CS}\|$ $RR_{i}\|$ $PW_{i}\|$ $"delete")$. $C_{i}$ performs a computation to hide the $RR_{i}$ ($tmpRR_{i}=RR_{i}\oplus N_{C_{2}}\oplus C_{i}Sig_{1}$). $C_{i}$ computes the temporary $PW_{i}$ value of $PW_{i}\oplus N_{C_{3}}\oplus C_{i}Sig_{1}$ to hide the $PW_{i}$ value. Additionally, It computes encryption ($Enc_{i}(TS_{C_{i}}\|N_{C_{1}}\|N_{C_{2}}\|N_{C_{3}}\|UP_{C_{i}}^{CS}\|MP_{C_{i}}^{CS}\|$ $tmpRR_{i}\|$ $tmpPW_{i}$ $\|C_{i}Sig_{1})$) and sends a revocation request to $CS$. Then, It hides a private key, in the same way, in the password update protocol.

• •

$CS$ decrypts ($Enc_{i}$) and computes timestamp and examines $UP_{C_{i}}^{CS}$ and $MP_{C_{i}}^{CS}$ in the datasets. It obtains the $RR_{i}$ from the computation equation $RR_{i}=tmpRR_{i}\oplus N_{C_{2}}\oplus CSSig_{1}$. It extracts $PW_{i}$ from $tmpPW_{i}\oplus N_{C_{3}}\oplus C_{i}Sig_{1}$ and checks $PW_{i}$ matching in the dataset. $CS$ computes the signature ($CSSig_{1}=h(TS_{C_{i}}\|N_{C_{1}}\|UP_{C_{i}}^{CS}\|MP_{C_{i}}^{CS}\|RR_{i}$ $\|PW_{i}\|$ $"delete")$ and then compares the result of the signatures. $CS$ computes operation $RR_{i}\oplus N_{C_{1}}$ to use $RR_{i}$’s signature in order to compare the $RR_{i}$ with the user’s $R_{i}$. If all operations are achieved and validated correctly, $CS$ sends a request to $AS$ to check the pseudonym’s association with real information and check $PW_{i}$. $AS$ deletes association between pseudonyms and information, and delete user’s $PW_{i}$ from dataset. $AS$ sends MAC delete request to $CS$. Upon receiving MAC delete request, $CS$ decrypts this request, then checks security parameters and signature. If all operations are achieved and validated correctly, $CS$ deletes MAC address from dataset. At this point, this user cannot perform an authentication process in RAMHU.

Revocation from $AS$ side:

• •

$AS$ deletes the association between user’s information and pseudonyms and $PW_{i}$ in datasets. It sends an encrypted request ($Enc_{i})$ to $CS$ to delete device’s MAC address for this user. After the completion of this protocol, the user is considered illegal and cannot access HC services.

5 Security Analysis

In this section, a theoretical, and an experimental security analysis have been presented. We describe how RAMHU applies security requirements in protecting users’ authentication information in the HC system.

5.1 Theoretical Security Analysis

The theoretical security analysis shows that RAMHU is secure against the various known attacks. In this section, we will show how RAMHU provides a high-security level against these attacks by providing assumptions and proofs. Table 4 summarises the comparison between RAMHU and other authentication protocols in various attacks resistance.

• •

**RAMHU prevents a privileged insider attack.

Proof 1:** The internal intruder ($II$) needs to eavesdrop authentication requests between $C_{i}$ and $CS$. After that, he/she tries to perform an analysis of these requests based on his/her access privileges to the network. First, the analysis of these requests to obtain the private key or password is infeasible because the authentication request is encrypted by the ECIES-256 bits algorithm; $II$ cannot decrypt these requests with his private key. Second, if $II$ broke the encryption (which is impossible), he/she is unable to extract the $PW_{i}$ value ($tmpPW_{i}=PW_{i}\oplus N_{C_{i}}\oplus GM\oplus C_{i}Sig_{1}$) in the login protocol because it is hidden and depends on the values of $GM$, $C_{i}Sig_{1}$, and $N_{C_{i}}$ where $II$ does not know the $GM$ value of the legitimate user’s device, and the $C_{i}Sig_{1}$ value depends on the $CM$ value that is also not known to $II$. Therefore, RAMHU prevents a privileged insider attack.

• •

**RAMHU is resistant to stolen attack.

Proof 2:** In the first case, The intruder ($I$) steals a legitimate user device (such as a laptop) that contains a client application. In our scheme, user’s $PW_{i}$, and $IDs$ are not stored on the user’s device, or in the client application. In addition, the private key is hidden and random for each authentication process by $C_{i}K_{pr_{i}}\oplus GM\oplus PW_{i}\oplus N_{C_{i}}$. Additionally, the Proof 1 shows that the $PW_{i}$ value cannot be extracted from the $tmpPW_{i}$. If $I$ is $II$, he/she also cannot use his/her $IDs$ and $PW_{i}$ to access information or other user data because both $CS$ and $AS$ perform matching $IDs$, and $PW_{i}$ to determine user-related information and data. In the second case, the attacker steals only client application. $I$ cannot use the application on another device because it does not have $OTP_{i}$ or original MAC, which prevents the application from being used on another device even if $I$ knows the $IDs$ and $PW_{i}$. The original MAC mechanism ($C_{i}Sig_{1}=h(CM\|N_{C_{i}}\|TS_{C_{i}}$) prevents the fake authentication request from being verified in the server because $I$ cannot generate an original MAC address ($CM$) in $C_{i}Sig_{1}$. Thus, RAMHU is resistant to stolen attack.

• •

**RAMHU resists replay attack.

Proof 3:** $I$ tries to get a login/registration/authentication request for a legitimate user to send it later and thus, gains access to the network. This case is infeasible in our scheme because all entities ($C_{i}$, $CS$, and $AS$) use timestamp (such as $TS_{CS}-TS_{C_{i}}\leq\triangle T$, where $\triangle T$ is the maximum transfer delay rate) that prevents the attacker from sending the authentication request at a later time. Furthermore, signatures and random nonces are not usable the next times. Hence, RAMHU successfully resists replay attack.

• •

**RAMHU overcomes the MITM attack.

Proof 4:** Assume that an $I$ attempts to intercept encrypted login/authentication requests (such as $Enc_{i}(TS_{C_{i}}\|N_{C_{i}}\|$ $CiSig_{1}\|UP^{CS}_{C_{i}}\|MP^{CS}_{C_{i}}\|tmpPW_{i}\|CiSig_{2})$) among network entities, and then modifies or replaces these requests with his/her messages to send to network entities. However, the attacker cannot replace exchanged requests among $C_{i}$, $CS$, and $AS$ because, first, he/she does not know the private keys ($C_{i}K_{pr_{i}}$, $CSK_{pr_{i}}$, $ASK_{pr_{i}}$) and therefore, the decryption process is computationally infeasible with 256 bits key length and difficulty in solving ECDLP. Second, mutual authentication with PHOTON-256 signatures prevents the modification of requests between RAMHU’s entities. As a result, RAMHU gracefully overcomes the MITM attack.

• •

**RAMHU is safe against guessing attack.

Proof 5:** Assume that an external intruder ($EI$) was able to penetrate the encryption ($Enc_{i}$) between $C_{i}$ and $CS$ (from Proof 4, this assumption is infeasible). This $EI$ tries to guess $PW_{i}$ in a login request to use it to access the network as a legitimate user. $EI$ cannot detect $PW_{i}$ for any authorised user (either on-line or off-line) because he/she does not know the configured process to protect $PW_{i}$ ($tmpPWi=PW_{i}\oplus N_{C_{i}}\oplus GM\oplus C_{i}Sig_{1}$) and does not know the MAC address for that user and thus, the process of deriving $PW_{i}$ is infeasible (Proof 1). It is an extremely difficult process to guess $PW_{i}$ from the $tmpPW_{i}$, which is 64 hex (256 bit). In addition, $EI$ cannot detect $UID_{i}$ and $MID_{i}$ for any legitimate user because of the use of multi pseudonyms mechanism for users and medical centres instead of sending real information to legitimate users. As a result, RAMHU is safe against guessing attack.

• •

**RAMHU withstands against client impersonation attack.

Proof 6:** Assume that an attacker tries to impersonate a login request (such as $Enc_{i}$ = $TS_{C_{i}}\|N_{C_{i}}$ $\|CiSig_{1}\|$ $UP^{CS}_{C_{i}}\|MP^{CS}_{C_{i}}\|tmpPW_{i}\|CiSig_{2}$) for a legitimate user. This $I$ can create $TS_{C_{i}}$ and $N_{C_{i}}$ but does not know $PW_{i}$ and $C_{i}K_{pr_{i}}$ (Proofs 1, and 4) for the legitimate user, namely, $I$ cannot impersonate the user identity. $I$ also tries to impersonate the legitimate user’s device by programmatically changing the MAC address to a legitimate one to gain access to the network. This case is infeasible because the original MAC check ($CM$) in $CiSig_{1}=h(CM\|N_{C_{i}}\|TS_{C_{i}})$ detects the attacker’s attempt to mimic the legitimate user’s device (as in Proof 2). Therefore, RAMHU withstands against instances of impersonating the user’s identity and device.

• •

**RAMHU resists server impersonation attack.

Proof 7:** Assume that an $I$ traps login requests from $C_{i}$ to $CS$. The attacker tries to deceive $C_{i}$ by sending fake requests to $C_{i}$ in order to inform them that he is a legitimate server. $I$ needs the private key for CS to decrypt and to accomplish the attack. Mutual authentication prevents $I$ from impersonating $CS$’s requests (such as $Enc_{i}(TS_{CS}\|N_{CS}\|UP_{CS}^{C_{i}}\|MP_{CS}^{C_{i}}\|CSSig_{5})$) and sending them to $C_{i}$. This mechanism ensures that $C_{i}$ deals with legitimate $CS$. Consequently, our protocol effectively resists server impersonation attack.

• •

**RAMHU resists DoS attack.

Proof 8:** In order for $I$ to execute a DoS attack against $CS$ and $AS$, he/she needs to decrypt the login request and change its data or send the same request multiple times for destroying servers. However, in the first case, decryption and change of signatures are infeasible as in Proofs 2 and 4. $CS$ checks signature validity and rejects login requests containing fake signatures, and $I$ cannot execute a collision or preimage attack because PHOTON-256 supplies PR, SPR, and CR. In the second case, the attacker sends the same request multiple times. This status is infeasible because CS or AS checks timestamp ($TS_{C_{i}}$, $TS_{CS}$, $TS_{AS}$) for each login/authentication request and eliminates all late requests (Proof 3) without checking the other security parameters such as $PW_{i}$, $CM$, and multi pseudonyms. In case $I$ can break the encryption, he/she can change timestamp and nonce but cannot tamper with the signatures. RAMHU prevents this condition during $C_{i}Sig_{1}$ and does not need to check the remaining security parameters. Therefore, RAMHU successfully resists DoS attack.

• •

**RAMHU is secure against password change attack.

Proof 9:** Assume that an $I$ intercepts a request to change $PW_{i}$ between $C_{i}$ and $CS$. When $I$ obtains an encrypted password update request (such as $Enc_{i}(TS_{C_{i}}\|NC_{1}\|NC_{2}\|NC_{3}\|UP_{C_{i}}^{CS}\|$ $MP_{C_{i}}^{CS}\|$ $tmp\_oldPW_{i}\|$ $tmp\_newPW_{i}\|$ $C_{i}Sig_{1})$). If $I$ can decrypt (this process is infeasible as in Proofs 1, and 4), he/she will find a temporary passwords and cannot derive new $PW_{i}$ because it depends on the $C_{i}Sig_{1}=h(TS_{C_{i}}\|NC_{1}\|UP_{C_{i}}^{CS}\|$ $MP_{C_{i}}^{CS}\|oldPW_{i})$. The signature operation ($C_{i}Sig_{1}$) is based on the old $PW_{i}$ which is not explicitly sent to $CS$ in this protocol. $I$ does not know old $PW_{i}$ and therefore, he/she cannot create a signature to complete the $PW_{i}$ change process. Thereupon, RAMHU provides a reliable solution against password change attack.

• •

**RAMHU is resistant to eavesdropping attack.

Proof 10:** Assume that an $I$ eavesdrops login/authentication requests to gain information about user authentication and access to the network. However, in our scheme, $I$ will not benefit from requests that are intercepted because RAMHU uses ECIES algorithm with key 256 bits to encrypt authentication information. The attacker can only decrypt requests by deriving private keys and this operation is infeasible (as in Proofs 1, and 2) due to key length, and random encryption with nonces (anonymity). Therefore, our protocol is resistant to eavesdropping attack.

• •

**RAMHU resists traceability attack.

Proof 11:** $I$ attempts to collect as many login/authentication requests as possible and then performs an analysis of those requests that helps him/her to perform user identity tracing. When an $I$ succeeds in tracking user requests, he/she can detect and distinguish patients’ data. All exchanged requests among RAMHU’s entities do not contain direct users’ information (such as username). RAMHU replaces the real user $ID_{s}$ ($UID_{i}$ and $MID_{i}$) with pseudonyms. Our protocol uses multi pseudonyms ($UP_{C_{i}}^{CS}$, $UP_{CS}^{AS}$, $UP_{AS}^{CS}$, and $UP_{CS}^{C_{i}}$ for users and $MP_{C_{i}}^{CS}$, $MP_{CS}^{AS}$, $MP_{AS}^{CS}$, and $MP_{CS}^{C_{i}}$ for medical centres) to prevent attackers from tracking user requests and revealing their identities when transferred between RAMHU entities ($C_{i}$, $CS$, and $AS$). Hence, RAMHU resists traceability attack.

• •

**RAMHU prevents revocation attack.

Proof 12:** Assume that an $I$ tries to penetrate a revocation request. The attacker tries to analyse the request and use it to prevent users from accessing the network’s services. Depending on Proofs 1, 5, and 11, the attacker cannot extract or distinguish $UID_{i}$, $MID_{i}$ and $PW_{i}$ from the revocation request. The attacker does not know and cannot extract a reason from the $tmpRR_{i}$, which is based on the values of $RR_{i}$, $N_{C_{2}}$, and $C_{i}Sig_{1}$. In Proofs 2 and 8, $I$ cannot perform collision, preimage, and second preimage attacks against the PHOTON-256 algorithm. Thus, our protocol prevents penetration of revocation request.

• •

**RAMHU resists verifier attack.

Proof 13:** Assume that $I$ tries to penetrate the datasets in $CS$. If the attacker is $EI$, he/she cannot penetrate datasets because he/she does not have a $K_{pr}$, $UID$, $MID$, $OTP$, and $PW_{i}$. If the attacker is $II$, when he penetrates datasets in $CS$ and wants to impersonate another user’s identity, first, he/she cannot distinguish this information for a particular user because the real information for users is stored in $AS$. Second, since $CS$ does not contain passwords’ dataset, $II$ will not benefit from hacking datasets such as pseudonyms and cannot create a request and send it to $AS$ because it does not know users’ passwords. Therefore, RAMHU resists verifier attack meritoriously.

• •

**RAMHU resists leakage attack.

Proof 14:** Suppose that $I$ listens to some exchanged requests among $C_{i}$, $CS$, and $AS$ and tries to find any information that helps him/her to penetrate network authentication such as sending an ID explicitly, or sending a password with weak encryption. Exchanged requests between RAMHU entities such as a password update request ($Enc_{i}(TS_{C_{i}}\|N_{C_{1}}\|N_{C_{2}}$ $\|N_{C_{3}}$ $\|UP_{C_{i}}^{CS}\|MP_{C_{i}}^{CS}\|$ $tmp\_oldPW_{i}\|$ $tmp\_newPW_{i}\|C_{i}Sig_{1})$) show that $I$ does not receive any leaked real information for users during transmission, such as $IDs$ and $PW_{i}$ (all information is anonymous and hidden) that could be useful in penetrating the HC network. Therefore, RAMHU resists leakage attack.

5.2 Experimental Security Analysis

To ensure that authentication schemes work correctly and are authenticated, these schemes require a formal tool to detect the robustness of users’ authentication in the network. We provide the proposed scheme simulation using the AVISPA tool to verify our scheme, whether safe or unsafe. Our simulations are based on the AVISPA tool with the current version v.1.1 (13/02/2006) available on the website in [58]. This tool has been widely used and accepted by researchers in recent years [59, 60]. It has been used to check security problems and ensure that known attacks are not able to penetrate users’ authentication information.

5.2.1 AVISPA Description

After designing any authentication protocol, this protocol should be checked and its accuracy verified under a test model such as the Dolev-Yao (dy) to analyse, trace and detect the possibility of attack theoretically. However, this analysis needs to be simulated in a practical manner to detect errors and hidden traces of the authentication protocol designer, statistics and accurate results, checking several techniques on the same protocol. The AVISPA tool provides the features listed above as well as the ease, robustness, and applicability of this tool to implement authentication protocols [61].

The AVISPA tool is a push-button, testing/proofing model and is based on HLPSL language. This language uses directives and expressive terms to represent security procedures. It is integrated with four backends that are the On-the-Fly Model-Checker (OFMC), the Constraint-Logic-based Attack Searcher (CL-AtSe), the SAT-based Model-Checker (SATMC), and (Tree Automata based on Automatic Approximations for the Analysis of Security Protocols (TA4SP) to perform the simulation in AVISPA. Each backend gives the result of simulation analysis statistics that is different from the other [58]. SATMC and TA4SP backends do not work with a security protocol that implements the XoR gateway; therefore, we relied on OFMC and CL-AtSe backends to simulate RAMHU. To implement the authentication protocol in AVISPA, this protocol should be first written in HLPSL and then converts to the low-level language. The latter is read directly by the backends, which is an intermediate format (IF) by the hlpsl2if compiler. Then, it converts to an output format (OF) to extract and describe the result of analysis by one of four backends. The result of the analysis accurately describes that the protocol is safe or not safe with some statistical numbers. HLPSL is modular, and role-oriented. This language allows the completion of authentication protocol procedures as well as intruder actions. To represent authentication scenarios and build simulation structures, HLPSL uses roles, including basic roles such as clients and servers (clients, centralServer, and attributesServer), and composition (session and environment) roles that control the sequence of sending and receiving actions between clients and servers. In addition, communication channels between network entities are governed by the dy model. Many basic types used in HLPSL to represent variables, constants, and algorithms (symmetric/asymmetric/hash) such as agent, public_key, message, text, nat, const, and hash_func; in addition to some symbols and terms that have shown in Table 5, more details are provided in [58]. The authentication protocol in AVISPA depends on security features in the goal specification. Each protocol contains a set of goals (authentication and secret) in authenticating each party with the other. The goals in secrecy_of demonstrate that secrets are not exposed or hacked to non-intended entities. While the goals in authentication_on demonstrate that strong authentication has been applied between entities based on witness and request.

5.2.2 Proposed Scheme with AVISPA

In this section, we will illustrate the simulation of RAMHU in the AVISPA tool using HLPSL language. Our scheme depends on three core roles: clienti, centralServer, and attributesServer played by $C_{i}$, $CS$ and $AS$ respectively. In addition, it includes the supporting roles such as session, and environment, goal specification section. Each role contains parameters, variables, and local constants. Each basic role contains a transition section that indicates the sequence of communication among entities. Each supporting role contains a composition section that indicates the binding of roles and sessions. Asymmetric encryption has been implemented between scheme entities ($C_{i}$, $CS$, and $AS$) during public key exchange ($KC_{pu}$, $KCS_{pu}$, and $KAS_{pu}$) to perform confidentiality. Moreover, mutual authentication has used to ensure the legitimacy of related parties in the protocols of the proposed scheme (initial setup, registration, login, and authentication). Moreover, it uses nonces ($N_{c}$, $N_{cs}$, and $N_{as}$) and timestamp ($TS_{c}$, $TS_{cs}$, $TS_{as}$) to support the features of anonymity and freshness. Our scheme accomplishes 10 secrecy goals and 6 authentication goals as noted in the goal section in Figure 11.

The authentication process begins by sending requests from clients to the server. Therefore, the $client_{i}$ role includes the start signal as shown in Figure 9. $C_{i}$ receives the start signal and changes the state flag (State variable) from 0 to 1. It replaces $UID$ and $MID$ with $UP_{c}$ and $MP_{c}$ and calculates the timestamp ($TS_{c}^{\prime}$) and new nonce ($N_{c}^{\prime}$) by the new() operation. After that, it computes the signatures ($C_{i}Sig_{1}$ and $C_{i}Sig_{2}$), as well as the password hiding process as calculated in the computation operation of the $TmpPW$ parameter. It encrypts the registration and login request ($TS_{c}^{\prime}$, $N_{c}^{\prime}$, $GM^{\prime}$, $C_{i}Sig_{1}^{\prime}$, $UP_{c}^{\prime}$, $MP_{c}^{\prime}$, $OTP_{i}$, $Tmp\_PW^{\prime}$, and $C_{i}Sig_{2}^{\prime}$) by the public key ($KCS_{pu}$) to establish a reliable communication with $CS$. $C_{i}$ sends the request to $CS$ where the transmission process is performed by the SND() operation. It achieves a set of secret goals ($sec1$ to $sec6$) with both $CS$ and $AS$; these secrets have been only known and kept by the intended parties. For instance in $sec1$, $UID$, $MID$, and $PW$ have been known and kept only to $C_{i}$, and $AS$. While in $sec3$ $GM$, and $CM$ have been known and kept only to $C_{i}$ and $CS$, since these parameters are not transmitted directly during the transition of information between network parties such as $PW$ implicitly is in the computation of $TmpPW$ and $CM$ is implicitly in $C_{i}Sig_{1}$. $C_{i}$ also achieves the goal of authentication using statement (witness) with parameters ($C_{i}$, $CS$, $ci\_cs\_auth2$, $N_{cs}$, $TS_{c}$). Namely, $C_{i}$ is a witness that the security parameters ($N_{cs}$, $TS_{c}$) are fresh and correct. $CS$ uses a statement (request) to validate parameters with the strong authentication goal ($ci\_cs\_auth2$) specified in the goal section (Figure 12). $C_{i}$ receives the authentication response by the RCV () operation and sent from $AS$ by $CS$. Then, $C_{i}$ decrypts the response using its private key to verify the security parameters. If all security parameters are verified correctly, $C_{i}$ performs the mutual authentication process securely.

As shown in Figure 9, $CS$ receives a registration and login request by RCV () operation in state 0. It decrypts request with its private key and then checks the parameters and signatures to accomplish secret and authentication goals. CS changes the state signal from 0 to 1 and constructs an authentication request based on the security parameters ($TS_{cs}^{\prime}$, $N_{cs}^{\prime}$, $UP_{cs}$, $MP_{cs}$, $CSSig_{3}$, and $TmpPW$) and encrypts it by the public key of $AS$. $CS$ performs strong authentication with $AS$ during witness ($CS$, $AS$, $as\_cs\_auth4$, $TS_{cs}^{\prime}$, $N_{cs}^{\prime}$) to accomplish the authentication goal ($as\_cs\_auth4$) based on timestamp and fresh nonce and validated in $AS$ by statement (request). In state 1, $CS$ receives an authentication response from $AS$ and checks the security parameters after decryption with its private key. It changes the state signal to 2 and then constructs the authentication response to $C_{i}$. $CS$ sends response with two strong authentication goals ($cs\_ci\_auth1$ and $cs\_ci\_auth5$) based on the security parameters ($N_{c}$, $TS_{cs}$, $TmpPW$, and $OTP_{i}$).

$AS$ receives the authentication request and decrypts it with the private key as shown in Figure 11. It accomplishes 5 secret goals, and accomplishes two authentication goals ($as\_cs\_auth4$ and $as\_cs\_auth6$) based on $TS_{cs}^{\prime}$, $N_{cs}^{\prime}$, and $PW^{\prime}$. It constructs the authentication response and establishes strong authentication when validating parameters ($TS_{as}$, $N_{cs}^{\prime}$, and $PW^{\prime}$) in $CS$. Figure 11 displays the roles of session, environment, and goal section. In the session role, a composition process has been performed for the three roles ($clienti$, $centralServer$, and $attributeServer$). This role specifies the transmit and receive channels in the dy model. In the environment role, the security parameters, the goals specified in the goal section, and the known information for the intruder ($intruder\_knowledge$) have been defined. In this role, one or more sessions are composed. We tested our scheme with sessions for replay, MITM, and impersonating attacks. We assumed that an intruder ($I$) creates a public key ($ki$) and has knowledge of the public keys ($kCpu$, $kCSpu$, and $kASpu$) of legitimate entities in the network. The intruder attempts to resend the registration/login or authentication requests later, intercept/modify these requests, or impersonate the participating entities using $i\_ci$, $i\_cs$, and $i\_as$ constants rather than $ci$, $cs$, and $as$. The results section shows that these attacks cannot penetrate the security goals in our scheme.

5.2.3 Simulation Results

In this section, the simulation results in the AVISPA tool are based on two backends (OFMC, and CL-AtSe). Figure 13 shows the simulation result with the OFMC backend and Figure 13 displays the simulation result with the CL-AtSe backend. From the results shown in Figure 13 and Figure 13, our scheme clearly and accurately shows the SAFE result in the SUMMARY section, bounded number of sessions in the DETAILS section, the goals of the scheme achieved (as_specified) in the GOAL section as well as statistical numbers such as time, number of nodes, and analysed states in the STATISTICS section for both figures. Based on these results, we note that our scheme is capable of preventing passive and active attacks such as replay, MITM, and impersonating. Thus, the goals of the scheme in Figure 11 achieved to prevent the violation of legitimate user information in the network authentication.

6 Conclusion and Future Work

In this paper, we found that existing healthcare applications were vulnerable to weak security against some known attacks. Towards this end, we proposed a new robust authentication protocol (RAMHU) to prevent internal, external, passive, and active attacks. Our scheme uses multi pseudonyms for both users and medical centres to prevent the transmission of real information in the authentication request and MAC address to prevent counterfeit devices from connecting to the network. The lightweight encryption and signature algorithms (as described in Section 3) is used to ensure that RAMHU’s efficient interaction with user requests is ensured. In addition, we provided a formal and informal security analysis to demonstrate the effectiveness of RAMHU in repelling known attacks. The RAMHU scheme provides a high-level security that maintains authentication information for users against various attacks. Future directions for further the development of this scheme are as follows:

RAMHU requires strong authorization to support patient data exchange after user authentication. We need a mechanism that supports role-based and attribute-based privileges (e.g., doctor, nurse, patient, advisor, researcher, and emergency) to access patients’ data on a data server ($DS$). We intend to use authorization policies with signatures to ensure proper authorization of access to the data repository. 2. 2.

Our scheme uses lightweight and efficient performance algorithms that, according to many researchers, have shown that ECIES and PHOTON are efficient encryption and signature algorithms, respectively. We intend to evaluate RAMHU in terms of efficiency and discovery of performance standards such as end-to-end request delay, throughput, and error rate. 3. 3.

We intend to use the wireless sensor network (WSN) to collect patients’ data and send it to $DS$. However, collecting and storing data in $DS$ requires the use of encryption and signature algorithms against known attacks.

Data Availability

No data were used to support this study.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This research did not receive specific funding but was performed as part of the employment of the authors.