Table of Contents Author Guidelines Submit a Manuscript
Security and Communication Networks
Volume 2019, Article ID 3263902, 26 pages
Research Article

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

1Thi-Qar University, Nasiriyah 64001, Iraq
2Faculty of Health, Engineering and Sciences, University of Southern Queensland, Toowoomba, QLD 4350, Australia

Correspondence should be addressed to Mishall Al-Zubaidie; ua.ude.qsu.liamu@1080701u

Received 1 December 2018; Accepted 17 February 2019; Published 17 March 2019

Academic Editor: Huaizhi Li

Copyright © 2019 Mishall Al-Zubaidie et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.


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 authorised 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 the server and clients. This model utilizes an Elliptic Curve Integrated Encryption Scheme (ECIES) and PHOTON to achieve strong security and good overall performance. RAMHU relies on multiple-pseudonym, 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 demonstrate that our model offers a high level of security in repelling a wide variety of possible attacks.

1. Introduction

A lack of security and confidentiality of information and data used by healthcare (HC) applications remains the main problem that limits the wide spread 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 with 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 [47]. 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 the 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:(i)Penetration attacks on HC data in the United States’ hospitals occurred (2013). These attacks revealed 85.4% of the protected health information (PHI) of the 5 largest incidents for patients’ records [13](ii)Apple Health (Medicaid) was exposed to data breach (2016). This attack revealed 370,000 records of users (Washington state) [14](iii)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 signatures 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 the 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 protocol in HC applications should provide mutual authentication, resistance to known attacks such as man-in-the-middle (MITM), eavesdropping, tracing, replay, impersonation, guessing, and 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 summarised as follows:(i)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(ii)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(iii)RAMHU uses a multiple-pseudonym 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)(iv)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(v)RAMHU improves the mutual authentication between the server and clients to prevent spoofing and impersonation attacks by either a fake server or client. This prevents external attacks intended to deceive trusted parties(vi)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. The threat model and basic concepts about the techniques used in RAMHU are 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 the 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 over 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 was 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 [2628], 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 a shared key to implement an 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. [23] 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’s (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 [24]. 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 for integrity. In addition, the 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. [25] 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 a separation server (attributes server) for users’ information and also only 5 lightweight hash operations in the central server.

Cloud-assisted conditional privacy preserving authentication (CACPPA) [7] was proposed to authenticate the network’s nodes. This scheme used ECIES and the Elliptic Curve Digital Signature Algorithm (ECDSA) 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, the 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 a 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 and, 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

An authentication mechanism specifies 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 been 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 a WLAN or the Internet. The dy model is an efficient and practical way to illustrate security protocols in the real world. In addition, it is a formal exemplar 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 the attributes server () is trustworthy. It is safe against repository penetration attacks. We assume threats in our model as follows:(i)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(ii)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(iii)The attacker can execute a forgery or masquerading attack in an attempt to penetrate the authentication process(iv)A legitimate user can perform a privileged insider attack based on his/her legitimacy in the network(v)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

(i) 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 an 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 Curve 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

Table 1: Keys sizes and some information for asymmetric algorithms.
Figure 1: Arithmetic operations in ECC hierarchy.

(ii) Lightweight Hash-Function Algorithm. The hash function has been used to generate signatures for authentication requests. PHOTON is a lightweight hash function and extremely suitable for projects that require a robust and reliable signature. This algorithm is based on a spongelike construction and AES-like primitive for domain extension and permutation efficiency [3840]. 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 a 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, 4146]. 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: Comparison of lightweight hash function algorithms.

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 with 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

(iii) One-Time Password (OTP). The OTP is a way to authenticate legitimate users by generating a passcode or nonce only once in a specified time. It will not be applicable the next times for authentication. The 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, an 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 an OTP as part of an authentication request. If the authentication process is valid, the server will delete the OTP from the dataset and will not accept it in the future. The OTP is a powerful mechanism to mitigate the risk of hackers’ communication in the network. In this project, we apply an 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

(iv) 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 the client and server. In RAMHU, we adopt the mechanism of mutual authentication in the preservation of users’ information and data

(v) Media Access Control (MAC) Address. A MAC address has been 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 48 bits. It is divided into six octets and written in hexadecimals such as “8C: 70: 5A: 41: 49: BC.” This address is a unique identifier (no duplicate address twice) for a device defined as global and persistent [51]. This address is used in WLAN 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 the 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 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.

Table 3: Paper’s notations.
4.1. Network Model

The RAMHU model consists of four entities, as shown in Figure 2:(1)Client (): This entity includes patients, relatives of patients, and HC providers such as doctors, researchers, emergency practitioners, advisors, and nurses(2)Central server (): This entity is a gateway to authenticate users with the attributes server and to authorise the data server(3)Attributes server (): This entity contains users’ real information as well as multiple pseudonyms. The authentication process requires verifying the association of the actual information with the multiple pseudonyms in this entity(4)Data server (): This entity contains users’ data as well as multiple 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

Figure 2: General network model.

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

4.2. Security Goals

To build a robust authentication scheme, RAMHU adopts the following security requirements:(i) 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(ii) 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 [10, 57]. RAMHU performs a PHOTON to prevent any process of modifying the user authentication information in HC applications(iii) Nonrepudiation: This requirement prevents both the 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(iv) 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 analyse 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(v) Pseudonym: This requirement denotes the provision of a mechanism to connect nonreal 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 multiple-pseudonym mechanism to prevent and separate the association with real information(vi) 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(vii) 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, and authenticate each other to prevent masquerading and impersonating attacks(viii) 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 [24](ix) 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

