MFF-IoT: A Multi-Granularity Formal Framework of User Authentication for IoT

Abstract

The Internet of Things (IoT) generates vast amounts of data from numerous applications. However, since wireless channels are the primary means of communication, IoT networks are vulnerable to several security threats, which can compromise their security and privacy. To address these issues, various user authentication protocols have been proposed. Thus, it is still a challenge to provide multi-granularity verifications for different authentications of the IoT. In this paper, we propose a multi-granularity formal framework of user authentication for the IoT (MFF-IoT). Our framework builds different formal models (specification language HLPSL models, process algebra CSP models, Timed CSP models, and timed automata) to complete multi-granularity formal verification. By using both coarse-grained and fine-grained modeling, we can balance the tradeoff between model complexity and verification accuracy. Specifically, our fine-grained models provide a more detailed representation of the framework’s behavior and enable us to perform timing-related probability analysis. As these formal models can be implemented by model-checking tools (AVISPA, PAT with C#, and UPPAAL), important properties and features can be analyzed and verified. We also propose several algorithms for better formal model building and evaluate our framework with a case study to show its practicality and effectiveness.

1. Introduction

The Internet of Things (IoT) is composed of a large number of devices that can connect and exchange data with each other over the Internet or other communication networks. IoT devices are growing at an unprecedented rate, and they are involved in many fields, including homes, offices, transportation, healthcare, etc. Although this situation provides tremendous convenience to our lives, it provides insufficient security due to the immaturity of the technology. As more devices are connected to the Internet, adversaries have more opportunities to use them to launch large-scale attacks [1,2]. Therefore, securing IoT devices is an increasingly serious challenge for manufacturers and consumers. Authentication frameworks and mechanisms [3,4] have been proposed in response to this challenge.

User authentication is an important part of the authentication framework. If there are security holes in user authentication, the risk of being invaded is very serious. Attackers can exploit these holes to carry out malicious activities, such as stealing sensitive data, tampering with device settings, etc. Therefore, verification is required to ensure that the implementation of the authentication framework for IoT satisfies the requirement (or specification) of security. Common methods for the verification process include simulating, testing, or formal verification (e.g., model checking). Formal verification is a method that can describe the system and its requirements formally. It mathematically proves whether the system meets these requirements. Model checking is one of the most popular formal verification techniques, which can automatically verify finite-state machines. Therefore, formal verification is recommended for user authentication in IoT applications.

As model checking helps to avoid manual testing and save time, it is suitable for modeling the authentication framework [5]. However, model-checking-based methods are still not widely used in the IoT. One reason is that it is very difficult for users to build a multi-granularity support model. Although some researchers have conducted formal verification of their schemes [6,7], there is a lack of methods to evaluate performance in a multi-grained way. To solve this problem, a formal verification method should generate multi-granularity formal models from the authentication framework as automatically as possible.

1.1. Contribution

As discussed above, our motivation is to provide a multi-granularity formal framework of user authentication for the IoT (MFF-IoT) that consists of one coarse-grained formal verification and two fine-grained formal verifications. Formal verification is a methodology that employs mathematical techniques to ensure that a system satisfies a predetermined set of properties. Model checking is one such technique, which involves verifying a formal model of the system against a set of formal specifications or properties. The formal verification technique we used is model checking, specifically using the model checkers AVISPA [8], PAT [9] and UPPAAL-SMC [10]. In model checking, the formal model is typically expressed in a formal language such as CSP or Timed CSP, and the model checker systematically explores all possible states of the model to verify whether the specifications hold for all possible system executions. Granularity refers to the level of detail at which the formal model is constructed. In coarse-grained formal verification, some aspects of the authentication framework’s behavior are abstracted away, while in fine-grained formal verification, all aspects of the authentication framework are modeled explicitly. We introduce two kinds of fine-grained models; the second fine-grained formal verification places a greater emphasis on timing-related probability analysis than the first fine-grained formal verification.

Figure 1 (Page 3) presents the overall architecture of MFF-IoT, and Figure 2 (Page 3) illustrates a flow chart of MFF-IoT. In the coarse-grained formal verification, we constructed the authentication framework as HLPSL [11] models, which are fed to the AVISPA tool to complete basic security verification. In the first fine-grained formal verification, we use formal language to describe the authentication framework, resulting in corresponding CSP models and Timed CSP models, which are then implemented using the model checker PAT with C#. The CSP models and Timed CSP models are checked against linear temporal logic (LTL) properties. In the second fine-grained formal verification, we construct timed automata in the UPPAAL-SMC tool for several components in the authentication framework to verify time-related security probabilistic properties, thus obtaining observable statistics in several different probability settings.

Moreover, we use the gateway-based two-factor authentication (G2F) framework [12] as a case study to show the practicality and effectiveness of MFF-IoT. We propose an algorithm for coarse-grained formal verification to construct HLPSL models for the entities in the G2F framework. We also design two algorithms for the entity’s CSP model building and Timed CSP model building in the first fine-grained formal verification. For the second fine-grained formal verification, our idea is to model key actions using timed automata in the G2F framework from the perspectives of the involved entity (user or intruder).

1.2. Related Work

As a promising method for security assurance, formal verification can apply different kinds of mathematical and logical methods to verify the correctness of designs. It is used in many systems that require safety and security properties. Formal verification also has a variety of applications in the IoT, such as authentication and communication protocols.

Shkarupylo et al. [5] proposed an approach to check the interoperability between the components of IoT systems. Using Temporal Logic of Actions (TLA), TLA+ and PlusCal formalisms, as well as the corresponding TLC (model checker for TLA), the MQTT application IoT protocol is analyzed as a case study. Hofer-Schmitz and Stojanovic [13] reviewed formal methods for a large variety of protocols used in the IoT environment, such as ZigBee, Z-Wave, 6LoWPAN, Sigfox, and Narrowband-IoT. Aziz [14] modeled and analyzed the MQ Telemetry Transport version 3.1 protocol based on a timed message-passing process algebra. They found some potential vulnerabilities and suggested an enhancement. Mohsin et al. [15] introduced a formal framework called IoTSAT using SMT logic. The framework can create a satisfiable (SAT) answer, which carries the threat resilience and presents the potential threat vectors. Mahadewa et al. [16,17] presented an approach that checks the security of the implementations of IoT systems by extracting the abstract specification of the application-layer protocol and internal behaviors. They discovered twelve security vulnerabilities in three IoT systems. Aktas and Astekin [4] proposed a run-time formal verification mechanism to support self-healing IoT applications that can detect faulty running behavior in IoT devices. These studies provided a variety of verifications for specific IoT authentication but failed to provide a general verification supporting multi-granularity. Our work introduces the verification of various security properties in a multi-grained way.

The rest of this paper is organized as follows. Section 2 presents the related background. Section 3 provides the architecture of our methodology. Section 4 applies MFF-IoT in a case study. Finally, Section 5 concludes the paper and discusses future work.

2. Background

In this section, we present process algebra CSP and Timed CSP. Model-checking tools AVISPA, PAT, and UPPAAL are also introduced. A case study for MFF-IoT is also presented.

2.1. CSP and Timed CSP

As one of the most mature formal methods, communicating sequential processes (CSP) [18,19] is tailored to describe the interaction between concurrency systems via mathematical theories. Because of its well-known expressive ability, CSP has been widely used in many fields [20,21]. CSP processes are constituted by primitive processes and actions. We use the following syntax to define the processes in this paper, where $\mathit{P}$ and $\mathit{Q}$ represent processes, and $\alpha \left(\mathit{P}\right)$ and $\alpha \left(\mathit{Q}\right)$ indicate the sets of actions that processes $\mathit{P}$ and $\mathit{Q}$ can take, respectively. Hence, $\mathit{a}$ and $\mathit{b}$ denote atomic actions, and $\mathit{c}$ represents a channel.

$$\begin{array}{cc}\hfill \mathit{P},\mathit{Q}::=& ...\mid \mathit{SKIP}\mid \mathit{a}\to \mathit{P}\mid \mathit{c}?\mathit{x}\to \mathit{P}\mid \mathit{c}!\mathit{e}\to \mathit{P}\mid \mathit{P}\parallel \mathit{Q}\mid \mathit{P};\mathit{Q}\hfill \end{array}$$

where SKIP is process that only terminates successfully. $\mathit{a}\to \mathit{P}$ first performs action $\mathit{a}$, then behaves like $\mathit{P}$. $\mathit{c}?\mathit{x}\to \mathit{P}$ receives a message from channel $\mathit{c}$ and assigns it to variable $\mathit{x}$, then implements the subsequent behavior like $\mathit{P}$. $\mathit{c}!\mathit{e}\to \mathit{P}$ sends a message ($\mathit{e}$) through channel $\mathit{c}$, then performs $\mathit{P}$. $\mathit{P}\Vert \mathit{Q}$ shows the parallel composition between $\mathit{P}$ and $\mathit{Q}$. P;Q represent the execution of P and Q, respectively.

Timed CSP [22] is an extension of CSP with a time concept. It is defined as follows.

$$\begin{array}{c}\hfill \mathit{P},\mathit{Q}::= ...\mid \mathit{WAIT}\mathit{t}\mid \mathit{P}{⊳}^{\mathit{t}}\mathit{Q}\end{array}$$

where WAIT t is a delayed form of $\mathit{S}kip$ and only terminates after the specified time ($\mathit{t}$). The notation $\mathit{P}{⊳}^{\mathit{t}}\mathit{Q}$ indicates that if process P is not executed within a certain time interval of t time units, process Q will be executed at time t. In other words, $\mathit{P}{⊳}^{\mathit{t}}\mathit{Q}$ specifies a constraint on the maximum duration of the execution of process P, and if this constraint is violated, process Q is activated to perform a recovery action or to initiate a new activity. It is useful in modeling real-time systems in which processes need to be completed within specific time constraints.

2.2. AVISPA, PAT, and UPPAAL

The Automated Validation of Internet Security Protocols and Applications (AVISPA) tool [8] provides a modular and expressive formal language for specifying protocols and security properties. It integrates different back ends that implement a variety of automatic protocol analysis techniques. It can also automatically translate the High-Level Protocol Specification Language (HLPSL) [11] specification into an equivalent specification written in the rewrite-based formalism (Intermediate Format IF), then obtain the checking results. AVISPA has been successfully employed in some classic and familiar protocols and schemes [8,23].

As a model-checking tool, the Process Analysis Toolkit (PAT) [9] was designed as an extensible and modularized framework based on CSP, which can also support Timed CSP. Different model-checking techniques are implemented in PAT, supporting many assertions, such as deadlock freeness and reachability [24]. With advanced optimization techniques implemented in PAT, it can achieve satisfactory performance.

UPPAAL is an integrated tool for the modeling, simulation, and verification of real-time systems [10]. It is appropriate for verifying systems that can be modeled as a collection of non-deterministic processes with finite control structures and real-valued clocks, communicating through channels or shared variables. UPPAAL-SMC is an extension of UPPAAL that can reason on networks of complex real-time systems under natural stochastic semantics, which is based on the idea of statistical model checking (SMC). UPPAAL has achieved fruitful results in industry [25] and achieves satisfactory performance in protocol verification [26]. Therefore, these three powerful tools can effectively support our multi-granularity formal verification method.

2.3. Case Study: Gateway-Based Two-Factor Authentication (G2F)

Lou et al. [12] introduced a secure user authentication for IoT management called G2F. The whole authentication scheme is based on the Universal Second Factor (U2F) protocol proposed by the FIDO Alliance. G2F can prevent malicious activity on IoT devices hosted on cloud servers, which also helps protect IoT devices from malicious attacks. It is an efficient, secure, and flexible user authentication solution for IoT-based smart homes, which makes it a suitable case study. Our proposed framework can also be applied to other user authentication schemes, such as those used in IoT-based healthcare [27]. The G2F system consists of five components:

• IoT Server: The IoT Server offers various IoT services, such as remote control and configuration of IoT devices;
• U2F Server: The U2F server works in coordination with the hardware token to facilitate registration and authentication processes. It is responsible for storing crucial security elements related to the hardware token, including public keys, key handles associated with public keys, etc;
• Gateway Node (GWN): The GWN serves as a bridge connecting IoT devices to a cloud server. Its main function is to gather data from IoT devices and transmit them to the cloud server for processing. Additionally, the GWN is equipped with a USB interface, which allows for the insertion of a hardware token;
• Hardware Token: The hardware token is a highly secure component held by the user and designed to be tamper-proof. It contains private keys and other security elements and communicates with the GWN through a USB interface. When registration or authentication requests are made, users can respond by pressing the button on the token;
• IoT Device: IoT devices are owned by the user and are managed through the IoT Server. They connect to the GWN wirelessly to access network services. The client GUI of the IoT server allows users to perform operations on their IoT devices.

The G2F system is comprised of three levels: the cloud server, the gateway node, and the user. The U2F server and IoT server belong to the cloud server level, while the hardware token and GWN belong to the gateway node level. The IoT device and the client belong to the user level.

The G2F framework includes the registration phase and authentication phase. We only introduce the authentication phase because most attacks occur in this phase, and our work mainly analyzes this part. User authentication is needed when the user wants to start operations on the IoT device through the IoT server. A detailed description of the G2F authentication phase is presented in

Table 1. Explanations of notations in the authentication phase of the G2F framework.

Notation	Explanation
app_id	The identity of the IoT application
challenge	A random number created by the U2F server
channel_id	The identity of the transport-layer security (TLS) channel
origin	The uniform resource identifier (URI) of the U2F server
k${}_{pri}$, k${}_{pub}$	The private key and public key generated by the hardware token
counter	The counter counting authentication times
handle	The key handle created by the hardware token
signature	The signature itself or the signing operation produced by the hardware token

, with explanations of the notations that appear in the authentication phase.:

$$\begin{array}{cc}\hfill & \mathrm{Step}1.\mathrm{IoT}\mathrm{Server}\to \mathrm{GWN}:\mathrm{notify}\mathrm{GWN}\mathrm{to}\mathrm{start}\mathrm{authentication};\hfill \\ \hfill & \mathrm{Step}2.\mathrm{GWN}\to \mathrm{U}2\mathrm{F}\mathrm{Server}:\mathrm{submit}\mathrm{authentication}\mathrm{request};\hfill \\ \hfill & \mathrm{Step}3.\mathrm{U}2\mathrm{F}\mathrm{Server}\to \mathrm{GWN}:\left\{\mathit{handle},\mathit{app\_id}, \mathit{challenge}\right\};\hfill \\ \hfill & \mathrm{Step}4.\mathrm{GWN}:\mathrm{verify}\mathit{app\_id};\hfill \\ \hfill & \mathrm{Step}5.\mathrm{GWN}\to \mathrm{Hardware}\mathrm{Token}:\left\{\mathit{handle},\mathit{app\_id},\mathit{challenge},\mathit{origin},\mathit{channel\_id}\right\};\hfill \\ \hfill & \mathrm{Step}6.\mathrm{Hardware}\mathrm{Token}:\mathrm{find}{K}_{\mathit{priv}}\mathrm{linked}\mathrm{with}h;\mathit{counter}=\mathit{counter}+1;\hfill \\ \hfill & \mathrm{Step}7.\mathrm{Hardware}\mathrm{Token}\to \mathrm{GWN}:\hfill \\ \hfill & \left\{\mathit{counter},\right[\mathit{app\_id},\mathit{challenge},\mathit{origin},\mathit{channel\_id},\mathit{counter}],{\mathit{K}}_{\mathit{priv}}\};\hfill \\ \hfill & \mathrm{Step}8.\mathrm{GWN}\to \mathrm{U}2\mathrm{F}\mathrm{Server}:\left\{\mathit{counter},\mathit{challenge},\mathit{origin},\mathit{channel\_id},\mathit{signature}\right\};\hfill \\ \hfill & \mathrm{Step}9.\mathrm{U}2\mathrm{F}\mathrm{Server}:\mathrm{verify}\mathit{signature}\mathrm{using}{K}_{\mathit{pub}}\mathrm{linked}\mathrm{with}\mathit{handle};\hfill \\ \hfill & \mathrm{verify}\mathit{origin},\mathit{channel\_id},\mathit{counter};\hfill \\ \hfill & \mathrm{Step}10.\mathrm{U}2\mathrm{F}\mathrm{Server}\to \mathrm{IoT}\mathrm{Server}:\mathrm{feed}\mathrm{back}\mathrm{the}\mathrm{result};\hfill \\ \hfill & \mathrm{Step}11.\mathrm{IoT}\mathrm{Server}:\mathrm{check}\mathrm{whether}\mathrm{authentication}\mathrm{is}\mathrm{passed};\hfill \\ \hfill & \mathrm{Step}12.\mathrm{IoT}\mathrm{Server}\to \mathrm{IoT}\mathrm{Device}:\mathrm{operation}\mathrm{on}\mathrm{the}\mathrm{IoT}\mathrm{device}.\hfill \end{array}$$

If the IoT server is informed to start an operation, it tells the GWN to send an authentication request to the U2F server; then, GWN sends an authentication request to the U2F server (steps 1–2). The U2F server replays {handle, app_id, challenge} to the GWN; then, the GWN checks app_id and sends {handle, app_id, challenge, origin, channel_id} to the hardware token (steps 3–5). The counter is increased when a signature is generated (i.e., the hardware token signs {app_id, challenge, origin, channel_id, counter} by k${}_{pri}$), and k${}_{pri}$ can be obtained based on handle (step 6). Then, the hardware token transmits {counter, signature} to the GWN (step 7). The GWN sends this message, together with the message it previously received from the hardware token, to the U2F server (step 8). The U2F server verifies the signature using the public key k${}_{pub}$ (step 9). The verification result is returned to the IoT server (step 10). If the user authentication is successful, the IoT server allows the operation on the IoT device (steps 11–12).

2.4. Threat Model

As all communication channels are unencrypted, attackers can obtain all messages. While they cannot obtain the hardware token, they can conduct a hardware token faking attack using their own public and private keys to forge signatures. Attackers can perform both single and persistent multiple attacks. In a single attack, they execute the hardware token faking attack only once within a designated time frame, assuming there are no normal user operations that need to be executed during this period. In a persistent multiple attack, they continuously execute hardware token faking attacks within a designated time frame, assuming there are normal user operations that need to be executed during this period.

3. The Architecture of Our Methodology

In this section, we introduce MFF-IoT, as illustrated in Figure 1, including coarse-grained formal verification, a first fine-grained formal verification, and a second fine-grained formal verification. Figure 2 shows a flow chart of MFF-IoT.

3.1. Representation of the Authentication Framework

In the process of modeling, whether at a coarse-grained or fine-grained level, it is necessary to model the entities of the authentication framework ($\mathcal{F}$) and specifically model the actions performed by these entities. In $\mathcal{F}$, most actions involve communication, while a small portion involves processing. The former often involves sending information, including signatures, to another entity, while the latter involves processing counters or performing signature-related behaviors. As an example of communication action, in coarse-grained modeling, keywords such as RCV and SND from communication protocols can be used to describe the corresponding receiving and sending of transmitted content. In fine-grained modeling, channels can be used for message transmission and reception.

3.2. Coarse-Grained Formal Verification in AVISPA

In the coarse-grained formal verification, we propose the use of the HLPSL algorithm to model the entity role in any authentication framework using the AVISPA tool. The overall steps can be roughly summarized as follows:

• Divide the roles according to the entities in the authentication framework;
• Define local variables;
• Set different transition states;
• For transmission actions, the actions in the transition are defined as assignment, sending, and receiving.

Further details can be found in Algorithm 1. After applying Algorithm 1 to generate the HLPSL model of each entity in the authentication framework, we adopt the homologous OFMC tool in AVISPA to verify the authentication property between entities and provide a general but coarse-grained conclusion as to whether a basic intrusion is detected, which indicates which element is most likely to cause intrusion.

3.3. First Fine-Grained Formal Verification in CSP and Timed CSP

In the coarse-grained formal verification, we only focus on the knowledge domain of the intruder and pay no attention to attack types. To solve this problem, we propose the first fine-grained formal verification. Algorithm 2 can be applied to build the CSP model of each entity. By combining different CSP models of entities with the parallel composition operator, the overall model for the authentication framework can be described.

Then the CSP models can be implemented in PAT and C#. Because PAT is extended based on CSP, the 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 for the use of C# code for libraries. C# classes are built as DLL and imported into the PAT model when the functions are used. As a result, we choose to implement our functions in the C# language. To convert the CSP model to the PAT model, the PAT model calls the C# functions, which have implemented processing actions, completing the integration of C# into PAT to support modeling and verification.

After the CSP models are implemented in PAT and C#, we can verify some properties, such as the deadlock property and the property indicating whether digital signatures can be verified under attacks. These properties can be described as linear temporal logic (LTL) formulations and verified using PAT. To support the verification of single attacks and persistent multiple attacks, we update the overall CSP model in the overall Timed CSP model. As a result, the CSP model of the entity involving time can be updated to the Timed CSP model using Algorithm 3. A renaming operation is used to support the description of the intruder. The WAIT operator in timed CSP can simulate the waiting time. With the help of this operator, the overall Timed CSP model can be constructed. The subsequent verification is still conducted in PAT in the same way, which is also able to detect single attacks and persistent multiple attacks.

Algorithm 1 Entity’s HLPSL Model Building Algorithm

Input:  entity name e, entity’s key set K,       entity’s local known elements set E, entity’s steps list S.       the sequence number of the steps list of this entity N Output: string of entity’s HLPSL model p.  1: Extract messages in S into message set M and communication entity set M’  2: p← “role  role_”+e+“(”+e+“:agent”+       elements in E separated with “:text,”  3: if K ∉ ∅ then  4:    p ←p+elements in K separated with          “:public_key,”+“SND, RCV:channel(dy))”  5: else  6:    p ← p+“SND, RCV:channel(dy))”  7: end if  8: p←p+“played_by HardwareToken”  9: p←p+“def=local State:nat,”+       elements in M separated with “:text,”+       elements in S separated with “:agent” 10: Choose the relevant sequence number of the steps to assign to the transition state 11: p←p+“init State:=”+choose the relevant number N${}_i$ in N 12: Find the elements changed in M to form M’ 13: p←p+“transition”+choose the relevant number N${}_j$ in N + “. State=N${}_i$∧RCV(”+elements in S with “ ’ ”+e+“.”+messages in M-M’ separated with “ ’ ”+“) $=|>$”+“ State’:=”+choose the relevant number N${}_k$ in N + elements in M’ with “ ’ ”+“:=new()” 14: if we need to verify the authentication property between e and the entity in S then 15:    Define the authentication property auth 16:    p ←p+“∧ witness(”+e+“,”+elements in S +       “,” + auth + “,” + elements in M’ with “ ’ ”+“)”+       “∧ SND(”+e+“.”+elements in S with “ ’ ”+“.”+       elements in E+“.”+elements in M’ with “ ’ ”+       “_inv(”+elements in K+“)) end role” 17: else if we request to check the authentication property between e and the entity in S then 18:    Define the authentication property auth 19:    p ←p+“∧ request(”+e+“,”+elements in S +       “,” + auth + “,” + elements in M’ with “ ’ ”+“)”+       “∧ SND(”+e+“.”+elements in S with “ ’ ”+“.”+       elements in E+“.”+elements in M’ with “ ’ ”+       “_inv(”+elements in K+“)) end role” 20: else 21:    p ←p+“∧ SND(”+e+“.”+elements in S with “ ’ ”+       “.”+elements in E+“.”+elements in M’ with       “ ’ ”+“_inv(”+elements in K+“)) end role” 22: end if 23: return p

