Smart card-based secure authentication protocol in multi-server IoT environment

In recent years, the internet of things has been widely utilized in various fields, such as in smart factories or connected cars. As its domain of application has expanded, it has begun to be employed using multi-server architectures for a more efficient use of resources. However, because users wishing to receive IoT(Internet of Things) services connect to multi-servers over wireless networks, this can expose systems to various attacks and result in serious security risks. To protect systems (and users) from potential security vulnerabilities, a secure authentication technology is necessary. In this paper, we propose a smart card-based authentication protocol, which performs the authentication for each entity by allowing users to go through the authentication process using a smart card transmitted from an authentication server, and to login to a server connected to the IoT. Furthermore, the security of our proposed authentication protocol is verified by simulating a formal verification scenario using AVISPA(Automated Validation of Internet Security Protocols and Applications), a security protocol-verification tool.

can occur in the network communication process of a multi-server IoT environment are as follows [7,12].

& User impersonation attack
In this kind of attack, assuming that the malicious attacker has knowledge of the user's login request message from the previous session with the IoT server, the attacker masquerades as the authorized user by deriving the login request message of the current session.
& Session key disclosure attack A public channel can occur when a user connects to the server over a wireless network. In this public channel, a malicious attacker can leak the session key by extracting the secret values. Through this attack, leakage and forgery/tampering of data stored on the server can occur.
& Denial-of-service attack If one or more attackers generate a large number of identical login request messages using their smart cards and send them to the server connected to the sensor, then there may be a problem in service availability in the server.

& Replay attack
In this type of attack, an attacker can authenticate the user from the server connected to the sensor by storing the message that was communicated to the authentication server in the previous session for the authenticated user, and retransmitting the message to the current session or a subsequent session.
& Server spoofing attack A malicious attacker can impersonate the IoT server when the user logs in. Therefore, the attacker can masquerade as the server to obtain the user login information.

& Invasion of privacy
Invasion of privacy is a violation of privacy through the revelation of private material, exposing various information and communication subjects of the user on the communication networks between the user and the server.

AVISPA
AVISPA is a tool that formally verifies the security of the internet protocol, and notifies the user with messages when it discovers attacks against the protocol [10]. AVISPA is composed of independently developed modules and the HLPSL, which is used as the input for the protocol specification. HLPSL is a module-type role-based language that can express various operators, as well as data flow and structure, intruder models, and complex security properties [15].
The roles can be divided into two types according to their purposes. One type consists of descriptions of the values required to describe each entity, and performs message transmission/ reception using SND and RCV commands. The other role is to contain the overall scenario, and include the contents of the declared constants, the information known to an attacker, and the verification properties for the authentication protocol.
Furthermore, AVISPA is automatically generated in intermediate format (IF) via the HLPSL2IF translator, and used as input to the OFMC(On-the-fly Model-Checker), CL-AtSe(CL-based Attack Searcher), SATMC(SAT-based Model-Checker), and TA4SP(Tree Automata-based Protocol Analyser) models. The schematic of its architecture is shown in Fig. 1 [2].

Proposed authentication protocol
The authentication protocol proposed in this paper consists of the user U i , IoT server S j , and authentication server CS. When the user logs into the IoT server, the protocol performs authentication for each entity. Table 1 lists the parameter values used in the proposed authentication protocol.
There are three phases in the proposed authentication protocol, and these are carried out in the following order: registration, login and authentication, and password change. CS is an authentication server that can be trusted, and it is responsible for the registration and authentication of the user and the IoT server. In addition, because the proposed authentication protocol employs timestamps, the authentication server CS, user U i and IoT server S j performs time synchronization.

Registration phase
During the registration phase, the user U i and the IoT server S j request registration to the authentication server CS. In return, the authentication server issues a smart card to the user U i , Fig. 1 Architecture of the AVISPA tool and sends the necessary values for the login and authentication phases to the IoT server S j . This process is illustrated in Fig. 2. STEP 1. S j sends its identification value SID j to CS via a secured channel, and CS computes the Serinfor j value that contains the information on the IoT server send to S j via secure channel.
STEP 2. U i chooses the user ID i and password P i , computes EncPass i , and sends the registration request message (ID I , EncPass i ,UID i ) with the user's anonymity values to CS.
CSgenerates the user's secret information value, Userinfor i , and stores UID i , Userinfor i , EncPass i , h( * ), and h(x) in the smart card.

