1 Introduction

The evolution of electronic devices and the internet has benefited us in almost all walks of life. Healthcare system [36, 45] such as TMIS is among one of these marvels which made our lives very easy and simple. TMIS has almost eliminated the distance between doctors and patients. This is due to huge development in the field of wireless body area networks and implantable medical devices [1,2,3,4,5,6]. Patients can consult their doctors from the comfort of their home which is not only beneficial for most people but also allows patients with critical conditions to receive proper medical attention and care. The quick availability of medical services can sometimes be a deciding factor between life and death. Doctors can also address more patients in this manner and specialists can address patients all around the world without wasting time in physical travel. The entities involved in a TMIS include User, Doctor, Smart Card, Smart Card Reader, Authentication Server, and Doctor Server. Figure 1 shows the system architecture of a general TMIS. There are multiple different users connected with different smart card readers to the network. There are multiple doctors connected to the same or different doctor server depending on the implementation [7,8,9]. The user enters the smart card into the smart card reader and authentication parameters like password and biometrics [43]. Smart cards reader does some preliminary processing and generates a login message. This login message is then sent to the authentication server. The authentication server sends the address of the doctor server to the smart card reader if authentication is successful. The authentication server also sends the address of the smart card reader to the doctor server. The doctor terminal is connected to the doctor server via a secure channel. User and doctor now communicate with the channel created between the smart card reader and doctor server.

Fig. 1
figure 1

The system architecture of a general TMIS

Full size image

Major security challenges lie to secure the communication first between the authentication server and smart card reader and then between the doctor server and smart card reader after successful authentication [37, 38, 42, 46,47,48]. These channels are open and can be accessed by the adversary [7]. An adversary can intercept and modify the transmitting messages and can send messages to the smart card reader, authentication server, and doctor server. This means that the adversary can pose as a smart card reader, authentication server, or doctor server. Proper security checks and mechanisms must be established to ensure that the adversary cannot pose as a legitimate entity and gain access to the system or acquire sensitive information. There are different approaches to meet these security requirements like Cryptography [39,40,41, 44], Hashing, and Chaotic Maps. Cryptography can be used to ensure the confidentiality and integrity of the messages. This ensures that an entity with secret information can only access sensitive data. One-way hashing is used to pass sensitive information as the hash functions are irreversible. An entity must also possess knowledge of both hash function and secure parameter to check the correctness of the message passed. Chaotic maps provide the same level of security as hash functions but require huge computation time [10,11,12,13,14,15]. Hence, we have used hashing in our system instead of chaotic maps. Limiting total login attempts is also important as most authentication schemes suffer from offline password guessing attacks [16,17,18,19,20].

User authentication plays a key role in maintaining the security of the system. Authentication can be done through three different factors: knowledge, Ownership, and Inheritance. Knowledge comprises secret information like PIN, password, etc. Ownership means possession of objects like smart cards, software tokens in smartphones, smartwatches, hardware tokens, etc. Inheritance consists of elements exclusive to the user like fingerprint, voice, DNA, etc. Single authentication parameters can be stolen (Ownership) or copied (Knowledge or Inheritance). Hence, it becomes essential to have multi-factor authentication. There are two types of multi-factor authentication: 2-factor authentication [35] and 3-factor authentication. 3-factor authentication is more secure than 2-factor authentication. In TMIS, the user generally contacts a doctor if the user has a disease or a medical condition. Some of them affect the biometrics of users like a swollen thumb, rash throat, eye infection, etc. So in order to maintain provide proper service to the user, we have used 2-factor authentication in our system.

1.1 Expected functionalities

A TMIS must achieve some security aspects in order to ensure secure authentication and key agreement protocol. They are as follows:

  • A secure login phase so that adversary cannot pose as a legitimate user.

  • A secure authentication phase to ensure mutual authentication property is achieved.

  • A minimum number of trusted entities to reduce spoofing attacks.

  • Multi-factor authentication to increase complexity for an adversary in a brute-force attack.

  • Absence of global clock to prevent synchronization attacks.

  • User identity must be kept anonymous from the attacker.

  • Absence of Verification table at the server to prevent insider attacks.

  • Limit the number of login attempts from each user to prevent guessing attacks.

  • Session key must be dynamically generated for each session.

  • A simple but secure password changing mechanism must be provided to the user for changing the password efficiently.

  • A smart card locking mechanism must be provided to the user for blocking lost or stolen smart cards.

  • Servermustkeeptrackofeachloginorpasswordchange attempt to trackanomalies.

  • Perfectforwardsecrecymustbeprovided.

  • User verification token must be generated dynamically after every successful login attempt.

1.2 Attacker model

The communication happens over the insecure channel in TMIS. An attacker has some advantages or capabilities, and they are described as follows:

  1. 1.

    Attackercanextractdatastoredonsmartcardbyobserving consumption of power if no mechanism is provided tolimitattemptsofaccessingdata [21, 22].

  2. 2.

    An attacker can eavesdrop on communication happening between different entities of the model. Another assumption is that attackers cannot access data sent over a secure channel.

  3. 3.

    It is not possible for an attacker to guess 2 parameters, i.e., user identity and password in polynomial time.

  4. 4.

    An attacker can modify and delete the intercepted message. It is also possible for the attacker to resend or reroute the intercepted message.

  5. 5.

    An attacker can also be a legitimate user trying to spoof as another user.

  6. 6.

    The information about the model is public and so even the attacker has the knowledge of the internal working of the model.

  7. 7.

    The probability of guessing user identity of n character and password of n character is 1/(26n). This is pointed out in [16, 23].

The remaining section of this paper is organized as follows: Section 2 shows related work which is relevant to our scheme. Section 3 introduces the proposed model and elaborates on different phases of our model. In Sect. 4, we evaluate the security of our model, prove its security against various attacks, list its functionalities, and compare it with other models. In Sect. 5, we conclude our paper.

2 Related work

Amin et al. [7] identified that the complexity increases in the password changing phase due to the presence of a server. They also found schemes are vulnerable to replay attacks. They proposed a solution in which they added nonce to prevent replay attacks. Nonce also enabled them to check the freshness of the received message. They also made the password changing phase offline to reduce the complexity. Choudhury et al. [24] showed that it is possible to enter fake biometrics in low computational power devices. This led to a weakness in the proposed model of infinite password guessing attacks. Also, no mechanism was provided to block the smart card if it was lost or stolen.

Amin et al. [9] identified that Das et al.’ scheme [16] which was dependent only on user passwords was vulnerable to guessing attacks. They also pointed out the lack of user anonymity and identity guessing by parameters stored on the smart card. They proposed a 3-factor authentication scheme which was more secure due to the inclusion of biometrics. Public-key cryptography and secure one-way hash functions were used to provide anonymity to user identity. A random number was hashed with user identity to provide strong security against identity guessing attacks. However, the biometric template of the user can be compromised if the biometric reader is malicious. Their system had a verification table which made the scheme vulnerable to privileged insider attacks.