Algorithm 2 Entity’s CSP Model Building Algorithm

Input: entity name e, channel names set C,       entity’s local known elements set E, entity’s steps list S. Output: string of entity’s CSP model p.  1: Extract messages in S into message set M  2: p←e+“(”+       elements in E separated with commas+“) =${}_{\mathit{df}}$”  3: while s ∈ S do  4:    if s is a transferring action between e and entity e’ then  5:      Find channel c in C connecting e and e’  6:      Find message m in M corresponding to s  7:    end if  8:    if s is a sending action then  9:      Add ’ suffix to elements in m not belong to E 10:      p ←p+c+“?”+m+“→” 11: else if s is a receiving action then 12:      Add “ ’ ” suffix to all the elements in m 13:      string p ←p+c+“!”+m+“→” 14:    else 15:      Create n as processing action’s name of s. 16:      p ←p+n+“→” 17:    end if 18: end while 19: p←p+“SKIP” 20: return p

Algorithm 3 Entity’s Timed CSP Model Building Algorithm

Input: string of entity’s CSP model p, times t${}_1$ and t${}_2$. Output: string of entity’s Timed CSP model tp.  1: Divide p into process head ph and process body pb by searching for a pattern which is “=${}_{\mathit{df}}$”.  2: if there are operations in pb that need to be executed within time t${}_1$ then  3:    Divide pb into two disjoint parts pb${}_1$ and pb${}_2$, where pb${}_1$ has no time limit for execution and pb${}_2$ has a time limit for execution.  4:    pb ←pb${}_1$+“→”+ “(”$p{b}_2$+${⊳}^{t{}_1}$+“SKIP)”  5: end if  6: if pb needs to wait for time t${}_2$ before executing then  7:    pb ←“WAIT t${}_2$; (”+pb+“)”  8: end if  9: tp←ph+“${=}_{\mathit{df}}$”+pb 10: return $tp$

