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

Abstract

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.

1 Introduction

By enabling devices such as machines to exchange information with embedded software, sensors, and so on via internet networks and consequently enhancing the functionality and performance of individual devices, the IoT enables the provision of new intelligent services. In recent years, as the applications of the IoT have expanded, it has undergone considerable progress through interactions with a diverse range of other industries, and has been employed in various applications such as smart factories, intelligent buildings, and connected cars [11].

Although the IoT is utilized in various fields, the performance of its sensors is not particularly high. Therefore, it is employed with multi-servers, in order to increase the resource efficiency. In particular, in terms of reducing the number of operations, the authentication protocol of a smart card-based multi-server environment involves the operations of one-way functions and the exclusive or (XOR) function. Thus, this authentication protocol has been the subject of ongoing research [1, 3,4,5,6].

However, if the multi-server authentication system is vulnerable, then attacks such as user impersonation, session key leakages, and replay attacks may occur in the process of connecting to the multi-server where the user stores IoT information over wireless networks [8]. This may result in leakages of confidential information by an unauthorized attacker, data sniffing and forgery/tampering, and other attacks during the communication process, and may lead to issues with the service availability of the multi-server [9, 13, 14]. Therefore, to mitigate the potential security vulnerabilities in a multi-server IoT environment, a secure authentication protocol is required.

In this study, we analyze the threats that may occur in multi-server IoT environment networks during the communication process, and propose a secure authentication protocol that can respond to such security threats. In addition, we verify the security of the proposed protocol by performing a formal verification of the proposed authentication protocol using the AVISPA.¹

In the authentication protocol proposed in this paper, a user logs in to the IoT server using a smart card, and the authentication server can verify the user and the IoT server. By generating the same session key, the authentication process between the user, the IoT server, and the authentication server is performed. The composition of this paper is as follows.

In Section 2, we describe the security threats that may occur in a multi-server IoT environment and explain AVISPA, a formal verification tool for security protocols. In Section 3, we propose a secure authentication protocol for multi-server IoT environments, and describe the authentication protocol specified by the HLPSL(high-level protocol specification language). In Section 4, we describe the security analysis of the proposed protocol, and in Section 5, we simulate the formal verification of the authentication protocol via AVISPA. Finally, our conclusions are listed in Section 6.

2 Related work

2.1 Multi-server IoT security threats

The vast amount of data collected by sensors connected to a multi-server can be considered an attractive target for attackers. In a multi-server IoT environment, a user may access the multi-server over a wireless network, which can be a serious security threat. The security threats that 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.

2.2 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].

Fig. 1

Architecture of the AVISPA tool

3 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.

Table 1 Notation used in the proposed 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.

3.1 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, and sends the necessary values for the login and authentication phases to the IoT server S_j . This process is illustrated in Fig. 2.

Fig. 2

Registration phase

• 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.

$$ Serinfo{r}_j=h\left({SID}_j\parallel x\right) $$

(1)

• 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.

$$ EncPas{s}_i=h\left({ID}_i\parallel h\left({P}_i\right)\right) $$

(2)

• STEP 3. 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.

$$ {Userinfor}_i=h\left( EncPas{s}_i\parallel x\right) $$

(3)

• STEP 4. CS stores the user secret information value Userinfor_i, the user’s anonymity value UID_i, and the status-bit value in the verifier table. If the user performs the registration process, then the status-bit value is stored as 1, and if there is no registration then the value is stored as 0. The verifier table is presented in Table 2.

Table 2 The verifier table

• STEP 5. CS issues the smart card to the user U_i.

3.2 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).

Fig. 3

Login and authentication phase

• 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.