Login and authentication phase
During the login and authentication phase, the verification of the legitimate smart card holder is performed. In order to login, the user U i sends a login request message to the IoT server S j , and CS performs the verification of each entity. Then, U i , S j , and CS all generate the same session key (Fig. 3). STEP 1. U i inserts the smart card into the card reader, and enters their ID, ID i , and password, P i . The smart card computes EncPass i ′ , and compares the information with EncPass i contained in the smart card. If the information matches, then the user is verified as the legitimate owner of the smart card. If the information does not match, then the session is terminated.
STEP 2. The user U i who is verified as the legitimate owner of the smart card, selects a random value N j1 to be generated for each session, and computes A i and Veru i with h(x) and UserInfor i contained in the smart card and the chosen random value N j1 . Then, the timestamp Ts is generated.
The user U i configures the login request message (A i , Veru i , UID i ,Ts) with his/her anonymity value UID i , computes A i and Ts, and sends the message to the IoT server S j . STEP 4. The IoT server S j that received the login request message from U i selects a random value N i2 to be generated for each session, and computes B i and Vers i using the Serinfor j value received in the registration phase.
The message is configured for the A i , UID i (received from the user U i ), S i 's own identification value SID j , B i (which was generated earlier), and the timestamp Ts. STEP 6. The CS that received the login request message from S i computes Ts ′ = Ts + 1, and then confirms whether ⊿Ts ≥ Ts ′ − Ts. Here, Ts ′ is the stamp for the time the server received the login message, and ⊿Ts is the minimum authentication time considering the time for the login message transmission. STEP 7. CS generates Serinfor j ′ using the received SID j value and its own master key, and extracts the N i2 value via the B i value received from the login request message.
Vers i ¼ ?Vers i 0 ð13Þ STEP 9. By using the UID i of the login request message, CS can search for Userinfor i from the verifier table generated in the registration phase. STEP 10. CS selects the random value N i3 and computes the N 0 i1 value using the received A i value, the generated h(x) and the previously retrieved Userinfor i . Using this computed N 0 i1 value and h(x), it generates the Veru i ′ value. Next, if this matches the Veru i value received with the login request message, then it is authenticated as a legitimate user, and generates the following session key SK. If it does not match, then the session is terminated.
STEP 11. The CS generates the timestamp Ts. Next, it computes C i , D i , and E i , and sends the mutual authentication message (C i , D i ,E i , Ts) to S i .
STEP 12. S i receives the mutual authentication message, and computes (N i1 ⊕ N i3 ) ′ via its own SID j value and the random value N i2 .
STEP 13. S i computes h(A‖h(x)) ′ via its own SID j value and the random value N i2 , using the D i value received in the mutual authentication message. It generates the session key SK by on operating its own random value N i2 with the previously computed (N i1 ⊕ N i3 ) ′ . Next, S i computes E i and sends a login response message (E i , Ts) to the user U i .
STEP 14. After receiving the login request message from the S i , the user U i computes Ts ′ = Ts + 1 to confirm that ⊿Ts ≥ Ts ′ − Ts. Ts ′ is the timestamp for when the login message is received by the server, and ⊿Ts is the minimum authentication time considering the transmission time for the login message. STEP 15. By using the E i value received in the mutual authentication message, U i can compute the (N i2 ⊕ N i3 ) ′ value via the A i value generated by the user and the h(x) value contained in the smart card.
STEP 16. U i can operate on its own random value N i1 with (N 2 ⊕ N 3 ) ′ that was computed earlier, and can generate the session key SK via its own A i value and the h(x) value contained in the smart card. Therefore, the user U i , IoT server S j , and authentication server CS can perform the authentication by generating the same session key.

Password change phase
The password change phase is the process performed when the user U i wants to change their password P i to a new one P i NEW . The process is illustrated in Fig. 4. STEP 1. The user U i inserts a smart card into the card reader and inputs their ID, ID i , and password, P i . The smart card computes EncPass i and generates Userinfor i ′ using the computed EncPass i . , and enters this into the smart card.
STEP 4. By using the EncPass i NEW generated in the above process, the new Userinfor i NEW can be computed, and the existing Userinfor i is replaced with Userinfor i NEW , which is stored in the smart card. In this manner, the password change process is completed.