Jiang et al. [25] identified a lack of a smart card-blocking mechanism in Wu et al.’s scheme [26]. They also identified the vulnerability to offline password guessing attacks if the biometric data of the user are compromised. They proposed a separate mechanism to block the smart card at the server after user verification. They achieved this by changing login-sensitive information at the server. They also added a server in the password changing phase to authorize the change of password. The major drawback of this scheme was that it had a verification table at the server which stored sensitive information regarding the authentication process. Also, there was no limit on password guessing attempts as there was no mechanism to update or count failed login attempts at the server.

Chaudhry et al. [27] identified the lack of user anonymity as a major issue in Mir et al.’s scheme [28]. They also found the system vulnerable to Denial-of-Service (DoS) attacks. Another issue was that the system was vulnerable to patient spoofing in case of a stolen smart card attack. They performed operations on the previous identity, newly generated random identity, and a random number to provide a dynamic identity in order to provide user anonymity. Patient impersonation was prevented by using user passwords and biometric data indirectly in each message. DoS attacks were prevented by providing local verification of user credentials. As the system used global clocks, there was a vulnerability of global clock synchronization. Local verification of credentials led to infinite password guessing attempts. A smart card-blocking mechanism was not provided by their system.

Jiang et al. [29] identified a lack of user anonymity and mutual authentication in Das et al.’s scheme [30]. They provided user anonymity by masking secret information on the public channel with dynamically generated random numbers. Mutual authentication was achieved by dynamically generating session key based on dynamically generated random numbers and user identity. They did not send user identity directly over an insecure public channel. Complex operations carried out on low-end devices like the smart card and smart card reader were a major drawback of this scheme. Offline password verification mechanism made infinite password guessing attempts possible in a controlled environment.

Xu et al. [8] identified privacy leakage as a major security flaw. Time-consuming heavy operations were performed with low-powered devices like smart cards. They identified reduced efficiency due to the usage of asymmetric cryptography. They also stated that 2-factor authentication schemes are weak as their security depends on using asymmetric key cryptography. Secure hash functions and lightweight symmetric cryptography were included in their schemes to increase the privacy and efficiency of their scheme. They also used 3-factor authentication scheme with a password and biometric verification on the server side. Biometric data can be compromised [24] and they have less accuracy if they are processed in low-end devices with constrained time. The compromised smart card reader can also compromise user identity by capturing the entire biometric template of the user [24]. Server-side verification also makes the system vulnerable to privileged insider attacks. Another disadvantage was that symmetric cryptography is relatively insecure and is easy to break.

Madhusudhan et al. [31] identified a lack of user anonymity in Li et al.’s scheme [32]. They also identified that the session keys generated were insecure. Offline password-guessing attack was also possible on Li et al.’s scheme. The smart card revocation phase was also inconvenient as it required the physical presence of the user. Madhusudhan et al. generated the dynamic identity of the user by masking actual identity with random numbers to provide user anonymity. Dynamic numbers were generated and transferred securely from both the server and user end to generate a dynamic and secure session key. Password value was masked with a random number to prevent password guessing in polynomial time. The major disadvantage was the presence of a verification table at the server end which led to the vulnerability of privileged insider attacks. The server was also not involved in the login phase which led to infinite login attempts. Major identified issues are lack of mutual authentication, lack of user anonymity, presence of verification table, infinite login attempts, and insecure session keys generated during login and authentication phase. Other identified issues include vulnerability to DoS attack, password guessing attacks, Insider attack, Replay attack, Man-in-the-Middle (MITM) attack, and Forward Secrecy attack. The global clock synchronization problem exists due to the presence of a global clock. It is essential that a simple yet secure password-changing mechanism and smart card-blocking mechanism must be provided. Some other common attacks like Stolen smart card attack, Session key disclosure attack, Brute force attack, Stolen verifier attack, Masquerade attack, and Modification attack are also considered as a serious security threat to the system.

We now address these issues in our proposed scheme. We prefer to use a 2-factor authentication scheme as it is more efficient with low-end devices and reduces inaccuracy due to the presence of biometric data. We also concluded that using nonce is better as it is not vulnerable to synchronization attacks.

3 Proposed scheme

In this section, we first list entities involved in our system along with their role. Then, we list our notations which we will be using in Table 1. Then, we see the system architecture of our model followed by different phases of our system in detail.

Table 1 Notations used in Proposed Model
Full size table

3.1 Entities involved and their role

Entities involved in the proposed scheme are Smart card, Smart card reader, Authentication server, Doctor Specialization server, User Data Server, Registration center, proxy node, and Nonce Generator.

  1. 1.

    Smart card: smart card is used on our system to use factor of ownership for user authentication. Data stored on the smart card are as follows:

    • UID: This is the user identification value used to uniquely identify a user as well as link a specific smart card to a specific user.

    • BSC: This is a flag that is stored on the smart card. If its value is zero, then the smart card is activated and can be used. If its value is 1, then the smart card is blocked and it must be reactivated at the registration center before reusing it.

    • hSC(): A hash function that is unique for every smart card. This function is used for the early detection of the wrong password.

    • TS1, TS2, TS3: three timestamp values which are stored to maintain the property of freshness. It is assumed that these timestamps are stored on the rewritable memory of the smart card. After every transaction, TS2 is stored in TS3, TS1 in TS2, and the latest timestamp in TS1. These 3 timestamps represent 3 tolerance of the wrong password provided by the system to the user.

    • HS: It is a single hash value stored on the smart card to check the freshness and correctness of the user password. This hash value consists of two input parameters, i.e., password of the user (P) and timestamp of last successful transaction (TSS).

    • RSA keys (eSC, dSC, nSC): RSA keys are stored on the smart card to perform secure communication over insecure channel. These are heavy operations and get performed on the smart card reader to perform them efficiently.

  2. 2.

    Smart card reader: Smart card reader provides a clock and power to the smart card so that it can perform necessary operations. It also performs complex operations like cryptographic operations needed by smart cards to communicate in a secure manner. It also contains 2 different addresses for communication purposes and their utilization are as follows:

    1. •

      Firstly, the address is used directly by the smart card reader in login and authentication phases to communicate with the authentication server.

    2. •

      Secondly, the address is used by a smart card reader to verify the identity of doctor-specific server as this address is kept secret and sent to the authentication server after server authentication.

  3. 3.

    Authentication server: The authentication server is trusted with the following responsibilities:

    1. •

      The authentication server is responsible to verify the identity of the user. After successful verification, the authentication server is responsible for introducing a random proxy node and establish a connection with the Doctor specialization server.

    2. •

      The authentication server also maintains a list of all available UID along with a flag. This flag is used to determine if a user card is active or blocked. Once AS decides that a specific card is invalid, it is blocked. In order to regain access to the system, either a new card must be requested or the same card must be reactivated at the registration center.

  4. 4.

    Doctor specialization server: There are multiple such servers that exist in our scheme. Each server is dedicated to a specific specialization like Cardiologists, Dermatologists, Neurologists, Ophthalmologists, etc. Each of these servers contains a list of all available doctors in the system. These doctors are classified into 2 categories and can be contacted by the user in 2 different ways. Classification of doctors is done based on whether they are online or not and whether they are free or currently engaged with a patient. Users can decide to either connect to a random doctor from a list of available doctors who are not engaged with a patient or wait for the doctor who is currently engaged with a patient based on their urgency and comfort.

  5. 5.

    User data server: This is a special type of server which is connected to all the doctor specialization server via a secure channel. This server retains the medical history of each user on the system along with maintaining the current status of the user like active diseases, recent diagnostics, etc. These records are provided to the doctor on demand when the doctor is addressing a patient. In order to access this data, Doctor id (DID) which is generated by the system, and User id (UID) which is verified by the authentication server are required. In order to maintain the privacy of the user and transparency of history to the doctor, only relevant historical data are selected and revealed to the doctor by the system based on the specialization of the doctor.

  6. 6.

    Registration center: These centers are available at multiple physical places as per our proposed scheme. They are considered as trusted nodes in the system. Their main role is accepting appropriate input from the user for their registration and reissuing of the smart card or reactivating them if they are blocked. These centers are responsible to ensure that only legitimate users are provided smart cards. The physical presence of the user is important for registration purposes.

  7. 7.

    ProxyNode: Proxy nodes are present in the system in the count of several thousand and are selected at random from a pool of free proxy nodes. They are present in the system with the only intention of message passing. These nodes ensure that identity of the Doctor specialization server, User data server, and Smart card reader are kept hidden from each other. These nodes are responsible for providing anonymity in the system. Only information about two different entities which are communicating are provided to the proxy node.

  8. 8.

    Nonce generator: Nonce generator is a node that generates new nonce based on timestamp. These nodes are present in the form of two different levels. A central generator generates new nonce every minute and broadcasts it to a trusted propagator node. These propagator nodes send the latest nonce as a reply to any machine which sends a request for the nonce. These broadcast nodes prevent a single point of failure and ease in process of transferring nonce as there is a possibility of the central node getting overwhelmed with requests for the nonce.