The 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:(i)Each legitimate user receives a client application from the authorised system provider(ii)Each legitimate user receives a (that can be changed later) and a random to be used in the first registration(iii)All entities (, , and ) should create public and private keys ( (, ), (, ), and (, )) to be used to validate the authentication request. All entities choose an elliptic curve over a prime field (where = 256) and base point on curve. Each entity selects a private key randomly and generates the public key during the implementation of scalar multiplication ()(iv)All entities broadcast the public key (, , and ) to use in ECIES’s encryption operations

4.3.2. Registration and Login Protocol

Patients and HC providers () should complete the registration and login protocol with 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 of the user security parameters such as pseudonyms, MAC address, and ; this protocol accomplishes the following steps (Figure 3 shows the registration and login protocol and Figure 4 shows the login protocol):

Figure 3: Registration and login protocol.
Figure 4: Login protocol.

Side(i)The user enters (such as his/her name), (such as medical centre name), and and for registration and login while only entering , , and for the login protocol the next times to the client () application. replaces with user’s pseudonym () and with medical centre pseudonym () to protect the authentication information when moving from to . generates a timestamp () to be used to verify the sending time of the registration/login request in (ii) gets a MAC address (GM) by entering its IP (Internet protocol) address. The process of checking MAC () is performed by 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 application. If the result is identical to , it means that the MAC address is native ( = “”). In the Windows system, searches for string value “NetworkAddress” in the path of the system registry (“"). If NetworkAddress = null, = “"; otherwise = “". The send is encrypted with a registration/login request while is implicitly sent with the signature value (). In only the login protocol, needs to extract a private key from the temporary key, MAC address, password, and random nonce through . generates a random nonce () to change signature and encryption data and add anonymity to the registration/login request(iii) performs two signatures using the PHOTON-256 algorithm to protect information from modification. The first signature includes the parameters check MAC, nonce, and timestamp ()). The second signature includes all the authentication parameters of the gotten MAC, nonce, timestamp, first signature, pseudonyms, one-time password, and password ( )). In the login protocol, is not added to the signature(iv) computes a temporary value () of when moving from to (v) uses ECIES to encrypt and hide all the data of this request ( ). In the login protocol, and are not added to the encryption as in Figure 4. After that, sends the registration and login request or login to to complete the authentication protocol. Then hides the private key by

Side(i)Upon receiving a registration and login request or login request, decrypts this request using ECIES’s and . It checks the timestamp (- ) to make sure that this request arrived at an appropriate time and without delay(ii)In the registration and login protocol, examines the random in the dataset. If exists, then the user is legitimate for the registration process. After that, deletes from the dataset to prevent it from being used the next times. If is not found, it discards the connection. In the login protocol, examines and and then tests their association with the MAC address in the dataset. If is found, completes the steps of this protocol; otherwise, it cancels the connection(iii) needs to ensure that the user’s device is legitimate within the network. computes the signature value to make sure that the MAC address is native and nonmodified ((“Real_MAC”∥). It examines the result of the computed signature () with ’s signature (). If the signatures results are identical, then the device is legitimate and the MAC address did not change. In the registration and login protocol, stores this address in the dataset for use and checks the next times in the login protocol(iv) performs the computation operation to extract the value and then uses this value to produce a second signature ()(v) computes a second signature operation (= )) to guarantee that all the encrypted information is not changed. Then, it compares the computed signature () with the received signature in the request (). If the signatures are identical, then the information for this request is unchanged or not tampered with. In the login protocol, and are not added to the signature. At this point, prepares to send the user’s authentication request to

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 ’s datasets. Note that the users’ information (such as name, age, address, mobile number, and passwords) is stored in a separate server (AS) and multiple pseudonyms are used to prevent detection and tracking of users’ information. This protocol is illustrated in the following steps (Figure 5 shows the authentication protocol in RAMHU):

Figure 5: Authentication protocol.

Side(i) computes a new timestamp () to ensure the fresh authentication request(ii) replaces ’s pseudonyms ( and ) with ’s pseudonyms ( and ) to prevent attackers from tracking the authentication request. It generates random nonce () to ensure an anonymous authentication request(iii) signs security parameters by PHOTON-256 ()) to prevent modification of authentication request information(iv) computes temporary by the computation of (v) encrypts information of authentication request ( ). It sends an authentication request to verify user’s information in

Side(i)Upon receiving the authentication request, decrypts that request using ECIES’s and to obtain the authentication information clearly(ii)It checks the timestamp by to ensure that the authentication request is not delayed. checks the pseudonyms ( and ) sent from CS and correlates them with the user’s real identifier ( and ) in the datasets. extracts the user’s password from the equation . After that, it checks matching in the dataset. computes the value of the signature based on authentication information ()) by PHOTON-256. compares the computed value of the signature () with the value of the received signature (). If the signature values are identical, the user’s information in the request for the signature is unmodified. At this point, considers this user to be legitimate and reliable(iii) prepares a response to authenticate the request of that user. It computes a new timestamp ( = new ) to prevent delayed or replayed requests at later times. replaces ’s pseudonyms ( and ) received with ’s pseudonyms ( and ) to hide users’ information. It generates a new random nonce () to add anonymity and prevent attacks from encryption and signature analysis(iv) computes a signature () to prevent modifications of authentication response information(v) encrypts the authentication information ( ) and sends the authentication response to to complete the authentication process

