1 Introduction
The continuous development of the
Internet of Things (IoT) gives rise to more problems of IoT authentication and key agreement. The IoT in a multi-server environment provides efficient resource utilization for users, which also introduces security issues such as the leakage of private information.
Authentication and Key Agreement (AKA) protocols play an important role in solving these problems [
29,
57,
58]. They can prevent unauthorized users from gaining protected data and help the entities to compute the shared secret session key [
11]. The first contribution was provided by Lamport [
33] in 1981, who proposed an authentication technique using the password in untrusted networks. As Lamport’s technique depends on the password table, the server may suffer from stolen-verifier attacks. Thus, Shamir [
47] introduced the concept of identity-based cryptosystems. Chen et al. [
16] presented two identity-based AKA protocols to support provable security in the
Bellare-Rogaway (BR) model [
8]. Based on a secure key encapsulation mechanism primitive, a generic approach was proposed by Boyd et al. [
12] for designing AKA protocols. Huang and Cao [
23] put forward a new ID-based two-party
authenticated key exchange (AKE) protocol, which is provably secure in the eCK model. Ni et al. [
42] proposed a strongly secure identity-based two-party AKA protocol. It can capture many desirable security properties, such as perfect forward secrecy and ephemeral secrets reveal resistance. Smart [
49] suggested an identity-based AKA protocol based on Weil pairing. Wang et al. [
56] introduced an efficient perfect forward-secure identity-based key agreement protocol in the escrow mode and proved its security in the random oracle model. Sood et al. [
50] presented a dynamic identity-based multi-server authentication protocol. Li et al. [
36] criticized that the protocol in [
50] lacks attack protection and suggested a countermeasure protocol. Xue et al. [
59] declared that the protocol in [
36] could not protect against several security threats and put forward an improved version of the protocol.
Although many AKA protocols have been proposed, only several works [
42,
56] have provided verifications of their own AKA protocols, most of which involve fundamental properties. Yet there are only a few works about AKA protocols for multi-server IoT. Meanwhile, there is a lack of a unifying verification framework to support the verification of AKA protocols. In addition, the tools that are often used to verify AKA protocols such as AVISPA and ProVerif require users to grasp relatively complex knowledge. Therefore, it is necessary to improve the legibility and usability of the method while supporting the description of the multi-server feature. Based on the legibility of
Communicating Sequential Processes (CSPs), we build a
formal verification framework of AKA protocols for multi-server IoT (FVF-AKA). We implement our CSP models into the model checker
Process Analysis Toolkit (PAT) with C# integrated. To the best of our knowledge, our work is the first to integrate C# into PAT to support modeling and verification for AKA protocols. We also design an automatic conversion algorithm implemented in Python, which supports the conversion from the CSP model to the PAT model conveniently. As far as we are aware, we are the first to provide formal model conversion for AKA protocols.
The remainder of this article is organized as follows. In Section
2, we briefly introduce the AKA protocol for multi-server IoT and process algebra CSP. Meanwhile, we also propose the framework FVF-AKA. Sections
3 and
4 are devoted to applying FVF-AKA to Xue et al.’s AKA protocol [
59] and Bae and Kwak’s AKA protocol [
26], respectively. Section
5 provides an automatic conversion from the CSP model to the PAT model. In Section
6, we verify four fundamental properties (deadlock freedom, entity legitimacy, timeout delay, and session key consistency). Section
7 studies four common attacks (replay attacks, denial of service (DoS) attacks, server spoofing attacks, and session key attacks) during the running of the AKA protocol and verifies the corresponding four security properties. The related work is illustrated in Section
8. Finally, Section
9 concludes the article and discusses future work.
6 Verification of Fundamental Properties
In this section, we show the verification of the four properties (deadlock freedom, entity legitimacy, timeout delay, and session key consistency) using the model checker PAT [
51,
53], which has a wide application area [
1,
48,
52]. Some of them are described in the
Linear Temporal Logic (LTL) formula, which illustrates linear-time properties. PAT supports the LTL formula via using
\(\#\) assert
P()
\(|\) =
F to check whether system
P() satisfies LTL formula
F. All experiments were conducted on a 2.60-GHz core i7 PC with 16 GB of RAM under the PAT 3.5.0 environment.
Property 1: Deadlock Freedom
\(\# {\it assert}~{\it Protocol}\_{\it X}()~{\it deadlockfree};\)
\(\# {\it assert}~{\it Protocol}\_{\it B}()~{\it deadlockfree};\)
Before performing other verifications, we must ensure that the model has no deadlock. So we use the reserved keyword “deadlockfree” in PAT to verify the deadlock freedom. The valid verification results (row 1 and row 7 in Table
5) show that no deadlock appears in the protocols of Xue et al. and Bae and Kwak.
Property 2: Entity Legitimacy
\(\#define~{\it S}\_{\it U}\_{\it Legitimacy}\_{\it X}\_{\it For}\_{\it CS}~\\ ~~~~~~~~~~~({\it cs}\_{\it check}\_{\it k}=={\it true}\&\&{\it cs}\_{\it check}\_{\it pij}=={\it true}\&\&{\it cs}\_{\it check}\_{\it pid}=={\it true}\&\&{\it cs}\_{\it check}\_{\it psid}=={\it true});\)
\(\#define~{\it CS}\_{\it U}\_{\it Legitimacy}\_{\it X}\_{\it For}\_{\it S}~({\it s}\_{\it check}\_{\it q}=={\it true});\)
\(\#define~{\it S}\_{\it CS}\_{\it Legitimacy}\_{\it X}\_{\it For}\_{\it U}~({\it u}\_{\it check}\_{\it v}=={\it true};)\)
\(\# {\it assert}~{\it Protocol}\_{\it X}()~|= \lt \gt ~{\it S}\_{\it U}\_{\it Legitimacy}\_{\it X}\_{\it For}\_{\it CS};\)
\(\# {\it assert}~{\it Protocol}\_{\it X}()~|= \lt \gt ~{\it CS}\_{\it U}\_{\it Legitimacy}\_{\it X}\_{\it For}\_{\it S};\)
\(\# {\it assert}~{\it Protocol}\_{\it X}()~|= \lt \gt ~{\it S}\_{\it CS}\_{\it Legitimacy}\_{\it X}\_{\it For}\_{\it U};\)
\(\#define~{\it S}\_{\it Legitimacy}\_{\it B}\_{\it For}\_{\it CS}~({\it cs}\_{\it check}\_{\it Vers}=={\it true});\)
\(\#define~{\it U}\_{\it Legitimacy}\_{\it B}\_{\it For}\_{\it CS}~({\it cs}\_{\it check}\_{\it Veru}=={\it true});\)
\(\# {\it assert}~{\it Protocol}\_{\it B}()~|= \lt \gt ~{\it S}\_{\it Legitimacy}\_{\it B}\_{\it For}\_{\it CS};\)
\(\# {\it assert}~{\it Protocol}\_{\it B}()~|= \lt \gt ~{\it U}\_{\it Legitimacy}\_{\it B}\_{\it For}\_{\it CS};\)
The property of entity legitimacy is a liveness property. Its definition depends on the AKA protocol itself. In Xue et al.’s protocol, the user, SPS, and CS confirm each other’s legitimacy mutually. However, only CS checks the legitimacy of SPS and the user in Bae and Kwak’s protocol. Using the “eventually” operator
\(\lt \gt\) in LTL, we describe the situation that one entity should check the legitimacy of another entity. As shown in rows 2–4 and rows 8–9 in Table
5, the valid verification results indicate that the protocols of Xue et al. and Bae and Kwak both have entity legitimacy.
Property 3: Timeout Delay
\(\#define~{\it TimeOut}~({\it timeout}=={\it true});\)
\(\# {\it assert}~{\it Protocol}\_{\it X}()~|= []!~{\it TimeOut};\)
\(\# {\it assert}~{\it Protocol}\_{\it B}()~|= []!~{\it TimeOut};\)
When the AKA protocol considers the timeout delay, it is necessary to verify the timeout delay property. In the previous model construction, the variable
timeout will be set to true once there is a session delay timeout. Thus, we apply the “always” operator [] in LTL to build the timeout delay property. As depicted in row 5 and row 10 in Table
5, the valid results denote that all the session delays are within the time interval
\(\Delta\) T for the protocols of Xue et al. and Bae and Kwak, respectively.
Property 4: Session Key Consistency
\(\#define~{\it SK}\_{\it Consistency} ~({\it CS}\_{\it SK}=={\it Server}\_{\it SK})~\&\&({\it Server}\_{\it SK}=={\it User}\_{\it SK});\)
\(\# {\it assert}~{\it Protocol}\_{\it X}()~|= \lt \gt ~{\it SK}\_{\it Consistency};\)
\(\# {\it assert}~{\it Protocol}\_{\it B}()~|= \lt \gt ~{\it SK}\_{\it Consistency};\)
Construction of the session key agreement between entities is an important goal of the AKA protocol, which can be described as the property of session key consistency. With the help of the “eventually” operator
\(\lt \gt\) in LTL, we use this assertion to check whether all the entities have the same session key finally. According to the two valid verification results in row 6 and row 11 in Table
5, we can determine that the session keys owned by SPS, CS, and user are the same in the protocols of Xue et al. and Bae and Kwak.
7 Verification of Security Properties
In this section, we model the behaviors of the intruders doing relay attacks, denial of service attacks, server spoofing attacks, and session key attacks. It helps to simulate the situation of the AKA protocol running in a vulnerable environment. These attacks are described in new processes; meanwhile, the original CSP models are also modified for supporting the vulnerable environments. The four security properties (success relay attack, success denial of service attack, success server spoofing attack, and success session key attack) are verified for the new CSP models with intruders.
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:
\({\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}\) ().
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.
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.
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.1 Verification of Denial of Service Attack.
In a DoS attack, the malicious intruder attempts to overload the system by sending a large number of requests. This affects the processing of legitimate requests seriously. We build processes
\({\it Intruder}{\it \_X\_DoSAttack}\) () and
\({\it Intruder}{\it \_B\_DoSAttack}\) () to denote the intruder performing a replay attack located between the user and SPS, and their constructions are similar with the building of CSP processes for replay attacks. Since DoS attacks and relay attacks both occur between the user and SPS, the overall CSP models for DoS attacks are similar to the overall CSP models for replay attacks. The models owning a DoS attack of Xue et al.’s protocol and Bae and Kwak’s protocol are denoted by
Protocol \(\_\) X_DoSAttack() and
Protocol \(\_\) B_DoSAttack(), which are shown in Table
6 (3–4). Then we give the property of success denial of service attack as below.
Property 6: Success Denial of Service Attack
\(\# {\it define}~{\it SuccessDoSAttack}~({\it success\_dos\_attack}==true);\)
\(\# {\it assert}~{\it Protocol\_X\_DoSAttack}()~{\it reaches}~{\it SuccessDoSAttack};\)
\(\# {\it assert}~{\it Protocol\_B\_DoSAttack}()~{\it reaches}~{\it SuccessDoSAttack};\)
When a DoS attack occurs, variable
success \(\_\) dos \(\_\) attack is assigned to be true. Thus, the property of success replay attack becomes a reachability property. From Table
7, two models only have valid results in the deadlock freedom property for the four fundamental properties. This shows that they have no deadlock freedom, but the emergence of DoS attacks does lead to dissatisfaction of other properties. For the verification results for success DoS attack property in Table
8, the invalid results indicate that the protocols of Xue et al. and Bae and Kwak can prevent DoS attacks.
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’():
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:
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.
7.2.3 Verification of Session Key Attack.
Session key attacks indicate that the intruder intercepts all the messages on public channels and attempts to analyze the real session key based on the received messages. The attacks are implemented as
Intruder \(\_\) X_SessionKeyAttack() and
Intruder \(\_\) B_SessionKeyAttack() for Xue et al.’s protocol and Bae and Kwak’s protocol. The modification of the original models is the same as when the server spoofing attacks appear, because the intruder can monitor the whole process.
Protocol_X_SessionKeyAttack() and
Protocol_B_SessionKeyAttack() denote the overall models of Xue et al.’s protocol and Bae and Kwak’s protocol with session key attack, respectively, shown in Table
6 (7–8). Their communication between interprocesses is presented in Figure
16. Then we illustrate the property of success session key attack as below:
Property 8: Success Session Key Attack
\(\# {\it define}~{\it SuccessSessionKeyAttack}~({\it success\_session\_key\_attack}==true);\)
\(\# {\it assert}~{\it Protocol\_X\_SuccessSessionKeyAttack}()~{\it reaches}~{\it SuccessSessionKeyAttack};\)
\(\# {\it assert}~{\it Protocol\_B\_SuccessSessionKeyAttack}()~{\it reaches}~{\it SuccessSessionKeyAttack};\)
If there is a session key attack, variable
success \(\_\) session \(\_\) key \(\_\) attack is assigned as true. The property of session key attack success is also declared as a reachability property. According to Table
7, the verification results of four fundamental properties are valid, which indicates session key attacks have no influence on the processing of protocols. The verification results of the success session key attack property are invalid in Table
8. They show that intruders are unable to infer the session key from the messages they intercepted, which indicates the protocols of Xue et al. and Bae and Kwak can avoid session key attacks.
The properties related to cryptography in the foundational properties are entity legitimacy and session key consistency. The properties related to cryptography in the security properties contain success server spoofing attack and success session key attack. Using the last assertion in Property 8 (success session key attack) as an example, the intruder tries to use the data that has been eavesdropped to decrypt the session key, and the basis is doing XOR and concatenation operations, which are implemented in our PAT model with C#.
8 Related Work
As security plays a very important role in AKA protocols, several researchers have explored the verification of AKA protocols. Bellare and Rogaway [
8,
9] gave the first work of formalizing the notion of security for key agreement. Blake-Wilson et al. [
10] and Bellare et al. [
7] made the extension according to the models in [
8,
9]. The
Canetti-Krawczyk (CK) model proposed by Canetti et al. [
14] is a promising one among the extension models, which was also extended to the Canetti-Krawczyk (eCK) model in [
32]. A modular technique [
31] was presented by using gap assumptions for simplifying proofs of security for key agreement protocols. Ota et al. [
43] proposed the OKT method, which is a security verification method for AKA protocols updated based on the BPR model. Aiash [
3] introduced a new AKA protocol to authenticate the mobile terminal in heterogeneous networks via the Casper/FDR tool. Schmidt et al. [
46] presented an algorithm for the verification of group key agreement protocols using Diffie-Hellman exponentiation. Lopes et al. [
38] introduced a secret sharing-based AKA protocol for machine-type communications and verified two simulations based on the On-the-fly Model-checker and Constraint-logic-based Attack Searcher. Kilciauskas et al. [
28] stated two versions of AKA protocols based on provable secure cryptographic functions and proved their security under some malicious attacks. However, there is a lack of a framework supporting general AKA protocol verification, and our work is to fill this gap.
As the AKA protocol is widely used in 3G and 4G, there are also many formal analyses and verifications in this domain. The
Third Generation Partnership Project (3GPP) [
2] verified the AKA protocol for 3G by the TLA-based formal analysis and the enhanced BAN logic. Hussain et al. [
24] introduced a model-based testing approach LTEInspector for exposing attacks against three critical procedures of 4G LTE. In [
17], Cheval et al. provided a procedure for automated verification of equivalence properties implemented in the DEEPSEC tool, and the AKA protocol deployed in 3G is one of its applications. Arapinis et al. [
5] exposed two novel threats to user privacy in the 3G-AKA protocol and proposed privacy-friendly fixes. Using the ProVerif tool, they verified that it satisfied the desired unlinkability and anonymity properties. Broek et al. [
55] presented a solution against IMSI catching attacks in 3G and 4G AKA protocols, which is verified formally in the ProVerif tool. Fouque et al. [
21] introduced a fixed variant of the AKA protocol for 3G and 4G and proved the key secrecy of the fixed variant of the AKA protocol. Lee et al. [
34] analyzed the anonymity property of the UMTS/LTE AKA protocol and adopted the indistinguishability-based formalization for the UMTS/LTE protocol. Tang et al. [
54] identified the AKA procedure in inter-generational mobile telephony for each of the possible cases, which are modeled and analyzed by the ProVerif tool. Li and Wang [
35] proved their proposed Security Enhanced AKA with the formal verification method, and the results indicated that it satisfies the security and efficiency properties in the LTE/SAE architecture. In [
4], Alezabi et al. introduced an efficient AKA protocol based on a secret key and applied the AVISPA tool to provide a formal verification. The results indicated that the proposed protocol is efficient and secure against active and passive attacks. Idrissi et al. [
25] introduced a new fast
Extensible Authentication Protocol and Authentication Key Agreement (EAP-AKA), which is an authentication mechanism for the 3G network. Its security properties are analyzed by applying the
High Level Protocol Specification Language (HLPSL) used in AVISPA.
Yet only a few formal analyses exist in the literature for the 5G-AKA protocol, and most of them use different formal verification tools. Cao et al. [
15] discussed the security features, security requirements, security vulnerabilities, and existing security solutions in the 5G network. Basin et al. [
6] proposed a comprehensive formal model of the 5G-AKA protocol using the Tamarin tool. Cremers and Dehnel-Wild [
18] performed a fine-grained formal analysis of the 5G-AKA protocol to demonstrate its fragility and subtle trust assumptions. Jiang et al. [
27] introduced an analytical modeling approach to analyze the dependability of the 5G-AKA protocol quantitatively. Zhang et al. [
60] introduced the formal model of the 5G-EAP-TLS protocol, which is analyzed by model checker Scyther to point out several design flaws. Adrien Koutsos [
30] modified a 5G-AKA protocol to prevent several attacks, which satisfies the 5G-AKA constraints as much as possible. Their protocol’s
\(\sigma\) -unlinkablity is also formally proved. Edris et al. [
19] conducted a formal security analysis by ProVerif of the 5G-AKA protocol to identify the 5G-AKA protocol’s security requirements based on two sets of taxonomies [
39,
41].
Compared with the 3G-AKA protocol and 4G-AKA protocol, the formal analyses for the 5G-AKA protocol are still in their early stages. For the above-mentioned AKA protocols, the most used verification tools are AVISPA and ProVerif. The works [
4,
25,
26] using AVISPA paid more attention to the related security properties of their own protocols. At the same time, the language used by AVISPA is relatively complicated, which means that users need to spend more time learning. As the ProVerif tool cannot deal with the
exclusive-or (XOR) operation, researchers need to employ special strategies. For example, the authors in [
5] used randomized symmetric encryption to conceal the sequence number SQN instead of using the XOR, and a special equation was applied to solve the XOR translation problem in [
19]. Thus, these two tools may not be suitable for general AKA protocols for multi-server IoT. There is also a lack of framework for AKA protocol verification of multi-server IoT.
As model checker PAT [
37,
52] has been applied in a wide range of security analyses, we chose PAT to support our framework FVF-AKA and applied the integration of C# in PAT to enrich the description of functions. As most of them input the model manually, automatic conversion of formal models is also needed, which can save time and cost. Our method can support the conversion from CSP-like models to PAT models automatically. Using AVISPA or ProVerif requires learning more knowledge. The simplicity of CSP also helps enhance the legibility. The advantage of CSP lies in its capacity to offer intuitive constructs for expressing communications between different roles. Moreover, CSP is supported by well-developed verification tools like PAT. Our framework has the automatic conversion from the CSP-like model and formulas to the PAT model and C# functions. We paid more attention to improving the legibility and usability of the method. Combined with third-party code, we also provide custom writing of functions to support modular reusability. Most existing formalization works of AKA protocols do not focus on the multi-server setting, so we provide support for its description. Our framework supports converting the subscripts of server and user into process parameters to distinguish different servers and users, providing support for the multi-server feature. We concentrate on the protocol in this multi-server environment and give the modeling support of the multi-server setting.
Therefore, we proposed the FVF-AKA, equipped with automatic conversion of formal models. With the implementation of CSP models to PAT and C#, we analyzed two AKA protocols as case studies and verified the eight important properties. The results indicated that the two protocols perform well not only in safe environments but also in vulnerable environments. Our framework is not specific for the analyzed protocols and shows how to automatically verify AKA protocols for multi-server IoT.
9 Conclusion and Future Work
In this article, we have provided the FVF-AKA. Xue et al.’s AKA protocol and Bae and Kwak’s AKA protocol have been selected as two case studies. With this framework, they can be modeled to support the verification of the fundamental properties (deadlock freedom, entity legitimacy, timeout delay, and session key consistency). We have applied the integration of C# in PAT to support modeling and verification. We have formalized the registration phase and the authentication phase in protocols. We have also provided a convenient automatic conversion approach to support the conversion from the CSP model to the PAT model. After feeding the CSP models to the powerful model checker PAT supported by C#, the four fundamental properties have been verified, and the valid verification results have indicated that the two protocols work properly in a safe environment. For supporting vulnerable environments, we also have introduced the intruders into CSP models and have verified security properties for the AKA protocol under four different attacks (relay attacks, denial of service attacks, server spoofing attacks, and session key attacks). According to the verification results, two protocols are resistant to these attacks. Our formal verification framework of AKA protocols for multi-server IoT would hopefully help to verify AKA protocols and analyze their performance in a vulnerable environment.
As for future work, we would like to focus on other attacks such as stolen smart card attacks and masquerade attacks and consider extending the FVF-AKA to model and verify other AKA protocols for multi-server IoT.