3.2 System architecture

The system architecture of the proposed model is defined in Fig. 2. The flow of data, its relation with various phases, and the overall working of the system are explained in the steps below:

  1. 1.

    User enters SC and his credentials into SCR.

  2. 2.

    SCR performs necessary operations mentioned in login phase and sends login message to AS.

  3. 3.

    AS performs operations mentioned in the login phase and sends an appropriate reply to the SCR. SCR evaluates the received reply and moves to the authentication phase if authentication is successful or else it restarts the login phase.

  4. 4.

    SC generates a new secret message, performs necessary operations and sends the message to AS.

  5. 5.

    AS sends a get-nonce message to SCR and stores the next 3 nonce values. SC stores the latest nonce when a get-nonce message is received.

  6. 6.

    SCR sends a get-nonce message to AS and stores the next 3 nonce values. AS stores the latest nonce when a get-nonce message is received.

  7. 7.

    AS sends the newly generated message to SCR. SCR uses the received message to authenticate the AS. Either AS is successfully authenticated and the next step is performed or the connection is terminated in case of authentication failure.

  8. 8.

    SCR sends the newly generated message and Req message to AS. AS performs the next step if SCR is successfully authenticated, otherwise the connection is terminated.

  9. 9.

    After successful mutual authentication, AS deciphers the received Req message. AS then sends necessary parameters to DSS and UDS, respectively.The authentication phase ends after this and the system moves to the connection establishment phase.

  10. 10.

    DSS selects a proxy node at random from a large available number of nodes. DSS then sends the address of SCR and a secret message to the selected proxy node.

  11. 11.

    The proxy node deciphers the address of SCR and sends a secret message to the SCR.

  12. 12.

    SCR receives the secret message, performs some operations, and sends a new secret message to the proxy node. SCR also verifies the identity of DSS with the received secret message.

  13. 13.

    Proxy node forwards the received secret message to DSS.

  14. 14.

    DSS performs some operations on the received secret message to verify the identity of SCR. A connection is established between SCR and DSS via proxy node after successful identity verification.

  15. 15.

    After all the communication is done between Doctor and the User, the system now moves to the connection termination phase. A free-node message and terminate-connection message are sent to the proxy node by DSS. DSS drops the connection with the proxy node after sending these messages.

  16. 16.

    The proxy node terminates the connection with DSS after receiving a terminate-connection message. Free-node message received from DSS is sent to SCR.

  17. 17.

    SCR sends the free-node and terminate-connection message to the proxy node after receiving the free-node message. SCR drops connection with proxy node after sending these messages.

  18. 18.

    The proxy node terminates the connection with SCR after receiving the terminate-connection message. Proxy node again becomes free and returns to available free nodes.

Fig. 2
figure 2

System architecture of proposed model

Full size image

3.3 Registration phase

The registration phase happens at RC. Entities involved in this phase include SC and RC. Once the Registration phase is complete, databases of AS and UDS have been modified accordingly. All messages are sent through a secure channel in this phase. Figures 3 and 4 illustrate working in the registration phase. The steps involved in the Registration phase are as follows:

  1. 1.

    User selects User id value (ID) at random. Restriction for selection of User id is that it should not overlap with id of any previous user which is taken care by the RC. The user then enters his desired password P and the biometric information B. Message {ID, B} is then passed to the RC.

  2. 2.

    After receiving previous message at RC, UID is computed as UID = hRC(ID). RC then generates 3 random Timestamps as TS1, TS2 and TS3. A new one-way hash function h() is generated. A new set of RSAKey(e, d, n) is generated. UID[IC] is initialized to 0, UID[Block] to 0 and TSS is initialized to TS1. Message {UID, hB(B)} is sent securely to UDS. Message {UID, UID[IC], TSS, UID[Block]} is sent securely to AS. Message {UID, TS1, TS2, TS3, h(), (e, d, n)} is passed to theSC.

  3. 3.

    SC initializes hSC() after receiving message from RC as hSC() = h(). TS1, TS2, TS3 and UID are stored directly on SC as TS1, TS2, TS3 and UID, respectively. (e, d, n) is stored as SC RSA keys, i.e., (eSC, dSC, nSC). HS is computed as HS = hSC(P||TS1). BSC is initialized as 0.

  4. 4.

    After receiving the message at AS, an entry is made for the new user with UID as UID, UID[IC] as IC, UID[TSS] as TSS, and UID[Block] as Block.

  5. 5.

    After UDS receives the message from RC, an entry is made for the new user with UID as UID and biometric template as hB(B). Through an existing secure connection, the medical data of the user are transferred securely and entered into the database.

Fig. 3
figure 3

Registration phase operations between SC and RC

Full size image
Fig. 4
figure 4

Registration phase operations between AS, UDS, and RC

Full size image

3.4 Login phase