Side(i) decrypts the authentication response () received from . It checks the timestamp value () to prevent late authentication responses. It examines and in datasets to complete the process of linking multiple pseudonyms to the user(ii) computes the signature for authentication response information. It compares the computed result of the signature () with the value of the received signature (). If the signature values match, then the authentication response information is unchanged(iii)After this point, initiates a login response request. It computes the value of new timestamp (). It replaces ’s pseudonyms ( and ) received with and . It generates a new random nonce () to hide encryption and signature information(iv) computes a new signature value () to protect login response information from modification(v) encrypts login response information () and sends this response to

Side(i) extracts his private key () from and decrypts the login request () received from (ii) checks the timestamp () to ensure that the login response is not late or replayed(iii) checks that ’s pseudonyms ( and ) are received in the dataset and associated with and . At this point, RAMHU applied multiple pseudonyms among model entities (, , and ) to prevent traceability in linking the real information of the user with pseudonyms(iv) calculates the value of the signature for login response information. It compares the result of the computed signature () and the value of the received signature (). If the signature values are identical, namely, the login response information is unmodified or not tampered with, accepts the login response; otherwise discards the login response. Then, hides its private key by 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 is important in any HC system for two reasons. First, it prevents the use of fixed for a long time which reduces the guessing attacks. Second, changing gives users more flexibility in choosing the appropriate . This process requires strict security measures to protect the new . RAMHU provides the legitimate user with a mechanism to change his/her password at any time. If the user wants to change his/her , the following illustration describes the new protection procedures in a secure manner (Figure 6 shows the password update protocol in RAMHU):(i) side: enters , , the old , and the new . It replaces and with pseudonyms to hide the user’s real information. calls the MAC address and then extracts the private key from to use in the encryption process of the password update request. generates three random nonces (, , and ) and computes a new timestamp (). computes the signature value ()) by PHOTON-256 based on the parameters of the password change request. It applies an anonymity mechanism to the old and new ( = and = ) to hide passwords and not explicitly send them in the change request. It encrypts the change request ( ) and sends it to ; then hides its private key by (ii) side: receives and decrypts a password update request (). It examines the timestamp to prevent delayed requests and examines and in datasets. extracts the old and new from and . Then, it computes the signature value () depending on , , , and to check the matching between and . Similarly, in the authentication protocol, computes and replaces pseudonyms. generates three nonces , , and and then computes the signature value ()) and hides the old and new by and . It encrypts the password update request with security parameters (, , , , , , , , and ) and sends to (iii) side: receives the password update request and decrypts () this request with and . It checks time delay and then it checks link pseudonyms with real information for users. It extracts the old from and then it checks the old in the dataset. It computes the signature value , and then it compares the calculated result () with the result of the received signature (). If they are identical, the signature is true; otherwise, rejects the change request. performs the calculation to obtain the new value. If all previous checks are validated, changes the old to the new

Figure 6: Password update protocol.
4.3.5. Revocation Protocol

Revocation in HC applications is used when a user finishes a task or to prevent attack. This protocol can be completed by or . For example, wants to cancel his/her 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 cancels his account after the completion of his duties. Additionally, 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 the authorities provider () to revoke his/her account information that is associated with his/her data (note that the patients’ data history remains stored in the 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 the revocation protocol in the side in RAMHU):

Figure 7: Revocation protocol.

Revocation from Side(i) enters , , and and then replaces with and with . It chooses the revocation reason () 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 256 bits in the dataset. computes the new , , , and . Then, performs the process of to add randomness for . Using this procedure is very useful in tightening security and distinguishing the roles of users (patients or professionals) in . It computes the signature “delete”). performs a computation to hide (). computes the temporary value of to hide the value. Additionally, it computes encryption ( ) and sends a revocation request to . Then, it hides a private key, in the same way, in the password update protocol(ii) decrypts () and computes the timestamp and examines and in the datasets. It obtains from the computation equation . It extracts from and checks matching in the dataset. computes the signature ( “delete”)) and then compares the results of the signatures. computes operation to use ’s signature in order to compare with the user’s . If all operations are achieved and validated correctly, sends a request to to check the pseudonym’s association with the real information and check . deletes association between pseudonyms and information and delete the user’s from the dataset. sends a MAC deletion request to . Upon receiving the MAC deletion request, decrypts this request and then checks security parameters and signature. If all operations are achieved and validated correctly, deletes the MAC address from the dataset. At this point, this user cannot perform an authentication process in RAMHU