3.4. Second Fine-Grained Formal Verification in UPPAAL-SMC

The first fine-grained formal verification is used to analyze important security properties, which can help to detect security vulnerabilities. However, different time parameters may lead to different results, and the first verification may not be able to further analyze more details. If further probability analysis is needed, we propose a second fine-grained formal verification, which is supported by UPPAAL-SMC. The second verification focuses on situations in which an entity may receive messages from both an intruder and the other entity and involves analysis of the complex interactions between different components to detect security vulnerabilities that may arise due to these interactions.

Specifically, we focus on a situation in which an entity may receive messages from both the intruder and the other entity. According to the action being performed by the entity in the situation, multiple automata are built. They generally simulate the key behaviors of the current entity, the user, and the intruder. The characterization of probability and time is added to the automaton so that UPPAAL-SMC can be applied to verify the properties of the probability-related attacks, which occur in the form of cost-constraint temporal logic formulations.

We chose different verification schemes based on the specific aspects that we want to verify. For example, the coarse-grained formal verification scheme only focuses on the knowledge domain of the intruder. However, for more detailed aspects such as counter changes and timing, the first fine-grained formal verification scheme is necessary. Additionally, if we want to analyze the probabilities of time-related events, the second fine-grained formal verification scheme becomes indispensable. The AVISPA tool is not suitable for capturing the details of element changes, so we use CSP and timed CSP, which provide support for time and element changes, and UPPAAL-SMC, which supports the analysis of time-related probabilities.