Users can log in remotely through any authorized SCR. Authorized SCR is one that is trusted by the system to perform desired operations. This SCR has the identity of AS stored in its memory and contains a mechanism to prevent tampering. Connection established in this phase between SCR and AS is secure as it uses public-key cryptography. In this phase, all operations which are performed on SC are done through SCR. Figure 5 illustrates computations and messages involved in the login phase. Steps involved in Login Phase are as follows:

  1. 1.

    The user enters SC in SCR and P whenever prompted by the system.

  2. 2.

    SCR reads the value of BSC from SC after SC is inserted. If the value of BSC is set to 1, then SC blocked message is prompted and the Login phase is terminated. If SC is not blocked, then SCR prompts user to enter his password and stores as P. Value of current time stamp is stored as TSL. SCR computes t1, t2 and t3 as t1 = hSC(P ||TS1), t2 = hSC(P ||TS2) and t3 = hSC(P ||TS3).If t1 matches HS, then TS1 is saved as TSSUCCESS otherwise if t2 matches HS then TS2 is saved as TSSUCCESS otherwise if t3 matches HS then TS3 is saved as TSSUCCESS and Step 4 is performed by SCR. If none of t1, t2, or t3 matches HS, then Step 3 is performed by SCR.

  3. 3.

    This step is performed by SCR when the user enters an invalid password. The value of a random timestamp is stored as TStemp. This time stamp value is not equal to either TS1, TS2 orTS3. SCR then updates TS3 as TS2, TS2 as TS1, and TS1 as TSL. The value of IC is then initialized to 1.

  4. 4.

    This step is performed by SCR when the user enters a valid password. SCR updates HS as HS = hSC(P||TSL). SCR initializes IC to 0 and TStemp to TSSUCCESS.

  5. 5.

    Message {IC, UID, TStemp, TSL} is sent to AS by SCR after completion of either Step 3 or Step 4.

  6. 6.

    This step is performed when AS received message from SCR. If value of UID[Block] is set to 0 and value of UID[TSS] is not equal to the value of TStemp, then UID[IC] is modified as UID[IC] = UID[IC] + IC. If value of UID[IC] is greater than 2,then the value of UID[Block] is set to 1. If value of UID[Block] is set to 0 and value of UID[TSS] equals value of TStemp, then UID[TSS] is updated as UID[TSS] = TSL, UID[IC] as UID[IC] = 0 and UID[Auth] as UID[Auth] = 1. Message {UID[Block], UID[Auth]} is then sent to SCR by AS.

  7. 7.

    After receiving a message from AS, SCR updates BSC as BSC = UID[Block]. If the value of BSC is set to 1, then SC blocked message is prompted and Login phase is terminated. If the value of BSC is set to 0 and the value of UID[Auth] is set to 1, then the user is successfully verified and SCR moves to the Authentication phase. If the value of BSC is set to 0 and the value of UID[Auth] is set to 0, then an invalid password message is prompted and SCR goes to execute Step Set B of login phase.

Fig. 5
figure 5

Login phase operations between SCR and AS

Full size image

3.5 Authentication phase

In the Login phase, we ensured that the user was legitimate. After the successful termination of the login phase, our system automatically moves to the Authentication phase, wherein we check the authenticity of SC and AS. We use the concept of digital signatures in our system for this purpose. All communications between SC and AS happen through an open insecure channel in this phase. Figure 6 shows operations used to ensure Mutual authentication between SCR and AS. After successful mutual authentication, Fig. 7 shows operations carried out to pass information to other entities in the system. The steps involved in our authentication phase are as follows:

  1. 1.

    SC generates a secret 128 bit keyword SSC. SC computes DSC as DSC = eAS[dSC(SSC)]. Message {DSC} is sent to AS by SC.

  2. 2.

    After receiving a message from SC, AS generates a secret 128 bit keyword SAS. AS computes DAS as DAS = eSC[dAS(SAS)]. AS computes KAS as KAS = dAS[eSC(DSC)]. AS sends a get-nonce message to SC. After sending this message, AS stores the next 3 nonces as m1, m2, and m3 by sending a nonce request to the nearest nonce propagator node.

  3. 3.

    After receiving a get-nonce message from AS, SC sends a nonce request to the nearest nonce propagation node and stores the resulting nonce as nt. SC now sends a get-nonce message to AS. After sending this message, SC stores the next 3 nonces as n1, n2, and n3 by sending a nonce request to the nearest nonce propagation node.

  4. 4.

    After receiving get a nonce message from SC, AS sends a nonce request to the nearest nonce propagation node and stores the resulting nonce as mt. AS computes MAS as MAS = eSC[dAS(KAS|| mt)]. Message {MAS, DAS} is then sent to SC by AS.

  5. 5.

    After receiving message from AS, SC computes the value of KSC as KSC = dSC[eAS(DAS)], MSC as MSC = eAS[dSC(KSC|| nt)], TSC as TSC = dSC[eAS(MAS)], p1 as p1 = SSC||n1, p2 as p2 = SSC||n2 and p3 as p3 = SSC||n3. If value of TSC is neither equal to p1 nor p2 nor p3,then AS authentication is failed. In this scenario, a terminate-connection message is sent to AS by SC. After sending this message connection is terminated and Authentication phase is alsoterminated. If value of TSCis equal to p1 or p2 or p3, then AS is successfully authenticated by the SC. SC now computes value of SK as SK = [SSC||KSC] after successful authentication. SC generates Req message as Req = ESK[UID, DSS type, SCRaddr]. Message {Req, MSC} is then sent to AS by SC.

  6. 6.

    After receiving message from SC, AS computes the value of TAS as TAS = dAS[eSC(MSC)], q1 as q1 = SSC||m1, q2 as q2 = SSC||m2 and q3 as q3 = SSC||m3. If the value of TAS is neither equal to q1 nor q2 nor q3, then SC authentication is failed. In this scenario, a terminate-connection message is sent to SC by AS. After sending this message connection is terminated and the Authentication phase is also terminated. If the value of TAS is equal to q1 or q2 or q3, then SC is successfully authenticated by the AS.

  7. 7.

    A Snow computes value of SK as: SK = [KAS||SAS] after successful SC authentication. AS then decrypts received Req message using SK i.e., DSK(Req) and gets values of UID, DSStype and SCRaddr.AS checks the value of UID[Auth] in its database. If the value of UID is 0, then either SC or SCR is compromised as the Login phase was skipped. In this case, UID[Block] is set to 1, and SC is blocked to prevent compromising user data. The authentication phase is terminated as connection is terminated with SC. If the value of UID[Auth] is 1, then its value is set to 0. Messages are sent to specific DSS as requested by the user in DSStype and UDS securely. The authentication phase is terminated successfully.

  8. 8.

    Message {UID, SK, SCRaddr} is sent to DSS by AS after completion of the Authentication phase. This message provides all the necessary parameters needed by DSS to verify identity of SCR and establishes a secure connection. Message {UID, DSStype} is sent to UDS by AS after completion of the Authentication phase.

Fig. 6
figure 6

Operations between SC and AS in authentication phase

Full size image
Fig. 7
figure 7

