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 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 [4–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 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 [26–28], 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

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 [38–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 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, 41–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 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.

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 attack Proof 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