Revocation from Side(i) deletes the association between user’s information and pseudonyms and in datasets. It sends an encrypted request ( to to delete the 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 resistance against various attacks.(i) RAMHU prevents a privileged insider attack.Proof 1: The internal intruder () needs to eavesdrop on authentication requests between and . 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-bit algorithm; cannot decrypt these requests with his/her private key. Second, if broke the encryption (which is impossible), he/she is unable to extract the value () in the login protocol because it is hidden and depends on the values of , , and where does not know the value of the legitimate user’s device, and the value depends on the value that is also not known to . Therefore, RAMHU prevents a privileged insider attack(ii) RAMHU is resistant to a stealing attack.Proof 2: In the first case, the intruder () steals a legitimate user’s device (such as a laptop) that contains a client application. In our scheme, the user’s and 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 . Additionally, Proof 1 shows that the value cannot be extracted from . If is , he/she also cannot use his/her and to access information or other user data because both and perform matching and to determine user-related information and data. In the second case, the attacker steals only the client application. cannot use the application on another device because it does not have or the original MAC, which prevents the application from being used on another device even if knows the and . The original MAC mechanism ()) prevents the fake authentication request from being verified in the server because cannot generate an original MAC address () in . Thus, RAMHU is resistant to a stealing attack(iii) RAMHU resists replay attack.Proof 3: 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 (, , and ) use a timestamp (such as , where 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(iv) RAMHU overcomes the MITM attack.Proof 4: Assume that an attempts to intercept encrypted login/authentication requests (such as ) 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 , , and because, first, he/she does not know the private keys (, , ) and, therefore, the decryption process is computationally infeasible with 256-bit 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(v) RAMHU is safe against guessing attack.Proof 5: Assume that an external intruder () was able to penetrate the encryption () between and (from Proof 4, this assumption is infeasible). This tries to guess in a login request to use it to access the network as a legitimate user. cannot detect for any authorised user (either on-line or off-line) because he/she does not know the configured process to protect () and does not know the MAC address for that user and, thus, the process of deriving is infeasible (Proof 1). It is an extremely difficult process to guess from , which is 64 hexes (256 bits). In addition, cannot detect and for any legitimate user because of the use of the multiple-pseudonym mechanism for users and medical centres instead of sending real information to legitimate users. As a result, RAMHU is safe against guessing attack(vi) RAMHU withstands client impersonation attack.Proof 6: Assume that an attacker tries to impersonate a login request (such as = ) for a legitimate user. This can create and but does not know and (Proofs 1 and 4) for the legitimate user; namely, cannot impersonate the user identity. 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 () in detects the attacker’s attempt to mimic the legitimate user’s device (as in Proof 2). Therefore, RAMHU withstands instances of impersonating the user’s identity and device(vii) RAMHU resists server impersonation attack.Proof 7: Assume that an traps login requests from to . The attacker tries to deceive by sending fake requests to in order to inform them that he is a legitimate server. needs the private key for CS to decrypt and to accomplish the attack. Mutual authentication prevents from impersonating ’s requests (such as ) and sending them to . This mechanism ensures that deals with legitimate . Consequently, our protocol effectively resists server impersonation attack(viii) RAMHU resists DoS attack.Proof 8: In order for to execute a DoS attack against and , 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. checks signature validity and rejects login requests containing fake signatures, and 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 the timestamp (, , ) for each login/authentication request and eliminates all late requests (Proof 3) without checking the other security parameters such as , , and multiple pseudonyms. In case can break the encryption, he/she can change the timestamp and nonce but cannot tamper with the signatures. RAMHU prevents this condition during and does not need to check the remaining security parameters. Therefore, RAMHU successfully resists DoS attack(ix) RAMHU is secure against password change attack.Proof 9: Assume that an intercepts a request to change between and . obtains an encrypted password update request (such as ). If can decrypt it (this process is infeasible as in Proofs 1 and 4), he/she will find a temporary password and cannot derive a new because it depends on . The signature operation () is based on the old which is not explicitly sent to in this protocol. does not know the old and, therefore, he/she cannot create a signature to complete the change process. Thereupon, RAMHU provides a reliable solution against password change attack(x) RAMHU is resistant to eavesdropping attack.Proof 10: Assume that an eavesdrops on login/authentication requests to gain information about user authentication and access to the network. However, in our scheme, will not benefit from requests that are intercepted because RAMHU uses the ECIES algorithm with a 256-bit key 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(xi) RAMHU resists traceability attack.Proof 11: 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 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 ( and ) with pseudonyms. Our protocol uses multiple pseudonyms (, , , and for users and , , , and for medical centres) to prevent attackers from tracking user requests and revealing their identities when they are transferred between RAMHU entities (, , and ). Hence, RAMHU resists traceability attack(xii) RAMHU prevents revocation attack.Proof 12: Assume that an 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 , , and from the revocation request. The attacker does not know and cannot extract a reason from , which is based on the values of , , and . In Proofs 2 and 8, cannot perform collision, preimage, and second preimage attacks against the PHOTON-256 algorithm. Thus, our protocol prevents penetration of revocation request(xiii) RAMHU resists verifier attack.Proof 13: Assume that tries to penetrate the datasets in . If the attacker is , he/she cannot penetrate datasets because he/she does not have , , , , and . If the attacker is , when he penetrates datasets in 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 . Second, since does not contain passwords’ dataset, will not benefit from hacking datasets such as pseudonyms and cannot create a request and send it to because it does not know users’ passwords. Therefore, RAMHU resists verifier attack meritoriously.(xiv)RAMHU resists leakage attackProof 14: Suppose that listens to some exchanged requests among , , and 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 ( ) show that does not receive any leaked real information for users during transmission such as and (all information is anonymous and hidden) that could be useful in penetrating the HC network. Therefore, RAMHU resists leakage attack

Table 4: Comparison of resistance in repelling the threats between RAMHU and existing schemes.
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 the 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]. The SATMC and TA4SP backends do not work with a security protocol that implements the XOR gateway; therefore, we relied on the 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 are 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 been 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 nonintended entities, while the goals in authentication_on demonstrate that strong authentication has been applied between entities based on witness and request.