Operations between AS, UDS, and DSS after successful mutual authentication between SC and AS

Full size image

This message gives information about the type of DSS which will request access to User data corresponding to UID. This ensures that data of specific user relevant to that DSS is sent by UDS.

3.6 Connection establishment phase

We need to understand some of the background statistics of the system before exploring the Connection establishment phase. They are as follows:

  • UDS has public RSA keys of every DSS stored in its database.

  • Every DSS has RSA key of UDS stored in its database.

  • Messages are transferred between UDS and DSS by using asymmetric cryptography and this connection is secure. The user is unaware about the existence of this connection.

  • DSS of different types have no knowledge about current communication of user with other DSS.

  • AS notifies UDS about UID and DSS type after successful completion of Authentication phase. This ensures that data of the only specific user is accessed by specific DSS. This ensures the privacy of user data as well as no spoofed connection to UDS by DSS.

  • PX is selected at random by DSS from a pool of a large number of proxy nodes.

Figure 8 shows operations that are performed in the system during the connection establishment phase. It is essential to note that there is a second mutual authentication operation taking place between DSS and SCR. After successful authentication of AS, SCR shares a secret address SCRaddr with AS. AS then shares this address with the DSS with which the user desires to establish a connection. SCR can thus verify the identity of DSS when it gets a message on a secret secondary address SCRaddr. SK is a secret key generated mutually by AS and SCR. AS shares this key with DSS using a secure channel. SCR already has this secret key from the authentication phase. If the value of R2 is greater than R1 by 1, then it ensures the identity of SCR as SK is known only to 3 entities i.e., SCR, AS, and DSS. Thus, before revealing any information about User data, our system thoroughly checks the identity of every communicating entity. Steps followed in the connection establishment phase are as follows:

  1. 1.

    After receiving message from AS, DSS generates random number R1. a is computed as a = ESK(R1). x1 is computed as × 1 = ePX[dDS(SCRaddr, a)]. Message {x1} is then sent to PX by DSS.

  2. 2.

    After receiving message from DSS, PX decrypts x1 as dPX[eDS(x1)] to obtain address SCRaddr and a. From SCRaddr, PX deduces public key of SCR. PX then computes the value of x2 as x2 = dPX(a) and x3 as × 3 = eSCR[PXaddr, x2]. Message {x3} is then sent to SCR by PX.

  3. 3.

    After receiving message from PX, SCR decrypts x3 as dSCR[x3] to obtain address PXaddr and x2. From PXaddr, SCR deduces public key of PX. SCR then computes a as a = ePX(x2), R1 as R1 = DSK[a], R2 as R2 = R1 + 1 and x4 as x4 = ePX[dSCR(R2)]. Message {x4} is then sent to PX by SCR.

  4. 4.

    After receiving message from SCR, PX computes the value of x5 as x5 = dPX[eSCR(x4)] and then x6 as x6 = eDS[dPX(x5)]. Message {x6} is then sent to DSS by PX.

  5. 5.

    DSS computes R2 as R2 = dDS[ePX(x6)] after receiving message from PX. If the value of R2 is not equal to the value of R1 + 1, then the SCR is detected as a malfunctioning reader or compromised reader. In this case, the proxy node is freed and the connection is terminated by DSS.

Fig. 8
figure 8

Operations performed within system to perform final check of identity of DSS and SCR while establishing connection

Full size image

If the value of R2 is equal to the value of R1 + 1, then DSS verifies the identity of SCR as only SCR had a value of SK apart from AS. SCR also successfully verifies the identity of DSS as only AS had the value of SCRaddr. Value of SCRaddr changes whenever a new SC is inserted. The connection is successfully established between SCR and DSS after these sets of messages. Messages which are exchanged after completion of Step 5 follow the following rules:

  1. 1.

    Messages exchanged between SCR and DSS are always exchanged via PX and the public-key cryptography method is always used as secondary encryption.

  2. 2.

    Messages transferred from SCR as well as DSS are encrypted using SK for primary encryption.

Rule 1 ensures anonymity of DSS from SCR as the address of DSS is never revealed to SCR. Rule 2 ensures secrecy of data from PX as the value of SK is not shared with PX. This ensures that even if PX is compromised, an attacker can still not access confidential user data.

3.7 Connection termination phase

This phase is reached after successful completion of the session or when SCR is not verified. Another scenario when this phase is reached is when SCR becomes non-responsive to PX. The connection between PX and DSS never terminates abruptly and the system ensures that no-fault occurs at DSS and PX. However, with respect to SCR, there can be many reasons for abrupt connection terminations like Network Failure on the user end, SCR failure, abrupt termination by user, etc. Thus, it becomes critical that the system terminates the connection properly so that there is no unnecessary open connection at DSS and no unnecessary blocking of the proxy node. To make this possible, there exists a counter at both DSS and PX. The key role of this counter is to push the system in the termination phase if no messages are transferred for a significant amount of time. After exchanging the free-node messages, both DSS and SCR terminated the existing connection with PX. PX terminates the connection with both DSS and SCR and then returns to the pool of free nodes.

3.8 Password change phase

Users can change passwords remotely through any authorized SCR. A prerequisite for changing the password on SC is to know the existing password of SC. So in this phase, we initially confirm the identity of the user. Once the user identity is verified, we then proceed to change the user’s password. Similar to the login phase, we provide 3 tolerance for the user if the wrong password is entered, after which SC is blocked. If a user forgets his password, then he must visit RC to reactivate the SC. Figure 9 gives a detailed explanation of this phase. Connection established in this phase between SCR and AS is secure after successful user verification as it uses public-key cryptography. In this phase, all operations which are performed on SC are done through SCR. Steps involved in Password Change Phase are as follows:

  1. 1.

    The user enters SC in SCR, User enters the current password P in the SCR whenever prompted by the system and Pnew in the SCR after successful user verification.

  2. 2.

    After SC is entered, SCR reads the value of BSC from SC. If the value of BSC is set to 1, then SC blocked message is prompted and the Password change phase is terminated. SCR prompts the user to enter his password and stores as P if SC is not blocked. Value of current timestamp is stored as TSL.TSSUCCESS is initialized to a random Timestamp value which is less than TSL.

  3. 3.

    SCR computes the value of t1, t2 and t3 as t1 = hSC(P||TS1), t2 = hSC(P||TS2) and t3 = hSC(P||TS3). If t1 matches HS then TS1 is saved as TSSUCCESS otherwise if t2 matches HS then TS2 is saved as TSSUCCESS otherwise if t3 matches HS then TS3 is saved as TSSUCCESS and Step 5 is performed by SCR. If none of t1, t2, or t3 matches HS, then Step 4 is performed by SCR.

  4. 4.

    SCR performs the following steps when entered password is invalid. SCR computes the value of TStemp as TStemp = TSSUCCESS, TS3 as TS3 = TS2, TS2 as TS2 = TS1, TS1 = TSL and initializes IC to 1.

  5. 5.

    SCR initializes IC to 0 and TStemp to TSSUCCESS if the password entered by the user is valid.

  6. 6.

    Message {IC, UID, TStemp, TSL} is sent to AS by SCR after completion of either Step 4 or Step 5.

  7. 7.

    After receiving message from SCR, AS checks values of UID[Block] UID[TSS]. If value of UID[Block] is set to 0 and value of UID[TSS] is not equal the value of TStemp, UID[IC] is updated as UID[IC] = UID[IC] + IC. If value of UID[IC] is greater than 2, then the value of UID[Block] is set to 1. If value of UID[Block] is set to 0 and value of UID[TSS] equals value of TStemp, then TS is computed as TS = TSL and UID[IC] is set as 0.

  8. 8.

    If the value of UID[Block] is set to 0 and the value of UID[TSS] is not equal to the value of TStemp, then the value of the current timestamp is stored as TS. Message {UID[Block], TS} is then sent to SCR by AS.

  9. 9.

    After receiving a message from AS, SCR updates value of BSC as BSC = UID[Block]. If the value of BSC is set to 1, then SC blocked message is prompted and the password change phase is terminated. If the value of BSC is set to 0 and the value of TS is not set to TSL, then an invalid password message is prompted and SCR goes to execute Step 2 of the password change phase. If the value of BSC is set to 0 and the value of TS is set to TSL, then the user is successfully verified and SCR prompts the user to enter a new password Pnew. SCR then updates HS as HS = hSC(Pnew||TSSUCCESS) and TS1 to TSSUCCESS. The password change phase is successfully terminated after values are updated successfully.