4. Application of MFF-IoT in the G2F Framework

In this section, we apply MFF-IoT in the G2F framework. By modeling the G2F framework in HLPSL models, CSP models, Timed CSP models, and timed automata, security properties are described and verified. We also analyze and discuss the verification results.

4.1. Coarse-Grained Formal Verification for G2F

We provide the coarse-grained formal verification for the G2F framework. The AVISPA tool is used to model the authentication phase of the G2F framework. The security of this phase is analyzed below.

4.1.1. Modeling the G2F Framework in AVISPA

The authentication phase of G2F involves five entities: the hardware token, GWN, U2F server, IoT server, and IoT service. Henceforth, we model this phase based on these five entities’ roles. In addition, an entity role intruder is added to our HLPSL model, which knows all the messages except the hardware token. Here, we also only provide the HLPSL model of the hardware token in AVISPA as an example, which is shown in

Table 2. The HLPSL model of the hardware token.

$\mathit{role}\mathit{role}\_\mathit{HardwareToken}(\mathit{HardwareToken}:\mathit{agent},\mathit{Counter}:\mathit{text},\mathit{K}:\mathit{public}\_\mathit{key},\mathit{SND},\mathit{RCV}:\mathit{channel}(\mathit{dy}\left)\right)$	(1)
$\mathit{played}\_\mathit{by}\mathit{HardwareToken}$	(2)
$\mathit{def}=$	(3)
$\mathit{local}$	(4)
$\mathit{State}:\mathit{nat},\mathit{ChanID}:\mathit{text},\mathit{Challenge}:\mathit{text},\mathit{Handle}:\mathit{text},\mathit{AppID}:\mathit{text},\mathit{Origin}:\mathit{text},\mathit{SSS}:\mathit{text},\mathit{GWN}:\mathit{agent}$	(5)
$\mathit{init}$	(6)
$\mathit{State}:=\mathit{0}$	(7)
$\mathit{transition}$	(8)
$\mathit{4}.\mathit{State}=\mathit{0}\wedge \mathit{RCV}({\mathit{GWN}}^{\prime }.\mathit{HardwareToken}.{\mathit{Handle}}^{\prime }.{\mathit{AppID}}^{\prime }.{\mathit{Challenge}}^{\prime }.{\mathit{Origin}}^{\prime }.{\mathit{ChanID}}^{\prime })=|>$	(9)
${\mathit{State}}^{\prime }:=\mathit{1}\wedge {\mathit{SSS}}^{\prime }:=\mathit{new}\left(\right)\wedge \mathit{witness}(\mathit{HardwareToken},\mathit{GWN},\mathit{auth}\_\mathit{1},{\mathit{SSS}}^{\prime })\wedge$	(10)
$\mathit{SND}(\mathit{HardwareToken}.{\mathit{GWN}}^{\prime }.\mathit{Counter}.\left\{{\mathit{SSS}}^{\prime }\right\}\_\mathit{inv}\left(\mathit{K}\right))$	(11)
$\mathit{end}\mathit{role}$	(12)