$$ {EncPass_i}^{\hbox{'}}=h\left({ID}_i\parallel h\left({P}_i\right)\right) $$

(4)

$$ {EncPass}_i=?{EncPass_i}^{\hbox{'}} $$

(5)

• 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.

$$ {A}_i= Userinfo{r}_i\oplus h(x)\oplus {N}_{i1} $$

(6)

$$ {Veru}_i=h\left(h(x)\Big\Vert {N}_{i1}\right) $$

(7)

• STEP 3. 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.

$$ {B}_i= Serinfo{r}_j\oplus {N}_{i2} $$

(8)

$$ {Vers}_i=h\left(h\left( SI{D}_j\Big\Vert x\right)\Big\Vert {N}_{i2}\right) $$

(9)

• STEP 5. S_i sends the login request message (UID_i,  A_i, Veru_i, B_i, Vers_i, SID_j, Ts) to CS. 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.

$$ Serinfo{r_j}^{\prime }=h\left({SID}_j\parallel x\right) $$

(10)

$$ {N_{i2}}^{\prime }= Serinfo{r_j}^{\prime}\oplus {B}_i $$

(11)

• STEP 8. By using the computed N_i2^′ value, CS generates the Vers_i^′ value, and if this matches the B_i value received by the login request message, it is authenticated as the legitimate IoT server S_j; if not, the session is terminated.

$$ {Vers_i}^{\prime }=h\left(h\left( SI{D}_j\Big\Vert x\right)\Big\Vert {N_{i2}}^{\prime}\right) $$

(12)

$$ {Vers}_i=?{Vers_i}^{\prime } $$

(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}_{i1}^{\prime }$value using the received A_i value, the generated h(x) and the previously retrieved Userinfor_i. Using this computed ${N}_{i1}^{\prime }$ 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.

$$ {N}_{i1}^{\prime }= Userinfo{r}_i\oplus h(x)\oplus {A}_i $$

(14)

$$ {Veru_i}^{\prime }=h\left(h(x)\Big\Vert {N_{i1}}^{\prime}\right) $$

(15)

$$ {Veru}_i=?{Veru_i}^{\prime } $$

(16)

$$ {SK}_i=h\left(h\left(A\Big\Vert h(x)\right)\oplus h\left({N}_{i1}\oplus {N}_{i2}\oplus {N}_{i3}\right)\right) $$

(17)

• 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.

$$ {C}_i={N}_{i1}\oplus {N}_{i3}\oplus h\left( SI{D}_j\oplus {N}_{i2}\right) $$

(18)

$$ {D}_i=h\left(A\Big\Vert h(x)\right)\oplus h\left( SI{D}_j\oplus {N}_{i2}\right) $$

(19)

$$ {E}_i={N}_{i2}\oplus {N}_{i3}\oplus h\left(A\Big\Vert h(x)\right) $$

(20)

• 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.

$$ {\left({N}_{i1}\oplus {N}_{i3}\right)}^{\prime }={C}_i\oplus h\left( SI{D}_j\oplus {N}_{i2}\right) $$

(21)

• 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.

$$ h{\left(A\Big\Vert h(x)\right)}^{\prime }={D}_i\oplus h\left( SI{D}_j\oplus {N}_{i2}\right) $$

(22)

$$ {SK}^{\prime }=h{\left(h{\left(A\Big\Vert h(x)\right)}^{\prime}\oplus h\left({N}_{i1}\oplus {N}_{i2}\oplus {N}_{i3}\right)\right)}^{\prime } $$

(23)

$$ {E}_i=\left({N}_{i2}\oplus {N}_{i3}\right)\oplus h\left(A\Big\Vert h(x)\right) $$

(24)

• 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.

$$ {\left({N}_{i2}\oplus {N}_{i3}\right)}^{\prime }={E}_i\oplus h\left(A\Big\Vert h(x)\right) $$

(25)

• STEP 16. U_i can operate on its own random value N_i1 with (N₂ ⊕ N₃)^′ 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.

$$ {SK}^{\prime \prime }=h\left(A\Big\Vert h(x)\right)\oplus {\left({N}_{i1}\oplus {N}_{i2}\oplus {N}_{i3}\right)}^{\prime } $$

(26)

3.3 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.

Fig. 4

Password change phase

• 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.

$$ EncPas{s}_i=h\left({ID}_i\parallel h\left({P}_i\right)\right) $$

(27)

$$ {Userinfor_i}^{\prime }=h\left( EncPas{s}_i\parallel x\right) $$

(28)

• STEP 2. The smart card compares the generated Userinfor_i^′ with Userinfor_i contained in the smart card. If these match, then the user is verified as the legitimate owner of the smart card, and the user can change the password. The smart card requests a new password.

$$ {Userinfor}_i=?{Userinfor_i}^{\prime } $$

(29)

• STEP 3. Once verified as the legitimate smart card owner, the user enters the new password P_i^NEW, generates EncPass_i^NEW, and enters this into the smart card.

$$ EncPas{s_i}^{NEW}=h\left({ID}_i\parallel h\left({P_i}^{NEW}\right)\right) $$

(30)

• STEP 4. By using the EncPass_i^NEW generated in the above process, the new Userinfor_i^NEWcan 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.

$$ {Userinfor_i}^{NEW}=h\left( EncPas{s_i}^{NEW}\parallel x\right) $$

(31)

3.4 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 “.”, xor operates as “xor(A, B)” and the exponent E^N operates as “exp(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.

Table 3 Specification for the user

Table 4 Specification for the IoT server

Table 5 Specification for the authentication server

Table 6 Specification for the role environment

Table 7 Specification for the goal

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.

4.2 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 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.

4.3 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.

4.4 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.

4.5 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.

4.6 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.

5 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 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.

Fig. 5

Execution screen of the AVISPA

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.

• 2. 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.

• 3. 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.

• 4. secret(NS’,auth_4,{S,CS})

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.

• 5. 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.

• 6. 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.

• 7. 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.

• 8. 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.

• 9. 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.

• 10. 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_ivalue 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.

Fig. 6

a Simulation result for the AVISPA tool under the OFMC model.; b Simulation result for the AVISPA tool under the CL-AtSe model

6 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.