Fig. 9
figure 9

Interaction between SCR and AS to change password of a user

Full size image

3.9 Smart card reactivation phase

This phase happens at RC. Entities involved in this phase include SC and RC. Once the Reactivation phase is complete, a database of AS has been modified accordingly. This phase is also used if the user requests issuing of a new card. This phase is explained in detail in Fig. 10. This phase is also useful for some other scenarios like if the user misplaces his SC, if the SC of the user is stolen or if the user forgets the password of his SC. The steps involved in this phase are as follows:

  1. 1.

    User enters his User id value as ID and his biometric information Bnew. Message{ID, B} is then passed to the RC.

  2. 2.

    After receiving a message from the user, RC computes UID as UID = hRC(ID) and HB as HB = hRC(Bnew). If the value of HB does not match the value of UID(hRC(B)), then user documents are tried to match with documents stored on UDS for that specific ID. If they do not match, then the user is considered as invalid on the system and is sent to the Registration phase.

  3. 3.

    If value of HB matches with UID(hRC(B)), then RC generates 3 random Timestamps as TS1, TS2 and TS3. A newone way has h function h() is generated. A new set of RSA Key(e, d, n) is generated. Bnew is then mapped to UID in database of RC as (UID, hRC(Bnew)). UID[IC] is initialized to 0, UID[Block] to 0 and TSS is initialized to TS1. Message {UID, hB(Bnew)} is sent securely to UDS. Message {UID, UID[IC], TSS, UID[Block]} is sentsecurely to AS. Message {UID, TS1, TS2, TS3, h(), (e, d, n)} is passed to the SC.

  4. 4.

    After receiving message from RC, SC prompts user to enter his new password Pnew. hSC() is initialized as h(). TS1, TS2, TS3 and UID are stored directly on SC as TS1, TS2, TS3 and UID respectively. (e, d, n) is stored as new SC RSA keys, i.e., (eSC, dSC, nSC). HS is then computed as HS = hSC(Pnew||TS1) and BSC is initialized to 0.

  5. 5.

    After receiving a message from RC, AS updates the entry user with UID as UID, UID[IC] as IC, UID[TSS] as TSS, and UID[Block] as Block.

  6. 6.

    After receiving a message from RC, UDS updates the entry of the user with UID where the biometric template hB(B) is modified to hB(Bnew).

Fig. 10
figure 10

The complete workflow of smart card reactivation phase

Full size image

4 Analysis and discussion

This section covers formal security verification of the proposed model using the AVISPA tool followed by functionalities provided by the proposed scheme and analysis of the scheme under some common attacks. Then we compare our scheme with some schemes from Table 2, to analyze security relatively in terms of attacks and functionalities.

Table 2 Related work for TMIS
Full size table

4.1 Formal verification using AVISPA

AVISPA (automated validation of internet security protocols and applications) tool [33] is widely accepted to prove the security of protocols against various attacks. It supports high-level protocol specification language (HLPSL) and gives its output as either SAFE or UNSAFE after analysis of the protocol. There are four different back-ends that are supported by AVISPA through which we can evaluate our protocol. We will be using OMFC (On-the-fly Model Checker) back-end and ATSE (Constraint-logic-based Attack Searcher) back-end to evaluate our protocol.

Some assumptions are made about entities of the system, and they are as follows:

  1. 1.

    All the elements stored in SC are secure and not accessible to adversary.

  2. 2.

    The adversary can access SC and modify the outgoing and incoming messages.

  3. 3.

    The adversary cannot verify identity without a response from AS.

  4. 4.

    The adversary cannot alter the internal processing of data withinSC.

We evaluate the login and authentication phase of our protocol with the above-mentioned back-ends. The registration phase and Reactivation phase occur in a secure environment at the RC. The connection establishment phase and connection termination phase are reachable only after the successful completion of the login and authentication phase. Also, there is a huge similarity between the Login phase and Password Change phase as the password can be changed only after successful login. Thus, our entire protocol’s security depends on the security of the login and authentication phase.

4.1.1 Evaluation of login phase/password change phase

There are two message exchanges between SCR and ASin this phase. The first message sends 4 parameters from SCR to AS. IC, UID, TSL and TStemp. In this phase, all the messages transfer through a secure channel. We encrypt the value of UID with the public key of AS so that user identity is not revealed to the attacker. Only a genuine user with the correct password will possess the correct value of TStemp on his SC. All other values are passed over an insecure channel.

AS replies with two status messages (UID[Auth] and UID[Block]). Our goal is the secrecy of UID in this phase. The main reason of this secrecy is so that attackers cannot send fake requests of that specific UID and block access of that user. The reply messages are transferred over an insecure channel and do not require secrecy. Figures 11 and 12 show security evaluation of the login phase with OFMC and ATSE back-ends. The main reason for this is because we have a mechanism to check the correct execution of the login phase in the authentication phase.

Fig.11
figure 11

Evaluation of login phase using OFMC back-end

Full size image
Fig. 12
figure 12

Evaluation of login phase using ATSE back-end

Full size image

In the password change phase, the first message remains the same, whereas parameters in the second message are changed. The value of a TS is passed along with the value of UID[Block]. The reply message in this phase is also transferred over the insecure open channel. The adversary can modify the value of TS here from an earlier message to modify the password of the user to the value of his choice. Because we change the value of TS1 to TSSUCCESS and merge it with a modified password, the original TSS value stored on AS is never merged with a new password. As a result, the new modified password will be detected as invalid in the next login phase.