Authentication protocol specification utilizing HLPSL
In this study, we use the AVISPA web tool for the formal verification of the authentication protocol. The AVISPA web tool can specify the authentication protocol with the CAS and HLPSL languages. This section explains the registration, and login and authentication phases of the proposed authentication protocol written in the HLPSL language. Because AVISPA is a role-based language, it assigns a role to each participant. It is composed of role_U, which represents the user, role_S, which is assigned to the IoT server, and role_CS, representing the authentication server. In the role environment (), the constants used by the specified protocol are defined, and can specify the property values known to the attacker. In addition, secrecy_of and weak_authentication_on are specified depending on the goal, in order to add the secrecy () and witness () functions. These functions are used to verify the security and authentication. The security and authentication are the properties of the protocol's verification. In the part where the formula is specified, concatenation can be expressed as B.^, xor operates as Bxor(A, B)^and the exponent E N operates as Bexp(E, N).^In addition, in the part where each role is specified, the message specified as RCV can be transmitted, and the received contents can be expressed as SND.
This section deals with the specifications for the sent and received messages, and for the security properties. Table 3 details the specification of the user, and Table 4 concerns the specification of the IoT server. Table 5 presents the specification of the authentication server, and Table 6 illustrates the role environment, which contains the specified constants. Finally, Table 7 shows the specification of the goal, by specifying a function to verify the authentication protocol.
4 Security analysis 4.1 User impersonation (i.e., masquerading) attack An attacker impersonates the authorized user by extracting the login request message of the current session, assuming that he/she knows the login request message from the previous session of the IoT server.
Assume that the attacker has learned the login message (UID i , A i , Ts) of the previous session via the public channel. Then, because the malicious attacker cannot compute EncPass i , the random value N i1 , and h(x), they cannot compute A i , which is composed of the Userinfor i ⊕ h(x) ⊕ N i1 operation. Therefore, they cannot extract the login request message for the current session by impersonating the authorized user, and the proposed authentication protocol is secure against user impersonation attacks.

Session key disclosure attack
Assuming that an attacker can intercept and steal A i , B i , C i , D i , and E i through the previous session via public channels, they still cannot extract the session key. The attacker cannot Table 3 Specification for the user compute Userinfor i and N i1 through the known value of A i because they cannot determine h(X). Furthermore, the attacker cannot compute the value N i2 via the publicly accessible B i value, because they cannot determine Serinfor j . For the same reason, the attacker cannot extract the random values N i1 , N i2 , and N i3 selected by the user U i , IoT server S j , and the authentication server CS, respectively, from the published C i , D i , and E i values and h(x) generated by the authentication server CS. Therefore, the proposed authentication protocol is secure against such attacks involving session key leakages.

Denial-of-service (Dos) attack
When an attacker uses their own smart card to send a large number of identical login request messages (A K1 , UID K1 ,Ts), (A K2 , UID K2 ,Ts),…, (A Kn , UID Kn ,Ts), the IoT server S j may experience problems with its availability. However, in the registration phase the value of the status bit is stored as 1, using the verifier table given in Table 2. In this manner, the proposed protocol is designed not to receive such login request messages. Thus, the proposed authentication protocol is secure against the denial-of-service attacks.

Replay attack
The proposed authentication protocol uses the timestamp for the authentication of messages in communications between the user U i , the IoT server S j , and the authentication server CS. Therefore, if an attacker participates in a session to perform eavesdropping (i.e., sniffing) or forgery/tampering attacks on transmitted or received messages, the value of the timestamp Ts changes, and the protocol terminates the session. Table 5 Specification for the authentication server Table 6 Specification for the role environment

Server spoofing attack
In a server spoofing attack, an attacker impersonates an IoT server to obtain the desired information. However, in the login phase of the proposed authentication protocol, the authenticated user is identified via the verification of the smart card as EncPass i = ? EncPass i ′ .
Because the session is terminated if this does not match, the attacker cannot masquerade as the IoT server. Thus, the proposed authentication protocol is secure against server spoofing attacks, because it verifies the IoT server S i by checking Vers i = ? Vers i ′ with the CS.

Invasion of privacy
Invasion of privacy is the infringement of privacy by exposing information regarding the subject during a communication procedure on a network. However, the proposed authentication protocol uses the identifiers of the user and the IoT server, UID i and SID j , and the anonymity value, to perform the communication procedure. Therefore, when the transmitted/received messages on a network are thought to have been eavesdropped, the communication subject cannot be identified, thus ensuring the privacy of the user and the IoT server.

Experimental result through formal verification
In this section, we analyze the experimental results by employing AVISPA, a formal verification tool for the authentication protocol, where the registration phase and login and authentication phase are specified using the HLPSL language, as described in Section 3.4. The result of executing the specified HLPSL code file using the AVISPA web tool is shown in Fig. 5. From left to right, the figure shows CS, S j , and U i . The authentication messages are Table 7 Specification for the goal transmitted and received through eight main phases, including the registration phase. However, in practice, authentication messages are transmitted and received in 10 phases, because the C i , D i , and E i values sent to S j from CS are divided and transmitted sequentially.
The secret() and witness() functions and the verification properties for the authentication protocol were employed in the goal of the HLPSL created in Section 3.4 for verification. For the secret () and witness () functions shown in Table 7, the specified security properties are as follows: 1. secret(P′,auth_1,{U,S}) This pertains to the login and authentication phase of STEP 3, and verifies whether the secrecy of P i in the login request message (A i , UID i ,Ts) between the user U i and IoT server S i is satisfied.

secret(H(X),auth_2,{U,S})
This pertains to the login and authentication phase of STEP 3, and verifies whether the secrecy of h(X) in the login request message (A i , UID i ,Ts) between the user U i and IoT server S i is satisfied.