Table 5: Some HLSPL’s symbols and statements.
5.2.2. Proposed Scheme with AVISPA

In this section, we will illustrate the simulation of RAMHU in the AVISPA tool using the HLPSL language. Our scheme depends on three core roles: clienti, centralServer, and attributesServer played by , , and , respectively. In addition, it includes the supporting roles such as session, environment, and 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 (, , and ) during public key exchange (, , and ) to perform confidentiality. Moreover, mutual authentication has been 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 (, , and ) and a timestamp (, , ) 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 role includes the start signal as shown in Figure 8. receives the start signal and changes the state flag (state variable) from 0 to 1. It replaces and with and and calculates the timestamp () and new nonce () by the new() operation. After that, it computes the signatures ( and ), as well as the password hiding process as calculated in the computation operation of the parameter. It encrypts the registration and login request (, , , , , , , , and ) by the public key () to establish a reliable communication with . sends the request to where the transmission process is performed by the SND() operation. It achieves a set of secret goals ( to ) with both and ; these secrets have been only known and kept by the intended parties. For instance in , , , and have been known and kept only to and , while in and have been known and kept only to and , since these parameters are not transmitted directly during the transition of information between network parties; for example, implicitly is in the computation of and is implicitly in . also achieves the goal of authentication using statement (witness) with parameters (, , , , ). Namely, is a witness that the security parameters (, ) are fresh and correct. uses a statement (request) to validate parameters with the strong authentication goal () specified in the goal section (Figure 12). receives the authentication response by the RCV () operation sent from by . Then, decrypts the response using its private key to verify the security parameters. If all security parameters are verified correctly, performs the mutual authentication process securely.

Figure 8: Client role in HLPSL.

As shown in Figure 9, receives a registration and login request by the RCV () operation in state 0. It decrypts the 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 (, , , , , and ) and encrypts it by the public key of . performs strong authentication with during witness (, , , , ) to accomplish the authentication goal () based on the timestamp and fresh nonce and validated in by statement (request). In state 1, receives an authentication response from 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 . sends response with two strong authentication goals ( and ) based on the security parameters (, , , and ).

Figure 9: Central server role in HLPSL.

receives the authentication request and decrypts it with the private key as shown in Figure 10. It accomplishes 5 secret goals and accomplishes two authentication goals ( and ) based on , , and . It constructs the authentication response and establishes strong authentication when validating parameters (, , and ) in . 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 (, , and ). 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 () 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 () creates a public key () and has knowledge of the public keys (, , and ) 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 , , and constants rather than , , and . The results section shows that these attacks cannot penetrate the security goals in our scheme.

Figure 10: Attributes server role in HLPSL.
Figure 11: Supporting roles in HLPSL.
Figure 12: Simulation result using OFMC.
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 12 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 Figures 12 and 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, and 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 are achieved to prevent the violation of legitimate user information in the network authentication.

Figure 13: Simulation result using CL-AtSe.

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 multiple pseudonyms for both users and medical centres to prevent the transmission of real information in the authentication request and a MAC address to prevent counterfeit devices from connecting to the network. The lightweight encryption and signature algorithms (as described in Section 3) are used to ensure that RAMHU’s efficient interaction with user requests is guaranteed. In addition, we provided formal and informal security analysis to demonstrate the effectiveness of RAMHU in repelling known attacks. The RAMHU scheme provides high-level security that maintains authentication information for users against various attacks. Future directions for furthering the development of this scheme are as follows:(1)RAMHU requires strong authorisation 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 (). We intend to use authorisation policies with signatures to ensure proper authorisation of access to the data repository(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)We intend to use the wireless sensor network (WSN) to collect patients’ data and send it to . However, collecting and storing data in requires the use of encryption and signature algorithms against known attacks

Data Availability

No data were used to support this study.


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

Conflicts of Interest