4.1.2 Evaluation of authentication phase

The main goal of the authentication phase is to provide mutual authentication and verify the secure implementation of the login phase. We use public-key cryptography to ensure the secure transmission of messages in this phase. In order to check the freshness of the message, we use a nonce generator which generates new nonce periodically. No session with DSS can be initiated without successful completion of either the login or authentication phase. Final verification of the identity of DSS happens when it contacts SCR on a second secret address. Verification of SCR occurs when it successfully replies with the secret encrypted value to DSS. We have considered the secrecy of random secrets SSC and SAS which is used to generate a session key and strong authentication in this phase as our goal. Figures 13 and 14 show an evaluation of AVISPA for the authentication phase using OFMC and ATSE back-ends.

Fig. 13
figure 13

Evaluation of authentication phase using OFMC back-end

Full size image
Fig. 14
figure 14

Evaluation of authentication phase using ATSE back-end

Full size image

4.2 Functionalities provided by the proposed scheme

In this section, we briefly explain how our scheme provides desired properties for a TMIS scheme. These properties are mentioned below as follows:

  1. 1.

    Multi-factor authentication scheme: We use two different factors for authentication of user i.e., Knowledge and Ownership. Knowledge factor is used in terms of password and Ownership factor as SC. The inheritance factor is not considered because it is tough to securely process them on low-powered devices.

  2. 2.

    Absence of biometric data: Biometric data of the user are not used in our scheme to provide security to user identity. It is possible to duplicate the fingerprint of a person. If the biometric data reader is faulty or compromised and stores data about the biometric template of the user, then the attacker can not only access files on our system but also on other systems where the same biometric template is used. Other biometric templates like speech can deviate from the stored template if a user is ill. In order to reduce false negatives and provide security to the identity of the user, we do not use the biometric data of the user in our system.

  3. 3.

    No global clock: Global clock-based tokens for user verification is a good way to authenticate users. However, due to the remote nature of the application there exists transmission delay which makes such schemes unreliable as the slow connection might be displayed as an illegitimate user. Global clock mechanism also suffers through global clock synchronization problem. So instead of a global clock, we use a global nonce generator and use the concept of the nonce to check the freshness of the message.

  4. 4.

    Mutual authentication: In our scheme, we have 2 mutual authentication mechanisms. In the authentication phase, SC authenticates AS and vice versa. After successful authentication, SC sends SCR's second address (secret) to AS encrypted with a newly generated key SK. This is our first mutual authentication. In the connection establishment phase with the help of a proxy node, DSS sends a message to SCR. SCR authenticates DSS as only DSS and AS knows the second address of SCR. DSS authenticates SCR when it receives a response message from SCR as only SCR has key SK which is used to update and sends R2 as R1 + 1. This is our second mutual authentication mechanism where DSS and SCR authenticate eachother.

  5. 5.

    User anonymity: The attacker needs the value of UID in order to trace the user in the system. UID is always transferred in an encrypted manner to AS from SC. After the login and authentication phase, UID is never transmitted in the connection establishment or connection termination phase. As per our assumption, SC elements are secured and cannot be extracted by an attacker. The token which is used to authenticate the user also does not contain any biometric information of the user. After the authentication phase, a new connection is established between DSS and SCR via a proxy node. As the second address of SCR is secret, it is not available to an attacker. Data stored on UDS can be accessed only when AS permits doctor from DSS to access data. The data are then again filtered according to the requirement of a doctor. From known elements or messages which are transferred, an attacker cannot deduce or guess the identity of the user. So the identity of the user is secure in the system and is not available to an attacker.

  6. 6.

    Server Anonymity: There are three different types of servers in our system, i.e., AS, UDS, and DDS. The identity of UDS and DDS is known only to AS. The identity of AS is revealed to everyone. No crucial data of the user are stored on AS. Identity of UDS is kept anonymous for every entity in the system apart from DSS and AS. DSS cannot access data from UDS without permission from AS. So UDS is completely anonymous from user and attacker. DSS communicates with SCR via a proxy node after successful authentication. So the identity of DSS is also not revealed to the user or attacker. So our mechanism provides server anonymity of DSS and UDS, i.e., all servers where user data are either stored or processed.

  7. 7.

    No verification table: No table is kept on AS which keeps track of user password.Userauthenticationisdoneat SC by a secret value HS. A single timestamp of the last successful session is stored at AS for each user. The primary role of this timestamp is to roll back any transactions which are done after that in case if SC is reported as lost.

  8. 8.

    Dynamic session key generation: In the authentication phase, there are two dynamically generated secret values SSC and SAS at SC and AS respectively. These values are exchanged secretly and are used to generate a new key SK which is useful only for this session. As this key is not dependent on any knowledge which is supposed to be stored on SC or AS, our scheme supports completely random and dynamic key generation.

  9. 9.

    Dynamic user verification token: User verification token is HS which is stored on SC. The value of HS is dependent on the user password and one of the 3 timestamp values TS1, TS2, or TS3 depending on a total number of wrong passwords entered. If more number of wrong passwords are entered, then the card is simply blocked. The value of TS’s keep on changing after every attempt to log in, and the value of the user verification token after every successful login.

  10. 10.

    Online password changing mechanism: The password of the user is stored on SC in our scheme. In order to change the password, the user must first verify his identity. In our scheme, we notify AS for every attempt to login and password change. This is so that malicious attempts to log in can be tracked by the system. This leads to little extra processing time in this phase but increases the security of the system.

  11. 11.

    Smart card blocking mechanism: SC can either be stolen or be lost. In our system, there is SC blocking mechanism in Login, authentication, and password change phase. After exceeding the total number of acceptable wrong passwords, AS blocks the SC. Even if the attack is to be performed in a simulated environment, SC deletes the original TS value after 3 failed attempts. As a result, SC gets blocked whenever it tries to log in after this event. In order to resume utilization of SC, either a new SC must be issued or old SC must be reactivated.

  12. 12.

    Multiserver support: In our system, there exists support for multiserver architecture. In some specific scenarios, there can be a need to consulting more than one doctor. In that case, more than one doctor from different DSS can communicate with each other. Depending on the type of server and availability of doctors, it is also possible to have more than one DSS for a specific type of doctor.

  13. 13.

    No infinite login attempts: Offline login and user authentication provide a simple and early detection mechanism for wrong user passwords. This happens at the user end and so no track is maintained in the system. It thus provides attackers to perform infinite login attempts and perform attacks like password guessing and brute force. In our scheme, we limit this by providing two different parameters to check login attempts. We use cascading times at SC and invalid counter at AS to limit the total number of login attempts.

4.3 Security analysis against various attacks