secret(NU',auth_3,{U,S})
This pertains to the login and authentication phase of STEP 3, and verifies whether the secrecy of N i1 in the login request message (A i , UID i ,Ts) between the user U i and IoT server S i is satisfied. This pertains to the login and authentication phase of STEP 5, and verifies whether the secrecy of N i2 in the login request message (UID i , A i , Veru i , B i , Vers i , SID j , Ts) between the IoT server S j and the authentication server CS is satisfied.

secret(H(SId.H(X)),auth_5,{S,CS})
This pertains to the login and authentication phase of STEP 5, and verifies whether the secrecy of Serinfor j in the login request message (UID i , A i , Veru i , B i , Vers i , SID j , Ts) between the IoT server S j and the authentication server CS is satisfied.

secret(NCS',auth_6,{CS,S})
This pertains to the login and authentication phase of STEP 11, and verifies whether the secrecy of N i3 in the mutual authentication message (C i , D i ,E i , Ts) between the authentication server CS and the IoT server S i is satisfied.

secret(NS,auth_7,{CS,S})
This pertains to the login and authentication phase of STEP 11, and verifies whether the secrecy of N i2 in the mutual authentication message (C i , D i ,E i , Ts) between the authentication server CS and the IoT server S i is satisfied.

secret(NU,auth_8,{CS,S})
This pertains to the login and authentication phase of STEP 11, and verifies whether the secrecy of N i1 in the mutual authentication message (C i , D i ,E i , Ts) between the authentication server CS and IoT server S i is satisfied.

secret(H(X),auth_9,{CS,S})
This pertains to the login and authentication phase of STEP 11, and verifies whether the secrecy of h(X) in the mutual authentication message (C i , D i ,E i , Ts) between the authentication server CS and the IoT server S i is satisfied.

secret(NU,auth_10,{S,U})
This pertains to the login and authentication phase of STEP 13, and verifies whether the secrecy of N i1 in the login response message (E i , Ts) between the IoT server S i and the user U i is satisfied. 11. witness(CS,S,auth_11,xor(H(SId.X),NS')) This pertains to the login and authentication phase of STEP 8, and the authentication server CS verifies whether the IoT server S j is authenticated through the Vers i value in the login request message (UID i , A i , Veru i , B i , Vers i , SID j , Ts) sent to the IoT server S j .
12. witness(CS,U,auth_12,xor(xor (H(H(ID.H(P)).X),H(X)),NU')) This pertains to the login and authentication phase of STEP 10, and the authentication server CS verifies whether the user U i is authenticated through the Vers i value in the login request message (UID i , A i , Veru i , B i , Vers i , SID j , Ts) sent to the IoT server S j . 13. witness(S,CS,auth_13, xor(xor(NU',NCS'),H(xor(SId,NS')))) This pertains to the login and authentication phase of STEP 12, and the IoT server S j verifies whether the authentication server CS is authorized through the C i value in the mutual authentication message (C i , D i ,E i , Ts) sent to the authentication server CS.
14. witness(U,S,auth_14,xor(xor(NS',NCS'),H(xor(xor (H(H(ID.H(P)).X), H(X)),NU).H(X)))) This pertains to the login and authentication phase of STEP 15, and the user U i verifies whether the IoT server S j is authenticated through the E i value in the mutual authentication message (E i , Ts) sent to the IoT server S j .
In this study, the formal verification of the authentication protocol is performed through the OFMC and CL-AtSe models, as shown in Figs. 5. and 6. It can be seen that the h(x), N i1 ,N i2 , and N i3 values, which should be kept secret during the process of sending/receiving messages in the proposed authentication protocol, are not exposed to an attacker. Furthermore, through the verification performed by each entity, it was possible to confirm that the authentication performed between the user U i , IoT server S j , and authentication server CS was securely authenticated.

Conclusion
In recent years, as the scope of applications of IoT has broadened, the amount of data generated in IoT has become enormous, and the multi-server architecture has been utilized to manage this scenario efficiently. In a multi-server IoT environment, a user can manage and receive information collected by a sensor by connecting to a server via wireless networks from remote locations. However, if a malicious attacker accesses a communication network by exploiting a vulnerable authentication system, the system can be exposed to user impersonation and session key leakage attacks. Thus, a secure authentication protocol is required to prevent this. Therefore, in this paper, we propose a secure authentication protocol to analyze and respond to security threats that may occur in a multi-server IoT environment. The proposed authentication protocol has been shown to be secure against user impersonations, session key leakage attacks, as well as various other attacks. The verification properties are specified by utilizing the formal specification language HLPSL. By using the formal verification tool AVISPA, the security of the required verification properties has also been verified through the results of our experiments.
The authentication protocol proposed in this paper is expected to be employed in applications such as key exchanges using smart cards, as well as applications in various other fields.