FVF-AKA: A Formal Verification Framework of AKA Protocols for Multi-server IoT

2.1 AKA Protocols for Multi-server IoT

Multi-server architectures are applied in IoT for better resource utilization. Users register on many service-providing servers to access numerous network services, but it is difficult for them to remember different identities and passwords. More importantly, communication in multi-server architectures of a wireless environment is vulnerable to malicious attacks. In order to provide convenience to users while protecting user privacy, AKA protocols for multi-server IoT are proposed [26, 59]. There are usually three types of entities in the AKA protocol, which are also depicted in the upper left picture of Figure 1. They are the user, service-providing server (SPS), and control server (CS). SPSs provide services to users. CS is responsible for the user’s registration and authentication, which is a trusted third party. Common notations used in the AKA protocol for multi-server IoT are illustrated in Table 1. The registration phase and authentication phase are two important phases in the AKA protocol. In the registration phase, the user and SPS complete their registrations on CS, respectively. In the authentication phase, the user, SPS, and CS can share the same session key to support subsequent secure data transmission.

Fig. 1.

View Figure

The verifier table is designed for CS to record user-related information during the registration phase. CS can retrieve the corresponding user-related information during the authentication phase to compute special elements. We select two relatively mature AKA protocols based on whether they have a verifier table or not. One is an identity-based AKA protocol without verifier tables proposed by Xue et al. [59]. It improved the protocol proposed by Li et al. [36] to resist some types of known attacks. The other is a relatively new AKA protocol with verifier tables introduced by Bae and Kwak [26]. It can respond to several security threats. The AKA protocols focus on the communication process between users and servers to establish a session key shared between the entities, which is the biggest similarity between most of the AKA protocols. The difference is that Bae and Kwak’s and Xue et al.’s protocols are two typical protocols with verifier tables and without verifier tables, respectively.

Xue et al.’s protocol is a typical AKA protocol without verifier tables, while Bae and Kwak’s protocol is a typical AKA protocol with verifier tables. Fortunately, FVF-AKA supports the modeling of both, which reflects that we provide support for these two basic types. We make the article more comprehensive by describing how our framework models different classes of AKA protocols. Specifically, to further support modeling the AKA protocol with verifier tables, we have added a formal description of the verifier table in the framework. For example, we give actions checkUID and StoreTable (highlighted with gray in Table 3) in the CSP model. Meanwhile, functions BuildStoreTable() and BuildCheckUID() involved in the automatic conversion (in Section 5) assist to construct the PAT codes of the two actions, which are also highlighted with gray in Table 4.

Table 2.

View Table

Table 2. The CSP Models of Entities in Xue et al.’s AKA Protocol

Table 3.

View Table

Table 3. The CSP Models of Entities in Bae and Kwak’s AKA Protocol

2.2 CSP

In this subsection, we give a short introduction to formal methods of CSP [13, 22]. It is a process algebra proposed by Hoare in 1978. As one of the most mature formal methods, it is tailored for describing the interaction between concurrency systems by mathematical theories. Because of its well-known expressive ability, CSP has been widely used in many fields [20, 40, 44, 45].

CSPs are constituted by primitive processes and actions. We use the following syntax to define the processes in this article, whereby \({\it P}\) and \({\it Q}\) represent processes, and the alphabets \(\alpha ({\it P})\) and \(\alpha ({\it Q})\) mean the set of actions that the processes \({\it P}\) and \({\it Q}\) can take, respectively. \({\it a}\) and \({\it b}\) denote the atomic actions, and \({\it c}\) stands for the name of a channel. In addition, \({\it e}\), \({\it x}\), and \({\it B}\) represent the message, the variable, and the condition, respectively: \(\begin{align*} {\it P,Q =} ~& {\textit {S}kip} \mid {\textit {S}top} \mid {\it a} \rightarrow {\it P} \mid {\it c?x} \rightarrow {\it P} \mid {\it c!e} \rightarrow {\it P} \mid {\it P}\, \Box {\it Q} \\ & \mid {\it P}\Vert {\it Q} \mid {\it P}|||{\it Q} \mid {\it P} \lhd {\it B} \rhd {\it Q} \mid {\it P;Q} \mid {\it P}[[{\it a}\leftarrow {\it b}]], \end{align*}\) where:

Model checker PAT [53] is designed as an extensible and modularized framework based on CSP. Different model checking techniques are implemented in PAT, supporting many assertions, such as deadlock freeness and reachability [48].

2.3 Formal Verification Framework of AKA Protocols for Multi-server IoT

As AKA protocols for multi-server IoT lack a unifying verification framework, we design the FVF-AKA. It can provide better security verification supporting future AKA protocols for multi-server IoT. As shown in Figure 1, FVF-AKA consists of the following five steps:

3.1 A Lightweight Dynamic Pseudonym Identity-based AKA Protocol for Multi-server IoT

Xue et al. discovered that Li et al.’s protocol [36] cannot resist some types of known attacks and proposed a lightweight dynamic pseudonym identity-based AKA protocol for multi-server architecture [59]. Their protocol not only includes the security features in Li et al.’s protocol but also provides some other security features, such as traceability and identity protection. This protocol is well suited for deployment within a multi-server IoT environment, as it supports multi-server architectures.

3.1.1 Registration Phase.

Figure 2 shows the registration phase in Xue et al.’s protocol. Here, the dotted line represents the secure channel, and the solid line represents the public channel. The user U\(_i\) chooses a random number d and his/her password P\(_i\). U\(_i\) computes A\(_i\)=h(b\(\Vert\)P\(_{i}\)) and sends the message \(\lbrace\)ID\(_i\), b, A\(_i\)\(\rbrace\) to CS (step 1 in Figure 2). The control server CS chooses two random numbers x and y. CS computes PID\(_i\)=h(ID\(_i\)\(\Vert\)b) and B\(_i\)=h(PID\(_i\)\(\Vert\)x). \(PID_i\) is the protected pseudonym identity of \(U_i\). Then B\(_i\) is submitted to U\(_i\) by CS (step 2 in Figure 2). After receiving the message from CS, U\(_i\) computes C\(_i\)=h(ID\(_i\)\(\Vert\)A\(_i\)) and D\(_i\). In addition, we find an error in Xue et al.’s protocol about the computation of D\(_i\). It should be changed to D\(_i\)=B\(_i\)\(\oplus\)C\(_i\); otherwise the session key SK cannot be unified. They are included in the smart card, which is (C\(_i\), D\(_i\), h(\(\cdot\)), b) (step 3 in Figure 2).

Fig. 2.

View Figure

The service-providing server S\(_j\) first selects a random number d and sends it to CS with its identity SID\(_j\) (step 4 in Figure 2). Then, CS computes PSID\(_j\)=h(SID\(_j\)\(\Vert\)d) and BS\(_j\)=h(PSID\(_j\)\(\Vert\)y) and transmits BS\(_j\) to S\(_j\) (step 5 in Figure 2). PSID\(_j\) is the protected pseudonym identity of S\(_j\).

3.1.2 Authentication Phase.

Figure 3 illustrates the authentication phase in Xue et al.’s protocol, which includes five steps. Step 1 and step 5 describe the computation and message transmission of user U\(_i\). Step 2 and step 4 give the computation and message transmission of server S\(_i\). The computation and message transmission of server S\(_i\) are denoted in step 3.

Fig. 3.

View Figure

