27
Research Article RAMHU: A New Robust Lightweight Scheme for Mutual Users Authentication in Healthcare Applications Mishall Al-Zubaidie , 1,2 Zhongwei Zhang, 2 and Ji Zhang 2 1 i-Qar University, Nasiriyah 64001, Iraq 2 Faculty of Health, Engineering and Sciences, University of Southern Queensland, Toowoomba, QLD 4350, Australia Correspondence should be addressed to Mishall Al-Zubaidie; [email protected] Received 1 December 2018; Accepted 17 February 2019; Published 17 March 2019 Academic Editor: Huaizhi Li Copyright © 2019 Mishall Al-Zubaidie et al. is 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. is 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 prob- lem that limits the wide spread of these applications. ese 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 exchang- ing 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 authenti- cation 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 Hindawi Security and Communication Networks Volume 2019, Article ID 3263902, 26 pages https://doi.org/10.1155/2019/3263902

RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

  • Upload
    others

  • View
    5

  • Download
    0

Embed Size (px)

Citation preview

Page 1: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Research ArticleRAMHU A New Robust Lightweight Scheme for Mutual UsersAuthentication in Healthcare Applications

Mishall Al-Zubaidie 12 Zhongwei Zhang2 and Ji Zhang2

1Thi-Qar University Nasiriyah 64001 Iraq2Faculty of Health Engineering and Sciences University of Southern Queensland Toowoomba QLD 4350 Australia

Correspondence should be addressed to Mishall Al-Zubaidie u1070801umailusqeduau

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

Academic Editor Huaizhi Li

Copyright copy 2019 Mishall Al-Zubaidie et al This is an open access article distributed under the Creative Commons AttributionLicense which permits unrestricted use distribution and reproduction in any medium provided the original work is properlycited

Providing a mechanism to authenticate users in healthcare applications is an essential security requirement to prevent bothexternal and internal attackers from penetrating patientsrsquo identities and revealing their health data Many schemes have beendeveloped to provide authenticationmechanisms to ensure that only legitimate users are authorised to connect but these schemesstill suffer from vulnerable security Various attacks expose patientsrsquo data for malicious tampering or destruction Transferringhealth-related data and information between users and the health centre makes them exposed to penetration by adversaries asthey may move through an insecure channel In addition previous mechanisms have suffered from the poor protection of usersrsquoauthentication information To ensure the protection of patientsrsquo information and data we propose a scheme that authenticatesusers based on the information of both the device and the legitimate user In this paper we propose a Robust AuthenticationModel for Healthcare Users (RAMHU) that provides mutual authentication between the server and clientsThis model utilizes anElliptic Curve Integrated Encryption Scheme (ECIES) and PHOTON to achieve strong security and good overall performanceRAMHU relies on multiple-pseudonym physical address and one-time password mechanisms to authenticate legitimate usersMoreover extensive informal and formal security analysis with the automated validation of Internet security protocols andapplications (AVISPA) tool demonstrate that our model offers a high level of security in repelling a wide variety of possibleattacks

1 Introduction

A lack of security and confidentiality of information and dataused by healthcare (HC) applications remains the main prob-lem that limits the wide spread of these applications Thesesystems require a robust security mechanism to authenticateHC users for achieving the confidentiality integrity andavailability (CIA) triangle [1 2] and the compliance withthe Health Insurance Portability and Accountability Act(HIPPA) and Health Level Seven (HL7) standards to protectdata from being tampered with and altered [3] Securityrequirements (CIA) should be implemented when exchang-ing data between a client (patient or provider) applicationand a server application as any modification to this dataaffects both medical decisions and the patientrsquos condition [4]Authentication is the first as well as the most critical security

requirement that plays a key role in building correct securitybefore the exchange of patientsrsquo data in HC applications [4ndash7] On one hand authentication can reduce malicious orfatal errors caused by penetration attacks on the authenti-cation information On the other hand it alleviates errorsin specifying the drug dose timing or procedure [8] Asa result authentication protocols are a critical requirementto repel various attacks Typically the server applicationshould prevent all fake and illegal authentication requests[9 10] It should protect personal information health recordsand physiological parameters (such as sugar and heart rate)[4 11] However authentication information may be easierto compromise if data and information are stored on asingle server Furthermore the transfer of authenticationinformation in an insecure environment (wireless local areanetwork (WLAN) or Internet) may expose patientsrsquo data for

HindawiSecurity and Communication NetworksVolume 2019 Article ID 3263902 26 pageshttpsdoiorg10115520193263902

2 Security and Communication Networks

detection or modification [6 12] Some of the recent cases ofsecurity threats on HC applications are presented as follows

(i) Penetration attacks on HC data in the United Statesrsquohospitals occurred (2013) These attacks revealed854 of the protected health information (PHI) ofthe 5 largest incidents for patientsrsquo records [13]

(ii) Apple Health (Medicaid) was exposed to data breach(2016) This attack revealed 370000 records of users(Washington state) [14]

(iii) An unauthenticated user penetrated the electronichealth record (EHR) containing 14633 records inthe New Jersey Diamond Institute for Fertility andMenopause (2017) [15]

The traditional cryptography (such as Rivest-Shamir-Adleman (RSA)) and signature (such as secure hashalgorithm-1 (SHA-1)) schemes require complex computationsthat consume server resources such as processing powerand memory to deal with large amounts of health datain HC applications [16] and thus which could renderthem unusable The electronic signature is used to checkthe integrity of the usersrsquo information in the authenticationrequest [17]Many lightweight algorithms such as PHOTONQUARK and SPONGENT are desired to implementelectronic signatures that perform lightweight operationsto reduce high overheads on the server HC applicationsrequire cryptographic and signature high-speed and securealgorithms [18] To implement an authentication schememany algorithms such as the Elliptic Curve Cryptography(ECC) RSA hash function bilinear pairing fuzzy extractorand XOR operation [19] are used in HC applicationprojects Many recent HC applications are based on ECCand RSA both of which provide the same security levelalthough ECC is more efficient than RSA The design of anauthentication protocol in HC applications should providemutual authentication resistance to known attacks suchas man-in-the-middle (MITM) eavesdropping tracingreplay impersonation guessing and denial-of-service (DoS)[20] protection of information and reduced cost and highefficiency [21 22]

11 Our Contributions We propose a Robust AuthenticationModel for HC Users (RAMHU) for HC applications thatperform massive and continuous authentication processeswhile simultaneously protecting against various attacks Ourcontributions include providing robust authentication forlegitimate users in the HC applications and access the serverrepository They are summarised as follows

(i) RAMHU uses lightweight algorithms for encryption(ECIES) and signature (PHOTON)These algorithmsprovide efficient and secure authentication for usersin HC applications compared to other algorithms

(ii) RAMHU applies a one-time password (OTP) mech-anism to authenticate users in their first registrationin the HC network with timestamp verification andrandom nonce generation to repel different types ofexternal attacks

(iii) RAMHU uses a multiple-pseudonym mechanism toprevent any association between the real informationpseudonyms and userrsquos data This mechanism pre-vents attackers from identifying HC users (providersand patients)

(iv) RAMHU integrates login request with media accesscontrol (MAC) address in addition to verifying thatthis address is original and not fake for authenticationof legitimate devices This prevents attackers fromusing different devices to compromise the networkinformation

(v) RAMHU improves the mutual authentication be-tween the server and clients to prevent spoofing andimpersonation attacks by either a fake server or clientThis prevents external attacks intended to deceivetrusted parties

(vi) We simulate RAMHU with an automated valida-tion of Internet security protocols and applications(AVISPA) tool that is generally acknowledged as aneffective way to represent the threat model We haveusedAVISPA to prove that ourmodel is secure againstboth passive and active attacks

12 Structure of the Paper The remainder of this paperproceeds as follows Section 2 discusses previous studiesrelated to our research The threat model and basic conceptsabout the techniques used in RAMHU are introduced inSection 3 Section 4 describes the proposed authenticationmodel Section 5 describes informal and formal securityanalysis for our proposed scheme The conclusion and futureresearch directions are presented in Section 6

2 Related Work

There are many authentication schemes in the literaturerelated to our research area This section discusses in briefthe suggestions in previous studies to design authenticationschemes in order to ensure the security of HC users in thenetwork We investigated these solutions and found that theyhad different drawbacks We will discuss the solutions andtheir disadvantages while clarifying the superiority of ourscheme over existing studies

He and Zeadally [1] proposed an authentication schemebased on ECC and advanced encryption standards (AES)algorithms Their scheme uses three entities user serverand controller The authors claimed that their scheme pro-vides many requirements such as mutual authenticationanonymity and forward confidentiality The problem withthis scheme is that user and controller identities are staticallysent to all three entities If the attacker can penetrate theencryption heshe can see the related user and controlleridentities The attacker can then generate a random numbertemporary key timestamp and message authentication codeSubsequently heshe can encrypt the user and controlleridentities and obtain the message authentication code andsend it to the network to become a legitimate and authen-ticated user In addition this scheme uses a 160-bit key with

Security and Communication Networks 3

ECC which is considered unreliable by trusted institutionssuch as the National Institute of Standards and Technology(NIST) Our scheme uses a 256-bit key and does not exchangereal information for legitimate users between clients andservers An authentication protocol was proposed to pro-tect patientsrsquo passwords by RSA against off-line password-guessing attacks [17] The main problem in their scheme isthat the authors used RSA with the 1024 key This algorithmaffects the performance of a hugeHCnetworkMany schemesrecommend using ECC [26ndash28] as the ECC-160 is equivalentto RSA-1024 with the same security level In addition theirprotocol suffers from sending an ID clearly from a client tothe server at the registration phase which causes authenti-cation information to be detected for analysis attacks Usinga shared key to implement an authentication mechanism isdesigned to prevent known attacks especially DoS attacks [6]The authors used the wrong password detection mechanismto reduce the risk of DoS attacks However the registrationphase of their scheme is not reliable if the ID of patients issent through an unsafe channel Additionally their researchsuffers 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 schemebased on ECC for HC environments They pointed outthat their scheme provides forward secrecy Their schemeprovides authentication during the exchange of messagesbetween the server and RFIDrsquos (radio-frequency identifica-tionrsquos) tag However their scheme shows that the information(identities) and data are stored on a single server and if theserver is hacked the usersrsquo information and data are exposedto detection tempering and modification The ECC and aPetri Nets model are proposed to achieve an authenticationrequirement to protect HC applications through the mobilecloud [24] The authors pointed out that their scheme isresistant to attacks of eavesdropping tracking replay andspoofing Unfortunately their scheme does not address theissue of stealloss of tag or device and internal attacks that aremore serious than external attacks in accessing patientsrsquo dataas well as no indication of what signature algorithm is usedfor integrity In addition the tagrsquos ID is explicitly sent fromserver to tag which makes it easier for the attacker to parsethe authentication request Jiang et al [25] designed a three-factor (biometric smart card and password) authenticationprotocol to protect e-health clouds Their scheme protectsauthentication requests from impersonation attacks and off-line password guessing if a mobile device is lost or stolenTheir scheme relies on ECC to support the confidentialityand authentication of HCrsquos usersThey used a fuzzy extractorto keep a biometric secret However this scheme relies ona single server to authenticate users which is the target ofthe attackers In addition it performs 7 hash operations thatcan exhaust the single server capabilities if the network has ahuge number of HC users especially if it is not a lightweighthash Our model has superior capacity as it uses a separationserver (attributes server) for usersrsquo information and also only5 lightweight hash operations in the central server

Cloud-assisted conditional privacy preserving authen-tication (CACPPA) [7] was proposed to authenticate thenetworkrsquos nodes This scheme used ECIES and the Elliptic

Curve Digital Signature Algorithm (ECDSA) with a times-tamp and pseudonym integration to perform the authen-tication process The problem with this scheme is that itdoes not provide mutual authentication to prevent an attackfrom a counterfeit party Furthermore the authors did notexplain the size of the keys in the algorithms to make surethat their scheme was able to repel the various attacksFurthermore a single pseudonym cannot separate the linkto the real information to prevent analysing and trackingattacks for authentication requests Das et al [5] provideda user authentication scheme for HC applications based onAES and hash (SHA-1) They used biometrics users and theanonymity feature to repel attacks such as replay MITMand privileged insider However their scheme will sufferfrom a key management problem if applied to a large healthinstitution with hundreds of users including managing usersrsquoaccounts from adding and deleting as symmetric encryptionsuffers from a scalability problem as well as the difficulty ofmanaging the single secret key Furthermore the attacker cansubmit a forgery attack on the login message if it detects thesingle secret key Recently Chandrakar andOm [19] providedan authentication scheme based on ECC and hash Theirscheme has supported several servers in user authenticationwith three factors In this case the user can connect to anyserver to perform the authentication process In this schemethe authors did not specify which hash algorithm was usedand the size of the message digest (MD) which is necessaryfor repelling attacks such as collision and preimage Usingmultiple servers means that the same usersrsquo information isstored on more than one server and thus the penetration ofany server that causes usersrsquo information to be detected ormodified Additionally this scheme did not use a mechanismto prevent the association of real user information withauthentication requests such as pseudonyms

3 The Basic Techniques for OurAuthentication Scheme

An authentication mechanism specifies connecting users tonetwork services securelyTheHC system needs a set of tech-niques to implement the authentication mechanism beforeaccessing patientsrsquo records One authentication techniquewill not be sufficient to repel known attacks To ensure thatonly legitimate users are associated with the HC applicationnetwork our project includes a set of techniques to validatethe authentication request In our scheme we relied onalgorithms that provide lightweight operations and a high-security level for encryption and signature operations Thissection describes the threat model and the basic concepts ofthese techniques

31 Threat Model The threat model has been used to detectsecurity weakness in authentication schemes The threatmodel is applied to RAMHU based on the Dolev-Yao (dy)[29] model in order to build a valid authentication processin insecure environments such as a WLAN or the InternetThe dy model is an efficient and practical way to illustratesecurity protocols in the real world In addition it is a

4 Security and Communication Networks

e first layercryptographic

protocol

e second layerelliptic curvepoint mul-tiplication

e third layerpoint operations

e lower finitefield arithmetic

ECC (ECIESECDSA

and ECDH)

Point multipli-cation (PM)

Point addition Point doubling

Multiplication Addition Squaring Inversion

Figure 1 Arithmetic operations in ECC hierarchy

Table 1 Keys sizes and some information for asymmetric algorithms

Algo Keys sizes Ratio Author(s) Year Mathematical problemRSA 1024 2048 3072 7680 15360

16-30Rivest Shamir and Adleman 1978 Integer factorization

Elgamal Taher Elgamal 1985 Multiplicative groupECIES 160-223 224-255 256-383 384-511 512-more Neal Koblitz and Victor Miller 1985 Elliptic curve discrete log (ECDLP)

formal exemplar for modelling the risk of attackers againstauthentication protocols This model is useful in detectinginternal external single and multiple attacks [30] In ourthreat model we assume that an intruder is capable ofcarrying out an internal external passive or active attacksuch asMITM replay eavesdropping and spoofing Also weassume that the attributes server (119860119878) is trustworthy It is safeagainst repository penetration attacks We assume threats inour model as follows

(i) The attacker can steal the client application and itsfiles to analyse the data retrieve the parameters andreveal the secret key and then use these applicationson different devices

(ii) The attacker can listen for authentication requests inthe insecure environment and execute interceptionreplay and MITM attacks in order to become alegitimate user in the network

(iii) The attacker can execute a forgery or masqueradingattack in an attempt to penetrate the authenticationprocess

(iv) A legitimate user can perform a privileged insiderattack based on hisher legitimacy in the network

(v) The attacker can successfully guess the real usernamepassword role and pseudonym associated with itduring intensive analysis of many authenticationrequests

32 Overview of Techniques

(i) Elliptic Curve Integrated Encryption Scheme (ECIES)Elliptic Curve Cryptography (ECC) has been used to providesecurity requirements It provides confidentiality integrity

and authentication in the communications network withlimited capacity in terms of power and processing Thisalgorithm was independently proposed by Neal Koblitz andVictorMiller in 1985 [31] It depends on the discrete logarithmproblem (DLP) which is impervious to known attacks whenselecting parameters accurately [32] ie difficulty obtainingk from P and Q (where k is an integer and P and Q aretwo points on the curve) Small parameters used in ECChelp to perform computations quickly These computationsare important in constrained-source and large environmentsthat require processing power memory or power con-sumption [20 33] ECC provides encryption (Elliptic CurveIntegrated Encryption Scheme (ECIES)) signature (EllipticCurve Digital Signature Algorithm (ECDSA)) and exchangekeys (Elliptic Curve Diffie-Hellman (ECDH)) approaches[31] Many operations are performed in ECC algorithms(described in four layers) as shown in Figure 1 [34] ECIEShas provided confidentiality and proven to be extremelyefficient in its performance as it uses small keys thus thecost of computation is small compared with other public keycryptography algorithms such as Rivest-Shamir-Adleman(RSA) [35] Table 1 [33 36 37] shows a comparison of keysizes for public key encryption algorithms

(ii) Lightweight Hash-Function Algorithm The hash functionhas been used to generate signatures for authenticationrequests PHOTON is a lightweight hash function andextremely suitable for projects that require a robust andreliable signature This algorithm is based on a spongelikeconstruction and AES-like primitive for domain extensionand permutation efficiency [38ndash40] PHOTON is available inseveral versions (80 128 160 224 and 256) It is a balancebetween the efficiency in the execution of computations onthe one hand and security in the implementation of the

Security and Communication Networks 5

Table 2 Comparison of lightweight hash function algorithms

Algorithm Performance MD Security Author (s) YearGate equivalent area Throughput (kbps) PR SPR CR

SQUASH 2646 GE 015 64 64 64 0 Shamir 2005MAME 8100 GE 1467 256 - - - Yoshida et al 2007C-PRESENT-192 8048 GE 5926 192 192 192 96 Bogdanov et al 2008ARMADILLO2 8653 GE 938 256 256 256 128 Bald et al 2010S-QUARK 2296 GE 313 256 224 112 112 Aumasson et al 2010KECCAK-f[400] 5090 GE 144 128 128 128 64 Kavun and Yalcin 2010GLUON 4724 GE 32 224 224 112 112 Berger et al 2011SPONGENT-256 3281 GE 1143 256 240 128 128 Bogdanov et al 2011PHOTON-256 2177 GE 088 256 224 128 128 Guo et al 2011

features of the signature principle that depend on preimageresistant (PR) second preimage resistant (SPR) collisionresistant (CR) and mixing-transformation [17] on the otherhand It uses sponge construction and applies two phasesof absorbing and squeezing to produce a message digest(MD) more details are available in [41] Table 2 providesa comparison among the lightweight hash algorithms (thelatest version of these algorithms) in terms of security andefficiency [39 41ndash46] Although standard hash algorithmsare still used in applications such as SHA-1 (5527 GE MD160-bit) and SHA-2 (10868 GE MD 256-bit) lightweighthash algorithms such as PHOTON (2177 GE MD 256-bit)provides the most effective solution for handling complexsignatures in large HC systems

Table 2 shows that the PHOTON-256 (2177 GE) providesthe best performance compared to all lightweight hashfunctions and offers a high level of security through theapplication of signature features PR (224) SPR (128) and CR(128) Linear and differential attacks are the most powerfulattacks in the MD analysis of hash functions Compared toPHOTON ARMADILLO and SPONGENT-256 also offersignature features but both are vulnerable to attacks whereARMIDLLO2 has been attacked by local linearization (prac-tical semi-free-start collision attack) [47] and SPONGENThas been attacked by linear distinguishers (23 rounds [48] and13 rounds [49]) for all SPONGENTversions and additionallythey need the most computations (3281 GE and 8653 GE)compared with PHOTON-256 (2177 GE) PHOTON is areliable algorithm against linear and differential attacks [41]It has a high level of security and efficiency therefore it issuitable for our project as a signature mechanism

(iii) One-Time Password (OTP) The OTP is a way to authen-ticate legitimate users by generating a passcode or nonceonly once in a specified time It will not be applicablethe next times for authentication The OTP is an effectivemethod for authenticating users in HC applications if usedwith robust encryption and signature technologies Usinga static password or nonce without other authenticationmechanisms is weak in respect to attacks Therefore an OTPprovides significant support to the authentication processThismechanismpreventsmany attacks such as replayMITM

and guessing [50] The attacker cannot use this passcode ornonce to connect to the network later The client sends anOTP as part of an authentication request If the authenticationprocess is valid the server will delete the OTP from thedataset and will not accept it in the future The OTPis a powerful mechanism to mitigate the risk of hackersrsquocommunication in the network In this project we apply anOTP to generate a random password with the first link tousers in HC applications to ensure that only legitimate usersare connected to the network

(iv) Mutual Authentication Mutual authentication is a pre-requisite for preventing fraudulent authentication requestsThe traditional methods of authentication (such as passwordand name) are not suitable for HC applications [18] Ingeneral there are two kinds of authentication simple andmutual In simple authentication one party performs theauthentication process for example the server verifies theauthentication request for the client This type of authenti-cation is vulnerable to attacks such as spoofing and imper-sonation The attacker can use his device as a fake server toreceive all clientsrsquo requests Mutual authentication providesa security solution to prevent known attacks [18] In thistype of authentication each party authenticates the otherparty and thus prevents counterfeit attacks by both the clientand server In RAMHU we adopt the mechanism of mutualauthentication in the preservation of usersrsquo information anddata

(v) Media Access Control (MAC) Address AMAC address hasbeenused to distinguish legitimate usersrsquo devices in a networkduring the completion of the authentication process Allnetwork devices of different types should contain a hardwarecard (interface) to connect to the local or global networkEach wire or wireless interface has a media access control(MAC) or physical address that consists of 48 bits It is dividedinto six octets and written in hexadecimals such as ldquo8C70 5A 41 49 BCrdquo This address is a unique identifier (noduplicate address twice) for a device defined as global andpersistent [51] This address is used in WLAN because itoffers advantages such as reducing costs and speed in accesscontrol procedures [52] It can be changed programmatically

6 Security and Communication Networks

Table 3 Paperrsquos notations

Symbol Description119862119894 Client entity or user119862119878 Central server119860119878 Attributes server119863119878 Data server119880119868119863119894 119872119868119863119894 119862119894rsquos identity and medical centre identity119875119882119894 119905119898119901119875119882119894 119862119894rsquos password temporary password119862119894119870119901119906119894 119862119894119870119901119903119894 119862119894 public and private key119862119878119870119901119906119894 119862119878119870119901119903119894 119862119878 public and private key119860119878119870119901119906119894 119860119878119870119901119903119894 119860119878 public and private key119879119878119862119894 119879119878119862119878 119879119878119860119878 Timestamp generated by 119862119894 119862119878 119860119878

119873119862119894 119873119862119878 119873119860119878 Nonce random generated by 119862119894 119862119878 119860119878

119868 Internal or external intruder119868119868 119864119868 Internal intruder and external intruderℎ() One-way hash function119877119894 Role of patient patient relative or provider119877119877119894 Revocation reason119874119879119875119894 One-time password to authenticate first time119862119894119878119894119892119895 Signature generated by 119862119894 and j is signature number119862119878119878119894119892119895 Signature generated by 119862119878119860119878119878119894119892119895 Signature generated by 119860119878119880119875119862119878119862119894 119875119872

119862119878119862119894

User and medical centre pseudonyms sent by 119862119894 and verified by 119862119878119880119875119860119878119862119878 119875119872

119860119878119862119878 User and medical centre pseudonyms sent by 119862119878 and verified by 119860119878

119880119875119862119878119860119878 119875119872119862119878119860119878 User and medical centre pseudonyms sent by 119860119878 and verified by 119862119878

119880119875119862119894119862119878 119875119872

119862119894119862119878 User and medical centre pseudonyms sent by 119862119878 and verified by 119862119894

oplus Concatenation and exclusive or operations119866119872 119862119872 Get MAC and checkMAC address119864119899119888119894 119863119890119888119894 Encryption and decryption operations

in various operating systems such as Linux and WindowsIn addition anyone can use the Address Resolution Protocol(ARP) to detect the MAC address of another user in thenetwork [53] The main problem with this address is thatthe attacker can execute an eavesdropping attack to accessthe MAC addresses of legitimate devices in the network andthen select a legitimate MAC address to use it For instancean attacker could execute an ARP poisoning or spoofingattack by using a fake identifier of the MAC address (for alegitimate entity) to gain illegal privileges that would enableit to perform other attacks such as MITM and DoS [54]In addition randomization operations for the MAC addresshave become useless in the protection against tracking attacks[55 56] Therefore if the server does not have a mechanismto detect MAC address change the attacker becomes alegitimate user in the network and has access to networkresources

4 The Proposed Authentication Scheme

In this section we will detail RAMHU that provides securityand efficiency features in HC applications This sectionwill be divided into the network model security goalsand proposed authentication protocols Notations listed in

Table 3 are used to describe symbols used throughout thispaper

41 Network Model The RAMHU model consists of fourentities as shown in Figure 2

(1) Client (119862119894) This entity includes patients relativesof patients and HC providers such as doctorsresearchers emergency practitioners advisors andnurses

(2) Central server (119862119878) This entity is a gateway toauthenticate users with the attributes server and toauthorise the data server

(3) Attributes server (119860119878) This entity contains usersrsquo realinformation as well as multiple pseudonyms Theauthentication process requires verifying the asso-ciation of the actual information with the multiplepseudonyms in this entity

(4) Data server (119863119878) This entity contains usersrsquo dataas well as multiple pseudonyms This entity is notimplemented in our scheme and is left to future workOur scheme focuses only on the process of usersrsquoauthentication in the HC network

Security and Communication Networks 7

Network model

Acknowledgement

Client

Attributes server (AS)

Central server (CS)

Data server (DS)

Authentication request

Informationrepository

Datarepository

Check userrsquos information

Response

Authentication request

Response

Acknowledgement Data request(with pseudonyms)

Figure 2 General network model

Generally 119862119894 creates an authentication request mainlybased on ECIES and PHOTON 119862119894 sends a request to 119862119878 toverify encryption signature and security parameters (suchas MAC address pseudonyms and 119874119879119875119894) Then the 119862119878sends a request to the 119860119878 to verify the link between thepseudonyms the real information the signatures and 119875119882119894After that the 119860119878 sends the response to the 119862119878 that verifiesthe signature and the parameters and then the 119862119878 sendsthe response (authenticated or not) to the 119862119894 If the useris authenticated we assume that the user can then send anauthorisation request to access the data in the repository (119863119878)and obtain the authorisation response from the 119862119878 119860119878 and119863119878

42 Security Goals To build a robust authentication schemeRAMHU adopts the following security requirements

(i) Confidentiality This requirement is performed tohide authentication information and to preserve usersecrecy from detection by intruders To implementthis requirement a high-security cryptographic algo-rithm [20] should be used RAMHU executes ECIESto hide authentication information about intruders

(ii) Integrity This is to protect the authentication requestinformation from modification by intruders Theauthentication request should reach the intendeddestination without modification to provide a reliablecommunication channel for legitimate users [10 57]RAMHU performs a PHOTON to prevent any pro-cess ofmodifying the user authentication informationin HC applications

(iii) Nonrepudiation This requirement prevents both theclients and server from denying their authenticationrequests This is a way to prove that the message issent by a particular sender in the HC applications

network If a legitimate user in the network performsinternal attacks heshe cannot deny hisher activitieswhile exploiting the privileges granted to himherOur scheme uses PHOTON signatures and a MACaddress tomeet this requirement and detectmaliciousattacks

(iv) Anonymity This requirement is extremely impor-tant in supporting the confidentiality of the authen-tication request The purpose of this requirementis to disguise the source and destination of theauthentication request If the authentication schemeapplies anonymity with encryption the attackerfinds it exceedingly difficult to analyse authentica-tion requests for a particular user at different timesbecause the authentication request is different eachtime the user is connected to the network [7]RAMHU applies this requirement through the use ofrandom nonces between entities

(v) Pseudonym This requirement denotes the provisionof a mechanism to connect nonreal attributes (suchas terms and symbols) with the real attributes of theuser (such as name address and phone number)The use of this mechanism in HC applications isan extremely important way to protect the personalinformation of users and prevent the detection oftheir identities RAMHU uses a multiple-pseudonymmechanism to prevent and separate the associationwith real information

(vi) Forward secrecy This requirement is accomplishedwhen network users use new keys and parameterstemporarily without relying on old onesThis require-ment prevents attackers from exploiting usersrsquo keysand passwords in decrypting authentication requestsUsing the temporary random password private key

8 Security and Communication Networks

and MAC RAMHU prevents users from accessingprevious authentication information

(vii) Mutual authentication This requirement is used inHCapplications tomitigate the risks of external fraudWith this feature each party ensures that it deals witha legitimate party The server authenticates the clientby checking encryptions and signatures and viceversa in order to establish a secure communicationchannel In RAMHU 119862119878 and 119862119894 authenticate eachother to prevent masquerading and impersonatingattacks

(viii) ScalabilityHCapplications operate in a scalable envi-ronment in terms of data and users Therefore theseapplications require authentication schemes capableof handling and adapting to the ever-increasing num-ber of users of HC applications This requirementrefers to the ability of the authentication scheme toappropriately handle large HC systems Public keyencryption schemes are efficient in supporting thisrequirement [24]

(ix) FreshnessThis requirement indicates that the authen-tication request is new and updated to ensure thatthe attacker cannot replay the authentication requestat a later time This requirement is achieved throughthe provision of time checking a random nonce andchange of signatures in each authentication process tocounteract counterfeit attacks such as MITM replayand impersonation [20] which ensures that theauthentication request is unaltered or not tamperedwith

43 Proposed Authentication Scheme The RAMHU schemeconsists of 5 protocols initial setup registrationloginauthentication password update and revocation Duringthese protocols RAMHU provides reliable authenticationprocesses to protect usersrsquo information

431 Initial Setup Protocol In this protocol all entitiesare ready to start communicating with each other whileconfiguring all security parameters and ECIESrsquos keys as in thefollowing steps

(i) Each legitimate user receives a client application fromthe authorised system provider

(ii) Each legitimate user receives a 119875119882119894 (that can bechanged later) and a random 119874119879119875119894 to be used in thefirst registration

(iii) All entities (119862119894 119862119878 and 119860119878) should create publicand private keys (119862119894 (119862119870119901119906119894 119862119870119901119903119894) 119862119878 (119862119878119870119901119906119894 119862119878119870119901119903119894) and 119860119878 (119860119878119870119901119906119894 119860119878119870119901119903119894)) to be used tovalidate the authentication request All entities choosean elliptic curve 119864119901(119886 119887) over a prime field 119865119875 (where119875 = 256) and base point 119866 on curve Each entityselects a private key 119870119901119903119894 randomly and generates thepublic key 119870119901119906119894 during the implementation of scalarmultiplication (119870119901119906119894 = 119870119901119903119894 lowast 119866)

(iv) All entities broadcast the public key (119862119870119901119906119894 119862119878119870119901119906119894 and 119860119878119870119901119906119894) to use in ECIESrsquos encryption operations

432 Registration and Login Protocol Patients and HCproviders (119862119894) should complete the registration and loginprotocol with 119862119878 to become legitimate users of HC appli-cations Without this protocol the user cannot completethe authentication process in RAMHU User registration isperformed once namely the user does not need to completethe registration protocol the next times (only the loginprotocol) the registration information has been kept in theservers until the revocation protocol and deletion of the usersecurity parameters such as pseudonyms MAC address and119875119882119894 this protocol accomplishes the following steps (Figure 3shows the registration and login protocol and Figure 4 showsthe login protocol)

119862119894 Side

(i) The user enters 119880119868119863119894 (such as hisher name) 119872119868119863119894(such as medical centre name) and 119875119882119894 and 119874119879119875119894for registration and login while only entering 119880119868119863119894119872119868119863119894 and119875119882119894 for the login protocol the next times tothe client (119862119894) application119862119894 replaces119880119868119863119894with userrsquospseudonym (119880119875119862119878119862119894 ) and 119872119868119863119894 with medical centrepseudonym (119872119875119862119878119862119894 ) to protect the authenticationinformationwhenmoving from119862119894 to119862119878119862119894 generatesa timestamp (119879119878119862119894) to be used to verify the sendingtime of the registrationlogin request in 119862119878

(ii) 119862119894 gets a MAC address (GM) by entering its IP(Internet protocol) address The process of checkingMAC (119862119872) is performed by 119862119894 to test the cred-ibility of the MAC address In the Linux systemwe used the command ldquoethtool -P interface namerdquo(such as ldquoethtool -P wlo1rdquo) in the 119862119894 applicationIf the result is identical to 119866119872 it means that theMAC address is native (119862119872 = ldquo119877119890119886119897 119872119860119862rdquo) Inthe Windows system 119862119894 searches for string valueldquoNetworkAddressrdquo in the path of the system reg-istry (ldquo119867119870119864119884 119871119874119862119860119871 119872119860119862119867119868119873119864 119878119884119878119879119864119872 119862119906119903119903119890119899119905119862119900119899119905119903119900119897119878119890119905 119862119900119899119905119903119900119897 119862119897119886119904119904 411986336119864972 minus119864325 minus 11119862119864 minus 1198611198651198621 minus 0800211986111986410318rdquo) If Net-workAddress = null 119862119872 = ldquo119877119890119886119897 119872119860119862rdquo otherwise119862119872 = ldquo119865119886119896119890 119872119860119862rdquo The 119866119872 send is encrypted witha registrationlogin request while 119862119872 is implicitlysent with the signature value (1198621198941198781198941198921) In only thelogin protocol 119862119894 needs to extract a private keyfrom the temporary keyMAC address password andrandom nonce through 119905119898119901119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus119873119862119894 119862119894 generates a random nonce (119873119862119894) to changesignature and encryption data and add anonymity tothe registrationlogin request

(iii) 119862119894 performs two signatures using the PHOTON-256algorithm to protect information from modificationThe first signature includes the parameters checkMAC nonce and timestamp (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) The second signature includes allthe authentication parameters of the gotten MAC

Security and Communication Networks 9

CS AS

Figure 3 Registration and login protocol

nonce timestamp first signature pseudonyms one-time password and password (1198621198941198781198941198922 = ℎ(119866119872

119873119862119894 119879119878119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875

119875119882119894)) In the login protocol 119874119879119875 is not added to thesignature

(iv) 119862119894 computes a temporary value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus 1198621198941198781198941198921) of 119875119882119894 when moving from 119862119894 to119862119878

(v) 119862119894 uses ECIES to encrypt and hide all the data ofthis request (119864119899119888119894(119879119878119862119894 119873119862119894 119866119872 1198621198941198781198941198921

119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875119894 119905119898119901119875119882119894 1198621198941198781198941198922)) Inthe login protocol 119874119879119875119894 and 119866119872 are not added tothe encryption as in Figure 4 After that 119862119894 sendsthe registration and login request or login to 119862119878 tocomplete the authentication protocol Then 119862119894 hidesthe private key by 119905119898119901119862119894119870119901119903119894 = 119862119894119870119901119903119894 oplus119875119882119894 oplus1198621198941198781198941198922

119862119878 Side

(i) Upon receiving a registration and login request orlogin request 119862119878 decrypts this request using ECIESrsquos119862119894119870119901119906119894 and 119862119878119870119901119903119894 It checks the timestamp (119879119878119862119878-119879119878119862119894 le 998779119879) to make sure that this request arrived atan appropriate time and without delay

(ii) In the registration and login protocol 119862119878 examinesthe random 119874119879119875119894 in the dataset If 119874119879119875119894 exists thenthe user is legitimate for the registration process After

that 119862119878 deletes 119874119879119875119894 from the dataset to prevent itfrom being used the next times If 119874119879119875119894 is not foundit discards the connection In the login protocol119862119878 examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 and then tests theirassociation with the MAC address in the dataset If119866119872 is found 119862119878 completes the steps of this protocolotherwise it cancels the connection

(iii) 119862119878 needs to ensure that the userrsquos device is legitimatewithin the network 119862119878 computes the signature valueto make sure that the MAC address is native andnonmodified (1198621198781198781198941198921 = ℎ(ldquoReal MACrdquo 119873119862119894 119879119878119862119894)) It examines the result of the computed sig-nature (1198621198781198781198941198921) with 119862119894rsquos signature (1198621198941198781198941198921) If thesignatures results are identical then the device islegitimate and the MAC address did not change Inthe registration and login protocol 119862119878 stores thisaddress in the dataset for use and checks the nexttimes in the login protocol

(iv) 119862119878 performs the computation operation 119905119898119901119875119882119894 oplus119873119862119894 oplus119866119872oplus1198621198781198781198941198921 to extract the 119875119882119894 value and thenuses this value to produce a second signature (1198621198781198781198941198922)

(v) 119862119878 computes a second signature operation (1198621198781198781198941198922=ℎ(119866119872 119873119862119894 119879119878119862119894 1198621198781198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894

119874119879119875119894 119875119882119894)) to guarantee that all the encryptedinformation is not changed Then it compares thecomputed signature (1198621198781198781198941198922) with the received sig-nature in the request (1198621198941198781198941198922) If the signatures are

10 Security and Communication Networks

CS AS

Figure 4 Login protocol

identical then the information for this request isunchanged or not tampered with In the login proto-col 119874119879119875119894 and 119866119872 are not added to the signature Atthis point 119862119878 prepares to send the userrsquos authentica-tion request to 119860119878

433 Authentication Protocol The authentication protocolverifies the reliability of the usersrsquo security parameters withtheir personal information in the server In this protocolRAMHU needs to link pseudonyms and passwords with realinformation for users in 119860119878rsquos datasets Note that the usersrsquoinformation (such as name age address mobile number andpasswords) is stored in a separate server (AS) and multiplepseudonyms are used to prevent detection and trackingof usersrsquo information This protocol is illustrated in thefollowing steps (Figure 5 shows the authentication protocolin RAMHU)

119862119878 Side

(i) 119862119878 computes a new timestamp (119879119878119862119878) to ensure thefresh authentication request

(ii) 119862119878 replaces 119862119894rsquos pseudonyms (119880119875119862119878119862119894 and119872119875119862119878119862119894 ) with119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119872119875119860119878119862119878 ) to prevent attack-ers from tracking the authentication request It gen-erates random nonce (119873119862119878) to ensure an anonymousauthentication request

(iii) 119862119878 signs security parameters by PHOTON-256(1198621198781198781198941198923 = ℎ(119879119878119862119878 119873119862119878 119880119875

119860119878119862119878 119872119875119860119878119862119878 )) to prevent

modification of authentication request information(iv) 119862119878 computes temporary 119875119882119894 by the computation of

119875119882119894 oplus 119873119862119878 oplus 1198621198781198781198941198923

(v) 119862119878 encrypts information of authentication request(119864119899119888119894(119879119878119862119878 119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 1198621198781198781198941198923 119905119898119901119875119882119894)) It sends an authentication request to verifyuserrsquos information in 119860119878

119860119878 Side

(i) Upon receiving the authentication request 119860119878 de-crypts that request using ECIESrsquos 119860119878119870119901119903119894 and 119862119878119870119901119906119894to obtain the authentication information clearly

(ii) It checks the timestamp by 119879119878119860119878 minus 119879119878119862119878 le 998779119879 toensure that the authentication request is not delayed119860119878 checks the pseudonyms (119880119875119860119878119862119878 and 119872119875119860119878119862119878 ) sentfromCS and correlates them with the userrsquos real iden-tifier (119880119868119863119894 and119872119868119863119894) in the datasets 119860119878 extracts theuserrsquos password from the equation 119875119882119894 = 119905119898119901119875119882i oplus119873119862119878oplus1198621198781198781198941198923 After that it checksmatching119875119882119894 in thedataset 119860119878 computes the value of the signature basedon authentication information (1198601198781198781198941198921 = ℎ(119879119878119862119878

119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 )) by PHOTON-256 119860119878 com-

pares the computed value of the signature (1198601198781198781198941198921)with the value of the received signature (1198621198781198781198941198923) If

Security and Communication Networks 11

CS AS

Figure 5 Authentication protocol

the signature values are identical the userrsquos informa-tion in the request for the signature is unmodified Atthis point 119860119878 considers this user to be legitimate andreliable

(iii) 119860119878 prepares a response to authenticate the request ofthat user It computes a new timestamp (119879119878119860119878 = new119879119878119860119878) to prevent delayed or replayed requests at latertimes119860119878 replaces119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119880119875

119860119878119862119878 )

received with 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) tohide usersrsquo information It generates a new randomnonce (119873119860119878) to add anonymity and prevent attacksfrom encryption and signature analysis

(iv) 119860119878 computes a signature (1198601198781198781198941198922 = ℎ(119879119878119860119878 119873119860119878

119880119875119862119878119860119878 119872119875119862119878119860119878 )) to prevent modifications of authenti-cation response information

(v) 119860119878 encrypts the authentication information(119864119899119888119894(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 1198601198781198781198941198922))and sends the authentication response to 119862119878 tocomplete the authentication process

119862119878 Side(i) 119862119878 decrypts the authentication response (119864119899119888119894)

received from 119860119878 It checks the timestamp value(119879119878119862119878 minus 119879119878119860119878 le 998779119879) to prevent late authentication

12 Security and Communication Networks

responses It examines 119880119875119860119878119862119878 and119872119875119860119878119862119878 in datasets tocomplete the process of linking multiple pseudonymsto the user

(ii) 119862119878 computes the signature 1198621198781198781198941198924 = ℎ(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 ) for authentication response infor-mation It compares the computed result of thesignature (1198621198781198781198941198924) with the value of the receivedsignature (1198601198781198781198941198922) If the signature values matchthen the authentication response information is un-changed

(iii) After this point 119862119878 initiates a login response requestIt computes the value of new timestamp (119879119878119862119878 =

119899119890119908119879119878119862119878) It replaces 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) received with 119880119875

119862119894119862119878 and 119872119875

119862119894119862119878 It generates

a new random nonce (119873119862119878) to hide encryption andsignature information

(iv) 119862119878 computes a new signature value (1198621198781198781198941198925 =

ℎ(119879119878119862119878 119873119862119878 119880119875119862119894119862119878

119872119875119862119894119862119878)) to protect login

response information frommodification(v) 119862119878 encrypts login response information (119864119899119888119894(119879119878119862119878

119873119862S 119880119875119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sends thisresponse to 119862119894

119862119894 Side

(i) 119862119894 extracts his private key (119862119894119870119901119903119894) from 119905119898119901119862119894119870119901119903119894 oplus119875119882119894 oplus 1198621198941198781198941198922 and decrypts the login request (119864119899119888119894)received from 119862119878

(ii) 119862119894 checks the timestamp (119879119878119862119894 minus119879119878119862119878 le 998779119879) to ensurethat the login response is not late or replayed

(iii) 119862119894 checks that 119862119878rsquos pseudonyms (119880119875119862119894119862119878 and 119872119875119862119894119862119878)

are received in the dataset and associated with 119880119875119862119878119862119894and 119872119875C119878

119862119894 At this point RAMHU applied multiple

pseudonyms among model entities (119862119894 119862119878 and 119860119878)to prevent traceability in linking the real informationof the user with pseudonyms

(iv) 119862119894 calculates the value of the signature 1198621198941198781198941198923 =

ℎ(119879119878119862119878 119873C119878 119880119875119862119894119862119878 119872119875

119862119894119862119878) for login re-

sponse information It compares the result of thecomputed signature (1198621198941198781198941198923) and the value of thereceived signature (1198621198781198781198941198925 ) If the signature values areidentical namely the login response information isunmodified or not tamperedwith119862119894 accepts the loginresponse otherwise 119862119894 discards the login responseThen119862119894 hides its private key by 119862119894119870119901119903119894 oplus119866119872oplus119875119882119894 oplus119873119862119894 after generating a random nonce to prevent thedetection of the private key if the device is hackedAt this point if all processes are achieved correctlythen all requests are considered legitimate and reli-able through the implementation of mutual authenti-cation

434 Password Update Protocol Updating the password isa security procedure to ensure authentication of legitimate

users The process of changing 119875119882119894 is important in any HCsystem for two reasons First it prevents the use of 119875119882119894fixed for a long time which reduces the guessing attacksSecond changing119875119882119894 gives usersmore flexibility in choosingthe appropriate 119875119882119894 This process requires strict securitymeasures to protect the new 119875119882119894 RAMHU provides thelegitimate user with amechanism to change hisher passwordat any time If the user wants to change hisher 119875119882119894the following illustration describes the new 119875119882119894 protectionprocedures in a secure manner (Figure 6 shows the passwordupdate protocol in RAMHU)

(i) 119862119894 side 119862119894 enters 119880119868119863119894 119872119868119863119894 the old 119875119882119894 andthe new 119875119882119894 It replaces 119880119868119863119894 and 119872119868119863119894 withpseudonyms to hide the userrsquos real information 119862119894calls the MAC address and then extracts the privatekey from 119905119898119901119862119894119870119901119903119894oplus119866119872oplus119900119897119889119875119882119894oplus119873119862119894 to use in theencryption process of the password update request119862119894generates three random nonces (1198731198621 1198731198622 and 1198731198623)and computes a new timestamp (119879119878119862119894) 119862119894 computesthe signature value (1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)) by PHOTON-256 basedon the parameters of the password change requestIt applies an anonymity mechanism to the old 119875119882119894and new 119875119882119894 (119905119898119901 119900119897119889119875119882119894 = 119900119897119889119875119882119894 oplus1198731198622 oplus 1198621198941198781198941198921and 119905119898119901 119899119890119908119875119882119894 = 119899119890119908119875119882119894 oplus 1198731198623 oplus 1198621198941198781198941198921) to hidepasswords and not explicitly send them in the 119875119882119894change request It encrypts the 119875119882119894 change request(119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) and sends itto 119862119878 119862119894 then hides its private key by 119862119894119870119901119903119894 oplus 119866119872oplus119899119890119908119875119882119894 oplus 119873119862119894

(ii) 119862119878 side 119862119878 receives and decrypts a password updaterequest (119864119899119888119894) It examines the timestamp to preventdelayed requests and examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 indatasets 119862119878 extracts the old 119875119882119894 and new 119875119882119894 from119905119898119901 119900119897119889119875119882119894 oplus 1198731198622 oplus 1198621198941198781198941198921 and 119905119898119901 119899119890119908119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 Then it computes the signature value(1198621198781198781198941198921) depending on 119879119878119862119894 1198731198621 119880119875

119862119878119862119894 119872119875119862119878119862119894 and

119900119897119889119875119882119894 to check the matching between 1198621198781198781198941198921 and1198621198941198781198941198921 Similarly in the authentication protocol 119862119878computes 119879119878119862119878 and replaces pseudonyms 119862119878 gener-ates three nonces 1198731198621198781 1198731198621198782 and 1198731198621198783 and then 119862119878computes the signature value (ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119900119897119889119875119882119894)) and hides the old119875119882119894 and new119875119882119894by 119900119897119889119875119882119894 oplus 1198731198621198782 oplus 1198621198781198781198941198922 and 119899119890119908119875119882119894 oplus 1198731198621198783 oplus1198621198781198781198941198922 It encrypts the password update request withsecurity parameters (119879119878119862119878 1198731198621198781 1198731198621198782 1198731198621198783 119880119875

119860119878119862119878

119872119875119860119878119862119878 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 and 1198621198781198781198941198922) andsends to 119860119878

(iii) 119860119878 side 119860119878 receives the password update requestand decrypts (119864119899119888119894) this request with 119860119878119870119901119903119894 and119862119878119870119901119906119894 It checks time delay and then it checkslink pseudonyms with real information for users Itextracts the old119875119882119894 from 119905119898119901 119900119897119889119875119882119894oplus1198731198621198782oplus1198621198781198781198941198922and then it checks the old 119875119882119894 in the dataset It com-putes the signature value 1198601198781198781198941198921 = ℎ(119879119878119862119878 1198731198621198781

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 2: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

2 Security and Communication Networks

detection or modification [6 12] Some of the recent cases ofsecurity threats on HC applications are presented as follows

(i) Penetration attacks on HC data in the United Statesrsquohospitals occurred (2013) These attacks revealed854 of the protected health information (PHI) ofthe 5 largest incidents for patientsrsquo records [13]

(ii) Apple Health (Medicaid) was exposed to data breach(2016) This attack revealed 370000 records of users(Washington state) [14]

(iii) An unauthenticated user penetrated the electronichealth record (EHR) containing 14633 records inthe New Jersey Diamond Institute for Fertility andMenopause (2017) [15]

The traditional cryptography (such as Rivest-Shamir-Adleman (RSA)) and signature (such as secure hashalgorithm-1 (SHA-1)) schemes require complex computationsthat consume server resources such as processing powerand memory to deal with large amounts of health datain HC applications [16] and thus which could renderthem unusable The electronic signature is used to checkthe integrity of the usersrsquo information in the authenticationrequest [17]Many lightweight algorithms such as PHOTONQUARK and SPONGENT are desired to implementelectronic signatures that perform lightweight operationsto reduce high overheads on the server HC applicationsrequire cryptographic and signature high-speed and securealgorithms [18] To implement an authentication schememany algorithms such as the Elliptic Curve Cryptography(ECC) RSA hash function bilinear pairing fuzzy extractorand XOR operation [19] are used in HC applicationprojects Many recent HC applications are based on ECCand RSA both of which provide the same security levelalthough ECC is more efficient than RSA The design of anauthentication protocol in HC applications should providemutual authentication resistance to known attacks suchas man-in-the-middle (MITM) eavesdropping tracingreplay impersonation guessing and denial-of-service (DoS)[20] protection of information and reduced cost and highefficiency [21 22]

11 Our Contributions We propose a Robust AuthenticationModel for HC Users (RAMHU) for HC applications thatperform massive and continuous authentication processeswhile simultaneously protecting against various attacks Ourcontributions include providing robust authentication forlegitimate users in the HC applications and access the serverrepository They are summarised as follows

(i) RAMHU uses lightweight algorithms for encryption(ECIES) and signature (PHOTON)These algorithmsprovide efficient and secure authentication for usersin HC applications compared to other algorithms

(ii) RAMHU applies a one-time password (OTP) mech-anism to authenticate users in their first registrationin the HC network with timestamp verification andrandom nonce generation to repel different types ofexternal attacks

(iii) RAMHU uses a multiple-pseudonym mechanism toprevent any association between the real informationpseudonyms and userrsquos data This mechanism pre-vents attackers from identifying HC users (providersand patients)

(iv) RAMHU integrates login request with media accesscontrol (MAC) address in addition to verifying thatthis address is original and not fake for authenticationof legitimate devices This prevents attackers fromusing different devices to compromise the networkinformation

(v) RAMHU improves the mutual authentication be-tween the server and clients to prevent spoofing andimpersonation attacks by either a fake server or clientThis prevents external attacks intended to deceivetrusted parties

(vi) We simulate RAMHU with an automated valida-tion of Internet security protocols and applications(AVISPA) tool that is generally acknowledged as aneffective way to represent the threat model We haveusedAVISPA to prove that ourmodel is secure againstboth passive and active attacks

12 Structure of the Paper The remainder of this paperproceeds as follows Section 2 discusses previous studiesrelated to our research The threat model and basic conceptsabout the techniques used in RAMHU are introduced inSection 3 Section 4 describes the proposed authenticationmodel Section 5 describes informal and formal securityanalysis for our proposed scheme The conclusion and futureresearch directions are presented in Section 6

2 Related Work

There are many authentication schemes in the literaturerelated to our research area This section discusses in briefthe suggestions in previous studies to design authenticationschemes in order to ensure the security of HC users in thenetwork We investigated these solutions and found that theyhad different drawbacks We will discuss the solutions andtheir disadvantages while clarifying the superiority of ourscheme over existing studies

He and Zeadally [1] proposed an authentication schemebased on ECC and advanced encryption standards (AES)algorithms Their scheme uses three entities user serverand controller The authors claimed that their scheme pro-vides many requirements such as mutual authenticationanonymity and forward confidentiality The problem withthis scheme is that user and controller identities are staticallysent to all three entities If the attacker can penetrate theencryption heshe can see the related user and controlleridentities The attacker can then generate a random numbertemporary key timestamp and message authentication codeSubsequently heshe can encrypt the user and controlleridentities and obtain the message authentication code andsend it to the network to become a legitimate and authen-ticated user In addition this scheme uses a 160-bit key with

Security and Communication Networks 3

ECC which is considered unreliable by trusted institutionssuch as the National Institute of Standards and Technology(NIST) Our scheme uses a 256-bit key and does not exchangereal information for legitimate users between clients andservers An authentication protocol was proposed to pro-tect patientsrsquo passwords by RSA against off-line password-guessing attacks [17] The main problem in their scheme isthat the authors used RSA with the 1024 key This algorithmaffects the performance of a hugeHCnetworkMany schemesrecommend using ECC [26ndash28] as the ECC-160 is equivalentto RSA-1024 with the same security level In addition theirprotocol suffers from sending an ID clearly from a client tothe server at the registration phase which causes authenti-cation information to be detected for analysis attacks Usinga shared key to implement an authentication mechanism isdesigned to prevent known attacks especially DoS attacks [6]The authors used the wrong password detection mechanismto reduce the risk of DoS attacks However the registrationphase of their scheme is not reliable if the ID of patients issent through an unsafe channel Additionally their researchsuffers 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 schemebased on ECC for HC environments They pointed outthat their scheme provides forward secrecy Their schemeprovides authentication during the exchange of messagesbetween the server and RFIDrsquos (radio-frequency identifica-tionrsquos) tag However their scheme shows that the information(identities) and data are stored on a single server and if theserver is hacked the usersrsquo information and data are exposedto detection tempering and modification The ECC and aPetri Nets model are proposed to achieve an authenticationrequirement to protect HC applications through the mobilecloud [24] The authors pointed out that their scheme isresistant to attacks of eavesdropping tracking replay andspoofing Unfortunately their scheme does not address theissue of stealloss of tag or device and internal attacks that aremore serious than external attacks in accessing patientsrsquo dataas well as no indication of what signature algorithm is usedfor integrity In addition the tagrsquos ID is explicitly sent fromserver to tag which makes it easier for the attacker to parsethe authentication request Jiang et al [25] designed a three-factor (biometric smart card and password) authenticationprotocol to protect e-health clouds Their scheme protectsauthentication requests from impersonation attacks and off-line password guessing if a mobile device is lost or stolenTheir scheme relies on ECC to support the confidentialityand authentication of HCrsquos usersThey used a fuzzy extractorto keep a biometric secret However this scheme relies ona single server to authenticate users which is the target ofthe attackers In addition it performs 7 hash operations thatcan exhaust the single server capabilities if the network has ahuge number of HC users especially if it is not a lightweighthash Our model has superior capacity as it uses a separationserver (attributes server) for usersrsquo information and also only5 lightweight hash operations in the central server

Cloud-assisted conditional privacy preserving authen-tication (CACPPA) [7] was proposed to authenticate thenetworkrsquos nodes This scheme used ECIES and the Elliptic

Curve Digital Signature Algorithm (ECDSA) with a times-tamp and pseudonym integration to perform the authen-tication process The problem with this scheme is that itdoes not provide mutual authentication to prevent an attackfrom a counterfeit party Furthermore the authors did notexplain the size of the keys in the algorithms to make surethat their scheme was able to repel the various attacksFurthermore a single pseudonym cannot separate the linkto the real information to prevent analysing and trackingattacks for authentication requests Das et al [5] provideda user authentication scheme for HC applications based onAES and hash (SHA-1) They used biometrics users and theanonymity feature to repel attacks such as replay MITMand privileged insider However their scheme will sufferfrom a key management problem if applied to a large healthinstitution with hundreds of users including managing usersrsquoaccounts from adding and deleting as symmetric encryptionsuffers from a scalability problem as well as the difficulty ofmanaging the single secret key Furthermore the attacker cansubmit a forgery attack on the login message if it detects thesingle secret key Recently Chandrakar andOm [19] providedan authentication scheme based on ECC and hash Theirscheme has supported several servers in user authenticationwith three factors In this case the user can connect to anyserver to perform the authentication process In this schemethe authors did not specify which hash algorithm was usedand the size of the message digest (MD) which is necessaryfor repelling attacks such as collision and preimage Usingmultiple servers means that the same usersrsquo information isstored on more than one server and thus the penetration ofany server that causes usersrsquo information to be detected ormodified Additionally this scheme did not use a mechanismto prevent the association of real user information withauthentication requests such as pseudonyms

3 The Basic Techniques for OurAuthentication Scheme

An authentication mechanism specifies connecting users tonetwork services securelyTheHC system needs a set of tech-niques to implement the authentication mechanism beforeaccessing patientsrsquo records One authentication techniquewill not be sufficient to repel known attacks To ensure thatonly legitimate users are associated with the HC applicationnetwork our project includes a set of techniques to validatethe authentication request In our scheme we relied onalgorithms that provide lightweight operations and a high-security level for encryption and signature operations Thissection describes the threat model and the basic concepts ofthese techniques

31 Threat Model The threat model has been used to detectsecurity weakness in authentication schemes The threatmodel is applied to RAMHU based on the Dolev-Yao (dy)[29] model in order to build a valid authentication processin insecure environments such as a WLAN or the InternetThe dy model is an efficient and practical way to illustratesecurity protocols in the real world In addition it is a

4 Security and Communication Networks

e first layercryptographic

protocol

e second layerelliptic curvepoint mul-tiplication

e third layerpoint operations

e lower finitefield arithmetic

ECC (ECIESECDSA

and ECDH)

Point multipli-cation (PM)

Point addition Point doubling

Multiplication Addition Squaring Inversion

Figure 1 Arithmetic operations in ECC hierarchy

Table 1 Keys sizes and some information for asymmetric algorithms

Algo Keys sizes Ratio Author(s) Year Mathematical problemRSA 1024 2048 3072 7680 15360

16-30Rivest Shamir and Adleman 1978 Integer factorization

Elgamal Taher Elgamal 1985 Multiplicative groupECIES 160-223 224-255 256-383 384-511 512-more Neal Koblitz and Victor Miller 1985 Elliptic curve discrete log (ECDLP)

formal exemplar for modelling the risk of attackers againstauthentication protocols This model is useful in detectinginternal external single and multiple attacks [30] In ourthreat model we assume that an intruder is capable ofcarrying out an internal external passive or active attacksuch asMITM replay eavesdropping and spoofing Also weassume that the attributes server (119860119878) is trustworthy It is safeagainst repository penetration attacks We assume threats inour model as follows

(i) The attacker can steal the client application and itsfiles to analyse the data retrieve the parameters andreveal the secret key and then use these applicationson different devices

(ii) The attacker can listen for authentication requests inthe insecure environment and execute interceptionreplay and MITM attacks in order to become alegitimate user in the network

(iii) The attacker can execute a forgery or masqueradingattack in an attempt to penetrate the authenticationprocess

(iv) A legitimate user can perform a privileged insiderattack based on hisher legitimacy in the network

(v) The attacker can successfully guess the real usernamepassword role and pseudonym associated with itduring intensive analysis of many authenticationrequests

32 Overview of Techniques

(i) Elliptic Curve Integrated Encryption Scheme (ECIES)Elliptic Curve Cryptography (ECC) has been used to providesecurity requirements It provides confidentiality integrity

and authentication in the communications network withlimited capacity in terms of power and processing Thisalgorithm was independently proposed by Neal Koblitz andVictorMiller in 1985 [31] It depends on the discrete logarithmproblem (DLP) which is impervious to known attacks whenselecting parameters accurately [32] ie difficulty obtainingk from P and Q (where k is an integer and P and Q aretwo points on the curve) Small parameters used in ECChelp to perform computations quickly These computationsare important in constrained-source and large environmentsthat require processing power memory or power con-sumption [20 33] ECC provides encryption (Elliptic CurveIntegrated Encryption Scheme (ECIES)) signature (EllipticCurve Digital Signature Algorithm (ECDSA)) and exchangekeys (Elliptic Curve Diffie-Hellman (ECDH)) approaches[31] Many operations are performed in ECC algorithms(described in four layers) as shown in Figure 1 [34] ECIEShas provided confidentiality and proven to be extremelyefficient in its performance as it uses small keys thus thecost of computation is small compared with other public keycryptography algorithms such as Rivest-Shamir-Adleman(RSA) [35] Table 1 [33 36 37] shows a comparison of keysizes for public key encryption algorithms

(ii) Lightweight Hash-Function Algorithm The hash functionhas been used to generate signatures for authenticationrequests PHOTON is a lightweight hash function andextremely suitable for projects that require a robust andreliable signature This algorithm is based on a spongelikeconstruction and AES-like primitive for domain extensionand permutation efficiency [38ndash40] PHOTON is available inseveral versions (80 128 160 224 and 256) It is a balancebetween the efficiency in the execution of computations onthe one hand and security in the implementation of the

Security and Communication Networks 5

Table 2 Comparison of lightweight hash function algorithms

Algorithm Performance MD Security Author (s) YearGate equivalent area Throughput (kbps) PR SPR CR

SQUASH 2646 GE 015 64 64 64 0 Shamir 2005MAME 8100 GE 1467 256 - - - Yoshida et al 2007C-PRESENT-192 8048 GE 5926 192 192 192 96 Bogdanov et al 2008ARMADILLO2 8653 GE 938 256 256 256 128 Bald et al 2010S-QUARK 2296 GE 313 256 224 112 112 Aumasson et al 2010KECCAK-f[400] 5090 GE 144 128 128 128 64 Kavun and Yalcin 2010GLUON 4724 GE 32 224 224 112 112 Berger et al 2011SPONGENT-256 3281 GE 1143 256 240 128 128 Bogdanov et al 2011PHOTON-256 2177 GE 088 256 224 128 128 Guo et al 2011

features of the signature principle that depend on preimageresistant (PR) second preimage resistant (SPR) collisionresistant (CR) and mixing-transformation [17] on the otherhand It uses sponge construction and applies two phasesof absorbing and squeezing to produce a message digest(MD) more details are available in [41] Table 2 providesa comparison among the lightweight hash algorithms (thelatest version of these algorithms) in terms of security andefficiency [39 41ndash46] Although standard hash algorithmsare still used in applications such as SHA-1 (5527 GE MD160-bit) and SHA-2 (10868 GE MD 256-bit) lightweighthash algorithms such as PHOTON (2177 GE MD 256-bit)provides the most effective solution for handling complexsignatures in large HC systems

Table 2 shows that the PHOTON-256 (2177 GE) providesthe best performance compared to all lightweight hashfunctions and offers a high level of security through theapplication of signature features PR (224) SPR (128) and CR(128) Linear and differential attacks are the most powerfulattacks in the MD analysis of hash functions Compared toPHOTON ARMADILLO and SPONGENT-256 also offersignature features but both are vulnerable to attacks whereARMIDLLO2 has been attacked by local linearization (prac-tical semi-free-start collision attack) [47] and SPONGENThas been attacked by linear distinguishers (23 rounds [48] and13 rounds [49]) for all SPONGENTversions and additionallythey need the most computations (3281 GE and 8653 GE)compared with PHOTON-256 (2177 GE) PHOTON is areliable algorithm against linear and differential attacks [41]It has a high level of security and efficiency therefore it issuitable for our project as a signature mechanism

(iii) One-Time Password (OTP) The OTP is a way to authen-ticate legitimate users by generating a passcode or nonceonly once in a specified time It will not be applicablethe next times for authentication The OTP is an effectivemethod for authenticating users in HC applications if usedwith robust encryption and signature technologies Usinga static password or nonce without other authenticationmechanisms is weak in respect to attacks Therefore an OTPprovides significant support to the authentication processThismechanismpreventsmany attacks such as replayMITM

and guessing [50] The attacker cannot use this passcode ornonce to connect to the network later The client sends anOTP as part of an authentication request If the authenticationprocess is valid the server will delete the OTP from thedataset and will not accept it in the future The OTPis a powerful mechanism to mitigate the risk of hackersrsquocommunication in the network In this project we apply anOTP to generate a random password with the first link tousers in HC applications to ensure that only legitimate usersare connected to the network

(iv) Mutual Authentication Mutual authentication is a pre-requisite for preventing fraudulent authentication requestsThe traditional methods of authentication (such as passwordand name) are not suitable for HC applications [18] Ingeneral there are two kinds of authentication simple andmutual In simple authentication one party performs theauthentication process for example the server verifies theauthentication request for the client This type of authenti-cation is vulnerable to attacks such as spoofing and imper-sonation The attacker can use his device as a fake server toreceive all clientsrsquo requests Mutual authentication providesa security solution to prevent known attacks [18] In thistype of authentication each party authenticates the otherparty and thus prevents counterfeit attacks by both the clientand server In RAMHU we adopt the mechanism of mutualauthentication in the preservation of usersrsquo information anddata

(v) Media Access Control (MAC) Address AMAC address hasbeenused to distinguish legitimate usersrsquo devices in a networkduring the completion of the authentication process Allnetwork devices of different types should contain a hardwarecard (interface) to connect to the local or global networkEach wire or wireless interface has a media access control(MAC) or physical address that consists of 48 bits It is dividedinto six octets and written in hexadecimals such as ldquo8C70 5A 41 49 BCrdquo This address is a unique identifier (noduplicate address twice) for a device defined as global andpersistent [51] This address is used in WLAN because itoffers advantages such as reducing costs and speed in accesscontrol procedures [52] It can be changed programmatically

6 Security and Communication Networks

Table 3 Paperrsquos notations

Symbol Description119862119894 Client entity or user119862119878 Central server119860119878 Attributes server119863119878 Data server119880119868119863119894 119872119868119863119894 119862119894rsquos identity and medical centre identity119875119882119894 119905119898119901119875119882119894 119862119894rsquos password temporary password119862119894119870119901119906119894 119862119894119870119901119903119894 119862119894 public and private key119862119878119870119901119906119894 119862119878119870119901119903119894 119862119878 public and private key119860119878119870119901119906119894 119860119878119870119901119903119894 119860119878 public and private key119879119878119862119894 119879119878119862119878 119879119878119860119878 Timestamp generated by 119862119894 119862119878 119860119878

119873119862119894 119873119862119878 119873119860119878 Nonce random generated by 119862119894 119862119878 119860119878

119868 Internal or external intruder119868119868 119864119868 Internal intruder and external intruderℎ() One-way hash function119877119894 Role of patient patient relative or provider119877119877119894 Revocation reason119874119879119875119894 One-time password to authenticate first time119862119894119878119894119892119895 Signature generated by 119862119894 and j is signature number119862119878119878119894119892119895 Signature generated by 119862119878119860119878119878119894119892119895 Signature generated by 119860119878119880119875119862119878119862119894 119875119872

119862119878119862119894

User and medical centre pseudonyms sent by 119862119894 and verified by 119862119878119880119875119860119878119862119878 119875119872

119860119878119862119878 User and medical centre pseudonyms sent by 119862119878 and verified by 119860119878

119880119875119862119878119860119878 119875119872119862119878119860119878 User and medical centre pseudonyms sent by 119860119878 and verified by 119862119878

119880119875119862119894119862119878 119875119872

119862119894119862119878 User and medical centre pseudonyms sent by 119862119878 and verified by 119862119894

oplus Concatenation and exclusive or operations119866119872 119862119872 Get MAC and checkMAC address119864119899119888119894 119863119890119888119894 Encryption and decryption operations

in various operating systems such as Linux and WindowsIn addition anyone can use the Address Resolution Protocol(ARP) to detect the MAC address of another user in thenetwork [53] The main problem with this address is thatthe attacker can execute an eavesdropping attack to accessthe MAC addresses of legitimate devices in the network andthen select a legitimate MAC address to use it For instancean attacker could execute an ARP poisoning or spoofingattack by using a fake identifier of the MAC address (for alegitimate entity) to gain illegal privileges that would enableit to perform other attacks such as MITM and DoS [54]In addition randomization operations for the MAC addresshave become useless in the protection against tracking attacks[55 56] Therefore if the server does not have a mechanismto detect MAC address change the attacker becomes alegitimate user in the network and has access to networkresources

4 The Proposed Authentication Scheme

In this section we will detail RAMHU that provides securityand efficiency features in HC applications This sectionwill be divided into the network model security goalsand proposed authentication protocols Notations listed in

Table 3 are used to describe symbols used throughout thispaper

41 Network Model The RAMHU model consists of fourentities as shown in Figure 2

(1) Client (119862119894) This entity includes patients relativesof patients and HC providers such as doctorsresearchers emergency practitioners advisors andnurses

(2) Central server (119862119878) This entity is a gateway toauthenticate users with the attributes server and toauthorise the data server

(3) Attributes server (119860119878) This entity contains usersrsquo realinformation as well as multiple pseudonyms Theauthentication process requires verifying the asso-ciation of the actual information with the multiplepseudonyms in this entity

(4) Data server (119863119878) This entity contains usersrsquo dataas well as multiple pseudonyms This entity is notimplemented in our scheme and is left to future workOur scheme focuses only on the process of usersrsquoauthentication in the HC network

Security and Communication Networks 7

Network model

Acknowledgement

Client

Attributes server (AS)

Central server (CS)

Data server (DS)

Authentication request

Informationrepository

Datarepository

Check userrsquos information

Response

Authentication request

Response

Acknowledgement Data request(with pseudonyms)

Figure 2 General network model

Generally 119862119894 creates an authentication request mainlybased on ECIES and PHOTON 119862119894 sends a request to 119862119878 toverify encryption signature and security parameters (suchas MAC address pseudonyms and 119874119879119875119894) Then the 119862119878sends a request to the 119860119878 to verify the link between thepseudonyms the real information the signatures and 119875119882119894After that the 119860119878 sends the response to the 119862119878 that verifiesthe signature and the parameters and then the 119862119878 sendsthe response (authenticated or not) to the 119862119894 If the useris authenticated we assume that the user can then send anauthorisation request to access the data in the repository (119863119878)and obtain the authorisation response from the 119862119878 119860119878 and119863119878

42 Security Goals To build a robust authentication schemeRAMHU adopts the following security requirements

(i) Confidentiality This requirement is performed tohide authentication information and to preserve usersecrecy from detection by intruders To implementthis requirement a high-security cryptographic algo-rithm [20] should be used RAMHU executes ECIESto hide authentication information about intruders

(ii) Integrity This is to protect the authentication requestinformation from modification by intruders Theauthentication request should reach the intendeddestination without modification to provide a reliablecommunication channel for legitimate users [10 57]RAMHU performs a PHOTON to prevent any pro-cess ofmodifying the user authentication informationin HC applications

(iii) Nonrepudiation This requirement prevents both theclients and server from denying their authenticationrequests This is a way to prove that the message issent by a particular sender in the HC applications

network If a legitimate user in the network performsinternal attacks heshe cannot deny hisher activitieswhile exploiting the privileges granted to himherOur scheme uses PHOTON signatures and a MACaddress tomeet this requirement and detectmaliciousattacks

(iv) Anonymity This requirement is extremely impor-tant in supporting the confidentiality of the authen-tication request The purpose of this requirementis to disguise the source and destination of theauthentication request If the authentication schemeapplies anonymity with encryption the attackerfinds it exceedingly difficult to analyse authentica-tion requests for a particular user at different timesbecause the authentication request is different eachtime the user is connected to the network [7]RAMHU applies this requirement through the use ofrandom nonces between entities

(v) Pseudonym This requirement denotes the provisionof a mechanism to connect nonreal attributes (suchas terms and symbols) with the real attributes of theuser (such as name address and phone number)The use of this mechanism in HC applications isan extremely important way to protect the personalinformation of users and prevent the detection oftheir identities RAMHU uses a multiple-pseudonymmechanism to prevent and separate the associationwith real information

(vi) Forward secrecy This requirement is accomplishedwhen network users use new keys and parameterstemporarily without relying on old onesThis require-ment prevents attackers from exploiting usersrsquo keysand passwords in decrypting authentication requestsUsing the temporary random password private key

8 Security and Communication Networks

and MAC RAMHU prevents users from accessingprevious authentication information

(vii) Mutual authentication This requirement is used inHCapplications tomitigate the risks of external fraudWith this feature each party ensures that it deals witha legitimate party The server authenticates the clientby checking encryptions and signatures and viceversa in order to establish a secure communicationchannel In RAMHU 119862119878 and 119862119894 authenticate eachother to prevent masquerading and impersonatingattacks

(viii) ScalabilityHCapplications operate in a scalable envi-ronment in terms of data and users Therefore theseapplications require authentication schemes capableof handling and adapting to the ever-increasing num-ber of users of HC applications This requirementrefers to the ability of the authentication scheme toappropriately handle large HC systems Public keyencryption schemes are efficient in supporting thisrequirement [24]

(ix) FreshnessThis requirement indicates that the authen-tication request is new and updated to ensure thatthe attacker cannot replay the authentication requestat a later time This requirement is achieved throughthe provision of time checking a random nonce andchange of signatures in each authentication process tocounteract counterfeit attacks such as MITM replayand impersonation [20] which ensures that theauthentication request is unaltered or not tamperedwith

43 Proposed Authentication Scheme The RAMHU schemeconsists of 5 protocols initial setup registrationloginauthentication password update and revocation Duringthese protocols RAMHU provides reliable authenticationprocesses to protect usersrsquo information

431 Initial Setup Protocol In this protocol all entitiesare ready to start communicating with each other whileconfiguring all security parameters and ECIESrsquos keys as in thefollowing steps

(i) Each legitimate user receives a client application fromthe authorised system provider

(ii) Each legitimate user receives a 119875119882119894 (that can bechanged later) and a random 119874119879119875119894 to be used in thefirst registration

(iii) All entities (119862119894 119862119878 and 119860119878) should create publicand private keys (119862119894 (119862119870119901119906119894 119862119870119901119903119894) 119862119878 (119862119878119870119901119906119894 119862119878119870119901119903119894) and 119860119878 (119860119878119870119901119906119894 119860119878119870119901119903119894)) to be used tovalidate the authentication request All entities choosean elliptic curve 119864119901(119886 119887) over a prime field 119865119875 (where119875 = 256) and base point 119866 on curve Each entityselects a private key 119870119901119903119894 randomly and generates thepublic key 119870119901119906119894 during the implementation of scalarmultiplication (119870119901119906119894 = 119870119901119903119894 lowast 119866)

(iv) All entities broadcast the public key (119862119870119901119906119894 119862119878119870119901119906119894 and 119860119878119870119901119906119894) to use in ECIESrsquos encryption operations

432 Registration and Login Protocol Patients and HCproviders (119862119894) should complete the registration and loginprotocol with 119862119878 to become legitimate users of HC appli-cations Without this protocol the user cannot completethe authentication process in RAMHU User registration isperformed once namely the user does not need to completethe registration protocol the next times (only the loginprotocol) the registration information has been kept in theservers until the revocation protocol and deletion of the usersecurity parameters such as pseudonyms MAC address and119875119882119894 this protocol accomplishes the following steps (Figure 3shows the registration and login protocol and Figure 4 showsthe login protocol)

119862119894 Side

(i) The user enters 119880119868119863119894 (such as hisher name) 119872119868119863119894(such as medical centre name) and 119875119882119894 and 119874119879119875119894for registration and login while only entering 119880119868119863119894119872119868119863119894 and119875119882119894 for the login protocol the next times tothe client (119862119894) application119862119894 replaces119880119868119863119894with userrsquospseudonym (119880119875119862119878119862119894 ) and 119872119868119863119894 with medical centrepseudonym (119872119875119862119878119862119894 ) to protect the authenticationinformationwhenmoving from119862119894 to119862119878119862119894 generatesa timestamp (119879119878119862119894) to be used to verify the sendingtime of the registrationlogin request in 119862119878

(ii) 119862119894 gets a MAC address (GM) by entering its IP(Internet protocol) address The process of checkingMAC (119862119872) is performed by 119862119894 to test the cred-ibility of the MAC address In the Linux systemwe used the command ldquoethtool -P interface namerdquo(such as ldquoethtool -P wlo1rdquo) in the 119862119894 applicationIf the result is identical to 119866119872 it means that theMAC address is native (119862119872 = ldquo119877119890119886119897 119872119860119862rdquo) Inthe Windows system 119862119894 searches for string valueldquoNetworkAddressrdquo in the path of the system reg-istry (ldquo119867119870119864119884 119871119874119862119860119871 119872119860119862119867119868119873119864 119878119884119878119879119864119872 119862119906119903119903119890119899119905119862119900119899119905119903119900119897119878119890119905 119862119900119899119905119903119900119897 119862119897119886119904119904 411986336119864972 minus119864325 minus 11119862119864 minus 1198611198651198621 minus 0800211986111986410318rdquo) If Net-workAddress = null 119862119872 = ldquo119877119890119886119897 119872119860119862rdquo otherwise119862119872 = ldquo119865119886119896119890 119872119860119862rdquo The 119866119872 send is encrypted witha registrationlogin request while 119862119872 is implicitlysent with the signature value (1198621198941198781198941198921) In only thelogin protocol 119862119894 needs to extract a private keyfrom the temporary keyMAC address password andrandom nonce through 119905119898119901119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus119873119862119894 119862119894 generates a random nonce (119873119862119894) to changesignature and encryption data and add anonymity tothe registrationlogin request

(iii) 119862119894 performs two signatures using the PHOTON-256algorithm to protect information from modificationThe first signature includes the parameters checkMAC nonce and timestamp (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) The second signature includes allthe authentication parameters of the gotten MAC

Security and Communication Networks 9

CS AS

Figure 3 Registration and login protocol

nonce timestamp first signature pseudonyms one-time password and password (1198621198941198781198941198922 = ℎ(119866119872

119873119862119894 119879119878119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875

119875119882119894)) In the login protocol 119874119879119875 is not added to thesignature

(iv) 119862119894 computes a temporary value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus 1198621198941198781198941198921) of 119875119882119894 when moving from 119862119894 to119862119878

(v) 119862119894 uses ECIES to encrypt and hide all the data ofthis request (119864119899119888119894(119879119878119862119894 119873119862119894 119866119872 1198621198941198781198941198921

119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875119894 119905119898119901119875119882119894 1198621198941198781198941198922)) Inthe login protocol 119874119879119875119894 and 119866119872 are not added tothe encryption as in Figure 4 After that 119862119894 sendsthe registration and login request or login to 119862119878 tocomplete the authentication protocol Then 119862119894 hidesthe private key by 119905119898119901119862119894119870119901119903119894 = 119862119894119870119901119903119894 oplus119875119882119894 oplus1198621198941198781198941198922

119862119878 Side

(i) Upon receiving a registration and login request orlogin request 119862119878 decrypts this request using ECIESrsquos119862119894119870119901119906119894 and 119862119878119870119901119903119894 It checks the timestamp (119879119878119862119878-119879119878119862119894 le 998779119879) to make sure that this request arrived atan appropriate time and without delay

(ii) In the registration and login protocol 119862119878 examinesthe random 119874119879119875119894 in the dataset If 119874119879119875119894 exists thenthe user is legitimate for the registration process After

that 119862119878 deletes 119874119879119875119894 from the dataset to prevent itfrom being used the next times If 119874119879119875119894 is not foundit discards the connection In the login protocol119862119878 examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 and then tests theirassociation with the MAC address in the dataset If119866119872 is found 119862119878 completes the steps of this protocolotherwise it cancels the connection

(iii) 119862119878 needs to ensure that the userrsquos device is legitimatewithin the network 119862119878 computes the signature valueto make sure that the MAC address is native andnonmodified (1198621198781198781198941198921 = ℎ(ldquoReal MACrdquo 119873119862119894 119879119878119862119894)) It examines the result of the computed sig-nature (1198621198781198781198941198921) with 119862119894rsquos signature (1198621198941198781198941198921) If thesignatures results are identical then the device islegitimate and the MAC address did not change Inthe registration and login protocol 119862119878 stores thisaddress in the dataset for use and checks the nexttimes in the login protocol

(iv) 119862119878 performs the computation operation 119905119898119901119875119882119894 oplus119873119862119894 oplus119866119872oplus1198621198781198781198941198921 to extract the 119875119882119894 value and thenuses this value to produce a second signature (1198621198781198781198941198922)

(v) 119862119878 computes a second signature operation (1198621198781198781198941198922=ℎ(119866119872 119873119862119894 119879119878119862119894 1198621198781198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894

119874119879119875119894 119875119882119894)) to guarantee that all the encryptedinformation is not changed Then it compares thecomputed signature (1198621198781198781198941198922) with the received sig-nature in the request (1198621198941198781198941198922) If the signatures are

10 Security and Communication Networks

CS AS

Figure 4 Login protocol

identical then the information for this request isunchanged or not tampered with In the login proto-col 119874119879119875119894 and 119866119872 are not added to the signature Atthis point 119862119878 prepares to send the userrsquos authentica-tion request to 119860119878

433 Authentication Protocol The authentication protocolverifies the reliability of the usersrsquo security parameters withtheir personal information in the server In this protocolRAMHU needs to link pseudonyms and passwords with realinformation for users in 119860119878rsquos datasets Note that the usersrsquoinformation (such as name age address mobile number andpasswords) is stored in a separate server (AS) and multiplepseudonyms are used to prevent detection and trackingof usersrsquo information This protocol is illustrated in thefollowing steps (Figure 5 shows the authentication protocolin RAMHU)

119862119878 Side

(i) 119862119878 computes a new timestamp (119879119878119862119878) to ensure thefresh authentication request

(ii) 119862119878 replaces 119862119894rsquos pseudonyms (119880119875119862119878119862119894 and119872119875119862119878119862119894 ) with119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119872119875119860119878119862119878 ) to prevent attack-ers from tracking the authentication request It gen-erates random nonce (119873119862119878) to ensure an anonymousauthentication request

(iii) 119862119878 signs security parameters by PHOTON-256(1198621198781198781198941198923 = ℎ(119879119878119862119878 119873119862119878 119880119875

119860119878119862119878 119872119875119860119878119862119878 )) to prevent

modification of authentication request information(iv) 119862119878 computes temporary 119875119882119894 by the computation of

119875119882119894 oplus 119873119862119878 oplus 1198621198781198781198941198923

(v) 119862119878 encrypts information of authentication request(119864119899119888119894(119879119878119862119878 119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 1198621198781198781198941198923 119905119898119901119875119882119894)) It sends an authentication request to verifyuserrsquos information in 119860119878

119860119878 Side

(i) Upon receiving the authentication request 119860119878 de-crypts that request using ECIESrsquos 119860119878119870119901119903119894 and 119862119878119870119901119906119894to obtain the authentication information clearly

(ii) It checks the timestamp by 119879119878119860119878 minus 119879119878119862119878 le 998779119879 toensure that the authentication request is not delayed119860119878 checks the pseudonyms (119880119875119860119878119862119878 and 119872119875119860119878119862119878 ) sentfromCS and correlates them with the userrsquos real iden-tifier (119880119868119863119894 and119872119868119863119894) in the datasets 119860119878 extracts theuserrsquos password from the equation 119875119882119894 = 119905119898119901119875119882i oplus119873119862119878oplus1198621198781198781198941198923 After that it checksmatching119875119882119894 in thedataset 119860119878 computes the value of the signature basedon authentication information (1198601198781198781198941198921 = ℎ(119879119878119862119878

119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 )) by PHOTON-256 119860119878 com-

pares the computed value of the signature (1198601198781198781198941198921)with the value of the received signature (1198621198781198781198941198923) If

Security and Communication Networks 11

CS AS

Figure 5 Authentication protocol

the signature values are identical the userrsquos informa-tion in the request for the signature is unmodified Atthis point 119860119878 considers this user to be legitimate andreliable

(iii) 119860119878 prepares a response to authenticate the request ofthat user It computes a new timestamp (119879119878119860119878 = new119879119878119860119878) to prevent delayed or replayed requests at latertimes119860119878 replaces119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119880119875

119860119878119862119878 )

received with 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) tohide usersrsquo information It generates a new randomnonce (119873119860119878) to add anonymity and prevent attacksfrom encryption and signature analysis

(iv) 119860119878 computes a signature (1198601198781198781198941198922 = ℎ(119879119878119860119878 119873119860119878

119880119875119862119878119860119878 119872119875119862119878119860119878 )) to prevent modifications of authenti-cation response information

(v) 119860119878 encrypts the authentication information(119864119899119888119894(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 1198601198781198781198941198922))and sends the authentication response to 119862119878 tocomplete the authentication process

119862119878 Side(i) 119862119878 decrypts the authentication response (119864119899119888119894)

received from 119860119878 It checks the timestamp value(119879119878119862119878 minus 119879119878119860119878 le 998779119879) to prevent late authentication

12 Security and Communication Networks

responses It examines 119880119875119860119878119862119878 and119872119875119860119878119862119878 in datasets tocomplete the process of linking multiple pseudonymsto the user

(ii) 119862119878 computes the signature 1198621198781198781198941198924 = ℎ(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 ) for authentication response infor-mation It compares the computed result of thesignature (1198621198781198781198941198924) with the value of the receivedsignature (1198601198781198781198941198922) If the signature values matchthen the authentication response information is un-changed

(iii) After this point 119862119878 initiates a login response requestIt computes the value of new timestamp (119879119878119862119878 =

119899119890119908119879119878119862119878) It replaces 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) received with 119880119875

119862119894119862119878 and 119872119875

119862119894119862119878 It generates

a new random nonce (119873119862119878) to hide encryption andsignature information

(iv) 119862119878 computes a new signature value (1198621198781198781198941198925 =

ℎ(119879119878119862119878 119873119862119878 119880119875119862119894119862119878

119872119875119862119894119862119878)) to protect login

response information frommodification(v) 119862119878 encrypts login response information (119864119899119888119894(119879119878119862119878

119873119862S 119880119875119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sends thisresponse to 119862119894

119862119894 Side

(i) 119862119894 extracts his private key (119862119894119870119901119903119894) from 119905119898119901119862119894119870119901119903119894 oplus119875119882119894 oplus 1198621198941198781198941198922 and decrypts the login request (119864119899119888119894)received from 119862119878

(ii) 119862119894 checks the timestamp (119879119878119862119894 minus119879119878119862119878 le 998779119879) to ensurethat the login response is not late or replayed

(iii) 119862119894 checks that 119862119878rsquos pseudonyms (119880119875119862119894119862119878 and 119872119875119862119894119862119878)

are received in the dataset and associated with 119880119875119862119878119862119894and 119872119875C119878

119862119894 At this point RAMHU applied multiple

pseudonyms among model entities (119862119894 119862119878 and 119860119878)to prevent traceability in linking the real informationof the user with pseudonyms

(iv) 119862119894 calculates the value of the signature 1198621198941198781198941198923 =

ℎ(119879119878119862119878 119873C119878 119880119875119862119894119862119878 119872119875

119862119894119862119878) for login re-

sponse information It compares the result of thecomputed signature (1198621198941198781198941198923) and the value of thereceived signature (1198621198781198781198941198925 ) If the signature values areidentical namely the login response information isunmodified or not tamperedwith119862119894 accepts the loginresponse otherwise 119862119894 discards the login responseThen119862119894 hides its private key by 119862119894119870119901119903119894 oplus119866119872oplus119875119882119894 oplus119873119862119894 after generating a random nonce to prevent thedetection of the private key if the device is hackedAt this point if all processes are achieved correctlythen all requests are considered legitimate and reli-able through the implementation of mutual authenti-cation

434 Password Update Protocol Updating the password isa security procedure to ensure authentication of legitimate

users The process of changing 119875119882119894 is important in any HCsystem for two reasons First it prevents the use of 119875119882119894fixed for a long time which reduces the guessing attacksSecond changing119875119882119894 gives usersmore flexibility in choosingthe appropriate 119875119882119894 This process requires strict securitymeasures to protect the new 119875119882119894 RAMHU provides thelegitimate user with amechanism to change hisher passwordat any time If the user wants to change hisher 119875119882119894the following illustration describes the new 119875119882119894 protectionprocedures in a secure manner (Figure 6 shows the passwordupdate protocol in RAMHU)

(i) 119862119894 side 119862119894 enters 119880119868119863119894 119872119868119863119894 the old 119875119882119894 andthe new 119875119882119894 It replaces 119880119868119863119894 and 119872119868119863119894 withpseudonyms to hide the userrsquos real information 119862119894calls the MAC address and then extracts the privatekey from 119905119898119901119862119894119870119901119903119894oplus119866119872oplus119900119897119889119875119882119894oplus119873119862119894 to use in theencryption process of the password update request119862119894generates three random nonces (1198731198621 1198731198622 and 1198731198623)and computes a new timestamp (119879119878119862119894) 119862119894 computesthe signature value (1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)) by PHOTON-256 basedon the parameters of the password change requestIt applies an anonymity mechanism to the old 119875119882119894and new 119875119882119894 (119905119898119901 119900119897119889119875119882119894 = 119900119897119889119875119882119894 oplus1198731198622 oplus 1198621198941198781198941198921and 119905119898119901 119899119890119908119875119882119894 = 119899119890119908119875119882119894 oplus 1198731198623 oplus 1198621198941198781198941198921) to hidepasswords and not explicitly send them in the 119875119882119894change request It encrypts the 119875119882119894 change request(119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) and sends itto 119862119878 119862119894 then hides its private key by 119862119894119870119901119903119894 oplus 119866119872oplus119899119890119908119875119882119894 oplus 119873119862119894

(ii) 119862119878 side 119862119878 receives and decrypts a password updaterequest (119864119899119888119894) It examines the timestamp to preventdelayed requests and examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 indatasets 119862119878 extracts the old 119875119882119894 and new 119875119882119894 from119905119898119901 119900119897119889119875119882119894 oplus 1198731198622 oplus 1198621198941198781198941198921 and 119905119898119901 119899119890119908119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 Then it computes the signature value(1198621198781198781198941198921) depending on 119879119878119862119894 1198731198621 119880119875

119862119878119862119894 119872119875119862119878119862119894 and

119900119897119889119875119882119894 to check the matching between 1198621198781198781198941198921 and1198621198941198781198941198921 Similarly in the authentication protocol 119862119878computes 119879119878119862119878 and replaces pseudonyms 119862119878 gener-ates three nonces 1198731198621198781 1198731198621198782 and 1198731198621198783 and then 119862119878computes the signature value (ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119900119897119889119875119882119894)) and hides the old119875119882119894 and new119875119882119894by 119900119897119889119875119882119894 oplus 1198731198621198782 oplus 1198621198781198781198941198922 and 119899119890119908119875119882119894 oplus 1198731198621198783 oplus1198621198781198781198941198922 It encrypts the password update request withsecurity parameters (119879119878119862119878 1198731198621198781 1198731198621198782 1198731198621198783 119880119875

119860119878119862119878

119872119875119860119878119862119878 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 and 1198621198781198781198941198922) andsends to 119860119878

(iii) 119860119878 side 119860119878 receives the password update requestand decrypts (119864119899119888119894) this request with 119860119878119870119901119903119894 and119862119878119870119901119906119894 It checks time delay and then it checkslink pseudonyms with real information for users Itextracts the old119875119882119894 from 119905119898119901 119900119897119889119875119882119894oplus1198731198621198782oplus1198621198781198781198941198922and then it checks the old 119875119882119894 in the dataset It com-putes the signature value 1198601198781198781198941198921 = ℎ(119879119878119862119878 1198731198621198781

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 3: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Security and Communication Networks 3

ECC which is considered unreliable by trusted institutionssuch as the National Institute of Standards and Technology(NIST) Our scheme uses a 256-bit key and does not exchangereal information for legitimate users between clients andservers An authentication protocol was proposed to pro-tect patientsrsquo passwords by RSA against off-line password-guessing attacks [17] The main problem in their scheme isthat the authors used RSA with the 1024 key This algorithmaffects the performance of a hugeHCnetworkMany schemesrecommend using ECC [26ndash28] as the ECC-160 is equivalentto RSA-1024 with the same security level In addition theirprotocol suffers from sending an ID clearly from a client tothe server at the registration phase which causes authenti-cation information to be detected for analysis attacks Usinga shared key to implement an authentication mechanism isdesigned to prevent known attacks especially DoS attacks [6]The authors used the wrong password detection mechanismto reduce the risk of DoS attacks However the registrationphase of their scheme is not reliable if the ID of patients issent through an unsafe channel Additionally their researchsuffers 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 schemebased on ECC for HC environments They pointed outthat their scheme provides forward secrecy Their schemeprovides authentication during the exchange of messagesbetween the server and RFIDrsquos (radio-frequency identifica-tionrsquos) tag However their scheme shows that the information(identities) and data are stored on a single server and if theserver is hacked the usersrsquo information and data are exposedto detection tempering and modification The ECC and aPetri Nets model are proposed to achieve an authenticationrequirement to protect HC applications through the mobilecloud [24] The authors pointed out that their scheme isresistant to attacks of eavesdropping tracking replay andspoofing Unfortunately their scheme does not address theissue of stealloss of tag or device and internal attacks that aremore serious than external attacks in accessing patientsrsquo dataas well as no indication of what signature algorithm is usedfor integrity In addition the tagrsquos ID is explicitly sent fromserver to tag which makes it easier for the attacker to parsethe authentication request Jiang et al [25] designed a three-factor (biometric smart card and password) authenticationprotocol to protect e-health clouds Their scheme protectsauthentication requests from impersonation attacks and off-line password guessing if a mobile device is lost or stolenTheir scheme relies on ECC to support the confidentialityand authentication of HCrsquos usersThey used a fuzzy extractorto keep a biometric secret However this scheme relies ona single server to authenticate users which is the target ofthe attackers In addition it performs 7 hash operations thatcan exhaust the single server capabilities if the network has ahuge number of HC users especially if it is not a lightweighthash Our model has superior capacity as it uses a separationserver (attributes server) for usersrsquo information and also only5 lightweight hash operations in the central server

Cloud-assisted conditional privacy preserving authen-tication (CACPPA) [7] was proposed to authenticate thenetworkrsquos nodes This scheme used ECIES and the Elliptic

Curve Digital Signature Algorithm (ECDSA) with a times-tamp and pseudonym integration to perform the authen-tication process The problem with this scheme is that itdoes not provide mutual authentication to prevent an attackfrom a counterfeit party Furthermore the authors did notexplain the size of the keys in the algorithms to make surethat their scheme was able to repel the various attacksFurthermore a single pseudonym cannot separate the linkto the real information to prevent analysing and trackingattacks for authentication requests Das et al [5] provideda user authentication scheme for HC applications based onAES and hash (SHA-1) They used biometrics users and theanonymity feature to repel attacks such as replay MITMand privileged insider However their scheme will sufferfrom a key management problem if applied to a large healthinstitution with hundreds of users including managing usersrsquoaccounts from adding and deleting as symmetric encryptionsuffers from a scalability problem as well as the difficulty ofmanaging the single secret key Furthermore the attacker cansubmit a forgery attack on the login message if it detects thesingle secret key Recently Chandrakar andOm [19] providedan authentication scheme based on ECC and hash Theirscheme has supported several servers in user authenticationwith three factors In this case the user can connect to anyserver to perform the authentication process In this schemethe authors did not specify which hash algorithm was usedand the size of the message digest (MD) which is necessaryfor repelling attacks such as collision and preimage Usingmultiple servers means that the same usersrsquo information isstored on more than one server and thus the penetration ofany server that causes usersrsquo information to be detected ormodified Additionally this scheme did not use a mechanismto prevent the association of real user information withauthentication requests such as pseudonyms

3 The Basic Techniques for OurAuthentication Scheme

An authentication mechanism specifies connecting users tonetwork services securelyTheHC system needs a set of tech-niques to implement the authentication mechanism beforeaccessing patientsrsquo records One authentication techniquewill not be sufficient to repel known attacks To ensure thatonly legitimate users are associated with the HC applicationnetwork our project includes a set of techniques to validatethe authentication request In our scheme we relied onalgorithms that provide lightweight operations and a high-security level for encryption and signature operations Thissection describes the threat model and the basic concepts ofthese techniques

31 Threat Model The threat model has been used to detectsecurity weakness in authentication schemes The threatmodel is applied to RAMHU based on the Dolev-Yao (dy)[29] model in order to build a valid authentication processin insecure environments such as a WLAN or the InternetThe dy model is an efficient and practical way to illustratesecurity protocols in the real world In addition it is a

4 Security and Communication Networks

e first layercryptographic

protocol

e second layerelliptic curvepoint mul-tiplication

e third layerpoint operations

e lower finitefield arithmetic

ECC (ECIESECDSA

and ECDH)

Point multipli-cation (PM)

Point addition Point doubling

Multiplication Addition Squaring Inversion

Figure 1 Arithmetic operations in ECC hierarchy

Table 1 Keys sizes and some information for asymmetric algorithms

Algo Keys sizes Ratio Author(s) Year Mathematical problemRSA 1024 2048 3072 7680 15360

16-30Rivest Shamir and Adleman 1978 Integer factorization

Elgamal Taher Elgamal 1985 Multiplicative groupECIES 160-223 224-255 256-383 384-511 512-more Neal Koblitz and Victor Miller 1985 Elliptic curve discrete log (ECDLP)

formal exemplar for modelling the risk of attackers againstauthentication protocols This model is useful in detectinginternal external single and multiple attacks [30] In ourthreat model we assume that an intruder is capable ofcarrying out an internal external passive or active attacksuch asMITM replay eavesdropping and spoofing Also weassume that the attributes server (119860119878) is trustworthy It is safeagainst repository penetration attacks We assume threats inour model as follows

(i) The attacker can steal the client application and itsfiles to analyse the data retrieve the parameters andreveal the secret key and then use these applicationson different devices

(ii) The attacker can listen for authentication requests inthe insecure environment and execute interceptionreplay and MITM attacks in order to become alegitimate user in the network

(iii) The attacker can execute a forgery or masqueradingattack in an attempt to penetrate the authenticationprocess

(iv) A legitimate user can perform a privileged insiderattack based on hisher legitimacy in the network

(v) The attacker can successfully guess the real usernamepassword role and pseudonym associated with itduring intensive analysis of many authenticationrequests

32 Overview of Techniques

(i) Elliptic Curve Integrated Encryption Scheme (ECIES)Elliptic Curve Cryptography (ECC) has been used to providesecurity requirements It provides confidentiality integrity

and authentication in the communications network withlimited capacity in terms of power and processing Thisalgorithm was independently proposed by Neal Koblitz andVictorMiller in 1985 [31] It depends on the discrete logarithmproblem (DLP) which is impervious to known attacks whenselecting parameters accurately [32] ie difficulty obtainingk from P and Q (where k is an integer and P and Q aretwo points on the curve) Small parameters used in ECChelp to perform computations quickly These computationsare important in constrained-source and large environmentsthat require processing power memory or power con-sumption [20 33] ECC provides encryption (Elliptic CurveIntegrated Encryption Scheme (ECIES)) signature (EllipticCurve Digital Signature Algorithm (ECDSA)) and exchangekeys (Elliptic Curve Diffie-Hellman (ECDH)) approaches[31] Many operations are performed in ECC algorithms(described in four layers) as shown in Figure 1 [34] ECIEShas provided confidentiality and proven to be extremelyefficient in its performance as it uses small keys thus thecost of computation is small compared with other public keycryptography algorithms such as Rivest-Shamir-Adleman(RSA) [35] Table 1 [33 36 37] shows a comparison of keysizes for public key encryption algorithms

(ii) Lightweight Hash-Function Algorithm The hash functionhas been used to generate signatures for authenticationrequests PHOTON is a lightweight hash function andextremely suitable for projects that require a robust andreliable signature This algorithm is based on a spongelikeconstruction and AES-like primitive for domain extensionand permutation efficiency [38ndash40] PHOTON is available inseveral versions (80 128 160 224 and 256) It is a balancebetween the efficiency in the execution of computations onthe one hand and security in the implementation of the

Security and Communication Networks 5

Table 2 Comparison of lightweight hash function algorithms

Algorithm Performance MD Security Author (s) YearGate equivalent area Throughput (kbps) PR SPR CR

SQUASH 2646 GE 015 64 64 64 0 Shamir 2005MAME 8100 GE 1467 256 - - - Yoshida et al 2007C-PRESENT-192 8048 GE 5926 192 192 192 96 Bogdanov et al 2008ARMADILLO2 8653 GE 938 256 256 256 128 Bald et al 2010S-QUARK 2296 GE 313 256 224 112 112 Aumasson et al 2010KECCAK-f[400] 5090 GE 144 128 128 128 64 Kavun and Yalcin 2010GLUON 4724 GE 32 224 224 112 112 Berger et al 2011SPONGENT-256 3281 GE 1143 256 240 128 128 Bogdanov et al 2011PHOTON-256 2177 GE 088 256 224 128 128 Guo et al 2011

features of the signature principle that depend on preimageresistant (PR) second preimage resistant (SPR) collisionresistant (CR) and mixing-transformation [17] on the otherhand It uses sponge construction and applies two phasesof absorbing and squeezing to produce a message digest(MD) more details are available in [41] Table 2 providesa comparison among the lightweight hash algorithms (thelatest version of these algorithms) in terms of security andefficiency [39 41ndash46] Although standard hash algorithmsare still used in applications such as SHA-1 (5527 GE MD160-bit) and SHA-2 (10868 GE MD 256-bit) lightweighthash algorithms such as PHOTON (2177 GE MD 256-bit)provides the most effective solution for handling complexsignatures in large HC systems

Table 2 shows that the PHOTON-256 (2177 GE) providesthe best performance compared to all lightweight hashfunctions and offers a high level of security through theapplication of signature features PR (224) SPR (128) and CR(128) Linear and differential attacks are the most powerfulattacks in the MD analysis of hash functions Compared toPHOTON ARMADILLO and SPONGENT-256 also offersignature features but both are vulnerable to attacks whereARMIDLLO2 has been attacked by local linearization (prac-tical semi-free-start collision attack) [47] and SPONGENThas been attacked by linear distinguishers (23 rounds [48] and13 rounds [49]) for all SPONGENTversions and additionallythey need the most computations (3281 GE and 8653 GE)compared with PHOTON-256 (2177 GE) PHOTON is areliable algorithm against linear and differential attacks [41]It has a high level of security and efficiency therefore it issuitable for our project as a signature mechanism

(iii) One-Time Password (OTP) The OTP is a way to authen-ticate legitimate users by generating a passcode or nonceonly once in a specified time It will not be applicablethe next times for authentication The OTP is an effectivemethod for authenticating users in HC applications if usedwith robust encryption and signature technologies Usinga static password or nonce without other authenticationmechanisms is weak in respect to attacks Therefore an OTPprovides significant support to the authentication processThismechanismpreventsmany attacks such as replayMITM

and guessing [50] The attacker cannot use this passcode ornonce to connect to the network later The client sends anOTP as part of an authentication request If the authenticationprocess is valid the server will delete the OTP from thedataset and will not accept it in the future The OTPis a powerful mechanism to mitigate the risk of hackersrsquocommunication in the network In this project we apply anOTP to generate a random password with the first link tousers in HC applications to ensure that only legitimate usersare connected to the network

(iv) Mutual Authentication Mutual authentication is a pre-requisite for preventing fraudulent authentication requestsThe traditional methods of authentication (such as passwordand name) are not suitable for HC applications [18] Ingeneral there are two kinds of authentication simple andmutual In simple authentication one party performs theauthentication process for example the server verifies theauthentication request for the client This type of authenti-cation is vulnerable to attacks such as spoofing and imper-sonation The attacker can use his device as a fake server toreceive all clientsrsquo requests Mutual authentication providesa security solution to prevent known attacks [18] In thistype of authentication each party authenticates the otherparty and thus prevents counterfeit attacks by both the clientand server In RAMHU we adopt the mechanism of mutualauthentication in the preservation of usersrsquo information anddata

(v) Media Access Control (MAC) Address AMAC address hasbeenused to distinguish legitimate usersrsquo devices in a networkduring the completion of the authentication process Allnetwork devices of different types should contain a hardwarecard (interface) to connect to the local or global networkEach wire or wireless interface has a media access control(MAC) or physical address that consists of 48 bits It is dividedinto six octets and written in hexadecimals such as ldquo8C70 5A 41 49 BCrdquo This address is a unique identifier (noduplicate address twice) for a device defined as global andpersistent [51] This address is used in WLAN because itoffers advantages such as reducing costs and speed in accesscontrol procedures [52] It can be changed programmatically

6 Security and Communication Networks

Table 3 Paperrsquos notations

Symbol Description119862119894 Client entity or user119862119878 Central server119860119878 Attributes server119863119878 Data server119880119868119863119894 119872119868119863119894 119862119894rsquos identity and medical centre identity119875119882119894 119905119898119901119875119882119894 119862119894rsquos password temporary password119862119894119870119901119906119894 119862119894119870119901119903119894 119862119894 public and private key119862119878119870119901119906119894 119862119878119870119901119903119894 119862119878 public and private key119860119878119870119901119906119894 119860119878119870119901119903119894 119860119878 public and private key119879119878119862119894 119879119878119862119878 119879119878119860119878 Timestamp generated by 119862119894 119862119878 119860119878

119873119862119894 119873119862119878 119873119860119878 Nonce random generated by 119862119894 119862119878 119860119878

119868 Internal or external intruder119868119868 119864119868 Internal intruder and external intruderℎ() One-way hash function119877119894 Role of patient patient relative or provider119877119877119894 Revocation reason119874119879119875119894 One-time password to authenticate first time119862119894119878119894119892119895 Signature generated by 119862119894 and j is signature number119862119878119878119894119892119895 Signature generated by 119862119878119860119878119878119894119892119895 Signature generated by 119860119878119880119875119862119878119862119894 119875119872

119862119878119862119894

User and medical centre pseudonyms sent by 119862119894 and verified by 119862119878119880119875119860119878119862119878 119875119872

119860119878119862119878 User and medical centre pseudonyms sent by 119862119878 and verified by 119860119878

119880119875119862119878119860119878 119875119872119862119878119860119878 User and medical centre pseudonyms sent by 119860119878 and verified by 119862119878

119880119875119862119894119862119878 119875119872

119862119894119862119878 User and medical centre pseudonyms sent by 119862119878 and verified by 119862119894

oplus Concatenation and exclusive or operations119866119872 119862119872 Get MAC and checkMAC address119864119899119888119894 119863119890119888119894 Encryption and decryption operations

in various operating systems such as Linux and WindowsIn addition anyone can use the Address Resolution Protocol(ARP) to detect the MAC address of another user in thenetwork [53] The main problem with this address is thatthe attacker can execute an eavesdropping attack to accessthe MAC addresses of legitimate devices in the network andthen select a legitimate MAC address to use it For instancean attacker could execute an ARP poisoning or spoofingattack by using a fake identifier of the MAC address (for alegitimate entity) to gain illegal privileges that would enableit to perform other attacks such as MITM and DoS [54]In addition randomization operations for the MAC addresshave become useless in the protection against tracking attacks[55 56] Therefore if the server does not have a mechanismto detect MAC address change the attacker becomes alegitimate user in the network and has access to networkresources

4 The Proposed Authentication Scheme

In this section we will detail RAMHU that provides securityand efficiency features in HC applications This sectionwill be divided into the network model security goalsand proposed authentication protocols Notations listed in

Table 3 are used to describe symbols used throughout thispaper

41 Network Model The RAMHU model consists of fourentities as shown in Figure 2

(1) Client (119862119894) This entity includes patients relativesof patients and HC providers such as doctorsresearchers emergency practitioners advisors andnurses

(2) Central server (119862119878) This entity is a gateway toauthenticate users with the attributes server and toauthorise the data server

(3) Attributes server (119860119878) This entity contains usersrsquo realinformation as well as multiple pseudonyms Theauthentication process requires verifying the asso-ciation of the actual information with the multiplepseudonyms in this entity

(4) Data server (119863119878) This entity contains usersrsquo dataas well as multiple pseudonyms This entity is notimplemented in our scheme and is left to future workOur scheme focuses only on the process of usersrsquoauthentication in the HC network

Security and Communication Networks 7

Network model

Acknowledgement

Client

Attributes server (AS)

Central server (CS)

Data server (DS)

Authentication request

Informationrepository

Datarepository

Check userrsquos information

Response

Authentication request

Response

Acknowledgement Data request(with pseudonyms)

Figure 2 General network model

Generally 119862119894 creates an authentication request mainlybased on ECIES and PHOTON 119862119894 sends a request to 119862119878 toverify encryption signature and security parameters (suchas MAC address pseudonyms and 119874119879119875119894) Then the 119862119878sends a request to the 119860119878 to verify the link between thepseudonyms the real information the signatures and 119875119882119894After that the 119860119878 sends the response to the 119862119878 that verifiesthe signature and the parameters and then the 119862119878 sendsthe response (authenticated or not) to the 119862119894 If the useris authenticated we assume that the user can then send anauthorisation request to access the data in the repository (119863119878)and obtain the authorisation response from the 119862119878 119860119878 and119863119878

42 Security Goals To build a robust authentication schemeRAMHU adopts the following security requirements

(i) Confidentiality This requirement is performed tohide authentication information and to preserve usersecrecy from detection by intruders To implementthis requirement a high-security cryptographic algo-rithm [20] should be used RAMHU executes ECIESto hide authentication information about intruders

(ii) Integrity This is to protect the authentication requestinformation from modification by intruders Theauthentication request should reach the intendeddestination without modification to provide a reliablecommunication channel for legitimate users [10 57]RAMHU performs a PHOTON to prevent any pro-cess ofmodifying the user authentication informationin HC applications

(iii) Nonrepudiation This requirement prevents both theclients and server from denying their authenticationrequests This is a way to prove that the message issent by a particular sender in the HC applications

network If a legitimate user in the network performsinternal attacks heshe cannot deny hisher activitieswhile exploiting the privileges granted to himherOur scheme uses PHOTON signatures and a MACaddress tomeet this requirement and detectmaliciousattacks

(iv) Anonymity This requirement is extremely impor-tant in supporting the confidentiality of the authen-tication request The purpose of this requirementis to disguise the source and destination of theauthentication request If the authentication schemeapplies anonymity with encryption the attackerfinds it exceedingly difficult to analyse authentica-tion requests for a particular user at different timesbecause the authentication request is different eachtime the user is connected to the network [7]RAMHU applies this requirement through the use ofrandom nonces between entities

(v) Pseudonym This requirement denotes the provisionof a mechanism to connect nonreal attributes (suchas terms and symbols) with the real attributes of theuser (such as name address and phone number)The use of this mechanism in HC applications isan extremely important way to protect the personalinformation of users and prevent the detection oftheir identities RAMHU uses a multiple-pseudonymmechanism to prevent and separate the associationwith real information

(vi) Forward secrecy This requirement is accomplishedwhen network users use new keys and parameterstemporarily without relying on old onesThis require-ment prevents attackers from exploiting usersrsquo keysand passwords in decrypting authentication requestsUsing the temporary random password private key

8 Security and Communication Networks

and MAC RAMHU prevents users from accessingprevious authentication information

(vii) Mutual authentication This requirement is used inHCapplications tomitigate the risks of external fraudWith this feature each party ensures that it deals witha legitimate party The server authenticates the clientby checking encryptions and signatures and viceversa in order to establish a secure communicationchannel In RAMHU 119862119878 and 119862119894 authenticate eachother to prevent masquerading and impersonatingattacks

(viii) ScalabilityHCapplications operate in a scalable envi-ronment in terms of data and users Therefore theseapplications require authentication schemes capableof handling and adapting to the ever-increasing num-ber of users of HC applications This requirementrefers to the ability of the authentication scheme toappropriately handle large HC systems Public keyencryption schemes are efficient in supporting thisrequirement [24]

(ix) FreshnessThis requirement indicates that the authen-tication request is new and updated to ensure thatthe attacker cannot replay the authentication requestat a later time This requirement is achieved throughthe provision of time checking a random nonce andchange of signatures in each authentication process tocounteract counterfeit attacks such as MITM replayand impersonation [20] which ensures that theauthentication request is unaltered or not tamperedwith

43 Proposed Authentication Scheme The RAMHU schemeconsists of 5 protocols initial setup registrationloginauthentication password update and revocation Duringthese protocols RAMHU provides reliable authenticationprocesses to protect usersrsquo information

431 Initial Setup Protocol In this protocol all entitiesare ready to start communicating with each other whileconfiguring all security parameters and ECIESrsquos keys as in thefollowing steps

(i) Each legitimate user receives a client application fromthe authorised system provider

(ii) Each legitimate user receives a 119875119882119894 (that can bechanged later) and a random 119874119879119875119894 to be used in thefirst registration

(iii) All entities (119862119894 119862119878 and 119860119878) should create publicand private keys (119862119894 (119862119870119901119906119894 119862119870119901119903119894) 119862119878 (119862119878119870119901119906119894 119862119878119870119901119903119894) and 119860119878 (119860119878119870119901119906119894 119860119878119870119901119903119894)) to be used tovalidate the authentication request All entities choosean elliptic curve 119864119901(119886 119887) over a prime field 119865119875 (where119875 = 256) and base point 119866 on curve Each entityselects a private key 119870119901119903119894 randomly and generates thepublic key 119870119901119906119894 during the implementation of scalarmultiplication (119870119901119906119894 = 119870119901119903119894 lowast 119866)

(iv) All entities broadcast the public key (119862119870119901119906119894 119862119878119870119901119906119894 and 119860119878119870119901119906119894) to use in ECIESrsquos encryption operations

432 Registration and Login Protocol Patients and HCproviders (119862119894) should complete the registration and loginprotocol with 119862119878 to become legitimate users of HC appli-cations Without this protocol the user cannot completethe authentication process in RAMHU User registration isperformed once namely the user does not need to completethe registration protocol the next times (only the loginprotocol) the registration information has been kept in theservers until the revocation protocol and deletion of the usersecurity parameters such as pseudonyms MAC address and119875119882119894 this protocol accomplishes the following steps (Figure 3shows the registration and login protocol and Figure 4 showsthe login protocol)

119862119894 Side

(i) The user enters 119880119868119863119894 (such as hisher name) 119872119868119863119894(such as medical centre name) and 119875119882119894 and 119874119879119875119894for registration and login while only entering 119880119868119863119894119872119868119863119894 and119875119882119894 for the login protocol the next times tothe client (119862119894) application119862119894 replaces119880119868119863119894with userrsquospseudonym (119880119875119862119878119862119894 ) and 119872119868119863119894 with medical centrepseudonym (119872119875119862119878119862119894 ) to protect the authenticationinformationwhenmoving from119862119894 to119862119878119862119894 generatesa timestamp (119879119878119862119894) to be used to verify the sendingtime of the registrationlogin request in 119862119878

(ii) 119862119894 gets a MAC address (GM) by entering its IP(Internet protocol) address The process of checkingMAC (119862119872) is performed by 119862119894 to test the cred-ibility of the MAC address In the Linux systemwe used the command ldquoethtool -P interface namerdquo(such as ldquoethtool -P wlo1rdquo) in the 119862119894 applicationIf the result is identical to 119866119872 it means that theMAC address is native (119862119872 = ldquo119877119890119886119897 119872119860119862rdquo) Inthe Windows system 119862119894 searches for string valueldquoNetworkAddressrdquo in the path of the system reg-istry (ldquo119867119870119864119884 119871119874119862119860119871 119872119860119862119867119868119873119864 119878119884119878119879119864119872 119862119906119903119903119890119899119905119862119900119899119905119903119900119897119878119890119905 119862119900119899119905119903119900119897 119862119897119886119904119904 411986336119864972 minus119864325 minus 11119862119864 minus 1198611198651198621 minus 0800211986111986410318rdquo) If Net-workAddress = null 119862119872 = ldquo119877119890119886119897 119872119860119862rdquo otherwise119862119872 = ldquo119865119886119896119890 119872119860119862rdquo The 119866119872 send is encrypted witha registrationlogin request while 119862119872 is implicitlysent with the signature value (1198621198941198781198941198921) In only thelogin protocol 119862119894 needs to extract a private keyfrom the temporary keyMAC address password andrandom nonce through 119905119898119901119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus119873119862119894 119862119894 generates a random nonce (119873119862119894) to changesignature and encryption data and add anonymity tothe registrationlogin request

(iii) 119862119894 performs two signatures using the PHOTON-256algorithm to protect information from modificationThe first signature includes the parameters checkMAC nonce and timestamp (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) The second signature includes allthe authentication parameters of the gotten MAC

Security and Communication Networks 9

CS AS

Figure 3 Registration and login protocol

nonce timestamp first signature pseudonyms one-time password and password (1198621198941198781198941198922 = ℎ(119866119872

119873119862119894 119879119878119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875

119875119882119894)) In the login protocol 119874119879119875 is not added to thesignature

(iv) 119862119894 computes a temporary value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus 1198621198941198781198941198921) of 119875119882119894 when moving from 119862119894 to119862119878

(v) 119862119894 uses ECIES to encrypt and hide all the data ofthis request (119864119899119888119894(119879119878119862119894 119873119862119894 119866119872 1198621198941198781198941198921

119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875119894 119905119898119901119875119882119894 1198621198941198781198941198922)) Inthe login protocol 119874119879119875119894 and 119866119872 are not added tothe encryption as in Figure 4 After that 119862119894 sendsthe registration and login request or login to 119862119878 tocomplete the authentication protocol Then 119862119894 hidesthe private key by 119905119898119901119862119894119870119901119903119894 = 119862119894119870119901119903119894 oplus119875119882119894 oplus1198621198941198781198941198922

119862119878 Side

(i) Upon receiving a registration and login request orlogin request 119862119878 decrypts this request using ECIESrsquos119862119894119870119901119906119894 and 119862119878119870119901119903119894 It checks the timestamp (119879119878119862119878-119879119878119862119894 le 998779119879) to make sure that this request arrived atan appropriate time and without delay

(ii) In the registration and login protocol 119862119878 examinesthe random 119874119879119875119894 in the dataset If 119874119879119875119894 exists thenthe user is legitimate for the registration process After

that 119862119878 deletes 119874119879119875119894 from the dataset to prevent itfrom being used the next times If 119874119879119875119894 is not foundit discards the connection In the login protocol119862119878 examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 and then tests theirassociation with the MAC address in the dataset If119866119872 is found 119862119878 completes the steps of this protocolotherwise it cancels the connection

(iii) 119862119878 needs to ensure that the userrsquos device is legitimatewithin the network 119862119878 computes the signature valueto make sure that the MAC address is native andnonmodified (1198621198781198781198941198921 = ℎ(ldquoReal MACrdquo 119873119862119894 119879119878119862119894)) It examines the result of the computed sig-nature (1198621198781198781198941198921) with 119862119894rsquos signature (1198621198941198781198941198921) If thesignatures results are identical then the device islegitimate and the MAC address did not change Inthe registration and login protocol 119862119878 stores thisaddress in the dataset for use and checks the nexttimes in the login protocol

(iv) 119862119878 performs the computation operation 119905119898119901119875119882119894 oplus119873119862119894 oplus119866119872oplus1198621198781198781198941198921 to extract the 119875119882119894 value and thenuses this value to produce a second signature (1198621198781198781198941198922)

(v) 119862119878 computes a second signature operation (1198621198781198781198941198922=ℎ(119866119872 119873119862119894 119879119878119862119894 1198621198781198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894

119874119879119875119894 119875119882119894)) to guarantee that all the encryptedinformation is not changed Then it compares thecomputed signature (1198621198781198781198941198922) with the received sig-nature in the request (1198621198941198781198941198922) If the signatures are

10 Security and Communication Networks

CS AS

Figure 4 Login protocol

identical then the information for this request isunchanged or not tampered with In the login proto-col 119874119879119875119894 and 119866119872 are not added to the signature Atthis point 119862119878 prepares to send the userrsquos authentica-tion request to 119860119878

433 Authentication Protocol The authentication protocolverifies the reliability of the usersrsquo security parameters withtheir personal information in the server In this protocolRAMHU needs to link pseudonyms and passwords with realinformation for users in 119860119878rsquos datasets Note that the usersrsquoinformation (such as name age address mobile number andpasswords) is stored in a separate server (AS) and multiplepseudonyms are used to prevent detection and trackingof usersrsquo information This protocol is illustrated in thefollowing steps (Figure 5 shows the authentication protocolin RAMHU)

119862119878 Side

(i) 119862119878 computes a new timestamp (119879119878119862119878) to ensure thefresh authentication request

(ii) 119862119878 replaces 119862119894rsquos pseudonyms (119880119875119862119878119862119894 and119872119875119862119878119862119894 ) with119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119872119875119860119878119862119878 ) to prevent attack-ers from tracking the authentication request It gen-erates random nonce (119873119862119878) to ensure an anonymousauthentication request

(iii) 119862119878 signs security parameters by PHOTON-256(1198621198781198781198941198923 = ℎ(119879119878119862119878 119873119862119878 119880119875

119860119878119862119878 119872119875119860119878119862119878 )) to prevent

modification of authentication request information(iv) 119862119878 computes temporary 119875119882119894 by the computation of

119875119882119894 oplus 119873119862119878 oplus 1198621198781198781198941198923

(v) 119862119878 encrypts information of authentication request(119864119899119888119894(119879119878119862119878 119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 1198621198781198781198941198923 119905119898119901119875119882119894)) It sends an authentication request to verifyuserrsquos information in 119860119878

119860119878 Side

(i) Upon receiving the authentication request 119860119878 de-crypts that request using ECIESrsquos 119860119878119870119901119903119894 and 119862119878119870119901119906119894to obtain the authentication information clearly

(ii) It checks the timestamp by 119879119878119860119878 minus 119879119878119862119878 le 998779119879 toensure that the authentication request is not delayed119860119878 checks the pseudonyms (119880119875119860119878119862119878 and 119872119875119860119878119862119878 ) sentfromCS and correlates them with the userrsquos real iden-tifier (119880119868119863119894 and119872119868119863119894) in the datasets 119860119878 extracts theuserrsquos password from the equation 119875119882119894 = 119905119898119901119875119882i oplus119873119862119878oplus1198621198781198781198941198923 After that it checksmatching119875119882119894 in thedataset 119860119878 computes the value of the signature basedon authentication information (1198601198781198781198941198921 = ℎ(119879119878119862119878

119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 )) by PHOTON-256 119860119878 com-

pares the computed value of the signature (1198601198781198781198941198921)with the value of the received signature (1198621198781198781198941198923) If

Security and Communication Networks 11

CS AS

Figure 5 Authentication protocol

the signature values are identical the userrsquos informa-tion in the request for the signature is unmodified Atthis point 119860119878 considers this user to be legitimate andreliable

(iii) 119860119878 prepares a response to authenticate the request ofthat user It computes a new timestamp (119879119878119860119878 = new119879119878119860119878) to prevent delayed or replayed requests at latertimes119860119878 replaces119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119880119875

119860119878119862119878 )

received with 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) tohide usersrsquo information It generates a new randomnonce (119873119860119878) to add anonymity and prevent attacksfrom encryption and signature analysis

(iv) 119860119878 computes a signature (1198601198781198781198941198922 = ℎ(119879119878119860119878 119873119860119878

119880119875119862119878119860119878 119872119875119862119878119860119878 )) to prevent modifications of authenti-cation response information

(v) 119860119878 encrypts the authentication information(119864119899119888119894(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 1198601198781198781198941198922))and sends the authentication response to 119862119878 tocomplete the authentication process

119862119878 Side(i) 119862119878 decrypts the authentication response (119864119899119888119894)

received from 119860119878 It checks the timestamp value(119879119878119862119878 minus 119879119878119860119878 le 998779119879) to prevent late authentication

12 Security and Communication Networks

responses It examines 119880119875119860119878119862119878 and119872119875119860119878119862119878 in datasets tocomplete the process of linking multiple pseudonymsto the user

(ii) 119862119878 computes the signature 1198621198781198781198941198924 = ℎ(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 ) for authentication response infor-mation It compares the computed result of thesignature (1198621198781198781198941198924) with the value of the receivedsignature (1198601198781198781198941198922) If the signature values matchthen the authentication response information is un-changed

(iii) After this point 119862119878 initiates a login response requestIt computes the value of new timestamp (119879119878119862119878 =

119899119890119908119879119878119862119878) It replaces 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) received with 119880119875

119862119894119862119878 and 119872119875

119862119894119862119878 It generates

a new random nonce (119873119862119878) to hide encryption andsignature information

(iv) 119862119878 computes a new signature value (1198621198781198781198941198925 =

ℎ(119879119878119862119878 119873119862119878 119880119875119862119894119862119878

119872119875119862119894119862119878)) to protect login

response information frommodification(v) 119862119878 encrypts login response information (119864119899119888119894(119879119878119862119878

119873119862S 119880119875119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sends thisresponse to 119862119894

119862119894 Side

(i) 119862119894 extracts his private key (119862119894119870119901119903119894) from 119905119898119901119862119894119870119901119903119894 oplus119875119882119894 oplus 1198621198941198781198941198922 and decrypts the login request (119864119899119888119894)received from 119862119878

(ii) 119862119894 checks the timestamp (119879119878119862119894 minus119879119878119862119878 le 998779119879) to ensurethat the login response is not late or replayed

(iii) 119862119894 checks that 119862119878rsquos pseudonyms (119880119875119862119894119862119878 and 119872119875119862119894119862119878)

are received in the dataset and associated with 119880119875119862119878119862119894and 119872119875C119878

119862119894 At this point RAMHU applied multiple

pseudonyms among model entities (119862119894 119862119878 and 119860119878)to prevent traceability in linking the real informationof the user with pseudonyms

(iv) 119862119894 calculates the value of the signature 1198621198941198781198941198923 =

ℎ(119879119878119862119878 119873C119878 119880119875119862119894119862119878 119872119875

119862119894119862119878) for login re-

sponse information It compares the result of thecomputed signature (1198621198941198781198941198923) and the value of thereceived signature (1198621198781198781198941198925 ) If the signature values areidentical namely the login response information isunmodified or not tamperedwith119862119894 accepts the loginresponse otherwise 119862119894 discards the login responseThen119862119894 hides its private key by 119862119894119870119901119903119894 oplus119866119872oplus119875119882119894 oplus119873119862119894 after generating a random nonce to prevent thedetection of the private key if the device is hackedAt this point if all processes are achieved correctlythen all requests are considered legitimate and reli-able through the implementation of mutual authenti-cation

434 Password Update Protocol Updating the password isa security procedure to ensure authentication of legitimate

users The process of changing 119875119882119894 is important in any HCsystem for two reasons First it prevents the use of 119875119882119894fixed for a long time which reduces the guessing attacksSecond changing119875119882119894 gives usersmore flexibility in choosingthe appropriate 119875119882119894 This process requires strict securitymeasures to protect the new 119875119882119894 RAMHU provides thelegitimate user with amechanism to change hisher passwordat any time If the user wants to change hisher 119875119882119894the following illustration describes the new 119875119882119894 protectionprocedures in a secure manner (Figure 6 shows the passwordupdate protocol in RAMHU)

(i) 119862119894 side 119862119894 enters 119880119868119863119894 119872119868119863119894 the old 119875119882119894 andthe new 119875119882119894 It replaces 119880119868119863119894 and 119872119868119863119894 withpseudonyms to hide the userrsquos real information 119862119894calls the MAC address and then extracts the privatekey from 119905119898119901119862119894119870119901119903119894oplus119866119872oplus119900119897119889119875119882119894oplus119873119862119894 to use in theencryption process of the password update request119862119894generates three random nonces (1198731198621 1198731198622 and 1198731198623)and computes a new timestamp (119879119878119862119894) 119862119894 computesthe signature value (1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)) by PHOTON-256 basedon the parameters of the password change requestIt applies an anonymity mechanism to the old 119875119882119894and new 119875119882119894 (119905119898119901 119900119897119889119875119882119894 = 119900119897119889119875119882119894 oplus1198731198622 oplus 1198621198941198781198941198921and 119905119898119901 119899119890119908119875119882119894 = 119899119890119908119875119882119894 oplus 1198731198623 oplus 1198621198941198781198941198921) to hidepasswords and not explicitly send them in the 119875119882119894change request It encrypts the 119875119882119894 change request(119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) and sends itto 119862119878 119862119894 then hides its private key by 119862119894119870119901119903119894 oplus 119866119872oplus119899119890119908119875119882119894 oplus 119873119862119894

(ii) 119862119878 side 119862119878 receives and decrypts a password updaterequest (119864119899119888119894) It examines the timestamp to preventdelayed requests and examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 indatasets 119862119878 extracts the old 119875119882119894 and new 119875119882119894 from119905119898119901 119900119897119889119875119882119894 oplus 1198731198622 oplus 1198621198941198781198941198921 and 119905119898119901 119899119890119908119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 Then it computes the signature value(1198621198781198781198941198921) depending on 119879119878119862119894 1198731198621 119880119875

119862119878119862119894 119872119875119862119878119862119894 and

119900119897119889119875119882119894 to check the matching between 1198621198781198781198941198921 and1198621198941198781198941198921 Similarly in the authentication protocol 119862119878computes 119879119878119862119878 and replaces pseudonyms 119862119878 gener-ates three nonces 1198731198621198781 1198731198621198782 and 1198731198621198783 and then 119862119878computes the signature value (ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119900119897119889119875119882119894)) and hides the old119875119882119894 and new119875119882119894by 119900119897119889119875119882119894 oplus 1198731198621198782 oplus 1198621198781198781198941198922 and 119899119890119908119875119882119894 oplus 1198731198621198783 oplus1198621198781198781198941198922 It encrypts the password update request withsecurity parameters (119879119878119862119878 1198731198621198781 1198731198621198782 1198731198621198783 119880119875

119860119878119862119878

119872119875119860119878119862119878 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 and 1198621198781198781198941198922) andsends to 119860119878

(iii) 119860119878 side 119860119878 receives the password update requestand decrypts (119864119899119888119894) this request with 119860119878119870119901119903119894 and119862119878119870119901119906119894 It checks time delay and then it checkslink pseudonyms with real information for users Itextracts the old119875119882119894 from 119905119898119901 119900119897119889119875119882119894oplus1198731198621198782oplus1198621198781198781198941198922and then it checks the old 119875119882119894 in the dataset It com-putes the signature value 1198601198781198781198941198921 = ℎ(119879119878119862119878 1198731198621198781

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 4: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

4 Security and Communication Networks

e first layercryptographic

protocol

e second layerelliptic curvepoint mul-tiplication

e third layerpoint operations

e lower finitefield arithmetic

ECC (ECIESECDSA

and ECDH)

Point multipli-cation (PM)

Point addition Point doubling

Multiplication Addition Squaring Inversion

Figure 1 Arithmetic operations in ECC hierarchy

Table 1 Keys sizes and some information for asymmetric algorithms

Algo Keys sizes Ratio Author(s) Year Mathematical problemRSA 1024 2048 3072 7680 15360

16-30Rivest Shamir and Adleman 1978 Integer factorization

Elgamal Taher Elgamal 1985 Multiplicative groupECIES 160-223 224-255 256-383 384-511 512-more Neal Koblitz and Victor Miller 1985 Elliptic curve discrete log (ECDLP)

formal exemplar for modelling the risk of attackers againstauthentication protocols This model is useful in detectinginternal external single and multiple attacks [30] In ourthreat model we assume that an intruder is capable ofcarrying out an internal external passive or active attacksuch asMITM replay eavesdropping and spoofing Also weassume that the attributes server (119860119878) is trustworthy It is safeagainst repository penetration attacks We assume threats inour model as follows

(i) The attacker can steal the client application and itsfiles to analyse the data retrieve the parameters andreveal the secret key and then use these applicationson different devices

(ii) The attacker can listen for authentication requests inthe insecure environment and execute interceptionreplay and MITM attacks in order to become alegitimate user in the network

(iii) The attacker can execute a forgery or masqueradingattack in an attempt to penetrate the authenticationprocess

(iv) A legitimate user can perform a privileged insiderattack based on hisher legitimacy in the network

(v) The attacker can successfully guess the real usernamepassword role and pseudonym associated with itduring intensive analysis of many authenticationrequests

32 Overview of Techniques

(i) Elliptic Curve Integrated Encryption Scheme (ECIES)Elliptic Curve Cryptography (ECC) has been used to providesecurity requirements It provides confidentiality integrity

and authentication in the communications network withlimited capacity in terms of power and processing Thisalgorithm was independently proposed by Neal Koblitz andVictorMiller in 1985 [31] It depends on the discrete logarithmproblem (DLP) which is impervious to known attacks whenselecting parameters accurately [32] ie difficulty obtainingk from P and Q (where k is an integer and P and Q aretwo points on the curve) Small parameters used in ECChelp to perform computations quickly These computationsare important in constrained-source and large environmentsthat require processing power memory or power con-sumption [20 33] ECC provides encryption (Elliptic CurveIntegrated Encryption Scheme (ECIES)) signature (EllipticCurve Digital Signature Algorithm (ECDSA)) and exchangekeys (Elliptic Curve Diffie-Hellman (ECDH)) approaches[31] Many operations are performed in ECC algorithms(described in four layers) as shown in Figure 1 [34] ECIEShas provided confidentiality and proven to be extremelyefficient in its performance as it uses small keys thus thecost of computation is small compared with other public keycryptography algorithms such as Rivest-Shamir-Adleman(RSA) [35] Table 1 [33 36 37] shows a comparison of keysizes for public key encryption algorithms

(ii) Lightweight Hash-Function Algorithm The hash functionhas been used to generate signatures for authenticationrequests PHOTON is a lightweight hash function andextremely suitable for projects that require a robust andreliable signature This algorithm is based on a spongelikeconstruction and AES-like primitive for domain extensionand permutation efficiency [38ndash40] PHOTON is available inseveral versions (80 128 160 224 and 256) It is a balancebetween the efficiency in the execution of computations onthe one hand and security in the implementation of the

Security and Communication Networks 5

Table 2 Comparison of lightweight hash function algorithms

Algorithm Performance MD Security Author (s) YearGate equivalent area Throughput (kbps) PR SPR CR

SQUASH 2646 GE 015 64 64 64 0 Shamir 2005MAME 8100 GE 1467 256 - - - Yoshida et al 2007C-PRESENT-192 8048 GE 5926 192 192 192 96 Bogdanov et al 2008ARMADILLO2 8653 GE 938 256 256 256 128 Bald et al 2010S-QUARK 2296 GE 313 256 224 112 112 Aumasson et al 2010KECCAK-f[400] 5090 GE 144 128 128 128 64 Kavun and Yalcin 2010GLUON 4724 GE 32 224 224 112 112 Berger et al 2011SPONGENT-256 3281 GE 1143 256 240 128 128 Bogdanov et al 2011PHOTON-256 2177 GE 088 256 224 128 128 Guo et al 2011

features of the signature principle that depend on preimageresistant (PR) second preimage resistant (SPR) collisionresistant (CR) and mixing-transformation [17] on the otherhand It uses sponge construction and applies two phasesof absorbing and squeezing to produce a message digest(MD) more details are available in [41] Table 2 providesa comparison among the lightweight hash algorithms (thelatest version of these algorithms) in terms of security andefficiency [39 41ndash46] Although standard hash algorithmsare still used in applications such as SHA-1 (5527 GE MD160-bit) and SHA-2 (10868 GE MD 256-bit) lightweighthash algorithms such as PHOTON (2177 GE MD 256-bit)provides the most effective solution for handling complexsignatures in large HC systems

Table 2 shows that the PHOTON-256 (2177 GE) providesthe best performance compared to all lightweight hashfunctions and offers a high level of security through theapplication of signature features PR (224) SPR (128) and CR(128) Linear and differential attacks are the most powerfulattacks in the MD analysis of hash functions Compared toPHOTON ARMADILLO and SPONGENT-256 also offersignature features but both are vulnerable to attacks whereARMIDLLO2 has been attacked by local linearization (prac-tical semi-free-start collision attack) [47] and SPONGENThas been attacked by linear distinguishers (23 rounds [48] and13 rounds [49]) for all SPONGENTversions and additionallythey need the most computations (3281 GE and 8653 GE)compared with PHOTON-256 (2177 GE) PHOTON is areliable algorithm against linear and differential attacks [41]It has a high level of security and efficiency therefore it issuitable for our project as a signature mechanism

(iii) One-Time Password (OTP) The OTP is a way to authen-ticate legitimate users by generating a passcode or nonceonly once in a specified time It will not be applicablethe next times for authentication The OTP is an effectivemethod for authenticating users in HC applications if usedwith robust encryption and signature technologies Usinga static password or nonce without other authenticationmechanisms is weak in respect to attacks Therefore an OTPprovides significant support to the authentication processThismechanismpreventsmany attacks such as replayMITM

and guessing [50] The attacker cannot use this passcode ornonce to connect to the network later The client sends anOTP as part of an authentication request If the authenticationprocess is valid the server will delete the OTP from thedataset and will not accept it in the future The OTPis a powerful mechanism to mitigate the risk of hackersrsquocommunication in the network In this project we apply anOTP to generate a random password with the first link tousers in HC applications to ensure that only legitimate usersare connected to the network

(iv) Mutual Authentication Mutual authentication is a pre-requisite for preventing fraudulent authentication requestsThe traditional methods of authentication (such as passwordand name) are not suitable for HC applications [18] Ingeneral there are two kinds of authentication simple andmutual In simple authentication one party performs theauthentication process for example the server verifies theauthentication request for the client This type of authenti-cation is vulnerable to attacks such as spoofing and imper-sonation The attacker can use his device as a fake server toreceive all clientsrsquo requests Mutual authentication providesa security solution to prevent known attacks [18] In thistype of authentication each party authenticates the otherparty and thus prevents counterfeit attacks by both the clientand server In RAMHU we adopt the mechanism of mutualauthentication in the preservation of usersrsquo information anddata

(v) Media Access Control (MAC) Address AMAC address hasbeenused to distinguish legitimate usersrsquo devices in a networkduring the completion of the authentication process Allnetwork devices of different types should contain a hardwarecard (interface) to connect to the local or global networkEach wire or wireless interface has a media access control(MAC) or physical address that consists of 48 bits It is dividedinto six octets and written in hexadecimals such as ldquo8C70 5A 41 49 BCrdquo This address is a unique identifier (noduplicate address twice) for a device defined as global andpersistent [51] This address is used in WLAN because itoffers advantages such as reducing costs and speed in accesscontrol procedures [52] It can be changed programmatically

6 Security and Communication Networks

Table 3 Paperrsquos notations

Symbol Description119862119894 Client entity or user119862119878 Central server119860119878 Attributes server119863119878 Data server119880119868119863119894 119872119868119863119894 119862119894rsquos identity and medical centre identity119875119882119894 119905119898119901119875119882119894 119862119894rsquos password temporary password119862119894119870119901119906119894 119862119894119870119901119903119894 119862119894 public and private key119862119878119870119901119906119894 119862119878119870119901119903119894 119862119878 public and private key119860119878119870119901119906119894 119860119878119870119901119903119894 119860119878 public and private key119879119878119862119894 119879119878119862119878 119879119878119860119878 Timestamp generated by 119862119894 119862119878 119860119878

119873119862119894 119873119862119878 119873119860119878 Nonce random generated by 119862119894 119862119878 119860119878

119868 Internal or external intruder119868119868 119864119868 Internal intruder and external intruderℎ() One-way hash function119877119894 Role of patient patient relative or provider119877119877119894 Revocation reason119874119879119875119894 One-time password to authenticate first time119862119894119878119894119892119895 Signature generated by 119862119894 and j is signature number119862119878119878119894119892119895 Signature generated by 119862119878119860119878119878119894119892119895 Signature generated by 119860119878119880119875119862119878119862119894 119875119872

119862119878119862119894

User and medical centre pseudonyms sent by 119862119894 and verified by 119862119878119880119875119860119878119862119878 119875119872

119860119878119862119878 User and medical centre pseudonyms sent by 119862119878 and verified by 119860119878

119880119875119862119878119860119878 119875119872119862119878119860119878 User and medical centre pseudonyms sent by 119860119878 and verified by 119862119878

119880119875119862119894119862119878 119875119872

119862119894119862119878 User and medical centre pseudonyms sent by 119862119878 and verified by 119862119894

oplus Concatenation and exclusive or operations119866119872 119862119872 Get MAC and checkMAC address119864119899119888119894 119863119890119888119894 Encryption and decryption operations

in various operating systems such as Linux and WindowsIn addition anyone can use the Address Resolution Protocol(ARP) to detect the MAC address of another user in thenetwork [53] The main problem with this address is thatthe attacker can execute an eavesdropping attack to accessthe MAC addresses of legitimate devices in the network andthen select a legitimate MAC address to use it For instancean attacker could execute an ARP poisoning or spoofingattack by using a fake identifier of the MAC address (for alegitimate entity) to gain illegal privileges that would enableit to perform other attacks such as MITM and DoS [54]In addition randomization operations for the MAC addresshave become useless in the protection against tracking attacks[55 56] Therefore if the server does not have a mechanismto detect MAC address change the attacker becomes alegitimate user in the network and has access to networkresources

4 The Proposed Authentication Scheme

In this section we will detail RAMHU that provides securityand efficiency features in HC applications This sectionwill be divided into the network model security goalsand proposed authentication protocols Notations listed in

Table 3 are used to describe symbols used throughout thispaper

41 Network Model The RAMHU model consists of fourentities as shown in Figure 2

(1) Client (119862119894) This entity includes patients relativesof patients and HC providers such as doctorsresearchers emergency practitioners advisors andnurses

(2) Central server (119862119878) This entity is a gateway toauthenticate users with the attributes server and toauthorise the data server

(3) Attributes server (119860119878) This entity contains usersrsquo realinformation as well as multiple pseudonyms Theauthentication process requires verifying the asso-ciation of the actual information with the multiplepseudonyms in this entity

(4) Data server (119863119878) This entity contains usersrsquo dataas well as multiple pseudonyms This entity is notimplemented in our scheme and is left to future workOur scheme focuses only on the process of usersrsquoauthentication in the HC network

Security and Communication Networks 7

Network model

Acknowledgement

Client

Attributes server (AS)

Central server (CS)

Data server (DS)

Authentication request

Informationrepository

Datarepository

Check userrsquos information

Response

Authentication request

Response

Acknowledgement Data request(with pseudonyms)

Figure 2 General network model

Generally 119862119894 creates an authentication request mainlybased on ECIES and PHOTON 119862119894 sends a request to 119862119878 toverify encryption signature and security parameters (suchas MAC address pseudonyms and 119874119879119875119894) Then the 119862119878sends a request to the 119860119878 to verify the link between thepseudonyms the real information the signatures and 119875119882119894After that the 119860119878 sends the response to the 119862119878 that verifiesthe signature and the parameters and then the 119862119878 sendsthe response (authenticated or not) to the 119862119894 If the useris authenticated we assume that the user can then send anauthorisation request to access the data in the repository (119863119878)and obtain the authorisation response from the 119862119878 119860119878 and119863119878

42 Security Goals To build a robust authentication schemeRAMHU adopts the following security requirements

(i) Confidentiality This requirement is performed tohide authentication information and to preserve usersecrecy from detection by intruders To implementthis requirement a high-security cryptographic algo-rithm [20] should be used RAMHU executes ECIESto hide authentication information about intruders

(ii) Integrity This is to protect the authentication requestinformation from modification by intruders Theauthentication request should reach the intendeddestination without modification to provide a reliablecommunication channel for legitimate users [10 57]RAMHU performs a PHOTON to prevent any pro-cess ofmodifying the user authentication informationin HC applications

(iii) Nonrepudiation This requirement prevents both theclients and server from denying their authenticationrequests This is a way to prove that the message issent by a particular sender in the HC applications

network If a legitimate user in the network performsinternal attacks heshe cannot deny hisher activitieswhile exploiting the privileges granted to himherOur scheme uses PHOTON signatures and a MACaddress tomeet this requirement and detectmaliciousattacks

(iv) Anonymity This requirement is extremely impor-tant in supporting the confidentiality of the authen-tication request The purpose of this requirementis to disguise the source and destination of theauthentication request If the authentication schemeapplies anonymity with encryption the attackerfinds it exceedingly difficult to analyse authentica-tion requests for a particular user at different timesbecause the authentication request is different eachtime the user is connected to the network [7]RAMHU applies this requirement through the use ofrandom nonces between entities

(v) Pseudonym This requirement denotes the provisionof a mechanism to connect nonreal attributes (suchas terms and symbols) with the real attributes of theuser (such as name address and phone number)The use of this mechanism in HC applications isan extremely important way to protect the personalinformation of users and prevent the detection oftheir identities RAMHU uses a multiple-pseudonymmechanism to prevent and separate the associationwith real information

(vi) Forward secrecy This requirement is accomplishedwhen network users use new keys and parameterstemporarily without relying on old onesThis require-ment prevents attackers from exploiting usersrsquo keysand passwords in decrypting authentication requestsUsing the temporary random password private key

8 Security and Communication Networks

and MAC RAMHU prevents users from accessingprevious authentication information

(vii) Mutual authentication This requirement is used inHCapplications tomitigate the risks of external fraudWith this feature each party ensures that it deals witha legitimate party The server authenticates the clientby checking encryptions and signatures and viceversa in order to establish a secure communicationchannel In RAMHU 119862119878 and 119862119894 authenticate eachother to prevent masquerading and impersonatingattacks

(viii) ScalabilityHCapplications operate in a scalable envi-ronment in terms of data and users Therefore theseapplications require authentication schemes capableof handling and adapting to the ever-increasing num-ber of users of HC applications This requirementrefers to the ability of the authentication scheme toappropriately handle large HC systems Public keyencryption schemes are efficient in supporting thisrequirement [24]

(ix) FreshnessThis requirement indicates that the authen-tication request is new and updated to ensure thatthe attacker cannot replay the authentication requestat a later time This requirement is achieved throughthe provision of time checking a random nonce andchange of signatures in each authentication process tocounteract counterfeit attacks such as MITM replayand impersonation [20] which ensures that theauthentication request is unaltered or not tamperedwith

43 Proposed Authentication Scheme The RAMHU schemeconsists of 5 protocols initial setup registrationloginauthentication password update and revocation Duringthese protocols RAMHU provides reliable authenticationprocesses to protect usersrsquo information

431 Initial Setup Protocol In this protocol all entitiesare ready to start communicating with each other whileconfiguring all security parameters and ECIESrsquos keys as in thefollowing steps

(i) Each legitimate user receives a client application fromthe authorised system provider

(ii) Each legitimate user receives a 119875119882119894 (that can bechanged later) and a random 119874119879119875119894 to be used in thefirst registration

(iii) All entities (119862119894 119862119878 and 119860119878) should create publicand private keys (119862119894 (119862119870119901119906119894 119862119870119901119903119894) 119862119878 (119862119878119870119901119906119894 119862119878119870119901119903119894) and 119860119878 (119860119878119870119901119906119894 119860119878119870119901119903119894)) to be used tovalidate the authentication request All entities choosean elliptic curve 119864119901(119886 119887) over a prime field 119865119875 (where119875 = 256) and base point 119866 on curve Each entityselects a private key 119870119901119903119894 randomly and generates thepublic key 119870119901119906119894 during the implementation of scalarmultiplication (119870119901119906119894 = 119870119901119903119894 lowast 119866)

(iv) All entities broadcast the public key (119862119870119901119906119894 119862119878119870119901119906119894 and 119860119878119870119901119906119894) to use in ECIESrsquos encryption operations

432 Registration and Login Protocol Patients and HCproviders (119862119894) should complete the registration and loginprotocol with 119862119878 to become legitimate users of HC appli-cations Without this protocol the user cannot completethe authentication process in RAMHU User registration isperformed once namely the user does not need to completethe registration protocol the next times (only the loginprotocol) the registration information has been kept in theservers until the revocation protocol and deletion of the usersecurity parameters such as pseudonyms MAC address and119875119882119894 this protocol accomplishes the following steps (Figure 3shows the registration and login protocol and Figure 4 showsthe login protocol)

119862119894 Side

(i) The user enters 119880119868119863119894 (such as hisher name) 119872119868119863119894(such as medical centre name) and 119875119882119894 and 119874119879119875119894for registration and login while only entering 119880119868119863119894119872119868119863119894 and119875119882119894 for the login protocol the next times tothe client (119862119894) application119862119894 replaces119880119868119863119894with userrsquospseudonym (119880119875119862119878119862119894 ) and 119872119868119863119894 with medical centrepseudonym (119872119875119862119878119862119894 ) to protect the authenticationinformationwhenmoving from119862119894 to119862119878119862119894 generatesa timestamp (119879119878119862119894) to be used to verify the sendingtime of the registrationlogin request in 119862119878

(ii) 119862119894 gets a MAC address (GM) by entering its IP(Internet protocol) address The process of checkingMAC (119862119872) is performed by 119862119894 to test the cred-ibility of the MAC address In the Linux systemwe used the command ldquoethtool -P interface namerdquo(such as ldquoethtool -P wlo1rdquo) in the 119862119894 applicationIf the result is identical to 119866119872 it means that theMAC address is native (119862119872 = ldquo119877119890119886119897 119872119860119862rdquo) Inthe Windows system 119862119894 searches for string valueldquoNetworkAddressrdquo in the path of the system reg-istry (ldquo119867119870119864119884 119871119874119862119860119871 119872119860119862119867119868119873119864 119878119884119878119879119864119872 119862119906119903119903119890119899119905119862119900119899119905119903119900119897119878119890119905 119862119900119899119905119903119900119897 119862119897119886119904119904 411986336119864972 minus119864325 minus 11119862119864 minus 1198611198651198621 minus 0800211986111986410318rdquo) If Net-workAddress = null 119862119872 = ldquo119877119890119886119897 119872119860119862rdquo otherwise119862119872 = ldquo119865119886119896119890 119872119860119862rdquo The 119866119872 send is encrypted witha registrationlogin request while 119862119872 is implicitlysent with the signature value (1198621198941198781198941198921) In only thelogin protocol 119862119894 needs to extract a private keyfrom the temporary keyMAC address password andrandom nonce through 119905119898119901119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus119873119862119894 119862119894 generates a random nonce (119873119862119894) to changesignature and encryption data and add anonymity tothe registrationlogin request

(iii) 119862119894 performs two signatures using the PHOTON-256algorithm to protect information from modificationThe first signature includes the parameters checkMAC nonce and timestamp (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) The second signature includes allthe authentication parameters of the gotten MAC

Security and Communication Networks 9

CS AS

Figure 3 Registration and login protocol

nonce timestamp first signature pseudonyms one-time password and password (1198621198941198781198941198922 = ℎ(119866119872

119873119862119894 119879119878119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875

119875119882119894)) In the login protocol 119874119879119875 is not added to thesignature

(iv) 119862119894 computes a temporary value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus 1198621198941198781198941198921) of 119875119882119894 when moving from 119862119894 to119862119878

(v) 119862119894 uses ECIES to encrypt and hide all the data ofthis request (119864119899119888119894(119879119878119862119894 119873119862119894 119866119872 1198621198941198781198941198921

119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875119894 119905119898119901119875119882119894 1198621198941198781198941198922)) Inthe login protocol 119874119879119875119894 and 119866119872 are not added tothe encryption as in Figure 4 After that 119862119894 sendsthe registration and login request or login to 119862119878 tocomplete the authentication protocol Then 119862119894 hidesthe private key by 119905119898119901119862119894119870119901119903119894 = 119862119894119870119901119903119894 oplus119875119882119894 oplus1198621198941198781198941198922

119862119878 Side

(i) Upon receiving a registration and login request orlogin request 119862119878 decrypts this request using ECIESrsquos119862119894119870119901119906119894 and 119862119878119870119901119903119894 It checks the timestamp (119879119878119862119878-119879119878119862119894 le 998779119879) to make sure that this request arrived atan appropriate time and without delay

(ii) In the registration and login protocol 119862119878 examinesthe random 119874119879119875119894 in the dataset If 119874119879119875119894 exists thenthe user is legitimate for the registration process After

that 119862119878 deletes 119874119879119875119894 from the dataset to prevent itfrom being used the next times If 119874119879119875119894 is not foundit discards the connection In the login protocol119862119878 examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 and then tests theirassociation with the MAC address in the dataset If119866119872 is found 119862119878 completes the steps of this protocolotherwise it cancels the connection

(iii) 119862119878 needs to ensure that the userrsquos device is legitimatewithin the network 119862119878 computes the signature valueto make sure that the MAC address is native andnonmodified (1198621198781198781198941198921 = ℎ(ldquoReal MACrdquo 119873119862119894 119879119878119862119894)) It examines the result of the computed sig-nature (1198621198781198781198941198921) with 119862119894rsquos signature (1198621198941198781198941198921) If thesignatures results are identical then the device islegitimate and the MAC address did not change Inthe registration and login protocol 119862119878 stores thisaddress in the dataset for use and checks the nexttimes in the login protocol

(iv) 119862119878 performs the computation operation 119905119898119901119875119882119894 oplus119873119862119894 oplus119866119872oplus1198621198781198781198941198921 to extract the 119875119882119894 value and thenuses this value to produce a second signature (1198621198781198781198941198922)

(v) 119862119878 computes a second signature operation (1198621198781198781198941198922=ℎ(119866119872 119873119862119894 119879119878119862119894 1198621198781198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894

119874119879119875119894 119875119882119894)) to guarantee that all the encryptedinformation is not changed Then it compares thecomputed signature (1198621198781198781198941198922) with the received sig-nature in the request (1198621198941198781198941198922) If the signatures are

10 Security and Communication Networks

CS AS

Figure 4 Login protocol

identical then the information for this request isunchanged or not tampered with In the login proto-col 119874119879119875119894 and 119866119872 are not added to the signature Atthis point 119862119878 prepares to send the userrsquos authentica-tion request to 119860119878

433 Authentication Protocol The authentication protocolverifies the reliability of the usersrsquo security parameters withtheir personal information in the server In this protocolRAMHU needs to link pseudonyms and passwords with realinformation for users in 119860119878rsquos datasets Note that the usersrsquoinformation (such as name age address mobile number andpasswords) is stored in a separate server (AS) and multiplepseudonyms are used to prevent detection and trackingof usersrsquo information This protocol is illustrated in thefollowing steps (Figure 5 shows the authentication protocolin RAMHU)

119862119878 Side

(i) 119862119878 computes a new timestamp (119879119878119862119878) to ensure thefresh authentication request

(ii) 119862119878 replaces 119862119894rsquos pseudonyms (119880119875119862119878119862119894 and119872119875119862119878119862119894 ) with119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119872119875119860119878119862119878 ) to prevent attack-ers from tracking the authentication request It gen-erates random nonce (119873119862119878) to ensure an anonymousauthentication request

(iii) 119862119878 signs security parameters by PHOTON-256(1198621198781198781198941198923 = ℎ(119879119878119862119878 119873119862119878 119880119875

119860119878119862119878 119872119875119860119878119862119878 )) to prevent

modification of authentication request information(iv) 119862119878 computes temporary 119875119882119894 by the computation of

119875119882119894 oplus 119873119862119878 oplus 1198621198781198781198941198923

(v) 119862119878 encrypts information of authentication request(119864119899119888119894(119879119878119862119878 119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 1198621198781198781198941198923 119905119898119901119875119882119894)) It sends an authentication request to verifyuserrsquos information in 119860119878

119860119878 Side

(i) Upon receiving the authentication request 119860119878 de-crypts that request using ECIESrsquos 119860119878119870119901119903119894 and 119862119878119870119901119906119894to obtain the authentication information clearly

(ii) It checks the timestamp by 119879119878119860119878 minus 119879119878119862119878 le 998779119879 toensure that the authentication request is not delayed119860119878 checks the pseudonyms (119880119875119860119878119862119878 and 119872119875119860119878119862119878 ) sentfromCS and correlates them with the userrsquos real iden-tifier (119880119868119863119894 and119872119868119863119894) in the datasets 119860119878 extracts theuserrsquos password from the equation 119875119882119894 = 119905119898119901119875119882i oplus119873119862119878oplus1198621198781198781198941198923 After that it checksmatching119875119882119894 in thedataset 119860119878 computes the value of the signature basedon authentication information (1198601198781198781198941198921 = ℎ(119879119878119862119878

119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 )) by PHOTON-256 119860119878 com-

pares the computed value of the signature (1198601198781198781198941198921)with the value of the received signature (1198621198781198781198941198923) If

Security and Communication Networks 11

CS AS

Figure 5 Authentication protocol

the signature values are identical the userrsquos informa-tion in the request for the signature is unmodified Atthis point 119860119878 considers this user to be legitimate andreliable

(iii) 119860119878 prepares a response to authenticate the request ofthat user It computes a new timestamp (119879119878119860119878 = new119879119878119860119878) to prevent delayed or replayed requests at latertimes119860119878 replaces119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119880119875

119860119878119862119878 )

received with 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) tohide usersrsquo information It generates a new randomnonce (119873119860119878) to add anonymity and prevent attacksfrom encryption and signature analysis

(iv) 119860119878 computes a signature (1198601198781198781198941198922 = ℎ(119879119878119860119878 119873119860119878

119880119875119862119878119860119878 119872119875119862119878119860119878 )) to prevent modifications of authenti-cation response information

(v) 119860119878 encrypts the authentication information(119864119899119888119894(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 1198601198781198781198941198922))and sends the authentication response to 119862119878 tocomplete the authentication process

119862119878 Side(i) 119862119878 decrypts the authentication response (119864119899119888119894)

received from 119860119878 It checks the timestamp value(119879119878119862119878 minus 119879119878119860119878 le 998779119879) to prevent late authentication

12 Security and Communication Networks

responses It examines 119880119875119860119878119862119878 and119872119875119860119878119862119878 in datasets tocomplete the process of linking multiple pseudonymsto the user

(ii) 119862119878 computes the signature 1198621198781198781198941198924 = ℎ(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 ) for authentication response infor-mation It compares the computed result of thesignature (1198621198781198781198941198924) with the value of the receivedsignature (1198601198781198781198941198922) If the signature values matchthen the authentication response information is un-changed

(iii) After this point 119862119878 initiates a login response requestIt computes the value of new timestamp (119879119878119862119878 =

119899119890119908119879119878119862119878) It replaces 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) received with 119880119875

119862119894119862119878 and 119872119875

119862119894119862119878 It generates

a new random nonce (119873119862119878) to hide encryption andsignature information

(iv) 119862119878 computes a new signature value (1198621198781198781198941198925 =

ℎ(119879119878119862119878 119873119862119878 119880119875119862119894119862119878

119872119875119862119894119862119878)) to protect login

response information frommodification(v) 119862119878 encrypts login response information (119864119899119888119894(119879119878119862119878

119873119862S 119880119875119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sends thisresponse to 119862119894

119862119894 Side

(i) 119862119894 extracts his private key (119862119894119870119901119903119894) from 119905119898119901119862119894119870119901119903119894 oplus119875119882119894 oplus 1198621198941198781198941198922 and decrypts the login request (119864119899119888119894)received from 119862119878

(ii) 119862119894 checks the timestamp (119879119878119862119894 minus119879119878119862119878 le 998779119879) to ensurethat the login response is not late or replayed

(iii) 119862119894 checks that 119862119878rsquos pseudonyms (119880119875119862119894119862119878 and 119872119875119862119894119862119878)

are received in the dataset and associated with 119880119875119862119878119862119894and 119872119875C119878

119862119894 At this point RAMHU applied multiple

pseudonyms among model entities (119862119894 119862119878 and 119860119878)to prevent traceability in linking the real informationof the user with pseudonyms

(iv) 119862119894 calculates the value of the signature 1198621198941198781198941198923 =

ℎ(119879119878119862119878 119873C119878 119880119875119862119894119862119878 119872119875

119862119894119862119878) for login re-

sponse information It compares the result of thecomputed signature (1198621198941198781198941198923) and the value of thereceived signature (1198621198781198781198941198925 ) If the signature values areidentical namely the login response information isunmodified or not tamperedwith119862119894 accepts the loginresponse otherwise 119862119894 discards the login responseThen119862119894 hides its private key by 119862119894119870119901119903119894 oplus119866119872oplus119875119882119894 oplus119873119862119894 after generating a random nonce to prevent thedetection of the private key if the device is hackedAt this point if all processes are achieved correctlythen all requests are considered legitimate and reli-able through the implementation of mutual authenti-cation

434 Password Update Protocol Updating the password isa security procedure to ensure authentication of legitimate

users The process of changing 119875119882119894 is important in any HCsystem for two reasons First it prevents the use of 119875119882119894fixed for a long time which reduces the guessing attacksSecond changing119875119882119894 gives usersmore flexibility in choosingthe appropriate 119875119882119894 This process requires strict securitymeasures to protect the new 119875119882119894 RAMHU provides thelegitimate user with amechanism to change hisher passwordat any time If the user wants to change hisher 119875119882119894the following illustration describes the new 119875119882119894 protectionprocedures in a secure manner (Figure 6 shows the passwordupdate protocol in RAMHU)

(i) 119862119894 side 119862119894 enters 119880119868119863119894 119872119868119863119894 the old 119875119882119894 andthe new 119875119882119894 It replaces 119880119868119863119894 and 119872119868119863119894 withpseudonyms to hide the userrsquos real information 119862119894calls the MAC address and then extracts the privatekey from 119905119898119901119862119894119870119901119903119894oplus119866119872oplus119900119897119889119875119882119894oplus119873119862119894 to use in theencryption process of the password update request119862119894generates three random nonces (1198731198621 1198731198622 and 1198731198623)and computes a new timestamp (119879119878119862119894) 119862119894 computesthe signature value (1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)) by PHOTON-256 basedon the parameters of the password change requestIt applies an anonymity mechanism to the old 119875119882119894and new 119875119882119894 (119905119898119901 119900119897119889119875119882119894 = 119900119897119889119875119882119894 oplus1198731198622 oplus 1198621198941198781198941198921and 119905119898119901 119899119890119908119875119882119894 = 119899119890119908119875119882119894 oplus 1198731198623 oplus 1198621198941198781198941198921) to hidepasswords and not explicitly send them in the 119875119882119894change request It encrypts the 119875119882119894 change request(119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) and sends itto 119862119878 119862119894 then hides its private key by 119862119894119870119901119903119894 oplus 119866119872oplus119899119890119908119875119882119894 oplus 119873119862119894

(ii) 119862119878 side 119862119878 receives and decrypts a password updaterequest (119864119899119888119894) It examines the timestamp to preventdelayed requests and examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 indatasets 119862119878 extracts the old 119875119882119894 and new 119875119882119894 from119905119898119901 119900119897119889119875119882119894 oplus 1198731198622 oplus 1198621198941198781198941198921 and 119905119898119901 119899119890119908119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 Then it computes the signature value(1198621198781198781198941198921) depending on 119879119878119862119894 1198731198621 119880119875

119862119878119862119894 119872119875119862119878119862119894 and

119900119897119889119875119882119894 to check the matching between 1198621198781198781198941198921 and1198621198941198781198941198921 Similarly in the authentication protocol 119862119878computes 119879119878119862119878 and replaces pseudonyms 119862119878 gener-ates three nonces 1198731198621198781 1198731198621198782 and 1198731198621198783 and then 119862119878computes the signature value (ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119900119897119889119875119882119894)) and hides the old119875119882119894 and new119875119882119894by 119900119897119889119875119882119894 oplus 1198731198621198782 oplus 1198621198781198781198941198922 and 119899119890119908119875119882119894 oplus 1198731198621198783 oplus1198621198781198781198941198922 It encrypts the password update request withsecurity parameters (119879119878119862119878 1198731198621198781 1198731198621198782 1198731198621198783 119880119875

119860119878119862119878

119872119875119860119878119862119878 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 and 1198621198781198781198941198922) andsends to 119860119878

(iii) 119860119878 side 119860119878 receives the password update requestand decrypts (119864119899119888119894) this request with 119860119878119870119901119903119894 and119862119878119870119901119906119894 It checks time delay and then it checkslink pseudonyms with real information for users Itextracts the old119875119882119894 from 119905119898119901 119900119897119889119875119882119894oplus1198731198621198782oplus1198621198781198781198941198922and then it checks the old 119875119882119894 in the dataset It com-putes the signature value 1198601198781198781198941198921 = ℎ(119879119878119862119878 1198731198621198781

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 5: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Security and Communication Networks 5

Table 2 Comparison of lightweight hash function algorithms

Algorithm Performance MD Security Author (s) YearGate equivalent area Throughput (kbps) PR SPR CR

SQUASH 2646 GE 015 64 64 64 0 Shamir 2005MAME 8100 GE 1467 256 - - - Yoshida et al 2007C-PRESENT-192 8048 GE 5926 192 192 192 96 Bogdanov et al 2008ARMADILLO2 8653 GE 938 256 256 256 128 Bald et al 2010S-QUARK 2296 GE 313 256 224 112 112 Aumasson et al 2010KECCAK-f[400] 5090 GE 144 128 128 128 64 Kavun and Yalcin 2010GLUON 4724 GE 32 224 224 112 112 Berger et al 2011SPONGENT-256 3281 GE 1143 256 240 128 128 Bogdanov et al 2011PHOTON-256 2177 GE 088 256 224 128 128 Guo et al 2011

features of the signature principle that depend on preimageresistant (PR) second preimage resistant (SPR) collisionresistant (CR) and mixing-transformation [17] on the otherhand It uses sponge construction and applies two phasesof absorbing and squeezing to produce a message digest(MD) more details are available in [41] Table 2 providesa comparison among the lightweight hash algorithms (thelatest version of these algorithms) in terms of security andefficiency [39 41ndash46] Although standard hash algorithmsare still used in applications such as SHA-1 (5527 GE MD160-bit) and SHA-2 (10868 GE MD 256-bit) lightweighthash algorithms such as PHOTON (2177 GE MD 256-bit)provides the most effective solution for handling complexsignatures in large HC systems

Table 2 shows that the PHOTON-256 (2177 GE) providesthe best performance compared to all lightweight hashfunctions and offers a high level of security through theapplication of signature features PR (224) SPR (128) and CR(128) Linear and differential attacks are the most powerfulattacks in the MD analysis of hash functions Compared toPHOTON ARMADILLO and SPONGENT-256 also offersignature features but both are vulnerable to attacks whereARMIDLLO2 has been attacked by local linearization (prac-tical semi-free-start collision attack) [47] and SPONGENThas been attacked by linear distinguishers (23 rounds [48] and13 rounds [49]) for all SPONGENTversions and additionallythey need the most computations (3281 GE and 8653 GE)compared with PHOTON-256 (2177 GE) PHOTON is areliable algorithm against linear and differential attacks [41]It has a high level of security and efficiency therefore it issuitable for our project as a signature mechanism

(iii) One-Time Password (OTP) The OTP is a way to authen-ticate legitimate users by generating a passcode or nonceonly once in a specified time It will not be applicablethe next times for authentication The OTP is an effectivemethod for authenticating users in HC applications if usedwith robust encryption and signature technologies Usinga static password or nonce without other authenticationmechanisms is weak in respect to attacks Therefore an OTPprovides significant support to the authentication processThismechanismpreventsmany attacks such as replayMITM

and guessing [50] The attacker cannot use this passcode ornonce to connect to the network later The client sends anOTP as part of an authentication request If the authenticationprocess is valid the server will delete the OTP from thedataset and will not accept it in the future The OTPis a powerful mechanism to mitigate the risk of hackersrsquocommunication in the network In this project we apply anOTP to generate a random password with the first link tousers in HC applications to ensure that only legitimate usersare connected to the network

(iv) Mutual Authentication Mutual authentication is a pre-requisite for preventing fraudulent authentication requestsThe traditional methods of authentication (such as passwordand name) are not suitable for HC applications [18] Ingeneral there are two kinds of authentication simple andmutual In simple authentication one party performs theauthentication process for example the server verifies theauthentication request for the client This type of authenti-cation is vulnerable to attacks such as spoofing and imper-sonation The attacker can use his device as a fake server toreceive all clientsrsquo requests Mutual authentication providesa security solution to prevent known attacks [18] In thistype of authentication each party authenticates the otherparty and thus prevents counterfeit attacks by both the clientand server In RAMHU we adopt the mechanism of mutualauthentication in the preservation of usersrsquo information anddata

(v) Media Access Control (MAC) Address AMAC address hasbeenused to distinguish legitimate usersrsquo devices in a networkduring the completion of the authentication process Allnetwork devices of different types should contain a hardwarecard (interface) to connect to the local or global networkEach wire or wireless interface has a media access control(MAC) or physical address that consists of 48 bits It is dividedinto six octets and written in hexadecimals such as ldquo8C70 5A 41 49 BCrdquo This address is a unique identifier (noduplicate address twice) for a device defined as global andpersistent [51] This address is used in WLAN because itoffers advantages such as reducing costs and speed in accesscontrol procedures [52] It can be changed programmatically

6 Security and Communication Networks

Table 3 Paperrsquos notations

Symbol Description119862119894 Client entity or user119862119878 Central server119860119878 Attributes server119863119878 Data server119880119868119863119894 119872119868119863119894 119862119894rsquos identity and medical centre identity119875119882119894 119905119898119901119875119882119894 119862119894rsquos password temporary password119862119894119870119901119906119894 119862119894119870119901119903119894 119862119894 public and private key119862119878119870119901119906119894 119862119878119870119901119903119894 119862119878 public and private key119860119878119870119901119906119894 119860119878119870119901119903119894 119860119878 public and private key119879119878119862119894 119879119878119862119878 119879119878119860119878 Timestamp generated by 119862119894 119862119878 119860119878

119873119862119894 119873119862119878 119873119860119878 Nonce random generated by 119862119894 119862119878 119860119878

119868 Internal or external intruder119868119868 119864119868 Internal intruder and external intruderℎ() One-way hash function119877119894 Role of patient patient relative or provider119877119877119894 Revocation reason119874119879119875119894 One-time password to authenticate first time119862119894119878119894119892119895 Signature generated by 119862119894 and j is signature number119862119878119878119894119892119895 Signature generated by 119862119878119860119878119878119894119892119895 Signature generated by 119860119878119880119875119862119878119862119894 119875119872

119862119878119862119894

User and medical centre pseudonyms sent by 119862119894 and verified by 119862119878119880119875119860119878119862119878 119875119872

119860119878119862119878 User and medical centre pseudonyms sent by 119862119878 and verified by 119860119878

119880119875119862119878119860119878 119875119872119862119878119860119878 User and medical centre pseudonyms sent by 119860119878 and verified by 119862119878

119880119875119862119894119862119878 119875119872

119862119894119862119878 User and medical centre pseudonyms sent by 119862119878 and verified by 119862119894

oplus Concatenation and exclusive or operations119866119872 119862119872 Get MAC and checkMAC address119864119899119888119894 119863119890119888119894 Encryption and decryption operations

in various operating systems such as Linux and WindowsIn addition anyone can use the Address Resolution Protocol(ARP) to detect the MAC address of another user in thenetwork [53] The main problem with this address is thatthe attacker can execute an eavesdropping attack to accessthe MAC addresses of legitimate devices in the network andthen select a legitimate MAC address to use it For instancean attacker could execute an ARP poisoning or spoofingattack by using a fake identifier of the MAC address (for alegitimate entity) to gain illegal privileges that would enableit to perform other attacks such as MITM and DoS [54]In addition randomization operations for the MAC addresshave become useless in the protection against tracking attacks[55 56] Therefore if the server does not have a mechanismto detect MAC address change the attacker becomes alegitimate user in the network and has access to networkresources

4 The Proposed Authentication Scheme

In this section we will detail RAMHU that provides securityand efficiency features in HC applications This sectionwill be divided into the network model security goalsand proposed authentication protocols Notations listed in

Table 3 are used to describe symbols used throughout thispaper

41 Network Model The RAMHU model consists of fourentities as shown in Figure 2

(1) Client (119862119894) This entity includes patients relativesof patients and HC providers such as doctorsresearchers emergency practitioners advisors andnurses

(2) Central server (119862119878) This entity is a gateway toauthenticate users with the attributes server and toauthorise the data server

(3) Attributes server (119860119878) This entity contains usersrsquo realinformation as well as multiple pseudonyms Theauthentication process requires verifying the asso-ciation of the actual information with the multiplepseudonyms in this entity

(4) Data server (119863119878) This entity contains usersrsquo dataas well as multiple pseudonyms This entity is notimplemented in our scheme and is left to future workOur scheme focuses only on the process of usersrsquoauthentication in the HC network

Security and Communication Networks 7

Network model

Acknowledgement

Client

Attributes server (AS)

Central server (CS)

Data server (DS)

Authentication request

Informationrepository

Datarepository

Check userrsquos information

Response

Authentication request

Response

Acknowledgement Data request(with pseudonyms)

Figure 2 General network model

Generally 119862119894 creates an authentication request mainlybased on ECIES and PHOTON 119862119894 sends a request to 119862119878 toverify encryption signature and security parameters (suchas MAC address pseudonyms and 119874119879119875119894) Then the 119862119878sends a request to the 119860119878 to verify the link between thepseudonyms the real information the signatures and 119875119882119894After that the 119860119878 sends the response to the 119862119878 that verifiesthe signature and the parameters and then the 119862119878 sendsthe response (authenticated or not) to the 119862119894 If the useris authenticated we assume that the user can then send anauthorisation request to access the data in the repository (119863119878)and obtain the authorisation response from the 119862119878 119860119878 and119863119878

42 Security Goals To build a robust authentication schemeRAMHU adopts the following security requirements

(i) Confidentiality This requirement is performed tohide authentication information and to preserve usersecrecy from detection by intruders To implementthis requirement a high-security cryptographic algo-rithm [20] should be used RAMHU executes ECIESto hide authentication information about intruders

(ii) Integrity This is to protect the authentication requestinformation from modification by intruders Theauthentication request should reach the intendeddestination without modification to provide a reliablecommunication channel for legitimate users [10 57]RAMHU performs a PHOTON to prevent any pro-cess ofmodifying the user authentication informationin HC applications

(iii) Nonrepudiation This requirement prevents both theclients and server from denying their authenticationrequests This is a way to prove that the message issent by a particular sender in the HC applications

network If a legitimate user in the network performsinternal attacks heshe cannot deny hisher activitieswhile exploiting the privileges granted to himherOur scheme uses PHOTON signatures and a MACaddress tomeet this requirement and detectmaliciousattacks

(iv) Anonymity This requirement is extremely impor-tant in supporting the confidentiality of the authen-tication request The purpose of this requirementis to disguise the source and destination of theauthentication request If the authentication schemeapplies anonymity with encryption the attackerfinds it exceedingly difficult to analyse authentica-tion requests for a particular user at different timesbecause the authentication request is different eachtime the user is connected to the network [7]RAMHU applies this requirement through the use ofrandom nonces between entities

(v) Pseudonym This requirement denotes the provisionof a mechanism to connect nonreal attributes (suchas terms and symbols) with the real attributes of theuser (such as name address and phone number)The use of this mechanism in HC applications isan extremely important way to protect the personalinformation of users and prevent the detection oftheir identities RAMHU uses a multiple-pseudonymmechanism to prevent and separate the associationwith real information

(vi) Forward secrecy This requirement is accomplishedwhen network users use new keys and parameterstemporarily without relying on old onesThis require-ment prevents attackers from exploiting usersrsquo keysand passwords in decrypting authentication requestsUsing the temporary random password private key

8 Security and Communication Networks

and MAC RAMHU prevents users from accessingprevious authentication information

(vii) Mutual authentication This requirement is used inHCapplications tomitigate the risks of external fraudWith this feature each party ensures that it deals witha legitimate party The server authenticates the clientby checking encryptions and signatures and viceversa in order to establish a secure communicationchannel In RAMHU 119862119878 and 119862119894 authenticate eachother to prevent masquerading and impersonatingattacks

(viii) ScalabilityHCapplications operate in a scalable envi-ronment in terms of data and users Therefore theseapplications require authentication schemes capableof handling and adapting to the ever-increasing num-ber of users of HC applications This requirementrefers to the ability of the authentication scheme toappropriately handle large HC systems Public keyencryption schemes are efficient in supporting thisrequirement [24]

(ix) FreshnessThis requirement indicates that the authen-tication request is new and updated to ensure thatthe attacker cannot replay the authentication requestat a later time This requirement is achieved throughthe provision of time checking a random nonce andchange of signatures in each authentication process tocounteract counterfeit attacks such as MITM replayand impersonation [20] which ensures that theauthentication request is unaltered or not tamperedwith

43 Proposed Authentication Scheme The RAMHU schemeconsists of 5 protocols initial setup registrationloginauthentication password update and revocation Duringthese protocols RAMHU provides reliable authenticationprocesses to protect usersrsquo information

431 Initial Setup Protocol In this protocol all entitiesare ready to start communicating with each other whileconfiguring all security parameters and ECIESrsquos keys as in thefollowing steps

(i) Each legitimate user receives a client application fromthe authorised system provider

(ii) Each legitimate user receives a 119875119882119894 (that can bechanged later) and a random 119874119879119875119894 to be used in thefirst registration

(iii) All entities (119862119894 119862119878 and 119860119878) should create publicand private keys (119862119894 (119862119870119901119906119894 119862119870119901119903119894) 119862119878 (119862119878119870119901119906119894 119862119878119870119901119903119894) and 119860119878 (119860119878119870119901119906119894 119860119878119870119901119903119894)) to be used tovalidate the authentication request All entities choosean elliptic curve 119864119901(119886 119887) over a prime field 119865119875 (where119875 = 256) and base point 119866 on curve Each entityselects a private key 119870119901119903119894 randomly and generates thepublic key 119870119901119906119894 during the implementation of scalarmultiplication (119870119901119906119894 = 119870119901119903119894 lowast 119866)

(iv) All entities broadcast the public key (119862119870119901119906119894 119862119878119870119901119906119894 and 119860119878119870119901119906119894) to use in ECIESrsquos encryption operations

432 Registration and Login Protocol Patients and HCproviders (119862119894) should complete the registration and loginprotocol with 119862119878 to become legitimate users of HC appli-cations Without this protocol the user cannot completethe authentication process in RAMHU User registration isperformed once namely the user does not need to completethe registration protocol the next times (only the loginprotocol) the registration information has been kept in theservers until the revocation protocol and deletion of the usersecurity parameters such as pseudonyms MAC address and119875119882119894 this protocol accomplishes the following steps (Figure 3shows the registration and login protocol and Figure 4 showsthe login protocol)

119862119894 Side

(i) The user enters 119880119868119863119894 (such as hisher name) 119872119868119863119894(such as medical centre name) and 119875119882119894 and 119874119879119875119894for registration and login while only entering 119880119868119863119894119872119868119863119894 and119875119882119894 for the login protocol the next times tothe client (119862119894) application119862119894 replaces119880119868119863119894with userrsquospseudonym (119880119875119862119878119862119894 ) and 119872119868119863119894 with medical centrepseudonym (119872119875119862119878119862119894 ) to protect the authenticationinformationwhenmoving from119862119894 to119862119878119862119894 generatesa timestamp (119879119878119862119894) to be used to verify the sendingtime of the registrationlogin request in 119862119878

(ii) 119862119894 gets a MAC address (GM) by entering its IP(Internet protocol) address The process of checkingMAC (119862119872) is performed by 119862119894 to test the cred-ibility of the MAC address In the Linux systemwe used the command ldquoethtool -P interface namerdquo(such as ldquoethtool -P wlo1rdquo) in the 119862119894 applicationIf the result is identical to 119866119872 it means that theMAC address is native (119862119872 = ldquo119877119890119886119897 119872119860119862rdquo) Inthe Windows system 119862119894 searches for string valueldquoNetworkAddressrdquo in the path of the system reg-istry (ldquo119867119870119864119884 119871119874119862119860119871 119872119860119862119867119868119873119864 119878119884119878119879119864119872 119862119906119903119903119890119899119905119862119900119899119905119903119900119897119878119890119905 119862119900119899119905119903119900119897 119862119897119886119904119904 411986336119864972 minus119864325 minus 11119862119864 minus 1198611198651198621 minus 0800211986111986410318rdquo) If Net-workAddress = null 119862119872 = ldquo119877119890119886119897 119872119860119862rdquo otherwise119862119872 = ldquo119865119886119896119890 119872119860119862rdquo The 119866119872 send is encrypted witha registrationlogin request while 119862119872 is implicitlysent with the signature value (1198621198941198781198941198921) In only thelogin protocol 119862119894 needs to extract a private keyfrom the temporary keyMAC address password andrandom nonce through 119905119898119901119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus119873119862119894 119862119894 generates a random nonce (119873119862119894) to changesignature and encryption data and add anonymity tothe registrationlogin request

(iii) 119862119894 performs two signatures using the PHOTON-256algorithm to protect information from modificationThe first signature includes the parameters checkMAC nonce and timestamp (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) The second signature includes allthe authentication parameters of the gotten MAC

Security and Communication Networks 9

CS AS

Figure 3 Registration and login protocol

nonce timestamp first signature pseudonyms one-time password and password (1198621198941198781198941198922 = ℎ(119866119872

119873119862119894 119879119878119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875

119875119882119894)) In the login protocol 119874119879119875 is not added to thesignature

(iv) 119862119894 computes a temporary value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus 1198621198941198781198941198921) of 119875119882119894 when moving from 119862119894 to119862119878

(v) 119862119894 uses ECIES to encrypt and hide all the data ofthis request (119864119899119888119894(119879119878119862119894 119873119862119894 119866119872 1198621198941198781198941198921

119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875119894 119905119898119901119875119882119894 1198621198941198781198941198922)) Inthe login protocol 119874119879119875119894 and 119866119872 are not added tothe encryption as in Figure 4 After that 119862119894 sendsthe registration and login request or login to 119862119878 tocomplete the authentication protocol Then 119862119894 hidesthe private key by 119905119898119901119862119894119870119901119903119894 = 119862119894119870119901119903119894 oplus119875119882119894 oplus1198621198941198781198941198922

119862119878 Side

(i) Upon receiving a registration and login request orlogin request 119862119878 decrypts this request using ECIESrsquos119862119894119870119901119906119894 and 119862119878119870119901119903119894 It checks the timestamp (119879119878119862119878-119879119878119862119894 le 998779119879) to make sure that this request arrived atan appropriate time and without delay

(ii) In the registration and login protocol 119862119878 examinesthe random 119874119879119875119894 in the dataset If 119874119879119875119894 exists thenthe user is legitimate for the registration process After

that 119862119878 deletes 119874119879119875119894 from the dataset to prevent itfrom being used the next times If 119874119879119875119894 is not foundit discards the connection In the login protocol119862119878 examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 and then tests theirassociation with the MAC address in the dataset If119866119872 is found 119862119878 completes the steps of this protocolotherwise it cancels the connection

(iii) 119862119878 needs to ensure that the userrsquos device is legitimatewithin the network 119862119878 computes the signature valueto make sure that the MAC address is native andnonmodified (1198621198781198781198941198921 = ℎ(ldquoReal MACrdquo 119873119862119894 119879119878119862119894)) It examines the result of the computed sig-nature (1198621198781198781198941198921) with 119862119894rsquos signature (1198621198941198781198941198921) If thesignatures results are identical then the device islegitimate and the MAC address did not change Inthe registration and login protocol 119862119878 stores thisaddress in the dataset for use and checks the nexttimes in the login protocol

(iv) 119862119878 performs the computation operation 119905119898119901119875119882119894 oplus119873119862119894 oplus119866119872oplus1198621198781198781198941198921 to extract the 119875119882119894 value and thenuses this value to produce a second signature (1198621198781198781198941198922)

(v) 119862119878 computes a second signature operation (1198621198781198781198941198922=ℎ(119866119872 119873119862119894 119879119878119862119894 1198621198781198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894

119874119879119875119894 119875119882119894)) to guarantee that all the encryptedinformation is not changed Then it compares thecomputed signature (1198621198781198781198941198922) with the received sig-nature in the request (1198621198941198781198941198922) If the signatures are

10 Security and Communication Networks

CS AS

Figure 4 Login protocol

identical then the information for this request isunchanged or not tampered with In the login proto-col 119874119879119875119894 and 119866119872 are not added to the signature Atthis point 119862119878 prepares to send the userrsquos authentica-tion request to 119860119878

433 Authentication Protocol The authentication protocolverifies the reliability of the usersrsquo security parameters withtheir personal information in the server In this protocolRAMHU needs to link pseudonyms and passwords with realinformation for users in 119860119878rsquos datasets Note that the usersrsquoinformation (such as name age address mobile number andpasswords) is stored in a separate server (AS) and multiplepseudonyms are used to prevent detection and trackingof usersrsquo information This protocol is illustrated in thefollowing steps (Figure 5 shows the authentication protocolin RAMHU)

119862119878 Side

(i) 119862119878 computes a new timestamp (119879119878119862119878) to ensure thefresh authentication request

(ii) 119862119878 replaces 119862119894rsquos pseudonyms (119880119875119862119878119862119894 and119872119875119862119878119862119894 ) with119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119872119875119860119878119862119878 ) to prevent attack-ers from tracking the authentication request It gen-erates random nonce (119873119862119878) to ensure an anonymousauthentication request

(iii) 119862119878 signs security parameters by PHOTON-256(1198621198781198781198941198923 = ℎ(119879119878119862119878 119873119862119878 119880119875

119860119878119862119878 119872119875119860119878119862119878 )) to prevent

modification of authentication request information(iv) 119862119878 computes temporary 119875119882119894 by the computation of

119875119882119894 oplus 119873119862119878 oplus 1198621198781198781198941198923

(v) 119862119878 encrypts information of authentication request(119864119899119888119894(119879119878119862119878 119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 1198621198781198781198941198923 119905119898119901119875119882119894)) It sends an authentication request to verifyuserrsquos information in 119860119878

119860119878 Side

(i) Upon receiving the authentication request 119860119878 de-crypts that request using ECIESrsquos 119860119878119870119901119903119894 and 119862119878119870119901119906119894to obtain the authentication information clearly

(ii) It checks the timestamp by 119879119878119860119878 minus 119879119878119862119878 le 998779119879 toensure that the authentication request is not delayed119860119878 checks the pseudonyms (119880119875119860119878119862119878 and 119872119875119860119878119862119878 ) sentfromCS and correlates them with the userrsquos real iden-tifier (119880119868119863119894 and119872119868119863119894) in the datasets 119860119878 extracts theuserrsquos password from the equation 119875119882119894 = 119905119898119901119875119882i oplus119873119862119878oplus1198621198781198781198941198923 After that it checksmatching119875119882119894 in thedataset 119860119878 computes the value of the signature basedon authentication information (1198601198781198781198941198921 = ℎ(119879119878119862119878

119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 )) by PHOTON-256 119860119878 com-

pares the computed value of the signature (1198601198781198781198941198921)with the value of the received signature (1198621198781198781198941198923) If

Security and Communication Networks 11

CS AS

Figure 5 Authentication protocol

the signature values are identical the userrsquos informa-tion in the request for the signature is unmodified Atthis point 119860119878 considers this user to be legitimate andreliable

(iii) 119860119878 prepares a response to authenticate the request ofthat user It computes a new timestamp (119879119878119860119878 = new119879119878119860119878) to prevent delayed or replayed requests at latertimes119860119878 replaces119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119880119875

119860119878119862119878 )

received with 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) tohide usersrsquo information It generates a new randomnonce (119873119860119878) to add anonymity and prevent attacksfrom encryption and signature analysis

(iv) 119860119878 computes a signature (1198601198781198781198941198922 = ℎ(119879119878119860119878 119873119860119878

119880119875119862119878119860119878 119872119875119862119878119860119878 )) to prevent modifications of authenti-cation response information

(v) 119860119878 encrypts the authentication information(119864119899119888119894(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 1198601198781198781198941198922))and sends the authentication response to 119862119878 tocomplete the authentication process

119862119878 Side(i) 119862119878 decrypts the authentication response (119864119899119888119894)

received from 119860119878 It checks the timestamp value(119879119878119862119878 minus 119879119878119860119878 le 998779119879) to prevent late authentication

12 Security and Communication Networks

responses It examines 119880119875119860119878119862119878 and119872119875119860119878119862119878 in datasets tocomplete the process of linking multiple pseudonymsto the user

(ii) 119862119878 computes the signature 1198621198781198781198941198924 = ℎ(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 ) for authentication response infor-mation It compares the computed result of thesignature (1198621198781198781198941198924) with the value of the receivedsignature (1198601198781198781198941198922) If the signature values matchthen the authentication response information is un-changed

(iii) After this point 119862119878 initiates a login response requestIt computes the value of new timestamp (119879119878119862119878 =

119899119890119908119879119878119862119878) It replaces 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) received with 119880119875

119862119894119862119878 and 119872119875

119862119894119862119878 It generates

a new random nonce (119873119862119878) to hide encryption andsignature information

(iv) 119862119878 computes a new signature value (1198621198781198781198941198925 =

ℎ(119879119878119862119878 119873119862119878 119880119875119862119894119862119878

119872119875119862119894119862119878)) to protect login

response information frommodification(v) 119862119878 encrypts login response information (119864119899119888119894(119879119878119862119878

119873119862S 119880119875119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sends thisresponse to 119862119894

119862119894 Side

(i) 119862119894 extracts his private key (119862119894119870119901119903119894) from 119905119898119901119862119894119870119901119903119894 oplus119875119882119894 oplus 1198621198941198781198941198922 and decrypts the login request (119864119899119888119894)received from 119862119878

(ii) 119862119894 checks the timestamp (119879119878119862119894 minus119879119878119862119878 le 998779119879) to ensurethat the login response is not late or replayed

(iii) 119862119894 checks that 119862119878rsquos pseudonyms (119880119875119862119894119862119878 and 119872119875119862119894119862119878)

are received in the dataset and associated with 119880119875119862119878119862119894and 119872119875C119878

119862119894 At this point RAMHU applied multiple

pseudonyms among model entities (119862119894 119862119878 and 119860119878)to prevent traceability in linking the real informationof the user with pseudonyms

(iv) 119862119894 calculates the value of the signature 1198621198941198781198941198923 =

ℎ(119879119878119862119878 119873C119878 119880119875119862119894119862119878 119872119875

119862119894119862119878) for login re-

sponse information It compares the result of thecomputed signature (1198621198941198781198941198923) and the value of thereceived signature (1198621198781198781198941198925 ) If the signature values areidentical namely the login response information isunmodified or not tamperedwith119862119894 accepts the loginresponse otherwise 119862119894 discards the login responseThen119862119894 hides its private key by 119862119894119870119901119903119894 oplus119866119872oplus119875119882119894 oplus119873119862119894 after generating a random nonce to prevent thedetection of the private key if the device is hackedAt this point if all processes are achieved correctlythen all requests are considered legitimate and reli-able through the implementation of mutual authenti-cation

434 Password Update Protocol Updating the password isa security procedure to ensure authentication of legitimate

users The process of changing 119875119882119894 is important in any HCsystem for two reasons First it prevents the use of 119875119882119894fixed for a long time which reduces the guessing attacksSecond changing119875119882119894 gives usersmore flexibility in choosingthe appropriate 119875119882119894 This process requires strict securitymeasures to protect the new 119875119882119894 RAMHU provides thelegitimate user with amechanism to change hisher passwordat any time If the user wants to change hisher 119875119882119894the following illustration describes the new 119875119882119894 protectionprocedures in a secure manner (Figure 6 shows the passwordupdate protocol in RAMHU)

(i) 119862119894 side 119862119894 enters 119880119868119863119894 119872119868119863119894 the old 119875119882119894 andthe new 119875119882119894 It replaces 119880119868119863119894 and 119872119868119863119894 withpseudonyms to hide the userrsquos real information 119862119894calls the MAC address and then extracts the privatekey from 119905119898119901119862119894119870119901119903119894oplus119866119872oplus119900119897119889119875119882119894oplus119873119862119894 to use in theencryption process of the password update request119862119894generates three random nonces (1198731198621 1198731198622 and 1198731198623)and computes a new timestamp (119879119878119862119894) 119862119894 computesthe signature value (1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)) by PHOTON-256 basedon the parameters of the password change requestIt applies an anonymity mechanism to the old 119875119882119894and new 119875119882119894 (119905119898119901 119900119897119889119875119882119894 = 119900119897119889119875119882119894 oplus1198731198622 oplus 1198621198941198781198941198921and 119905119898119901 119899119890119908119875119882119894 = 119899119890119908119875119882119894 oplus 1198731198623 oplus 1198621198941198781198941198921) to hidepasswords and not explicitly send them in the 119875119882119894change request It encrypts the 119875119882119894 change request(119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) and sends itto 119862119878 119862119894 then hides its private key by 119862119894119870119901119903119894 oplus 119866119872oplus119899119890119908119875119882119894 oplus 119873119862119894

(ii) 119862119878 side 119862119878 receives and decrypts a password updaterequest (119864119899119888119894) It examines the timestamp to preventdelayed requests and examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 indatasets 119862119878 extracts the old 119875119882119894 and new 119875119882119894 from119905119898119901 119900119897119889119875119882119894 oplus 1198731198622 oplus 1198621198941198781198941198921 and 119905119898119901 119899119890119908119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 Then it computes the signature value(1198621198781198781198941198921) depending on 119879119878119862119894 1198731198621 119880119875

119862119878119862119894 119872119875119862119878119862119894 and

119900119897119889119875119882119894 to check the matching between 1198621198781198781198941198921 and1198621198941198781198941198921 Similarly in the authentication protocol 119862119878computes 119879119878119862119878 and replaces pseudonyms 119862119878 gener-ates three nonces 1198731198621198781 1198731198621198782 and 1198731198621198783 and then 119862119878computes the signature value (ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119900119897119889119875119882119894)) and hides the old119875119882119894 and new119875119882119894by 119900119897119889119875119882119894 oplus 1198731198621198782 oplus 1198621198781198781198941198922 and 119899119890119908119875119882119894 oplus 1198731198621198783 oplus1198621198781198781198941198922 It encrypts the password update request withsecurity parameters (119879119878119862119878 1198731198621198781 1198731198621198782 1198731198621198783 119880119875

119860119878119862119878

119872119875119860119878119862119878 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 and 1198621198781198781198941198922) andsends to 119860119878

(iii) 119860119878 side 119860119878 receives the password update requestand decrypts (119864119899119888119894) this request with 119860119878119870119901119903119894 and119862119878119870119901119906119894 It checks time delay and then it checkslink pseudonyms with real information for users Itextracts the old119875119882119894 from 119905119898119901 119900119897119889119875119882119894oplus1198731198621198782oplus1198621198781198781198941198922and then it checks the old 119875119882119894 in the dataset It com-putes the signature value 1198601198781198781198941198921 = ℎ(119879119878119862119878 1198731198621198781

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 6: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

6 Security and Communication Networks

Table 3 Paperrsquos notations

Symbol Description119862119894 Client entity or user119862119878 Central server119860119878 Attributes server119863119878 Data server119880119868119863119894 119872119868119863119894 119862119894rsquos identity and medical centre identity119875119882119894 119905119898119901119875119882119894 119862119894rsquos password temporary password119862119894119870119901119906119894 119862119894119870119901119903119894 119862119894 public and private key119862119878119870119901119906119894 119862119878119870119901119903119894 119862119878 public and private key119860119878119870119901119906119894 119860119878119870119901119903119894 119860119878 public and private key119879119878119862119894 119879119878119862119878 119879119878119860119878 Timestamp generated by 119862119894 119862119878 119860119878

119873119862119894 119873119862119878 119873119860119878 Nonce random generated by 119862119894 119862119878 119860119878

119868 Internal or external intruder119868119868 119864119868 Internal intruder and external intruderℎ() One-way hash function119877119894 Role of patient patient relative or provider119877119877119894 Revocation reason119874119879119875119894 One-time password to authenticate first time119862119894119878119894119892119895 Signature generated by 119862119894 and j is signature number119862119878119878119894119892119895 Signature generated by 119862119878119860119878119878119894119892119895 Signature generated by 119860119878119880119875119862119878119862119894 119875119872

119862119878119862119894

User and medical centre pseudonyms sent by 119862119894 and verified by 119862119878119880119875119860119878119862119878 119875119872

119860119878119862119878 User and medical centre pseudonyms sent by 119862119878 and verified by 119860119878

119880119875119862119878119860119878 119875119872119862119878119860119878 User and medical centre pseudonyms sent by 119860119878 and verified by 119862119878

119880119875119862119894119862119878 119875119872

119862119894119862119878 User and medical centre pseudonyms sent by 119862119878 and verified by 119862119894

oplus Concatenation and exclusive or operations119866119872 119862119872 Get MAC and checkMAC address119864119899119888119894 119863119890119888119894 Encryption and decryption operations

in various operating systems such as Linux and WindowsIn addition anyone can use the Address Resolution Protocol(ARP) to detect the MAC address of another user in thenetwork [53] The main problem with this address is thatthe attacker can execute an eavesdropping attack to accessthe MAC addresses of legitimate devices in the network andthen select a legitimate MAC address to use it For instancean attacker could execute an ARP poisoning or spoofingattack by using a fake identifier of the MAC address (for alegitimate entity) to gain illegal privileges that would enableit to perform other attacks such as MITM and DoS [54]In addition randomization operations for the MAC addresshave become useless in the protection against tracking attacks[55 56] Therefore if the server does not have a mechanismto detect MAC address change the attacker becomes alegitimate user in the network and has access to networkresources

4 The Proposed Authentication Scheme

In this section we will detail RAMHU that provides securityand efficiency features in HC applications This sectionwill be divided into the network model security goalsand proposed authentication protocols Notations listed in

Table 3 are used to describe symbols used throughout thispaper

41 Network Model The RAMHU model consists of fourentities as shown in Figure 2

(1) Client (119862119894) This entity includes patients relativesof patients and HC providers such as doctorsresearchers emergency practitioners advisors andnurses

(2) Central server (119862119878) This entity is a gateway toauthenticate users with the attributes server and toauthorise the data server

(3) Attributes server (119860119878) This entity contains usersrsquo realinformation as well as multiple pseudonyms Theauthentication process requires verifying the asso-ciation of the actual information with the multiplepseudonyms in this entity

(4) Data server (119863119878) This entity contains usersrsquo dataas well as multiple pseudonyms This entity is notimplemented in our scheme and is left to future workOur scheme focuses only on the process of usersrsquoauthentication in the HC network

Security and Communication Networks 7

Network model

Acknowledgement

Client

Attributes server (AS)

Central server (CS)

Data server (DS)

Authentication request

Informationrepository

Datarepository

Check userrsquos information

Response

Authentication request

Response

Acknowledgement Data request(with pseudonyms)

Figure 2 General network model

Generally 119862119894 creates an authentication request mainlybased on ECIES and PHOTON 119862119894 sends a request to 119862119878 toverify encryption signature and security parameters (suchas MAC address pseudonyms and 119874119879119875119894) Then the 119862119878sends a request to the 119860119878 to verify the link between thepseudonyms the real information the signatures and 119875119882119894After that the 119860119878 sends the response to the 119862119878 that verifiesthe signature and the parameters and then the 119862119878 sendsthe response (authenticated or not) to the 119862119894 If the useris authenticated we assume that the user can then send anauthorisation request to access the data in the repository (119863119878)and obtain the authorisation response from the 119862119878 119860119878 and119863119878

42 Security Goals To build a robust authentication schemeRAMHU adopts the following security requirements

(i) Confidentiality This requirement is performed tohide authentication information and to preserve usersecrecy from detection by intruders To implementthis requirement a high-security cryptographic algo-rithm [20] should be used RAMHU executes ECIESto hide authentication information about intruders

(ii) Integrity This is to protect the authentication requestinformation from modification by intruders Theauthentication request should reach the intendeddestination without modification to provide a reliablecommunication channel for legitimate users [10 57]RAMHU performs a PHOTON to prevent any pro-cess ofmodifying the user authentication informationin HC applications

(iii) Nonrepudiation This requirement prevents both theclients and server from denying their authenticationrequests This is a way to prove that the message issent by a particular sender in the HC applications

network If a legitimate user in the network performsinternal attacks heshe cannot deny hisher activitieswhile exploiting the privileges granted to himherOur scheme uses PHOTON signatures and a MACaddress tomeet this requirement and detectmaliciousattacks

(iv) Anonymity This requirement is extremely impor-tant in supporting the confidentiality of the authen-tication request The purpose of this requirementis to disguise the source and destination of theauthentication request If the authentication schemeapplies anonymity with encryption the attackerfinds it exceedingly difficult to analyse authentica-tion requests for a particular user at different timesbecause the authentication request is different eachtime the user is connected to the network [7]RAMHU applies this requirement through the use ofrandom nonces between entities

(v) Pseudonym This requirement denotes the provisionof a mechanism to connect nonreal attributes (suchas terms and symbols) with the real attributes of theuser (such as name address and phone number)The use of this mechanism in HC applications isan extremely important way to protect the personalinformation of users and prevent the detection oftheir identities RAMHU uses a multiple-pseudonymmechanism to prevent and separate the associationwith real information

(vi) Forward secrecy This requirement is accomplishedwhen network users use new keys and parameterstemporarily without relying on old onesThis require-ment prevents attackers from exploiting usersrsquo keysand passwords in decrypting authentication requestsUsing the temporary random password private key

8 Security and Communication Networks

and MAC RAMHU prevents users from accessingprevious authentication information

(vii) Mutual authentication This requirement is used inHCapplications tomitigate the risks of external fraudWith this feature each party ensures that it deals witha legitimate party The server authenticates the clientby checking encryptions and signatures and viceversa in order to establish a secure communicationchannel In RAMHU 119862119878 and 119862119894 authenticate eachother to prevent masquerading and impersonatingattacks

(viii) ScalabilityHCapplications operate in a scalable envi-ronment in terms of data and users Therefore theseapplications require authentication schemes capableof handling and adapting to the ever-increasing num-ber of users of HC applications This requirementrefers to the ability of the authentication scheme toappropriately handle large HC systems Public keyencryption schemes are efficient in supporting thisrequirement [24]

(ix) FreshnessThis requirement indicates that the authen-tication request is new and updated to ensure thatthe attacker cannot replay the authentication requestat a later time This requirement is achieved throughthe provision of time checking a random nonce andchange of signatures in each authentication process tocounteract counterfeit attacks such as MITM replayand impersonation [20] which ensures that theauthentication request is unaltered or not tamperedwith

43 Proposed Authentication Scheme The RAMHU schemeconsists of 5 protocols initial setup registrationloginauthentication password update and revocation Duringthese protocols RAMHU provides reliable authenticationprocesses to protect usersrsquo information

431 Initial Setup Protocol In this protocol all entitiesare ready to start communicating with each other whileconfiguring all security parameters and ECIESrsquos keys as in thefollowing steps

(i) Each legitimate user receives a client application fromthe authorised system provider

(ii) Each legitimate user receives a 119875119882119894 (that can bechanged later) and a random 119874119879119875119894 to be used in thefirst registration

(iii) All entities (119862119894 119862119878 and 119860119878) should create publicand private keys (119862119894 (119862119870119901119906119894 119862119870119901119903119894) 119862119878 (119862119878119870119901119906119894 119862119878119870119901119903119894) and 119860119878 (119860119878119870119901119906119894 119860119878119870119901119903119894)) to be used tovalidate the authentication request All entities choosean elliptic curve 119864119901(119886 119887) over a prime field 119865119875 (where119875 = 256) and base point 119866 on curve Each entityselects a private key 119870119901119903119894 randomly and generates thepublic key 119870119901119906119894 during the implementation of scalarmultiplication (119870119901119906119894 = 119870119901119903119894 lowast 119866)

(iv) All entities broadcast the public key (119862119870119901119906119894 119862119878119870119901119906119894 and 119860119878119870119901119906119894) to use in ECIESrsquos encryption operations

432 Registration and Login Protocol Patients and HCproviders (119862119894) should complete the registration and loginprotocol with 119862119878 to become legitimate users of HC appli-cations Without this protocol the user cannot completethe authentication process in RAMHU User registration isperformed once namely the user does not need to completethe registration protocol the next times (only the loginprotocol) the registration information has been kept in theservers until the revocation protocol and deletion of the usersecurity parameters such as pseudonyms MAC address and119875119882119894 this protocol accomplishes the following steps (Figure 3shows the registration and login protocol and Figure 4 showsthe login protocol)

119862119894 Side

(i) The user enters 119880119868119863119894 (such as hisher name) 119872119868119863119894(such as medical centre name) and 119875119882119894 and 119874119879119875119894for registration and login while only entering 119880119868119863119894119872119868119863119894 and119875119882119894 for the login protocol the next times tothe client (119862119894) application119862119894 replaces119880119868119863119894with userrsquospseudonym (119880119875119862119878119862119894 ) and 119872119868119863119894 with medical centrepseudonym (119872119875119862119878119862119894 ) to protect the authenticationinformationwhenmoving from119862119894 to119862119878119862119894 generatesa timestamp (119879119878119862119894) to be used to verify the sendingtime of the registrationlogin request in 119862119878

(ii) 119862119894 gets a MAC address (GM) by entering its IP(Internet protocol) address The process of checkingMAC (119862119872) is performed by 119862119894 to test the cred-ibility of the MAC address In the Linux systemwe used the command ldquoethtool -P interface namerdquo(such as ldquoethtool -P wlo1rdquo) in the 119862119894 applicationIf the result is identical to 119866119872 it means that theMAC address is native (119862119872 = ldquo119877119890119886119897 119872119860119862rdquo) Inthe Windows system 119862119894 searches for string valueldquoNetworkAddressrdquo in the path of the system reg-istry (ldquo119867119870119864119884 119871119874119862119860119871 119872119860119862119867119868119873119864 119878119884119878119879119864119872 119862119906119903119903119890119899119905119862119900119899119905119903119900119897119878119890119905 119862119900119899119905119903119900119897 119862119897119886119904119904 411986336119864972 minus119864325 minus 11119862119864 minus 1198611198651198621 minus 0800211986111986410318rdquo) If Net-workAddress = null 119862119872 = ldquo119877119890119886119897 119872119860119862rdquo otherwise119862119872 = ldquo119865119886119896119890 119872119860119862rdquo The 119866119872 send is encrypted witha registrationlogin request while 119862119872 is implicitlysent with the signature value (1198621198941198781198941198921) In only thelogin protocol 119862119894 needs to extract a private keyfrom the temporary keyMAC address password andrandom nonce through 119905119898119901119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus119873119862119894 119862119894 generates a random nonce (119873119862119894) to changesignature and encryption data and add anonymity tothe registrationlogin request

(iii) 119862119894 performs two signatures using the PHOTON-256algorithm to protect information from modificationThe first signature includes the parameters checkMAC nonce and timestamp (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) The second signature includes allthe authentication parameters of the gotten MAC

Security and Communication Networks 9

CS AS

Figure 3 Registration and login protocol

nonce timestamp first signature pseudonyms one-time password and password (1198621198941198781198941198922 = ℎ(119866119872

119873119862119894 119879119878119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875

119875119882119894)) In the login protocol 119874119879119875 is not added to thesignature

(iv) 119862119894 computes a temporary value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus 1198621198941198781198941198921) of 119875119882119894 when moving from 119862119894 to119862119878

(v) 119862119894 uses ECIES to encrypt and hide all the data ofthis request (119864119899119888119894(119879119878119862119894 119873119862119894 119866119872 1198621198941198781198941198921

119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875119894 119905119898119901119875119882119894 1198621198941198781198941198922)) Inthe login protocol 119874119879119875119894 and 119866119872 are not added tothe encryption as in Figure 4 After that 119862119894 sendsthe registration and login request or login to 119862119878 tocomplete the authentication protocol Then 119862119894 hidesthe private key by 119905119898119901119862119894119870119901119903119894 = 119862119894119870119901119903119894 oplus119875119882119894 oplus1198621198941198781198941198922

119862119878 Side

(i) Upon receiving a registration and login request orlogin request 119862119878 decrypts this request using ECIESrsquos119862119894119870119901119906119894 and 119862119878119870119901119903119894 It checks the timestamp (119879119878119862119878-119879119878119862119894 le 998779119879) to make sure that this request arrived atan appropriate time and without delay

(ii) In the registration and login protocol 119862119878 examinesthe random 119874119879119875119894 in the dataset If 119874119879119875119894 exists thenthe user is legitimate for the registration process After

that 119862119878 deletes 119874119879119875119894 from the dataset to prevent itfrom being used the next times If 119874119879119875119894 is not foundit discards the connection In the login protocol119862119878 examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 and then tests theirassociation with the MAC address in the dataset If119866119872 is found 119862119878 completes the steps of this protocolotherwise it cancels the connection

(iii) 119862119878 needs to ensure that the userrsquos device is legitimatewithin the network 119862119878 computes the signature valueto make sure that the MAC address is native andnonmodified (1198621198781198781198941198921 = ℎ(ldquoReal MACrdquo 119873119862119894 119879119878119862119894)) It examines the result of the computed sig-nature (1198621198781198781198941198921) with 119862119894rsquos signature (1198621198941198781198941198921) If thesignatures results are identical then the device islegitimate and the MAC address did not change Inthe registration and login protocol 119862119878 stores thisaddress in the dataset for use and checks the nexttimes in the login protocol

(iv) 119862119878 performs the computation operation 119905119898119901119875119882119894 oplus119873119862119894 oplus119866119872oplus1198621198781198781198941198921 to extract the 119875119882119894 value and thenuses this value to produce a second signature (1198621198781198781198941198922)

(v) 119862119878 computes a second signature operation (1198621198781198781198941198922=ℎ(119866119872 119873119862119894 119879119878119862119894 1198621198781198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894

119874119879119875119894 119875119882119894)) to guarantee that all the encryptedinformation is not changed Then it compares thecomputed signature (1198621198781198781198941198922) with the received sig-nature in the request (1198621198941198781198941198922) If the signatures are

10 Security and Communication Networks

CS AS

Figure 4 Login protocol

identical then the information for this request isunchanged or not tampered with In the login proto-col 119874119879119875119894 and 119866119872 are not added to the signature Atthis point 119862119878 prepares to send the userrsquos authentica-tion request to 119860119878

433 Authentication Protocol The authentication protocolverifies the reliability of the usersrsquo security parameters withtheir personal information in the server In this protocolRAMHU needs to link pseudonyms and passwords with realinformation for users in 119860119878rsquos datasets Note that the usersrsquoinformation (such as name age address mobile number andpasswords) is stored in a separate server (AS) and multiplepseudonyms are used to prevent detection and trackingof usersrsquo information This protocol is illustrated in thefollowing steps (Figure 5 shows the authentication protocolin RAMHU)

119862119878 Side

(i) 119862119878 computes a new timestamp (119879119878119862119878) to ensure thefresh authentication request

(ii) 119862119878 replaces 119862119894rsquos pseudonyms (119880119875119862119878119862119894 and119872119875119862119878119862119894 ) with119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119872119875119860119878119862119878 ) to prevent attack-ers from tracking the authentication request It gen-erates random nonce (119873119862119878) to ensure an anonymousauthentication request

(iii) 119862119878 signs security parameters by PHOTON-256(1198621198781198781198941198923 = ℎ(119879119878119862119878 119873119862119878 119880119875

119860119878119862119878 119872119875119860119878119862119878 )) to prevent

modification of authentication request information(iv) 119862119878 computes temporary 119875119882119894 by the computation of

119875119882119894 oplus 119873119862119878 oplus 1198621198781198781198941198923

(v) 119862119878 encrypts information of authentication request(119864119899119888119894(119879119878119862119878 119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 1198621198781198781198941198923 119905119898119901119875119882119894)) It sends an authentication request to verifyuserrsquos information in 119860119878

119860119878 Side

(i) Upon receiving the authentication request 119860119878 de-crypts that request using ECIESrsquos 119860119878119870119901119903119894 and 119862119878119870119901119906119894to obtain the authentication information clearly

(ii) It checks the timestamp by 119879119878119860119878 minus 119879119878119862119878 le 998779119879 toensure that the authentication request is not delayed119860119878 checks the pseudonyms (119880119875119860119878119862119878 and 119872119875119860119878119862119878 ) sentfromCS and correlates them with the userrsquos real iden-tifier (119880119868119863119894 and119872119868119863119894) in the datasets 119860119878 extracts theuserrsquos password from the equation 119875119882119894 = 119905119898119901119875119882i oplus119873119862119878oplus1198621198781198781198941198923 After that it checksmatching119875119882119894 in thedataset 119860119878 computes the value of the signature basedon authentication information (1198601198781198781198941198921 = ℎ(119879119878119862119878

119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 )) by PHOTON-256 119860119878 com-

pares the computed value of the signature (1198601198781198781198941198921)with the value of the received signature (1198621198781198781198941198923) If

Security and Communication Networks 11

CS AS

Figure 5 Authentication protocol

the signature values are identical the userrsquos informa-tion in the request for the signature is unmodified Atthis point 119860119878 considers this user to be legitimate andreliable

(iii) 119860119878 prepares a response to authenticate the request ofthat user It computes a new timestamp (119879119878119860119878 = new119879119878119860119878) to prevent delayed or replayed requests at latertimes119860119878 replaces119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119880119875

119860119878119862119878 )

received with 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) tohide usersrsquo information It generates a new randomnonce (119873119860119878) to add anonymity and prevent attacksfrom encryption and signature analysis

(iv) 119860119878 computes a signature (1198601198781198781198941198922 = ℎ(119879119878119860119878 119873119860119878

119880119875119862119878119860119878 119872119875119862119878119860119878 )) to prevent modifications of authenti-cation response information

(v) 119860119878 encrypts the authentication information(119864119899119888119894(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 1198601198781198781198941198922))and sends the authentication response to 119862119878 tocomplete the authentication process

119862119878 Side(i) 119862119878 decrypts the authentication response (119864119899119888119894)

received from 119860119878 It checks the timestamp value(119879119878119862119878 minus 119879119878119860119878 le 998779119879) to prevent late authentication

12 Security and Communication Networks

responses It examines 119880119875119860119878119862119878 and119872119875119860119878119862119878 in datasets tocomplete the process of linking multiple pseudonymsto the user

(ii) 119862119878 computes the signature 1198621198781198781198941198924 = ℎ(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 ) for authentication response infor-mation It compares the computed result of thesignature (1198621198781198781198941198924) with the value of the receivedsignature (1198601198781198781198941198922) If the signature values matchthen the authentication response information is un-changed

(iii) After this point 119862119878 initiates a login response requestIt computes the value of new timestamp (119879119878119862119878 =

119899119890119908119879119878119862119878) It replaces 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) received with 119880119875

119862119894119862119878 and 119872119875

119862119894119862119878 It generates

a new random nonce (119873119862119878) to hide encryption andsignature information

(iv) 119862119878 computes a new signature value (1198621198781198781198941198925 =

ℎ(119879119878119862119878 119873119862119878 119880119875119862119894119862119878

119872119875119862119894119862119878)) to protect login

response information frommodification(v) 119862119878 encrypts login response information (119864119899119888119894(119879119878119862119878

119873119862S 119880119875119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sends thisresponse to 119862119894

119862119894 Side

(i) 119862119894 extracts his private key (119862119894119870119901119903119894) from 119905119898119901119862119894119870119901119903119894 oplus119875119882119894 oplus 1198621198941198781198941198922 and decrypts the login request (119864119899119888119894)received from 119862119878

(ii) 119862119894 checks the timestamp (119879119878119862119894 minus119879119878119862119878 le 998779119879) to ensurethat the login response is not late or replayed

(iii) 119862119894 checks that 119862119878rsquos pseudonyms (119880119875119862119894119862119878 and 119872119875119862119894119862119878)

are received in the dataset and associated with 119880119875119862119878119862119894and 119872119875C119878

119862119894 At this point RAMHU applied multiple

pseudonyms among model entities (119862119894 119862119878 and 119860119878)to prevent traceability in linking the real informationof the user with pseudonyms

(iv) 119862119894 calculates the value of the signature 1198621198941198781198941198923 =

ℎ(119879119878119862119878 119873C119878 119880119875119862119894119862119878 119872119875

119862119894119862119878) for login re-

sponse information It compares the result of thecomputed signature (1198621198941198781198941198923) and the value of thereceived signature (1198621198781198781198941198925 ) If the signature values areidentical namely the login response information isunmodified or not tamperedwith119862119894 accepts the loginresponse otherwise 119862119894 discards the login responseThen119862119894 hides its private key by 119862119894119870119901119903119894 oplus119866119872oplus119875119882119894 oplus119873119862119894 after generating a random nonce to prevent thedetection of the private key if the device is hackedAt this point if all processes are achieved correctlythen all requests are considered legitimate and reli-able through the implementation of mutual authenti-cation

434 Password Update Protocol Updating the password isa security procedure to ensure authentication of legitimate

users The process of changing 119875119882119894 is important in any HCsystem for two reasons First it prevents the use of 119875119882119894fixed for a long time which reduces the guessing attacksSecond changing119875119882119894 gives usersmore flexibility in choosingthe appropriate 119875119882119894 This process requires strict securitymeasures to protect the new 119875119882119894 RAMHU provides thelegitimate user with amechanism to change hisher passwordat any time If the user wants to change hisher 119875119882119894the following illustration describes the new 119875119882119894 protectionprocedures in a secure manner (Figure 6 shows the passwordupdate protocol in RAMHU)

(i) 119862119894 side 119862119894 enters 119880119868119863119894 119872119868119863119894 the old 119875119882119894 andthe new 119875119882119894 It replaces 119880119868119863119894 and 119872119868119863119894 withpseudonyms to hide the userrsquos real information 119862119894calls the MAC address and then extracts the privatekey from 119905119898119901119862119894119870119901119903119894oplus119866119872oplus119900119897119889119875119882119894oplus119873119862119894 to use in theencryption process of the password update request119862119894generates three random nonces (1198731198621 1198731198622 and 1198731198623)and computes a new timestamp (119879119878119862119894) 119862119894 computesthe signature value (1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)) by PHOTON-256 basedon the parameters of the password change requestIt applies an anonymity mechanism to the old 119875119882119894and new 119875119882119894 (119905119898119901 119900119897119889119875119882119894 = 119900119897119889119875119882119894 oplus1198731198622 oplus 1198621198941198781198941198921and 119905119898119901 119899119890119908119875119882119894 = 119899119890119908119875119882119894 oplus 1198731198623 oplus 1198621198941198781198941198921) to hidepasswords and not explicitly send them in the 119875119882119894change request It encrypts the 119875119882119894 change request(119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) and sends itto 119862119878 119862119894 then hides its private key by 119862119894119870119901119903119894 oplus 119866119872oplus119899119890119908119875119882119894 oplus 119873119862119894

(ii) 119862119878 side 119862119878 receives and decrypts a password updaterequest (119864119899119888119894) It examines the timestamp to preventdelayed requests and examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 indatasets 119862119878 extracts the old 119875119882119894 and new 119875119882119894 from119905119898119901 119900119897119889119875119882119894 oplus 1198731198622 oplus 1198621198941198781198941198921 and 119905119898119901 119899119890119908119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 Then it computes the signature value(1198621198781198781198941198921) depending on 119879119878119862119894 1198731198621 119880119875

119862119878119862119894 119872119875119862119878119862119894 and

119900119897119889119875119882119894 to check the matching between 1198621198781198781198941198921 and1198621198941198781198941198921 Similarly in the authentication protocol 119862119878computes 119879119878119862119878 and replaces pseudonyms 119862119878 gener-ates three nonces 1198731198621198781 1198731198621198782 and 1198731198621198783 and then 119862119878computes the signature value (ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119900119897119889119875119882119894)) and hides the old119875119882119894 and new119875119882119894by 119900119897119889119875119882119894 oplus 1198731198621198782 oplus 1198621198781198781198941198922 and 119899119890119908119875119882119894 oplus 1198731198621198783 oplus1198621198781198781198941198922 It encrypts the password update request withsecurity parameters (119879119878119862119878 1198731198621198781 1198731198621198782 1198731198621198783 119880119875

119860119878119862119878

119872119875119860119878119862119878 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 and 1198621198781198781198941198922) andsends to 119860119878

(iii) 119860119878 side 119860119878 receives the password update requestand decrypts (119864119899119888119894) this request with 119860119878119870119901119903119894 and119862119878119870119901119906119894 It checks time delay and then it checkslink pseudonyms with real information for users Itextracts the old119875119882119894 from 119905119898119901 119900119897119889119875119882119894oplus1198731198621198782oplus1198621198781198781198941198922and then it checks the old 119875119882119894 in the dataset It com-putes the signature value 1198601198781198781198941198921 = ℎ(119879119878119862119878 1198731198621198781

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 7: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Security and Communication Networks 7

Network model

Acknowledgement

Client

Attributes server (AS)

Central server (CS)

Data server (DS)

Authentication request

Informationrepository

Datarepository

Check userrsquos information

Response

Authentication request

Response

Acknowledgement Data request(with pseudonyms)

Figure 2 General network model

Generally 119862119894 creates an authentication request mainlybased on ECIES and PHOTON 119862119894 sends a request to 119862119878 toverify encryption signature and security parameters (suchas MAC address pseudonyms and 119874119879119875119894) Then the 119862119878sends a request to the 119860119878 to verify the link between thepseudonyms the real information the signatures and 119875119882119894After that the 119860119878 sends the response to the 119862119878 that verifiesthe signature and the parameters and then the 119862119878 sendsthe response (authenticated or not) to the 119862119894 If the useris authenticated we assume that the user can then send anauthorisation request to access the data in the repository (119863119878)and obtain the authorisation response from the 119862119878 119860119878 and119863119878

42 Security Goals To build a robust authentication schemeRAMHU adopts the following security requirements

(i) Confidentiality This requirement is performed tohide authentication information and to preserve usersecrecy from detection by intruders To implementthis requirement a high-security cryptographic algo-rithm [20] should be used RAMHU executes ECIESto hide authentication information about intruders

(ii) Integrity This is to protect the authentication requestinformation from modification by intruders Theauthentication request should reach the intendeddestination without modification to provide a reliablecommunication channel for legitimate users [10 57]RAMHU performs a PHOTON to prevent any pro-cess ofmodifying the user authentication informationin HC applications

(iii) Nonrepudiation This requirement prevents both theclients and server from denying their authenticationrequests This is a way to prove that the message issent by a particular sender in the HC applications

network If a legitimate user in the network performsinternal attacks heshe cannot deny hisher activitieswhile exploiting the privileges granted to himherOur scheme uses PHOTON signatures and a MACaddress tomeet this requirement and detectmaliciousattacks

(iv) Anonymity This requirement is extremely impor-tant in supporting the confidentiality of the authen-tication request The purpose of this requirementis to disguise the source and destination of theauthentication request If the authentication schemeapplies anonymity with encryption the attackerfinds it exceedingly difficult to analyse authentica-tion requests for a particular user at different timesbecause the authentication request is different eachtime the user is connected to the network [7]RAMHU applies this requirement through the use ofrandom nonces between entities

(v) Pseudonym This requirement denotes the provisionof a mechanism to connect nonreal attributes (suchas terms and symbols) with the real attributes of theuser (such as name address and phone number)The use of this mechanism in HC applications isan extremely important way to protect the personalinformation of users and prevent the detection oftheir identities RAMHU uses a multiple-pseudonymmechanism to prevent and separate the associationwith real information

(vi) Forward secrecy This requirement is accomplishedwhen network users use new keys and parameterstemporarily without relying on old onesThis require-ment prevents attackers from exploiting usersrsquo keysand passwords in decrypting authentication requestsUsing the temporary random password private key

8 Security and Communication Networks

and MAC RAMHU prevents users from accessingprevious authentication information

(vii) Mutual authentication This requirement is used inHCapplications tomitigate the risks of external fraudWith this feature each party ensures that it deals witha legitimate party The server authenticates the clientby checking encryptions and signatures and viceversa in order to establish a secure communicationchannel In RAMHU 119862119878 and 119862119894 authenticate eachother to prevent masquerading and impersonatingattacks

(viii) ScalabilityHCapplications operate in a scalable envi-ronment in terms of data and users Therefore theseapplications require authentication schemes capableof handling and adapting to the ever-increasing num-ber of users of HC applications This requirementrefers to the ability of the authentication scheme toappropriately handle large HC systems Public keyencryption schemes are efficient in supporting thisrequirement [24]

(ix) FreshnessThis requirement indicates that the authen-tication request is new and updated to ensure thatthe attacker cannot replay the authentication requestat a later time This requirement is achieved throughthe provision of time checking a random nonce andchange of signatures in each authentication process tocounteract counterfeit attacks such as MITM replayand impersonation [20] which ensures that theauthentication request is unaltered or not tamperedwith

43 Proposed Authentication Scheme The RAMHU schemeconsists of 5 protocols initial setup registrationloginauthentication password update and revocation Duringthese protocols RAMHU provides reliable authenticationprocesses to protect usersrsquo information

431 Initial Setup Protocol In this protocol all entitiesare ready to start communicating with each other whileconfiguring all security parameters and ECIESrsquos keys as in thefollowing steps

(i) Each legitimate user receives a client application fromthe authorised system provider

(ii) Each legitimate user receives a 119875119882119894 (that can bechanged later) and a random 119874119879119875119894 to be used in thefirst registration

(iii) All entities (119862119894 119862119878 and 119860119878) should create publicand private keys (119862119894 (119862119870119901119906119894 119862119870119901119903119894) 119862119878 (119862119878119870119901119906119894 119862119878119870119901119903119894) and 119860119878 (119860119878119870119901119906119894 119860119878119870119901119903119894)) to be used tovalidate the authentication request All entities choosean elliptic curve 119864119901(119886 119887) over a prime field 119865119875 (where119875 = 256) and base point 119866 on curve Each entityselects a private key 119870119901119903119894 randomly and generates thepublic key 119870119901119906119894 during the implementation of scalarmultiplication (119870119901119906119894 = 119870119901119903119894 lowast 119866)

(iv) All entities broadcast the public key (119862119870119901119906119894 119862119878119870119901119906119894 and 119860119878119870119901119906119894) to use in ECIESrsquos encryption operations

432 Registration and Login Protocol Patients and HCproviders (119862119894) should complete the registration and loginprotocol with 119862119878 to become legitimate users of HC appli-cations Without this protocol the user cannot completethe authentication process in RAMHU User registration isperformed once namely the user does not need to completethe registration protocol the next times (only the loginprotocol) the registration information has been kept in theservers until the revocation protocol and deletion of the usersecurity parameters such as pseudonyms MAC address and119875119882119894 this protocol accomplishes the following steps (Figure 3shows the registration and login protocol and Figure 4 showsthe login protocol)

119862119894 Side

(i) The user enters 119880119868119863119894 (such as hisher name) 119872119868119863119894(such as medical centre name) and 119875119882119894 and 119874119879119875119894for registration and login while only entering 119880119868119863119894119872119868119863119894 and119875119882119894 for the login protocol the next times tothe client (119862119894) application119862119894 replaces119880119868119863119894with userrsquospseudonym (119880119875119862119878119862119894 ) and 119872119868119863119894 with medical centrepseudonym (119872119875119862119878119862119894 ) to protect the authenticationinformationwhenmoving from119862119894 to119862119878119862119894 generatesa timestamp (119879119878119862119894) to be used to verify the sendingtime of the registrationlogin request in 119862119878

(ii) 119862119894 gets a MAC address (GM) by entering its IP(Internet protocol) address The process of checkingMAC (119862119872) is performed by 119862119894 to test the cred-ibility of the MAC address In the Linux systemwe used the command ldquoethtool -P interface namerdquo(such as ldquoethtool -P wlo1rdquo) in the 119862119894 applicationIf the result is identical to 119866119872 it means that theMAC address is native (119862119872 = ldquo119877119890119886119897 119872119860119862rdquo) Inthe Windows system 119862119894 searches for string valueldquoNetworkAddressrdquo in the path of the system reg-istry (ldquo119867119870119864119884 119871119874119862119860119871 119872119860119862119867119868119873119864 119878119884119878119879119864119872 119862119906119903119903119890119899119905119862119900119899119905119903119900119897119878119890119905 119862119900119899119905119903119900119897 119862119897119886119904119904 411986336119864972 minus119864325 minus 11119862119864 minus 1198611198651198621 minus 0800211986111986410318rdquo) If Net-workAddress = null 119862119872 = ldquo119877119890119886119897 119872119860119862rdquo otherwise119862119872 = ldquo119865119886119896119890 119872119860119862rdquo The 119866119872 send is encrypted witha registrationlogin request while 119862119872 is implicitlysent with the signature value (1198621198941198781198941198921) In only thelogin protocol 119862119894 needs to extract a private keyfrom the temporary keyMAC address password andrandom nonce through 119905119898119901119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus119873119862119894 119862119894 generates a random nonce (119873119862119894) to changesignature and encryption data and add anonymity tothe registrationlogin request

(iii) 119862119894 performs two signatures using the PHOTON-256algorithm to protect information from modificationThe first signature includes the parameters checkMAC nonce and timestamp (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) The second signature includes allthe authentication parameters of the gotten MAC

Security and Communication Networks 9

CS AS

Figure 3 Registration and login protocol

nonce timestamp first signature pseudonyms one-time password and password (1198621198941198781198941198922 = ℎ(119866119872

119873119862119894 119879119878119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875

119875119882119894)) In the login protocol 119874119879119875 is not added to thesignature

(iv) 119862119894 computes a temporary value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus 1198621198941198781198941198921) of 119875119882119894 when moving from 119862119894 to119862119878

(v) 119862119894 uses ECIES to encrypt and hide all the data ofthis request (119864119899119888119894(119879119878119862119894 119873119862119894 119866119872 1198621198941198781198941198921

119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875119894 119905119898119901119875119882119894 1198621198941198781198941198922)) Inthe login protocol 119874119879119875119894 and 119866119872 are not added tothe encryption as in Figure 4 After that 119862119894 sendsthe registration and login request or login to 119862119878 tocomplete the authentication protocol Then 119862119894 hidesthe private key by 119905119898119901119862119894119870119901119903119894 = 119862119894119870119901119903119894 oplus119875119882119894 oplus1198621198941198781198941198922

119862119878 Side

(i) Upon receiving a registration and login request orlogin request 119862119878 decrypts this request using ECIESrsquos119862119894119870119901119906119894 and 119862119878119870119901119903119894 It checks the timestamp (119879119878119862119878-119879119878119862119894 le 998779119879) to make sure that this request arrived atan appropriate time and without delay

(ii) In the registration and login protocol 119862119878 examinesthe random 119874119879119875119894 in the dataset If 119874119879119875119894 exists thenthe user is legitimate for the registration process After

that 119862119878 deletes 119874119879119875119894 from the dataset to prevent itfrom being used the next times If 119874119879119875119894 is not foundit discards the connection In the login protocol119862119878 examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 and then tests theirassociation with the MAC address in the dataset If119866119872 is found 119862119878 completes the steps of this protocolotherwise it cancels the connection

(iii) 119862119878 needs to ensure that the userrsquos device is legitimatewithin the network 119862119878 computes the signature valueto make sure that the MAC address is native andnonmodified (1198621198781198781198941198921 = ℎ(ldquoReal MACrdquo 119873119862119894 119879119878119862119894)) It examines the result of the computed sig-nature (1198621198781198781198941198921) with 119862119894rsquos signature (1198621198941198781198941198921) If thesignatures results are identical then the device islegitimate and the MAC address did not change Inthe registration and login protocol 119862119878 stores thisaddress in the dataset for use and checks the nexttimes in the login protocol

(iv) 119862119878 performs the computation operation 119905119898119901119875119882119894 oplus119873119862119894 oplus119866119872oplus1198621198781198781198941198921 to extract the 119875119882119894 value and thenuses this value to produce a second signature (1198621198781198781198941198922)

(v) 119862119878 computes a second signature operation (1198621198781198781198941198922=ℎ(119866119872 119873119862119894 119879119878119862119894 1198621198781198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894

119874119879119875119894 119875119882119894)) to guarantee that all the encryptedinformation is not changed Then it compares thecomputed signature (1198621198781198781198941198922) with the received sig-nature in the request (1198621198941198781198941198922) If the signatures are

10 Security and Communication Networks

CS AS

Figure 4 Login protocol

identical then the information for this request isunchanged or not tampered with In the login proto-col 119874119879119875119894 and 119866119872 are not added to the signature Atthis point 119862119878 prepares to send the userrsquos authentica-tion request to 119860119878

433 Authentication Protocol The authentication protocolverifies the reliability of the usersrsquo security parameters withtheir personal information in the server In this protocolRAMHU needs to link pseudonyms and passwords with realinformation for users in 119860119878rsquos datasets Note that the usersrsquoinformation (such as name age address mobile number andpasswords) is stored in a separate server (AS) and multiplepseudonyms are used to prevent detection and trackingof usersrsquo information This protocol is illustrated in thefollowing steps (Figure 5 shows the authentication protocolin RAMHU)

119862119878 Side

(i) 119862119878 computes a new timestamp (119879119878119862119878) to ensure thefresh authentication request

(ii) 119862119878 replaces 119862119894rsquos pseudonyms (119880119875119862119878119862119894 and119872119875119862119878119862119894 ) with119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119872119875119860119878119862119878 ) to prevent attack-ers from tracking the authentication request It gen-erates random nonce (119873119862119878) to ensure an anonymousauthentication request

(iii) 119862119878 signs security parameters by PHOTON-256(1198621198781198781198941198923 = ℎ(119879119878119862119878 119873119862119878 119880119875

119860119878119862119878 119872119875119860119878119862119878 )) to prevent

modification of authentication request information(iv) 119862119878 computes temporary 119875119882119894 by the computation of

119875119882119894 oplus 119873119862119878 oplus 1198621198781198781198941198923

(v) 119862119878 encrypts information of authentication request(119864119899119888119894(119879119878119862119878 119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 1198621198781198781198941198923 119905119898119901119875119882119894)) It sends an authentication request to verifyuserrsquos information in 119860119878

119860119878 Side

(i) Upon receiving the authentication request 119860119878 de-crypts that request using ECIESrsquos 119860119878119870119901119903119894 and 119862119878119870119901119906119894to obtain the authentication information clearly

(ii) It checks the timestamp by 119879119878119860119878 minus 119879119878119862119878 le 998779119879 toensure that the authentication request is not delayed119860119878 checks the pseudonyms (119880119875119860119878119862119878 and 119872119875119860119878119862119878 ) sentfromCS and correlates them with the userrsquos real iden-tifier (119880119868119863119894 and119872119868119863119894) in the datasets 119860119878 extracts theuserrsquos password from the equation 119875119882119894 = 119905119898119901119875119882i oplus119873119862119878oplus1198621198781198781198941198923 After that it checksmatching119875119882119894 in thedataset 119860119878 computes the value of the signature basedon authentication information (1198601198781198781198941198921 = ℎ(119879119878119862119878

119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 )) by PHOTON-256 119860119878 com-

pares the computed value of the signature (1198601198781198781198941198921)with the value of the received signature (1198621198781198781198941198923) If

Security and Communication Networks 11

CS AS

Figure 5 Authentication protocol

the signature values are identical the userrsquos informa-tion in the request for the signature is unmodified Atthis point 119860119878 considers this user to be legitimate andreliable

(iii) 119860119878 prepares a response to authenticate the request ofthat user It computes a new timestamp (119879119878119860119878 = new119879119878119860119878) to prevent delayed or replayed requests at latertimes119860119878 replaces119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119880119875

119860119878119862119878 )

received with 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) tohide usersrsquo information It generates a new randomnonce (119873119860119878) to add anonymity and prevent attacksfrom encryption and signature analysis

(iv) 119860119878 computes a signature (1198601198781198781198941198922 = ℎ(119879119878119860119878 119873119860119878

119880119875119862119878119860119878 119872119875119862119878119860119878 )) to prevent modifications of authenti-cation response information

(v) 119860119878 encrypts the authentication information(119864119899119888119894(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 1198601198781198781198941198922))and sends the authentication response to 119862119878 tocomplete the authentication process

119862119878 Side(i) 119862119878 decrypts the authentication response (119864119899119888119894)

received from 119860119878 It checks the timestamp value(119879119878119862119878 minus 119879119878119860119878 le 998779119879) to prevent late authentication

12 Security and Communication Networks

responses It examines 119880119875119860119878119862119878 and119872119875119860119878119862119878 in datasets tocomplete the process of linking multiple pseudonymsto the user

(ii) 119862119878 computes the signature 1198621198781198781198941198924 = ℎ(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 ) for authentication response infor-mation It compares the computed result of thesignature (1198621198781198781198941198924) with the value of the receivedsignature (1198601198781198781198941198922) If the signature values matchthen the authentication response information is un-changed

(iii) After this point 119862119878 initiates a login response requestIt computes the value of new timestamp (119879119878119862119878 =

119899119890119908119879119878119862119878) It replaces 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) received with 119880119875

119862119894119862119878 and 119872119875

119862119894119862119878 It generates

a new random nonce (119873119862119878) to hide encryption andsignature information

(iv) 119862119878 computes a new signature value (1198621198781198781198941198925 =

ℎ(119879119878119862119878 119873119862119878 119880119875119862119894119862119878

119872119875119862119894119862119878)) to protect login

response information frommodification(v) 119862119878 encrypts login response information (119864119899119888119894(119879119878119862119878

119873119862S 119880119875119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sends thisresponse to 119862119894

119862119894 Side

(i) 119862119894 extracts his private key (119862119894119870119901119903119894) from 119905119898119901119862119894119870119901119903119894 oplus119875119882119894 oplus 1198621198941198781198941198922 and decrypts the login request (119864119899119888119894)received from 119862119878

(ii) 119862119894 checks the timestamp (119879119878119862119894 minus119879119878119862119878 le 998779119879) to ensurethat the login response is not late or replayed

(iii) 119862119894 checks that 119862119878rsquos pseudonyms (119880119875119862119894119862119878 and 119872119875119862119894119862119878)

are received in the dataset and associated with 119880119875119862119878119862119894and 119872119875C119878

119862119894 At this point RAMHU applied multiple

pseudonyms among model entities (119862119894 119862119878 and 119860119878)to prevent traceability in linking the real informationof the user with pseudonyms

(iv) 119862119894 calculates the value of the signature 1198621198941198781198941198923 =

ℎ(119879119878119862119878 119873C119878 119880119875119862119894119862119878 119872119875

119862119894119862119878) for login re-

sponse information It compares the result of thecomputed signature (1198621198941198781198941198923) and the value of thereceived signature (1198621198781198781198941198925 ) If the signature values areidentical namely the login response information isunmodified or not tamperedwith119862119894 accepts the loginresponse otherwise 119862119894 discards the login responseThen119862119894 hides its private key by 119862119894119870119901119903119894 oplus119866119872oplus119875119882119894 oplus119873119862119894 after generating a random nonce to prevent thedetection of the private key if the device is hackedAt this point if all processes are achieved correctlythen all requests are considered legitimate and reli-able through the implementation of mutual authenti-cation

434 Password Update Protocol Updating the password isa security procedure to ensure authentication of legitimate

users The process of changing 119875119882119894 is important in any HCsystem for two reasons First it prevents the use of 119875119882119894fixed for a long time which reduces the guessing attacksSecond changing119875119882119894 gives usersmore flexibility in choosingthe appropriate 119875119882119894 This process requires strict securitymeasures to protect the new 119875119882119894 RAMHU provides thelegitimate user with amechanism to change hisher passwordat any time If the user wants to change hisher 119875119882119894the following illustration describes the new 119875119882119894 protectionprocedures in a secure manner (Figure 6 shows the passwordupdate protocol in RAMHU)

(i) 119862119894 side 119862119894 enters 119880119868119863119894 119872119868119863119894 the old 119875119882119894 andthe new 119875119882119894 It replaces 119880119868119863119894 and 119872119868119863119894 withpseudonyms to hide the userrsquos real information 119862119894calls the MAC address and then extracts the privatekey from 119905119898119901119862119894119870119901119903119894oplus119866119872oplus119900119897119889119875119882119894oplus119873119862119894 to use in theencryption process of the password update request119862119894generates three random nonces (1198731198621 1198731198622 and 1198731198623)and computes a new timestamp (119879119878119862119894) 119862119894 computesthe signature value (1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)) by PHOTON-256 basedon the parameters of the password change requestIt applies an anonymity mechanism to the old 119875119882119894and new 119875119882119894 (119905119898119901 119900119897119889119875119882119894 = 119900119897119889119875119882119894 oplus1198731198622 oplus 1198621198941198781198941198921and 119905119898119901 119899119890119908119875119882119894 = 119899119890119908119875119882119894 oplus 1198731198623 oplus 1198621198941198781198941198921) to hidepasswords and not explicitly send them in the 119875119882119894change request It encrypts the 119875119882119894 change request(119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) and sends itto 119862119878 119862119894 then hides its private key by 119862119894119870119901119903119894 oplus 119866119872oplus119899119890119908119875119882119894 oplus 119873119862119894

(ii) 119862119878 side 119862119878 receives and decrypts a password updaterequest (119864119899119888119894) It examines the timestamp to preventdelayed requests and examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 indatasets 119862119878 extracts the old 119875119882119894 and new 119875119882119894 from119905119898119901 119900119897119889119875119882119894 oplus 1198731198622 oplus 1198621198941198781198941198921 and 119905119898119901 119899119890119908119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 Then it computes the signature value(1198621198781198781198941198921) depending on 119879119878119862119894 1198731198621 119880119875

119862119878119862119894 119872119875119862119878119862119894 and

119900119897119889119875119882119894 to check the matching between 1198621198781198781198941198921 and1198621198941198781198941198921 Similarly in the authentication protocol 119862119878computes 119879119878119862119878 and replaces pseudonyms 119862119878 gener-ates three nonces 1198731198621198781 1198731198621198782 and 1198731198621198783 and then 119862119878computes the signature value (ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119900119897119889119875119882119894)) and hides the old119875119882119894 and new119875119882119894by 119900119897119889119875119882119894 oplus 1198731198621198782 oplus 1198621198781198781198941198922 and 119899119890119908119875119882119894 oplus 1198731198621198783 oplus1198621198781198781198941198922 It encrypts the password update request withsecurity parameters (119879119878119862119878 1198731198621198781 1198731198621198782 1198731198621198783 119880119875

119860119878119862119878

119872119875119860119878119862119878 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 and 1198621198781198781198941198922) andsends to 119860119878

(iii) 119860119878 side 119860119878 receives the password update requestand decrypts (119864119899119888119894) this request with 119860119878119870119901119903119894 and119862119878119870119901119906119894 It checks time delay and then it checkslink pseudonyms with real information for users Itextracts the old119875119882119894 from 119905119898119901 119900119897119889119875119882119894oplus1198731198621198782oplus1198621198781198781198941198922and then it checks the old 119875119882119894 in the dataset It com-putes the signature value 1198601198781198781198941198921 = ℎ(119879119878119862119878 1198731198621198781

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 8: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

8 Security and Communication Networks

and MAC RAMHU prevents users from accessingprevious authentication information

(vii) Mutual authentication This requirement is used inHCapplications tomitigate the risks of external fraudWith this feature each party ensures that it deals witha legitimate party The server authenticates the clientby checking encryptions and signatures and viceversa in order to establish a secure communicationchannel In RAMHU 119862119878 and 119862119894 authenticate eachother to prevent masquerading and impersonatingattacks

(viii) ScalabilityHCapplications operate in a scalable envi-ronment in terms of data and users Therefore theseapplications require authentication schemes capableof handling and adapting to the ever-increasing num-ber of users of HC applications This requirementrefers to the ability of the authentication scheme toappropriately handle large HC systems Public keyencryption schemes are efficient in supporting thisrequirement [24]

(ix) FreshnessThis requirement indicates that the authen-tication request is new and updated to ensure thatthe attacker cannot replay the authentication requestat a later time This requirement is achieved throughthe provision of time checking a random nonce andchange of signatures in each authentication process tocounteract counterfeit attacks such as MITM replayand impersonation [20] which ensures that theauthentication request is unaltered or not tamperedwith

43 Proposed Authentication Scheme The RAMHU schemeconsists of 5 protocols initial setup registrationloginauthentication password update and revocation Duringthese protocols RAMHU provides reliable authenticationprocesses to protect usersrsquo information

431 Initial Setup Protocol In this protocol all entitiesare ready to start communicating with each other whileconfiguring all security parameters and ECIESrsquos keys as in thefollowing steps

(i) Each legitimate user receives a client application fromthe authorised system provider

(ii) Each legitimate user receives a 119875119882119894 (that can bechanged later) and a random 119874119879119875119894 to be used in thefirst registration

(iii) All entities (119862119894 119862119878 and 119860119878) should create publicand private keys (119862119894 (119862119870119901119906119894 119862119870119901119903119894) 119862119878 (119862119878119870119901119906119894 119862119878119870119901119903119894) and 119860119878 (119860119878119870119901119906119894 119860119878119870119901119903119894)) to be used tovalidate the authentication request All entities choosean elliptic curve 119864119901(119886 119887) over a prime field 119865119875 (where119875 = 256) and base point 119866 on curve Each entityselects a private key 119870119901119903119894 randomly and generates thepublic key 119870119901119906119894 during the implementation of scalarmultiplication (119870119901119906119894 = 119870119901119903119894 lowast 119866)

(iv) All entities broadcast the public key (119862119870119901119906119894 119862119878119870119901119906119894 and 119860119878119870119901119906119894) to use in ECIESrsquos encryption operations

432 Registration and Login Protocol Patients and HCproviders (119862119894) should complete the registration and loginprotocol with 119862119878 to become legitimate users of HC appli-cations Without this protocol the user cannot completethe authentication process in RAMHU User registration isperformed once namely the user does not need to completethe registration protocol the next times (only the loginprotocol) the registration information has been kept in theservers until the revocation protocol and deletion of the usersecurity parameters such as pseudonyms MAC address and119875119882119894 this protocol accomplishes the following steps (Figure 3shows the registration and login protocol and Figure 4 showsthe login protocol)

119862119894 Side

(i) The user enters 119880119868119863119894 (such as hisher name) 119872119868119863119894(such as medical centre name) and 119875119882119894 and 119874119879119875119894for registration and login while only entering 119880119868119863119894119872119868119863119894 and119875119882119894 for the login protocol the next times tothe client (119862119894) application119862119894 replaces119880119868119863119894with userrsquospseudonym (119880119875119862119878119862119894 ) and 119872119868119863119894 with medical centrepseudonym (119872119875119862119878119862119894 ) to protect the authenticationinformationwhenmoving from119862119894 to119862119878119862119894 generatesa timestamp (119879119878119862119894) to be used to verify the sendingtime of the registrationlogin request in 119862119878

(ii) 119862119894 gets a MAC address (GM) by entering its IP(Internet protocol) address The process of checkingMAC (119862119872) is performed by 119862119894 to test the cred-ibility of the MAC address In the Linux systemwe used the command ldquoethtool -P interface namerdquo(such as ldquoethtool -P wlo1rdquo) in the 119862119894 applicationIf the result is identical to 119866119872 it means that theMAC address is native (119862119872 = ldquo119877119890119886119897 119872119860119862rdquo) Inthe Windows system 119862119894 searches for string valueldquoNetworkAddressrdquo in the path of the system reg-istry (ldquo119867119870119864119884 119871119874119862119860119871 119872119860119862119867119868119873119864 119878119884119878119879119864119872 119862119906119903119903119890119899119905119862119900119899119905119903119900119897119878119890119905 119862119900119899119905119903119900119897 119862119897119886119904119904 411986336119864972 minus119864325 minus 11119862119864 minus 1198611198651198621 minus 0800211986111986410318rdquo) If Net-workAddress = null 119862119872 = ldquo119877119890119886119897 119872119860119862rdquo otherwise119862119872 = ldquo119865119886119896119890 119872119860119862rdquo The 119866119872 send is encrypted witha registrationlogin request while 119862119872 is implicitlysent with the signature value (1198621198941198781198941198921) In only thelogin protocol 119862119894 needs to extract a private keyfrom the temporary keyMAC address password andrandom nonce through 119905119898119901119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus119873119862119894 119862119894 generates a random nonce (119873119862119894) to changesignature and encryption data and add anonymity tothe registrationlogin request

(iii) 119862119894 performs two signatures using the PHOTON-256algorithm to protect information from modificationThe first signature includes the parameters checkMAC nonce and timestamp (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) The second signature includes allthe authentication parameters of the gotten MAC

Security and Communication Networks 9

CS AS

Figure 3 Registration and login protocol

nonce timestamp first signature pseudonyms one-time password and password (1198621198941198781198941198922 = ℎ(119866119872

119873119862119894 119879119878119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875

119875119882119894)) In the login protocol 119874119879119875 is not added to thesignature

(iv) 119862119894 computes a temporary value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus 1198621198941198781198941198921) of 119875119882119894 when moving from 119862119894 to119862119878

(v) 119862119894 uses ECIES to encrypt and hide all the data ofthis request (119864119899119888119894(119879119878119862119894 119873119862119894 119866119872 1198621198941198781198941198921

119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875119894 119905119898119901119875119882119894 1198621198941198781198941198922)) Inthe login protocol 119874119879119875119894 and 119866119872 are not added tothe encryption as in Figure 4 After that 119862119894 sendsthe registration and login request or login to 119862119878 tocomplete the authentication protocol Then 119862119894 hidesthe private key by 119905119898119901119862119894119870119901119903119894 = 119862119894119870119901119903119894 oplus119875119882119894 oplus1198621198941198781198941198922

119862119878 Side

(i) Upon receiving a registration and login request orlogin request 119862119878 decrypts this request using ECIESrsquos119862119894119870119901119906119894 and 119862119878119870119901119903119894 It checks the timestamp (119879119878119862119878-119879119878119862119894 le 998779119879) to make sure that this request arrived atan appropriate time and without delay

(ii) In the registration and login protocol 119862119878 examinesthe random 119874119879119875119894 in the dataset If 119874119879119875119894 exists thenthe user is legitimate for the registration process After

that 119862119878 deletes 119874119879119875119894 from the dataset to prevent itfrom being used the next times If 119874119879119875119894 is not foundit discards the connection In the login protocol119862119878 examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 and then tests theirassociation with the MAC address in the dataset If119866119872 is found 119862119878 completes the steps of this protocolotherwise it cancels the connection

(iii) 119862119878 needs to ensure that the userrsquos device is legitimatewithin the network 119862119878 computes the signature valueto make sure that the MAC address is native andnonmodified (1198621198781198781198941198921 = ℎ(ldquoReal MACrdquo 119873119862119894 119879119878119862119894)) It examines the result of the computed sig-nature (1198621198781198781198941198921) with 119862119894rsquos signature (1198621198941198781198941198921) If thesignatures results are identical then the device islegitimate and the MAC address did not change Inthe registration and login protocol 119862119878 stores thisaddress in the dataset for use and checks the nexttimes in the login protocol

(iv) 119862119878 performs the computation operation 119905119898119901119875119882119894 oplus119873119862119894 oplus119866119872oplus1198621198781198781198941198921 to extract the 119875119882119894 value and thenuses this value to produce a second signature (1198621198781198781198941198922)

(v) 119862119878 computes a second signature operation (1198621198781198781198941198922=ℎ(119866119872 119873119862119894 119879119878119862119894 1198621198781198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894

119874119879119875119894 119875119882119894)) to guarantee that all the encryptedinformation is not changed Then it compares thecomputed signature (1198621198781198781198941198922) with the received sig-nature in the request (1198621198941198781198941198922) If the signatures are

10 Security and Communication Networks

CS AS

Figure 4 Login protocol

identical then the information for this request isunchanged or not tampered with In the login proto-col 119874119879119875119894 and 119866119872 are not added to the signature Atthis point 119862119878 prepares to send the userrsquos authentica-tion request to 119860119878

433 Authentication Protocol The authentication protocolverifies the reliability of the usersrsquo security parameters withtheir personal information in the server In this protocolRAMHU needs to link pseudonyms and passwords with realinformation for users in 119860119878rsquos datasets Note that the usersrsquoinformation (such as name age address mobile number andpasswords) is stored in a separate server (AS) and multiplepseudonyms are used to prevent detection and trackingof usersrsquo information This protocol is illustrated in thefollowing steps (Figure 5 shows the authentication protocolin RAMHU)

119862119878 Side

(i) 119862119878 computes a new timestamp (119879119878119862119878) to ensure thefresh authentication request

(ii) 119862119878 replaces 119862119894rsquos pseudonyms (119880119875119862119878119862119894 and119872119875119862119878119862119894 ) with119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119872119875119860119878119862119878 ) to prevent attack-ers from tracking the authentication request It gen-erates random nonce (119873119862119878) to ensure an anonymousauthentication request

(iii) 119862119878 signs security parameters by PHOTON-256(1198621198781198781198941198923 = ℎ(119879119878119862119878 119873119862119878 119880119875

119860119878119862119878 119872119875119860119878119862119878 )) to prevent

modification of authentication request information(iv) 119862119878 computes temporary 119875119882119894 by the computation of

119875119882119894 oplus 119873119862119878 oplus 1198621198781198781198941198923

(v) 119862119878 encrypts information of authentication request(119864119899119888119894(119879119878119862119878 119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 1198621198781198781198941198923 119905119898119901119875119882119894)) It sends an authentication request to verifyuserrsquos information in 119860119878

119860119878 Side

(i) Upon receiving the authentication request 119860119878 de-crypts that request using ECIESrsquos 119860119878119870119901119903119894 and 119862119878119870119901119906119894to obtain the authentication information clearly

(ii) It checks the timestamp by 119879119878119860119878 minus 119879119878119862119878 le 998779119879 toensure that the authentication request is not delayed119860119878 checks the pseudonyms (119880119875119860119878119862119878 and 119872119875119860119878119862119878 ) sentfromCS and correlates them with the userrsquos real iden-tifier (119880119868119863119894 and119872119868119863119894) in the datasets 119860119878 extracts theuserrsquos password from the equation 119875119882119894 = 119905119898119901119875119882i oplus119873119862119878oplus1198621198781198781198941198923 After that it checksmatching119875119882119894 in thedataset 119860119878 computes the value of the signature basedon authentication information (1198601198781198781198941198921 = ℎ(119879119878119862119878

119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 )) by PHOTON-256 119860119878 com-

pares the computed value of the signature (1198601198781198781198941198921)with the value of the received signature (1198621198781198781198941198923) If

Security and Communication Networks 11

CS AS

Figure 5 Authentication protocol

the signature values are identical the userrsquos informa-tion in the request for the signature is unmodified Atthis point 119860119878 considers this user to be legitimate andreliable

(iii) 119860119878 prepares a response to authenticate the request ofthat user It computes a new timestamp (119879119878119860119878 = new119879119878119860119878) to prevent delayed or replayed requests at latertimes119860119878 replaces119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119880119875

119860119878119862119878 )

received with 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) tohide usersrsquo information It generates a new randomnonce (119873119860119878) to add anonymity and prevent attacksfrom encryption and signature analysis

(iv) 119860119878 computes a signature (1198601198781198781198941198922 = ℎ(119879119878119860119878 119873119860119878

119880119875119862119878119860119878 119872119875119862119878119860119878 )) to prevent modifications of authenti-cation response information

(v) 119860119878 encrypts the authentication information(119864119899119888119894(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 1198601198781198781198941198922))and sends the authentication response to 119862119878 tocomplete the authentication process

119862119878 Side(i) 119862119878 decrypts the authentication response (119864119899119888119894)

received from 119860119878 It checks the timestamp value(119879119878119862119878 minus 119879119878119860119878 le 998779119879) to prevent late authentication

12 Security and Communication Networks

responses It examines 119880119875119860119878119862119878 and119872119875119860119878119862119878 in datasets tocomplete the process of linking multiple pseudonymsto the user

(ii) 119862119878 computes the signature 1198621198781198781198941198924 = ℎ(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 ) for authentication response infor-mation It compares the computed result of thesignature (1198621198781198781198941198924) with the value of the receivedsignature (1198601198781198781198941198922) If the signature values matchthen the authentication response information is un-changed

(iii) After this point 119862119878 initiates a login response requestIt computes the value of new timestamp (119879119878119862119878 =

119899119890119908119879119878119862119878) It replaces 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) received with 119880119875

119862119894119862119878 and 119872119875

119862119894119862119878 It generates

a new random nonce (119873119862119878) to hide encryption andsignature information

(iv) 119862119878 computes a new signature value (1198621198781198781198941198925 =

ℎ(119879119878119862119878 119873119862119878 119880119875119862119894119862119878

119872119875119862119894119862119878)) to protect login

response information frommodification(v) 119862119878 encrypts login response information (119864119899119888119894(119879119878119862119878

119873119862S 119880119875119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sends thisresponse to 119862119894

119862119894 Side

(i) 119862119894 extracts his private key (119862119894119870119901119903119894) from 119905119898119901119862119894119870119901119903119894 oplus119875119882119894 oplus 1198621198941198781198941198922 and decrypts the login request (119864119899119888119894)received from 119862119878

(ii) 119862119894 checks the timestamp (119879119878119862119894 minus119879119878119862119878 le 998779119879) to ensurethat the login response is not late or replayed

(iii) 119862119894 checks that 119862119878rsquos pseudonyms (119880119875119862119894119862119878 and 119872119875119862119894119862119878)

are received in the dataset and associated with 119880119875119862119878119862119894and 119872119875C119878

119862119894 At this point RAMHU applied multiple

pseudonyms among model entities (119862119894 119862119878 and 119860119878)to prevent traceability in linking the real informationof the user with pseudonyms

(iv) 119862119894 calculates the value of the signature 1198621198941198781198941198923 =

ℎ(119879119878119862119878 119873C119878 119880119875119862119894119862119878 119872119875

119862119894119862119878) for login re-

sponse information It compares the result of thecomputed signature (1198621198941198781198941198923) and the value of thereceived signature (1198621198781198781198941198925 ) If the signature values areidentical namely the login response information isunmodified or not tamperedwith119862119894 accepts the loginresponse otherwise 119862119894 discards the login responseThen119862119894 hides its private key by 119862119894119870119901119903119894 oplus119866119872oplus119875119882119894 oplus119873119862119894 after generating a random nonce to prevent thedetection of the private key if the device is hackedAt this point if all processes are achieved correctlythen all requests are considered legitimate and reli-able through the implementation of mutual authenti-cation

434 Password Update Protocol Updating the password isa security procedure to ensure authentication of legitimate

users The process of changing 119875119882119894 is important in any HCsystem for two reasons First it prevents the use of 119875119882119894fixed for a long time which reduces the guessing attacksSecond changing119875119882119894 gives usersmore flexibility in choosingthe appropriate 119875119882119894 This process requires strict securitymeasures to protect the new 119875119882119894 RAMHU provides thelegitimate user with amechanism to change hisher passwordat any time If the user wants to change hisher 119875119882119894the following illustration describes the new 119875119882119894 protectionprocedures in a secure manner (Figure 6 shows the passwordupdate protocol in RAMHU)

(i) 119862119894 side 119862119894 enters 119880119868119863119894 119872119868119863119894 the old 119875119882119894 andthe new 119875119882119894 It replaces 119880119868119863119894 and 119872119868119863119894 withpseudonyms to hide the userrsquos real information 119862119894calls the MAC address and then extracts the privatekey from 119905119898119901119862119894119870119901119903119894oplus119866119872oplus119900119897119889119875119882119894oplus119873119862119894 to use in theencryption process of the password update request119862119894generates three random nonces (1198731198621 1198731198622 and 1198731198623)and computes a new timestamp (119879119878119862119894) 119862119894 computesthe signature value (1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)) by PHOTON-256 basedon the parameters of the password change requestIt applies an anonymity mechanism to the old 119875119882119894and new 119875119882119894 (119905119898119901 119900119897119889119875119882119894 = 119900119897119889119875119882119894 oplus1198731198622 oplus 1198621198941198781198941198921and 119905119898119901 119899119890119908119875119882119894 = 119899119890119908119875119882119894 oplus 1198731198623 oplus 1198621198941198781198941198921) to hidepasswords and not explicitly send them in the 119875119882119894change request It encrypts the 119875119882119894 change request(119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) and sends itto 119862119878 119862119894 then hides its private key by 119862119894119870119901119903119894 oplus 119866119872oplus119899119890119908119875119882119894 oplus 119873119862119894

(ii) 119862119878 side 119862119878 receives and decrypts a password updaterequest (119864119899119888119894) It examines the timestamp to preventdelayed requests and examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 indatasets 119862119878 extracts the old 119875119882119894 and new 119875119882119894 from119905119898119901 119900119897119889119875119882119894 oplus 1198731198622 oplus 1198621198941198781198941198921 and 119905119898119901 119899119890119908119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 Then it computes the signature value(1198621198781198781198941198921) depending on 119879119878119862119894 1198731198621 119880119875

119862119878119862119894 119872119875119862119878119862119894 and

119900119897119889119875119882119894 to check the matching between 1198621198781198781198941198921 and1198621198941198781198941198921 Similarly in the authentication protocol 119862119878computes 119879119878119862119878 and replaces pseudonyms 119862119878 gener-ates three nonces 1198731198621198781 1198731198621198782 and 1198731198621198783 and then 119862119878computes the signature value (ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119900119897119889119875119882119894)) and hides the old119875119882119894 and new119875119882119894by 119900119897119889119875119882119894 oplus 1198731198621198782 oplus 1198621198781198781198941198922 and 119899119890119908119875119882119894 oplus 1198731198621198783 oplus1198621198781198781198941198922 It encrypts the password update request withsecurity parameters (119879119878119862119878 1198731198621198781 1198731198621198782 1198731198621198783 119880119875

119860119878119862119878

119872119875119860119878119862119878 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 and 1198621198781198781198941198922) andsends to 119860119878

(iii) 119860119878 side 119860119878 receives the password update requestand decrypts (119864119899119888119894) this request with 119860119878119870119901119903119894 and119862119878119870119901119906119894 It checks time delay and then it checkslink pseudonyms with real information for users Itextracts the old119875119882119894 from 119905119898119901 119900119897119889119875119882119894oplus1198731198621198782oplus1198621198781198781198941198922and then it checks the old 119875119882119894 in the dataset It com-putes the signature value 1198601198781198781198941198921 = ℎ(119879119878119862119878 1198731198621198781

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 9: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Security and Communication Networks 9

CS AS

Figure 3 Registration and login protocol

nonce timestamp first signature pseudonyms one-time password and password (1198621198941198781198941198922 = ℎ(119866119872

119873119862119894 119879119878119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875

119875119882119894)) In the login protocol 119874119879119875 is not added to thesignature

(iv) 119862119894 computes a temporary value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus 1198621198941198781198941198921) of 119875119882119894 when moving from 119862119894 to119862119878

(v) 119862119894 uses ECIES to encrypt and hide all the data ofthis request (119864119899119888119894(119879119878119862119894 119873119862119894 119866119872 1198621198941198781198941198921

119880119875119862119878119862119894 119872119875119862119878119862119894 119874119879119875119894 119905119898119901119875119882119894 1198621198941198781198941198922)) Inthe login protocol 119874119879119875119894 and 119866119872 are not added tothe encryption as in Figure 4 After that 119862119894 sendsthe registration and login request or login to 119862119878 tocomplete the authentication protocol Then 119862119894 hidesthe private key by 119905119898119901119862119894119870119901119903119894 = 119862119894119870119901119903119894 oplus119875119882119894 oplus1198621198941198781198941198922

119862119878 Side

(i) Upon receiving a registration and login request orlogin request 119862119878 decrypts this request using ECIESrsquos119862119894119870119901119906119894 and 119862119878119870119901119903119894 It checks the timestamp (119879119878119862119878-119879119878119862119894 le 998779119879) to make sure that this request arrived atan appropriate time and without delay

(ii) In the registration and login protocol 119862119878 examinesthe random 119874119879119875119894 in the dataset If 119874119879119875119894 exists thenthe user is legitimate for the registration process After

that 119862119878 deletes 119874119879119875119894 from the dataset to prevent itfrom being used the next times If 119874119879119875119894 is not foundit discards the connection In the login protocol119862119878 examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 and then tests theirassociation with the MAC address in the dataset If119866119872 is found 119862119878 completes the steps of this protocolotherwise it cancels the connection

(iii) 119862119878 needs to ensure that the userrsquos device is legitimatewithin the network 119862119878 computes the signature valueto make sure that the MAC address is native andnonmodified (1198621198781198781198941198921 = ℎ(ldquoReal MACrdquo 119873119862119894 119879119878119862119894)) It examines the result of the computed sig-nature (1198621198781198781198941198921) with 119862119894rsquos signature (1198621198941198781198941198921) If thesignatures results are identical then the device islegitimate and the MAC address did not change Inthe registration and login protocol 119862119878 stores thisaddress in the dataset for use and checks the nexttimes in the login protocol

(iv) 119862119878 performs the computation operation 119905119898119901119875119882119894 oplus119873119862119894 oplus119866119872oplus1198621198781198781198941198921 to extract the 119875119882119894 value and thenuses this value to produce a second signature (1198621198781198781198941198922)

(v) 119862119878 computes a second signature operation (1198621198781198781198941198922=ℎ(119866119872 119873119862119894 119879119878119862119894 1198621198781198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894

119874119879119875119894 119875119882119894)) to guarantee that all the encryptedinformation is not changed Then it compares thecomputed signature (1198621198781198781198941198922) with the received sig-nature in the request (1198621198941198781198941198922) If the signatures are

10 Security and Communication Networks

CS AS

Figure 4 Login protocol

identical then the information for this request isunchanged or not tampered with In the login proto-col 119874119879119875119894 and 119866119872 are not added to the signature Atthis point 119862119878 prepares to send the userrsquos authentica-tion request to 119860119878

433 Authentication Protocol The authentication protocolverifies the reliability of the usersrsquo security parameters withtheir personal information in the server In this protocolRAMHU needs to link pseudonyms and passwords with realinformation for users in 119860119878rsquos datasets Note that the usersrsquoinformation (such as name age address mobile number andpasswords) is stored in a separate server (AS) and multiplepseudonyms are used to prevent detection and trackingof usersrsquo information This protocol is illustrated in thefollowing steps (Figure 5 shows the authentication protocolin RAMHU)

119862119878 Side

(i) 119862119878 computes a new timestamp (119879119878119862119878) to ensure thefresh authentication request

(ii) 119862119878 replaces 119862119894rsquos pseudonyms (119880119875119862119878119862119894 and119872119875119862119878119862119894 ) with119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119872119875119860119878119862119878 ) to prevent attack-ers from tracking the authentication request It gen-erates random nonce (119873119862119878) to ensure an anonymousauthentication request

(iii) 119862119878 signs security parameters by PHOTON-256(1198621198781198781198941198923 = ℎ(119879119878119862119878 119873119862119878 119880119875

119860119878119862119878 119872119875119860119878119862119878 )) to prevent

modification of authentication request information(iv) 119862119878 computes temporary 119875119882119894 by the computation of

119875119882119894 oplus 119873119862119878 oplus 1198621198781198781198941198923

(v) 119862119878 encrypts information of authentication request(119864119899119888119894(119879119878119862119878 119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 1198621198781198781198941198923 119905119898119901119875119882119894)) It sends an authentication request to verifyuserrsquos information in 119860119878

119860119878 Side

(i) Upon receiving the authentication request 119860119878 de-crypts that request using ECIESrsquos 119860119878119870119901119903119894 and 119862119878119870119901119906119894to obtain the authentication information clearly

(ii) It checks the timestamp by 119879119878119860119878 minus 119879119878119862119878 le 998779119879 toensure that the authentication request is not delayed119860119878 checks the pseudonyms (119880119875119860119878119862119878 and 119872119875119860119878119862119878 ) sentfromCS and correlates them with the userrsquos real iden-tifier (119880119868119863119894 and119872119868119863119894) in the datasets 119860119878 extracts theuserrsquos password from the equation 119875119882119894 = 119905119898119901119875119882i oplus119873119862119878oplus1198621198781198781198941198923 After that it checksmatching119875119882119894 in thedataset 119860119878 computes the value of the signature basedon authentication information (1198601198781198781198941198921 = ℎ(119879119878119862119878

119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 )) by PHOTON-256 119860119878 com-

pares the computed value of the signature (1198601198781198781198941198921)with the value of the received signature (1198621198781198781198941198923) If

Security and Communication Networks 11

CS AS

Figure 5 Authentication protocol

the signature values are identical the userrsquos informa-tion in the request for the signature is unmodified Atthis point 119860119878 considers this user to be legitimate andreliable

(iii) 119860119878 prepares a response to authenticate the request ofthat user It computes a new timestamp (119879119878119860119878 = new119879119878119860119878) to prevent delayed or replayed requests at latertimes119860119878 replaces119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119880119875

119860119878119862119878 )

received with 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) tohide usersrsquo information It generates a new randomnonce (119873119860119878) to add anonymity and prevent attacksfrom encryption and signature analysis

(iv) 119860119878 computes a signature (1198601198781198781198941198922 = ℎ(119879119878119860119878 119873119860119878

119880119875119862119878119860119878 119872119875119862119878119860119878 )) to prevent modifications of authenti-cation response information

(v) 119860119878 encrypts the authentication information(119864119899119888119894(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 1198601198781198781198941198922))and sends the authentication response to 119862119878 tocomplete the authentication process

119862119878 Side(i) 119862119878 decrypts the authentication response (119864119899119888119894)

received from 119860119878 It checks the timestamp value(119879119878119862119878 minus 119879119878119860119878 le 998779119879) to prevent late authentication

12 Security and Communication Networks

responses It examines 119880119875119860119878119862119878 and119872119875119860119878119862119878 in datasets tocomplete the process of linking multiple pseudonymsto the user

(ii) 119862119878 computes the signature 1198621198781198781198941198924 = ℎ(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 ) for authentication response infor-mation It compares the computed result of thesignature (1198621198781198781198941198924) with the value of the receivedsignature (1198601198781198781198941198922) If the signature values matchthen the authentication response information is un-changed

(iii) After this point 119862119878 initiates a login response requestIt computes the value of new timestamp (119879119878119862119878 =

119899119890119908119879119878119862119878) It replaces 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) received with 119880119875

119862119894119862119878 and 119872119875

119862119894119862119878 It generates

a new random nonce (119873119862119878) to hide encryption andsignature information

(iv) 119862119878 computes a new signature value (1198621198781198781198941198925 =

ℎ(119879119878119862119878 119873119862119878 119880119875119862119894119862119878

119872119875119862119894119862119878)) to protect login

response information frommodification(v) 119862119878 encrypts login response information (119864119899119888119894(119879119878119862119878

119873119862S 119880119875119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sends thisresponse to 119862119894

119862119894 Side

(i) 119862119894 extracts his private key (119862119894119870119901119903119894) from 119905119898119901119862119894119870119901119903119894 oplus119875119882119894 oplus 1198621198941198781198941198922 and decrypts the login request (119864119899119888119894)received from 119862119878

(ii) 119862119894 checks the timestamp (119879119878119862119894 minus119879119878119862119878 le 998779119879) to ensurethat the login response is not late or replayed

(iii) 119862119894 checks that 119862119878rsquos pseudonyms (119880119875119862119894119862119878 and 119872119875119862119894119862119878)

are received in the dataset and associated with 119880119875119862119878119862119894and 119872119875C119878

119862119894 At this point RAMHU applied multiple

pseudonyms among model entities (119862119894 119862119878 and 119860119878)to prevent traceability in linking the real informationof the user with pseudonyms

(iv) 119862119894 calculates the value of the signature 1198621198941198781198941198923 =

ℎ(119879119878119862119878 119873C119878 119880119875119862119894119862119878 119872119875

119862119894119862119878) for login re-

sponse information It compares the result of thecomputed signature (1198621198941198781198941198923) and the value of thereceived signature (1198621198781198781198941198925 ) If the signature values areidentical namely the login response information isunmodified or not tamperedwith119862119894 accepts the loginresponse otherwise 119862119894 discards the login responseThen119862119894 hides its private key by 119862119894119870119901119903119894 oplus119866119872oplus119875119882119894 oplus119873119862119894 after generating a random nonce to prevent thedetection of the private key if the device is hackedAt this point if all processes are achieved correctlythen all requests are considered legitimate and reli-able through the implementation of mutual authenti-cation

434 Password Update Protocol Updating the password isa security procedure to ensure authentication of legitimate

users The process of changing 119875119882119894 is important in any HCsystem for two reasons First it prevents the use of 119875119882119894fixed for a long time which reduces the guessing attacksSecond changing119875119882119894 gives usersmore flexibility in choosingthe appropriate 119875119882119894 This process requires strict securitymeasures to protect the new 119875119882119894 RAMHU provides thelegitimate user with amechanism to change hisher passwordat any time If the user wants to change hisher 119875119882119894the following illustration describes the new 119875119882119894 protectionprocedures in a secure manner (Figure 6 shows the passwordupdate protocol in RAMHU)

(i) 119862119894 side 119862119894 enters 119880119868119863119894 119872119868119863119894 the old 119875119882119894 andthe new 119875119882119894 It replaces 119880119868119863119894 and 119872119868119863119894 withpseudonyms to hide the userrsquos real information 119862119894calls the MAC address and then extracts the privatekey from 119905119898119901119862119894119870119901119903119894oplus119866119872oplus119900119897119889119875119882119894oplus119873119862119894 to use in theencryption process of the password update request119862119894generates three random nonces (1198731198621 1198731198622 and 1198731198623)and computes a new timestamp (119879119878119862119894) 119862119894 computesthe signature value (1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)) by PHOTON-256 basedon the parameters of the password change requestIt applies an anonymity mechanism to the old 119875119882119894and new 119875119882119894 (119905119898119901 119900119897119889119875119882119894 = 119900119897119889119875119882119894 oplus1198731198622 oplus 1198621198941198781198941198921and 119905119898119901 119899119890119908119875119882119894 = 119899119890119908119875119882119894 oplus 1198731198623 oplus 1198621198941198781198941198921) to hidepasswords and not explicitly send them in the 119875119882119894change request It encrypts the 119875119882119894 change request(119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) and sends itto 119862119878 119862119894 then hides its private key by 119862119894119870119901119903119894 oplus 119866119872oplus119899119890119908119875119882119894 oplus 119873119862119894

(ii) 119862119878 side 119862119878 receives and decrypts a password updaterequest (119864119899119888119894) It examines the timestamp to preventdelayed requests and examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 indatasets 119862119878 extracts the old 119875119882119894 and new 119875119882119894 from119905119898119901 119900119897119889119875119882119894 oplus 1198731198622 oplus 1198621198941198781198941198921 and 119905119898119901 119899119890119908119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 Then it computes the signature value(1198621198781198781198941198921) depending on 119879119878119862119894 1198731198621 119880119875

119862119878119862119894 119872119875119862119878119862119894 and

119900119897119889119875119882119894 to check the matching between 1198621198781198781198941198921 and1198621198941198781198941198921 Similarly in the authentication protocol 119862119878computes 119879119878119862119878 and replaces pseudonyms 119862119878 gener-ates three nonces 1198731198621198781 1198731198621198782 and 1198731198621198783 and then 119862119878computes the signature value (ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119900119897119889119875119882119894)) and hides the old119875119882119894 and new119875119882119894by 119900119897119889119875119882119894 oplus 1198731198621198782 oplus 1198621198781198781198941198922 and 119899119890119908119875119882119894 oplus 1198731198621198783 oplus1198621198781198781198941198922 It encrypts the password update request withsecurity parameters (119879119878119862119878 1198731198621198781 1198731198621198782 1198731198621198783 119880119875

119860119878119862119878

119872119875119860119878119862119878 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 and 1198621198781198781198941198922) andsends to 119860119878

(iii) 119860119878 side 119860119878 receives the password update requestand decrypts (119864119899119888119894) this request with 119860119878119870119901119903119894 and119862119878119870119901119906119894 It checks time delay and then it checkslink pseudonyms with real information for users Itextracts the old119875119882119894 from 119905119898119901 119900119897119889119875119882119894oplus1198731198621198782oplus1198621198781198781198941198922and then it checks the old 119875119882119894 in the dataset It com-putes the signature value 1198601198781198781198941198921 = ℎ(119879119878119862119878 1198731198621198781

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 10: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

10 Security and Communication Networks

CS AS

Figure 4 Login protocol

identical then the information for this request isunchanged or not tampered with In the login proto-col 119874119879119875119894 and 119866119872 are not added to the signature Atthis point 119862119878 prepares to send the userrsquos authentica-tion request to 119860119878

433 Authentication Protocol The authentication protocolverifies the reliability of the usersrsquo security parameters withtheir personal information in the server In this protocolRAMHU needs to link pseudonyms and passwords with realinformation for users in 119860119878rsquos datasets Note that the usersrsquoinformation (such as name age address mobile number andpasswords) is stored in a separate server (AS) and multiplepseudonyms are used to prevent detection and trackingof usersrsquo information This protocol is illustrated in thefollowing steps (Figure 5 shows the authentication protocolin RAMHU)

119862119878 Side

(i) 119862119878 computes a new timestamp (119879119878119862119878) to ensure thefresh authentication request

(ii) 119862119878 replaces 119862119894rsquos pseudonyms (119880119875119862119878119862119894 and119872119875119862119878119862119894 ) with119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119872119875119860119878119862119878 ) to prevent attack-ers from tracking the authentication request It gen-erates random nonce (119873119862119878) to ensure an anonymousauthentication request

(iii) 119862119878 signs security parameters by PHOTON-256(1198621198781198781198941198923 = ℎ(119879119878119862119878 119873119862119878 119880119875

119860119878119862119878 119872119875119860119878119862119878 )) to prevent

modification of authentication request information(iv) 119862119878 computes temporary 119875119882119894 by the computation of

119875119882119894 oplus 119873119862119878 oplus 1198621198781198781198941198923

(v) 119862119878 encrypts information of authentication request(119864119899119888119894(119879119878119862119878 119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 1198621198781198781198941198923 119905119898119901119875119882119894)) It sends an authentication request to verifyuserrsquos information in 119860119878

119860119878 Side

(i) Upon receiving the authentication request 119860119878 de-crypts that request using ECIESrsquos 119860119878119870119901119903119894 and 119862119878119870119901119906119894to obtain the authentication information clearly

(ii) It checks the timestamp by 119879119878119860119878 minus 119879119878119862119878 le 998779119879 toensure that the authentication request is not delayed119860119878 checks the pseudonyms (119880119875119860119878119862119878 and 119872119875119860119878119862119878 ) sentfromCS and correlates them with the userrsquos real iden-tifier (119880119868119863119894 and119872119868119863119894) in the datasets 119860119878 extracts theuserrsquos password from the equation 119875119882119894 = 119905119898119901119875119882i oplus119873119862119878oplus1198621198781198781198941198923 After that it checksmatching119875119882119894 in thedataset 119860119878 computes the value of the signature basedon authentication information (1198601198781198781198941198921 = ℎ(119879119878119862119878

119873119862119878 119880119875119860119878119862119878 119872119875119860119878119862119878 )) by PHOTON-256 119860119878 com-

pares the computed value of the signature (1198601198781198781198941198921)with the value of the received signature (1198621198781198781198941198923) If

Security and Communication Networks 11

CS AS

Figure 5 Authentication protocol

the signature values are identical the userrsquos informa-tion in the request for the signature is unmodified Atthis point 119860119878 considers this user to be legitimate andreliable

(iii) 119860119878 prepares a response to authenticate the request ofthat user It computes a new timestamp (119879119878119860119878 = new119879119878119860119878) to prevent delayed or replayed requests at latertimes119860119878 replaces119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119880119875

119860119878119862119878 )

received with 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) tohide usersrsquo information It generates a new randomnonce (119873119860119878) to add anonymity and prevent attacksfrom encryption and signature analysis

(iv) 119860119878 computes a signature (1198601198781198781198941198922 = ℎ(119879119878119860119878 119873119860119878

119880119875119862119878119860119878 119872119875119862119878119860119878 )) to prevent modifications of authenti-cation response information

(v) 119860119878 encrypts the authentication information(119864119899119888119894(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 1198601198781198781198941198922))and sends the authentication response to 119862119878 tocomplete the authentication process

119862119878 Side(i) 119862119878 decrypts the authentication response (119864119899119888119894)

received from 119860119878 It checks the timestamp value(119879119878119862119878 minus 119879119878119860119878 le 998779119879) to prevent late authentication

12 Security and Communication Networks

responses It examines 119880119875119860119878119862119878 and119872119875119860119878119862119878 in datasets tocomplete the process of linking multiple pseudonymsto the user

(ii) 119862119878 computes the signature 1198621198781198781198941198924 = ℎ(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 ) for authentication response infor-mation It compares the computed result of thesignature (1198621198781198781198941198924) with the value of the receivedsignature (1198601198781198781198941198922) If the signature values matchthen the authentication response information is un-changed

(iii) After this point 119862119878 initiates a login response requestIt computes the value of new timestamp (119879119878119862119878 =

119899119890119908119879119878119862119878) It replaces 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) received with 119880119875

119862119894119862119878 and 119872119875

119862119894119862119878 It generates

a new random nonce (119873119862119878) to hide encryption andsignature information

(iv) 119862119878 computes a new signature value (1198621198781198781198941198925 =

ℎ(119879119878119862119878 119873119862119878 119880119875119862119894119862119878

119872119875119862119894119862119878)) to protect login

response information frommodification(v) 119862119878 encrypts login response information (119864119899119888119894(119879119878119862119878

119873119862S 119880119875119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sends thisresponse to 119862119894

119862119894 Side

(i) 119862119894 extracts his private key (119862119894119870119901119903119894) from 119905119898119901119862119894119870119901119903119894 oplus119875119882119894 oplus 1198621198941198781198941198922 and decrypts the login request (119864119899119888119894)received from 119862119878

(ii) 119862119894 checks the timestamp (119879119878119862119894 minus119879119878119862119878 le 998779119879) to ensurethat the login response is not late or replayed

(iii) 119862119894 checks that 119862119878rsquos pseudonyms (119880119875119862119894119862119878 and 119872119875119862119894119862119878)

are received in the dataset and associated with 119880119875119862119878119862119894and 119872119875C119878

119862119894 At this point RAMHU applied multiple

pseudonyms among model entities (119862119894 119862119878 and 119860119878)to prevent traceability in linking the real informationof the user with pseudonyms

(iv) 119862119894 calculates the value of the signature 1198621198941198781198941198923 =

ℎ(119879119878119862119878 119873C119878 119880119875119862119894119862119878 119872119875

119862119894119862119878) for login re-

sponse information It compares the result of thecomputed signature (1198621198941198781198941198923) and the value of thereceived signature (1198621198781198781198941198925 ) If the signature values areidentical namely the login response information isunmodified or not tamperedwith119862119894 accepts the loginresponse otherwise 119862119894 discards the login responseThen119862119894 hides its private key by 119862119894119870119901119903119894 oplus119866119872oplus119875119882119894 oplus119873119862119894 after generating a random nonce to prevent thedetection of the private key if the device is hackedAt this point if all processes are achieved correctlythen all requests are considered legitimate and reli-able through the implementation of mutual authenti-cation

434 Password Update Protocol Updating the password isa security procedure to ensure authentication of legitimate

users The process of changing 119875119882119894 is important in any HCsystem for two reasons First it prevents the use of 119875119882119894fixed for a long time which reduces the guessing attacksSecond changing119875119882119894 gives usersmore flexibility in choosingthe appropriate 119875119882119894 This process requires strict securitymeasures to protect the new 119875119882119894 RAMHU provides thelegitimate user with amechanism to change hisher passwordat any time If the user wants to change hisher 119875119882119894the following illustration describes the new 119875119882119894 protectionprocedures in a secure manner (Figure 6 shows the passwordupdate protocol in RAMHU)

(i) 119862119894 side 119862119894 enters 119880119868119863119894 119872119868119863119894 the old 119875119882119894 andthe new 119875119882119894 It replaces 119880119868119863119894 and 119872119868119863119894 withpseudonyms to hide the userrsquos real information 119862119894calls the MAC address and then extracts the privatekey from 119905119898119901119862119894119870119901119903119894oplus119866119872oplus119900119897119889119875119882119894oplus119873119862119894 to use in theencryption process of the password update request119862119894generates three random nonces (1198731198621 1198731198622 and 1198731198623)and computes a new timestamp (119879119878119862119894) 119862119894 computesthe signature value (1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)) by PHOTON-256 basedon the parameters of the password change requestIt applies an anonymity mechanism to the old 119875119882119894and new 119875119882119894 (119905119898119901 119900119897119889119875119882119894 = 119900119897119889119875119882119894 oplus1198731198622 oplus 1198621198941198781198941198921and 119905119898119901 119899119890119908119875119882119894 = 119899119890119908119875119882119894 oplus 1198731198623 oplus 1198621198941198781198941198921) to hidepasswords and not explicitly send them in the 119875119882119894change request It encrypts the 119875119882119894 change request(119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) and sends itto 119862119878 119862119894 then hides its private key by 119862119894119870119901119903119894 oplus 119866119872oplus119899119890119908119875119882119894 oplus 119873119862119894

(ii) 119862119878 side 119862119878 receives and decrypts a password updaterequest (119864119899119888119894) It examines the timestamp to preventdelayed requests and examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 indatasets 119862119878 extracts the old 119875119882119894 and new 119875119882119894 from119905119898119901 119900119897119889119875119882119894 oplus 1198731198622 oplus 1198621198941198781198941198921 and 119905119898119901 119899119890119908119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 Then it computes the signature value(1198621198781198781198941198921) depending on 119879119878119862119894 1198731198621 119880119875

119862119878119862119894 119872119875119862119878119862119894 and

119900119897119889119875119882119894 to check the matching between 1198621198781198781198941198921 and1198621198941198781198941198921 Similarly in the authentication protocol 119862119878computes 119879119878119862119878 and replaces pseudonyms 119862119878 gener-ates three nonces 1198731198621198781 1198731198621198782 and 1198731198621198783 and then 119862119878computes the signature value (ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119900119897119889119875119882119894)) and hides the old119875119882119894 and new119875119882119894by 119900119897119889119875119882119894 oplus 1198731198621198782 oplus 1198621198781198781198941198922 and 119899119890119908119875119882119894 oplus 1198731198621198783 oplus1198621198781198781198941198922 It encrypts the password update request withsecurity parameters (119879119878119862119878 1198731198621198781 1198731198621198782 1198731198621198783 119880119875

119860119878119862119878

119872119875119860119878119862119878 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 and 1198621198781198781198941198922) andsends to 119860119878

(iii) 119860119878 side 119860119878 receives the password update requestand decrypts (119864119899119888119894) this request with 119860119878119870119901119903119894 and119862119878119870119901119906119894 It checks time delay and then it checkslink pseudonyms with real information for users Itextracts the old119875119882119894 from 119905119898119901 119900119897119889119875119882119894oplus1198731198621198782oplus1198621198781198781198941198922and then it checks the old 119875119882119894 in the dataset It com-putes the signature value 1198601198781198781198941198921 = ℎ(119879119878119862119878 1198731198621198781

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 11: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Security and Communication Networks 11

CS AS

Figure 5 Authentication protocol

the signature values are identical the userrsquos informa-tion in the request for the signature is unmodified Atthis point 119860119878 considers this user to be legitimate andreliable

(iii) 119860119878 prepares a response to authenticate the request ofthat user It computes a new timestamp (119879119878119860119878 = new119879119878119860119878) to prevent delayed or replayed requests at latertimes119860119878 replaces119862119878rsquos pseudonyms (119880119875119860119878119862119878 and119880119875

119860119878119862119878 )

received with 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) tohide usersrsquo information It generates a new randomnonce (119873119860119878) to add anonymity and prevent attacksfrom encryption and signature analysis

(iv) 119860119878 computes a signature (1198601198781198781198941198922 = ℎ(119879119878119860119878 119873119860119878

119880119875119862119878119860119878 119872119875119862119878119860119878 )) to prevent modifications of authenti-cation response information

(v) 119860119878 encrypts the authentication information(119864119899119888119894(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 1198601198781198781198941198922))and sends the authentication response to 119862119878 tocomplete the authentication process

119862119878 Side(i) 119862119878 decrypts the authentication response (119864119899119888119894)

received from 119860119878 It checks the timestamp value(119879119878119862119878 minus 119879119878119860119878 le 998779119879) to prevent late authentication

12 Security and Communication Networks

responses It examines 119880119875119860119878119862119878 and119872119875119860119878119862119878 in datasets tocomplete the process of linking multiple pseudonymsto the user

(ii) 119862119878 computes the signature 1198621198781198781198941198924 = ℎ(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 ) for authentication response infor-mation It compares the computed result of thesignature (1198621198781198781198941198924) with the value of the receivedsignature (1198601198781198781198941198922) If the signature values matchthen the authentication response information is un-changed

(iii) After this point 119862119878 initiates a login response requestIt computes the value of new timestamp (119879119878119862119878 =

119899119890119908119879119878119862119878) It replaces 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) received with 119880119875

119862119894119862119878 and 119872119875

119862119894119862119878 It generates

a new random nonce (119873119862119878) to hide encryption andsignature information

(iv) 119862119878 computes a new signature value (1198621198781198781198941198925 =

ℎ(119879119878119862119878 119873119862119878 119880119875119862119894119862119878

119872119875119862119894119862119878)) to protect login

response information frommodification(v) 119862119878 encrypts login response information (119864119899119888119894(119879119878119862119878

119873119862S 119880119875119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sends thisresponse to 119862119894

119862119894 Side

(i) 119862119894 extracts his private key (119862119894119870119901119903119894) from 119905119898119901119862119894119870119901119903119894 oplus119875119882119894 oplus 1198621198941198781198941198922 and decrypts the login request (119864119899119888119894)received from 119862119878

(ii) 119862119894 checks the timestamp (119879119878119862119894 minus119879119878119862119878 le 998779119879) to ensurethat the login response is not late or replayed

(iii) 119862119894 checks that 119862119878rsquos pseudonyms (119880119875119862119894119862119878 and 119872119875119862119894119862119878)

are received in the dataset and associated with 119880119875119862119878119862119894and 119872119875C119878

119862119894 At this point RAMHU applied multiple

pseudonyms among model entities (119862119894 119862119878 and 119860119878)to prevent traceability in linking the real informationof the user with pseudonyms

(iv) 119862119894 calculates the value of the signature 1198621198941198781198941198923 =

ℎ(119879119878119862119878 119873C119878 119880119875119862119894119862119878 119872119875

119862119894119862119878) for login re-

sponse information It compares the result of thecomputed signature (1198621198941198781198941198923) and the value of thereceived signature (1198621198781198781198941198925 ) If the signature values areidentical namely the login response information isunmodified or not tamperedwith119862119894 accepts the loginresponse otherwise 119862119894 discards the login responseThen119862119894 hides its private key by 119862119894119870119901119903119894 oplus119866119872oplus119875119882119894 oplus119873119862119894 after generating a random nonce to prevent thedetection of the private key if the device is hackedAt this point if all processes are achieved correctlythen all requests are considered legitimate and reli-able through the implementation of mutual authenti-cation

434 Password Update Protocol Updating the password isa security procedure to ensure authentication of legitimate

users The process of changing 119875119882119894 is important in any HCsystem for two reasons First it prevents the use of 119875119882119894fixed for a long time which reduces the guessing attacksSecond changing119875119882119894 gives usersmore flexibility in choosingthe appropriate 119875119882119894 This process requires strict securitymeasures to protect the new 119875119882119894 RAMHU provides thelegitimate user with amechanism to change hisher passwordat any time If the user wants to change hisher 119875119882119894the following illustration describes the new 119875119882119894 protectionprocedures in a secure manner (Figure 6 shows the passwordupdate protocol in RAMHU)

(i) 119862119894 side 119862119894 enters 119880119868119863119894 119872119868119863119894 the old 119875119882119894 andthe new 119875119882119894 It replaces 119880119868119863119894 and 119872119868119863119894 withpseudonyms to hide the userrsquos real information 119862119894calls the MAC address and then extracts the privatekey from 119905119898119901119862119894119870119901119903119894oplus119866119872oplus119900119897119889119875119882119894oplus119873119862119894 to use in theencryption process of the password update request119862119894generates three random nonces (1198731198621 1198731198622 and 1198731198623)and computes a new timestamp (119879119878119862119894) 119862119894 computesthe signature value (1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)) by PHOTON-256 basedon the parameters of the password change requestIt applies an anonymity mechanism to the old 119875119882119894and new 119875119882119894 (119905119898119901 119900119897119889119875119882119894 = 119900119897119889119875119882119894 oplus1198731198622 oplus 1198621198941198781198941198921and 119905119898119901 119899119890119908119875119882119894 = 119899119890119908119875119882119894 oplus 1198731198623 oplus 1198621198941198781198941198921) to hidepasswords and not explicitly send them in the 119875119882119894change request It encrypts the 119875119882119894 change request(119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) and sends itto 119862119878 119862119894 then hides its private key by 119862119894119870119901119903119894 oplus 119866119872oplus119899119890119908119875119882119894 oplus 119873119862119894

(ii) 119862119878 side 119862119878 receives and decrypts a password updaterequest (119864119899119888119894) It examines the timestamp to preventdelayed requests and examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 indatasets 119862119878 extracts the old 119875119882119894 and new 119875119882119894 from119905119898119901 119900119897119889119875119882119894 oplus 1198731198622 oplus 1198621198941198781198941198921 and 119905119898119901 119899119890119908119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 Then it computes the signature value(1198621198781198781198941198921) depending on 119879119878119862119894 1198731198621 119880119875

119862119878119862119894 119872119875119862119878119862119894 and

119900119897119889119875119882119894 to check the matching between 1198621198781198781198941198921 and1198621198941198781198941198921 Similarly in the authentication protocol 119862119878computes 119879119878119862119878 and replaces pseudonyms 119862119878 gener-ates three nonces 1198731198621198781 1198731198621198782 and 1198731198621198783 and then 119862119878computes the signature value (ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119900119897119889119875119882119894)) and hides the old119875119882119894 and new119875119882119894by 119900119897119889119875119882119894 oplus 1198731198621198782 oplus 1198621198781198781198941198922 and 119899119890119908119875119882119894 oplus 1198731198621198783 oplus1198621198781198781198941198922 It encrypts the password update request withsecurity parameters (119879119878119862119878 1198731198621198781 1198731198621198782 1198731198621198783 119880119875

119860119878119862119878

119872119875119860119878119862119878 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 and 1198621198781198781198941198922) andsends to 119860119878

(iii) 119860119878 side 119860119878 receives the password update requestand decrypts (119864119899119888119894) this request with 119860119878119870119901119903119894 and119862119878119870119901119906119894 It checks time delay and then it checkslink pseudonyms with real information for users Itextracts the old119875119882119894 from 119905119898119901 119900119897119889119875119882119894oplus1198731198621198782oplus1198621198781198781198941198922and then it checks the old 119875119882119894 in the dataset It com-putes the signature value 1198601198781198781198941198921 = ℎ(119879119878119862119878 1198731198621198781

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 12: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

12 Security and Communication Networks

responses It examines 119880119875119860119878119862119878 and119872119875119860119878119862119878 in datasets tocomplete the process of linking multiple pseudonymsto the user

(ii) 119862119878 computes the signature 1198621198781198781198941198924 = ℎ(119879119878119860119878 119873119860119878 119880119875119862119878119860119878 119872119875119862119878119860119878 ) for authentication response infor-mation It compares the computed result of thesignature (1198621198781198781198941198924) with the value of the receivedsignature (1198601198781198781198941198922) If the signature values matchthen the authentication response information is un-changed

(iii) After this point 119862119878 initiates a login response requestIt computes the value of new timestamp (119879119878119862119878 =

119899119890119908119879119878119862119878) It replaces 119860119878rsquos pseudonyms (119880119875119862119878119860119878 and119872119875119862119878119860119878 ) received with 119880119875

119862119894119862119878 and 119872119875

119862119894119862119878 It generates

a new random nonce (119873119862119878) to hide encryption andsignature information

(iv) 119862119878 computes a new signature value (1198621198781198781198941198925 =

ℎ(119879119878119862119878 119873119862119878 119880119875119862119894119862119878

119872119875119862119894119862119878)) to protect login

response information frommodification(v) 119862119878 encrypts login response information (119864119899119888119894(119879119878119862119878

119873119862S 119880119875119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sends thisresponse to 119862119894

119862119894 Side

(i) 119862119894 extracts his private key (119862119894119870119901119903119894) from 119905119898119901119862119894119870119901119903119894 oplus119875119882119894 oplus 1198621198941198781198941198922 and decrypts the login request (119864119899119888119894)received from 119862119878

(ii) 119862119894 checks the timestamp (119879119878119862119894 minus119879119878119862119878 le 998779119879) to ensurethat the login response is not late or replayed

(iii) 119862119894 checks that 119862119878rsquos pseudonyms (119880119875119862119894119862119878 and 119872119875119862119894119862119878)

are received in the dataset and associated with 119880119875119862119878119862119894and 119872119875C119878

119862119894 At this point RAMHU applied multiple

pseudonyms among model entities (119862119894 119862119878 and 119860119878)to prevent traceability in linking the real informationof the user with pseudonyms

(iv) 119862119894 calculates the value of the signature 1198621198941198781198941198923 =

ℎ(119879119878119862119878 119873C119878 119880119875119862119894119862119878 119872119875

119862119894119862119878) for login re-

sponse information It compares the result of thecomputed signature (1198621198941198781198941198923) and the value of thereceived signature (1198621198781198781198941198925 ) If the signature values areidentical namely the login response information isunmodified or not tamperedwith119862119894 accepts the loginresponse otherwise 119862119894 discards the login responseThen119862119894 hides its private key by 119862119894119870119901119903119894 oplus119866119872oplus119875119882119894 oplus119873119862119894 after generating a random nonce to prevent thedetection of the private key if the device is hackedAt this point if all processes are achieved correctlythen all requests are considered legitimate and reli-able through the implementation of mutual authenti-cation

434 Password Update Protocol Updating the password isa security procedure to ensure authentication of legitimate

users The process of changing 119875119882119894 is important in any HCsystem for two reasons First it prevents the use of 119875119882119894fixed for a long time which reduces the guessing attacksSecond changing119875119882119894 gives usersmore flexibility in choosingthe appropriate 119875119882119894 This process requires strict securitymeasures to protect the new 119875119882119894 RAMHU provides thelegitimate user with amechanism to change hisher passwordat any time If the user wants to change hisher 119875119882119894the following illustration describes the new 119875119882119894 protectionprocedures in a secure manner (Figure 6 shows the passwordupdate protocol in RAMHU)

(i) 119862119894 side 119862119894 enters 119880119868119863119894 119872119868119863119894 the old 119875119882119894 andthe new 119875119882119894 It replaces 119880119868119863119894 and 119872119868119863119894 withpseudonyms to hide the userrsquos real information 119862119894calls the MAC address and then extracts the privatekey from 119905119898119901119862119894119870119901119903119894oplus119866119872oplus119900119897119889119875119882119894oplus119873119862119894 to use in theencryption process of the password update request119862119894generates three random nonces (1198731198621 1198731198622 and 1198731198623)and computes a new timestamp (119879119878119862119894) 119862119894 computesthe signature value (1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)) by PHOTON-256 basedon the parameters of the password change requestIt applies an anonymity mechanism to the old 119875119882119894and new 119875119882119894 (119905119898119901 119900119897119889119875119882119894 = 119900119897119889119875119882119894 oplus1198731198622 oplus 1198621198941198781198941198921and 119905119898119901 119899119890119908119875119882119894 = 119899119890119908119875119882119894 oplus 1198731198623 oplus 1198621198941198781198941198921) to hidepasswords and not explicitly send them in the 119875119882119894change request It encrypts the 119875119882119894 change request(119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) and sends itto 119862119878 119862119894 then hides its private key by 119862119894119870119901119903119894 oplus 119866119872oplus119899119890119908119875119882119894 oplus 119873119862119894

(ii) 119862119878 side 119862119878 receives and decrypts a password updaterequest (119864119899119888119894) It examines the timestamp to preventdelayed requests and examines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 indatasets 119862119878 extracts the old 119875119882119894 and new 119875119882119894 from119905119898119901 119900119897119889119875119882119894 oplus 1198731198622 oplus 1198621198941198781198941198921 and 119905119898119901 119899119890119908119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 Then it computes the signature value(1198621198781198781198941198921) depending on 119879119878119862119894 1198731198621 119880119875

119862119878119862119894 119872119875119862119878119862119894 and

119900119897119889119875119882119894 to check the matching between 1198621198781198781198941198921 and1198621198941198781198941198921 Similarly in the authentication protocol 119862119878computes 119879119878119862119878 and replaces pseudonyms 119862119878 gener-ates three nonces 1198731198621198781 1198731198621198782 and 1198731198621198783 and then 119862119878computes the signature value (ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119900119897119889119875119882119894)) and hides the old119875119882119894 and new119875119882119894by 119900119897119889119875119882119894 oplus 1198731198621198782 oplus 1198621198781198781198941198922 and 119899119890119908119875119882119894 oplus 1198731198621198783 oplus1198621198781198781198941198922 It encrypts the password update request withsecurity parameters (119879119878119862119878 1198731198621198781 1198731198621198782 1198731198621198783 119880119875

119860119878119862119878

119872119875119860119878119862119878 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 and 1198621198781198781198941198922) andsends to 119860119878

(iii) 119860119878 side 119860119878 receives the password update requestand decrypts (119864119899119888119894) this request with 119860119878119870119901119903119894 and119862119878119870119901119906119894 It checks time delay and then it checkslink pseudonyms with real information for users Itextracts the old119875119882119894 from 119905119898119901 119900119897119889119875119882119894oplus1198731198621198782oplus1198621198781198781198941198922and then it checks the old 119875119882119894 in the dataset It com-putes the signature value 1198601198781198781198941198921 = ℎ(119879119878119862119878 1198731198621198781

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 13: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Security and Communication Networks 13

CS AS

Figure 6 Password update protocol

119880119875119860119878119862119878 119872119875119860119878119862119878 119900119897119889119875119882119894) and then it comparesthe calculated result (1198601198781198781198941198921) with the result of thereceived signature (1198621198781198781198941198922) If they are identical thesignature is true otherwise119860119878 rejects the119875119882119894 changerequest 119860119878 performs the calculation 119905119898119901 119899119890119908119875119882119894 oplus1198731198621198783 oplus 1198621198781198781198941198922 to obtain the new 119875119882119894 value If allprevious checks are validated119860119878 changes the old119875119882119894to the new 119875119882119894

435 Revocation Protocol Revocation in HC applications isused when a user finishes a task or to prevent attack Thisprotocol can be completed by 119862119894 or 119860119878 For example 119862119894wants to cancel hisher account from the HC system aftercompleting hisher duties such as a research doctor who usesthe system for a limited period and then cancels his accountafter the completion of his duties Additionally119860119878 can revokethe account of any user who performs suspicious activities

(internal attacks) that are not within hisher privileges suchas a nurse who wants to access the personal informationof a particular doctor or patient Furthermore the user canrequest from the authorities provider (119860119878) to revoke hisheraccount information that is associated with hisher data (notethat the patientsrsquo data history remains stored in the 119863119878even after the completion of the revocation protocol) Theprotocol of revocation is extremely important in restrictingthe malicious activities of HC systems RAMHU includes arevocation protocol to provide strict security procedures inprotecting usersrsquo authentication information (Figure 7 showsthe revocation protocol in the 119862119894 side in RAMHU)

Revocation from 119862119894 Side

(i) 119862119894 enters 119880119868119863119894 119872119868119863119894 and 119875119882119894 and then replaces119880119868119863119894 with 119880119875119862119878119862119894 and 119872119868119863119894 with 119872119875119862119878119862119894 It chooses

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 14: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

14 Security and Communication Networks

CS AS

Figure 7 Revocation protocol

the revocation reason (119877119877119894) from the drop-down list(such as ending the researcherrsquos study ending a satis-factory condition resigning a professional changinga health institution and the unwillingness of a patientto use the system) These reasons have converted tosignatures using PHOTON to get MDs with 256 bitsin the dataset 119862119894 computes the new 119879119878119862119894 1198731198621 1198731198622 and1198731198623 Then119862119894 performs the process of119877119877119894oplus1198731198621 toadd randomness for 119877119877119894 Using this procedure is veryuseful in tightening security and distinguishing theroles of users (patients or professionals) in119862119878 It com-putes the signature 1198621198941198781198941198921 = ℎ(119879119878119862119894 1198731198621 119880119875

119862119878119862119894

119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo) 119862119894 performs a com-putation to hide 119877119877119894 (119905119898119901119877119877119894 = 119877119877119894 oplus1198731198622 oplus1198621198941198781198941198921)119862119894 computes the temporary 119875119882119894 value of 119875119882119894 oplus1198731198623 oplus 1198621198941198781198941198921 to hide the 119875119882119894 value Additionally itcomputes encryption (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119877119877119894 119905119898119901119875119882119894 1198621198941198781198941198921))and sends a revocation request to 119862119878 Then it hidesa private key in the same way in the password updateprotocol

(ii) 119862119878 decrypts (119864119899119888119894) and computes the timestamp andexamines 119880119875119862119878119862119894 and 119872119875119862119878119862119894 in the datasets It obtains

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 15: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Security and Communication Networks 15

119877119877119894 from the computation equation 119877119877119894 = 119905119898119901119877119877119894 oplus1198731198622 oplus 1198621198781198781198941198921 It extracts 119875119882119894 from 119905119898119901119875119882119894 oplus 1198731198623 oplus1198621198941198781198941198921 and checks 119875119882119894 matching in the dataset 119862119878computes the signature (1198621198781198781198941198921 = ℎ(119879119878119862119894 1198731198621

119880119875119862119878119862119894 119872119875119862119878119862119894 119877119877119894 119875119882119894 ldquodeleterdquo)) and thencompares the results of the signatures 119862119878 computesoperation 119877119877119894 oplus 1198731198621 to use 119877119877119894rsquos signature in orderto compare 119877119877119894 with the userrsquos 119877119894 If all operations areachieved and validated correctly119862119878 sends a request to119860119878 to check the pseudonymrsquos association with the realinformation and check 119875119882119894 119860119878 deletes associationbetween pseudonyms and information and delete theuserrsquos119875119882119894 from the dataset 119860119878 sends aMAC deletionrequest to 119862119878 Upon receiving the MAC deletionrequest 119862119878 decrypts this request and then checkssecurity parameters and signature If all operationsare achieved and validated correctly 119862119878 deletes theMAC address from the dataset At this point thisuser cannot perform an authentication process inRAMHU

Revocation from 119860119878 Side

(i) 119860119878 deletes the association between userrsquos informationand pseudonyms and 119875119882119894 in datasets It sends anencrypted request (119864119899119888119894) to 119862119878 to delete the devicersquosMAC address for this user After the completion ofthis protocol the user is considered illegal and cannotaccess HC services

5 Security Analysis

In this section a theoretical and an experimental securityanalysis have been presented We describe how RAMHUapplies security requirements in protecting usersrsquo authenti-cation information in the HC system

51 Theoretical Security Analysis The theoretical securityanalysis shows that RAMHU is secure against the variousknown attacks In this section we will show how RAMHUprovides a high-security level against these attacks by provid-ing assumptions and proofs Table 4 summarises the compar-ison between RAMHU and other authentication protocols inresistance against various attacks

(i) RAMHU prevents a privileged insider attackProof 1The internal intruder (119868119868) needs to eavesdropon authentication requests between 119862119894 and 119862119878 Afterthat heshe tries to perform an analysis of theserequests based on hisher access privileges to thenetwork First the analysis of these requests to obtainthe private key or password is infeasible because theauthentication request is encrypted by the ECIES-256-bit algorithm 119868119868 cannot decrypt these requestswith hisher private key Second if 119868119868 broke theencryption (which is impossible) heshe is unable toextract the 119875119882119894 value (119905119898119901119875119882119894 = 119875119882119894 oplus119873119862119894 oplus 119866119872oplus1198621198941198781198941198921) in the login protocol because it is hidden and

depends on the values of 119866119872 1198621198941198781198941198921 and119873119862119894 where119868119868 does not know the 119866119872 value of the legitimateuserrsquos device and the1198621198941198781198941198921 value depends on the119862119872value that is also not known to 119868119868Therefore RAMHUprevents a privileged insider attack

(ii) RAMHU is resistant to a stealing attackProof 2 In the first case the intruder (119868) stealsa legitimate userrsquos device (such as a laptop) thatcontains a client application In our scheme the userrsquos119875119882119894 and 119868119863119904 are not stored on the userrsquos device or inthe client application In addition the private key ishidden and random for each authentication processby 119862119894119870119901119903119894 oplus 119866119872 oplus 119875119882119894 oplus 119873119862119894 Additionally Proof 1shows that the 119875119882119894 value cannot be extracted from119905119898119901119875119882119894 If 119868 is 119868119868 heshe also cannot use hisher119868119863119904 and 119875119882119894 to access information or other user databecause both 119862119878 and 119860119878 perform matching 119868119863119904 and119875119882119894 to determine user-related information and dataIn the second case the attacker steals only the clientapplication 119868 cannot use the application on anotherdevice because it does not have 119874119879119875119894 or the originalMACwhich prevents the application frombeing usedon another device even if 119868 knows the 119868119863119904 and 119875119882119894The original MAC mechanism (1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894)) prevents the fake authentication requestfrom being verified in the server because 119868 cannotgenerate an original MAC address (119862119872) in 1198621198941198781198941198921Thus RAMHU is resistant to a stealing attack

(iii) RAMHU resists replay attackProof 3 119868 tries to get a loginregistrationauthenti-cation request for a legitimate user to send it later andthus gains access to the networkThis case is infeasiblein our scheme because all entities (119862119894 119862119878 and 119860119878)use a timestamp (such as 119879119878119862119878 minus 119879119878119862119894 le 998779119879 where998779119879 is the maximum transfer delay rate) that preventsthe attacker from sending the authentication requestat a later time Furthermore signatures and randomnonces are not usable the next times Hence RAMHUsuccessfully resists replay attack

(iv) RAMHU overcomes the MITM attackProof 4 Assume that an 119868 attempts to interceptencrypted loginauthentication requests (such as119864119899119888119894(119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862i 119872119875119862119878119862119894

119905119898119901119875119882119894 1198621198941198781198941198922)) among network entities andthen modifies or replaces these requests with hishermessages to send to network entities However theattacker cannot replace exchanged requests among119862119894 119862119878 and 119860119878 because first heshe does notknow the private keys (119862119894119870119901119903119894 119862119878119870119901119903119894 119860119878119870119901119903119894) andtherefore the decryption process is computation-ally infeasible with 256-bit key length and difficultyin solving ECDLP Second mutual authenticationwith PHOTON-256 signatures prevents the modi-fication of requests between RAMHUrsquos entities Asa result RAMHU gracefully overcomes the MITMattack

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 16: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

16 Security and Communication Networks

Table4Com

paris

onof

resistanceinrepelling

thethreatsbetweenRA

MHUandexistingschemes

Attack

Hee

tal[1]Giri

etal[17]Li

etal[6]

Farash

etal[23]Ku

mar

etal[24]Jia

ngetal[25]Ra

jput

etal[7]

Das

etal[5]

Chandrakar

etal[19]RA

MHUscheme

Privilegedinsid

er

Stolen

deviceapp

lication

Re

play

MITM

Guessing

Client

imperson

ation

Server

imperson

ation

DoS

Change

passwo

rd

Ea

vesdropp

ing

Traceability

Revocatio

n

Verifi

er

Leakage

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 17: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Security and Communication Networks 17

(v) RAMHU is safe against guessing attackProof 5 Assume that an external intruder (119864119868) wasable to penetrate the encryption (119864119899119888119894) between 119862119894and 119862119878 (from Proof 4 this assumption is infeasible)This 119864119868 tries to guess 119875119882119894 in a login request to use itto access the network as a legitimate user 119864119868 cannotdetect 119875119882119894 for any authorised user (either on-line oroff-line) because heshe does not know the configuredprocess to protect 119875119882119894 (119905119898119901119875119882119894 = 119875119882119894 oplus 119873119862119894 oplus119866119872 oplus 1198621198941198781198941198921) and does not know the MAC addressfor that user and thus the process of deriving 119875119882119894is infeasible (Proof 1) It is an extremely difficultprocess to guess119875119882119894 from 119905119898119901119875119882119894 which is 64 hexes(256 bits) In addition 119864119868 cannot detect 119880119868119863119894 and119872119868119863119894 for any legitimate user because of the use ofthe multiple-pseudonym mechanism for users andmedical centres instead of sending real information tolegitimate users As a result RAMHU is safe againstguessing attack

(vi) RAMHU withstands client impersonation attackProof 6 Assume that an attacker tries to impersonatea login request (such as 119864119899119888119894 = 119879119878119862119894 119873119862119894 1198621198941198781198941198921 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901119875119882119894 1198621198941198781198941198922) for a legitimateuserThis 119868 can create119879119878119862119894 and119873119862119894 but does not know119875119882119894 and 119862119894119870119901119903119894 (Proofs 1 and 4) for the legitimateuser namely 119868 cannot impersonate the user identity119868 also tries to impersonate the legitimate userrsquos deviceby programmatically changing the MAC address to alegitimate one to gain access to the networkThis caseis infeasible because the original MAC check (119862119872) in1198621198941198781198941198921 = ℎ(119862119872 119873119862119894 119879119878119862119894) detects the attackerrsquosattempt to mimic the legitimate userrsquos device (as inProof 2)Therefore RAMHU withstands instances ofimpersonating the userrsquos identity and device

(vii) RAMHU resists server impersonation attackProof 7 Assume that an 119868 traps login requests from119862119894 to 119862119878 The attacker tries to deceive 119862119894 by sendingfake requests to 119862119894 in order to inform them that heis a legitimate server 119868 needs the private key forCS to decrypt and to accomplish the attack Mutualauthentication prevents 119868 from impersonating 119862119878rsquosrequests (such as 119864119899119888119894(119879119878119862119878 119873119862119878 119880119875

119862119894119862119878

119872119875119862119894119862119878

1198621198781198781198941198925)) and sending them to 119862119894 This mechanismensures that 119862119894 deals with legitimate 119862119878 Conse-quently our protocol effectively resists server imper-sonation attack

(viii) RAMHU resists DoS attackProof 8 In order for 119868 to execute a DoS attack against119862119878 and 119860119878 heshe needs to decrypt the login requestand change its data or send the same request multipletimes for destroying serversHowever in the first casedecryption and change of signatures are infeasibleas in Proofs 2 and 4 119862119878 checks signature validityand rejects login requests containing fake signaturesand 119868 cannot execute a collision or preimage attackbecause PHOTON-256 supplies PR SPR and CR In

the second case the attacker sends the same requestmultiple times This status is infeasible because CSor AS checks the timestamp (119879119878119862119894 119879119878119862119878 119879119878119860119878) foreach loginauthentication request and eliminates alllate requests (Proof 3) without checking the othersecurity parameters such as 119875119882119894 119862119872 and multiplepseudonyms In case 119868 can break the encryptionheshe can change the timestamp and nonce butcannot tamper with the signatures RAMHUpreventsthis condition during 1198621198941198781198941198921 and does not need tocheck the remaining security parameters ThereforeRAMHU successfully resists DoS attack

(ix) RAMHU is secure against password change attackProof 9 Assume that an 119868 intercepts a requestto change 119875119882119894 between 119862119894 and 119862119878 119868 obtainsan encrypted password update request (such as119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875

119862119878119862119894

119872119875119862119878119862119894

119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894 1198621198941198781198941198921)) If 119868 candecrypt it (this process is infeasible as in Proofs 1and 4) heshe will find a temporary password andcannot derive a new119875119882119894 because it depends on1198621198941198781198941198921= ℎ(119879119878119862119894 1198731198621 119880119875119862119878119862119894 119872119875119862119878119862119894 119900119897119889119875119882119894)The signature operation (1198621198941198781198941198921) is based on theold 119875119882119894 which is not explicitly sent to 119862119878 in thisprotocol 119868 does not know the old 119875119882119894 and thereforeheshe cannot create a signature to complete the119875119882119894 change process Thereupon RAMHU providesa reliable solution against password change attack

(x) RAMHU is resistant to eavesdropping attackProof 10 Assume that an 119868 eavesdrops on loginau-thentication requests to gain information about userauthentication and access to the network Howeverin our scheme 119868 will not benefit from requests thatare intercepted because RAMHU uses the ECIESalgorithm with a 256-bit key to encrypt authenti-cation information The attacker can only decryptrequests by deriving private keys and this operationis infeasible (as in Proofs 1 and 2) due to key lengthand random encryption with nonces (anonymity)Therefore our protocol is resistant to eavesdroppingattack

(xi) RAMHU resists traceability attackProof 11 119868 attempts to collect as many loginauthen-tication requests as possible and then performs ananalysis of those requests that helps himher toperform user identity tracing When an 119868 succeedsin tracking user requests heshe can detect and dis-tinguish patientsrsquo data All exchanged requests amongRAMHUrsquos entities do not contain direct usersrsquo infor-mation (such as username) RAMHUreplaces the realuser 119868119863119904 (119880119868119863119894 and 119872119868119863119894) with pseudonyms Ourprotocol uses multiple pseudonyms (119880119875119862119878119862119894 119880119875

119860119878119862119878

119880119875119862119878119860119878 and 119880119875119862119894119862119878 for users and 119872119875119862119878119862119894 119872119875119860119878119862119878 119872119875119862119878119860119878

and 119872119875119862119894119862119878

for medical centres) to prevent attackersfrom tracking user requests and revealing their iden-tities when they are transferred between RAMHU

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 18: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

18 Security and Communication Networks

entities (119862119894 119862119878 and 119860119878) Hence RAMHU resiststraceability attack

(xii) RAMHU prevents revocation attackProof 12 Assume that an 119868 tries to penetrate arevocation request The attacker tries to analyse therequest and use it to prevent users from accessingthe networkrsquos services Depending on Proofs 1 5 and11 the attacker cannot extract or distinguish 119880119868119863119894119872119868119863119894 and 119875119882119894 from the revocation request Theattacker does not know and cannot extract a reasonfrom 119905119898119901119877119877119894 which is based on the values of 1198771198771198941198731198622 and 1198621198941198781198941198921 In Proofs 2 and 8 119868 cannot performcollision preimage and second preimage attacksagainst the PHOTON-256 algorithm Thus our pro-tocol prevents penetration of revocation request

(xiii) RAMHU resists verifier attackProof 13 Assume that 119868 tries to penetrate the datasetsin 119862119878 If the attacker is 119864119868 heshe cannot penetratedatasets because heshe does not have 119870119901119903 119880119868119863119872119868119863 119874119879119875 and 119875119882119894 If the attacker is 119868119868 when hepenetrates datasets in 119862119878 and wants to impersonateanother userrsquos identity first heshe cannot distinguishthis information for a particular user because the realinformation for users is stored in119860119878 Second since119862119878does not contain passwordsrsquo dataset 119868119868 will not ben-efit from hacking datasets such as pseudonyms andcannot create a request and send it to 119860119878 because itdoes not know usersrsquo passwords Therefore RAMHUresists verifier attack meritoriously

(xiv) RAMHU resists leakage attackProof 14 Suppose that 119868 listens to some exchangedrequests among 119862119894 119862119878 and 119860119878 and tries to find anyinformation that helps himher to penetrate networkauthentication such as sending an ID explicitly orsending a passwordwithweak encryption Exchangedrequests between RAMHU entities such as a pass-word update request (119864119899119888119894(119879119878119862119894 1198731198621 1198731198622 1198731198623 119880119875119862119878119862119894 119872119875119862119878119862119894 119905119898119901 119900119897119889119875119882119894 119905119898119901 119899119890119908119875119882119894

1198621198941198781198941198921)) show that 119868 does not receive any leakedreal information for users during transmission suchas 119868119863119904 and 119875119882119894 (all information is anonymous andhidden) that could be useful in penetrating the HCnetwork Therefore RAMHU resists leakage attack

52 Experimental Security Analysis To ensure that authenti-cation schemes work correctly and are authenticated theseschemes require a formal tool to detect the robustness ofusersrsquo authentication in the network We provide the pro-posed scheme simulation using the AVISPA tool to verify ourscheme whether safe or unsafe Our simulations are based onthe AVISPA tool with the current version v11 (13022006)available on the website in [58] This tool has been widelyused and accepted by researchers in recent years [59 60] Ithas been used to check security problems and ensure thatknown attacks are not able to penetrate usersrsquo authenticationinformation

521 AVISPA Description After designing any authenti-cation protocol this protocol should be checked and itsaccuracy verified under a test model such as the Dolev-Yao(dy) to analyse trace and detect the possibility of attacktheoretically However this analysis needs to be simulatedin a practical manner to detect errors and hidden traces ofthe authentication protocol designer statistics and accurateresults checking several techniques on the same protocolThe AVISPA tool provides the features listed above as wellas the ease robustness and applicability of this tool toimplement authentication protocols [61]

The AVISPA tool is a push-button testingproofingmodel and is based on the HLPSL language This languageuses directives and expressive terms to represent securityprocedures It is integrated with four backends that are theOn-the-Fly Model-Checker (OFMC) the Constraint-Logic-based Attack Searcher (CL-AtSe) the SAT-based Model-Checker (SATMC) and Tree Automata based on Auto-matic Approximations for the Analysis of Security Protocols(TA4SP) to perform the simulation in AVISPA Each backendgives the result of simulation analysis statistics that is differentfrom the other [58] The SATMC and TA4SP backendsdo not work with a security protocol that implements theXOR gateway therefore we relied on the OFMC and CL-AtSe backends to simulate RAMHU To implement theauthentication protocol in AVISPA this protocol shouldbe first written in HLPSL and then converts to the low-level language The latter is read directly by the backendswhich is an intermediate format (IF) by the hlpsl2if compilerThen it converts to an output format (OF) to extract anddescribe the result of analysis by one of four backends Theresult of the analysis accurately describes that the protocolis safe or not safe with some statistical numbers HLPSLis modular and role-oriented This language allows thecompletion of authentication protocol procedures as wellas intruder actions To represent authentication scenariosand build simulation structures HLPSL uses roles includingbasic roles such as clients and servers (clients centralServerand attributesServer) and composition (session and envi-ronment) roles that control the sequence of sending andreceiving actions between clients and servers In additioncommunication channels between network entities are gov-erned by the dy model Many basic types are used in HLPSLto represent variables constants and algorithms (symmet-ricasymmetrichash) such as agent public key messagetext nat const and hash func in addition to some symbolsand terms that have been shown in Table 5 more detailsare provided in [58] The authentication protocol in AVISPAdepends on security features in the goal specification Eachprotocol contains a set of goals (authentication and secret)in authenticating each party with the other The goals insecrecy of demonstrate that secrets are not exposed or hackedto nonintended entities while the goals in authentication ondemonstrate that strong authentication has been appliedbetween entities based on witness and request

522 Proposed Scheme with AVISPA In this section we willillustrate the simulation of RAMHU in the AVISPA tool

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 19: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Security and Communication Networks 19

Table 5 Some HLSPLrsquos symbols and statements

Symbol Description Concatenation 119870119901 Asymmetric encryption with public key119901119897119886119910119890119889 119887119910 Used to link the role with the intended entity= | gt Reaction transitions to relate event with act Conjunction119901119903119900119905119900119888119900119897 119894119889 Goal identifier119904119890119888119903119890119888119910 119900119891 The goal of protecting the secret between entities permanently119886119906119905ℎ119890119899119905119894119888119886119905119894119900119899 119900119899 The goal of strong authentication between entities119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890 What intruder knows about network

using the HLPSL language Our scheme depends on threecore roles clienti centralServer and attributesServer playedby 119862119894 119862119878 and 119860119878 respectively In addition it includes thesupporting roles such as session environment and goal spec-ification section Each role contains parameters variablesand local constants Each basic role contains a transitionsection that indicates the sequence of communication amongentities Each supporting role contains a composition sectionthat indicates the binding of roles and sessions Asymmetricencryption has been implemented between scheme entities(119862119894 119862119878 and 119860119878) during public key exchange (119870119862119901119906 119870119862119878119901119906and 119870119860119878119901119906) to perform confidentiality Moreover mutualauthentication has been used to ensure the legitimacy ofrelated parties in the protocols of the proposed scheme (initialsetup registration login and authentication) Moreover ituses nonces (119873119888 119873119888119904 and 119873119886119904) and a timestamp (119879119878119888 119879119878119888119904119879119878119886119904) to support the features of anonymity and freshness Ourscheme accomplishes 10 secrecy goals and 6 authenticationgoals as noted in the goal section in Figure 11

The authentication process begins by sending requestsfrom clients to the server Therefore the 119888119897119894119890119899119905119894 role includesthe start signal as shown in Figure 8 119862119894 receives the startsignal and changes the state flag (state variable) from 0 to 1 Itreplaces 119880119868119863 and119872119868119863 with 119880119875119888 and119872119875119888 and calculates thetimestamp (1198791198781015840119888) and new nonce (1198731015840119888) by the new() operationAfter that it computes the signatures (1198621198941198781198941198921 and 1198621198941198781198941198922)as well as the password hiding process as calculated in thecomputation operation of the119879119898119901119875119882 parameter It encryptsthe registration and login request (1198791198781015840119888 119873

1015840119888 119866119872

1015840 11986211989411987811989411989210158401

1198801198751015840119888 1198721198751015840119888 119874119879119875119894 119879119898119901 1198751198821015840 and 11986211989411987811989411989210158402) by the public key

(119870119862119878119901119906) to establish a reliable communication with 119862119878 119862119894sends the request to 119862119878 where the transmission process isperformed by the SND() operation It achieves a set of secretgoals (1199041198901198881 to 1199041198901198886) with both 119862119878 and 119860119878 these secretshave been only known and kept by the intended parties Forinstance in 1199041198901198881 119880119868119863119872119868119863 and 119875119882 have been known andkept only to 119862119894 and 119860119878 while in 1199041198901198883119866119872 and 119862119872 have beenknown and kept only to119862119894 and119862119878 since these parameters arenot transmitted directly during the transition of informationbetween network parties for example 119875119882 implicitly is inthe computation of 119879119898119901119875119882 and 119862119872 is implicitly in 1198621198941198781198941198921119862119894 also achieves the goal of authentication using statement(witness) with parameters (119862119894 119862119878 119888119894 119888119904 119886119906119905ℎ2 119873119888119904 119879119878119888)Namely 119862119894 is a witness that the security parameters (119873119888119904

119879119878119888) are fresh and correct 119862119878 uses a statement (request)to validate parameters with the strong authentication goal(119888119894 119888119904 119886119906119905ℎ2) specified in the goal section (Figure 12) 119862119894receives the authentication response by the RCV () operationsent from 119860119878 by 119862119878 Then 119862119894 decrypts the response using itsprivate key to verify the security parameters If all securityparameters are verified correctly 119862119894 performs the mutualauthentication process securely

As shown in Figure 9 119862119878 receives a registration andlogin request by the RCV () operation in state 0 Itdecrypts the request with its private key and then checksthe parameters and signatures to accomplish secret andauthentication goals CS changes the state signal from 0to 1 and constructs an authentication request based on thesecurity parameters (1198791198781015840119888119904 119873

1015840119888119904 119880119875119888119904 119872119875119888119904 1198621198781198781198941198923 and

119879119898119901119875119882) and encrypts it by the public key of 119860119878 119862119878performs strong authentication with 119860119878 during witness (119862119878119860119878 119886119904 119888119904 119886119906119905ℎ4 1198791198781015840119888119904119873

1015840119888119904) to accomplish the authentication

goal (119886119904 119888119904 119886119906119905ℎ4) based on the timestamp and fresh nonceand validated in 119860119878 by statement (request) In state 1 119862119878receives an authentication response from 119860119878 and checks thesecurity parameters after decryption with its private keyIt changes the state signal to 2 and then constructs theauthentication response to 119862119894 119862119878 sends response with twostrong authentication goals (119888119904 119888119894 119886119906119905ℎ1 and 119888119904 119888119894 119886119906119905ℎ5)based on the security parameters (119873119888 119879119878119888119904 119879119898119901119875119882 and119874119879119875119894)

119860119878 receives the authentication request and decrypts itwith the private key as shown in Figure 10 It accomplishes5 secret goals and accomplishes two authentication goals(119886119904 119888119904 119886119906119905ℎ4 and 119886119904 119888119904 119886119906119905ℎ6) based on 1198791198781015840119888119904119873

1015840119888119904 and 119875119882

1015840It constructs the authentication response and establishesstrong authentication when validating parameters (119879119878119886119904119873

1015840119888119904

and 1198751198821015840) in 119862119878 Figure 11 displays the roles of sessionenvironment and goal section In the session role a compo-sition process has been performed for the three roles (119888119897119894119890119899119905119894119888119890119899119905119903119886119897119878119890119903V119890119903 and 119886119905119905119903119894119887119906119905119890119878119890119903V119890119903) This role specifies thetransmit and receive channels in the dy model In the envi-ronment role the security parameters the goals specified inthe goal section and the known information for the intruder(119894119899119905119903119906119889119890119903 119896119899119900119908119897119890119889119892119890) have been defined In this role oneor more sessions are composed We tested our scheme withsessions for replay MITM and impersonating attacks Weassumed that an intruder (119868) creates a public key (119896119894) and

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 20: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

20 Security and Communication Networks

Figure 8 Client role in HLPSL

has knowledge of the public keys (119896119862119901119906 119896119862119878119901119906 and 119896119860119878119901119906)of legitimate entities in the network The intruder attemptsto resend the registrationlogin or authentication requestslater interceptmodify these requests or impersonate theparticipating entities using 119894 119888119894 119894 119888119904 and 119894 119886119904 constantsrather than 119888119894 119888119904 and 119886119904 The results section shows thatthese attacks cannot penetrate the security goals in ourscheme

523 Simulation Results In this section the simulationresults in the AVISPA tool are based on two backends (OFMCand CL-AtSe) Figure 12 shows the simulation result withthe OFMC backend and Figure 13 displays the simulation

result with the CL-AtSe backend From the results shownin Figures 12 and 13 our scheme clearly and accuratelyshows the SAFE result in the SUMMARY section boundednumber of sessions in the DETAILS section the goals ofthe scheme achieved (as specified) in the GOAL sectionand statistical numbers such as time number of nodesand analysed states in the STATISTICS section for bothfigures Based on these results we note that our schemeis capable of preventing passive and active attacks such asreplay MITM and impersonating Thus the goals of thescheme in Figure 11 are achieved to prevent the violationof legitimate user information in the network authentica-tion

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 21: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Security and Communication Networks 21

Figure 9 Central server role in HLPSL

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 22: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

22 Security and Communication Networks

Figure 10 Attributes server role in HLPSL

6 Conclusion and Future Work

In this paper we found that existing healthcare applicationswere vulnerable toweak security against some known attacksTowards this end we proposed a new robust authenticationprotocol (RAMHU) to prevent internal external passiveand active attacks Our scheme uses multiple pseudonymsfor both users and medical centres to prevent the trans-mission of real information in the authentication requestand a MAC address to prevent counterfeit devices fromconnecting to the network The lightweight encryption andsignature algorithms (as described in Section 3) are usedto ensure that RAMHUrsquos efficient interaction with userrequests is guaranteed In addition we provided formaland informal security analysis to demonstrate the effective-ness of RAMHU in repelling known attacks The RAMHUscheme provides high-level security that maintains authenti-cation information for users against various attacks Future

directions for furthering the development of this scheme areas follows

(1) RAMHU requires strong authorisation to supportpatient data exchange after user authenticationWe need a mechanism that supports role-basedand attribute-based privileges (eg doctor nursepatient advisor researcher and emergency) to accesspatientsrsquo data on a data server (119863119878) We intend touse authorisation policies with signatures to ensureproper authorisation of access to the data repos-itory

(2) Our scheme uses lightweight and efficient perform-ance algorithms that according to many researchershave shown that ECIES and PHOTON are efficientencryption and signature algorithms respectivelyWe intend to evaluate RAMHU in terms of effi-ciency and discovery of performance standards such

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 23: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Security and Communication Networks 23

Figure 11 Supporting roles in HLPSL

as end-to-end request delay throughput and errorrate

(3) We intend to use the wireless sensor network (WSN)to collect patientsrsquo data and send it to 119863119878 Howevercollecting and storing data in 119863119878 requires the use ofencryption and signature algorithms against knownattacks

Data Availability

No data were used to support this study

Disclosure

This research did not receive specific funding but was per-formed as part of the employment of the authors

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 24: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

24 Security and Communication Networks

Figure 12 Simulation result using OFMC

Figure 13 Simulation result using CL-AtSe

Conflicts of Interest

The authors declare that they have no conflicts of interest

References

[1] D He and S Zeadally ldquoAuthentication protocol for an ambientassisted living systemrdquo IEEE CommunicationsMagazine vol 53no 1 pp 71ndash77 2015

[2] W Sun Z Cai Y Li F Liu S Fang and G Wang ldquoSecurityand privacy in the medical internet of things a reviewrdquo Securityand Communication Networks vol 2018 Article ID 5978636 9pages 2018

[3] S J Tipton S Forkey and Y B Choi ldquoToward proper authen-tication methods in electronic medical record access compliantto HIPAA and CIA trianglerdquo Journal of Medical Systems vol40 no 4 pp 1ndash8 2016

[4] HArshad V TeymooriMNikooghadam andHAbbassi ldquoOnthe security of a two-factor authentication and key agreement

scheme for telecare medicine information systemsrdquo Journal ofMedical Systems vol 39 no 8 p 76 2015

[5] A K Das A K Sutrala V Odelu and A Goswami ldquoA securesmartcard-based anonymous user authentication scheme forhealthcare applications using wireless medical sensor net-worksrdquo Wireless Personal Communications vol 94 no 3 pp1899ndash1933 2017

[6] X Li J Niu S Kumari J Liao W Liang and M K Khan ldquoAnew authentication protocol for healthcare applications usingwirelessmedical sensor networkswith user anonymityrdquo Securityand Communication Networks vol 9 no 15 pp 2643ndash26552016

[7] U Rajput F Abbas J Wang H Eun and H Oh ldquoCACPPAa cloud-assisted conditional privacy preserving authenticationprotocol for vanetrdquo in Proceedings of the 16th IEEEACM Inter-national Symposium on Cluster Cloud and Grid ComputingCCGrid 2016 pp 434ndash442 Colombia May 2016

[8] Y Yuehong Y Zeng X Chen and Y Fan ldquoThe internetof things in healthcare an overviewrdquo Journal of IndustrialInformation Integration vol 1 pp 3ndash13 2016

[9] J Shen Z Gui S Ji J Shen H Tan and Y Tang ldquoCloud-aided lightweight certificateless authentication protocol withanonymity for wireless body area networksrdquo Journal of Networkand Computer Applications vol 106 pp 117ndash123 2018

[10] D He S Zeadally and L Wu ldquoCertificateless public auditingscheme for cloud-assisted wireless body area networksrdquo IEEESystems Journal vol 12 no 1 pp 64ndash73 2018

[11] M Wazid S Zeadally A K Das and V Odelu ldquoAnalysis ofsecurity protocols for mobile healthcarerdquo Journal of MedicalSystems vol 40 no 11 p 229 2016

[12] N M Shrestha A Alsadoon P Prasad L Hourany and AElchouemi ldquoEnhanced e-health framework for security andprivacy in healthcare systemrdquo in Proceedings of the 2016 SixthInternational Conference on Digital Information Processing andCommunications (ICDIPC) pp 75ndash79 Beirut Lebanon April2016

[13] P Paganini ldquoRisks and cyber threats to the healthcare indus-tryrdquo INFOSEC Institute Tech Rep 2014 httpresourcesinfosecinstitutecomrisks-cyber-threats-healthcare-industry

[14] ldquoData breach for apple health (medicaid) managed care planrdquoWashington State Health Care Authority Tech Rep 2016httpswwwhcawagovabout-hcaapple-health-medicaidda-ta-breach-apple-health-medicaid-managed-care-plan-what-cli-ents

[15] J Davis ldquoEhr server hack threatens data of 14 000 ivf clinicpatients healthcare IT Newsrdquo Tech Rep 2017 httpwwwhealthcareitnewscomnewsehr-server-hack-threatens-data-14000-ivf-clinic-patients

[16] G Manogaran R Varatharajan D Lopez P M Kumar RSundarasekar and C Thota ldquoA new architecture of Internetof Things and big data ecosystem for secured smart healthcaremonitoring and alerting systemrdquo Future Generation ComputerSystems vol 82 pp 375ndash387 2018

[17] D Giri T Maitra R Amin and P D Srivastava ldquoAn efficientand robust RSA-based remote user authentication for telecaremedical information systemsrdquo Journal of Medical Systems vol39 no 1 p 145 2015

[18] C-H Liu and Y-F Chung ldquoSecure user authentication schemeforwireless healthcare sensor networksrdquoComputers amp ElectricalEngineering vol 59 pp 250ndash261 2017

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 25: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

Security and Communication Networks 25

[19] P Chandrakar and H Om ldquoA secure and robust anonymousthree-factor remote user authentication scheme for multi-server environment using ECCrdquo Computer Communicationsvol 110 pp 26ndash34 2017

[20] S Al-Janabi I Al-ShourbajiM Shojafar and S ShamshirbandldquoSurvey of main challenges (security and privacy) in wirelessbody area networks for healthcare applicationsrdquo Egyptian Infor-matics Journal vol 18 no 2 pp 113ndash122 2016

[21] K-H Yeh ldquoA secure IoT-based healthcare system with bodysensor networksrdquo IEEE Access vol 4 pp 10288ndash10299 2016

[22] S K Shankar A S Tomar and G K Tak ldquoSecure medicaldata transmission by using ECC with mutual authentication inWSNsrdquo in Proceedings of the 4th International Conference onEco-friendly Computing and Communication Systems ICECCS2015 vol 70 pp 455ndash461 India December 2015

[23] M S Farash O Nawaz K Mahmood S A Chaudhry andM K Khan ldquoA provably secure RFID authentication protocolbased on elliptic curve for healthcare environmentsrdquo Journal ofMedical Systems vol 40 no 7 p 165 2016

[24] N Kumar K Kaur S C Misra and R Iqbal ldquoAn intelligentRFID-enabled authentication scheme for healthcare applica-tions in vehicular mobile cloudrdquo Peer-to-Peer Networking andApplications vol 9 no 5 pp 824ndash840 2016

[25] Q Jiang M K Khan X Lu J Ma and D He ldquoA privacypreserving three-factor authentication protocol for e-healthcloudsrdquoThe Journal of Supercomputing vol 72 no 10 pp 3826ndash3849 2016

[26] J Timpner D Schurmann and L Wolf ldquoTrustworthy parkingcommunities helping your neighbor to find a spacerdquo IEEETransactions on Dependable and Secure Computing vol 13 no1 pp 120ndash132 2016

[27] A Sojka-Piotrowska and P Langendoerfer ldquoShortening thesecurity parameters in lightweight WSN applications for IoT -Lessons learnedrdquo in Proceedings of the 2017 IEEE InternationalConference on Pervasive Computing andCommunicationsWork-shops PerCom Workshops 2017 pp 636ndash641 March 2017

[28] N Meddah A Jebrane and A Toumanari ldquoScalablelightweight ABAC scheme for secure sharing PHR in cloudcomputingrdquo in Proceedings of the International Conference onAdvanced Information Technology Services and Systems vol25 of Lecture Notes in Networks and Systems pp 333ndash346Springer 2017

[29] D Dolev and A C-C Yao ldquoOn the security of public keyprotocolsrdquo IEEETransactions on InformationTheory vol 29 no2 pp 198ndash208 1983

[30] T R Andel and A Yasinsac ldquoAdaptive threat modeling forsecureAdHoc routing protocolsrdquoElectronic Notes inTheoreticalComputer Science vol 197 no 2 pp 3ndash14 2008

[31] M Imran M Rashid and I Shafi ldquoLopez dahab based ellipticcrypto processor (ECP) over gf (2 163) for low-area applicationson FPGArdquo in Proceedings of the 2018 International Conferenceon Engineering and Emerging Technologies (ICEET) pp 1ndash6Lahore Pakistan Feburary 2018

[32] M B Rafik and F Mohammed ldquoThe impact of ECCrsquos scalarmultiplication on wireless sensor networksrdquo in Proceedings ofthe 2013 11th International Symposium on Programming andSystems (ISPS) pp 17ndash23 Algiers Algeria April 2013

[33] S Singh P K Sharma S Y Moon and J H Park ldquoAdvancedlightweight encryption algorithms for IoT devices surveychallenges and solutionsrdquo Journal of Ambient Intelligence andHumanized Computing pp 1ndash18 2017

[34] G Nabil K Naziha F Lamia and K Lotfi ldquoHardware imple-mentation of elliptic curve digital signature algorithm (ECDSA)on Koblitz curvesrdquo in Proceedings of the 2012 8th InternationalSymposium on Communication Systems Networks and DigitalSignal Processing CSNDSP 2012 pp 1ndash6 July 2012

[35] J Shen S Chang J Shen Q Liu and X Sun ldquoA lightweightmulti-layer authentication protocol for wireless body areanetworksrdquo Future Generation Computer Systems vol 78 pp956ndash963 2018

[36] E Barker and Q Dang ldquoNist special publication 800-57 part 1revision 4rdquo 2016

[37] R Harkanson and Y Kim ldquoApplications of elliptic curvecryptography a light introduction to elliptic curves and asurvey of their applicationsrdquo in Proceedings of the 12th AnnualConference on Cyber and Information Security Research pp 1ndash7April 2017

[38] P Porambage A Braeken C Schmitt A Gurtov M Ylianttilaand B Stiller ldquoGroup key establishment for secure multicastingin IoT-enabledWireless Sensor Networksrdquo in Proceedings of the2015 IEEE 40th Conference on Local Computer Networks (LCN)pp 482ndash485 Clearwater Beach FL October 2015

[39] N Nalla Anandakumar T Peyrin and A Poschmann ldquoA verycompact FPGA implementation of LED and PHOTONrdquo inProceedings of the International Conference in Cryptology inIndia vol 8885 pp 304ndash321 Springer 2014

[40] R Ijaz and M A Pasha ldquoArea-efficient and high-throughputhardware implementations of TAV-128 hash function forresource-constrained IoT devicesrdquo inProceedings of the 2017 9thIEEE International Conference on Intelligent Data Acquisitionand Advanced Computing Systems Technology and Applications(IDAACS) pp 832ndash835 Bucharest September 2017

[41] J Guo T Peyrin and A Poschmann ldquoThe photon fam-ily of lightweight hash functionsrdquo in Advances in Cryptol-ogymdashCRYPTO 2011 vol 6841 of Lecture Notes in ComputerScience pp 222ndash239 Springer Berlin Germany 2011

[42] A Bogdanov M Knezevic G Leander D Toz K Varıcıand I Verbauwhede ldquospongent a lightweight hash functionrdquoin International Workshop on Cryptographic Hardware andEmbedded Systems vol 6917 pp 312ndash325 Springer 2011

[43] T P Berger J DrsquoHayer K Marquet M Minier and GThomasldquoThe GLUON family a lightweight hash function family basedon FCSRsrdquo in Proceedings of the International Conference onCryptology in Africa vol 7374 pp 306ndash323 Springer 2012

[44] E B Kavun and T Yalcin ldquoA lightweight implementationof keccak hash function for radio-frequency identificationapplicationsrdquo in Proceedings of the International Workshop onRadio Frequency Identification Security and Privacy Issues vol6370 pp 258ndash269 Springer 2010

[45] H YoshidaDWatanabe KOkeya et al ldquoMame a compressionfunction with reduced hardware requirementsrdquo in Proceedingsof the International Workshop on Cryptographic Hardware andEmbedded Systems pp 148ndash165 Springer 2007

[46] J-P Aumasson L Henzen W Meier and M Naya-PlasencialdquoQuark a lightweight hashrdquo in Proceedings of the InternationalWorkshop on Cryptographic Hardware and Embedded Systemsvol 26 pp 1ndash15 Springer 2010

[47] M Naya-Plasencia and T Peyrin ldquoPractical Cryptanalysis ofARMADILLO2rdquo in Fast Software Encryption vol 7549 ofLecture Notes in Computer Science pp 146ndash162 Springer 2012

[48] M A Abdelraheem ldquoEstimating the probabilities of low-weight differential and linear approximations on PRESENT-like ciphersrdquo in Proceedings of the International Conference on

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 26: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

26 Security and Communication Networks

Information Security and Cryptology pp 368ndash382 Springer2012

[49] G Zhang andM Liu ldquoA distinguisher on present-like permuta-tions with application to spongentrdquo Science China InformationSciences vol 60 no 7 p 072101 2017

[50] C-M Chen W Fang K-H Wang and T-Y Wu ldquoCommentson ldquoAn improved secure and efficient password and chaos-based two-party key agreement protocolrdquordquo Nonlinear Dynam-ics vol 87 no 3 pp 2073ndash2075 2017

[51] J Martin T Mayberry C Donahue et al ldquoA study of MACaddress randomization in mobile devices and when it failsrdquoProceedings on Privacy Enhancing Technologies vol 2017 no 4pp 365ndash383 2017

[52] D M Ferrazani Mattos and O C M B Duarte ldquoAuthFlowauthentication and access control mechanism for softwaredefinednetworkingrdquoAnnals of Telecommunications-Annales desTelecommunications vol 71 no 11-12 pp 607ndash615 2016

[53] M Dallaglio A Giorgetti N Sambo F Cugini and P CastoldildquoProvisioning and restorationwith sliceability in GMPLS-basedelastic optical networksrdquo Journal of Optical Communicationsand Networking vol 7 no 2 pp A309ndashA317 2015

[54] L Xiao Y Li G Han G Liu and W Zhuang ldquoPHY-authentication protocol for spoofing detection in wireless net-worksrdquo IEEE Transactions on Vehicular Technology vol 65 no12 pp 10037ndash10047 2016

[55] C Matte M Cunche F Rousseau andM Vanhoef ldquoDefeatingmac address randomization through timing attacksrdquo inProceed-ings of the 9th ACM Conference on Security Privacy in Wirelessand Mobile Networks pp 15ndash20 2016

[56] MVanhoef CMatteMCunche L S Cardoso and F PiessensldquoWhyMACaddress randomization is not enough an analysis ofWi-Fi network discoverymechanismsrdquo inProceedings of the 11thACM on Asia Conference on Computer and CommunicationsSecurity pp 413ndash424 ACM Xirsquoan China June 2016

[57] U Rajput F Abbas and H Oh ldquoA hierarchical privacy pre-serving pseudonymous authenticationprotocol for vanetrdquo IEEEAccess vol 4 pp 7770ndash7784 2016

[58] T A Team ldquoAvispa v11 user manualrdquo 2006 httpwwwavispa-projectorg

[59] R Amin N Kumar G P Biswas R Iqbal and V Chang ldquoAlight weight authentication protocol for IoT-enabled devices indistributed Cloud Computing environmentrdquo Future GenerationComputer Systems vol 78 pp 1005ndash1019 2018

[60] R Amin S Islam G Biswas M Khan and N KumarldquoA robust and anonymous patient monitoring system usingwirelessmedical sensor networksrdquo Future Generation ComputerSystems vol 80 pp 483ndash495 2018

[61] S Bojjagani and V N Sastry ldquoA secure end-to-end SMS-basedmobile banking protocolrdquo International Journal of Communica-tion Systems vol 30 no 15 Article ID e3302 pp 1ndash19 2017

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom

Page 27: RAMHU: A New Robust Lightweight Scheme for Mutual Users ...downloads.hindawi.com/journals/scn/2019/3263902.pdf · algorithms []. To implement an authentication scheme, manyalgorithms,

International Journal of

AerospaceEngineeringHindawiwwwhindawicom Volume 2018

RoboticsJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Active and Passive Electronic Components

VLSI Design

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Shock and Vibration

Hindawiwwwhindawicom Volume 2018

Civil EngineeringAdvances in

Acoustics and VibrationAdvances in

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Electrical and Computer Engineering

Journal of

Advances inOptoElectronics

Hindawiwwwhindawicom

Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Control Scienceand Engineering

Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Journal ofEngineeringVolume 2018

SensorsJournal of

Hindawiwwwhindawicom Volume 2018

International Journal of

RotatingMachinery

Hindawiwwwhindawicom Volume 2018

Modelling ampSimulationin EngineeringHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Chemical EngineeringInternational Journal of Antennas and

Propagation

International Journal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Navigation and Observation

International Journal of

Hindawi

wwwhindawicom Volume 2018

Advances in

Multimedia

Submit your manuscripts atwwwhindawicom