. In this phase, the hardware token can communicate with the entity role GWN so that the input in Algorithm 1 can have the entity name HardwareToken. Similarly, we can provide other content of the input. Hence, the model of the entity role HardwareToken shown in Table 2 illustrates that it has one state to be changed. We also add an intruder into the model and test all the kinds of the knowledge domain. Finally, we know that if we can protect the security and privacy of the hardware token, the safety of the phase can also ensured, no matter what other messages the intruder knows. Please refer to the website (The full implementation in AVISPA can be found in https://github.com/asunafy/MFF/tree/main/AVISPA (accessed on 28 March 2023)) for full implementation in AVISPA.

4.1.2. Security Verification

We adopt the AVISPA tool to verify the security of the authentication phase, and its analysis result is presented in Figure 3. We enable OFMC (on-the-fly model checker) in AVISPA to verify the identity authentication between the GWN and the hardware token as the goal in order to verify the security of the G2F framework design. The statistics presented in Figure 3 show that the state search time during the entire verification process is 1.23 s, with 648 visited nodes and a depth of 11 plies, and the summary is safe.

In particular, we assume that both intruders and normal entities can ensure the normal operation of the function. According to the analysis result, we believe that as long as the hardware token is not leaked, even if the intruder knows all other information and has public and private keys to intervene, the security of this protocol can still be guaranteed. That is to say that the hardware token is held by the user, so we can infer that the design of the G2F framework for the authentication phase is secure. Thus, we can conclude that the G2F framework is capable of resisting hardware token faking attacks, assuming that the signature content is not taken into consideration and the hardware token has not been lost.

4.2. First Fine-Grained Formal Verification for G2F

In the coarse-grained formal verification, we only focus on the knowledge domain of the intruder and pay no attention to attack types and signatures. Our first fine-grained formal verification supports the discussion provided in this section. Specifically, we provide the CSP models of entities to build the system and update them into the Timed CSP model to discuss the performance of the G2F framework under a single attack and persistent multiple attacks. They are also implemented in PAT and C#. Finally, the model-checking tool PAT is applied to verify security properties (deadlock freedom, signature verification, and intruder success).

4.2.1. Modeling the G2F Framework in CSP

To simplify the model, we focus on the steps involving the transmission of key information in the authentication phase of the G2F framework, which are shown in Steps 3–9. There are three entities involved in this process: the hardware token, GWN, and U2F server. The related CSP models are built by Algorithm 2. Then, we can obtain the overall model (G2F_Auth()) with the parallel composition operator. We then study a hardware token faking attack in which the hardware token is replaced by a fake token. Its CSP model is G2F_Auth_S(), which is almost the same as G2F_Auth(), except that the parameter of the signature is replaced by a fake parameter.

We explain the CSP model of the hardware token (HT_Auth()) as an example, which is illustrated in

Table 3. The CSP model and Timed CSP model of the hardware token.

$\mathit{HT}\_\mathit{Auth}(\mathit{counter},\mathit{signature}){=}_{\mathit{d}\mathit{f}}$	(1)
$\mathit{ComGH}\_\mathit{U}?\mathit{msg}$auth$.{\mathit{handle}}^{\prime }.\mathit{app}\_{\mathit{id}}^{\prime }.{\mathit{challenge}}^{\prime }.{\mathit{origin}}^{\prime }.\mathit{channel}\_{\mathit{id}}^{\prime }\to$	(2)
$\mathit{Increase}\_\mathit{Counter}\to \mathit{Generate}\_\mathit{Signature}\to$	(3)
$\mathit{ComGH}\_\mathit{U}!{\mathit{msg}}_{\mathit{auth}}.\mathit{counter}.\mathit{signature}\to \mathit{SKIP}$	(4)
$\mathit{HT}\_{\mathit{Auth}}^{\prime }(\mathit{counter},\mathit{signature}){=}_{df}$	(5)
$\mathit{WAIT}\mathit{t};(\mathit{ComGH}\_\mathit{U}?\mathit{msg}$auth$.{\mathit{handle}}^{\prime }.\mathit{app}\_{\mathit{id}}^{\prime }.{\mathit{challenge}}^{\prime }.{\mathit{origin}}^{\prime }.\mathit{channel}\_{\mathit{id}}^{\prime }\to$	(6)
$\mathit{Increase}\_\mathit{Counter}\to \mathit{Generate}\_\mathit{Signature}\to$	(7)
$\mathit{ComGH}\_\mathit{U}!\mathit{msg}$auth$.\mathit{counter}.\mathit{signature}\to \mathit{SKIP})$	(8)

. This process describes the behaviors of the hardware token when communicating with the GWN in the authentication phase. It first obtains handle, app_id, challenge, origin, and channel_id from the GWN (step6). Through the action Increase_Counter and Generate_Signature, it increases the counter and creates signature using the private key included in handle (step7). Finally, it transmits counter and signature to the GWN (step8).

4.2.2. Updating CSP Models to Timed CSP models

To discuss the performance of the G2F framework under a single attack and persistent multiple attacks [12], we upgrade the CSP model to the Timed CSP model to support appreciably finer-grained formal verification. Table 3 also shows the Timed CSP model of the hardware token (HT_Auth’()). We also verify two properties (deadlock freedom and intruder success) under the two attacks for the new models (G2F_Auth_Single() and G2F_Auth_Multiple()).

In the single attack and persistent multiple attacks, intruders request that IoT servers perform a malicious operation. Whether step 7 and the subsequent steps are performed depends on whether the user presses the button on the hardware token. In a single attack, we assume that the user does not press the button within the time consumption of the authentication phase. For persistent multiple attacks, the user may submit a legitimate request during the period during which the intruder continues to send malicious operation requests. Then, the user presses the button for his legitimate request, which may cause the malicious operation request to be passed. Equipped with Algorithm 3, we complete the conversion from the CSP models involving time to Timed CSP models.

4.2.3. Property Verification

We implemented CSP models and Timed CSP models in the PAT tool (The full implementation of the CSP models in PAT and C# can be found in https://github.com/asunafy/MFF/tree/main/PAT (accessed on 28 March 2023)). The implementation capability of PAT for data processing is limited, and using its C# interface would be beneficial to perform additional actions, such as making signatures. Moreover, C++ provides better support for random number generation, so we can import C++ functions into C# code. Specifically, to implement the steps belonging to processing actions, we introduce one C++ function and five C# functions. The C++ function is built as DLL, then imported into the C# class. The six functions implement random number generation, type conversion, file storage, file reading, signature generation, and signature verification, respectively. We provide three properties to be verified in

Table 4. Properties in PAT.

$\#\mathit{assert}\mathit{System}\left(\right)\mathit{deadlockfree};$	$\left(1\right)$
$\#\mathit{define}\mathit{SignatureCheck}(\mathit{signaturecheck}==\mathit{true});$	$\left(2\right)$
$\#\mathit{assert}\mathit{G}\mathit{2}\mathit{F}$_$Auth\left(\right)|=<>\mathit{SignatureCheck};$	$\left(3\right)$
$\#\mathit{assert}\mathit{G}\mathit{2}\mathit{F}$_$Auth$_$S\left(\right)|=<>\mathit{SignatureCheck};$	$\left(4\right)$
$\#\mathit{define}\mathit{IntruderSuccess}(\mathit{intrudersuccess}==\mathit{true});$	$\left(5\right)$
$\#\mathit{assert}\mathit{G}\mathit{2}\mathit{F}$_$Auth$_$Single\left(\right)\mathit{reaches}\mathit{IntruderSuccess};$	$\left(6\right)$
$\#\mathit{assert}\mathit{G}\mathit{2}\mathit{F}$_$Auth$_$Multiple\left(\right)\mathit{reaches}\mathit{IntruderSuccess};$	$\left(7\right)$

.

• Deadlock freedom property (in Table 4(1)): All the CSP and Timed CSP models should have no deadlock. “deadlockfree” is the reserved keyword of PAT. Here, System() refers to all models. The valid verification results of the deadlock freedom property presented in Figure 4a and

  Table 5. The verification results of properties for Timed CSP models.

  Time Parameter Values				Model Verification Results
  				Deadlock Freedom Property		Intruder Success Property
  TU	TOU	TI	TOI	G2F_Auth_Single()	G2F_Auth_Multiple()	G2F_Auth_Single()	G2F_Auth_Multiple()
  4	5	3	5	Valid	Valid	Not Valid	Valid
  7	5	3	5	Valid	Valid	Not Valid	Not Valid
  10	5	3	5	Valid	Valid	Not Valid	Valid
  15	5	3	5	Valid	Valid	Not Valid	Not Valid

  indicate that no deadlock appears in our models. In model checking, only models without deadlocks can be further analyzed.
• Signature verification property (in Table 4(2–4)): In the coarse-grained verification, by default, all signatures can be successfully verified by the U2F server, so the signature verification property is not considered. Here, we verify the signature verification property in the CSP model (G2F_Auth() and G2F_Auth_S()). The property of signature verification is described in the LTL formula, which illustrates a linear-time property. PAT supports the LTL formula by using #assert P() |= F to check whether system P() satisfies the LTL formula F. Using the “eventually” operator ($<>$) in LTL, we describe a situation in which the U2F server checks the signature successfully. As the G2F_Auth_S() introduces signature-faking attacks, the signature verification property can effectively detect these attacks. As shown in Figure 4b, the valid verification result of G2F_Auth() indicates that the G2F framework can successfully verify the signature under normal operation, and the invalid verification result of G2F_Auth_S() means that our methodology is able to detect illegal signatures to protect the user’s legal authentication. Therefore, we can conclude that G2F can effectively identify the signature of a hardware token forged by an intruder.
• Intruder success property (in Table 4(5–7)): The intruder success property checks whether our model can be invaded under single attacks and persistent multiple attacks and is expressed as reachability. Because Timed CSP models G2F_Auth_Single() and G2F_Auth_Multiple() introduce single attacks and persistent multiple attacks, respectively, with the reserved keywords “reaches”, PAT can check whether the system reaches a state at which some given condition is satisfied. For G2F_Auth_Single(), the four invalid results presented in Table 5 indicate that the G2F framework can prevent a single attack under each of the four cases. For G2F_Auth_Multiple(), different verification results appear under different cases in Table 5, indicating that the G2F framework cannot always prevent persistent multiple attacks and that intruders cannot invade successfully every time. Therefore, we can conclude that once introduced into an uncertain environment, there is a possibility that G2F may encounter an intrusion when the timing of an attacker sending intrusion data is close to the timing of user usage.

4.3. Second Fine-Grained Formal Verification for G2F

According to the verification results of Timed CSP models, the intruder may invade the G2F framework when persistent multiple attacks happen, but more detailed information is unknown, such as the probability of being intruded. To further improve the granularity of our formal verification, we use UPPAAL-SMC to model and verify the G2F framework under a single attack and persistent multiple attacks.

4.3.1. Building Timed Automata with Probability Distributions

For persistent multiple attacks, we focus on a situation in which the hardware token receives a notification both from the user and the intruder simultaneously when its button is pushed. Therefore, the behavior of the G2F framework under persistent multiple attacks can be simplified to three automata (The full implementation in UPPAAL-SMC can be found at https://github.com/asunafy/MFF/tree/main/UPPAAL (accessed on 28 March 2023)) (HT automaton, User automaton, and Intruder automaton), as shown in Figure 5. HT automaton denotes a situation in which the hardware token receives notifications from the user or intruder, then completes the push-button action. User automaton indicates a situation in which the user sends a notification to the hardware token. Intruder automaton represents a situation in which the intruder sends notifications to the hardware token periodically. Here, we explain some of the functions implemented in HT automaton shown in Figure 5 as an example. Edges among Idle, PushButton, Invaded, and Safe with the branch illustrate the user and intruder requests are both received when the user pushes the button. The second Boolean condition (intruder&&User) means that the hardware token has received the requests from both the user and the intruder. Meanwhile, the Invaded branch state is with probability weight i_pro, and the Safe branch state is with probability weight u_pro.

4.3.2. Probability Property Verification

Timed automata with probability distributions are implemented by UPPAAL-SMC, which can reason on networks of complex real-time systems under natural stochastic semantics. User_multiple, Intruder_multiple, and HT_multiple are instantiations of automata User, Intruder, and HT, respectively, for persistent multiple attacks. At the same time, Intruder_single and HT_single are instantiations of Intruder, and HT automata, respectively for a single attack and are included in the system for a single attack. Thus, we can verify the probability of the G2F framework being safe or being invaded.

The four queries in

Table 6. Properties in UPPAAL.

$\mathit{Pr}[$<$=100]<>(\mathit{HT}$_$single.Safe)$	$\left(1\right)$
$\mathit{Pr}[$<$=100]<>(\mathit{HT}$_$single.Invaded)$	$\left(2\right)$
$\mathit{Pr}[$<$=100]<>(\mathit{HT}$_$multiple.Safe)$	$\left(3\right)$
$\mathit{Pr}[$<$=100]<>(\mathit{HT}$_$multiple.Invaded)$	$\left(4\right)$

are the properties of security probability. They estimate the four probabilities that HT_multiple and HT_single will reach a Safe state or Invaded state before 100 time units.

• Probability properties of single attacks: According to the four different probability settings shown in Figure 6, the query in Table 6(1) has the same answer [0.901855, 1] with a confidence of 0.95 in 29 runs. Meanwhile, the query in Table 6(2) has the same answer [0, 0.0981446] with a confidence of 0.95 in 29 runs. The results indicate that single attacks fail in most cases. Therefore, we can conclude that in most cases, a single attack will not pose a threat to the security of the G2F framework.
• Probability properties of persistent multiple attacks: Using the four probability settings in Figure 6, the answers of the query in Table 6(3) are [0.499902, 0.599848], [0.757374,0.857253], [0.393781, 0.49372], and [0.822723, 0.922673], with 95% confidence intervals obtained from 398, 254, 397, and 182 runs, respectively. Meanwhile, the answers to the query in Table 6(4) are [0.421586, 0.521483], [0.151334, 0.251058], [0.473541, 0.573489] and [0.0619394, 0.16173], with 95% confidence intervals obtained from 401, 263, 401, and 163 runs, respectively. These results show that HT_multiple has a higher probability of reaching a Safe state than reaching an Invaded state within the given time limit, except when probability parameters both_pro and i_pro are too large. That is to say that persistent multiple attacks can be successful with a certain probability, but the probability is generally lower than that of an unsuccessful attack. Figure 6 shows the probability density distribution of the two time-bounded reachability properties, the abscissa means of which run for a duration in time. Therefore, we can conclude that in most cases, the probability of entering a safe state is higher than that of entering an unsafe state. In some cases, the probability of the two states is similar. Thus, the G2F framework defense mechanism is relatively weak against persistent multiple attacks, and caution is still needed.

4.4. Proposed Algorithms

Algorithm 1 is designed to build an HLPSL model. We instantiate and explain the algorithm by building the HLPSL model of the hardware token in Table 2. Line 2 in Algorithm 1 provides the roles and their parameters (corresponding to line 1 in Table 2). Lines 3–5 in Table 2 generate their parameters and corresponding types (through line 9 of Algorithm 1). The transition starting from lines 9–12 in Table 2 is generated by dividing the functions of different entity roles (through lines 12–22 in Algorithm 1).

Algorithm 2 supports the construction of CSP models for entities. Here, we demonstrate the process of constructing a partial CSP model for the hardware token. Specifically, we refer to steps 5–7 and extract three messages to form a message set (line 1 in Algorithm 2). Based on the local known elements of the hardware token, which include counter and signature, we can obtain line 1 in Table 3 (through line 1 in Algorithm 2). Taking the first message (corresponding to step 5) as an illustration, we identify it as a transferring action and thus find channel ComGH_U, along with the corresponding message ({handle, app_id, challenge, origin, channel_id}) (through lines 3–7 in Algorithm 2). Additionally, since it is a sending action, the “ ’ ” suffix is added to the element of the message, resulting in lines 1–2 of Table 3 (through lines 8–10 in Algorithm 2).

Algorithm 3 is capable of converting a CSP model into a Timed CSP model. Taking the hardware token as an example, the CSP model (HT_Auth()) (shown in Table 3) is first divided into a process head (ph) (line 1 in Table 3 without “=${}_{\mathit{df}}$”) and a process body (pb) (lines 2–4 in Table 3), which is achieved by line 1 in Algorithm 3. The pb does not contain any operations that need to be executed within a certain time, but it does require a waiting time (t${}_2$) before execution. Therefore, WAIT t${}_2$ needs to be added to the beginning of the pd, and ph and pb are combined again to obtain the Timed CSP model (tp) (lines 2–10 in Algorithm 3), which is shown in lines 5–8 in Table 3.

4.5. Discussion

Currently, MFF-IoT only supports the modeling of operations for general authentication (e.g., encryption and decryption), but it can easily be extended to support other operations using C# integrated into PAT. MFF-IoT is only able to detect signature-faking attacks, single attacks, and persistent multiple attacks; it can also easily be improved by building more formal models for other attack types. Algorithms 1–3 proposed in our framework are reusable and support the modeling of new authentication schemes. They facilitate security analysis in the coarse-grained formal verification and the first fine-grained formal verification. Moreover, this methodology can only be used for user authentication in IoT applications, which means that it does not consider other IoT applications. Although the time to complete each verification is less than 2 s in our case study, an increase in the time parameter may lead to a time increase for fine-grained verification. We will keep improving our methodology to solve these issues.

5. Conclusions and Future Work

In this paper, we have provided a multi-granularity formal framework of user authentication for IoT (MFF-IoT) that includes one coarse-grained modeling and two fine-grained modelings. We used G2F as a case study and formalized it with the AVISPA tool to verify fundamental security properties as a coarse-grained formal verification. We applied process algebra CSP, Timed CSP, and timed automata to build three formal models, then fed them to PAT supported by C# and UPPAAL, which completed two fine-grained formal verifications with gradually finer granularity. We also verified three security properties (deadlock freedom, signature verification, and intruder success), as well as security probability properties, with observable statistics. Based on the verification results, the ability of G2F to resist hardware token faking attacks is influenced by the frequency with which such attacks occur. We represent attack frequency as different weights on the edges of the timed automata, and as this frequency increases, the likelihood of worse system performance also increases. We intend for our MFF-IoT to assist in analyzing the performance of authentication mechanisms in a vulnerable environment in which hardware token faking attacks are possible.

In addition to the vulnerability posed by hardware token faking attacks, there may be other types of attacks that create vulnerable environments, which could be considered in future work. We plan to prevent attacks for the case study based on our verification results and explore strategies to extend the applicability of MFF-IoT to other IoT applications that require user authentication. To improve the usability and reusability of MFF-IoT, we intend to implement algorithms that make the conversion process more automatic and efficient. We also aim to integrate reliability metrics into our framework to provide users with a more comprehensive understanding of their system’s security.

In summary, our future work includes preventing attacks for the case study, extending the applicability of MFF-IoT to other IoT applications, improving the usability and reusability of MFF-IoT, and integrating reliability metrics into our framework.