The authors declare that they have no conflicts of interest.


  1. D. He and S. Zeadally, “Authentication protocol for an ambient assisted living system,” IEEE Communications Magazine, vol. 53, no. 1, pp. 71–77, 2015. View at Publisher · View at Google Scholar · View at Scopus
  2. W. Sun, Z. Cai, Y. Li, F. Liu, S. Fang, and G. Wang, “Security and privacy in the medical internet of things: a review,” Security and Communication Networks, vol. 2018, Article ID 5978636, 9 pages, 2018. View at Google Scholar · View at Scopus
  3. S. J. Tipton, S. Forkey, and Y. B. Choi, “Toward proper authentication methods in electronic medical record access compliant to HIPAA and C.I.A. triangle,” Journal of Medical Systems, vol. 40, no. 4, pp. 1–8, 2016. View at Publisher · View at Google Scholar · View at Scopus
  4. H. Arshad, V. Teymoori, M. Nikooghadam, and H. Abbassi, “On the security of a two-factor authentication and key agreement scheme for telecare medicine information systems,” Journal of Medical Systems, vol. 39, no. 8, p. 76, 2015. View at Publisher · View at Google Scholar · View at Scopus
  5. A. K. Das, A. K. Sutrala, V. Odelu, and A. Goswami, “A secure smartcard-based anonymous user authentication scheme for healthcare applications using wireless medical sensor networks,” Wireless Personal Communications, vol. 94, no. 3, pp. 1899–1933, 2017. View at Publisher · View at Google Scholar · View at Scopus
  6. X. Li, J. Niu, S. Kumari, J. Liao, W. Liang, and M. K. Khan, “A new authentication protocol for healthcare applications using wireless medical sensor networks with user anonymity,” Security and Communication Networks, vol. 9, no. 15, pp. 2643–2655, 2016. View at Publisher · View at Google Scholar
  7. U. Rajput, F. Abbas, J. Wang, H. Eun, and H. Oh, “CACPPA: a cloud-assisted conditional privacy preserving authentication protocol for vanet,” in Proceedings of the 16th IEEE/ACM International Symposium on Cluster, Cloud, and Grid Computing, CCGrid 2016, pp. 434–442, Colombia, May 2016. View at Scopus
  8. Y. Yuehong, Y. Zeng, X. Chen, and Y. Fan, “The internet of things in healthcare: an overview,” Journal of Industrial Information Integration, vol. 1, pp. 3–13, 2016. View at Publisher · View at Google Scholar · View at Scopus
  9. J. Shen, Z. Gui, S. Ji, J. Shen, H. Tan, and Y. Tang, “Cloud-aided lightweight certificateless authentication protocol with anonymity for wireless body area networks,” Journal of Network and Computer Applications, vol. 106, pp. 117–123, 2018. View at Publisher · View at Google Scholar
  10. D. He, S. Zeadally, and L. Wu, “Certificateless public auditing scheme for cloud-assisted wireless body area networks,” IEEE Systems Journal, vol. 12, no. 1, pp. 64–73, 2018. View at Google Scholar
  11. M. Wazid, S. Zeadally, A. K. Das, and V. Odelu, “Analysis of security protocols for mobile healthcare,” Journal of Medical Systems, vol. 40, no. 11, p. 229, 2016. View at Google Scholar · View at Scopus
  12. N. M. Shrestha, A. Alsadoon, P. Prasad, L. Hourany, and A. Elchouemi, “Enhanced e-health framework for security and privacy in healthcare system,” in Proceedings of the 2016 Sixth International Conference on Digital Information Processing and Communications (ICDIPC), pp. 75–79, Beirut, Lebanon, April 2016. View at Publisher · View at Google Scholar
  13. P. Paganini, “Risks and cyber threats to the healthcare industry,” INFOSEC Institute, Tech. Rep., 2014,
  14. “Data breach for apple health (medicaid) managed care plan,” Washington State, Health Care Authority, Tech. Rep., 2016,
  15. J. Davis, “Ehr server hack threatens data of 14, 000 ivf clinic patients , healthcare IT News,” Tech. Rep., 2017,
  16. G. Manogaran, R. Varatharajan, D. Lopez, P. M. Kumar, R. Sundarasekar, and C. Thota, “A new architecture of Internet of Things and big data ecosystem for secured smart healthcare monitoring and alerting system,” Future Generation Computer Systems, vol. 82, pp. 375–387, 2018. View at Publisher · View at Google Scholar · View at Scopus
  17. D. Giri, T. Maitra, R. Amin, and P. D. Srivastava, “An efficient and robust RSA-based remote user authentication for telecare medical information systems,” Journal of Medical Systems, vol. 39, no. 1, p. 145, 2015. View at Publisher · View at Google Scholar · View at Scopus
  18. C.-H. Liu and Y.-F. Chung, “Secure user authentication scheme for wireless healthcare sensor networks,” Computers & Electrical Engineering, vol. 59, pp. 250–261, 2017. View at Publisher · View at Google Scholar
  19. P. Chandrakar and H. Om, “A secure and robust anonymous three-factor remote user authentication scheme for multi-server environment using ECC,” Computer Communications, vol. 110, pp. 26–34, 2017. View at Publisher · View at Google Scholar · View at Scopus
  20. S. Al-Janabi, I. Al-Shourbaji, M. Shojafar, and S. Shamshirband, “Survey of main challenges (security and privacy) in wireless body area networks for healthcare applications,” Egyptian Informatics Journal, vol. 18, no. 2, pp. 113–122, 2016. View at Publisher · View at Google Scholar · View at Scopus
  21. K.-H. Yeh, “A secure IoT-based healthcare system with body sensor networks,” IEEE Access, vol. 4, pp. 10288–10299, 2016. View at Publisher · View at Google Scholar · View at Scopus
  22. S. K. Shankar, A. S. Tomar, and G. K. Tak, “Secure medical data transmission by using ECC with mutual authentication in WSNs,” in Proceedings of the 4th International Conference on Eco-friendly Computing and Communication Systems, ICECCS 2015, vol. 70, pp. 455–461, India, December 2015. View at Scopus
  23. M. S. Farash, O. Nawaz, K. Mahmood, S. A. Chaudhry, and M. K. Khan, “A provably secure RFID authentication protocol based on elliptic curve for healthcare environments,” Journal of Medical Systems, vol. 40, no. 7, p. 165, 2016. View at Publisher · View at Google Scholar · View at Scopus
  24. N. Kumar, K. Kaur, S. C. Misra, and R. Iqbal, “An intelligent RFID-enabled authentication scheme for healthcare applications in vehicular mobile cloud,” Peer-to-Peer Networking and Applications, vol. 9, no. 5, pp. 824–840, 2016. View at Publisher · View at Google Scholar · View at Scopus
  25. Q. Jiang, M. K. Khan, X. Lu, J. Ma, and D. He, “A privacy preserving three-factor authentication protocol for e-health clouds,” The Journal of Supercomputing, vol. 72, no. 10, pp. 3826–3849, 2016. View at Google Scholar
  26. J. Timpner, D. Schürmann, and L. Wolf, “Trustworthy parking communities: helping your neighbor to find a space,” IEEE Transactions on Dependable and Secure Computing, vol. 13, no. 1, pp. 120–132, 2016. View at Publisher · View at Google Scholar · View at Scopus
  27. A. Sojka-Piotrowska and P. Langendoerfer, “Shortening the security parameters in lightweight WSN applications for IoT - Lessons learned,” in Proceedings of the 2017 IEEE International Conference on Pervasive Computing and Communications Workshops, PerCom Workshops 2017, pp. 636–641, March 2017. View at Scopus
  28. N. Meddah, A. Jebrane, and A. Toumanari, “Scalable lightweight ABAC scheme for secure sharing PHR in cloud computing,” in Proceedings of the International Conference on Advanced Information Technology, Services and Systems, vol. 25 of Lecture Notes in Networks and Systems, pp. 333–346, Springer, 2017. View at Publisher · View at Google Scholar
  29. D. Dolev and A. C.-C. Yao, “On the security of public key protocols,” IEEE Transactions on Information Theory, vol. 29, no. 2, pp. 198–208, 1983. View at Publisher · View at Google Scholar · View at MathSciNet
  30. T. R. Andel and A. Yasinsac, “Adaptive threat modeling for secure Ad Hoc routing protocols,” Electronic Notes in Theoretical Computer Science, vol. 197, no. 2, pp. 3–14, 2008. View at Publisher · View at Google Scholar · View at Scopus
  31. M. Imran, M. Rashid, and I. Shafi, “Lopez dahab based elliptic crypto processor (ECP) over gf (2 163) for low-area applications on FPGA,” in Proceedings of the 2018 International Conference on Engineering and Emerging Technologies (ICEET), pp. 1–6, Lahore, Pakistan, Feburary 2018. View at Publisher · View at Google Scholar
  32. M. B. Rafik and F. Mohammed, “The impact of ECC's scalar multiplication on wireless sensor networks,” in Proceedings of the 2013 11th International Symposium on Programming and Systems (ISPS), pp. 17–23, Algiers, Algeria, April 2013. View at Publisher · View at Google Scholar
  33. S. Singh, P. K. Sharma, S. Y. Moon, and J. H. Park, “Advanced lightweight encryption algorithms for IoT devices: survey, challenges and solutions,” Journal of Ambient Intelligence and Humanized Computing, pp. 1–18, 2017. View at Google Scholar · View at Scopus
  34. G. Nabil, K. Naziha, F. Lamia, and K. Lotfi, “Hardware implementation of elliptic curve digital signature algorithm (ECDSA) on Koblitz curves,” in Proceedings of the 2012 8th International Symposium on Communication Systems, Networks and Digital Signal Processing, CSNDSP 2012, pp. 1–6, July 2012. View at Scopus
  35. J. Shen, S. Chang, J. Shen, Q. Liu, and X. Sun, “A lightweight multi-layer authentication protocol for wireless body area networks,” Future Generation Computer Systems, vol. 78, pp. 956–963, 2018. View at Publisher · View at Google Scholar · View at Scopus
  36. E. Barker and Q. Dang, “Nist special publication 800-57 part 1, revision 4,” 2016.
  37. R. Harkanson and Y. Kim, “Applications of elliptic curve cryptography: a light introduction to elliptic curves and a survey of their applications,” in Proceedings of the 12th Annual Conference on Cyber and Information Security Research, pp. 1–7, April 2017. View at Publisher · View at Google Scholar
  38. P. Porambage, A. Braeken, C. Schmitt, A. Gurtov, M. Ylianttila, and B. Stiller, “Group key establishment for secure multicasting in IoT-enabled Wireless Sensor Networks,” in Proceedings of the 2015 IEEE 40th Conference on Local Computer Networks (LCN), pp. 482–485, Clearwater Beach, FL, October 2015. View at Publisher · View at Google Scholar
  39. N. Nalla Anandakumar, T. Peyrin, and A. Poschmann, “A very compact FPGA implementation of LED and PHOTON,” in Proceedings of the International Conference in Cryptology in India, vol. 8885, pp. 304–321, Springer, 2014. View at Publisher · View at Google Scholar · View at MathSciNet
  40. R. Ijaz and M. A. Pasha, “Area-efficient and high-throughput hardware implementations of TAV-128 hash function for resource-constrained IoT devices,” in Proceedings of the 2017 9th IEEE International Conference on Intelligent Data Acquisition and Advanced Computing Systems: Technology and Applications (IDAACS), pp. 832–835, Bucharest, September 2017. View at Publisher · View at Google Scholar
  41. J. Guo, T. Peyrin, and A. Poschmann, “The photon family of lightweight hash functions,” in Advances in Cryptology—CRYPTO 2011, vol. 6841 of Lecture Notes in Computer Science, pp. 222–239, Springer, Berlin, Germany, 2011. View at Publisher · View at Google Scholar
  42. A. Bogdanov, M. Knežević, G. Leander, D. Toz, K. Varıcı, and I. Verbauwhede, “spongent: a lightweight hash function,” in International Workshop on Cryptographic Hardware and Embedded Systems, vol. 6917, pp. 312–325, Springer, 2011. View at Publisher · View at Google Scholar
  43. T. P. Berger, J. D'Hayer, K. Marquet, M. Minier, and G. Thomas, “The GLUON family: a lightweight hash function family based on FCSRs,” in Proceedings of the International Conference on Cryptology in Africa, vol. 7374, pp. 306–323, Springer, 2012. View at Publisher · View at Google Scholar · View at MathSciNet
  44. E. B. Kavun and T. Yalcin, “A lightweight implementation of keccak hash function for radio-frequency identification applications,” in Proceedings of the International Workshop on Radio Frequency Identification: Security and Privacy Issues, vol. 6370, pp. 258–269, Springer, 2010. View at Publisher · View at Google Scholar
  45. H. Yoshida, D. Watanabe, K. Okeya et al., “Mame: a compression function with reduced hardware requirements,” in Proceedings of the International Workshop on Cryptographic Hardware and Embedded Systems, pp. 148–165, Springer, 2007.
  46. J.-P. Aumasson, L. Henzen, W. Meier, and M. Naya-Plasencia, “Quark: a lightweight hash,” in Proceedings of the International Workshop on Cryptographic Hardware and Embedded Systems, vol. 26, pp. 1–15, Springer, 2010.
  47. M. Naya-Plasencia and T. Peyrin, “Practical Cryptanalysis of ARMADILLO2,” in Fast Software Encryption, vol. 7549 of Lecture Notes in Computer Science, pp. 146–162, Springer, 2012. View at Publisher · View at Google Scholar
  48. M. A. Abdelraheem, “Estimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphers,” in Proceedings of the International Conference on Information Security and Cryptology, pp. 368–382, Springer, 2012.
  49. G. Zhang and M. Liu, “A distinguisher on present-like permutations with application to spongent,” Science China Information Sciences, vol. 60, no. 7, p. 072101, 2017. View at Google Scholar · View at Scopus
  50. C.-M. Chen, W. Fang, K.-H. Wang, and T.-Y. Wu, “Comments on “An improved secure and efficient password and chaos-based two-party key agreement protocol”,” Nonlinear Dynamics, vol. 87, no. 3, pp. 2073–2075, 2017. View at Publisher · View at Google Scholar · View at Scopus
  51. J. Martin, T. Mayberry, C. Donahue et al., “A study of MAC address randomization in mobile devices and when it fails,” Proceedings on Privacy Enhancing Technologies, vol. 2017, no. 4, pp. 365–383, 2017. View at Publisher · View at Google Scholar
  52. D. M. Ferrazani Mattos and O. C. M. B. Duarte, “AuthFlow: authentication and access control mechanism for software defined networking,” Annals of Telecommunications-Annales des Télécommunications, vol. 71, no. 11-12, pp. 607–615, 2016. View at Publisher · View at Google Scholar · View at Scopus
  53. M. Dallaglio, A. Giorgetti, N. Sambo, F. Cugini, and P. Castoldi, “Provisioning and restoration with sliceability in GMPLS-based elastic optical networks,” Journal of Optical Communications and Networking, vol. 7, no. 2, pp. A309–A317, 2015. View at Publisher · View at Google Scholar · View at Scopus
  54. L. Xiao, Y. Li, G. Han, G. Liu, and W. Zhuang, “PHY-authentication protocol for spoofing detection in wireless networks,” IEEE Transactions on Vehicular Technology, vol. 65, no. 12, pp. 10037–10047, 2016. View at Publisher · View at Google Scholar
  55. C. Matte, M. Cunche, F. Rousseau, and M. Vanhoef, “Defeating mac address randomization through timing attacks,” in Proceedings of the 9th ACM Conference on Security Privacy in Wireless and Mobile Networks, pp. 15–20, 2016.
  56. M. Vanhoef, C. Matte, M. Cunche, L. S. Cardoso, and F. Piessens, “Why MAC address randomization is not enough: an analysis of Wi-Fi network discovery mechanisms,” in Proceedings of the 11th ACM on Asia Conference on Computer and Communications Security, pp. 413–424, ACM, Xi'an, China, June 2016. View at Publisher · View at Google Scholar · View at Scopus
  57. U. Rajput, F. Abbas, and H. Oh, “A hierarchical privacy preserving pseudonymous authentication protocol for vanet,” IEEE Access, vol. 4, pp. 7770–7784, 2016. View at Publisher · View at Google Scholar · View at Scopus
  58. T. A. Team, “Avispa v1.1 user manual,” 2006,
  59. R. Amin, N. Kumar, G. P. Biswas, R. Iqbal, and V. Chang, “A light weight authentication protocol for IoT-enabled devices in distributed Cloud Computing environment,” Future Generation Computer Systems, vol. 78, pp. 1005–1019, 2018. View at Publisher · View at Google Scholar · View at Scopus
  60. R. Amin, S. Islam, G. Biswas, M. Khan, and N. Kumar, “A robust and anonymous patient monitoring system using wireless medical sensor networks,” Future Generation Computer Systems, vol. 80, pp. 483–495, 2018. View at Publisher · View at Google Scholar · View at Scopus
  61. S. Bojjagani and V. N. Sastry, “A secure end-to-end SMS-based mobile banking protocol,” International Journal of Communication Systems, vol. 30, no. 15, Article ID e3302, pp. 1–19, 2017. View at Publisher · View at Google Scholar · View at Scopus