In this section, we show how our scheme can withstand various known attacks. We have considered attacks mentioned in Gupta et al.’s [34] paper and they are as follows:

  1. 1.

    Stolen smart card attack: In our scheme, the user is supposed to enter a password to verify his identity. We provide tolerance to only 3 wrong passwords after which the card is blocked. Also instead of storing the password directly, we hash it with a timestamp and store it as HS to provide password blinding. Thus, our scheme can withstand this attack.

  2. 2.

    Session key disclosure attack: In our scheme, we use the public-key cryptography technique to securely generate a dynamic session key. This session key is then used to communicate via a secret channel, i.e., the second address of SCR. Due to the presence of cipher operations and secrecy of address of DSS and SCR, our scheme can withstand this attack.

  3. 3.

    Stolen verifier attack: In our scheme, the server maintains a status table of every user identity. Passwords are not stored on AS instead verification mechanism is stored on SC. Each SC possesses a unique hSC(). Due to a unique verifier, i.e., hSC() and no verification table, our scheme can withstand this attack.

  4. 4.

    Brute force attack: In our scheme, the timestamp value is updated for every attempt to login into the system. After 3 attempts, an original timestamp associated with the correct password is deleted from SC. Due to the limit in the total number of login attempts, our scheme can withstand this attack.

  5. 5.

    Parallel session attack: In our scheme, the value of UID[Auth] becomes 1 after successful login. If the attacker initiates a second session with the same identity, then it is noted in the login phase that the value of UID[Auth] is 1 when an attempt to login is made. This is considered as an anomaly by the system. As the system is unable to judge which of these sessions is genuine, service is terminated and SC is blocked to protect private user data from becoming accessible to the attacker. Thus, our scheme can withstand this attack.

  6. 6.

    Plain Text Attack: In our scheme, we generate session keys by providing security through public-key cryptography. Once the secure session key is generated, it is used to transfer data through symmetric encryption. So our scheme can withstand this attack.

  7. 7.

    Insider attack: Data that are required to check user identity is stored on the smart card. An insider cannot access this data as it is not stored on AS. If SK is not generated at SC, then DSS cannot verify the identity of SC and the session will still be terminated. So an insider with access to data stored on AS or a privileged insider with access to modify and transmit data from AS cannot gain access to sensitive user data. So our scheme can withstand this attack.

  8. 8.

    Replay attack: After every successful login, the value of TSS gets updated at AS and SC. So verification parameter changes after every successful login. If the past session is re-played, then the TSS value will be different and it will be considered as an invalid attempt. So by using timestamps, our scheme resists this attack.

  9. 9.

    Relay attack: In the authentication phase and login phase, values are encrypted with the public key of AS which will not be accessible to the attacker. Also, the second address of SCR is transmitted by using a SK which is generated dynamically at SC. Due to the secrecy of SK and then cryptography of data using SK, our scheme can withstand this attack.

  10. 10.

    Reflection attack: In our scheme, we never transfer the value of TSS from AS to SC. Value of correct TSS isrequired to authenticate the user. After 3 failed attempts, SC is blocked. Due to the presence of cryptography and dynamic authentication tokens, our scheme can withstand this attack.

  11. 11.

    Masquerade attack: Known id and password of a genuine user are known to the attacker in this attack. Even after having the perfect credential of the user, the attacker does not possess the value of TSSwhich is stored on SC. Due to this 2 parameter authentication mechanism, our scheme can withstand this attack.

  12. 12.

    Modification attack: Messages which are in transit after authentication are encrypted using SK. Messages which are transmitted before authentication will either be discarded or considered as a failed login access. As a result, the attacker is not able to access user data and our system can withstand this attack.

  13. 13.

    Man-in-the-middle attack: Secret address of SCR is transmitted by using public-key cryptography in the authentication phase to AS. Messages transmitted after that are encrypted with SK generated in the authentication phase. An attacker cannot access data which is transmitted due to a lack of SK or dAS(). So our scheme can with stand this attack.

  14. 14.

    Denial-of-service attack: In our scheme, the address of DSS is kept secret and is known only to AS. Even after successful authentication, the proxy node is used to keep the identity of DSS secret from the user and thus the attacker. Due to the anonymity of the DSS address, our scheme can withstand this attack.

  15. 15.

    Forward secrecy attack: Dynamically generated secret values SAS and SSC are used for the generation of SK. All the messages which are transmitted are then transmitted by using key SK. So even if the current SK is revealed to the attacker, all the previously transmitted messages are not accessible to the attacker. Thus, our scheme can withstand a forward secrecy attack.

  16. 16.

    User impersonation attack: The user possesses SC and his own password to access the system. Even if someone gets access to SC, the user password is still not known to the attacker. After 3 failed attempts, the user card is blocked and the user is locked out of the system. Our system can thus withstand this attack.

  17. 17.

    Offline password guessing attack: AS is required to check is the login is successful or not. Even though the password verification mechanism is stored on SC, an attacker cannot check is the password is correct or not without including AS. After 3 wrong guesses by an attacker, SC is blocked as all the timestamp values present on SC will be replaced. After that even if the password entered is correct, the system will still display an invalid password. Our scheme thus resists this attack.

  18. 18.

    Server impersonation attack: In this attack, a malicious server is spoofed as a genuine AS. Even if the user cannot distinguish between the malicious server and genuine AS. The identity of DSS is known only to AS and thus an attacker can still not access user data stored on the server. Our scheme can thus withstand this attack.

4.4 Relative analysis of the proposed scheme

In Table 3, we compare our scheme in terms of common attacks and in Table 4 in terms of different functionalities provided by the schemes. From Table 4, we observe that no other scheme provides resistance to infinite login attempts. This means the attacker can try password guessing attempts and the system will not detect the malicious behavior. However, we provide a system which can detect and block a user by detecting such behavior.

Table 3 Relative Analysis of Scheme against Various Attacks
Full size table
Table 4 Relative analysis of scheme for various functionalities
Full size table

From Table 4, we also notice that server anonymity is only provided by our scheme. Server anonymity becomes crucial as all-important medical data of the user is stored on the server. Also, another important functionality provided by our scheme is the absence of biometric data. This functionality is important as this data cannot be modified by users if the biometric template of the user is compromised.

5 Conclusion and future work

TMIS is gaining popularity in these pandemic times, as it provides a more efficient and on-demand health evaluation system. It also helps the user to get medical advice from more experienced doctors, thus providing more feedback from doctors. Therefore, from our proposed system patients can get on-demand healthcare services at home, and they need not to visit the hospitals in this pandemic situation. Security of such system is of utmost importance as apart from internal working of the system, identity of the user and their secrets will also be made available to everyone if the system is compromised.

In this paper, we have presented a new approach for TMIS systems to authenticate and communicate with the user. We provided a new mechanism to provide anonymity of servers which are present in the system. Another key contribution of this paper is the mechanism to limit the total number of failed attempts for user login and block the card. We have then evaluated the proposed scheme formally and informally studied its performance against various attacks. We also have listed out key functionalities which are provided by the system.

Due to advancements in technology, we have focused to make the proposed scheme secure instead of lightweight. Further exploration can be done to detect tampering in smart cards, anomalies in user behavior, and block user access in such cases. The smart card reactivation phase could also be explored to make it an online system for increasing user convenience.