STEP 1.	A current timestamp value TS\(_i\) is created by U\(_i\). U\(_i\) also selects a random number N\(_{i1}\). Then U\(_i\) computes B\(_i\), F\(_i\), P\(_{ij}\), CID\(_i\), and G\(_i\) as below: \(\begin{align*} &{B_i}= {D_i}\oplus {C_i}~~~{F_i}= {B_i}\oplus {N_{i1}}~~~{P_{ij}}= {h}({B_i}\oplus {h}({N_{i1}}\Vert {SID_j}\Vert {PID_i}\Vert {TS_i}))\\ &{CID_{i}}= {ID_i}\oplus {h}({B_i}\Vert {N_{i1}}\Vert {TS_i}\Vert ``00\hbox{''}))~~~{G_{i}}= {b}\oplus {h}({B_i}\Vert {N_{i1}}\Vert {TS_i}\Vert ``11\hbox{''})) \end{align*}\) Here “00” and “11” represent a 2-bit binary “0” and a 2-bit binary “1,” respectively. After the computation, the user U\(_i\) sends the message \(\lbrace\)F\(_i\), P\(_{ij}\), CID\(_i\), G\(_i\), PID\(_i\), TS\(_i\)\(\rbrace\) to the service-providing server S\(_j\).
STEP 2.	When S\(_j\) receives the message from U\(_i\), it checks the session delay. TS\(_j\) and \(\Delta\)T are assumed to be the current time and the tolerable time interval, respectively. If TS\(_j\) - TS\(_j\) \(\gt\) \(\Delta\)T, the session times out and S\(_j\) terminates the session. Otherwise, the following operations are performed by S\(_j\). It chooses a random number N\(_{i2}\) and computes J\(_i\), K\(_i\), L\(_i\), and M\(_i\) as below: \(\begin{align*} &{J_i}= {BS_j}\oplus {N_{i2}}~~~{L_i}= {SID_{j}}\oplus {h}({BS_{j}}\Vert {N_{i2}}\Vert {TS_{i}}\Vert ``00\hbox{''})\\ &{K_i}= {h}({N_{i2}}\Vert {BS_j}\Vert {P_{ij}}\Vert {TS_{i}})~~~{M_{i}}= {d}\oplus {h}({BS_{j}}\Vert {N_{i2}}\Vert {TS_{i}}\Vert ``11\hbox{''}) \end{align*}\) The message \(\lbrace\)F\(_i\), P\(_{ij}\), CID\(_i\), G\(_i\), PID\(_i\), TS\(_i\), J\(_i\), K\(_i\), L\(_i\), M\(_i\), PSID\(_j\)\(\rbrace\) is submitted to CS by S\(_j\).
STEP 3.	At first, CS checks whether the session delay is within the time interval \(\Delta\)T when getting the message from S\(_j\). TS\(_{CS}\) is assumed to be the current time. If TS\(_{CS}\) - TS\(_i\) \(\gt\) \(\Delta\)T, the session times out and CS ends the session. Otherwise, CS computes BS\(_j\)=h(PSID\(_j\)\(\Vert\)y), N\(_{i2}\)=J\(_i\)\(\oplus\)BS\(_j\), and K’=h(N\(_{i2}\)\(\Vert\)BS\(_{j}\)\(\Vert\)P\(_{ij}\)\(\Vert\)TS\(_{i}\)). CS verifies whether K\(_{i}^{\prime }\) is equal to K\(_{i}\) or not. If not, the session is terminated by CS. Otherwise, CS calculates the following elements: \(\begin{align*} &{ B_i}= { h}({ PID_{i}}\Vert { x})~~~{ N_{i1}}={ F_{i}}\oplus { B_i}~~~{ ID_i}= { CID_{i}}\oplus { h}({ B_{j}}\Vert { N_{i1}}\Vert { TS_{i}}\Vert ``00\hbox{''})\\ &{ SID_{i}}= { L_{i}}\oplus { h}({ BS_{j}}\Vert { N_{i2}}\Vert { TS_{i}}\Vert 11\hbox{''})~~~{ P_{ij}^{\prime }}= { h}({ B_{i}}\oplus { h}({ N_{i1}}\Vert { SID_{j}}\Vert { PID_{i}}\Vert { TS_{i}})) \end{align*}\) Then CS verifies the equivalence between P\(_{ij}\) and P\(_{ij}^{\prime }\). If they are equal, CS finishes the session. Otherwise, CS calculates b, d, PID\(_i^{\prime }\), and PSID\(_{j}^{\prime }\) as below: \(\begin{align*} &{ b}= { G_{i}}\oplus h({ B_{i}}\Vert { N_{i1}}\Vert { TS_{i}}\Vert ``11\hbox{''})~~~{ PID_i^{\prime }}= { h} ({ ID_{i}}\Vert { b})\\ &{ d}={ M_{i}}\oplus { h}({ BS_{j}}\Vert { N_{i2}}\Vert { TS_{i}}\Vert ``11\hbox{''})~~~{ PSID_{j}^{\prime }}= { h}({ SID_{j}}\Vert { d}) \end{align*}\) CS verifies whether PID\(_i^{\prime }\) and PSID\(_j^{\prime }\) equal PID\(_i\) and PSID\(_j\), respectively. If not, CS terminates the session. Otherwise, CS confirms that the messages are from legal U\(_i\) and S\(_j\). A random number N\(_{i3}\) is selected, and CS computes P\(_i\), Q\(_i\), R\(_i\), and V\(_i\) as below: \(\begin{align*} &{ \textit{P_{i}}}= { N_{i1}}\oplus{ N_{i3}}\oplus h({ SID_{j}}\|{ N_{i2}}\|{ BS_{j}})~~~{ Q_{i}}={ h}({ N_{i1}}\oplus{ N_{i3}})\\ &{ R_i}= { N_{i2}}\oplus { N_{i3}}\oplus{ h}({ ID_{i}}\|{ N_{i1}}\|{ B_{i1}})~~~{ V_{i}}= { h}({ N_{i2}}\oplus { N_{i3}}) \end{align*}\) Then CS transmits the message \(\lbrace\)P\(_i\), Q\(_{i}\), R\(_i\), V\(_i\)\(\rbrace\) to S\(_i\). CS also computes the session key SK as below: \(\begin{align*} &{ SK}={ h}(({ N_{i1}}\oplus { N_{i2}}\oplus { N_{i3}})\Vert { TS_{i}}) \end{align*}\)
STEP 4.	When S\(_{j}\) receives the message from CS, it computes N\(_{i1}\)\(\oplus\)N\(_{i3}\) and Q\(_{i}^{\prime }\) as below: \(\begin{align*} &({ N_{i1}}\oplus { N_{i3}})^{\prime }= { P_{i}}\oplus { h} ({ SID_{i}}\Vert { N_{i2}}\Vert { BS_{j}})~~~{ Q_{i}^{\prime }}={ h}(({ N_{i1}}\oplus { N_{i3}})^{\prime }) \end{align*}\) Then S\(_{j}\) verifies whether Q\(_{i}^{\prime }\) and Q\(_{i}\) are equal or not. If not, S\(_{j}\) finishes the session. Otherwise, S\(_{j}\) verifies the legitimacy of CS and U\(_{j}\). After the verification, S\(_{j}\) transmits the message \(\lbrace\)R\(_{i}\), V\(_{i}\)\(\rbrace\) to U\(_{i}\). The session key SK\(^{\prime }\) can be obtained by S\(_{j}\) as below: \(\begin{align*} &{ SK^{\prime }}={ h}(({ N_{i2}}\oplus ({ N_{i1}}\oplus { N_{i3}})^{\prime })\Vert { TS_{i}}) \end{align*}\)
STEP 5.	When receiving the message from S\(_{j}\), U\(_{i}\) computes (N\(_{i2}\)\(\oplus\)N\(_{i3}\))\(^{\prime }\) and V\(_{i}^{\prime }\): \(\begin{align*} &({ N_{i2}}\oplus { N_{i3}})^{\prime }= { R_{i}}\oplus { h} ({ ID_{i}}\Vert { N_{i1}}\Vert { B_{i}})~~~{ V_{i}^{\prime }}={ h}(({ N_{i2}}\oplus { N_{i3}})^{\prime } \end{align*}\) Then U\(_{i}\) checks whether V\(_{i}^{\prime }\) is equal to V\(_{i}\). If not, the session is terminated by U\(_{i}\). Otherwise, U\(_{i}\) verifies the legitimacy of CS and S\(_{i}\). U\(_{i}\) computes the session key SK\(^{\prime \prime }\) as below: \(\begin{align*} &{ SK^{\prime \prime }}={ h}(({ N_{i1}}\oplus ({ N_{i2}}\oplus { N_{i3}})^{\prime })\Vert { TS_{i}}) \end{align*}\)

3.2 Building CSP Model for Xue et al.’s AKA Protocol

In this subsection, we formalize the notation in the AKA protocol and construct the CSP models of the AKA protocol. The CSP model of the whole protocol consists of two parts, which represent the performance of entities in the registration phase and authentication phase, respectively. Meanwhile, the user, SPS, and CS in the AKA protocol are modeled separately.

3.2.1 Modeling Xue et al.’s AKA Protocol.

We design set ComputingSet based on the notations in the protocol. The variables in uppercase letters carry values generated by the current entity, and the variables in lowercase letters store values received from other entities. Without intruders, variables with the same letter and different capitalizations should carry the same value. The messages are modeled in set MSG\(_{reg}\) and MSG\(_{auth}\) for two phases in the protocol. ComputingSet, MSG\(_{reg}\), and MSG\(_{auth}\) are defined as below: \(\begin{align*} { ComputingSet}=~&\lbrace { A_i},{ B},{ ID_i},{ C_{i}},{ PID_i},{ D_i},{ N_{i1}},{ N_{i2}},{ N_{i3}},{ TS_{i}},{ B_{i}},{ F_{i}},{ P_{ij}},{ CID_{i}},{ G_{i}},{ V_{i}},{ SID_{j}},{ D},{ BS_{j}},\\ &{ TS_{i}},{ J_{i}},{ K_{i}},{ L_{i}},{ M_{i}},{ PSID_{j}},{ Q_{i}},{ PSID_{j}},{ R_{i}},{ V_{i}},{ K_{i}},{ B_{i}}\rbrace \\ &\cup \lbrace { a_i},{ b},{ id_i},{ c_i},{ b_i},{ f_i},{ p_i},{ p_{ij}},{ cid_{i}},{ g_{i}},{ pid_{i}},{ ts_{i}},{ r_{i}},{ v_{i}},{ j_{i}},{ k_{i}},{ l_{i}},{ m_{i}},{ psid_{i}}\rbrace \\ { MSG{_{reg}}}=~&\left\lbrace \begin{array}{l} { msg{_{reg}}}.{ ID_i}.{ B}.{ A_i},{ msg{_{reg}}}.{ id_i}.{ b}.{ a_i},{ msg{_{reg}}}.{ B_i},{ msg{_{reg}}}.{ b_i},{ msg{_{reg}}}.{ SID_j}.{ D},\\ { msg{_{reg}}}.{ sid_j}.{ d},{ msg{_{reg}}}.{ BS_j},{ msg{_{reg}}}.{ bs_j} \end{array} \right\rbrace \\ { MSG{_{auth}}}=~&\left\lbrace \begin{array}{l} { msg{_{auth}}}.{ F_i}.{ P_{ij}}.{ CID_{i}}.{ G_{i}}.{ PID_i}.{ TS_i}, { msg{_{auth}}}.{ f_i}.{ p_{ij}}.{ cid_{i}}.{ g_{i}}.{ pid_i}.{ ts_i},\\ { msg{_{auth}}}.{ F_i}.{ P_{ij}}.{ CID_{i}}.{ G_{i}}.{ PID_{i}}.{ TS_{i}}.{ J_{i}}.{ K_{i}}.{ L_{i}}.{ M_{i}}.{ PSID_{j}},\\ { msg{_{auth}}}.{ f_i}.{ p_{ij}}.{ cid_{i}}.{ g_{i}}.{ pid_{i}}.{ ts_{i}}.{ j_{i}}.{ k_{i}}.{ l_{i}}.{ m_{i}}.{ psid_{j}},\\ { msg{_{auth}}}.{ P_i}.{ Q_{i}}.{ R_{i}}.{ V_{i}},{ msg{_{auth}}}.{ p_i}.{ q_{i}}.{ r_{i}}.{ v_{i}},{ msg{_{auth}}}.{ R_i}.{ V_i},{ msg{_{auth}}}.{ r_i}.{ v_i} \end{array} \right\rbrace \end{align*}\)

We also give the declaration of channel ComUS, ComCS, and ComUC to support the communication between entities: \(\begin{eqnarray*} &{\bf Channel}~{ComUS}, { ComCS}, { ComUC}:{ MSG{_{reg}}},{ MSG{_{auth}}}\nonumber \nonumber \end{eqnarray*}\)

Xue et al.’s AKA protocol is implemented in process Protocol\(\_\)X(), which is illustrated as below: \(\begin{align*} { Protocol}&{ \_X}()=_{df}~~\\ &{ Protocol}{ \_X}{ \_Reg}({ UserID},{ ServerID});{ Protocol}{ \_X}{ \_Auth}({ UserID},{ ServerID}); \end{align*}\)

Here, processes Protocol\(\_\)X\(\_\)Reg() and Protocol\(\_\)X\(\_\)Auth() model the registration phase and authentication phase, respectively. UserID and ServerID mean the identity of the user and server. The definitions of Protocol\(\_\)X\(\_\)Reg() and Protocol\(\_\)X\(\_\)Auth() are as below: \(\begin{align*} { Protocol}&{ \_X}{ \_Reg}(i,j)=_{df}~~\\ &Initialization\rightarrow { SKIP};({ User\_X}{ \_Reg}(i)\Vert { Server\_X}{ \_Reg}(i)\Vert { CS\_X}{ \_Reg}(i,j));\\ { Protocol}&{ \_X}{ \_Auth}(i,j)=_{df}~~\\ &{ User\_X}{ \_Auth}(i,j)\Vert { Server\_X}{ \_Auth}(i,j)\Vert { CS\_X}{ \_Auth}(i,j); \end{align*}\)

Here, the Initialization action includes the initialization of each entity’s local storage information, as well as Boolean variables used in subsequent verification, such as s\(\_\)check\(\_\)q, which will store the result of SPS’s judgment on whether Q\(_{i}\) and Q\(_{i}^{\prime }\) are equal. Processes User\(\_\)X\(\_\)Reg(), Server\(\_\)X\(\_\)Reg(), and CS\(\_\)X\(\_\)Reg() capture the behavior of the user, SPS, and CS in the registration phase, respectively. Processes User\(\_\)X\(\_\)Auth(), Server\(\_\)X\(\_\)Auth(), and CS\(\_\)X\(\_\)Auth() describe the behavior of the user, SPS, and CS in the authentication phase, respectively. The communication between all processes is shown in Figure 4

Fig. 4.

View Figure

. The modeling of the user, SPS, and CS is illustrated as below:

•	User Modeling: User behaviors of different phases are implemented into User\(\_\)X\(\_\)Reg() and User\(\_\)X\(\_\)Auth(), which are shown in Table 2 (1–2). (1) In User\(\_\)X\(\_\)Reg(), the user computes A\(_i\) and sends it with ID\(_i\) and B (represented by b in the protocol description) to CS. After receiving b\(_i\) from CS, the user computes C\(_{i}\), PID\(_{i}\), and D\(_{i}\). (2) In User\(\_\)X\(\_\)Auth(), the user generates a random number N\(_{i1}\) and a current timestamp value TS\(_{i}\). The user also computes B\(_{i}\), F\(_{i}\), P\(_{ij}\), CID\(_{i}\), and G\(_{i}\). It sends F\(_{i}\), P\(_{ij}\), CID\(_{i}\), G\(_{i}\), PID\(_{i}\), and TS\(_{i}\) to SPS by channel ComUS. When receiving r\(_i\) and v\(_i\), the user computes N\(_{i2}\)\(\oplus\)N\(_{i3}\) and V\(_{i}^{\prime }\). Then U\(_{i}\) checks whether V\(_{i}^{\prime }\) and V\(_{i}\) are equal or not. If they are equal, the variable u’\(\_\)check\(\_\)v is assigned by true. Otherwise, the session is terminated. If the session keeps on going, the user computes the shared session key SK.
•	SPS Modeling: Processes Server\(\_\)X\(\_\)Reg() and Server\(\_\)X\(\_\)Auth() implement SPS’s behaviors in the registration phase and authentication phase, respectively. They are illustrated in Table 2 (3–4). (1) Process Server\(\_\)X\(\_\)Reg() represents the behaviors of SPS in the registration phase. The server sends SID\(_j\) and D (represented by d in the protocol description) to CS using channel ComSC. Then bs\(_j\) is also received from CS. (2) Process Server\(\_\)X\(\_\)Auth() illustrates the behaviors of SPS in the authentication phase. The server generates N\(_{i2}\) and receives f\(_i\), p\(_{ij}\), cid\(_{i}\), g\(_{i}\), pid\(_{i}\), and ts\(_{i}\) from CS by channel ComUS. Action CheckDelay indicates that SPS checks whether the session delay is within the time interval \(\Delta\)T. If it is not, the variable timeout is assigned to be true and the session is terminated. If the session keeps on, SPS computes J\(_{i}\), K\(_{i}\), L\(_{i}\), and M\(_{i}\). The server then sends F\(_i\), P\(_{ij}\), CID\(_{i}\), G\(_{i}\), PID\(_{i}\), TS\(_{i}\), J\(_{i}\), K\(_{i}\), L\(_{i}\), M\(_{i}\), and PSID\(_{j}\) to CS by channel ComSC. Then it also receives p\(_i\), q\(_{i}\), r\(_{i}\), and v\(_{i}\) from CS by channel ComSC. Then SPS computes N\(_{i1}\)\(\oplus\)N\(_{i3}\) and Q\(_{i}^{\prime }\). Action Check_Q\(_{i}\)_Q\(_{i}^{\prime }\) represents that SPS checks whether Q\(_{i}\) and the received q\(_{i}\) are equal. If they are, the variable s\(^{\prime }\_\)check\(\_\)q is set to true. Otherwise, SPS terminates the session. If the session continues, the server receives R\(_{i}\) and V\(_{i}\) from the user by channel ComUS. At last, the server computes the shared session key SK.
•	CS Modeling: The behaviors of CS during the registration phase and authentication phase are implemented in CS\(\_\)X\(\_\)Reg() and CS\(\_\)X\(\_\)Auth(), respectively. They are presented in Table 2 (5–6). (1) In process CS\(\_\)X\(\_\)Reg(), CS gets id\(_i\), b, and a from the user by channel ComUC. The CS computes PID\(_{j}\) and B\(_{i}\). B\(_{i}\) is sent to CS by channel ComUC. CS receives sid\(_j\) and d by channel ComSC. The CS computes PSID\(_{j}\) and BS\(_{j}\). BS\(_{j}\) is transmitted to SPS by channel ComSC. (2) In process CS\(\_\)X\(\_\)Auth(), CS receives f\(_i\), p\(_{ij}\), cid\(_{i}\), g\(_{i}\), pid\(_{i}\), ts\(_{i}\), j\(_{i}\), k\(_{i}\), l\(_{i}\), m\(_{i}\), and psid\(_{j}\) from channel ComSC. Action CheckDelay checks whether the session delay is within the tolerable time interval \(\Delta\)T. If it is not, the variable timeout is assigned to be true and the session is terminated. The CS calculates BS\(_j\), N\(_{i2}\), and K\(_{i}^{\prime }\). Action Check\(\_\)K\(_{i}\)\(\_\)K\(_{i}^{\prime }\) indicates that CS verifies whether K\(_{i}^{\prime }\) is equal to the received k\(_{i}\). If they are equal, cs\(^{\prime }\_\)check\(\_\)k is assigned to be true. Otherwise, the session is ended. The CS computes B\(_{i}\), N\(_{i1}\), ID\(_{i}\), SID\(_{i}\), and P\(_{ij}\). In action Check\(\_\)P\(_{ij}\)\(\_\)P\(_{ij}^{\prime }\), the CS verifies whether P\(_{ij}\) is equal to the received p\(_{ij}\). If they are different, CS terminates the session. Otherwise, CS sets cs\(^{\prime }\_\)check\(\_\)pij with value true and keeps on computing B, D, PID\(_{i}^{\prime }\), and PSID\(_{j}^{\prime }\). In action Check\(\_\)PID\(_{i}\)\(\_\)PID\(_{i}^{\prime }\) and Check\(\_\)PSID\(_{i}\)\(\_\)PSID\(_{i}^{\prime }\), the CS verifies whether PID\(_{i}^{\prime }\) and PSID\(_{j}^{\prime }\) are equal to the received pid\(_{i}\) and psid\(_{j}\), respectively. If they are not both equal, CS ends the session. Otherwise, CS assigns cs\(^{\prime }\_\)check\(\_\)pid and cs\(^{\prime }\_\)check\(\_\)psid with the value true. The CS selects a random number N\(_{i3}\) and computes P\(_{i}\), Q\(_{i}\), R\(_{i}\), and V\(_{i}\), which are transmitted to SPS by channel ComSC. Finally, CS computes the session key SK.

3.3 Implementation of the CSP Models in PAT and C#

Because PAT is extended based on CSP, channel output/input in PAT can also be used to implement message sending and receiving in CSP. Meanwhile, functions should be implemented to complete the functional actions in the CSP model. As it is difficult to write complex functions in PAT, PAT allows using C# code as libraries. C# classes are built as DLL, which are imported into the PAT model when the functions are used. As a result, we choose to implement our functions in C# language. In the CSP model, the computation in the protocol is described by functional action. In order to convert the CSP model to the PAT model, the PAT model calls the C# functions, which have implemented the computation in the protocol. In this way, we have completed the integration of C# into PAT to support modeling and verification. All the functions are included in a C# class, except the function RAND() written by C++ code. This function is built as DLL and then imported into the C# class.¹ For brevity, we only give several functions as examples here. We divide them into the following five categories according to the functions implemented by the function.

•	Random number generation and hush function: Function Hash() is implemented in C# to support the hashing of elements. We utilize C++ to implement function RAND() that generates a random integer within a fixed range. The assignment statemen (Line 7 of Figure 5) generates a uniformly distributed integer random number between the parameter max and min. In order to save space, only the definition of function RAND() is given here. The assignment statement (Line 7 of Figure 5) helps function RAND() to generate a uniformly distributed int random number between the parameter max and min. In addition, we call C# interfaces (e.g., the real random number generator) in the PAT model for initialization and number generation, which supports the session key sharing between entities. Only a fixed number of actions that invoke the random number generator are performed in a single run of the model (highlighted in light blue Table 2), so this will not lead to the increase of the state space in a single run. Function RAND() is given in Figure 5. Fig. 5. View Figure
•	Bitwise concatenation and bitwise XOR: Functions XOR() and concat() simulate the bitwise XOR operation \(\oplus\) and the bitwise concatenation operation \(\Vert\), respectively. For function concat(), function Convert.ToString() in C# is applied to convert a decimal number into a string of a binary number, with the help of setting the second parameter to 2, indicating base-2 (binary) notation. We connect two binary strings into one and then convert it to a decimal integer by the function Convert.ToInt32() in C#. Function concat() is illustrated in Figure 6. Fig. 6. View Figure
•	Timestamp generation and session delay check: Function Timestamp() records the current system time in an integer way, as PAT can only accept integer or Boolean type as a function returning value. Function EndSession() simulates whether it is necessary to close the session currently by comparing the difference between the two timestamps with the session delay time. The time-related elements in PAT mainly involve two scenarios: the entity adds a new timestamp to the message, and the entity compares the current time with the timestamp on the received message. In the namespace of C#, object DataTime’s property (Now) can support retrieving the current local date. Thus, we can generate the timestamp involved in the scenario by calling function Timestamp() implemented in C#. In this way, the timestamp is related to the time-related elements in PAT. Function Timestamp() is shown in Figure 7. Fig. 7. View Figure
•	Computation for elements: By calling functions Hash(), concat(), and XOR(), all the element computations in the AKA protocol can be implemented. Due to space constraints, we only provide the C# implementation of computation for the CS illustrated in Figure 8, omitting the C# implementation of computation for the user and SPS. The computation of step 2 and step 5 of the registration phase in the orange dotted frame, and the computation of step 3 of the authentication phase in the purple dotted frame. Fig. 8. View Figure

The corresponding C# class including these functions is compiled into a DLL and placed into the library folder of the PAT tool. The DLL can be imported into the PAT model using the import statement, which can support calling C# functions in the PAT model.

4.1 A Smart-card-based Secure AKA Protocol in Multi-server IoT Environment

Bae and Kwak [26] proposed a smart-card-based secure AKA protocol in a multi-server IoT environment. The proposed protocol has been shown to be secure against replay attacks, session key leakage attacks, and various other attacks. They used the formal verification tool AVISPA to verify the secrecy and witness of the messages. However, this work lacked verification of fundamental properties, such as entity legitimacy, timeout delay, and session key consistency. At the same time, it did not provide verification of security properties when intruders appeared. By applying our verification framework, we can provide a formal model of the protocol and verification of fundamental properties and security properties of the protocol.

4.1.1 Registration Phase.

The registration phase in Bae and Kwak’s protocol has four steps, as shown in Figure 9. Here, the dotted line represents the secure channel, and the solid line represents the public channel. Step 1 describes the message transmission of server S\(_j\). Step 2 and step 4 give the computation and message transmission of CS. The computation and message transmission of user U\(_i\) are denoted in step 3.

Fig. 9.

View Figure

STEP 1.	The service-providing server S\(_j\) sends its identity SID\(_j\) to CS.
STEP 2.	The control server CS chooses a random number x for computation. CS computes Serinfor\(_j\)=h(SID\(_j\)\(\Vert\)x) and sends it to S\(_j\).
STEP 3.	The user U\(_i\) chooses his/her password P\(_i\). U\(_i\) computes EncPass\(_i\)=h(ID\(_i\)\(\Vert\)h(P\(_i\))) and sends it to CS with its identity ID\(_i\) and anonymity value UID\(_i\).
STEP 4.	After receiving the messages from U\(_i\), CS computes Userinfor\(_i\)=h(EncPass\(_i\)\(\Vert\)x). It also stores UID\(_i\), Userinfor\(_i\), EncPass\(_i\), h(\(\cdot\)), and h(x) in the smart card. CS also adds similar elements together with the status-bit value into the verifier table. If the user does the registration, the status-bit value is saved as 1. Otherwise, the status-bit value is saved as 0. At last, CS sends the smart card to U\(_i\).

4.1.2 Authentication Phase.

In Bae and Kwak’s protocol, there are five steps in the authentication phase depicted in Figure 10. Step 1 and step 5 give the computation and message transmission of user U\(_i\). Step 2 and step 4 indicate the computation and message transmission of server S\(_i\). The computation and message transmission of CS are shown in step 3.

Fig. 10.

View Figure

STEP 1.	After user U\(_i\) has verified the legitimate owner of the smart card, it generates a random number N\(_{i1}\) and timestamp Ts. By using Userinfor\(_i\) and h(x) in the smart card, A\(_i\)= Userinfor\(_i\)\(\oplus\)h(x)\(\oplus\)N\(_{i1}\) and Veru\(_i\)=h(h(x)\(\Vert\)N\(_{i1}\)) are computed. Then U\(_i\) sends UID\(_i\), A\(_i\), Veru\(_i\), and Ts to server S\(_j\).
STEP 2.	After receiving messages from user U\(_i\), server S\(_j\) generates N\(_{i2}\). Then it computes B\(_i\)= Serinfor\(_j\)\(\oplus\)N\(_{i2}\) and Vers\(_j\)=h(h(Serinfor\(_j\))\(\Vert\)N\(_{i2}\)). After the computation, S\(_j\) sends UID\(_i\), A\(_i\), Veru\(_i\), B\(_i\), Vers\(_i\), SID\(_j\), and Ts to CS.
STEP 3.	When CS receives the message from S\(_j\), it first checks the session delay. Ts\(^{\prime }\) and \(\Delta\)T represent the current time and the tolerable time interval, respectively. If Ts\(^{\prime }\) - Ts \(\gt\) \(\Delta\)T, the session times out and CS terminates the session. Otherwise, CS computes the following elements. CS calculates Serinfor\(_j\), N\(_{i2}\) and Vers\(_i^{\prime }\) as follows: \(\begin{align*} &{ Serinfor_j}= { h}({ SID_{j}}\Vert { x})~~~{ N_{i2}}={ Serinfor_{j}}\oplus { B_{i}}~~~{ Vers_i^{\prime }}= { h} ({ h}({ SID_{j}}\Vert { x})\Vert { N_{i2})} \end{align*}\) CS then checks whether Vers\(_i^{\prime }\) is equal to Vers\(_i\). If not, CS terminates the session. Otherwise, CS verifies the legitimacy of S\(_{j}\). CS computes N\(_{i1}\) and Veru\(_i^{\prime }\) as below: \(\begin{align*} &{ N_{i1}}= { Userinfor_{i}}\oplus { h}({ x})\oplus { A_{i}}~~~{ Veru_i^{\prime }}= { h} ({ h}({ x})\Vert { N_{i1}^{\prime })} \end{align*}\) CS checks whether Veru\(_i^{\prime }\) is equal to Veru\(_i\). If not, CS terminates the session. Otherwise, CS verifies the legitimacy of U\(_{i}\). After generating random number N\(_{i3}\) and new timestamp Ts, CS computes C\(_{i}\), D\(_{i}\), and E\(_{i}\) as below: \(\begin{align*} &{ C_{i}}= { N_{i1}}\oplus { N_{i2}}\oplus { h}({ SID_{j}}\oplus { N_{i2}})\\ &{ D_i}= { h}({ A_{i}}\Vert { h}({ x}))\oplus { h}({ SID_{j}}\oplus { N_{i2}}))\\ &{ E_i}= { N_{i2}}\oplus { N_{i3}}\oplus { h}({ A_{i}}\Vert { h}({ x})) \end{align*}\) Then CS sends C\(_{i}\), D\(_{i}\), E\(_{i}\), and Ts to server S\(_{j}\). As CS knows A\(_{i}\), x, N\(_{i1}\), N\(_{i2}\), and N\(_{i3}\), it calculates the session key as below: \(\begin{align*} &{ SK}={ h}({ h}({ A_{i}}\Vert { h}({ x}))\oplus ({ N_{i1}}\oplus { N_{i2}}\oplus { N_{i3}})) \end{align*}\)
STEP 4.	After getting the message from CS, S\(_j\) sends E\(_{i}\) and Ts to U\(_i\). Then S\(_j\) computes (N\(_{i1}\)\(\oplus\)N\(_{i3}\))\(^{\prime }\) and (h(A\(_{i}\)\(\Vert\)h(x)))\(^{\prime }\) as below: \(\begin{align*} &({ N_{i1}}\oplus { N_{i3}})^{\prime }= { C_{i}}\oplus { h}({ SID_{j}}\oplus { N_{i2}})\\ &({ h}({ A_i}\Vert { h}({ x}))^{\prime }= { D_i}\oplus ({ SID_{j}}\oplus { N_{i2}}) \end{align*}\) So far, S\(_{j}\) has already learned (h(A\(_{i}\)\(\Vert\)h(x)))\(^{\prime }\), (N\(_{i1}\)\(\oplus\)N\(_{i3}\))\(^{\prime }\), and N\(_{i2}\). Therefore, the session key can be obtained by it as below: \(\begin{align*} &{ SK}^{\prime }={ h}(({ h}({ A_{i}}\Vert { h}({ x}))^{\prime })\oplus (({ N_{i1}}\oplus { N_{i3}})^{\prime }\oplus { N_{i2}})) \end{align*}\)
STEP 5.	When U\(_{i}\) receives E\(_{i}\) and Ts, it checks the session delay. As Ts\(^{\prime }\) and \(\Delta\)T denote the current time and the tolerable time interval, respectively, Ts’ - Ts \(\gt\) \(\Delta\)T is considered to be a timeout case. If it happens, U\(_{i}\) terminates the session. If it does not happen, U\(_{i}\) computes (N\(_{i2}\)\(\oplus\)N\(_{i3}\))\(^{\prime }\)=E\(_{i}\)\(\oplus\)h(A\(_{i}\)\(\Vert\)h(x)). As h(x) is in the smart card, U\(_{i}\) can obtain the session key as below: \(\begin{align*} &{ SK}^{\prime \prime }={ h}({ h}({ A_{i}}\Vert { h}({ x}))\oplus ({ N_{i1}}\oplus ({ N_{i2}}\oplus { N_{i3}})^{\prime })) \end{align*}\)

4.2 Building and Implementing CSP Model for Bae and Kwak’s AKA Protocol

Similar to Section 3.2, we need to design variable set ComputingSet, message sets MSG\(_{reg}\) and MSG\(_{auth}\), and channels for transmitting messages before building CSP models. Therefore, ComputingSet, MSG\(_{reg}\), and MSG\(_{auth}\) are updated according to the notations in the protocol, which is omitted here due to space constraints. Meanwhile, we keep the old channel declarations because the entities are the same. Since the general AKA protocols mostly only involve three entities (user, SPS, and CS), the composition of CSP models representing entities for Bae and Kwak’s protocol is the same as that of Xue et al.’s protocol. The overall CSP model is implemented in process Protocol\(\_\)B(). Protocol\(\_\)B\(\_\)Reg() and Protocol\(\_\)B\(\_\)Auth() represent the registration phase and authentication phase, respectively. Their definitions are given as below: \(\begin{align*} { Protocol}&{ \_B}()=_{df}~~\\ &{ Protocol}{ \_B}{ \_Reg}({ UserID},{ ServerID});{ Protocol}{ \_B}{ \_Auth}(UserID,ServerID);\\ { Protocol}&{ \_B}{ \_Reg}(i,j)=_{df}~~\\ &Initialization\rightarrow { SKIP};({ User\_B}{ \_Reg}(i)\Vert { Server\_B}{ \_Reg}(i)\Vert { CS\_B}{ \_Reg}(i,j));\\ { Protocol}&{ \_B}{ \_Auth}(i,j)=_{df}~~\\ &{ User\_B}{ \_Auth}(i,j)\Vert { Server\_B}{ \_Auth}(i,j)\Vert { CS\_B}{ \_Auth}(i,j); \end{align*}\)

The CSP models of user, SPS, and CS in the registration phase shown in Figure 9 are User\(\_\)B\(\_\)Reg(), Server\(\_\)B\(\_\)Reg(), and CS\(\_\)B\(\_\)Reg(), which are given in Table 3 (1–3). Table 3 (4–6) presents User\(\_\)B\(\_\)Auth(), Server\(\_\)B\(\_\)Auth(), and CS\(\_\)B\(\_\)Auth(), which denote CSP models of user, SPS, and CS in the authentication phase appearing in Figure 10. The communication between interprocesses for Protocol\(\_\)B() is the same as one for Protocol\(\_\)X() in Figure 4, except that all “X”s in the process name are replaced with “B”s.

In order to complete the implementation of the CSP models in PAT and C#, we can reuse the functions in Section 3.3 to construct the PAT models, except that the C# implementation of computation for elements needs to be updated. The actions related to the verifier table contain two types: (1) CS generates the verifier table element, and (2) CS judges whether the received UID is in the verifier table. Therefore, we need to implement the data structure of the verifier table in the PAT. Here, we implement the verifier table in the form of a list. Because only a fixed number of such actions are performed in a single run of the model (highlighted in gray in Table 3), the actions related to the verifier table will not cause an increase in the state space during a single run. Limited by the space, we only give Figure 11 to show the implementation of computation for the CS in Bae and Kwak’s protocol.

Fig. 11.

View Figure

5.1 Splitting Files for PAT Model

In the conversion from the CSP model to the PAT model, there is a gap involving data storage and function calls. Therefore, we design CSP-like models that are similar to the CSP models. CSP-like models update the actions in the CSP models by inserting the notation of involved data storage and involved parameters (the function name to be called and the parameters used to call the function). In order to support the effective conversion from CSP-like models to PAT models, we need to analyze the .csp file that saves the PAT model. We divide the .csp file into three parts, which are the declaration file, the phases file, and the composition file. Figure 12 shows the files of the PAT model with C#, the CSP-like model, and computation formulas. The declaration file mainly contains five parts: (1) introduction of libraries that support complex data structure and C# functions, (2) definition of global constants for further verification, (3) definition of enumeration types characterizing notations in the AKA protocol, (4) definition of variables involving verification and data storage, and (5) definition of channels supporting information transmission between entities.

Fig. 12.

View Figure

The composition file includes the combination of the process for each entity and the assertion representing property verification (mentioned in Section 6 later). The phase file represents the models that describe the behavior of entities in the registration phase and authentication phase. The difference between the two phase files in Figure 12 is that the phase file belonging to the CSP-like model is a .txt file storing CSP-like processes, while the phase file in the PAT model is a .csp file containing PAT processes.

The C# foundation file contains the definitions of the hash function, XOR operation, concatenation operation, and random number generation. The formula file has all the computation formulas involved in the protocol. The difference between the two formula files in Figure 12 is that the formula file in the CSP-like model is a .txt file storing the original computation formulas, while the formula file in the PAT model is a .cs file containing the C# functions corresponding to the formulas.

5.2 Automatic Conversion Algorithm

We design an algorithm to support automatic conversion from the phase file of the CSP-like model and the formula file of computation formulas to the phase file and the formula file in the PAT model with C#.² Figure 13 illustrates the conversion from the CSP-like model and formulas (in .txt file) to the PAT model (in .csp file) and C# functions (in .cs file). First, we manually prepare a CSP-like model for the registration phase and authentication phase as one input. After obtaining the process by reading line by line from the .txt file, we extract the name of the process and the actions in the process definition. Only Skip actions need no conversion. Other actions adopt different functions to complete the conversion based on their types (shown in the dotted box in Figure 13). For example, if the type of action a is element computation, we call BuildCompute() or BuildComputeCheck() to convert a to the action a\(_{PAT}\) in the PAT.

Fig. 13.

View Figure

There are five types of actions including value assignment, timestamp process, message transition, element computation, and verifier table process. For each action type, we provide two corresponding functions to construct the PAT code, whose explanations are illustrated in Table 4. Value assignment actions include adding corresponding parameters (involving function BuildAssignment()) and random numbers to the entity’s storage structure (involving function BuildRAND()). Timestamp generation (involving function BuildTimestamp()) and timestamp comparison (involving function BuildCheckDelay()) belong to timestamp process actions. Message transition actions contain the sending and receiving of elements (involving functions BuildSend() and BuildReceive()). Element computation actions consist of the computation of elements (involving function BuildCompute()) and the comparison between the calculated element value and the element value in the entity’s storage structure (involving function BuildComputeCheck()). Verifier table process actions include adding the corresponding element to the verifier table (involving function BuildStoreTable()) and verifying whether the corresponding element is in the verifier table (involving function BuildCheckUID()). The .csp file C\(_{PAT}\) can be completed after converting all actions into new ones. Meanwhile, we also use computation formulas (in a .txt file) as the input. After preprocessing the computation formulas involved in the protocol, Algorithm 1 is applied to convert each formula into a C# function, and finally, the .cs file F\(_{C\#}\) is built.

Algorithm 1 illustrates the conversion of the formula to C# code.\(^{2}\) Here, we use the stack to extract the sub-formulas divided by parentheses in the preprocessed computation formula (Lines 6–15). The sub-formulas are handed over to procedure CONVERT-ELEMENTS, so that the C# function body can be obtained (Line 16). Finally, the function name is also constructed to form a complete C# function definition (Lines 18–25). Procedure CONVERT-ELEMENTS (Lines 27–59) supports the conversion of the XOR and concatenation operations in the sub-formula into the form of C# code and provides a special conversion for the variables to contact “11” and “00” in Xue et al.’s protocol.

Figure 14 shows the automatic conversion example for some behaviors in the registration phase of CS in Bae and Kwak’s protocol. Taking the transmission of SID\(_{j}\) and the calculation of Serinfor\(_{j}\) as an example, we show how to obtain the CSP-like model and formula file (in .txt files) from the perspective of CS based on Bae and Kwak’s protocol. Further, we use automatic conversion to convert them to a .csp file and a .cs file, respectively.

Fig. 14.

View Figure

7.1 Verification of Replay Attack

In a replay attack, the intruder can eavesdrop and intercept sensitive communication. Meanwhile, the intruder may delay or resend the messages to the receiver fraudulently. We simulate the behaviors of the intruder doing a relay attack in Xue et al.’s protocol and Bae and Kwak’s protocol by processes \({\it Intruder}{\it \_X\_ReplayAttack(i, j)}\) and \({\it Intruder}{\it \_B\_ReplayAttack(i),}\) respectively, shown as below: \(\begin{align*} { Intruder}&{ \_X\_ReplayAttack}(i,j)=_{df}\\ &{ FakeUI}?{ msg{_{auth}}}.{ f_i}.{ p_{ij}}.{ cid_{i}}.{ g_{i}}.{ pid_{i}}.{ ts_{i}}\rightarrow ModifyTimestamp \rightarrow \\ &{ FakeIS}!{ msg{_{auth}}}.{ f_i}.{ p_{ij}}.{ cid_{i}}.{ g_{i}}.{ pid_{i}}.{ TS\_old}\rightarrow ({ Intruder}{ \_X\_ReplayAttack}{ \_Sub}(i)\square { Skip})\\ { Intruder}&{ \_X\_ReplayAttack}{ \_Sub}(i)=_{df}\\ &{ FakeIS}?{ msg{_{auth}}}.{ r_i}.{ v_i}\rightarrow { FakeUI}!{ msg{_{auth}}}.{ r_i}.{ v_i}\rightarrow \\ &{ Check\_Replay\_Attack}\lbrace success\_replay\_attack=true\rbrace \rightarrow { Skip}\\ { Intruder}&{ \_B\_ReplayAttack}(i)=_{df}\\ &{ FakeUI}?{ msg{_{auth}}}.{ uid_i}.{ a_{i}}.{ veru_{i}}.{ ts}\rightarrow ModifyTimestamp \rightarrow \\ &{ FakeIS}!{ msg{_{auth}}}.{ uid_i}.{ a_{i}}.{ veru_{i}}.{ TS\_old}\rightarrow ({ Intruder}{ \_B\_ReplayAttack}{ \_Sub}(i)\square { Skip}) \end{align*}\) \(\begin{align*} { Intruder}&{ \_B\_ReplayAttack}{ \_Sub}(i)=_{df}\\ &{ FakeIS}?{ msg{_{auth}}}.{ e_i}.{ ts}\rightarrow { FakeUI}!{ msg{_{auth}}}.{ e_i}.{ ts}\rightarrow \\ &{ Check\_Replay\_Attack}\lbrace success\_replay\_attack=true\rbrace \rightarrow { Skip} \end{align*}\)

\({\it Intruder}{\it \_X\_ReplayAttack}(i, j)\) and \({\it Intruder}{\it \_B\_ReplayAttack}(i)\) intercept the messages transmitted between SPS and user and carry out a relay attack. They use channels FakeUI and FakeIS to intercept messages between the user and SPS. Here, we use the old timestamp to perform a replay attack, which can be obtained by the intruder from interception. The ModifyTimestamp action means to modify the timestamp to an old timestamp, and TS_old appearing in the message denotes the old timestamp. If the intruder can receive messages from SPS, action Check_Replay_Attack assigns variable success_replay_attack to be true, which also indicates the success of the relay attack.

To describe the influence of the intruder on the protocol, we modify the original model using renaming. \(\lbrace |\)c\(|\rbrace\) represents the set of all communications over channel c. To support the simulation of the replay attack in the authentication phase, the model needs to support channels FakeIS and FakeUI. The intruder can use these two channels to eavesdrop or even change the data on channel ComUS. Because the user and SPS are connected by channel ComUS, their CSP models in the authentication phase should be updated by applying renaming. We add the suffix “_I” in the process name to denote the updated process. Due to space constraints, here we only give the definition of \({\it User\_X}{\it \_Auth} {\it \_I}\)(). \(\begin{align*} { User}&{ \_X\_Auth}{ \_I}({ i},{ j})=_{df}~\\ &{ User\_X}{ \_Auth}({ i},{ j})[[{ ComUS}?\lbrace |{ ComUS}|\rbrace \leftarrow { ComUS}?\lbrace |{ ComUS}|\rbrace ,\\ &{ ComUS}?\lbrace |{ ComUS}|\rbrace \leftarrow { FakeUI}?\lbrace |{ ComUS}|\rbrace ,{ ComUS}!\lbrace |{ ComUS}|\rbrace \leftarrow { ComUS}!\lbrace |{ ComUS}|\rbrace ,\\ &~~~~~~~~~~~~~~~~~~~~~~~~~~~{ ComUS}!\lbrace |{ ComUS}|\rbrace \leftarrow { FakeUI}!\lbrace |{ ComUS}|\rbrace ]] \end{align*}\)

For building the CPS model with the intruder, the previous models also have more minor changes, such as adding a more nondeterministic choice \(\square\) to cope with attack appearance, which is not expanded here due to limited space. For the overall modeling, Intruder\(\_\)X\(\_\)ReplayAttack() and Intruder\(\_\)B\(\_\)ReplayAttack() will be concurrent with related entities in the protocol, which builds models of the protocols under replay attacks. When replay attacks occur in Xue et al.’s protocol and Bae and Kwak’s protocol, the two models are shown in Table 6 (1–2), called Protocol\(\_\)X_ReplayAttack() and Protocol\(\_\)B_ReplayAttack(). The communication between interprocesses for them is shown in Figure 15.

Fig. 15.

View Figure

Table 6.

View Table

Table 6. The CSP Models with Intruders

Property 5: Success Replay Attack

\(\# {\it define}~{\it SuccessReplayAttack}~({\it success\_replay\_attack}==true);\)

\(\# {\it assert}~{\it Protocol\_X\_ReplayAttack}()~{\it reaches}~{\it SuccessReplayAttack};\)

\(\# {\it assert}~{\it Protocol\_B\_ReplayAttack}()~{\it reaches}~{\it SuccessReplayAttack};\)

If a relay attack occurs and affects the protocol, the variable success\(\_\)replay\(\_\)attack will be set to true. We define the replay attack success property as a reachability property. Before performing the verification of any security property, we should verify the fundamental properties for the updated models. Except for the deadlock freedom property, the two models have invalid results for the other three properties shown in Table 7. This means the models have deadlock freedom but suffer from entity illegitimacy, timeout delay, and session key inconsistency. So the existence of intruders affects the fundamental properties. According to the invalid verification results of the success reply attack property in Table 8, we can learn that Xue et al.’s protocol and Bae and Kwak’s protocol are resistant to replay attacks.

Table 7.

View Table

Table 7. Verification Results of Fundamental Properties in the CPS Models with Intruders

7.2 Verification of Other Attacks

In addition to replay attacks, we also support the formalization and verification of denial of service attacks, server spoofing attacks, and session key attacks. The method of constructing the CPS models with intruders launching these attacks is the same as the CPS models with intruders doing replay attacks. All experiments were conducted on a 2.60-GHz core i7 PC with 16 GB of RAM under the PAT 3.5.0 environment.

7.2.2 Verification of Server Spoofing Attack.

Server spoofing attacks describe a situation where an intruder pretends to be the server to interact with the user and CS. The intruder can complete the attack with the help of intercepting the information sent to SPS. Processes \({\it Intruder}{\it \_X\_ServerSpoofingAttack}\)() and \({\it Intruder}{\it \_B\_ServerSpoofingAttack}\)() denote server spoofing attacks in Xue et al.’s protocol and Bae and Kwak’s protocol, respectively.

To complete the simulation of the server spoofing attack in the authentication phase, the model needs to support channels FakeIS, FakeSI, FakeIC, and FakeUI. Equipped with these four channels, the intruder is able to eavesdrop or manipulate the data on channels ComUS and ComSC. Compared with the previously updated model, it is necessary to update the CSP models of SPS and CS by applying renaming again. We add the suffix “_I’ ” in the process name to denote the newly updated process. Because of space constraints, here we only give the definition of Server_X_Auth_I’(): \(\begin{align*} { Server}&{ \_X\_Auth}{ \_I$'$}({ i})=_{df}~\\ &{ Server\_X}{ \_Auth}({ i})[[{ ComUS}?\{|{ ComUS}|\}\leftarrow{ ComUS}?\{|{ ComUS}|\},\\ &~~~~~~~~~~~~~~~~~~~~~~~~~{ ComUS}?\{|{ ComUS}|\}\leftarrow{ FakeIS}?\{|{ ComUS}|\},{ ComUS}!\{|{ ComUS}|\}\leftarrow{ ComUS}!\{|{ ComUS}|\},\\ &~~~~~~~~~~~~~~~~~~~~~~~~~{ ComUS}!\{|{ ComUS}|\}\leftarrow{ FakeIS}!\{|{ ComUS}|\},{ ComSC}?\{|{ ComSC}|\}\leftarrow{ ComSC}?\{|{ ComSC}|\},\\ &~~~~~~~~~~~~~~~~~~~~~~~~~{ ComSC}?\{|{ ComSC}|\}\leftarrow{ FakeSI}?\{|{ ComSC}|\},{ ComSC}!\{|{ ComSC}|\}\leftarrow{ ComSC}!\{|{ ComSC}|\},\\ &~~~~~~~~~~~~~~~~~~~~~~~~{ ComSC}!\{|{ ComSC}|\}\leftarrow{ FakeSI}!\{|{ ComSC}|\}]] \end{align*}\)

The overall models of Xue et al.’s protocol and Bae and Kwak’s protocol affected by server spoofing attacks are presented as Protocol_X_ServerSpoofingAttack() and Protocol_B_ServerSpoof

ingAttack(), respectively. They are illustrated in Table 6 (5–6), whose interprocess communication is also shown in Figure 16. Then the property of success server spoofing attack is listed as below:

Fig. 16.

View Figure

Property 7: Success Server Spoofing Attack

\(\# {\it define}~{\it SuccessServerSpoofingAttack}~({\it success\_server\_spoofing\_attack}==true);\)

\(\# {\it assert}~{\it Protocol\_X\_SuccessServerSpoofingAttack}()~{\it reaches}~{\it SuccessServerSpoofingAttack};\)

\(\# {\it assert}~{\it Protocol\_B\_SuccessServerSpoofingAttack}()~{\it reaches}~{\it SuccessServerSpoofingAttack};\)

Once a server spoofing attack happens, variable success\(\_\)server\(\_\)spoofing\(\_\)attack is set to be true. The property of success server spoofing attack is depicted as a reachability property. According to Table 7, the verification results of the deadlock freedom property and timeout delay property are valid, but the verification results of the entity legitimacy property and session key consistency property are invalid. That is to say, entity legitimacy and session key consistency are affected when server spoofing attacks occur. According to Table 8, the models do not satisfy the success server spoofing attack property, which indicates that the protocols of Xue et al. and Bae and Kwak can prevent server spoofing attacks effectively.